<steev>
lumag: weird... i probably don't have the linux-firmware packages installed on mine :D i'm trying to get it up to snuff though, and testing your merge request with the c630 ec patches applied to debian's 6.10 (and eventually moving to test the 6.11 kernel)
<steev>
sorry, i meant i'm testing your merge request for the rb* enablement, as well as adding the c630 ec on to
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
<steev>
lumag: on your c630, you don't see any rcu stalls when ipa is probed?
<lumag>
steev, no, it works
<lumag>
But I haven't been testing the debian kernel on c630.
<steev>
i wonder what i'm missing here
<steev>
lumag: fwiw, this is what i see here - https://gist.github.com/steev/2a261a6ab244e943c7ddc554f21e340f - starts around 40 seconds in when i load the ipa module (the only way i can successfully boot is to pass modprobe.blacklist=ipa ) but maybe i'm missing a commandline option
<lumag>
O
<lumag>
Interesting. Let me check it.
<steev>
the null ptr is something soundwire related, i still haven't tracked it down, it's sorta known and was supposed to be patched and i tested the patch and even sent my t-b on it, but somehow it seems i screwed up testing or something because its back
<lumag>
steev, I know what might be the issue. For quite a while I have been overriding the PSCI value
<lumag>
Otherwise the c630 wasn't coming up from suspend. So I have cluster-sleep-0: acpi,psci-suspend-param = <0x400000f4>;
<lumag>
let me check the debian kernel though. It will take a while.
<steev>
there is no rush at all :) i have the x13s and it's quite performant, i just love the long battery life of the c630 when i need to really be able to work on something
<lumag>
Yes!
<lumag>
As for the sdw issue I hope srinik or krzk can take a look at it at some point, it is reproducible both on C630 and RB3
<steev>
someone in #aarch64-laptops did, and submitted a patch, but they said no, that's bad. if you revert the soundwire.c file to... 6.7? 6.8? i think it was, it works fine
<marc|gonzalez>
I have it, but I need to check if I have all the patches that make it do something useful ;)
<marc|gonzalez>
thanks for having a look!
<marc|gonzalez>
I will report back what is hosing the system
<marc|gonzalez>
this invocation was for Angelo's sony phone
<marc|gonzalez>
I'm wondering if our FW reserves other context banks
<konradybcio>
no, they have the same msm8998
<marc|gonzalez>
same SoC, but not necessarily same FW, no?
<marc|gonzalez>
This is purely a software issue
<marc|gonzalez>
(I think, I have been wrong in the past)
<konradybcio>
this is from before the times qcom re-released the same soc with 10 different firmware skus
<konradybcio>
(this is an artistic exaggeration but you get the point)
<marc|gonzalez>
OK I will call you "the artist formerly known as konrad" then :)
<lumag>
steev, ok, I also got the IPA issue
<lumag>
Strangely enough, my testing kernel boots perfectly fine.
<lumag>
Maybe the difference is in the coresight, I usually don't enable that
<lumag>
Also I don't have 'quiet' in the testing boots.
<konradybcio>
lumag of course console prints fix issues ;)
<lumag>
konradybcio, btw: any ideas why the sdm845 RPMh can start roaming around on its own? I'm always getting RPMh timeout on rebooting the device and with the Debian config I also got it once during the bootup.
<konradybcio>
??
<lumag>
konradybcio, don't have a log at this point, but on c630 I'm getting the WARN_ON(1) in rpmh_write_batch() in the timeout path.
<konradybcio>
oh wow you must have messed something up badly
<lumag>
Just 6.10 + usb patches
<lumag>
And with debian it's pure 6.10
<marc|gonzalez>
lumag: in the tdp158, pin 36 is "Operation Enable/Reset Pin" documented as "OE = L: Power Down Mode -- OE = H: Normal Operation -- Internal weak pullup: Resets device when transitions from H to L"
<marc|gonzalez>
In the binding, I declared this as enable-gpios: description: GPIO controlling bridge enable.
<marc|gonzalez>
In the DTS, enable-gpios = <&tlmm 17 GPIO_ACTIVE_HIGH>; pinctrl-0 = <&hdmi_en>; pinctrl-names = "default";
<marc|gonzalez>
In the driver code, tdp158->enable = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
<marc|gonzalez>
Is that correct? phh told me there is a difference between an "enable" GPIO and a "reset" GPIO. I'm confused.