On Monday 28 July 2014 16:51:48 Andy Shevchenko wrote:
> Split from another topic with reduced Cc list.
>
> On Mon, 2014-07-28 at 14:47 +0200, Arnd Bergmann wrote:
> > > > We already have an interface for this, in the form of
> > > > dma_request_slave_channel(), which takes a string identifier that
> > > > is used to look up all that information in either device tree or
> > > > ACPI. It wouldn't be unreasonable to add a third path in there
> > > > to handle hardcoded platform devices, but that's a lot of work.
> > > > Note that you still need to encode a reference to the dma engine
> > > > in some way to do this right. The current code (with or without Mika's
> > > > patch) will break as soon as you have multiple DMA engine devices.
> > >
> > > What about to keep PCI case still valid? We can pass struct pci_dev (or
> > > actual struct device) of DMA controller to filter proper device.
> >
> > Yes, that would be best. IIRC you have a single PCI device that instantiates
> > both the SPI and the DMA engine as subdevices (I haven't looked at the
> > code again), so that information would be readily available.
>
> Now we have only two parameters to the function: struct device of the
> client and string to get an info. For PCI case we need to have struct
> device of DMA controller. This could cover actually a case where we have
> hardcoded platform data (such as one in AVR32).
>
> But this would look a bit awkward.
>
> Current infrastructure allows to extract this from struct pci_dev, but
> do we have a capability to distinguish PCI device from others using only
> struct device?
I think we were mixing two conversations above. In my second reply there,
I meant it would be easy to do by just passing dw_dma_slave (or something
like it) into a filter function and to keep using
dma_request_slave_channel_compat with this data.
If we actually want to make dma_request_slave_channel() with platform
provided data, we need to do something like the DT path: every
DMA controller driver that needs to work with this has to register
a function (like the .xlate function) with the core, e.g. as a callback
in struct dma_device, and then there has to be a generic way to
pass an array of something like
struct dma_slave_lookup {
struct device *dmadev;
const char *req;
void *data;
};
that associates the (dev,req) tuple with data that gets passed to the
dma controller specific callback from dma_request_slave_channel().
Arnd
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
