08:06 <warpme_> hi *

08:07 <warpme_> just quic q: do we have any support for thermal sensors and/or DVFS on s905 familly?

08:16 <narmstrong> warpme_: yes

08:33 <warpme_> narmstrong: great. I’m asking as on testing 5.3-rc8 mainine on 905w (tx3) I don’t see anything in /sys/class/thermal. Do I miss someting?

08:39 <repk> and in /sys/class/hwmon ?

08:40 <narmstrong> shoudl be in hwmon, if you want thermal you'll need to add a thermal zone in the DT like the vim2

08:41 <warpme_> repk, narmstrong: qll. thx. let me play with this. I’ll report how it goes soon!

11:29 <khilman> warpme_: the thermal driver isn't updstream yet, but if you try my `integ` branch, it's in there for broader testing, but only sets up thermal zones for a couple boards (e.g. odroid-n2)

11:29 <khilman> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/

11:34 <warpme_> khilman: thx alot. I just added thermal zones to my tx3 mini and all seems to be working. You mentoin thermal driver. Will this thermal driver not using scpi interface?

11:38 <khilman> on newer chips (g12[ab], sm1) thermal is no longer behind scpi

11:41 <warpme_> indeed i see :-). Also I see some suspend related things :-) Is there currently any support for S3 on s905/912?

11:43 <narmstrong> warpme_: nop, S905/s912 reuses standard PSCI functions for suspend, and overriding them is not allowed, thus it has been rejected

11:44 <narmstrong> warpme_: http://lkml.iu.edu/hypermail/linux/kernel/1611.0/01583.html

11:44 <narmstrong> this enabled suspend

11:44 <narmstrong> the vrtc has been merged recently

11:44 <khilman> sorry, I misunderstood what soc you were on. I thought you were on a newer one.

11:45 <khilman> narmstrong is right, for the older chips, there are firmware issues with how they implemented PSCI

11:45 <narmstrong> ```

11:45 <narmstrong> this needs to go anywhere, it should live in the existing PSCI driver.

11:45 <narmstrong> ```

11:45 <narmstrong> That is to say, NAK to other driver invoking PSCI functions.

11:45 <narmstrong> While I am very much not happy with platform-specific extensions to PSCI, if

11:46 <warpme_> right. If i’m reading correctly supported event to resume from s3 is rtc alarm only? (no usb)?

11:47 <narmstrong> warpme_: it's hardcoded in the SCP fw loaded by the BL31

11:47 <khilman> some GPIOs are also configured for wakeup (and hooked to buttons) but it's firmware specific which wakeup sources are configured.

11:48 <khilman> but what we've seen so far, I think the VRTC is enabled for pretty much all platforms

11:56 <warpme_> right - it looks like old small ir hw circuit (where long enough remote key press can triger gpio state change) is only solution for appliance resume from s3 by ir remote?…. but how then this tx3 box is resumed from s3 by red power button on original remote with origial android? I suspect onboard ir can trigger resume in scpi controler?

11:57 <narmstrong> yes usually ir can wakeup

11:57 <narmstrong> cec could, but we don't program the current logical address before going in suspend

11:58 <warpme_> it will be interesting to play with this…. will http://lkml.iu.edu/hypermail/linux/kernel/1611.0/01583.html patchset go with 5.3-rc8?

11:59 <narmstrong> you can try to rebase it, but instead rebase on https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/log/?h=v5.4/integ since it contains the vrtc driver, you'll only need to add the DT node for vrtc

12:08 <warpme_> right. but I prefer to go with mainline as currently I have single kernel working on rpi3/s905/s912/rk33xx/h6. So backporting will require: 1\meson_gx_pm.c changes from above msq; 2\vrtc like in https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/commit/?h=v5.4/integ&id=fb7694e614f0817cf0937a4e89fc86255b1b06ab ?

12:32 <narmstrong> yep

20:37 <Tartarus> Hey all, I have an s905x based board that Ive managed to get into a fairly funky bricked state. The vendor U-Boot is crashing because it doesn't like the contents I flashed in, is there some way to force BL to drop into USB recovery mode?

20:45 <wens> ground/short emmc pins?

20:48 <Tartarus> is there often something exposed enough for that?

20:48 <Tartarus> I have jumper wires around

20:48 <Tartarus> but nothing with a more fine point

20:49 <wens> oh right.. bga pins :(

21:41 <chewitt> Tartarus: exactly which board?

21:42 <Tartarus> https://smile.amazon.com/gp/product/B07HD6W4M9/ref=ppx_yo_dt_b_asin_title_o00_s00

21:42 <Tartarus> So, oops, s905w not x

21:42 <Tartarus> But close enough

21:43 <chewitt> there's probably a reset button on it somewhere

21:44 <Tartarus> There is

21:45 <Tartarus> But U-Boot is crashing before we check if the button is pressed

21:45 <chewitt> if it has an analogue audio out port it's sometimes at the bottom of the socket .. unbend a paperclip

21:45 <chewitt> u have uart log?

21:45 <Tartarus> Sure, moment

21:47 <Tartarus> UART log of crash https://www.irccloud.com/pastebin/FIHTP9Yb/bootlog.txt

21:51 <chewitt> did you write a new image to emmc?

21:52 <chewitt> or it just fcuked up on its own?

22:01 <Tartarus> Yeah, I'm attempting to put something very different on the eMMC and messed it up

22:01 <Tartarus> (I've got another one of these boxes coming and I know what I need to try differently next time in the table)