linux-kernel - Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <565DA47C.4000308@ti.com>
Date:	Tue, 1 Dec 2015 15:45:32 +0200
From:	Peter Ujfalusi <peter.ujfalusi@...com>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
CC:	Vinod Koul <vinod.koul@...el.com>, Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dmaengine <dmaengine@...r.kernel.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Sekhar Nori <nsekhar@...com>,
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting
 channel

On 11/30/2015 04:32 PM, Andy Shevchenko wrote:
>> Andy: I did looked at the unified device properties, but I decided to not to use
>> it as I don't see it to fit well and most of the legacy board files are using
>> resources to specify at least their memory regions so adding the DMA resource
>> to them would be more inline with the rest of the code.
> 
> We could return back to this in the future, still we have to amend
> built-in device properties (there is a patch series already in the
> wild).

I believe we could have similar dmaengine 'infra' for the built-in device
properties as we have now for DT and ACPI. I need to dig deeper to get full
understanding on the device properties, but from a quick view it looks to me
that it could replace the direct OF and ACPI property handing in a unified
API. I might be totally mistaken here ;)

>> static struct dma_filter_map da830_edma_map[] = {
>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> 
> Does this ".2" and so prevent driver to use auto ID for platform devices?

Yes, as all the infra around the traditional board files with platform_device
creation does. Ideally we could have 'phandle' pointing from this table to the
device in question (or other way around), but I'm not aware of anything we can
use.
Auto ID did not really worked for us since the driver does need to know their
ID in some cases, or we need to be able to be sure that for example McASP1 is
handled as davinci-mcasp.1
We have clocks and other dependencies where the device name or device ID need
to be predictable.
It is different in DT cases, but we are talking about legacy things.

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