<minecrell>
Marijn[m]: What do you mean wiht "In part because we currently have prepare_prev_first which only applies to enable/prepare, but not to disable/prepare"? Pretty sure it should change the ordering for both enabling and disabling?
<Marijn[m]>
It didn't for me
<Marijn[m]>
E.g. I could send DSI commands (enable TE, enable whatever), in prepare(), but not in unprepare()
<Marijn[m]>
I intended to reply that to one of my massive-panel-patch-series review, but never got to that
<minecrell>
also IMHO the implementation in drm/msm is wrong because it does full power up + stream start in pre_enable() and stream end + full power down in post_disable(), which isn't right for initializing video mode panels (but I guess you don't have those much anymore on newer devices)
pespin has joined #linux-msm
ZkliA_ has joined #linux-msm
<Marijn[m]>
minecrell: oh thanks, I'll give that a read. Indeed figured this was something that should be fixed, there's a very long discussion thread on the topic elsewhere
ZkliA__ has quit [Ping timeout: 480 seconds]
<Marijn[m]>
minecrell: no video mode for me but there have been various (dsc related) complaints about not getting video mode to work here, and I can barely help them
pespin has quit [Remote host closed the connection]
<Rayyan>
konradybcio: do I also need to add a label to the touchscreens defined on 735 and 830 (because they are on a different bus)?
<Rayyan>
now that I think about it, not sure how it would work with the `/delete-node/ &touchscreen`
<calebccff>
in dt schema, how do you define properties of a child node where the node name doesn't include an "@"? The schema validator seems to falsely try and match all the properties to my subnode regex (compatible: ['qcom,qmi-cooling'] is not of type 'object')
<calebccff>
I guess I want an "if type: object" condition, but i dont know how to do that
<calebccff>
put more simply, is it supported to have child nodes with totally arbitrary names?
heyda has left #linux-msm [#linux-msm]
<konradybcio>
yes
<konradybcio>
to schema, subnode names are just properites
<konradybcio>
Rayyan: hm, interesting thought
<konradybcio>
you can decompile with dtc -I dtb file.dtb -O dts >out.dts and check the output
<HappY[m]>
I found one brightness control related issues.. any suggestions for this.. brightness control working.. but very much buggy
<calebccff>
konradybcio: right, so the issue is my regex for matching any arbitrary child node ("^[a-z-]+$") ALSO matches the compatible property
<calebccff>
and I'm not sure what the magic incantations are to prevent that
<calebccff>
i mean there's the chaotic neutral approach of "^(?!compatible|qcom,instance-id|status)[a-z-]+$" but that CAN'T be right... right?
<konradybcio>
calebccf what are the subnodes going to be?
<konradybcio>
they should probably have some common prefix/sufix/component
<calebccff>
konradybcio: i honestly don't think it makes sense to do that, the node name is used exclusively to generate the cooling device "type" property, example: https://p.calebs.dev/f47a56
<konradybcio>
HappY🤗: try using mipi_dsi_dcs_set_display_brightness_large instead of mipi_dsi_dcs_set_display_brightness
<calebccff>
im gonna go the route of just documenting each subnode, that way at least it encourages documenting what these arbitrary label strings actually mean...