02:00 <steev> jstultz: why do you disable venus in you db845c mainline config??

02:01 <bamse> steev: because the main venus device races with the two sub-devices...

02:03 <jstultz> bamse: steev: also with the static config, the firmware loading fails (as the vendor part isn't yet mounted) and takes forever to give up and boot.

02:03 <bamse> jstultz: ahh, i see

02:04 <steev> ah, that makes sense

02:04 <bamse> jstultz: but remind me again, what's the symptom of that race? just a reboot?

02:04 <jstultz> bamse: I'm carrying the locking fix to avoid the crash.

02:04 <steev> i have that locking fix here too

02:04 <jstultz> bamse: yeah, the board crashes and reboots.

02:04 <steev> but i've also never seen *that*

02:04 <bamse> jstultz: i made this awesome clock fix that made it possible to bring up display on sm8350, but it apparently tripped steev's device badly

02:05 <bamse> jstultz: but it's apparently not the same issue then

02:05 <jstultz> 8350 is what? I can't keep track when there's more then 3 digits.

02:05 <steev> but it did make the blue screen black, which is somewhat of an improvement?

02:06 <bamse> jstultz: 888

02:06 <jstultz> steev: we are moving the Venus fw to the ramdisk so it should start working with the static config

02:07 <jstultz> bamse: ah, very cool

02:07 <bamse> steev: nah, the blue screen indicates that mdp is ticking but is somehow isn't able to read the pixels to display

02:07 <steev> makes sense, it's a module here so maybe that's why i never ran into it

02:07 <bamse> steev: black probably means that the display block isn't ticking anymore

02:07 <steev> the backlight is on, but probably

02:08 <bamse> jstultz: seems to be a bunch of things in the power-domain/clock space where we used to wing it and 8350 got stricter

02:09 <bamse> jstultz: so on the path to 8450 (snapdragon 8 gen 1) and 8cx gen 3, i finally managed to figure out how to please the display clock controller...but apparently not steev

02:10 <steev> bamse: i'm still carrying the patch from lumag that he'd sent me to test, maybe i should back that out?

02:10 <steev> https://github.com/steev/linux/commit/c8206985f8207e515c09aebbc3332d758287d64f iirc

02:25 <steev> hm, yeah, okay with that reverted, and your patch i got video

02:26 <steev> https://paste.debian.net/1221912/ the rcg stuff is back, and venus made an appearance too

03:08 <bamse> steev: you're saying that without dmitry's patch it works as good as it used to? with the old warning?

03:09 <steev> i need to reboot a bunch more to test

03:10 <steev> but does seem to

03:11 <bamse> okay good, because afaict there should really be no different on sdm845

03:17 <steev> yeah, i think the part where you return 0 in your patch, his patch kind of relied on

03:18 <steev> so clocks were just getting deferred forever?

03:18 <steev> roughly

03:25 <bamse> before my change, when you switch parent for a disabled rcg, the register configuration would be written...but the bit that you write to "commit" the change in the hardware was never written

03:25 <bamse> then as you hit enable, we just hit that bit

03:25 <bamse> so we sort of used the configuration register in the rcg as a "temporary variable"

03:26 <bamse> the problem i spotted on 8350 is that when MDSS_GDSC is toggled, it will actually commit the configuration...

03:26 <bamse> so the rate-change for a disabled clock would actually kick in, while we thought it was disabled

03:27 <bamse> the problem is that for the rcg to operate over one of these updates, it needs to have both the old and new parent (if different) enabled, or the hardware will stall

03:27 <bamse> so if linux has turned off the parent, and we call clk_set_rate() and then gdsc_enable(MDSS_GDSC) we would stall the rcg

03:28 <bamse> so what my change does is to leave the hardware alone and once we later try to enable the rcg we actually apply the configuration change as well as commit the change

03:30 <bamse> steev: what's interesting in this journey is that i got 8350 to boot without clk_ignore_unused and pd_ignore_unused...so i got a couple more patches to post but i think we can do the same on sdm845

03:30 <bamse> and thereby clean things up a little bit more

04:41 <steev> that would be awesome

05:01 <Danct12> anyway to identify the device has which touch screen? for example on redmi note 7 (lavender), some uses synaptics and some uses novatek

10:15 <konradybcio> you have to just rely on probe failures, probably

10:16 <konradybcio> unless you want to know which one is currently on your device, then you can run evtest and it should show you the device name