On Thu, Jan 13, 2011 at 06:18:21PM +0200, Matti J. Aaltonen wrote:
I'm not changing the MFD driver, the first version is hopefully going into the v. 2.6.38 kernel.
Oh, fail.
At first I started to upstream all three parts of the driver at the same time, about a year ago. At first I sent all parts to the media list, there I was - quite reasonably - asked to send the codec to the alsa list. After some tuning and fine tuning the codec got accepted. But getting the rest of the driver in took much longer and in the process the MFD and V4L2 parts became incompatible with the codec.
This is something that should really have been brought up when making changes. It's really bad to just go and make other bits of the kernel fail to build.
While looking at this I also notice that it's surprisingly difficult to actually build any of this stuff - the MFD core can't be enabled directly, it's only available if you enable the V4L driver, and the core V4L build appears to be rather large adding a noticable amount of time to the build needed to get coverage of the CODECs. It'd be good if you could fix this to remove the dependency, I'd really expect the MFD to be able to build by itself.
So we'll just wait until 2.6.38 is out and everything remains compilable... When 38 gets released the codec cannot be used with rest of the driver until this patch is applied, but that can be done when a suitable window opens, right?
*Ideally* we'd have this API change included as part of the MFD driver merge or included in 2.6.37 since otherwise we cause build issues. ASoC has already been sent to Linus for this merge window. As it is I guess we have to apply this and send a fix later.