07:53 <z3ntu> bryanodonoghue: CAMSS currently only supports CSI D-PHY and not C-PHY, right? I don't really see it stated clearly but based on some commit messages looks like it?

08:29 <Adrian[m]1> Marijn: (I'm the 10-bit panel guy again) I've spent some more time looking over the downstream DTS and schematics for my device. The backlight is handled by a separate chip (NT50372S) which is apparently wired via a node called "SWIRE". In my downstream DTS I see a "qcom,qpnp-amoled-regulator" collection with "qcom,swire-control". Now, I assume these must be enabled for the backlight to function. The issue is that these seem to be

08:29 <Adrian[m]1> entirely unsupported by mainline and konradybcio mentions in https://lore.kernel.org/linux-arm-msm/8737f195-673f-4837-9a2a-80c3be93e6cf@linaro.org/ that they are configured by XBL. Sadly I'm on SM8450, where the presence of the "cont_splash_memory" region in the mainline DTS causes XBL to keep MDSS clocks enabled, so I have to remove that region entirely. My guess now is that removing this region also means XBL won't configure these

08:29 <Adrian[m]1> regulators. My question now is: Am I making this up or does this sound plausible?

08:49 <Adrian[m]1> * Marijn: (I'm the 10-bit panel guy again) I've spent some more time looking over the downstream DTS and schematics for my device. The backlight is handled by a separate chip (NT50372S) which is apparently wired via a node called "SWIRE". In my downstream DTS I see a "qcom,qpnp-amoled-regulator" collection with "qcom,swire-control... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/hrcQxmWAyPMNzlqquitPLpeF>)

08:56 <Adrian[m]1> ...and I have one more entirely unrelated question about supplies for more recent bluetooth chips. The names, amount of vregs and their voltages are completely different in downstream sources and mainline, and I basically have no idea what to put where with these.

08:56 <Adrian[m]1> This is from msm-5.10

08:56 <Adrian[m]1> vs mainline

08:57 <Adrian[m]1> Is there any way I can do this without randomly guessing around?

08:58 <Adrian[m]1> * guessing around? (I have WCN6855 to be exact)

08:58 <Adrian[m]1> * guessing around? (I have WCN6855 to be exact, which uses QCA6490 vregs in downstream)

11:05 <bryanodonoghue> z3ntu yep

11:06 <bryanodonoghue> Mostly all that's required is upstreaming the PHY init sequence - publicly available in techpack for the C-PHY and you'd need a dts method to differentiate the init mode

11:07 <bryanodonoghue> I've given it thought but, since I have no hw to test it out on...

11:08 <bryanodonoghue> also dts is legitimate since per my understanding there are hw level changes to PCBs needed - soldering or desoldering caps on the rb5 for example

11:13 <z3ntu> bryanodonoghue: ok.. sounds reasonable. I guess once I have my two D-PHY camera sensors on FP5 working then I might take a look at the last C-PHY sensor ;) also found that there's dt-bindings for this stuff, e.g. bus-type = <MEDIA_BUS_TYPE_CSI2_CPHY>;

11:14 <z3ntu> but since it's already not simple to get the other sensors working, I think staying with D-PHY sensors for now is the better choice

12:47 <bryanodonoghue> I mean "it should only be the init sequence and the hardware caps" is my initial ignorant stock reply

12:47 <bryanodonoghue> There may be something more than that required in reality YMMV

15:10 <z3ntu> imagined something like that, that's why I want to ignore that sensor for now^^

15:11 <z3ntu> but I don't think I can get any sensor working in time for FOSDEM, too bad :)