Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()

[Guennadi Liakhovetski]

On Mon, 19 Mar 2012, Vinod Koul wrote:

> On Fri, 2012-03-16 at 10:36 +0100, Guennadi Liakhovetski wrote:
> > On Mon, 12 Mar 2012, Vinod Koul wrote:
> > 
> > > On Fri, 2012-03-09 at 13:20 +0100, Guennadi Liakhovetski wrote:
> > > > It can be made to work as long as there's only one DMAC group with 
> > > > configurable channels and all other DMACs are dedicated to specific 
> > > > peripherals, yes. I don't know whether there are already now or are 
> > > > approaching any platforms with multiple reconfigurable groups. 
> > > And that is what I am talking about.
> > > 
> > > Having specific channel mapping given by platform for all channels which
> > > are to be used dedicated. And a pool of channels which can be used by
> > > anyone (if they can be) on a platform.
> > > 
> > > Does this proposal sound good for others as well. I think we can target
> > > this for next merge cycle, we are too late for the current one.
> > 
> > Ok, let me try to summarise, what this would mean for sh-mobile:
> > 
> > 1. this proposal introduces a new special case: with or without a mapping, 
> > that will have to be handled in affected client and DMA controller 
> > drivers. E.g., on sh-mobile some devices might on some systems use 
> > channels from "general purpose" DMA controllers (no mapping), on other 
> > systems it will be a dedicated controller (fixed mapping).
> that should work. The mapping is platform specific, so I expect the
> board handling code for that one to tell dmaengine the mapping.
> On device A: controller P can be generic but on some other device it can
> be dedicated.

As I wrote in a reply to Linus W - you need to pass information about the 
requesting client to the dmaengine core to let it match it against mapping 
tables. You have to pass this information with the dma_request_channel() 
function. So, either you need to add a parameter or you have to reuse one 
of existing ones, e.g., deprecate the filter and use its argument for this 
purpose. If you do this and as long as you pass that parameter further on 
to the dmaengine device (controller) driver after whatever matching you 
like to do in the core - I'm fine with that, that fits well with my 
initial proposal.

Thanks
Guennadi

> > 
> > 2. this will break, if we get more than 1 "general purpose" type with 
> > different supported client sets. So, we develop a new API with a 
> > pre-programmed limitation.
> No, see above
> > 
> > 3. this will mean a substantial driver and platform code modification. 
> > Nothing super-complex, but still some.
> Again No to driver, Yes to platform mapping part, which is again device
> specfic
> > 
> > 4. we'll need a 3-stage channel allocation / configuration: request, 
> > filter, config. Whereas with my configuration-parameter proposal it's just 
> > one stage: allocate-and-configure.
> Its not about stages, it about doing the right thing. Which happens to
> make dmaengine aware of the mapping which exists for a certain device
> and give you the channels based on how hardware is mapped.
> 
> If we get this right then we dont need to worry about filtering as well,
> that can go away. With Russell's approach it just request_config one
> single step to get channel and get it configured for slave.
> > 
> > So, yes, this would be doable, but it doesn't look like a very good 
> > solution to me.
> 
> 
> -- 
> ~Vinod
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/