All of lore.kernel.org
 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 [PATCH 0/7] staging: vc04_services: Some dead code removal 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.