04:40 <tokyovigilante> apritzel: we do but I wasn't sure whether it was best to do that separately. I have patches for the RG35XX but because there is only a single line-out there is a separate mux, headphone detect and speaker amp GPIO to manage, and the other boards may have bespoke hw. Otherwise only a simple codec { status = "okay"; } is required.

04:41 <tokyovigilante> Sorry about the timing but I only have so much free time to work on these so have to take advantage of when I can spend some time.

09:40 <apritzel> tokyovigilante: no worries, I think it's fine here, it was just a heads up: I heard of maintainers ignoring new patches sent during the merge window

09:53 <loki666> apritzel, testing tokyovigilante DE33 patches on 6.12-rc1, but kernel doesn't boot

09:53 <loki666> are all AXP717 merged ?

09:54 <loki666> kernels logs ends with

09:54 <loki666> [ 3.056939] sun50i-h616-r-pinctrl 7022000.pinctrl: supply vcc-pl not found, using dummy regulator

09:54 <loki666> [ 3.074886] axp20x-i2c 0-0034: Failed to set masks in 0x40: -6

09:54 <loki666> [ 3.067679] axp20x-i2c 0-0034: AXP20x variant AXP717 found

09:54 <loki666> [ 3.081311] axp20x-i2c 0-0034: failed to add irq chip: -6

10:41 <apritzel> loki666: interesting, thanks for the report!

10:44 <loki666> Not related to tokyovigilante patches, I just tried a bare 6.12-rc1

10:45 <loki666> Uboot/TFA ?

10:47 <apritzel> I doubt it, it looks like a write to some interrupt related register failed, and I think the code tries to verify that write

10:53 <loki666> That issue rings a bell to me...

11:16 <loki666> mmmh taught, it was this one https://lore.kernel.org/linux-sunxi/20240613233104.17529-1-andre.przywara@arm.com/ , but seems to be merge

11:22 <loki666> I'll try to switch to rsb

12:29 <loki666> it works with pmic on rsb

12:32 <loki666> that's as much as I can test, I have no clues on what's going when axp is on i2c

12:37 <loki666> maybe macromorgan has an idea ?

22:24 <iscle> I have a doubt with something about dts. (I'm writing the DMA driver for USB for those that did not follow the conversation 2-3 days ago).

22:24 <iscle> The current DTS for Allwinner D1 uses the following nomenclature to declare DMA channels

22:24 <iscle> dmas = <&dma 25>, <&dma 25>;

22:24 <iscle> dma-names = "rx", "tx";

22:25 <iscle> The DMA controller seems to always have the same channel for TX and RX, but the dts specifies both instead of just 1.

22:25 <iscle> For USB, there are 5 RX and 5 TX channels, one for each endpoint. Should I also implement the driver to read the repeated RX and TX values, or should I just declare it 1 time for each endpoint like in the following example?

22:26 <iscle> dmas = <&dma 30>, <&dma 31>, <&dma 32>, <&dma 33>, <&dma 34>;

22:26 <iscle> dma-names = "ep1", "ep2", "ep3", "ep4", "ep5";

22:26 <iscle> To be clear, right now the DTS is not specifying any DMA channels for USB, I have to write it by myself

22:26 <iscle> So I'd like feedback for any of the two options (to repeat channels or not to do so)

22:27 <apritzel> iscle: are there other users of the MUSB DMA feature? I'd check how they solve this.

22:28 <apritzel> I think the rx/tx differentation comes from different code paths involved in sending and receiving, so having them separately makes sense. Not sure how this works in your code

22:30 <apritzel> My gut feeling is that just per-endpoint elements would be fine, as you sketched above

22:31 <iscle> There are other MUSB drivers implementing DMA for other SOCs but each of them handle in their own code. One of them is, for example, "stericsson,db8500-musb" which does repeat each channel ("iep_1_9", "oep_1_9", "iep_2_10", "oep_2_10", ...)

22:32 <apritzel> do you have the code finished and working? Often those things become clearer if you look how the code would need to handle this

22:32 <iscle> At least two drivers for musb dma use separate tx and rx channels, even if they are the same

22:34 <apritzel> in general I wouldn't sweat it, reviewers on the list will complain early enough. Maybe just think about how the other way would be implemented already, just in case.

22:34 <iscle> apritzel: not yet finished nor working, it compiles at least. I will implement it by repeating the channels and then upload the code so you (or somebody else) can take a second look and lmk their opinion

22:35 <iscle> I just wanted to know if there was a general convention or not

22:39 <apritzel> I think this question is more MUSB/USB/Linux specific, probably not the right audience in here. If you really need to know before sending, ask on the list

22:41 <apritzel> was there anyone in here having trouble with audio on the D1/T113s? Just found what looks like a bug in the PLL_AUDIO0 setup, which would mean its frequency would always be halved. Does that ring a bell with someone?