[alsa-devel] [PATCH] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

[Matti J. Aaltonen]

On Thu, 2011-01-13 at 17:12 +0000, ext Mark Brown 
wrote:
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.

I'm not exactly sure what you mean here... It's easy to say now - when
looking back that - the whole driver should have been handled more as a
whole. An ACK from you and an ACK from Samuel to the media guys etc...

But I'm not trying to break the kernel or the build process or irritate
you. I'm just trying to get this driver in because that's a part of my
job. And on the other hand I've followed every bit of advice I've gotten
along the way.

> 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.

My original plan was to have an MFD part with all the core functionality
and then the child drivers as two different clients to the core. With
that design it was possible to build the MFD with either, both or none
of the children... But the media people wanted an empty MFD part and all
basic functionality in the V4L2 driver. And the MFD driver was acked by
Samuel the MFD maintainer.

The codec can already be built alone, I can't see what benefit would
building the empty MFD driver offer. With the current structure nothing
can actually be done without the V4L2 driver. But if there's something I
don't get right now, I'll be happy make changes.

> > 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.

OK, sounds good...

Cheers,
Matti