Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be impl
On Thursday 15 March 2012, Nicolas Ferre wrote:
> Add some basic helpers to retrieve a DMA controller device_node and the
> DMA request specifications. By making DMA controllers register a generic
> translation function, we allow the management of any type of DMA requests
> specification.
> The voi
On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
> On Thursday 15 March 2012, Nicolas Ferre wrote:
> > Add some basic helpers to retrieve a DMA controller device_node and the
> > DMA request specifications. By making DMA controllers register a generic
> > translation function, we allo
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
> > On Thursday 15 March 2012, Nicolas Ferre wrote:
> > > Add some basic helpers to retrieve a DMA controller device_node and the
> > > DMA request specifications. By making D
* Arnd Bergmann wrote:
> On Thursday 15 March 2012, Nicolas Ferre wrote:
[...]
> > + i2c1: i2c@1 {
> > + ...
> > + dma-request = <&sdma 2 &sdma 3>;
> > + dma-request-names = "tx", "rx";
> > + ...
> > + };
>
> This is slightly different from how the propo
On 3/15/2012 10:22 AM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type o
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
> This was done like IRQ on purpose, because an Interrupt ReQuest line and
> a DMA Request line are really similar for the HW point of view at IP
> level.
I'm not sure about that at all levels. Sure, at hardware level they're
the
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
> > This was done like IRQ on purpose, because an Interrupt ReQuest line and
> > a DMA Request line are really similar for the HW point of view at IP
> > level.
>
> I'm
On 3/15/2012 9:41 PM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
This was done like IRQ on purpose, because an Interrupt ReQuest line and
a DMA Request line are really similar for the HW point
On Thu, Mar 15, 2012 at 10:39:12PM +0100, Cousson, Benoit wrote:
> On 3/15/2012 9:41 PM, Arnd Bergmann wrote:
>> On Thursday 15 March 2012, Russell King - ARM Linux wrote:
>>> On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
This was done like IRQ on purpose, because an Interru
On Thu, 15 Mar 2012, Russell King - ARM Linux wrote:
> I really don't like these behind-the-scenes discussions which never then
> get followed up in public, and people then start quoting what was "agreed"
> as that's the way things must be done.
>
> It's a bit like folk at the recent Linaro Conne
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> Thank you both for missing my point.
>
> #define OMAP24XX_DMA_SHA1MD5_RX 13 /* S_DMA_12 */
> #define OMAP34XX_DMA_SHA2MD5_RX 13 /* S_DMA_12 */
>
> #define OMAP242X_DMA_EXT_DMAREQ214 /* S_DMA_13 */
On Thursday 15 March 2012, Nicolas Ferre wrote:
> For legacy reason another API will export the DMA request number into a
> Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
> +/**
> + * of_dma_to_resource - Decode a node's DMA and
On 3/16/2012 11:03 AM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
We do have a
On Friday 16 March 2012, Cousson, Benoit wrote:
> And it seems that other ARM SoCs are using it for the same purpose.
> There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either the
ISA dma api or a platform specific varian
On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
On Friday 16 March 2012, Cousson, Benoit wrote:
And it seems that other ARM SoCs are using it for the same purpose.
There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either the
On 03/16/2012 02:28 PM, Cousson, Benoit :
> On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
>> On Friday 16 March 2012, Cousson, Benoit wrote:
>>> And it seems that other ARM SoCs are using it for the same purpose.
>>> There are at least 230+ IORESOURCE_DMA instances in the kernel today.
>>
>> These ten
On Thu, 15 Mar 2012 11:27:36 +0100, Thierry Reding
wrote:
> * Arnd Bergmann wrote:
> > On Thursday 15 March 2012, Nicolas Ferre wrote:
> [...]
> > > + i2c1: i2c@1 {
> > > + ...
> > > + dma-request = <&sdma 2 &sdma 3>;
> > > + dma-request-names = "tx", "rx";
> > > +
On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
wrote:
> Add some basic helpers to retrieve a DMA controller device_node and the
> DMA request specifications. By making DMA controllers register a generic
> translation function, we allow the management of any type of DMA requests
> specification
On Thu, 15 Mar 2012 09:26:52 +, Russell King - ARM Linux
wrote:
> On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
> > On Thursday 15 March 2012, Nicolas Ferre wrote:
> > > Add some basic helpers to retrieve a DMA controller device_node and the
> > > DMA request specifications.
On Saturday 17 March 2012, Grant Likely wrote:
> On Thu, 15 Mar 2012 09:26:52 +, Russell King - ARM Linux
> wrote:
> > On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
> > > On Thursday 15 March 2012, Nicolas Ferre wrote:
> > > > Add some basic helpers to retrieve a DMA controll
On Sat, 17 Mar 2012 16:03:02 +, Arnd Bergmann wrote:
> On Saturday 17 March 2012, Grant Likely wrote:
> > On Thu, 15 Mar 2012 09:26:52 +, Russell King - ARM Linux
> > wrote:
> > > On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
> > > > On Thursday 15 March 2012, Nicolas Fe
* Grant Likely wrote:
> On Thu, 15 Mar 2012 11:27:36 +0100, Thierry Reding
> wrote:
> > So if we decide to explicitly allow specifying names, then we can always add
> > a pwm-names property (or -pwm-names respectively) to use as label and
> > fallback to the user OF device node name if that prope
On Sunday 18 March 2012, Thierry Reding wrote:
> Not enough information to check signature validity. Show Details
> * Grant Likely wrote:
> > On Thu, 15 Mar 2012 11:27:36 +0100, Thierry Reding
> > wrote:
> > > So if we decide to explicitly allow specifying names, then we can always
> > > add
On Sun, 18 Mar 2012 10:22:41 +0100, Thierry Reding
wrote:
> * Grant Likely wrote:
> > On Thu, 15 Mar 2012 11:27:36 +0100, Thierry Reding
> > wrote:
> > > So if we decide to explicitly allow specifying names, then we can always
> > > add
> > > a pwm-names property (or -pwm-names respectively) t
On Saturday 17 March 2012, Grant Likely wrote:
> > +static LIST_HEAD(of_dma_list);
> > +
> > +struct of_dma {
> > + struct list_head of_dma_controllers;
> > + struct device_node *of_node;
> > + int of_dma_n_cells;
> > + int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *dat
On Sun, 18 Mar 2012 20:13:22 +, Arnd Bergmann wrote:
> On Saturday 17 March 2012, Grant Likely wrote:
> > > +static LIST_HEAD(of_dma_list);
> > > +
> > > +struct of_dma {
> > > + struct list_head of_dma_controllers;
> > > + struct device_node *of_node;
> > > + int of_dma_n_cells;
>
On Sunday 18 March 2012, Grant Likely wrote:
> > struct dma_channel *of_dma_request_channel(struct of_node*, int index,
> > dma_cap_mask_t *mask,
> > void *driver_data)
> > {
> > struct of_phandle_args dma_spec;
> >
On Sunday 18 March 2012, Arnd Bergmann wrote:
> >
> > Is dma_find_device() a new function? How does it look up the dma
> > device?
>
> Yes, it would be similar to the proposed function in Benoit's patch
>
Well, actually we would not even need a new list with all the devices,
it can simply beco
On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
> After implementing both schemes (ie. interrupts+interrupt-names && [*-]gpios)
> I definitely prefer the fixed property name plus a separate names property.
> It is easier to use common code with that scheme, and easier to statically
>
On 03/17/2012 10:40 AM, Grant Likely :
> On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
> wrote:
>> Add some basic helpers to retrieve a DMA controller device_node and the
>> DMA request specifications. By making DMA controllers register a generic
>> translation function, we allow the manageme
On 03/18/2012 09:13 PM, Arnd Bergmann :
> On Saturday 17 March 2012, Grant Likely wrote:
>>> +static LIST_HEAD(of_dma_list);
>>> +
>>> +struct of_dma {
>>> + struct list_head of_dma_controllers;
>>> + struct device_node *of_node;
>>> + int of_dma_n_cells;
>>> + int (*of_dma_xlate)(s
On Monday 19 March 2012, Nicolas Ferre wrote:
> > This _xlate is nearly useless as a generic API. It solves the problem for
> > the specific case where the driver is hard-coded to know which DMA engine
> > to talk to, but since the returned data doesn't provide any context, it
> > isn't useful if
On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre
wrote:
> On 03/17/2012 10:40 AM, Grant Likely :
> > On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
> > wrote:
> >> +struct of_dma {
> >> + struct list_head of_dma_controllers;
> >> + struct device_node *of_node;
> >> + int of_dma_n_cells;
On Monday 19 March 2012, Mark Brown wrote:
> On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
>
> > After implementing both schemes (ie. interrupts+interrupt-names &&
> > [*-]gpios)
> > I definitely prefer the fixed property name plus a separate names property.
> > It is easier to us
On 03/19/2012 09:01 AM, Arnd Bergmann wrote:
> On Monday 19 March 2012, Mark Brown wrote:
>> On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
>>
>>> After implementing both schemes (ie. interrupts+interrupt-names &&
>>> [*-]gpios)
>>> I definitely prefer the fixed property name plus a
On Mon, Mar 19, 2012 at 02:37:56PM +0100, Nicolas Ferre wrote:
> On 03/18/2012 09:13 PM, Arnd Bergmann :
> > On Saturday 17 March 2012, Grant Likely wrote:
> >>> +static LIST_HEAD(of_dma_list);
> >>> +
> >>> +struct of_dma {
> >>> + struct list_head of_dma_controllers;
> >>> + struct device
On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
> mmci
> /* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
> bool stedma40_filter(struct dma_chan *chan, void *data)
> {
> struct stedma40_chan_cfg *info = data;
> struct d40_
On Monday 19 March 2012, Stephen Warren wrote:
> > Maybe one can use named properties in a new device node in that case,
> > like this:
> >
> > bus {
> > dma: dma-controller {
> > #dma-cells = <1>;
> > };
> >
> > device {
> >
On 3/19/2012 4:20 PM, Russell King - ARM Linux wrote:
On Mon, Mar 19, 2012 at 02:37:56PM +0100, Nicolas Ferre wrote:
On 03/18/2012 09:13 PM, Arnd Bergmann :
On Saturday 17 March 2012, Grant Likely wrote:
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+ struct list_head of_dma_controlle
On Monday 19 March 2012, Russell King - ARM Linux wrote:
> Firstly, define what you mean by "the DMA parameters". Things like burst
> size, register width, register address? That should all be known by the
> peripheral driver and not be encoded into DT in any way - and this
> information should b
On 03/19/2012 04:33 PM, Russell King - ARM Linux :
> On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
>> mmci
>> /* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
>> bool stedma40_filter(struct dma_chan *chan, void *data)
>> {
>> st
On 03/19/2012 09:45 AM, Arnd Bergmann wrote:
> On Monday 19 March 2012, Stephen Warren wrote:
>>> Maybe one can use named properties in a new device node in that case,
>>> like this:
>>>
>>> bus {
>>> dma: dma-controller {
>>> #dma-cells = <1>;
>>>
Hi Nico,
On 3/19/2012 5:31 PM, Nicolas Ferre wrote:
On 03/19/2012 04:33 PM, Russell King - ARM Linux :
On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
mmci
/* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
bool stedma40_filter(struct dma_chan *chan,
On Mon, Mar 19, 2012 at 9:41 PM, Arnd Bergmann wrote:
>
>> Secondly, there are platforms (Samsung) where peripherals are connected
>> to more than one DMA controller, and either DMA controller can be used -
>> I'm told by Jassi that there's reasons why you'd want to select one or
>> other as the t
On Thu, Mar 15, 2012 at 10:39:12PM +0100, Cousson, Benoit wrote:
> On 3/15/2012 9:41 PM, Arnd Bergmann wrote:
> >The numbers definitely need to become local to each of the controllers, but
> >that is the case pretty much automatically using the proposed binding,
> >because each dma request identifi
On 03/19/2012 03:45 PM, Grant Likely :
> On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre
> wrote:
>> On 03/17/2012 10:40 AM, Grant Likely :
>>> On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
>>> wrote:
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device
47 matches
Mail list logo
