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

Open Source and information security mailing list archives

Date:   Thu, 18 Oct 2018 11:37:57 +0200
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Dave Stevenson <dave.stevenson@...pberrypi.org>,
        pbrobinson@...il.com
Cc:     devel@...verdev.osuosl.org, tuomas.tynkkynen@....fi,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

Am 18.10.2018 um 11:22 schrieb Dave Stevenson:
> On Wed, 17 Oct 2018 at 17:51, Peter Robinson <pbrobinson@...il.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@...e.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.

>
> 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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives