ChanServ changed the topic of #linux-cros-arm to:
hexdump0815 has joined #linux-cros-arm
hexdump01 has quit [Ping timeout: 480 seconds]
unixabg has quit [Remote host closed the connection]
unixabg has joined #linux-cros-arm
amstan has joined #linux-cros-arm
jenneron[m] has joined #linux-cros-arm
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-cros-arm
<hexdump0815> jenneron[m]: after looking through the v6.1.52 patch and not finding anything which might cause the usb3 breakage at all i decided to retest again
<hexdump0815> it looks like i did something wrong during my last v6.1.51 with new pmos patches testing - retesting showed that it also does not see the usb3 device
<hexdump0815> so looks like its something introduced with newer pmos patches - diffing old and new patched tree now - lets see what comes out of this
<hexdump0815> jenneron[m]: here is the diff between old and new pmos changes - https://pastebin.com/raw/etsLQhBS
<hexdump0815> maybe the phy-exynos5250-usb2.c changes also affect usb3?
<jenneron[m]> hexdump0815: i think i tested that patch
<jenneron[m]> and even without it usb 3 is still broken
<jenneron[m]> i'm not sure honestly
<hexdump0815> i guess the hsotg changes in exynos5250.dtsi have no effect as they are disabled and nowhere enabled for snow
<jenneron[m]> doesn't make sense for me
<hexdump0815> there are some clk changes in for what looks to me like video decoder (?) - maybe they have side effects?
<jenneron[m]> the right thing to do is to checkout to our lts branch, we have about 30 patches. start git bisect
<jenneron[m]> select the latest as bad, and the lts release as a good
<hexdump0815> also from the diff between old and new patches it is also not clear to me what fixes hdmi for me with the new changes
<jenneron[m]> and go on
<hexdump0815> i'm not yet willing to do kernel bisecting again :) - i'll first try to revert this one: https://gitlab.com/exynos5-mainline/linux/-/commit/1b6228bf75b6eda00626c93ac874d75683f2ec69 as it seems to be the only one which might really affect usb in some way
<hexdump0815> nice discovery along the way while looking through the pmos patches: i think we can do this https://gitlab.com/exynos5-mainline/linux/-/commit/d374681000108b0e314de54c934ec87c3164d604 for snow as well to get finer grained backlight steps
<hexdump0815> nothing which will be very important, but i guess that oe is for free ...
<hexdump0815> will check that too
<hexdump0815> oh - looks like that brightness change is already in :)
<hexdump0815> i'm out of ideas: reverting that usb2 phy patch did not fix the problem, neither did reverting the hsotg node patch, the clk naming patch or the spi flash adding patch
<hexdump0815> besides those there is nothing left among the pmos patches of the last less 10 months (when i did my last pmos kernel changes sync) which might even remotely have an influence on usb3
<hexdump0815> the difference between working and non-working usb3 for a v6.1.51 kernel is the small diff i linked in the pastebin above
<hexdump0815> that is just 715 lines of diff, most of which is obviously not related to usb - in there must be the problem somehow
<hexdump0815> ok - i think i understand what part of the problem is: for testing a cold boot is required - if i boot my usb3 working kernel after having booted a non usb3 kernel, it will not work anymore as well
<hexdump0815> jenneron[m]: i think i have it - it seems to be https://gitlab.com/exynos5-mainline/linux/-/commit/b8b48822a944ce9b701f99516b9a91f00ea71f2c - with that really deleted from the dtb usb3 works (after a cold boot)
<hexdump0815> looks like broken code somewhere which seems to evaluate this node even if it is disabled
<hexdump0815> enough for today ...
<hexdump0815> i "fixed" it by adding a /delete-node/ for it in the snow-common.dtsi - might be a useable workaround to to still keep it working for that tablet which seems to use/need it
<hexdump0815> jenneron[m]: can you please check if this fixes it for you as well? - https://pastebin.com/raw/cNAhPQbr