On Thursday 25 September 2008, Steve Sakoman wrote: > On Thu, 2008-09-25 at 09:50 -0700, David Brownell wrote: > > On Thursday 25 September 2008, Tony Lindgren wrote: > > > > Get rid of bogus ASOC boot messages on non-Overo boards. > > > > > > I'm not touching this without an ack from alsa list :) > > > > Has this driver even gone to that list yet? ;) > > Yes, the initial submission was reviewed and acked by folks on > alsa-devel. > > And now that I think of it, this code should never execute on non-overo > boards since they will have their own machine ASoC driver! So this > patch isn't really necessary. But it *did* execute on a Beagle. The kernel had both Overo and Beagle configured in. Ergo the $SUBJECT patch. :) > > I haven't really looked at initialization for this yet, > > but my initial reaction to seeing the Beagle's version > > of the overo.c file is that more sharing should exist. > > (Wasn't the beagle ASOC init described as a clone?) > > This was discussed, but since the overo has some additional > functionality that will be added to the machine portion of the driver it > was decided to have separate machine files for overo and beagle. I'm > waiting for an overo "buddy" board that brings out the additional > microphone inputs before I can add and test this functionality. OK. The amount of code isn't actually that much, but what's there looks like it should be sharable. > > And then ... that, hey, this should hook into the same > > MFD-style initialization as we're making the other > > twl4030 code use. > > > > And finally ... whoa, maybe someone else can split > > out the board-specific bits so they can be put in > > the arch/arm/mach-omap2/board-XYZ.c files, since I'd > > surely lose a lot of time learning ASOC if I were > > to start that! (These messages are right at the > > core of that bit.) > > Putting the board specific bits in the arch/arm/mach-omap2/board-XYZ.c > file has been discussed a number of times on alsa-devel and the folks > there insist that for now (i.e. ASoC V1) this is the proper way to do > things. Hmm, I'm not sure I follow. They want the SOC devices in the wrong place in the driver model tree, potentially impacting power management? I don't want to fight that fight, but ... that seems unwise. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
