Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 02, 2020 at 05:23:53PM +0000, Ertman, David M wrote:
> > From: Mark Brown <broonie@xxxxxxxxxx>
> > Sent: Friday, October 2, 2020 4:20 AM
> > To: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > Cc: Ertman, David M <david.m.ertman@xxxxxxxxx>; Greg KH
> > <gregkh@xxxxxxxxxxxxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx;
> > tiwai@xxxxxxx; pierre-louis.bossart@xxxxxxxxxxxxxxx; Sridharan, Ranjani
> > <ranjani.sridharan@xxxxxxxxx>; parav@xxxxxxxxxx
> > Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client
> > support
> > 
> > On Thu, Oct 01, 2020 at 09:47:40PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Oct 01, 2020 at 09:17:18PM +0100, Mark Brown wrote:
> > 
> > > Instead of making ancillary bus giant, it might be interesting to use
> > > a library technique to avoid the code duplication you are talking
> > > about, eg
> > 
> > >  struct my_ancillary_data {
> > >       struct ancillary_device adev;
> > >       struct ancillary_resource resources;
> > >  }
> > 
> > > Then each user can access the facets they need.
> > 
> > The way most of this stuff works already it's not a table in the device
> > itself, it's an array of resources with type information.  Your second
> > struct there is presumably just going to be the pointer and size
> > information which you *could* split out but I'm really not sure what
> > you're buying there.
> > 
> > The interesting bit isn't really the data in the devices themselves,
> > it's the code that allows devices to just supply a data table and have
> > things mapped through to their child devices.  That isn't particularly
> > complex either, but it's still worth avoiding having lots of copies of
> > it.  *None* of this bus stuff is hugely complex but we still don't want
> > each device with children having to open code it all when they could
> > just do something data driven.
> 
> Would you recommend adding two elements to the ancillary_device like:
> 	void *ancillary_data;
> 	u32 ancildata_size;
> like the platform_device uses?

That doesn't seem useful here, the intent is to use container_of, if
the creator wants to pass private data then it should be structured
into the containing struct.

platform_devices/etc don't use container_of so have this side band way
to pass more data.

Jason



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux