17:18 <rcn-ee> zmatt: pinged you over email, uio is on the chopping block, last chance for your piece.. https://lore.kernel.org/lkml/2024032631-excursion-opposing-be36@gregkh/t/

19:02 <zmatt> rcn-ee: I do agree with Andrew that if the mainline driver has been broken for ages, and nobody is interested in patching up the driver in mainline, then instead of maintaining the patches out-of-tree one may as well maintain the entire driver out-of-tree

19:09 <zmatt> it's a pretty trivial driver anyway

19:13 <zmatt> the main benefit it offers over the generic uio_pdrv_genirq is slightly more efficient irq handling and the facility to allocate a chunk of shared ddr memory... honestly I'd really like a better way to allocate such memory, e.g. maybe a way to attach a dmabuf to the pru driver (to keep it pinned and provide its physical address to userspace)

19:14 <zmatt> remoteproc-pru still has no way to do that either right?

19:15 <zmatt> I remember you ended up using uio for shared memory anyway even after officially switching to remoteproc (but only for pru memory, no way to allocate ddr memory)

21:35 <rcn-ee> and that remoteproc memory sharing hack @jkridner was a one off..idk.. memory access and irq was the big thing uio allowed (easily).. to andrew's point, what do we need to add to remoteproc_pruss that would make uio users happy.. i kinda want to say it needs to allow existing firmware to load.. idk..

21:36 <rcn-ee> we will probally revert and backport it forever, but it would be nice to have a forward option.. (some newer ti parts don't even have pruss)

21:47 <jkridner> zmatt had pointed out that we could memory map the data memory under the remoteproc driver.

21:48 <jkridner> i think that is enough for *most* uio users, though something like prudebug would not work with it.

21:49 <jkridner> unclear if this can be a use case for putting the driver upstream, maintaining out of tree or motivation to add more debug features to remoteproc.

21:50 <jkridner> gdb on remoteproc sounds sane to me.

21:53 <rcn-ee> the nice thing, Andrew is wiling to add something... We need to figure out what we need and ask for it.. didn't your mem just use memmap to grab it?

21:53 <rcn-ee> https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.14.y/patches/drivers/uio_pruss_shmem/0001-uio-add-uio_pruss_shmem-driver.patch

21:54 <rcn-ee> ^ @jkridner patch

21:55 <rcn-ee> i thought irq control was also important to uio/pruss users..

21:55 <rcn-ee> (or lack of hard irq, do what you want irq)

21:57 <jkridner> yeah. irq is important too.

21:57 <jkridner> but, you can do fast circular buffers without it.

21:59 <jkridner> with what i got, mmap and /dev/mem was all that you needed for shared memory.

22:00 <jkridner> i had c examples in cloud9-examples.

22:00 <rcn-ee> then it's mostly pinging https://github.com/dinuxbg/gnuprumcu hey new interface.. i don't know who is maintaining llvm..

22:01 <rcn-ee> https://github.com/beagleboard/cloud9-examples

22:02 <rcn-ee> https://github.com/beagleboard/cloud9-examples/blob/v2020.08/BeagleBone/AI/pru/shared.pru1_1.c

22:04 <rcn-ee> this was zmatt's https://github.com/mvduin/py-uio/blob/master/pru-examples/ddr-ping.py https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/ping.pasm

22:05 <rcn-ee> honestly, mainline will want something sane... mmap /dev/mem is off the table, it'll probally be dmabuf or cma

22:06 <rcn-ee> cma is just a carve out, dmabuf would be dynamic

22:06 <rcn-ee> dmabuf would be (more) dynamic

22:08 <rcn-ee> do we have any hope of running old binaries.. toggle i/o should work.. but memory and irq assumptions probally break..

23:27 <zmatt> the ddr memory allocated by uio-pruss is also at a runtime address

23:27 <zmatt> you can see my ddr-ping passes the address to the pru program

23:28 <zmatt> but honestly if you were to extend remoteproc with enough access to allow everything you can do with uio, then you'll have eliminated every reason to use remoteproc in the first place

23:28 <zmatt> for userspace users anyway, remoteproc is more useful for kernel users

23:29 <zmatt> like, remoteproc is really designed with the idea of loading some fixed-function blob onto a remote core with an associated kernel driver to manage it and interact with it

23:31 <zmatt> but in the usage model where a user is developing custom code that spans between linux userspace and pru, the ideas behind remoteproc just don't work and its protections serve no benefit and just get in the way

23:31 <zmatt> it's just overhead and inflexibility

23:34 <zmatt> so while I do think uio could be improved upon, I don't think shoehorning all of its functionality into remoteproc makes much sense

23:40 <zmatt> btw for irqs you can still use uio_pdrv_genirq anyway, with or without demultiplexing through a ti,pruss-intc device

23:56 <zmatt> the only difference is that when the irq fires, uio-pruss will disable the irq in the pru-intc which means userspace needs to do a register write to reenable it, while uio_pdrv_genirq will disable the interrupt in the kernel hence userspace needs to do a system call (write()) to reenable it