07:58 <warpme> tokyovigilante : i'm switching to 6.11 and on h313/616/618 i have plan to use https://patchwork.kernel.org/project/linux-arm-kernel/cover/20240921095153.213568-1-ryan@testtoast.com/ may you hint me what is timeline (assuming you have plan to address this) for missing hdmi phy support ?

08:36 <tokyovigilante> warpme: I absolutely do. once that’s accepted I’ll send in the LCD controller enablement, and then the HDMI patches. both work now but the HDMI series in particular not yet fit for majnljne

08:37 <tokyovigilante> some feedback on the DE patches would be awesome, will rebase my HDMI series on top this weekend and push it to my git repo at least

08:39 <warpme> ah perfect! Will you also push hdmi phy code? I can test: 1\how it goes on h616/313/618 and 2\ potential regressions on h6/rk3328/3399/3566/3568/3588

20:58 <tokyovigilante> yeah will rebase the trees when I have time, but probably not much point testing the HDMI code elsewhere as it will need significant work, quite a few hacks in the generic HDMI code that need reviewing, it will not get into mainline like that I don’t think.

22:05 <apritzel> so what is the interest and availability for people to work on A523/T527 mainlining? I have quite some basics now, but there is a lot of work to do still

22:40 <iscle> Nobody has ever worked on implementing DMA for sunxi musb right?

22:40 <iscle> My specific use case requires high speed usb, with low CPU usage, so I'm giving it a go. If anyone knows about previous work on this I can give it a look too. However, it does not look very complicated :)

22:50 <apritzel> iscle: godspeed! AFAIK this question pops up every now and then here, but typically people then run away ;-)

22:51 <apritzel> I just remember a long time ago people suspecting hardware issues, since AW is not using DMA in their BSP either

22:51 <apritzel> (which might be just laziness or no need or what, but might also be due to a non-communicated hardware issue)

22:51 <apritzel> iscle: but please try it, just saying that upfront, to avoid disappointment

22:52 <iscle> apritzel: In the linux kernel I have for V853 they are indeed using DMA on the driver. At least the code is there, not sure if it's enabled in the config. However, I think it is, because this particular SoC is used in Apple CarPlay USB->Wireless dongles which stream H264 video over usb to the headunit, and I'm sure it's more than 10Mbps including the audio.

22:53 <apritzel> iscle: oh well, then even better! As mentioned, those reports were years ago

22:53 <iscle> There are also other AW chips used in this kind of application, like A113 (https://www.aliexpress.com/item/1005007606633832.html)

22:54 <iscle> A133*

22:54 <apritzel> iscle: you would make yourself some friends with this, because people regularly complain about both higher CPU usage and lower bandwidth with OTG at the moment

22:54 <iscle> Maybe tomorrow I have something to test, or maybe in a few hours if I stay late at night coding this haha

22:55 <iscle> It's definitely a positive learning experience, I never dug so deep on the linux kernel!

22:56 <iscle> I'm not sure how to test the usb bandwith after the driver is done. Is there any easy way to do it, with a linux usb gadget or something?

22:57 <apritzel> I think the difference would be quite noticeable ;-)

22:57 <apritzel> do you have a working DMA driver for your SoC?

22:58 <iscle> I haven't tested it but should be identical to the d1 dma which is upstreamed already

22:58 <iscle> So it *should* work

22:58 <apritzel> ah, good!

23:00 <apritzel> SPI and UART support DMA operations, you just need to announce the DMA channel number in the DT, in case you want to test the DMA driver up front

23:00 <apritzel> (before digging around in the MUSB code, while the whole time the DMA driver is the problem)

23:01 <iscle> Then it must work, as I'm booting from SPI flash and using UART to access the machine. The DMA is indeed declared in the DT (also based on the D1 which was upstreamed)

23:02 <iscle> This is the device I'm using to test, if you're curious

23:02 <apritzel> double check dmesg, I think it announces it somewhere

23:02 <iscle> https://imgur.com/IU7lMRw

23:03 <apritzel> well, *booting* from SPI flash might mean Linux is not involved in SPI, unless you do some MTD stuff for the rootfs

23:03 <apritzel> and I am not sure, but I don't believe the console is using UART DMA transfers?

23:05 <iscle> u-boot copies the kernel and dtb to ram, but the rootfs is also in spi and gets accessed by linux

23:05 <iscle> and you're probably right about UART not using DMA

23:06 <apritzel> iscle: ah, if the rootfs is on SPI, then DMA should be used

23:07 <iscle> I'm not seeing anything in dmesg about DMA, give me a sec to check the source code and if it has some debug logs that could be enabled

23:12 <iscle> Enabled DEBUG in sun6i-dma, and it is definitely used haha, so no issues there

23:36 <iscle> Stupid question: Why in the usb driver code they use musb_readw to read the first 16 bits of the register, instead of reading all 32 bits of them? Is it any better, other than using 16 bits less of RAM?

23:39 <iscle> The 16 MSB, to make it clearer

23:56 <apritzel> the driver is quite old, so there might have been dragons there, back then? Like 16-bit busses?

23:57 <apritzel> definitely remember some Ethernet MACs with such restrictions

23:59 <apritzel> but in general, if a register has only 16 defined bits, or you don't need the upper ones, then using a 16 bit read seems alright?