Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
Daanct12 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
jhovold has joined #linux-msm
pevik has joined #linux-msm
<lumag>
Marijn[m]: regarding the mdss. Anything in debugfs/devices_deferred?
<lumag>
Regarding the DSC, feel free to submit patches. There might be issues left
<Marijn[m]>
lumag: Everything that's deferred is irrelevant for MDSS (LPASS, audio codecs - I may be missing some FW)
<lumag>
Then could you please check the returns from mdss probe?
<lumag>
Most probably it returns an error at some point during the boot
<Marijn[m]>
lumag: I definitely will, it'd be great to have this working properly upstream (and we found some patches from vkoul that indicated he may have been stuck on exactly the same issues 😬)
<lumag>
:D
<Marijn[m]>
lumag: Which probe function specifically? `msm_drm_register` succeeded (I can see all the drivers on the platform bus), but `mdss_probe()` was never called for me
<lumag>
Hmmm, how can this happen?
<lumag>
What is your base commit?
<Marijn[m]>
lumag: I'm surprised as well; identical kernel works fine on sdm845
<lumag>
Or maybe abelvesa can suggest his patchset
<Marijn[m]>
lumag: Thanks, that patch fixes it indeed!
<lumag>
:-)
<Marijn[m]>
Unfortunately there was a conflict, and strangely enough my git is very happy to give a big-fat `error: sha1 information is lacking or useless (drivers/of/property.c)` on 3-way-merge lately :(
<Marijn[m]>
lumag: cc me when you send that to the lists :)
<lumag>
It was sent, but nak'ed by Saravana.
<lumag>
He promised to debug the issue, but I never saw any updates from him.
<konradybcio>
>An example of the system where this matters is the SDM8450 MTP board
<konradybcio>
one of them is not like the other :D
<konradybcio>
(see arch/arm64/boot/dts/qcom/sdm845-mtp.dts).
<abelvesa>
Marijn[m], lumag: that is actually happening because the dispcc is dependent on dsi1_phy
<Marijn[m]>
abelvesa: Correct, I expected/understood as much. What's the desired way to address this?
<abelvesa>
well, there are multiple options here
<abelvesa>
the perfect one for us would be to fix the "supplier availability check" Saravana introduced
<abelvesa>
my suggested fix was to move the check for the target before checking the flags of that specific link
<abelvesa>
but that, according to Saravana, breaks state_sync_only
<abelvesa>
there is another RFC I sent which, if reworked a bit, might fix this issue for good:
<abelvesa>
if we remove the check for DL_FLAG_DEVICE_IS_DEPENDENT in device_is_dependent, it will work properly
<abelvesa>
all of these options are 'hacks',but maybe Saravana comes with something better
<abelvesa>
I suggest we give him another week or two and then we can push again
<abelvesa>
there are two separate usecases here
<abelvesa>
1. sdm845-mtp which has both dsi phys enabled but because they get populated by the mdss, the second check for the same link fails
<abelvesa>
2. sm8250-mtp which has only one dsi phy enabled (like Marijn[m]'s xperia) which (IIUC) fails because the second dsi phy would not even get populated (since dts disabled)
<Marijn[m]>
abelvesa: Thanks for explaining, should I try the second patch or wait for a rework? This is a bit above my league to look into, so keep using lumag's patch for the time being to have things working :)
<abelvesa>
Marijn[m], lumag: I think since the dsi1 is disabled in dts, the dispcc should be made in such a way to not use a clock that will never be available
<Marijn[m]>
abelvesa: You mean not creating those clocks at all, if they can't be parented to anything? That might be nice yes, `clk_summary` is cluttered with unparented dispcc clocks
<abelvesa>
I remmember on i.MX platforms we had a dts defined fixed-rate "dummy" clock which we would parent all the clocks which don't have their rightful parent HW/dts populated
<abelvesa>
with such a clock Marijn[m] would be able to override the input clocks for the dispcc in his xperia dts file
<abelvesa>
and instead of dsi1_phy clocks he would use that dummy clock (fixed-rate 0)
<abelvesa>
Marijn[m]: you can use lumag's patch until we fix it for good
<Marijn[m]>
abelvesa: Thanks! I'll carry on submitting things I _do_ know a thing about :D
<abelvesa>
Marijn[m]: as for clocks with missing parent not registering (or not showing up in summary), I think the benefit of that might not be worth the effort of implementing it at all
pespin has joined #linux-msm
<Mis012[m]>
out of the 7 possible parents (assuming it's still 7 on that platform), surely at least one is outside dispcc?
<Mis012[m]>
I'd even expect XO to be an option
<Mis012[m]>
if parent index 0 is not already documented, I'd say it's pretty likely to be XO
<Marijn[m]>
Mis012: Yes the driver is fully functional without DSI1 clocks, as already stated. It's just that the device link prevents the driver from probing before DSI1 appears, even if it's status=disabled
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<Mis012[m]>
hm, guess it doesn't know if all parents are needed all the time
<Marijn[m]>
Exactly
<Marijn[m]>
But you are right that it's strange to see the clocks floating in clk_summary, instead of being parented to bi_tcxo then
pevik has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]