01:45 <macromorgan> clocks are making my eyes tired. Do you know an easy way to dump the children names for a given parent from the clk subsystem?

01:45 <macromorgan> I think for now I'll just submit this fix upstream minus the phy-supply node... 2 seconds of wonky USB will have to wait to be resolved until this clock thing can be solved

01:48 <macromorgan> does the fact that usb480m is marked as a protected clock and also appears to be a child of usb480m-phy which tries to get disabled matter?

01:48 <macromorgan> i.e. we're trying to disable the parent of a critical clock?

01:51 <macromorgan> answered my own question... that's the problem

01:52 <macromorgan> so usb480m is a critical clock. Assume it's an orphan until its parent usb480_phy gets enabled; after which I can confirm it prevents usb480_phy from getting disabled (I removed usb480m as a critical clock and the error went away).

01:53 <macromorgan> I'm pretty sure usb480m is in fact a critical clock since it's also used by the GPU for some reason... so I'm wondering if there's a way to reparent the clock when we try to disable its parent (or drop it back to "orphan" temporarily)

08:56 <wens> eballetbo: fyi this is an old report of the MIPI DSI failure # https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.camel@gmail.com/

09:22 <eballetbo> Thanks wens, we will give a try

12:04 <punit> wrt RK3399 ethernet issue.. I compared /sys/kernel/debug/clk/clk_summary between a working and a broken kernel

12:04 <punit> The only difference is in the prepare and enable counts of "clk_usbphy[01]_480m"

12:08 <punit> I don't see how the usb clocks are related to the gmac. Any ideas?

12:09 <punit> mriesch: Thanks for the patches. They don't seem to help though. :(

12:12 <mriesch> punit: well it would have been a lucky shot... thanks for testing

12:13 <mriesch> once we found the actual cause of this bug we can take again a look at those patches, i think they do clean up the glue driver a bit

12:19 <punit> Ack, it can definitely use some cleanup.

12:21 <mriesch> as to the differences in clk_summary: interesting, but is this clock somehow related to ethernet at all?

12:26 <punit> I couldn't find any relation in the documentation or the device tree.

12:27 <punit> But it's suspicious as it's the only difference with your patch

12:27 <punit> There are ~450+ odd clocks in there...

12:36 <mriesch> interestingly there was a discussion about this clock (or at least one with a similar name) in this channel earlier this day

12:39 <punit> Thanks for the pointer I had missed that. The mention of usbphy480m being used for unrelated functions seems interesting

12:40 <punit> macromorgan: Maybe /sys/kernel/debug/clk/clk_summary is what you're looking for

12:45 <macromorgan> yes, seems our problems are somehow related?

12:47 <macromorgan> the issue I have is that the usb480m clock is marked as critical and is also a child of the usb480m_phy clock. When the usb PHY driver tries to undo setting the clock because it's not ready to fully probe yet it can't because of the critical child

12:47 <pgwipeout[m]> On a fun note, I played around with this a bit. I found if I run `pm_runtime_put_sync(dev);` after `pm_runtime_get_sync(dev);` in the offending code path it hard locks, but adding `pm_runtime_disable(dev);` removes the unbalanced enable warning.

12:47 <pgwipeout[m]> So something starts talking as soon as `pm_runtime_get_sync(dev);` fires.

12:50 <pgwipeout[m]> This is what I've got currently for the usbphy480 clock path:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3ba23d4e6a5008b3dfe10c038e6df8ebf9fd3e68)

12:52 <pgwipeout[m]> This is when things are working btw.

12:55 <punit> I see this with 5.15-rc1 + revert - https://paste.debian.net/1211970/

12:56 <punit> i.e., the working configuration

12:56 <punit> macromorgan: are you also looking at rk3399? Crazy co-incidence

12:57 <macromorgan> no, PX30

12:57 <macromorgan> (actually RK3326, but what's the difference aside from a VOPL?)

12:58 <punit> I know nothing about either - px30 or rk3326, except that a clock named usb480m is causing trouble there :-D

12:58 <macromorgan> yep

12:59 <macromorgan> not a lot of trouble, just making a warning

12:59 <macromorgan> but still, I like my dmesg log not full of crap

13:05 <pgwipeout[m]> Looking at the clocks only a few things of interest: `clk_usbphy_480m` can be a parent of `upll`, I wonder if that's set correctly. We have `clk_hsicphy` who's parent is also `clk_usbphy_480m`

13:24 <punit> Hmm... both upll and clk_hsicphy don't seem to circle back to gmac afaict

18:56 <macromorgan> fuck it... I can make the USB work fine if I also add regulator-boot-on and don't add the phy-supply. I'll just do that for now and note why in the patch notes, I'll leave this clock craziness for some time when I am bored or for someone who is smarter than I (basically everyone)

21:01 <norris> eballetbo: I hear you were talking about me? (I mean, bugs I'm looking at, regarding MIPI displays?) sorry, I forgot to sign back in here post freenode-fiasco

21:02 <norris> the answer to your question is yes, it's definitely a known issue, but I don't know _who_ all knows :) if you're willing to stomach a google account, this is open for reading: https://issuetracker.google.com/195913664

21:03 <norris> I believe things work if you build as a module, instead of built-in

21:03 <norris> also, somebody else noticed before: https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.camel@gmail.com/

21:05 <norris> my bug link has a hack that fixes things. it's not yet clear _why_ it fixes, so I didn't try to upstream it