On Thu, 18 Oct 2018 at 10:38, Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > > 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. Thanks Stefan. I've picked up your latest patches which mean I can get the driver loaded via the (almost) approved method. I do seem to still have issues with not getting the expected address ranges, so the driver/VPU was trying to map cached alias memory. As your patches only came through yesterday I haven't had a chance to dig through why yet. I've done a temporary hack to ensure we always map the uncached alias, but that can't persist. > > > > 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. The networking issue has been resolved :-) I've pushed where I've got to to https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b It's a touch messy due to integrating in your patches in the last 24 hours. It needs a full rebase so that my changes are on top of yours rather than haphazard. As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree and jump to either that or directly on staging. I'll see where I get to early next week. Dave _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
