11:59 <mgonzalez> Hello everyone :) bamse: I don't understand Vikash's answer regarding the qcom,msm8998-venus DT & driver code. It's based on your qcom,msm8996-venus code, almost line for line...

12:05 <mgonzalez> https://patchwork.kernel.org/project/linux-media/patch/0843621b-386b-4173-9e3c-9538cdb4641d@freebox.fr/#25723173

13:27 <calebccff> bryanodonoghue: ah the debugfs stuff looks incredibly helpful! I'll give it a go. The driver I'm using as a base is indeed just for D-PHY with 2 lanes, I have replaced all the register sequences with ones from downstream on my device which configures the sensor for 3 lane C-PHY mode (that is, using 9 of the 10 possible wires, the 10th wire is not even connected on op6)

13:27 <calebccff> but i should be able to try D-PHY as well on the other device I have

13:36 <konradybcio> JIaxyga: no, there's some very painful to read information in downstream dt

13:36 <konradybcio> also, no changes on 937x

13:39 <Adrian[m]1> Hi there, my device has a weird GPIO setup. The amplifier's smartpa_enable is GPIO 12, which is shared with the nxp-nci-i2c's enable-gpios. Is there a patch series or mechanism that allows for sharing this GPIO? Currently the NFC seems to probe first and the amplifier can't claim it; I can have either of them working, but not both at once. I saw https://lore.kernel.org/linux-arm-msm/20240129115216.96479-1-krzysztof.kozlowski@linaro.org/

13:39 <Adrian[m]1> for sharing GPIO resets, did anyone come up with a similar patch that covers my usecase yet? I imagine it's not that uncommon...

13:42 <JIaxyga[m]> <konradybcio> "JIaxyga: no, there's some very..." <- https://github.com/sm7150-mainline/linux/blob/e77878d0ee86591043348906cae38c947f2cc783/drivers/pinctrl/qcom/pinctrl-sm7150-lpass-lpi.c

13:42 <JIaxyga[m]> I wrote this based on a confidential datasheet, can you take a look? This looks weird to me because of the SSC part of the pins

13:49 <calebccff> KieranBingham[m]: JIaxyga: i guess it makes sense to lump the audio and SSC pins together

13:50 <calebccff> oops, sorry kieran i did not mean to tag you there !

18:20 <aka_[m]> then most suitable reg for iommus would be MMU500_SMMU_GFX/MMU500_SMMU_APP like on downstream

18:20 <aka_[m]> and then if smmu_ss_local>0 then write base

18:20 <aka_[m]> then current reg on 8916 would shift into smmu_ss_local

18:30 <aka_[m]> konradybcio: when we put new lines in nodes?

18:30 <aka_[m]> between groups of props and before new subnode?

18:34 <aka_[m]> seems new line between subnode ain't often there it is in lets say opp tables

19:04 <konradybcio> until "the great dts linting tool" (tm) is ready, your best bet for good practices is looking at the most recent trees

19:08 <aka_[m]> 1)no new legacy platform with same nodes

19:08 <aka_[m]> 2)every single dts have different order in same nodes

19:19 <aka_[m]> ok i haven't yet build it:

19:19 <aka_[m]> https://github.com/Kiciuk/linux/commits/26022024-cleaned/

19:20 <aka_[m]> ok i messed gpu yaml

19:25 <aka_[m]> and dts

19:25 <aka_[m]> lol

19:27 <aka_[m]> so i tested other a6xx device against gpu yaml and i haven't broke anything it seems

19:33 <aka_[m]> ok that would be last

19:33 <aka_[m]> https://github.com/Kiciuk/linux/commits/26022024-cleaned-2/