[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.1203191722390.11516@axis700.grange>
Date: Mon, 19 Mar 2012 17:32:20 +0100 (CET)
From: Guennadi Liakhovetski <g.liakhovetski@....de>
To: Vinod Koul <vinod.koul@...ux.intel.com>
cc: Russell King - ARM Linux <linux@....linux.org.uk>,
linux-kernel@...r.kernel.org,
'Jassi Brar' <jassisinghbrar@...il.com>,
Linus Walleij <linus.walleij@...aro.org>,
Magnus Damm <magnus.damm@...il.com>,
Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()
On Mon, 19 Mar 2012, Vinod Koul wrote:
> On Mon, 2012-03-19 at 15:45 +0100, Guennadi Liakhovetski wrote:
> > > Btw why should .device_alloc_chan_resources() need this, I so no reason,
> > > unless we are working around some other issue.
> >
> > The reason is the following: with the proposed modifications to the
> > existing API we want to achieve:
> >
> > 1. client requests a channel
> > dmaengine_request_slave_channel(dev)
> > 2. the core looks through platform-specific mapping tables and finds a
> > suitable channel
> > 3. the core calls device driver's .device_alloc_chan_resources() method
> > for that channel
> > 4. the client uses
> > dmaengine_slave_config(chan, config)
> > to configure the channel
> >
> > Now, that last channel configuration can have two aspects: (1) static:
> > routing, multiplexing, peripheral address. This needs to be set only once
> > per each such channel allocation to a specific client,
> correct
>
> > (2) (potentially)
> > dynamic: any burst sizes etc.
> I dont think burst-size would be dynamic, are they on sh- ?
Not atm, I just thought some other platforms / clients wanted to configure
it dynamically. I may be wrong, though.
> > We can pass both these configuration types
> > together to the DMA device driver at step 4. For that the slave would have
> > to embed struct dma_slave_config into another hardware-specific type with
> > additional routing parameters.
> I think most of generic parameters are already there. As long as you
> dont have abnormal controller current dma_slave_config should suffice.
> Again, if you have specific need pls let us know, this structure can &
> should be expanded if dmacs needs something for slave configuration.
Sure. In the datasheet we have: to configure a channel for client 1 write
value X to register A and value Y to register B. That's it. One of them is
really just a magic slave ID. Another one has several fields with values
like bus width and transfer size. They could be passed "properly," but
since those fields also vary between DMAC versions, it is easier to just
fix the whole register value per client and pass it from the platform
data. In any case, at least the slave ID is really just a constant, that
cannot be calculated and has to be passed from platform data.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/
Powered by blists - more mailing lists