[PATCH V2 0/3] Add vchi_queue_kernel_message and vchi_queue_user_message

[Michael Zoran]

On Wed, 2017-01-25 at 18:39 +0100, Stefan Wahren wrote:
> > Michael Zoran <mzoran at crowfest.net> hat am 25. Januar 2017 um 17:53
> > geschrieben:
> > 
> > 
> > On Wed, 2017-01-25 at 06:23 -0800, Michael Zoran wrote:
> > > On Wed, 2017-01-25 at 17:12 +0300, Dan Carpenter wrote:
> > > > > Again, that's not my decision.  I can go either way.  But if
> > > > > the
> > > > > decision was made to delete it, I think the 4.10 version
> > > > > should
> > > > > also be
> > > > > deleted because the same logic applies.  Nothing uses it 4.10
> > > > > either
> > > > > and 4.10 is still an RC.
> > > > 
> > > > Nah.  No rush.  We can delete it in another kernel release or
> > > > two
> > > > if
> > > > we
> > > > can't figure out the issue.
> > > > 
> > > > Let's first figure out why the other code hasn't been
> > > > upstreamed. 
> > > > You
> > > > must have at least looked at it to be sending these
> > > > patches.  Do
> > > > you
> > > > know what the story is?
> > > 
> > > No, not really.  Some of it may simply be that nobody has taken
> > > the
> > > time to upstream them.
> > > 
> > > Some of it my be the nature of the RPI which is fundamentially(at
> > > least
> > > the history of it), a toy.  Either for children or people that
> > > want
> > > to
> > > tinker with things.  So some of the downstream code doesn't
> > > always
> > > follow all the rules that upstream drivers would.  Because like I
> > > said
> > > at least historically, it's a toy.
> > > 
> > > I have submitted some small changes to the drivers that hook into
> > > vc04_services mostly for HDMI audio.   But it's only small
> > > changes...
> > > 
> > > Like I said, my goal here was simply to get ARM64 to work on the
> > > RPI3
> > > and HDMI audio was important to me.   And vc04_services was
> > > necessary
> > 
> > So Greg/Dan/Eric:
> > 
> > Have we come to any conclusion on how things are going to proceed
> > with
> > this driver?
> 
> Looking at the TODO shows 3 candidates: vc_mem, bcm2835-camera, VCSM
> 
> I suggest to pick one first, because the kernel developer for bcm2835
> are limited. So my favorite would be bcm2835-camera, since it's the
> only driver with a practical application for a non-developer.
> 
> @Michael: Does this make sense to you?

This isn't my decision.  

But I'm a personal fan of bcm2835-audio.  I know it isn't on the TODO
list, but it was the reason I started down this path in the first
place.

Eric is working on a replacement for it, but I'm not sure when he will
have it available.