Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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.

  Dave
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux