14:02 <strongtz[m]> Hi everyone. I'm trying to bring up display on a SM8550 device, but I encountered disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration and disp_cc_mdss_ahb_clk status stuck at 'off'. Any advice maybe?

14:06 <strongtz[m]> dmesg here, https://bpa.st/7E6Q

14:35 <strongtz[m]> btw I'm compiling everything as built-in

16:29 <z3ntu> Anybody got some knowledge on lpg with mpp pins and the pwm behind it? I'm trying to get it working on some old-school msm8226 device but having some troubles wrapping my head around it.

16:29 <z3ntu> For sure I know the two leds are connected to mpp4 and mpp6 (and pulling them low makes the led on, used as current sink then). Downstream dts suggests mpp4 somehow uses pwm channel 0 and mpp6 pwm channel 5 e.g. for blinking (I'm sorta assuming those pwm channels are the ones from lpg block). Also I'm quite sure mpp4 is configured to use the dtest1, and mpp6 the dtest2 in downstream.

16:32 <z3ntu> So far my theory is that I configure lpg led@1 and led@6 to produce some pwm signal, lpg is configured to connect(?) led@1 (=pwm0) to dtest1 and led@6 (=pwm5) to dtest2, and the mpp I have a pinctrl state also with qcom,dtest = <1> and <2> respectively.

16:33 <z3ntu> Also fwiw I believe downstream only uses the pwm for blinking (on-off), not for dimming to lower brightness. Worst case I make it a gpio led with the mpp pin and that should work also, but would be nice to configure this fully

16:37 <konradybcio> lpg should eat way less power than cortex a7

16:37 <z3ntu> Also I've been looking at these commits for reference, seems to be a similar setup https://github.com/andersson/kernel/commit/786fbb7c93b00272e86e49af85a72d7f4e229811 https://github.com/andersson/kernel/commit/9236c290043a75d16aa16b01f4e120feb2ed22b0

16:43 <strongtz[m]> I found this comment regard the disp_cc_mdss_ahb_clk problem, not sure if it's relevant :/ https://patchwork.kernel.org/comment/24598889/

16:50 <strongtz[m]> s/regard/regarding/, s//`/, s//`/

18:24 <HappY[m]> <z3ntu> "Also I've been looking at..." <- `[ 1.509422] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x9bc3f000, fsynr=0x200011, cbfrsynra=0x1c00, cb=10` dear are you solve this issue ? with panel i am receving this errors..

21:57 <z3ntu> bamse: in case you're not reading all messages, ping. Maybe you have some ideas about the mpp/dtest/lpg thing from some hours ago :)

22:01 <bamse> z3ntu: what pmic is that?

22:01 <z3ntu> pm8226 (used with msm8226, Snapdragon 400 from many years ago)

22:01 <bamse> z3ntu: quite likely you don't need to resort to the (undocumented) dtest feature...

22:02 <z3ntu> I'm pretty sure downstream sets some registers regarding dtest if I followed the code correctly

22:02 <z3ntu> qcom,source-sel = <8> => dtest1 (because 8>>1 = 4 and PMIC_MPP_SELECTOR_DTEST_FIRST=4)

22:02 <z3ntu> qcom,source-sel = <10> => dtest2 (because 10>>1 = 5)

22:02 <bamse> so it's not just finding the pwm signal on function 1 or 2?

22:03 <z3ntu> I'm not aware that there is pwm muxed onto the mpps?

22:03 <z3ntu> This is downstream declaration of the leds https://github.com/nightcore500/android_kernel_htc_msm8974-caf_rebase/blob/lineage-14.1/arch/arm/boot/dts/msm8226-720p-mtp.dtsi#L149-L184

22:04 <bamse> hmm, so we have the function "sink" on db820c mpp2...that's odd, or just too long since i looked at this mess

22:06 <z3ntu> sink does get selected from qcom,mode-ctrl which sets the bit 7-4 of LED_MPP_MODE_CTRL

22:07 <z3ntu> from my understanding on this device the led is always connected to power, and when the led is off, the mpp is high so no current flows, and only when the mpp is low then current flows and the led is on

22:07 <z3ntu> so it makes sense to switch the mpp into sink mode

22:07 <bamse> right

22:08 <bamse> i just didn't expect "function" to be "mode"

22:08 <z3ntu> the naming downstream->mainline is really messed up, nothing matches really... but after comparing the code for register writes I'm half sure my theory is correct :P

22:09 <bamse> but, as you say...the pwm will output a signal on some internal pin, which can be used as control signal for the mpp

22:10 <bamse> i think downstream dts might be inherited from the pm8921-era, and i just ignored that when i did the upstream stuff

22:11 <bamse> so the qcom,dtest on the lpg side is supposedly denoting how the invidiual pwm channels are connected to the dtest lines...and then the qcom,dtest on the mpp is used to connect input signal to that same line

22:12 <z3ntu> that's kind of what I thought.. but I honestly didn't find any writes to the register that qcom,dtest in lpg writes to in downstream

22:13 <bamse> in sc8280xp-lenovo-thinkpad-x13s.dts you find edp_bl_pwm, which just says function = "func1", to select the pwm-input...i was expecting to see the same here...but i guess the mpp is different

22:14 <bamse> and looking at the register docs for pmi8994 seems to confirm that, and confirm that i had to do that crazy hack on db820c

22:24 <z3ntu> fun ^^

22:24 <z3ntu> I'm honestly considering just making it a gpio led for now to not have to bother with all of this

22:24 <z3ntu> already spent too much time on this haha

22:25 <bamse> z3ntu: but it's not that they poke some magic value into MODE_CTL bits 3:0?

22:26 <z3ntu> apart from setting dtest, don't think so

22:26 <z3ntu> qcom,source-sel (source_sel) => b0000XXXX of LED_MPP_MODE_CTRL (0x40) -- e.g. dtest1-x/paired/normal

22:27 <z3ntu> so it's just setting the 8 or 10 value from qcom,source-sel which I think is just dtest1 & dtest2

22:29 <bamse> sounds like it...but do you have a similar write on the lpg side?

22:29 <bamse> (and yeah, i can see why you're leaning towards a gpio-led)

22:29 <z3ntu> this drivers/leds/leds-qpnp.c driver is an all-in-1 magic box but at least I didn't see it doing something there too

22:32 <z3ntu> in led_blink_do_work it does pwm_config_us (with duty & period), then pwm_enable, small sleep, then pwm_enable again(?), then only writes LED_MPP_MODE_CTRL and LED_MPP_EN_CTRL