lkml.org 
[lkml]   [2011]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] serial: sh-sci: don't filter on DMA device, use only channel ID
On Mon, 2011-09-05 at 17:21 +0200, Guennadi Liakhovetski wrote:
> On Mon, 5 Sep 2011, Vinod Koul wrote:
>
> > On Mon, 2011-09-05 at 17:01 +0200, Guennadi Liakhovetski wrote:
> > > On Mon, 5 Sep 2011, Vinod Koul wrote:
> > >
> > > > On Mon, 2011-09-05 at 15:48 +0200, Guennadi Liakhovetski wrote:
> > > > >
> > > > > Let me try again. DMA channels on these DMA controllers are not dedicated.
> > > > > On one such SoC there can be several such DMA controllers of different
> > > > > kinds. One kind is "generic" - it can do memcpy(), besides channels can be
> > > > > freely configured for one of onboard peripherals: serial, mmc, etc. Some
> > > > > of them can also serve external DMA-capable devices. Another kind of DMA
> > > > > controllers, served by the same driver, can only be used with USB
> > > > > controllers. Now, if the MMC driver requests a DMA channel, let's say, the
> > > > > dmaengine core first finds the USB DMA controller. The MMC driver cannot
> > > > > know this. It assigns its MMC DMA configuration to the.private pointer and
> > > > > returns true. Next the DMA driver is entered, it checks the private
> > > > > pointer, sees an MMC channel request, looks at the DMA controller and
> > > > > sees, that it doesn't support MMC. So, .device_alloc_chan_resources()
> > > > > fails. When the same is attempted with a suitable DMA controller, the
> > > > > shdma driver recognises, that the controller can service MMC and uses the
> > > > > data, provided the MMC driver, to configure the DMA channel for MMC.
> > > > Hmmm, Can't you know in filter function if the respective channel can do
> > > > the dma for you or not? Maybe export a dma function or use platform data
> > > > for this (wont you soc have these caps fixed), i prefer latter.
> > > > That maybe a better approach.
> > >
> > > How? On a system you can have 3 suitable DMA controllers and 2 unsuitable.
> > > Do you want to pass a list of 3 suitable DMA controllers to each
> > > peripheral driver?...
> > The peripheral driver (client driver in slave-dma terminology) should
> > already know which dmac it wants. (base on information in platform data
> > etc) That is why the filter function is provided. Please use it properly
> > Other soc have similar capabilities and they can filter properly so why
> > cant you..?
>
> Sorry, I have been thinking about these possibilities, but I really didn't
> find any similar case in existing drivers. Normally either channels are
> fixed - only one channel can be used for a specific peripheral, or any at
> all, or there is only one suitable controller. I only see two
> possibilities here, and they both look ugly to me:
>
> (1) pass a list of suitable DMA controllers to slave-dma drivers, there in
> the filter you'd have to scan that list.
> (2) select only one out of several suitable DMA controllers in the
> platform configuration - that needlessly reduces flexibility.
>
> Whereas on the contrary, the DMA controller itself can perfectly look
> through the list of supported peripherals on the current controller and
> decide, whether the requested one is among them or not.
Then why not have shdma_filter_func() exported and then used by all your
clients for proper filtering.

I cant agree to the whole point of filtering in alloc

One channel is allocated, we should _not_ do any further filtering

>
> > PS: This might well be my last post before Tue EOD PST, traveling to
> > LPC, if you are there feel free to chat with me on this.
>
> No, unfortunately, I won#t be there. Are you coming to the KS in Prague in
> October?
Not decided yet...

\
 
 \ /
  Last update: 2011-09-07 20:45    [from the cache]
©2003-2011 Jasper Spaans