On Thu, Jan 31, 2008 at 12:27:24AM -0800, David Brownell wrote: > On Wednesday 30 January 2008, Haavard Skinnemoen wrote: > > So basically, you're asking for maximum flexibility with minimum > > overhead. I agree that should be the ultimate goal, but wouldn't it > > be better to start with something more basic? > > 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. :) > I agree with Haavard here. The original dmaengine code was sparse at best and for a very specific type of workload, evolving that in to something that can be used by far more people with minimal pain is a good first step. Trying to overengineer it from the beginning to accomodate fringe controllers that already have an established API pretty much blocks the vast majority of users for this work. It also adds in additional complexity that is simply unnecessary for most of the controllers out there.
Flexibility is a nice thing to have, but there's absolutely no reason to penalize all of the other users for this due to the fact that OMAP wants to be different. Perhaps rather than reinventing the OMAP DMA framework, it would make more sense to just provide a dmaengine driver that wraps in to it. You're ultimately going to be dealing with a reduced set of functionality, but users that need to hook in to all of the quirks of the hardware are going to be special-cased drivers anyways. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
