A few fix patches for ASoC

A few fix patches for ASoC

[Takashi Iwai]

Mark,

I applied a few fix patches to fix/asoc and topic/asoc branches for
build errors I found with cross-build tests in this morning.
Check below and sync to your tree.

commit bb26276744a80d066681836f4d49c70010b129d6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 1 07:39:45 2009 +0200

    ASoC: Fix build errors of wm8711.c with SPI

commit c877c25170e2655d519b29e91d6c91d5d1a72a6f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 1 08:33:47 2009 +0200

    ASoC: Fix dependency of CONFIG_SND_PXA2XX_SOC_IMOTE2
    
commit 140318aaa924ce9664ff59366993228cf1547f1d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 1 08:40:32 2009 +0200

    ASoC: Fix snd_soc_dai_set_pll() calls in neo1973_*.c

Re: A few fix patches for ASoC

[Mark Brown]

On Thu, Oct 01, 2009 at 09:04:32AM +0200, Takashi Iwai wrote:

> commit c877c25170e2655d519b29e91d6c91d5d1a72a6f
> Author: Takashi Iwai <tiwai@suse.de>
> Date:   Thu Oct 1 08:33:47 2009 +0200
> 
>     ASoC: Fix dependency of CONFIG_SND_PXA2XX_SOC_IMOTE2

Hrm.  This one applies to every board which doesn't use AC97 (some will
need SPI but it's the same deal for that).  It should probably also be a
dependency on the actual I2C controller driver rather than I2C in
general since the driver isn't going to do anything if the I2C device
isn't actually able to come up, though that'd prevent people doing
strange stuff like having the I2C bus driver modular and the audio built
in.

I'll have a look at doing this properly later, though probably not
targetted at 2.6.32 since it doesn't seem to be something people hit
often.  An easier way of approaching it would be to put ifdefs into the
all CODEC drivers for their bus access, even if they only support one
bus type.  That'd keep build testing happy which I think is the main
thing here.

Re: A few fix patches for ASoC

[Takashi Iwai]

At Thu, 1 Oct 2009 16:24:43 +0100,
Mark Brown wrote:
> 
> On Thu, Oct 01, 2009 at 09:04:32AM +0200, Takashi Iwai wrote:
> 
> > commit c877c25170e2655d519b29e91d6c91d5d1a72a6f
> > Author: Takashi Iwai <tiwai@suse.de>
> > Date:   Thu Oct 1 08:33:47 2009 +0200
> > 
> >     ASoC: Fix dependency of CONFIG_SND_PXA2XX_SOC_IMOTE2
> 
> Hrm.  This one applies to every board which doesn't use AC97 (some will
> need SPI but it's the same deal for that).  It should probably also be a
> dependency on the actual I2C controller driver rather than I2C in
> general since the driver isn't going to do anything if the I2C device
> isn't actually able to come up, though that'd prevent people doing
> strange stuff like having the I2C bus driver modular and the audio built
> in.

Well, the problem is that it unconditionally selects WM8940, and
wm8940.c can't be built without CONFIG_I2C (and doesn't make much
sense right now).  I'd happily remove that I2C Kconfig dependency if
you are going to fix wm8940 part.


Takashi

Re: A few fix patches for ASoC

[Mark Brown]

On 1 Oct 2009, at 16:30, Takashi Iwai <tiwai@suse.de> wrote:

> At Thu, 1 Oct 2009 16:24:43 +0100,
> Mark Brown wrote:
>>
>> On Thu, Oct 01, 2009 at 09:04:32AM +0200, Takashi Iwai wrote:
>>
>>> commit c877c25170e2655d519b29e91d6c91d5d1a72a6f
>>> Author: Takashi Iwai <tiwai@suse.de>
>>> Date:   Thu Oct 1 08:33:47 2009 +0200
>>>
>>>    ASoC: Fix dependency of CONFIG_SND_PXA2XX_SOC_IMOTE2
>>
>> Hrm.  This one applies to every board which doesn't use AC97 (some  
>> will
>> need SPI but it's the same deal for that).  It should probably also  
>> be a
>> dependency on the actual I2C controller driver rather than I2C in
>> general since the driver isn't going to do anything if the I2C device
>> isn't actually able to come up, though that'd prevent people doing
>> strange stuff like having the I2C bus driver modular and the audio  
>> built
>> in.
>
> Well, the problem is that it unconditionally selects WM8940, and
> wm8940.c can't be built without CONFIG_I2C (and doesn't make much
> sense right now).  I'd happily remove that I2C Kconfig dependency if
> you are going to fix wm8940 part.

Yes, I see the problem you're trying to fix. It's just that this way  
it's going to bite pretty much every board one way or another. If it's  
just the randconfig style builds then bodging it in the CODEC drivers  
is probably more complete but OTOH it would be better to do it in a  
way that also ensures that the machine drivers are usable when  
enabled. I'll have a look and see how much trouble it would be to do  
that.