Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1278736

Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel

From Arnd Bergmann <arnd@arndb.de>
Newsgroups linux.kernel
Subject Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel
Date 2015-11-27 12:10 +0100
Message-ID <qzp4D-243-51@gated-at.bofh.it> (permalink)
References <qzmJs-pZ-3@gated-at.bofh.it> <qzmJs-pZ-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Friday 27 November 2015 10:29:39 Peter Ujfalusi wrote:
> struct dma_chan *dma_request_chan(struct device *dev, const char *name,
> 				  const dma_cap_mask_t *mask);
> To request a slave channel. The mask parameter is optional and it is used
> to check if the received channel's capabilities can satisfy the requested
> mask. The dma_request_chan() will try to find the channel via DT, ACPI or
> in case if the kernel booted in non DT/ACPI mode it will use a filter
> lookup table and retrieves the RESOURCE_DMA from the requester's device.
> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:

I think we should not introduce the mask parameter at all. In the rare
case that we actually need to pass a mask other than DMA_SLAVE today,
we should be able to encode that in the data we pass to the filter
function.

> RESOURCE_DMA needs to be added to the platform devices with names
> 
> For each dmaengine driver a string array listing the devices handled by the
> given DMA driver:
> 
> static char *da8xx_edma0_devices[] = {
> 	"davinci-mcasp.0",
> 	"da830-mmc.0",
> };
> 
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:

However, a lot of drivers definitely need to pass a data pointer for
each device. I see that you currently rely on the IORESOURCE_DMA
method that a couple of platforms use today, but I think it would
be backwards to do it that way for the platforms that require passing
more than an integer number today.

Having a pointer as the filter function argument is intentional and I'd
prefer to change the platforms that currently use IORESOURCE_DMA (davinci,
pxa, omap1, blackfin, alchemy) to stop doing it instead, and return
IORESOURCE_DMA to its original meaning that was limited to ISAPNP style
devices not using the dmaengine API.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-11-27 09:40 +0100
  Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel Arnd Bergmann <arnd@arndb.de> - 2015-11-27 12:10 +0100
    Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to  request a channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-11-27 12:20 +0100
      Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel Arnd Bergmann <arnd@arndb.de> - 2015-11-27 12:30 +0100

csiph-web