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

[Dave Stevenson]

On Thu, 18 Oct 2018 at 10:38, Stefan Wahren <stefan.wahren at i2se.com> wrote:
>
> Am 18.10.2018 um 11:22 schrieb Dave Stevenson:
> > On Wed, 17 Oct 2018 at 17:51, Peter Robinson <pbrobinson at gmail.com> 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 at i2se.com>
> >>>>>
> >>>>> 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