Message-ID: <0CE8B6BE3C4AD74AB97D9D29BD24E55202321F65@CORPEXCH1.na.ads.idt.com>
Date:	Mon, 17 Oct 2011 11:00:06 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
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 Mon, Oct 17, 2011 at 11:17 AM, Jassi Brar
<jaswinder.singh@...aro.org> wrote:
> 
> 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.
> 
This is a source of the problem for RIO - DMA controller driver creates
virtual channels statically. RapidIO may use 8- or 16-bit destID.
In this case we need to create 256 or 64K virtual channels if we
want to cover all possible targets on single RIO port. Adding an extra
controller/net multiplies that number. Considering that not every
device will need a data transfer from a given node static allocation
will
create even more wasted resources. 

> > 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.
> 
This is a reason for calling it "added complexity" we will need
to find some mechanism to do it dynamically at DMA or RIO layer.

> > - linking virtual channel to the physical one
> >
> Perhaps you mean what I suggested ?
> 
I mean linking dynamically allocated virtual channel to the physical
one.
Sorry for confusing statement. Ideally, in the virtual channel scenario
rio_request_dma() should dynamically allocate target-mapped virtual DMA
channel and link it to the appropriate physical DMA channel.  

> >
> >> 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 ?
> 
Just upper bits of the RIO address.

> 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.
> 
There is nothing that absence of full 66-bit addressing blocks now.
So far we are not aware about implementations that use 66-bit address.
This does not prevent someone from designing RIO compliant endpoint
device
which gives interpretation to these two bits in addition to full 64-bit
addressing of their platform.

At this moment we may say that it is reasonable to lower an importance
of 66-bit
addressing but we should keep it in mind when considering all pros and
cons
of possible API changes. I discussed this with some members of RTA and
did not
hear any strong argument in favor of full 66-bit addressing support in
SW
at this moment.

> 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.

Do we really expect that clients will jump to use an extra parameter
without a valid reason and without knowing their hardware specifics?

Alex.

--
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