All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Gross <agross-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>,
	Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Dan Williams
	<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Date: Tue, 28 Jan 2014 13:50:35 -0600	[thread overview]
Message-ID: <20140128195035.GB18930@qualcomm.com> (raw)
In-Reply-To: <4697306.PPWWh8UGTE@wuerfel>

On Tue, Jan 28, 2014 at 10:16:53AM +0100, Arnd Bergmann wrote:
> On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
> > > +
> > > +Clients must use the format described in the dma.txt file, using a three cell
> > > +specifier for each channel.
> > > +
> > > +The three cells in order are:
> > > +  1. A phandle pointing to the DMA controller
> > > +  2. The channel number
> > > +  3. Direction of the fixed unidirectional channel
> > > +     0 - Memory to Device
> > > +     1 - Device to Memory
> > > +     2 - Device to Device
> > > +
> > 
> > Why does the direction needs to be specified in specifier? I see two
> > options, either the direction per is fixed in hardware. In that case the DMA
> > controller node should describe which channel is which direction. Or the
> > direction is not fixed in hardware and can be changed at runtime in which
> > case it should be set on a per descriptor basis.
> 
> Normally the direction is implied by dmaengine_slave_config().
> Note that neither the dma slave API nor the generic DT binding
> can actually support device-to-device transfers, since this
> normally implies using two dma-request lines rather than one.
> 
> There might be a case where the direction is required in order
> to allocate a channel, because the engine has specialized channels
> per direction, and might connect any of them to any dma request
> line. This does not seem to be the case for "bam", because
> the DMA specifier already contains a specific channel number, not
> a request line or slave ID number.
> 

In the case of BAM, the channels are hardcoded based on the attached peripheral.
For instance, if the BAM is attached to the BLSP UART, channel 0 is uart0-RX,
channel 1 is uart0-TX, channel 2 is uart1-RX... etc, etc.  So not only is the
direction hardcoded, but also the function.

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: agross@codeaurora.org (Andy Gross)
To: linux-arm-kernel@lists.infradead.org
Subject: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Date: Tue, 28 Jan 2014 13:50:35 -0600	[thread overview]
Message-ID: <20140128195035.GB18930@qualcomm.com> (raw)
In-Reply-To: <4697306.PPWWh8UGTE@wuerfel>

On Tue, Jan 28, 2014 at 10:16:53AM +0100, Arnd Bergmann wrote:
> On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
> > > +
> > > +Clients must use the format described in the dma.txt file, using a three cell
> > > +specifier for each channel.
> > > +
> > > +The three cells in order are:
> > > +  1. A phandle pointing to the DMA controller
> > > +  2. The channel number
> > > +  3. Direction of the fixed unidirectional channel
> > > +     0 - Memory to Device
> > > +     1 - Device to Memory
> > > +     2 - Device to Device
> > > +
> > 
> > Why does the direction needs to be specified in specifier? I see two
> > options, either the direction per is fixed in hardware. In that case the DMA
> > controller node should describe which channel is which direction. Or the
> > direction is not fixed in hardware and can be changed at runtime in which
> > case it should be set on a per descriptor basis.
> 
> Normally the direction is implied by dmaengine_slave_config().
> Note that neither the dma slave API nor the generic DT binding
> can actually support device-to-device transfers, since this
> normally implies using two dma-request lines rather than one.
> 
> There might be a case where the direction is required in order
> to allocate a channel, because the engine has specialized channels
> per direction, and might connect any of them to any dma request
> line. This does not seem to be the case for "bam", because
> the DMA specifier already contains a specific channel number, not
> a request line or slave ID number.
> 

In the case of BAM, the channels are hardcoded based on the attached peripheral.
For instance, if the BAM is attached to the BLSP UART, channel 0 is uart0-RX,
channel 1 is uart0-TX, channel 2 is uart1-RX... etc, etc.  So not only is the
direction hardcoded, but also the function.

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: Andy Gross <agross@codeaurora.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Vinod Koul <vinod.koul@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Date: Tue, 28 Jan 2014 13:50:35 -0600	[thread overview]
Message-ID: <20140128195035.GB18930@qualcomm.com> (raw)
In-Reply-To: <4697306.PPWWh8UGTE@wuerfel>

On Tue, Jan 28, 2014 at 10:16:53AM +0100, Arnd Bergmann wrote:
> On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
> > > +
> > > +Clients must use the format described in the dma.txt file, using a three cell
> > > +specifier for each channel.
> > > +
> > > +The three cells in order are:
> > > +  1. A phandle pointing to the DMA controller
> > > +  2. The channel number
> > > +  3. Direction of the fixed unidirectional channel
> > > +     0 - Memory to Device
> > > +     1 - Device to Memory
> > > +     2 - Device to Device
> > > +
> > 
> > Why does the direction needs to be specified in specifier? I see two
> > options, either the direction per is fixed in hardware. In that case the DMA
> > controller node should describe which channel is which direction. Or the
> > direction is not fixed in hardware and can be changed at runtime in which
> > case it should be set on a per descriptor basis.
> 
> Normally the direction is implied by dmaengine_slave_config().
> Note that neither the dma slave API nor the generic DT binding
> can actually support device-to-device transfers, since this
> normally implies using two dma-request lines rather than one.
> 
> There might be a case where the direction is required in order
> to allocate a channel, because the engine has specialized channels
> per direction, and might connect any of them to any dma request
> line. This does not seem to be the case for "bam", because
> the DMA specifier already contains a specific channel number, not
> a request line or slave ID number.
> 

In the case of BAM, the channels are hardcoded based on the attached peripheral.
For instance, if the BAM is attached to the BLSP UART, channel 0 is uart0-RX,
channel 1 is uart0-TX, channel 2 is uart1-RX... etc, etc.  So not only is the
direction hardcoded, but also the function.

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

  parent reply	other threads:[~2014-01-28 19:50 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-28  6:27 [Patch v3 0/2] Add Qualcomm BAM dmaengine driver Andy Gross
2014-01-28  6:27 ` Andy Gross
2014-01-28  6:27 ` [Patch v3 1/2] dmaengine: add Qualcomm BAM dma driver Andy Gross
2014-01-28  6:27   ` Andy Gross
2014-01-28  6:27 ` [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding Andy Gross
2014-01-28  6:27   ` Andy Gross
2014-01-28  9:05   ` Lars-Peter Clausen
2014-01-28  9:05     ` Lars-Peter Clausen
2014-01-28  9:16     ` Arnd Bergmann
2014-01-28  9:16       ` Arnd Bergmann
2014-01-28 11:17       ` Russell King - ARM Linux
2014-01-28 11:17         ` Russell King - ARM Linux
2014-01-28 11:32         ` Vinod Koul
2014-01-28 11:32           ` Vinod Koul
2014-01-28 12:05           ` Arnd Bergmann
2014-01-28 12:05             ` Arnd Bergmann
2014-01-28 12:05             ` Arnd Bergmann
2014-01-28 12:08             ` Arnd Bergmann
2014-01-28 12:08               ` Arnd Bergmann
2014-01-28 12:08               ` Arnd Bergmann
2014-01-28 12:16               ` Russell King - ARM Linux
2014-01-28 12:16                 ` Russell King - ARM Linux
2014-01-29 15:05                 ` Arnd Bergmann
2014-01-29 15:05                   ` Arnd Bergmann
2014-01-28 13:01             ` Russell King - ARM Linux
2014-01-28 13:01               ` Russell King - ARM Linux
2014-01-28 19:50       ` Andy Gross [this message]
2014-01-28 19:50         ` Andy Gross
2014-01-28 19:50         ` Andy Gross
2014-01-30  6:23       ` Andy Gross
2014-01-30  6:23         ` Andy Gross
2014-01-28 19:47     ` Andy Gross
2014-01-28 19:47       ` Andy Gross

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=20140128195035.GB18930@qualcomm.com \
    --to=agross-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /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.