[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110727203710.GB5028@flint.arm.linux.org.uk>
Date: Wed, 27 Jul 2011 21:37:11 +0100
From: Russell King <rmk@....linux.org.uk>
To: Jaswinder Singh <jaswinder.singh@...aro.org>
Cc: "Koul, Vinod" <vinod.koul@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
Linus Walleij <linus.walleij@...aro.org>,
linux-kernel@...r.kernel.org, linus.walleij@...ricsson.com,
per.friden@...ricsson.com, wei.zhang@...escale.com,
ebony.zhu@...escale.com, iws@...o.caltech.edu,
s.hauer@...gutronix.de, maciej.sosnowski@...el.com,
saeed@...vell.com, shawn.guo@...escale.com, yur@...raft.com,
agust@...x.de, iwamatsu.nobuhiro@...esas.com,
per.forlin@...ricsson.com, jonas.aberg@...ricsson.com,
anemo@....ocn.ne.jp
Subject: Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id
On Wed, Jul 27, 2011 at 08:00:23PM +0530, Jaswinder Singh wrote:
> On 27 July 2011 14:32, Koul, Vinod <vinod.koul@...el.com> wrote:
> > You can have two different DMACs in same system. At least I have two
> > from current intel_mid_dma which are used. Both give their channel id
> > starting from 0, 1....
> > Further as we integrate video, audio, spi, emmc dmacs possibility of
> > having multiple dmacs will increase in a system
>
> Most of Samsung's S5P series have 3 DMACs - 2 for peripherals and 1 for
> mem->mem But that is not the point.
>
> This patch in no way affects what values currently a dmac driver
> assigns to chan_id
Then *explain* how the chan_id is used to match the channel which the
peripheral requires when you have three DMA controllers, each with
channels numbered 0 to 7.
> > Sorry I didn't get you.
> > As I understand you are trying to simplify the filter function by
> > assigning unique ids to all channels,
>
> No dear. Let me put it precisely.
>
> Even if we make no further change to the dmaengine, this patch is the right
> thing to do today.
You sound like a politician. "the right thing to do" is a cop-out. That
says "believe me, I know I'm right, but I can't say why I'm right, I just
am." Basically, it means that the person saying it has no clue on the
subject they're talking about.
If you do have a clue, then don't say that infuriating phrase, but give an
actual reason.
> On a serious note, my proposal, and the reply, shows the possibility
> of having :-
> a) Client drivers that are truly platform agnostic -- no platform_data
> poking for
> channel selection
I really doubt that's even possible. Take this setup:
MMCI ---> DMAC
where the DMAC has 32 request signals, and 8 channels. The MMCI is
connected to two of them. The DMAC can supply any of its physical
channels for MMCI.
Board 1 has the MMCI connected to request signals #1 and #3. Board 2
has the MMCI connected to request signals #8 and #22. Board 3 has
the MMCI connected through an external FPGA mux, which can route the
MMCI requests to DMA request signals #1, #2 or #3.
Now, explain how a channel is selected for each of those two boards, and
the DMA controller is provided with the relevant request signal is found
without platform data involved, using _only_ your 'capabilities' bitfield
and the channel ID number.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
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