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 Thu, Oct 01, 2020 at 05:03:16PM +0100, Mark Brown wrote:
> On Thu, Oct 01, 2020 at 05:32:07PM +0200, Greg KH wrote:
> > On Thu, Oct 01, 2020 at 03:40:19PM +0100, Mark Brown wrote:
> 
> > > Right, so my concern is that as soon as we decide we want to pass some
> > > resources or platform data through to one of the subdevices it needs to
> > > move over into being a platform device and vice versa.  That feels like
> > > something that's going to add to the mess for some of the uses.
> 
> > There shouldn't be a need for resources or platform data to be passed
> > that way as they are all "owned" by the parent device that creates
> > these.
> 
> > I don't want to see platform devices become children of real devices
> > (like PCI and USB and others), which is the goal here.  platform devices
> > are overloaded and abused enough as it is, let's not make it worse.
> 
> How does this interact with the situation where someone makes a PCI
> device that's basically a bunch of IPs glued together in a PCI memory
> region (or similarly for other buses)?  The IPs all have distinct
> memory regions and other resources like interrupt lines which makes them
> unsuitable for auxilliary devices as proposed, especially in cases where
> there's more than one copy of the IP instantiated.  There's a bunch of
> PCI MFDs in tree already of admittedly varying degrees of taste, and
> MFDs on other buses also use the resource passing stuff.

I would like to move those PCI MFDs away from that, and into this bus
instead.

If there needs to have a way to pass/share resources, great, let's add
it, there's no objection from me.

thanks,

greg k-h



[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