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

Groups > linux.kernel > #1280878 > unrolled thread

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

Started byPeter Ujfalusi <peter.ujfalusi@ti.com>
First post2015-12-01 14:50 +0100
Last post2015-12-02 14:40 +0100
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-12-01 14:50 +0100
    Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-12-01 15:30 +0100
      Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-12-02 12:00 +0100
        Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-12-02 14:40 +0100

#1280878 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-12-01 14:50 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qATtD-1Sb-13@gated-at.bofh.it>
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1280904 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-01 15:30 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qAU6m-2l1-21@gated-at.bofh.it>
In reply to#1280878
On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
> >> 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.

I was thinking that we could use a pointer to the device structure, but
if you have that, you can also just read the name from it.

	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/

[toc] | [prev] | [next] | [standalone]

#1281624

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-12-02 12:00 +0100
Message-ID<qBdiG-64Q-7@gated-at.bofh.it>
In reply to#1280904
On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
>>>> 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.
> 
> I was thinking that we could use a pointer to the device structure, but
> if you have that, you can also just read the name from it.

Hrm to have pdev pointer instead of the devname string? In the core we could
get the pdev from the caller's device with to_platform_device(dev) and simply
compare the pointers...

One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs
are scattered around in the c files so gathering the pointers to a place where
we can see them to be able to use it in the dma_filter_map is not going to be
light weight task.
Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs
and resources from the omap_hwmod data structures so getting out the DMA event
numbers there is not going to be easy either...

I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay
with the devname strings here.

-- 
Péter
--
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/

[toc] | [prev] | [next] | [standalone]

#1281783 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-02 14:40 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qBfNv-7MJ-7@gated-at.bofh.it>
In reply to#1281624
On Wednesday 02 December 2015 12:51:43 Peter Ujfalusi wrote:
> On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
> >>>> 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.
> > 
> > I was thinking that we could use a pointer to the device structure, but
> > if you have that, you can also just read the name from it.
> 
> Hrm to have pdev pointer instead of the devname string? In the core we could
> get the pdev from the caller's device with to_platform_device(dev) and simply
> compare the pointers...
> 
> One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs
> are scattered around in the c files so gathering the pointers to a place where
> we can see them to be able to use it in the dma_filter_map is not going to be
> light weight task.
> Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs
> and resources from the omap_hwmod data structures so getting out the DMA event
> numbers there is not going to be easy either...
> 
> I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay
> with the devname strings here.

Sorry, what I meant to say above is that I had already concluded that using
device pointers was a bad idea and we should stay with names.

	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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web