Am 18.10.2018 um 11:22 schrieb Dave Stevenson: > On Wed, 17 Oct 2018 at 17:51, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >>>>>> Drop various pieces of dead code from here and there to get rid of >>>>>> the remaining users of VCHI_CONNECTION_T. After that we get to drop >>>>>> entire header files worth of unused code. >>>>>> >>>>>> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that >>>>>> snd-bcm2835 can still play analog audio just fine. >>>>>> >>>>> thanks and i'm fine with your patch series: >>>>> >>>>> Acked-by: Stefan Wahren <stefan.wahren@xxxxxxxx> >>>>> >>>>> Unfortunately this would break compilation of the downstream vchi >>>>> drivers like vcsm [1]. Personally i don't want to maintain another >>>>> one, because i cannot see the gain of the resulting effort. >>>>> >>>>> [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm >>>> >>>> I feel like everyone else already knows the answer but why don't we just >>>> merge that code into staging? >>> Dave's been working on a new VCSM service where the firmware can call >>> back into Linux to allocate (instead of just having a permanent carveout >>> of system memory that the firmware allocates from), and lets us make >>> dma-bufs out of those buffers. That driver makes a no-copies v4l2 media >>> decode driver possible, which would then let Kodi and similar projects >>> switch from downstream kernels with closed graphics to upstream kernels >>> with open graphics. >>> >>> Given that the new VCSM service is a rewrite, it's not clear to me that >>> importing the old VCSM driver is a win. But maybe we should go raid >>> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab >>> the new drivers. Upstreaming the VCHI audio driver to staging has >>> clearly been a win for it, so maybe other eyes on the new v4l2 codec >>> could help Dave along in stabilizing it. >> I think that makes sense as long as the firmware side changes are in >> place so it can actually be used. > The firmware has supported the necessary for dmabuf import since Sept 2017. > > The new vcsm driver currently only supports importing from other > kernel modules as I cut it back to the bare minimum to ease > upstreaming. To be a complete replacement of the existing then it > needs to support userspace alloc/free/import/mmap. I did have most of > that working, but will add it in stages. > The codec code is working for decode but something is off for setting > formats on encode. > Both drivers are loading through DT at the moment as I couldn't get > Eric's platform driver stuff working. IIRC A combination of modules > not getting loaded and getting the appropriate coherent DMA mask set > (being under soc in DT gives the correct mappings, but being a > platform driver didn't). I'm working on these issues and i will post a proper solution soon. In case you need a hack in order to test your stuff, i can prepare a branch for you. > > I'm fire-fighting a networking issue at the moment, but hope to be > back on codecs next week. > Could you hold off raiding my trees until say Fri 26th Oct so I can > ensure they are fully up to date? If I get a chance then I'll start > the work of porting into staging before then. The merge window will open soon, so i don't see the need to hurry. Thanks Stefan > > Dave > > _______________________________________________ > linux-rpi-kernel mailing list > linux-rpi-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
