mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Wahren <stefan.wahren@i2se.com>
To: Dave Stevenson <dave.stevenson@raspberrypi.org>, pbrobinson@gmail.com
Cc: devel@driverdev.osuosl.org, tuomas.tynkkynen@iki.fi,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" 
	<linux-rpi-kernel@lists.infradead.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Date: Thu, 18 Oct 2018 11:37:57 +0200	[thread overview]
Message-ID: <f358db9f-1b7f-d0c6-ace5-64b908f08b63@i2se.com> (raw)
In-Reply-To: <CAAoAYcPyB-Xjh+BfSsUgbmRGP+M3LmHcjxshnDDqB8=JvMrjCg@mail.gmail.com>

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

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

  reply	other threads:[~2018-10-18  9:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-04  9:37 Tuomas Tynkkynen
2018-10-04  9:37 ` [PATCH 1/7] staging: vc04_services: Drop pointless stub functions Tuomas Tynkkynen
2018-10-04  9:37 ` [PATCH 2/7] staging: vc04_services: Drop 'connection' field from SERVICE_CREATION_T Tuomas Tynkkynen
2018-10-04  9:37 ` [PATCH 3/7] staging: vc04_services: Drop trivially unused fields " Tuomas Tynkkynen
2018-10-04  9:37 ` [PATCH 4/7] staging: vc04_services: Drop declaration of vchi_crc_control() Tuomas Tynkkynen
2018-10-04  9:37 ` [PATCH 5/7] staging: vc04_services: Drop VCHI_SERVICE_INIT and SERVICE_INFO_T Tuomas Tynkkynen
2018-10-04  9:37 ` [PATCH 6/7] staging: vc04_services: Drop unused parameters from vchi_connect() Tuomas Tynkkynen
2018-10-04  9:37 ` [PATCH 7/7] staging: vc04_services: Drop no longer needed headers Tuomas Tynkkynen
2018-10-06 10:18 ` [PATCH 0/7] staging: vc04_services: Some dead code removal Stefan Wahren
2018-10-15 16:14   ` Eric Anholt
2018-10-17  9:55     ` Dave Stevenson
2018-10-17 10:50       ` Stefan Wahren
2018-10-17 10:18   ` Dan Carpenter
2018-10-17 15:37     ` Eric Anholt
2018-10-17 16:51       ` Peter Robinson
2018-10-18  9:22         ` Dave Stevenson
2018-10-18  9:37           ` Stefan Wahren [this message]
2018-10-26 17:15             ` Dave Stevenson
2018-10-28  8:31               ` Stefan Wahren
2018-10-29 10:43                 ` Dave Stevenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f358db9f-1b7f-d0c6-ace5-64b908f08b63@i2se.com \
    --to=stefan.wahren@i2se.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dave.stevenson@raspberrypi.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=pbrobinson@gmail.com \
    --cc=tuomas.tynkkynen@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®