On Tue, Sep 18, 2012 at 10:52 PM, Russell King - ARM Linux
wrote:
> There's a clue in that paragraph about how the DMA engine TX descriptors
> _should_ be handled. "hold a reference" is the clue. Or another way to
> say it, a kref should be embedded in the structure, providing us with
> proper
On Tue, Sep 18, 2012 at 02:20:53PM +0200, Linus Walleij wrote:
> But we're probably the odd exception here so nevermind.
> One day we may test to rip out the logical channel handling and
> use Russell's virtual channel lib to run the show as an experiment.
Note that I'm beginning to add support fo
On Tue, Sep 18, 2012 at 5:18 AM, Vinod Koul wrote:
> On Mon, 2012-09-17 at 22:57 +0100, Russell King - ARM Linux wrote:
>>
>> Except that we expose one 'channel' per mux setting, so as far as DMA
>> engine goes, the mux number _is_ the channel number - which is the same
>> approach taken by the PL
On Mon, 2012-09-17 at 22:57 +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 17, 2012 at 03:20:29PM +0530, Vinod Koul wrote:
> > On Mon, 2012-09-17 at 09:36 +0100, Russell King - ARM Linux wrote:
> > > > > I'm not saying take the slave_id out of the map. I'm saying, let the
> > > > > DMA engin
On Mon, Sep 17, 2012 at 03:20:29PM +0530, Vinod Koul wrote:
> On Mon, 2012-09-17 at 09:36 +0100, Russell King - ARM Linux wrote:
> > > > I'm not saying take the slave_id out of the map. I'm saying, let the
> > > > DMA engine driver itself figure out what dma_chan to return.
> > > But wont that as
On Mon, 2012-09-17 at 09:36 +0100, Russell King - ARM Linux wrote:
> > > I'm not saying take the slave_id out of the map. I'm saying, let the
> > > DMA engine driver itself figure out what dma_chan to return.
> > But wont that assume the dma controller knows which channel to allocate.
> > And how
On Mon, Sep 17, 2012 at 09:10:23AM +0530, Vinod Koul wrote:
> On Fri, 2012-09-14 at 12:18 +0100, Russell King - ARM Linux wrote:
> > I'm not saying take the slave_id out of the map. I'm saying, let the
> > DMA engine driver itself figure out what dma_chan to return.
> But wont that assume the dma
On Fri, 2012-09-14 at 12:18 +0100, Russell King - ARM Linux wrote:
> I'm not saying take the slave_id out of the map. I'm saying, let the
> DMA engine driver itself figure out what dma_chan to return.
But wont that assume the dma controller knows which channel to allocate.
And how would it know t
On Fri, Sep 14, 2012 at 04:21:08PM +0530, Vinod Koul wrote:
> On Fri, 2012-09-14 at 10:41 +0100, Russell King - ARM Linux wrote:
> > On Fri, Sep 14, 2012 at 03:03:09PM +0530, Vinod Koul wrote:
> > > + /* now we hit an entry in map,
> > > + * see if we can get a channel in controlle
On Fri, 2012-09-14 at 10:41 +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 14, 2012 at 03:03:09PM +0530, Vinod Koul wrote:
> > +/*called under lock held */
> > +static struct dma_chan *dmaengine_get_slave_channel(char *requestor,
> > dma_cap_mask_t *mask)
> > +{
> > +
> > + struct dma_devi
On Fri, Sep 14, 2012 at 03:03:09PM +0530, Vinod Koul wrote:
> +/*called under lock held */
> +static struct dma_chan *dmaengine_get_slave_channel(char *requestor,
> dma_cap_mask_t *mask)
> +{
> +
> + struct dma_device *device, *_d;
> + struct dma_chan *chan = NULL;
> + int err;
> +
> +
when allocating a channel the dmaengine finds first channel that matches the
mask and calls filter function
In slave dmaengine model, there already exists a mapping, either hardwired in
SoC or thru a configurable mux. So we typically need channel from controller X
and in same cases a partcular chan
12 matches
Mail list logo
