Cc: Dan Williams <dan.j.williams@...>, <linux-kernel@...>, Shannon Nelson <shannon.nelson@...>, <kernel@...>, Francis Moreau <francis.moro@...>, Paul Mundt <lethal@...>, Vladimir A. Barinov <vbarinov@...>, Pierre Ossman <drzeus-list@...>
On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
That's always a goal, but that's not what I said. I was pointing out
one scenario I ran into ... where starting with the simple solution
ran into product issues which were unfixable without using some of the
more advanced (and nonportable!!) hardware mechanisms.
Where you start is often NOT where you end up! You should make sure
that a wants-to-be-generic slave interface can accomodate a variety of
non-basic mechanisms, without getting bloated. :)
You probably missed the point that both "logical" and "physical"
channels in that case have hardware support. Drivers didn't really
need to worry about not being able to allocate a (logical) channel.
Yes, I also had the half-thought that maybe that notion could show
up in the "dmaengine" framework... ;)
Modulo the little glitches the hardware people always throw at us.
Like little synchronization races when the various signals don't
cross the same clock domains, and errata that creep in ... and the
fact that "just fine" can still have performance requirements, ones
that get harder to satisfy when the overcapacity gets shaved.
In platform-specific drivers, it's common to *NEED* to use lots
of different platform-specific mechanisms. The DMA engine and
the controller may well have been co-designed to address various
system-wide requirements, for example. It depends on how tightly
integrated things are.
Better to have some sort of "struct engine_type" and include a pointer
to it. That way there's no global enum in a header to maintain and
evolve over time.
Why not just use container_of() wrappers?
- Dave
--
