Message-ID: <CAJe_ZhfWcUY2ctUFt0iUf2FOfjKj1Aa8hQH5LqFG+bZ+93CcNQ@mail.gmail.com>
Date:	Mon, 17 Oct 2011 20:46:54 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
Cc:	"Williams, Dan J" <dan.j.williams@...el.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Russell King <rmk@....linux.org.uk>,
	Barry Song <21cnbao@...il.com>, linux-kernel@...r.kernel.org,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>,
	Dave Jiang <dave.jiang@...el.com>
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

On 17 October 2011 19:37, Bounine, Alexandre <Alexandre.Bounine@....com> wrote:
> On Sat, Oct 15, 2011 at 7:26 AM, Jassi Brar <jaswinder.singh@...aro.org>
> wrote:
>>
>> On 15 October 2011 00:45, Bounine, Alexandre
>> <Alexandre.Bounine@....com> wrote:
>>
>> >> But doesn't the info, pointed to by this (void *), remain same for
>> >> every
>> >> transfer to a particular target/remote device ?
>> > No. An address within the target may (and most likely will) be
> changed for
>> > every transfer. Target destination ID will be the same for given
> virtual channel.
>> >
>> Thanks for the info.
>>
>> > Virtual channel may bring the same challenge and I may need a
> channel locking
>> > if more than one requester try to read/write data to the same target
> RIO device.
>> >
>> One can't avoid taking care of locking, but using virtual channels
>> keeps the dma_chan usage consistent.
>>
> Using virtual channels adds layers of complexity
Perhaps you didn't get me ... I suggest the dma controller driver
(not client drivers) create virtual channels corresponding to each
device it can talk to. A bunch of virtual channels could be served
by a single appropriate physical channel.
It is actually quite common, see amba-pl08x.c or pl330.c for example.

> which may be avoided with simple API changes:
> - virtual channel allocation: statically vs. dynamically
Yes, it would be cool but it's not possible right now.

> - linking virtual channel to the physical one
>
Perhaps you mean what I suggested ?

>
>> RapidIO supports 34(32+2), 50(48+2) and 66(64+2) bit addressing
>> which makes me wonder if the (upper or lower) 2 bits could be attached
>> to
>> the identity of the target device ?
>> (tsi721 driver actually discards the upper 2 bits while claiming to
>> support
>> 66bit addressing so I couldn't make anything out of it and specs don't
>> seem to say much about it)
>>
>> If there is no user of 66bit addressing and isn't coming in very near
>> future,
>> we might as well drop that case for now(tsi721 already does) because
>> that 'completeness' of support modifies the semantics of dmaengine
> apis
>> today for no real use.
> This is marked to be fixed in tsi721 driver. Also, this is a local
> deficiency
> and changing it that does not affect other components of the RIO
> subsystem.
> Contrary to that, defining an upper layer affects all future development
> and
> may result in greater pain if it needs to be adjusted later.
>
I just wanted to know

1) The role of the 'extra' 2bits ?

2) Are there real use-cases that are blocked on this support right now ?
    If there are indeed, do you think the transfer would be _randomly_
   distributed over the 66-bit address space ? Because otherwise, maybe
   the upper 2 bits could be used to "activate" one of the 4 "segments"
   using slave config call.

We should try our best to avoid opening the can of worms by adding
(void *) hook to each transfer, because any client driver could want to
pass its own private data to dmac and there would be no way for a dmac
driver to know what to cast the void pointer to.
Thanks.
--
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