All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Vinod Koul <vinod.koul@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dmaengine <dmaengine@vger.kernel.org>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Sekhar Nori <nsekhar@ti.com>,
	linux-spi <linux-spi@vger.kernel.org>
Subject: Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Date: Wed, 02 Dec 2015 14:38:39 +0100	[thread overview]
Message-ID: <15116008.0PghG2Imaa@wuerfel> (raw)
In-Reply-To: <565ECD3F.3070500@ti.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Cc: Andy Shevchenko
	<andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	dmaengine <dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux OMAP Mailing List
	<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-arm Mailing List
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>,
	linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Date: Wed, 02 Dec 2015 14:38:39 +0100	[thread overview]
Message-ID: <15116008.0PghG2Imaa@wuerfel> (raw)
In-Reply-To: <565ECD3F.3070500-l0cyMroinI0@public.gmane.org>

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-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Date: Wed, 02 Dec 2015 14:38:39 +0100	[thread overview]
Message-ID: <15116008.0PghG2Imaa@wuerfel> (raw)
In-Reply-To: <565ECD3F.3070500@ti.com>

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

  reply	other threads:[~2015-12-02 13:39 UTC|newest]

Thread overview: 147+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-30 13:45 [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask() Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 14:35   ` Andy Shevchenko
2015-11-30 14:35     ` Andy Shevchenko
2015-11-30 14:35     ` Andy Shevchenko
2015-12-01  9:47     ` Peter Ujfalusi
2015-12-01  9:47       ` Peter Ujfalusi
2015-12-01 12:58       ` Andy Shevchenko
2015-12-01 12:58         ` Andy Shevchenko
2015-12-01 17:06         ` Vinod Koul
2015-12-01 17:06           ` Vinod Koul
2015-11-30 13:45 ` [RFC v02 02/15] dmaengine: core: Move and merge the code paths using private_candidate Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 14:42   ` Andy Shevchenko
2015-11-30 14:42     ` Andy Shevchenko
2015-12-01  8:41     ` Peter Ujfalusi
2015-12-01  8:41       ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 14:09   ` Arnd Bergmann
2015-11-30 14:09     ` Arnd Bergmann
2015-11-30 14:09     ` Arnd Bergmann
2015-12-01  9:48     ` Peter Ujfalusi
2015-12-01  9:48       ` Peter Ujfalusi
2015-12-01  9:48       ` Peter Ujfalusi
2015-11-30 14:51   ` Andy Shevchenko
2015-11-30 14:51     ` Andy Shevchenko
2015-11-30 14:51     ` Andy Shevchenko
2015-12-01  9:56     ` Peter Ujfalusi
2015-12-01  9:56       ` Peter Ujfalusi
2015-12-01 10:07       ` Andy Shevchenko
2015-12-01 10:07         ` Andy Shevchenko
2015-11-30 15:51   ` Tony Lindgren
2015-11-30 15:51     ` Tony Lindgren
2015-11-30 15:51     ` Tony Lindgren
2015-12-01  8:13     ` Peter Ujfalusi
2015-12-01  8:13       ` Peter Ujfalusi
2015-12-01  8:13       ` Peter Ujfalusi
2015-12-01 17:00       ` Tony Lindgren
2015-12-01 17:00         ` Tony Lindgren
2015-12-02 10:00         ` Peter Ujfalusi
2015-12-02 10:00           ` Peter Ujfalusi
2015-12-02 10:00           ` Peter Ujfalusi
2015-12-02 10:00           ` Peter Ujfalusi
2015-12-02 15:00           ` Tony Lindgren
2015-12-02 15:00             ` Tony Lindgren
2015-12-02 15:00             ` Tony Lindgren
2015-11-30 13:45 ` [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 14:11   ` Arnd Bergmann
2015-11-30 14:11     ` Arnd Bergmann
2015-12-01  9:58     ` Peter Ujfalusi
2015-12-01  9:58       ` Peter Ujfalusi
2015-12-01  9:58       ` Peter Ujfalusi
2015-12-01 10:14       ` Arnd Bergmann
2015-12-01 10:14         ` Arnd Bergmann
2015-12-01 17:22   ` Vinod Koul
2015-12-01 17:22     ` Vinod Koul
2015-12-01 20:20     ` Arnd Bergmann
2015-12-01 20:20       ` Arnd Bergmann
2015-12-01 20:20       ` Arnd Bergmann
2015-12-02  4:37       ` Vinod Koul
2015-12-02  4:37         ` Vinod Koul
2015-12-02  4:37         ` Vinod Koul
2015-12-02 10:02         ` Peter Ujfalusi
2015-12-02 10:02           ` Peter Ujfalusi
2015-12-02 10:02           ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 05/15] ARM: davinci: devices-da8xx: Add dma_filter_map to edma Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 06/15] ARM: davinci: dm355: " Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 07/15] ARM: davinci: dm365: " Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 08/15] ARM: davinci: dm644x: " Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 09/15] ARM: davinci: dm646x: " Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 10/15] mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 11/15] spi: davinci: " Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2016-05-02 11:04   ` Applied "spi: davinci: Use dma_request_chan() for requesting DMA channel" to the spi tree Mark Brown
2016-05-02 11:04     ` Mark Brown
2015-11-30 13:45 ` [RFC v02 12/15] ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 13/15] ARM: davinci: devices: Remove DMA resources for MMC Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 14/15] ARM: davinci: dm355: Remove DMA resources for SPI Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 15/15] ARM: davinci: dm365: " Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 13:45   ` Peter Ujfalusi
2015-11-30 14:18 ` [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann
2015-11-30 14:18   ` Arnd Bergmann
2015-12-01 10:12   ` Peter Ujfalusi
2015-12-01 10:12     ` Peter Ujfalusi
2015-12-01 10:12     ` Peter Ujfalusi
2015-12-01 10:12     ` Peter Ujfalusi
2015-12-01 10:15     ` Arnd Bergmann
2015-12-01 10:15       ` Arnd Bergmann
2015-12-01 10:15       ` Arnd Bergmann
2015-11-30 14:32 ` Andy Shevchenko
2015-11-30 14:32   ` Andy Shevchenko
2015-12-01 13:45   ` Peter Ujfalusi
2015-12-01 13:45     ` Peter Ujfalusi
2015-12-01 14:24     ` Arnd Bergmann
2015-12-01 14:24       ` Arnd Bergmann
2015-12-02 10:51       ` Peter Ujfalusi
2015-12-02 10:51         ` Peter Ujfalusi
2015-12-02 13:38         ` Arnd Bergmann [this message]
2015-12-02 13:38           ` Arnd Bergmann
2015-12-02 13:38           ` Arnd Bergmann
2015-12-01 16:59 ` Vinod Koul
2015-12-01 16:59   ` Vinod Koul
2015-12-01 16:59   ` Vinod Koul
2015-12-01 20:17   ` Arnd Bergmann
2015-12-01 20:17     ` Arnd Bergmann
2015-12-01 20:17     ` Arnd Bergmann
2015-12-02  4:52     ` Vinod Koul
2015-12-02  4:52       ` Vinod Koul
2015-12-02  8:23       ` Arnd Bergmann
2015-12-02  8:23         ` Arnd Bergmann
2015-12-02 12:29     ` Peter Ujfalusi
2015-12-02 12:29       ` Peter Ujfalusi
2015-12-02 12:29       ` Peter Ujfalusi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15116008.0PghG2Imaa@wuerfel \
    --to=arnd@arndb.de \
    --cc=andy.shevchenko@gmail.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.