linux-next: sound tree build failure

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/drivers/pcsp/pcsp.c: In function 'snd_card_pcsp_probe':
sound/drivers/pcsp/pcsp.c:99: error: 'HRTIMER_CB_IRQSAFE' undeclared (first use in this function)

That identifier does not exist anywhere else in my tree.  It was removed
by commit 621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up
unused callback modes") which is now in Linus' tree (as of yesterday).

I'll drop the sound tree for today and hope it will be fixed for Monday.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 14 Nov 2008 14:56:30 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/drivers/pcsp/pcsp.c: In function 'snd_card_pcsp_probe':
> sound/drivers/pcsp/pcsp.c:99: error: 'HRTIMER_CB_IRQSAFE' undeclared (first use in this function)
> 
> That identifier does not exist anywhere else in my tree.  It was removed
> by commit 621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up
> unused callback modes") which is now in Linus' tree (as of yesterday).

I had to rebase the tree yesterday, but the code there is identical with
the older versions.  So, if it failed there, it must be a change of
hrtimer side.

I'll check tip tree...


Takashi

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Hi Takashi,

On Fri, 14 Nov 2008 07:32:23 +0100 Takashi Iwai <tiwai@suse.de> wrote:
>
> > That identifier does not exist anywhere else in my tree.  It was removed
> > by commit 621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up
> > unused callback modes") which is now in Linus' tree (as of yesterday).
> 
> I had to rebase the tree yesterday, but the code there is identical with
> the older versions.  So, if it failed there, it must be a change of
> hrtimer side.
> 
> I'll check tip tree...

That commit entered Linus' tree after you rebased your tree but before I
fetched it this morning.  You could fix things by merging Linus' tree and
doing the fix in the merge commit rather than rebasing.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 14 Nov 2008 17:58:56 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> On Fri, 14 Nov 2008 07:32:23 +0100 Takashi Iwai <tiwai@suse.de> wrote:
> >
> > > That identifier does not exist anywhere else in my tree.  It was removed
> > > by commit 621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up
> > > unused callback modes") which is now in Linus' tree (as of yesterday).
> > 
> > I had to rebase the tree yesterday, but the code there is identical with
> > the older versions.  So, if it failed there, it must be a change of
> > hrtimer side.
> > 
> > I'll check tip tree...
> 
> That commit entered Linus' tree after you rebased your tree but before I
> fetched it this morning.  You could fix things by merging Linus' tree and
> doing the fix in the merge commit rather than rebasing.

To defense myself: the reason of the rebase is irrelevant with this
build error.  It's just a sad coincident.

I had to rebase the sound tree because I need to drop one topic branch
which cause another build error.  Of course, I could revert each 15 commit
of that topic branch, but it's also annoying.  Thus I decided to rebase
(just re-merging each topic branch again from scratch).

I'm wondering why this happens, though.  Such a clean-up patch should
has been tested enough long on linux-next before pushed into Linus
tree.  And, I see no reason to push a clean-up patch at this late rc
stage...


thanks,

Takashi

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 14 Nov 2008 08:07:44 +0100,
私 wrote:
> 
> At Fri, 14 Nov 2008 17:58:56 +1100,
> Stephen Rothwell wrote:
> > 
> > Hi Takashi,
> > 
> > On Fri, 14 Nov 2008 07:32:23 +0100 Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > > That identifier does not exist anywhere else in my tree.  It was removed
> > > > by commit 621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up
> > > > unused callback modes") which is now in Linus' tree (as of yesterday).
> > > 
> > > I had to rebase the tree yesterday, but the code there is identical with
> > > the older versions.  So, if it failed there, it must be a change of
> > > hrtimer side.
> > > 
> > > I'll check tip tree...
> > 
> > That commit entered Linus' tree after you rebased your tree but before I
> > fetched it this morning.  You could fix things by merging Linus' tree and
> > doing the fix in the merge commit rather than rebasing.
> 
> To defense myself: the reason of the rebase is irrelevant with this
> build error.  It's just a sad coincident.

Well, what I wanted to say is that the rebase on my tree is fairly
rare (IIRC, it was the first time after 2.6.28-rc1), and this build
error would occur regardless of rebase or not...  Sigh.


Takashi

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

[For Peter and Ingo, we are discussing commit
621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up unused
callback modes") that went into Linus' tree yesterday but broke the sound
tree in linux-next which used one of the removed defines.]

Hi Takshi,

On Fri, 14 Nov 2008 08:07:44 +0100 Takashi Iwai <tiwai@suse.de> wrote:
>
> To defense myself: the reason of the rebase is irrelevant with this
> build error.  It's just a sad coincident.

There is no need to defend yourself, as you say a sad coincidence.

I am sorry if dropping the sound tree has made you feel attacked, it is
just the new way I am doing things - I cannot fix every problem, so I
will not try in most cases.  The sound tree will be restored as soon as
this is fixed up.

> I had to rebase the sound tree because I need to drop one topic branch
> which cause another build error.  Of course, I could revert each 15 commit
> of that topic branch, but it's also annoying.  Thus I decided to rebase
> (just re-merging each topic branch again from scratch).

And that is perfectly fine.  As you said the rebase had nothing to do
with this new build error.

> I'm wondering why this happens, though.  Such a clean-up patch should
> has been tested enough long on linux-next before pushed into Linus
> tree.  And, I see no reason to push a clean-up patch at this late rc
> stage...

A lot of stuff goes into Linus' tree without entering linux-next at all.
But, as you say, this clean up patch, and, coming through the tip trees, I
would have expected to be in linux-next for at least a day ...

Things like this happen all the time ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 14 Nov 2008 18:27:18 +1100,
Stephen Rothwell wrote:
> 
> [For Peter and Ingo, we are discussing commit
> 621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up unused
> callback modes") that went into Linus' tree yesterday but broke the sound
> tree in linux-next which used one of the removed defines.]
> 
> Hi Takshi,
> 
> On Fri, 14 Nov 2008 08:07:44 +0100 Takashi Iwai <tiwai@suse.de> wrote:
> >
> > To defense myself: the reason of the rebase is irrelevant with this
> > build error.  It's just a sad coincident.
> 
> There is no need to defend yourself, as you say a sad coincidence.
> 
> I am sorry if dropping the sound tree has made you feel attacked, it is
> just the new way I am doing things - I cannot fix every problem, so I
> will not try in most cases.  The sound tree will be restored as soon as
> this is fixed up.

Heh, don't take too serious.  I was just too nervous when I saw two
build error mails just after waking up in the morning ;)
Should have taken a pot of healthy caffeine before checking mails, at
least.

BTW, what would be the best fix?  To me, the easiest is to revert the
commit.  But, if other HRTIMER_CB_IRQSAFE_* flag is known and confirmed
to work like HRTIMER_CB_IRQSAFE, I can simply change to it as a fix.

> > I had to rebase the sound tree because I need to drop one topic branch
> > which cause another build error.  Of course, I could revert each 15 commit
> > of that topic branch, but it's also annoying.  Thus I decided to rebase
> > (just re-merging each topic branch again from scratch).
> 
> And that is perfectly fine.  As you said the rebase had nothing to do
> with this new build error.
> 
> > I'm wondering why this happens, though.  Such a clean-up patch should
> > has been tested enough long on linux-next before pushed into Linus
> > tree.  And, I see no reason to push a clean-up patch at this late rc
> > stage...
> 
> A lot of stuff goes into Linus' tree without entering linux-next at all.
> But, as you say, this clean up patch, and, coming through the tip trees, I
> would have expected to be in linux-next for at least a day ...
> 
> Things like this happen all the time ...

Yeah, but in this case, really funny.  The very same moment I did
something dirty, suddenly spotted a light and taken onto the stage :)

But, seriously, it'd be really helpful if clean-up patches are put on
linux-next for a while just for testing purpose, too.


thanks,

Takashi

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Hi Takashi,

On Fri, 14 Nov 2008 08:41:31 +0100 Takashi Iwai <tiwai@suse.de> wrote:
>
> BTW, what would be the best fix?  To me, the easiest is to revert the
> commit.  But, if other HRTIMER_CB_IRQSAFE_* flag is known and confirmed
> to work like HRTIMER_CB_IRQSAFE, I can simply change to it as a fix.

I don't know, sorry - that is why I am leaving fixes to those who do.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/soc/codecs/wm8994.c:30:35: error: linux/mfd/wm8994/core.h: No such file or directory
sound/soc/codecs/wm8994.c:31:40: error: linux/mfd/wm8994/registers.h: No such file or directory
sound/soc/codecs/wm8994.c:32:36: error: linux/mfd/wm8994/pdata.h: No such file or directory
sound/soc/codecs/wm8994.c:33:35: error: linux/mfd/wm8994/gpio.h: No such file or directory

And went down hill form there :-(

Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
WM8994 CODEC driver").  I presume that this commit depends on commits
currently only in the mfd tree ...

I have used the sound tree from next-20100201 for today.

To fix this, the relevant commits from the mfd tree could be put into a
"never to be rebased" branch (or separate git tree) and then this branch
merged into both the sound and mfd trees.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Tue, 2 Feb 2010 12:47:11 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/soc/codecs/wm8994.c:30:35: error: linux/mfd/wm8994/core.h: No such file or directory
> sound/soc/codecs/wm8994.c:31:40: error: linux/mfd/wm8994/registers.h: No such file or directory
> sound/soc/codecs/wm8994.c:32:36: error: linux/mfd/wm8994/pdata.h: No such file or directory
> sound/soc/codecs/wm8994.c:33:35: error: linux/mfd/wm8994/gpio.h: No such file or directory
> 
> And went down hill form there :-(

Ah, sorry, this driver didn't hit in my quick test in the last
evening before pushing.

> Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
> WM8994 CODEC driver").  I presume that this commit depends on commits
> currently only in the mfd tree ...

Yep, looks so.
 
> I have used the sound tree from next-20100201 for today.
> 
> To fix this, the relevant commits from the mfd tree could be put into a
> "never to be rebased" branch (or separate git tree) and then this branch
> merged into both the sound and mfd trees.

Well, I don't think the codec register definitions don't have to be
dependent on mfd tree at all.  All other codec drivers have own
definitions.

Mark, can it be self-contained?


thanks,

Takashi

Re: linux-next: sound tree build failure

[Mark Brown]

On Tue, Feb 02, 2010 at 08:27:19AM +0100, Takashi Iwai wrote:

> Well, I don't think the codec register definitions don't have to be
> dependent on mfd tree at all.  All other codec drivers have own
> definitions.

> Mark, can it be self-contained?

No, it needs to look at things like the multi-function pin configuration
in order to configure itself correctly.

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Tue, 2 Feb 2010 10:31:12 +0000,
Mark Brown wrote:
> 
> On Tue, Feb 02, 2010 at 08:27:19AM +0100, Takashi Iwai wrote:
> 
> > Well, I don't think the codec register definitions don't have to be
> > dependent on mfd tree at all.  All other codec drivers have own
> > definitions.
> 
> > Mark, can it be self-contained?
> 
> No, it needs to look at things like the multi-function pin configuration
> in order to configure itself correctly.

Hm, then shouldn't it depend on mfd?



Takashi

Re: linux-next: sound tree build failure

[Mark Brown]

On Tue, Feb 02, 2010 at 11:40:03AM +0100, Takashi Iwai wrote:
> Mark Brown wrote:

> > No, it needs to look at things like the multi-function pin configuration
> > in order to configure itself correctly.

> Hm, then shouldn't it depend on mfd?

Yes, I've got a patch for that which I'll send shortly (though that
shouldn't affect the -next build it will affect the sound build).

Re: linux-next: sound tree build failure

[Mark Brown]

On Tue, Feb 02, 2010 at 12:47:11PM +1100, Stephen Rothwell wrote:

> sound/soc/codecs/wm8994.c:30:35: error: linux/mfd/wm8994/core.h: No such file or directory
> sound/soc/codecs/wm8994.c:31:40: error: linux/mfd/wm8994/registers.h: No such file or directory
> sound/soc/codecs/wm8994.c:32:36: error: linux/mfd/wm8994/pdata.h: No such file or directory
> sound/soc/codecs/wm8994.c:33:35: error: linux/mfd/wm8994/gpio.h: No such file or directory

> And went down hill form there :-(

This looks really odd - all those headers are present in the linux-next
tree (and have been for a few days) as far as I can tell, and I can't
see any way they could not be found without serious breakage elsewhere.
Could you please re-run your build with V=1 to show the kernel command
line used to build the driver?  I can't reproduce this here and like I
say I can't see how this could happen given that those files are there
in -next and it's hard to see how this could happen.

> Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
> WM8994 CODEC driver").  I presume that this commit depends on commits
> currently only in the mfd tree ...

Not exactly, there's a Kconfig dependency which should keep track of
things but the wrong one got merged over when things got split out to go
into the several trees.  Though for allmodconfig that will not be
relevant since the dependency will be satisfied anyway and the headers
don't need Kconfig to pull them in.

Like I say, everything required is in the MFD tree in -next anyway.

> I have used the sound tree from next-20100201 for today.

> To fix this, the relevant commits from the mfd tree could be put into a
> "never to be rebased" branch (or separate git tree) and then this branch
> merged into both the sound and mfd trees.

This is not needed, Kconfig will handle it.

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

Hi Mark,

On Tue, 2 Feb 2010 10:26:10 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> This looks really odd - all those headers are present in the linux-next
> tree (and have been for a few days) as far as I can tell, and I can't
> see any way they could not be found without serious breakage elsewhere.
> Could you please re-run your build with V=1 to show the kernel command
> line used to build the driver?  I can't reproduce this here and like I
> say I can't see how this could happen given that those files are there
> in -next and it's hard to see how this could happen.

The sound tree is merged before the mfd tree, and the commit that adds
those is only in the mfd tree.  So the sound tree, on its own, is
broken.  This driver will only build if you merge the mfd tree as well.

> > Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
> > WM8994 CODEC driver").  I presume that this commit depends on commits
> > currently only in the mfd tree ...
> 
> Not exactly, there's a Kconfig dependency which should keep track of
> things but the wrong one got merged over when things got split out to go
> into the several trees.  Though for allmodconfig that will not be
> relevant since the dependency will be satisfied anyway and the headers
> don't need Kconfig to pull them in.
> 
> Like I say, everything required is in the MFD tree in -next anyway.

yes, but I do builds between merging trees ...

> > I have used the sound tree from next-20100201 for today.
> 
> > To fix this, the relevant commits from the mfd tree could be put into a
> > "never to be rebased" branch (or separate git tree) and then this branch
> > merged into both the sound and mfd trees.
> 
> This is not needed, Kconfig will handle it.

Kconfig has nothing to do with it, sorry.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sound tree build failure

[Mark Brown]

On Tue, Feb 02, 2010 at 09:37:32PM +1100, Stephen Rothwell wrote:

> The sound tree is merged before the mfd tree, and the commit that adds
> those is only in the mfd tree.  So the sound tree, on its own, is
> broken.  This driver will only build if you merge the mfd tree as well.

Ah, you're doing builds after each individual merge.  It might help to
change the form you're using when reporting problems with partially
constructed -next - at the minute you say "Today's linux-next build
(x86_64 allmodconfig) failed like this:" which makes it look like you're
testing the result of the full -next merge.

> > > To fix this, the relevant commits from the mfd tree could be put into a
> > > "never to be rebased" branch (or separate git tree) and then this branch
> > > merged into both the sound and mfd trees.

> > This is not needed, Kconfig will handle it.

> Kconfig has nothing to do with it, sorry.

No, it does really fix the problem.  As I said the driver should build
depend on a Kconfig symbol which is introduced in the MFD tree.  This
means that the driver will not be built at all until MFD has been merged
since the dependencies required to select the driver will not be
satisfied unless the commits it depends on are present in the tree.

I'll push a patch for this shortly.

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

Hi Mark,

On Tue, 2 Feb 2010 10:58:00 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Feb 02, 2010 at 09:37:32PM +1100, Stephen Rothwell wrote:
> 
> > The sound tree is merged before the mfd tree, and the commit that adds
> > those is only in the mfd tree.  So the sound tree, on its own, is
> > broken.  This driver will only build if you merge the mfd tree as well.
> 
> Ah, you're doing builds after each individual merge.  It might help to

Always have ...

> change the form you're using when reporting problems with partially
> constructed -next - at the minute you say "Today's linux-next build
> (x86_64 allmodconfig) failed like this:" which makes it look like you're
> testing the result of the full -next merge.

I was hoping that the subject of the email would help with that
impression.

> > Kconfig has nothing to do with it, sorry.
> 
> No, it does really fix the problem.  As I said the driver should build
> depend on a Kconfig symbol which is introduced in the MFD tree.  This
> means that the driver will not be built at all until MFD has been merged
> since the dependencies required to select the driver will not be
> satisfied unless the commits it depends on are present in the tree.

Yeah, OK, I guess you could do that.

> I'll push a patch for this shortly.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sound tree build failure

[Mark Brown]

On Tue, Feb 02, 2010 at 10:17:43PM +1100, Stephen Rothwell wrote:
> On Tue, 2 Feb 2010 10:58:00 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > change the form you're using when reporting problems with partially
> > constructed -next - at the minute you say "Today's linux-next build
> > (x86_64 allmodconfig) failed like this:" which makes it look like you're
> > testing the result of the full -next merge.

> I was hoping that the subject of the email would help with that
> impression.

The way I've always read that was that you'd found a build failure in
a given bit of the tree while testing -next - you're clearly doing some
work to identify and understand where the failure came from (and simply
looking at the source file leads to the same result normally anyway) so
the fact that you've identified the subsystem doesn't automatically say
that this happened with a partially merged -next.  If you looked less
like a human the subject by itself would be clearer :)

> > > Kconfig has nothing to do with it, sorry.

> > No, it does really fix the problem.  As I said the driver should build
> > depend on a Kconfig symbol which is introduced in the MFD tree.  This
> > means that the driver will not be built at all until MFD has been merged
> > since the dependencies required to select the driver will not be
> > satisfied unless the commits it depends on are present in the tree.

> Yeah, OK, I guess you could do that.

It's needed anyway, the driver will try to link against the MFD core so
even with both bits merged a build that didn't select the core would
fail.

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Hi Mark,

On Tue, 2 Feb 2010 11:34:24 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> The way I've always read that was that you'd found a build failure in
> a given bit of the tree while testing -next - you're clearly doing some
> work to identify and understand where the failure came from (and simply
> looking at the source file leads to the same result normally anyway) so
> the fact that you've identified the subsystem doesn't automatically say
> that this happened with a partially merged -next.  If you looked less
> like a human the subject by itself would be clearer :)

How about "linux-next: build failure after merging xxx tree"?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sound tree build failure

[Mark Brown]

On Tue, Feb 02, 2010 at 10:55:45PM +1100, Stephen Rothwell wrote:

> How about "linux-next: build failure after merging xxx tree"?

Yes that's a lot clearer, thanks.

Re: linux-next: sound tree build failure

[Liam Girdwood]

Hi Stephen,

On Tue, 2010-02-02 at 22:17 +1100, Stephen Rothwell wrote:
> Hi Mark,
> 
> On Tue, 2 Feb 2010 10:58:00 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> >
> > On Tue, Feb 02, 2010 at 09:37:32PM +1100, Stephen Rothwell wrote:
> > 
> > > The sound tree is merged before the mfd tree, and the commit that adds
> > > those is only in the mfd tree.  So the sound tree, on its own, is
> > > broken.  This driver will only build if you merge the mfd tree as well.
> > 
> > Ah, you're doing builds after each individual merge.  It might help to
> 
> Always have ...
> 

I wonder if it would be possible to re-order the merge sequence so that
similar inter tree dependencies are less likely to cause -next build
failures in the future.  I guess atm lots of driver trees can depend on
MFD (e.g. regulator, sound, rtc, backlight, led, watchdog, etc) so it
may be good to move it up the order.

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

Hi Liam,

On Tue, 02 Feb 2010 11:50:30 +0000 Liam Girdwood <lrg@slimlogic.co.uk> wrote:
>
> I wonder if it would be possible to re-order the merge sequence so that
> similar inter tree dependencies are less likely to cause -next build

Anything is possible with software :-)

> failures in the future.  I guess atm lots of driver trees can depend on
> MFD (e.g. regulator, sound, rtc, backlight, led, watchdog, etc) so it
> may be good to move it up the order.

In this case it would just have masked the dependency and we may not have
found it until the sound tree was merged into Linus' tree and builds
started failing.  (I now Mark already knew about this one.)  We actually
have very few build dependencies between trees and in most cases I would
prefer that they were exposed in linux-next than in Linus' tree (with the
ensuing bisection problems).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

linux-next: sound tree build failure

[Stephen Rothwell]

Hi Takashi,

Today's linux-next build (i386 defconfig) failed like this:

sound/pci/hda/patch_via.c: In function 'patch_vt1718S':
sound/pci/hda/patch_via.c:4951: error: expected expression before 'return'

Caused by commit eb7188cafcb7aa1419b8889494cdbd4e6a01da1c ("ALSA: HDA
VIA: Add VT1718S support").

sound/pci/hda/patch_via.c: In function 'patch_vt1716S':
sound/pci/hda/patch_via.c:5441: error: expected expression before 'return'

Caused by commit f3db423df84570c9950754a5771ad26f0111235f ("ALSA: HDA
VIA: Add VT1716S support").

sound/pci/hda/patch_via.c: In function 'patch_vt2002P':
sound/pci/hda/patch_via.c:5794: error: expected expression before 'return'

Caused by commit 25eaba2f8a6877ba6f58197c4723c2433a316e09 ("ALSA: HDA VIA: Add VT2002P support").

sound/pci/hda/patch_via.c: In function 'patch_vt1812':
sound/pci/hda/patch_via.c:6148: error: expected expression before 'return'

Caused by commit ab6734e7ea32e9f9cbe0f55eeddf4aa629ed1c3d ("ALSA: HDA VIA: Add VT1812 support").

I applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 12 Oct 2009 15:56:17 +1100
Subject: [PATCH] sound: use semicolons to end statements

Fixes:

sound/pci/hda/patch_via.c: In function 'patch_vt1718S':
sound/pci/hda/patch_via.c:4951: error: expected expression before 'return'
sound/pci/hda/patch_via.c: In function 'patch_vt1716S':
sound/pci/hda/patch_via.c:5441: error: expected expression before 'return'
sound/pci/hda/patch_via.c: In function 'patch_vt2002P':
sound/pci/hda/patch_via.c:5794: error: expected expression before 'return'
sound/pci/hda/patch_via.c: In function 'patch_vt1812':
sound/pci/hda/patch_via.c:6148: error: expected expression before 'return'

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 sound/pci/hda/patch_via.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c
index 30260e2..a294060 100644
--- a/sound/pci/hda/patch_via.c
+++ b/sound/pci/hda/patch_via.c
@@ -4942,7 +4942,7 @@ static int patch_vt1718S(struct hda_codec *codec)
 	codec->patch_ops = via_patch_ops;
 
 	codec->patch_ops.init = via_auto_init;
-	codec->patch_ops.unsol_event = via_unsol_event,
+	codec->patch_ops.unsol_event = via_unsol_event;
 
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	spec->loopback.amplist = vt1718S_loopbacks;
@@ -5432,7 +5432,7 @@ static int patch_vt1716S(struct hda_codec *codec)
 	codec->patch_ops = via_patch_ops;
 
 	codec->patch_ops.init = via_auto_init;
-	codec->patch_ops.unsol_event = via_unsol_event,
+	codec->patch_ops.unsol_event = via_unsol_event;
 
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	spec->loopback.amplist = vt1716S_loopbacks;
@@ -5785,7 +5785,7 @@ static int patch_vt2002P(struct hda_codec *codec)
 	codec->patch_ops = via_patch_ops;
 
 	codec->patch_ops.init = via_auto_init;
-	codec->patch_ops.unsol_event = via_unsol_event,
+	codec->patch_ops.unsol_event = via_unsol_event;
 
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	spec->loopback.amplist = vt2002P_loopbacks;
@@ -6139,7 +6139,7 @@ static int patch_vt1812(struct hda_codec *codec)
 	codec->patch_ops = via_patch_ops;
 
 	codec->patch_ops.init = via_auto_init;
-	codec->patch_ops.unsol_event = via_unsol_event,
+	codec->patch_ops.unsol_event = via_unsol_event;
 
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	spec->loopback.amplist = vt1812_loopbacks;
-- 
1.6.4.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Mon, 12 Oct 2009 16:08:16 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (i386 defconfig) failed like this:
> 
> sound/pci/hda/patch_via.c: In function 'patch_vt1718S':
> sound/pci/hda/patch_via.c:4951: error: expected expression before 'return'
> 
> Caused by commit eb7188cafcb7aa1419b8889494cdbd4e6a01da1c ("ALSA: HDA
> VIA: Add VT1718S support").
> 
> sound/pci/hda/patch_via.c: In function 'patch_vt1716S':
> sound/pci/hda/patch_via.c:5441: error: expected expression before 'return'
> 
> Caused by commit f3db423df84570c9950754a5771ad26f0111235f ("ALSA: HDA
> VIA: Add VT1716S support").
> 
> sound/pci/hda/patch_via.c: In function 'patch_vt2002P':
> sound/pci/hda/patch_via.c:5794: error: expected expression before 'return'
> 
> Caused by commit 25eaba2f8a6877ba6f58197c4723c2433a316e09 ("ALSA: HDA VIA: Add VT2002P support").
> 
> sound/pci/hda/patch_via.c: In function 'patch_vt1812':
> sound/pci/hda/patch_via.c:6148: error: expected expression before 'return'
> 
> Caused by commit ab6734e7ea32e9f9cbe0f55eeddf4aa629ed1c3d ("ALSA: HDA VIA: Add VT1812 support").
> 
> I applied the following patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 12 Oct 2009 15:56:17 +1100
> Subject: [PATCH] sound: use semicolons to end statements
> 
> Fixes:
> 
> sound/pci/hda/patch_via.c: In function 'patch_vt1718S':
> sound/pci/hda/patch_via.c:4951: error: expected expression before 'return'
> sound/pci/hda/patch_via.c: In function 'patch_vt1716S':
> sound/pci/hda/patch_via.c:5441: error: expected expression before 'return'
> sound/pci/hda/patch_via.c: In function 'patch_vt2002P':
> sound/pci/hda/patch_via.c:5794: error: expected expression before 'return'
> sound/pci/hda/patch_via.c: In function 'patch_vt1812':
> sound/pci/hda/patch_via.c:6148: error: expected expression before 'return'
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

This error happens only when CONFIG_SND_HDA_POWER_SAVE=n, which wasn't
triggered by build tests...

I applied your fix now.  Thanks Stephen!


Takashi


> ---
>  sound/pci/hda/patch_via.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c
> index 30260e2..a294060 100644
> --- a/sound/pci/hda/patch_via.c
> +++ b/sound/pci/hda/patch_via.c
> @@ -4942,7 +4942,7 @@ static int patch_vt1718S(struct hda_codec *codec)
>  	codec->patch_ops = via_patch_ops;
>  
>  	codec->patch_ops.init = via_auto_init;
> -	codec->patch_ops.unsol_event = via_unsol_event,
> +	codec->patch_ops.unsol_event = via_unsol_event;
>  
>  #ifdef CONFIG_SND_HDA_POWER_SAVE
>  	spec->loopback.amplist = vt1718S_loopbacks;
> @@ -5432,7 +5432,7 @@ static int patch_vt1716S(struct hda_codec *codec)
>  	codec->patch_ops = via_patch_ops;
>  
>  	codec->patch_ops.init = via_auto_init;
> -	codec->patch_ops.unsol_event = via_unsol_event,
> +	codec->patch_ops.unsol_event = via_unsol_event;
>  
>  #ifdef CONFIG_SND_HDA_POWER_SAVE
>  	spec->loopback.amplist = vt1716S_loopbacks;
> @@ -5785,7 +5785,7 @@ static int patch_vt2002P(struct hda_codec *codec)
>  	codec->patch_ops = via_patch_ops;
>  
>  	codec->patch_ops.init = via_auto_init;
> -	codec->patch_ops.unsol_event = via_unsol_event,
> +	codec->patch_ops.unsol_event = via_unsol_event;
>  
>  #ifdef CONFIG_SND_HDA_POWER_SAVE
>  	spec->loopback.amplist = vt2002P_loopbacks;
> @@ -6139,7 +6139,7 @@ static int patch_vt1812(struct hda_codec *codec)
>  	codec->patch_ops = via_patch_ops;
>  
>  	codec->patch_ops.init = via_auto_init;
> -	codec->patch_ops.unsol_event = via_unsol_event,
> +	codec->patch_ops.unsol_event = via_unsol_event;
>  
>  #ifdef CONFIG_SND_HDA_POWER_SAVE
>  	spec->loopback.amplist = vt1812_loopbacks;
> -- 
> 1.6.4.3
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

make[4]: *** No rule to make target `include/sound/sscape_ioctl.h', needed by `usr/include/sound/.install'.

Caused by commit acd47100914b2896d0699febefd077f85c4dd272 ("ALSA: sscape:
convert to firmware loader framework") which removed
include/sound/sscape_ioctl.h but neglected to update include/sound/Kbuild.

I have used the sound tree from next-20090930 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 2 Oct 2009 11:15:52 +1000,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> make[4]: *** No rule to make target `include/sound/sscape_ioctl.h', needed by `usr/include/sound/.install'.
> 
> Caused by commit acd47100914b2896d0699febefd077f85c4dd272 ("ALSA: sscape:
> convert to firmware loader framework") which removed
> include/sound/sscape_ioctl.h but neglected to update include/sound/Kbuild.

Oops, totally forgot about this.  (And my build test didn't reach here.)
Fixed now.


thanks,

Takashi

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3957 bytes --]

Hi Takashi,

Today's linux-next build (x86_64_allmodconfig) failed like this:

sound/soc/codecs/wm8711.c:523: warning: 'struct spi_device' declared inside parameter list
sound/soc/codecs/wm8711.c:523: warning: its scope is only this definition or declaration, which is probably not what you want
sound/soc/codecs/wm8711.c: In function 'wm8711_spi_probe':
sound/soc/codecs/wm8711.c:534: error: dereferencing pointer to incomplete type
sound/soc/codecs/wm8711.c:536: error: dereferencing pointer to incomplete type
sound/soc/codecs/wm8711.c: At top level:
sound/soc/codecs/wm8711.c:541: warning: 'struct spi_device' declared inside parameter list
sound/soc/codecs/wm8711.c: In function 'wm8711_spi_remove':
sound/soc/codecs/wm8711.c:543: error: dereferencing pointer to incomplete type
sound/soc/codecs/wm8711.c: At top level:
sound/soc/codecs/wm8711.c:551: warning: 'struct spi_device' declared inside parameter list
sound/soc/codecs/wm8711.c: In function 'wm8711_spi_suspend':
sound/soc/codecs/wm8711.c:553: error: dereferencing pointer to incomplete type
sound/soc/codecs/wm8711.c: At top level:
sound/soc/codecs/wm8711.c:556: warning: 'struct spi_device' declared inside parameter list
sound/soc/codecs/wm8711.c: In function 'wm8711_spi_resume':
sound/soc/codecs/wm8711.c:558: error: dereferencing pointer to incomplete type
sound/soc/codecs/wm8711.c: At top level:
sound/soc/codecs/wm8711.c:565: error: variable 'wm8711_spi_driver' has initializer but incomplete type
sound/soc/codecs/wm8711.c:566: error: unknown field 'driver' specified in initializer
sound/soc/codecs/wm8711.c:566: error: extra brace group at end of initializer
sound/soc/codecs/wm8711.c:566: error: (near initialization for 'wm8711_spi_driver')
sound/soc/codecs/wm8711.c:568: error: 'spi_bus_type' undeclared here (not in a function)
sound/soc/codecs/wm8711.c:570: warning: excess elements in struct initializer
sound/soc/codecs/wm8711.c:570: warning: (near initialization for 'wm8711_spi_driver')
sound/soc/codecs/wm8711.c:571: error: unknown field 'probe' specified in initializer
sound/soc/codecs/wm8711.c:571: warning: excess elements in struct initializer
sound/soc/codecs/wm8711.c:571: warning: (near initialization for 'wm8711_spi_driver')
sound/soc/codecs/wm8711.c:572: error: unknown field 'suspend' specified in initializer
sound/soc/codecs/wm8711.c:572: warning: excess elements in struct initializer
sound/soc/codecs/wm8711.c:572: warning: (near initialization for 'wm8711_spi_driver')
sound/soc/codecs/wm8711.c:573: error: unknown field 'resume' specified in initializer
sound/soc/codecs/wm8711.c:573: warning: excess elements in struct initializer
sound/soc/codecs/wm8711.c:573: warning: (near initialization for 'wm8711_spi_driver')
sound/soc/codecs/wm8711.c:574: error: unknown field 'remove' specified in initializer
sound/soc/codecs/wm8711.c:574: warning: excess elements in struct initializer
sound/soc/codecs/wm8711.c:574: warning: (near initialization for 'wm8711_spi_driver')
sound/soc/codecs/wm8711.c: In function 'wm8711_modinit':
sound/soc/codecs/wm8711.c:635: error: implicit declaration of function 'spi_register_driver'
sound/soc/codecs/wm8711.c:635: error: 'wm8731_spi_driver' undeclared (first use in this function)
sound/soc/codecs/wm8711.c:635: error: (Each undeclared identifier is reported only once
sound/soc/codecs/wm8711.c:635: error: for each function it appears in.)
sound/soc/codecs/wm8711.c: In function 'wm8711_exit':
sound/soc/codecs/wm8711.c:651: error: implicit declaration of function 'spi_unregister_driver'
sound/soc/codecs/wm8711.c:651: error: 'wm8731_spi_driver' undeclared (first use in this function)

Caused by commit 08aff8cd7a8568588d460c4bf8875a492d430314 ("ASoC: Add SPI
support to WM8711").

I have used the version of the sound tree from next-20090930 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Thu, 1 Oct 2009 11:19:35 +1000,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (x86_64_allmodconfig) failed like this:
> 
> sound/soc/codecs/wm8711.c:523: warning: 'struct spi_device' declared inside parameter list
> sound/soc/codecs/wm8711.c:523: warning: its scope is only this definition or declaration, which is probably not what you want
> sound/soc/codecs/wm8711.c: In function 'wm8711_spi_probe':
> sound/soc/codecs/wm8711.c:534: error: dereferencing pointer to incomplete type
> sound/soc/codecs/wm8711.c:536: error: dereferencing pointer to incomplete type
> sound/soc/codecs/wm8711.c: At top level:
> sound/soc/codecs/wm8711.c:541: warning: 'struct spi_device' declared inside parameter list
> sound/soc/codecs/wm8711.c: In function 'wm8711_spi_remove':
> sound/soc/codecs/wm8711.c:543: error: dereferencing pointer to incomplete type
> sound/soc/codecs/wm8711.c: At top level:
> sound/soc/codecs/wm8711.c:551: warning: 'struct spi_device' declared inside parameter list
> sound/soc/codecs/wm8711.c: In function 'wm8711_spi_suspend':
> sound/soc/codecs/wm8711.c:553: error: dereferencing pointer to incomplete type
> sound/soc/codecs/wm8711.c: At top level:
> sound/soc/codecs/wm8711.c:556: warning: 'struct spi_device' declared inside parameter list
> sound/soc/codecs/wm8711.c: In function 'wm8711_spi_resume':
> sound/soc/codecs/wm8711.c:558: error: dereferencing pointer to incomplete type
> sound/soc/codecs/wm8711.c: At top level:
> sound/soc/codecs/wm8711.c:565: error: variable 'wm8711_spi_driver' has initializer but incomplete type
> sound/soc/codecs/wm8711.c:566: error: unknown field 'driver' specified in initializer
> sound/soc/codecs/wm8711.c:566: error: extra brace group at end of initializer
> sound/soc/codecs/wm8711.c:566: error: (near initialization for 'wm8711_spi_driver')
> sound/soc/codecs/wm8711.c:568: error: 'spi_bus_type' undeclared here (not in a function)
> sound/soc/codecs/wm8711.c:570: warning: excess elements in struct initializer
> sound/soc/codecs/wm8711.c:570: warning: (near initialization for 'wm8711_spi_driver')
> sound/soc/codecs/wm8711.c:571: error: unknown field 'probe' specified in initializer
> sound/soc/codecs/wm8711.c:571: warning: excess elements in struct initializer
> sound/soc/codecs/wm8711.c:571: warning: (near initialization for 'wm8711_spi_driver')
> sound/soc/codecs/wm8711.c:572: error: unknown field 'suspend' specified in initializer
> sound/soc/codecs/wm8711.c:572: warning: excess elements in struct initializer
> sound/soc/codecs/wm8711.c:572: warning: (near initialization for 'wm8711_spi_driver')
> sound/soc/codecs/wm8711.c:573: error: unknown field 'resume' specified in initializer
> sound/soc/codecs/wm8711.c:573: warning: excess elements in struct initializer
> sound/soc/codecs/wm8711.c:573: warning: (near initialization for 'wm8711_spi_driver')
> sound/soc/codecs/wm8711.c:574: error: unknown field 'remove' specified in initializer
> sound/soc/codecs/wm8711.c:574: warning: excess elements in struct initializer
> sound/soc/codecs/wm8711.c:574: warning: (near initialization for 'wm8711_spi_driver')
> sound/soc/codecs/wm8711.c: In function 'wm8711_modinit':
> sound/soc/codecs/wm8711.c:635: error: implicit declaration of function 'spi_register_driver'
> sound/soc/codecs/wm8711.c:635: error: 'wm8731_spi_driver' undeclared (first use in this function)
> sound/soc/codecs/wm8711.c:635: error: (Each undeclared identifier is reported only once
> sound/soc/codecs/wm8711.c:635: error: for each function it appears in.)
> sound/soc/codecs/wm8711.c: In function 'wm8711_exit':
> sound/soc/codecs/wm8711.c:651: error: implicit declaration of function 'spi_unregister_driver'
> sound/soc/codecs/wm8711.c:651: error: 'wm8731_spi_driver' undeclared (first use in this function)
> 
> Caused by commit 08aff8cd7a8568588d460c4bf8875a492d430314 ("ASoC: Add SPI
> support to WM8711").

I overlooked this since SPI was disabled on my test build.
Now fixed in sound git tree.


thanks,

Takashi

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

On Thu, 01 Oct 2009 08:45:40 +0200 Takashi Iwai <tiwai@suse.de> wrote:
> 
> I overlooked this since SPI was disabled on my test build.
> Now fixed in sound git tree.

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

Hi Takashi,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

sound/core/oss/mixer_oss.c: In function 'snd_mixer_oss_proc_write':
sound/core/oss/mixer_oss.c:1168: error: implicit declaration of function 'prinkt'
sound/core/seq/seq_device.c: In function 'snd_seq_device_register_driver':
sound/core/seq/seq_device.c:327: error: implicit declaration of function 'prinkt'

Caused by commit 36ce99c1dcab2978fc1900f19b431adedd8f99f6 ("ALSA: Add
debug module option").

I have used the version of the sound tree from next-20090827 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 28 Aug 2009 11:23:39 +1000,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> sound/core/oss/mixer_oss.c: In function 'snd_mixer_oss_proc_write':
> sound/core/oss/mixer_oss.c:1168: error: implicit declaration of function 'prinkt'
> sound/core/seq/seq_device.c: In function 'snd_seq_device_register_driver':
> sound/core/seq/seq_device.c:327: error: implicit declaration of function 'prinkt'
> 
> Caused by commit 36ce99c1dcab2978fc1900f19b431adedd8f99f6 ("ALSA: Add
> debug module option").
> 
> I have used the version of the sound tree from next-20090827 for today.

Fixed this typo now.  Sorry for inconvenience.


Takashi

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Hi Takashi,

On Fri, 28 Aug 2009 07:37:31 +0200 Takashi Iwai <tiwai@suse.de> wrote:
>
> Fixed this typo now.  Sorry for inconvenience.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/soc/codecs/ad1938.c: In function 'ad1938_spi_probe':
sound/soc/codecs/ad1938.c:423: error: 'struct device' has no member named 'driver_data'
sound/soc/codecs/ad1938.c: In function 'ad1938_spi_remove':
sound/soc/codecs/ad1938.c:430: error: 'struct device' has no member named 'driver_data'

Caused by commit 1274738d85d0e25c4f82d83f50a6bcbe2397e9ea ("ASoC: new
ad1938 codec driver based on asoc") interacting with commit
2e34003ff6237e2216396d61dc8b32ea5959de80 ("Driver core: move
dev_get/set_drvdata to drivers/base/dd.c") from the driver-core.current
tree (which will, I assume, be sent to Linus shortly - right, Greg?).

New drivers need to use the (existing) API's dev_{set,get}_drvdata().

I have used the version of the sound tree from next-20090716 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Greg KH]

On Fri, Jul 17, 2009 at 11:29:35AM +1000, Stephen Rothwell wrote:
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/soc/codecs/ad1938.c: In function 'ad1938_spi_probe':
> sound/soc/codecs/ad1938.c:423: error: 'struct device' has no member named 'driver_data'
> sound/soc/codecs/ad1938.c: In function 'ad1938_spi_remove':
> sound/soc/codecs/ad1938.c:430: error: 'struct device' has no member named 'driver_data'
> 
> Caused by commit 1274738d85d0e25c4f82d83f50a6bcbe2397e9ea ("ASoC: new
> ad1938 codec driver based on asoc") interacting with commit
> 2e34003ff6237e2216396d61dc8b32ea5959de80 ("Driver core: move
> dev_get/set_drvdata to drivers/base/dd.c") from the driver-core.current
> tree (which will, I assume, be sent to Linus shortly - right, Greg?).

It turned out to be "too late" to make the change, I missed the -rc2
window, so it will be a .32 thing.

I'll move it from my driver-core.current to my driver-core tree to clear
up any confusion.

But yes, the apis should be used instead of directly accessing the
fields.

thanks,

greg k-h

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

Hi Greg,

On Thu, 16 Jul 2009 21:56:20 -0700 Greg KH <greg@kroah.com> wrote:
>
> It turned out to be "too late" to make the change, I missed the -rc2
> window, so it will be a .32 thing.
> 
> I'll move it from my driver-core.current to my driver-core tree to clear
> up any confusion.

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Greg KH]

On Fri, Jul 17, 2009 at 03:32:43PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Thu, 16 Jul 2009 21:56:20 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > It turned out to be "too late" to make the change, I missed the -rc2
> > window, so it will be a .32 thing.
> > 
> > I'll move it from my driver-core.current to my driver-core tree to clear
> > up any confusion.
> 
> OK, thanks.

Now done.

thanks,

greg k-h

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 17 Jul 2009 11:29:35 +1000,
Stephen Rothwell wrote:
> 
> [1  <text/plain; US-ASCII (quoted-printable)>]
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/soc/codecs/ad1938.c: In function 'ad1938_spi_probe':
> sound/soc/codecs/ad1938.c:423: error: 'struct device' has no member named 'driver_data'
> sound/soc/codecs/ad1938.c: In function 'ad1938_spi_remove':
> sound/soc/codecs/ad1938.c:430: error: 'struct device' has no member named 'driver_data'
> 
> Caused by commit 1274738d85d0e25c4f82d83f50a6bcbe2397e9ea ("ASoC: new
> ad1938 codec driver based on asoc") interacting with commit
> 2e34003ff6237e2216396d61dc8b32ea5959de80 ("Driver core: move
> dev_get/set_drvdata to drivers/base/dd.c") from the driver-core.current
> tree (which will, I assume, be sent to Linus shortly - right, Greg?).
> 
> New drivers need to use the (existing) API's dev_{set,get}_drvdata().

Yep.  Fixed now.


> I have used the version of the sound tree from next-20090716 for today.


thanks,

Takashi

Re: linux-next: sound tree build failure

[Mark Brown]

On Fri, Jul 17, 2009 at 11:29:35AM +1000, Stephen Rothwell wrote:

> Caused by commit 1274738d85d0e25c4f82d83f50a6bcbe2397e9ea ("ASoC: new
> ad1938 codec driver based on asoc") interacting with commit
> 2e34003ff6237e2216396d61dc8b32ea5959de80 ("Driver core: move
> dev_get/set_drvdata to drivers/base/dd.c") from the driver-core.current
> tree (which will, I assume, be sent to Linus shortly - right, Greg?).

I've fixed this.

> New drivers need to use the (existing) API's dev_{set,get}_drvdata().

Incidentally, is there any great reason not to have the equivalent thing
for platform data?  I can supply a patch.

>From 91a0351b2d1e86f421ee9c95d07136f648d2da06 Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Fri, 17 Jul 2009 10:18:14 +0100
Subject: [PATCH] ASoC: Use driverdata accessors in ad1938

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 sound/soc/codecs/ad1938.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/ad1938.c b/sound/soc/codecs/ad1938.c
index 3dc8091..5a7d00c 100644
--- a/sound/soc/codecs/ad1938.c
+++ b/sound/soc/codecs/ad1938.c
@@ -420,14 +420,14 @@ static int __devinit ad1938_spi_probe(struct spi_device *spi)
 	codec->control_data = spi;
 	codec->dev = &spi->dev;
 
-	spi->dev.driver_data = ad1938;
+	dev_set_drvdata(&spi->dev, ad1938);
 
 	return ad1938_register(ad1938);
 }
 
 static int __devexit ad1938_spi_remove(struct spi_device *spi)
 {
-	struct ad1938_priv *ad1938 = spi->dev.driver_data;
+	struct ad1938_priv *ad1938 = dev_get_drvdata(&spi->dev);
 
 	ad1938_unregister(ad1938);
 	return 0;
-- 
1.6.3.3

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 17 Jul 2009 10:28:25 +0100,
Mark Brown wrote:
> 
> On Fri, Jul 17, 2009 at 11:29:35AM +1000, Stephen Rothwell wrote:
> 
> > Caused by commit 1274738d85d0e25c4f82d83f50a6bcbe2397e9ea ("ASoC: new
> > ad1938 codec driver based on asoc") interacting with commit
> > 2e34003ff6237e2216396d61dc8b32ea5959de80 ("Driver core: move
> > dev_get/set_drvdata to drivers/base/dd.c") from the driver-core.current
> > tree (which will, I assume, be sent to Linus shortly - right, Greg?).
> 
> I've fixed this.

Oh, it was already fixed this morning.
I couldn't send a notify mail just because my server crashed after
pushing the tree...   And rebooted now :)


Takashi

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Hi Takashi,

Today's linux-next build (powerpc allyesconfig) failed like this:

sound/soc/codecs/twl4030.c: In function 'twl4030_read_reg_cache':
sound/soc/codecs/twl4030.c:152: error: 'cache' undeclared (first use in this function)

Caused by commit 16a30fbb0d3aa4ee829a2dd3d0e314e2b5ae96a9 ("ASoC:
TWL4030: Use reg_cache in twl4030_init_chip").

I reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Thu, 4 Jun 2009 17:33:42 +1000,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> sound/soc/codecs/twl4030.c: In function 'twl4030_read_reg_cache':
> sound/soc/codecs/twl4030.c:152: error: 'cache' undeclared (first use in this function)
> 
> Caused by commit 16a30fbb0d3aa4ee829a2dd3d0e314e2b5ae96a9 ("ASoC:
> TWL4030: Use reg_cache in twl4030_init_chip").
> 
> I reverted that commit for today.

Thanks.  It's likely a cut-and-paste error in that commit.
I fixed now on sound git tree.


Takashi

Re: linux-next: sound tree build failure

[Peter Ujfalusi]

On Thursday 04 June 2009 11:03:07 ext Takashi Iwai wrote:
> At Thu, 4 Jun 2009 17:33:42 +1000,
>
> Stephen Rothwell wrote:
> > Hi Takashi,
> >
> > Today's linux-next build (powerpc allyesconfig) failed like this:
> >
> > sound/soc/codecs/twl4030.c: In function 'twl4030_read_reg_cache':
> > sound/soc/codecs/twl4030.c:152: error: 'cache' undeclared (first use in
> > this function)
> >
> > Caused by commit 16a30fbb0d3aa4ee829a2dd3d0e314e2b5ae96a9 ("ASoC:
> > TWL4030: Use reg_cache in twl4030_init_chip").
> >
> > I reverted that commit for today.
>
> Thanks.  It's likely a cut-and-paste error in that commit.
> I fixed now on sound git tree.

Yes, it was a cut-and-paste error. I have also made the patch to fix it.
I'll not send it, thanks Takashi for fixing it.

It is so embarrassing, since this is the second time that my patch broke the 
linux-next build.
I'll try to be even more careful in the future.

Again, sorry about this.

>
> Takashi

-- 
Péter

Re: linux-next: sound tree build failure

[Mark Brown]

On Thu, Jun 04, 2009 at 10:03:07AM +0200, Takashi Iwai wrote:

> Thanks.  It's likely a cut-and-paste error in that commit.
> I fixed now on sound git tree.

Thanks for sorting this.

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

Hi Takashi,

Today's linux-next build (sparc64 allmodconfig) failed like this:

sound/pci/ctxfi/cthw20k2.c:1217:3: error: #error "Don't support 8k-page!"

Caused by commit 8cc72361481f00253f1e468ade5795427386d593 ("ALSA: SB X-Fi
driver merge").  I assume that this driver needs better Kconfig
protection.  Maybe test for CONFIG_SPARC64_PAGE_SIZE_8KB or something.
Does this driver support other pages sizes (16k, 64k, 256k)?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Thu, 21 May 2009 00:31:45 +1000,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (sparc64 allmodconfig) failed like this:
> 
> sound/pci/ctxfi/cthw20k2.c:1217:3: error: #error "Don't support 8k-page!"
> 
> Caused by commit 8cc72361481f00253f1e468ade5795427386d593 ("ALSA: SB X-Fi
> driver merge").  I assume that this driver needs better Kconfig
> protection.  Maybe test for CONFIG_SPARC64_PAGE_SIZE_8KB or something.
> Does this driver support other pages sizes (16k, 64k, 256k)?

Likely not.  I'm going to fix and clean up the buffer handling of this
driver later, but first I need to get a hardware to test :)

Meanwhile, I'll add Kconfig dependency to x86 so that it won't be
built on other architectures (which haven't been tested anyway).


thanks,

Takashi

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Hi Takashi,

On Wed, 20 May 2009 16:46:45 +0200 Takashi Iwai <tiwai@suse.de> wrote:
>
> Meanwhile, I'll add Kconfig dependency to x86 so that it won't be
> built on other architectures (which haven't been tested anyway).

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Thu, 21 May 2009 00:59:49 +1000,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> On Wed, 20 May 2009 16:46:45 +0200 Takashi Iwai <tiwai@suse.de> wrote:
> >
> > Meanwhile, I'll add Kconfig dependency to x86 so that it won't be
> > built on other architectures (which haven't been tested anyway).
> 
> OK, thanks.

Fixed and pushed now.

Please pull the sound tree again if possible (or do it tomorrow :)


thanks,

Takashi

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

Hi Takashi,

Today's linux-next build (powerpc allyesconfig) failed like this:

sound/soc/codecs/twl4030.c:1400: warning: braces around scalar initializer
sound/soc/codecs/twl4030.c:1400: warning: (near initialization for 'twl4030_dai.ops')
sound/soc/codecs/twl4030.c:1401: error: field name not in record or union initializer
sound/soc/codecs/twl4030.c:1401: error: (near initialization for 'twl4030_dai.ops')
sound/soc/codecs/twl4030.c:1401: warning: initialization from incompatible pointer type
sound/soc/codecs/twl4030.c:1402: error: field name not in record or union initializer
sound/soc/codecs/twl4030.c:1402: error: (near initialization for 'twl4030_dai.ops')
sound/soc/codecs/twl4030.c:1402: warning: excess elements in scalar initializer
sound/soc/codecs/twl4030.c:1402: warning: (near initialization for 'twl4030_dai.ops')
sound/soc/codecs/twl4030.c:1403: error: field name not in record or union initializer
sound/soc/codecs/twl4030.c:1403: error: (near initialization for 'twl4030_dai.ops')
sound/soc/codecs/twl4030.c:1403: warning: excess elements in scalar initializer
sound/soc/codecs/twl4030.c:1403: warning: (near initialization for 'twl4030_dai.ops')

Caused by commit 6335d05548eece40092000aa91b64a50310d69d5 ("ASoC: make
ops a pointer in 'struct snd_soc_dai'") which missed a conversion (or a
later merge missed the fixup) ...

I have reverted commit 65ec1cd1e2c6228752d2f167b01e6d291014d249 ("ASoC:
Merge dai_ops factor out") (which merged in the above commit) for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Mon, 16 Mar 2009 21:39:32 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> sound/soc/codecs/twl4030.c:1400: warning: braces around scalar initializer
> sound/soc/codecs/twl4030.c:1400: warning: (near initialization for 'twl4030_dai.ops')
> sound/soc/codecs/twl4030.c:1401: error: field name not in record or union initializer
> sound/soc/codecs/twl4030.c:1401: error: (near initialization for 'twl4030_dai.ops')
> sound/soc/codecs/twl4030.c:1401: warning: initialization from incompatible pointer type
> sound/soc/codecs/twl4030.c:1402: error: field name not in record or union initializer
> sound/soc/codecs/twl4030.c:1402: error: (near initialization for 'twl4030_dai.ops')
> sound/soc/codecs/twl4030.c:1402: warning: excess elements in scalar initializer
> sound/soc/codecs/twl4030.c:1402: warning: (near initialization for 'twl4030_dai.ops')
> sound/soc/codecs/twl4030.c:1403: error: field name not in record or union initializer
> sound/soc/codecs/twl4030.c:1403: error: (near initialization for 'twl4030_dai.ops')
> sound/soc/codecs/twl4030.c:1403: warning: excess elements in scalar initializer
> sound/soc/codecs/twl4030.c:1403: warning: (near initialization for 'twl4030_dai.ops')
> 
> Caused by commit 6335d05548eece40092000aa91b64a50310d69d5 ("ASoC: make
> ops a pointer in 'struct snd_soc_dai'") which missed a conversion (or a
> later merge missed the fixup) ...

Yep, I found a few other issues with that patch, too...

> I have reverted commit 65ec1cd1e2c6228752d2f167b01e6d291014d249 ("ASoC:
> Merge dai_ops factor out") (which merged in the above commit) for today.

Thanks.  Will fix up later.


Takashi

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

Hi Takashi,

On Mon, 16 Mar 2009 11:41:21 +0100 Takashi Iwai <tiwai@suse.de> wrote:
>
> Thanks.  Will fix up later.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Mark Brown]

On Mon, Mar 16, 2009 at 09:39:32PM +1100, Stephen Rothwell wrote:

> Today's linux-next build (powerpc allyesconfig) failed like this:

> sound/soc/codecs/twl4030.c:1400: warning: braces around scalar initializer
> sound/soc/codecs/twl4030.c:1400: warning: (near initialization for 'twl4030_dai.ops')

I'll push a fix for this later today.

Re: linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

Hi Mark,

On Mon, 16 Mar 2009 10:59:02 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Mon, Mar 16, 2009 at 09:39:32PM +1100, Stephen Rothwell wrote:
> 
> > Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> > sound/soc/codecs/twl4030.c:1400: warning: braces around scalar initializer
> > sound/soc/codecs/twl4030.c:1400: warning: (near initialization for 'twl4030_dai.ops')
> 
> I'll push a fix for this later today.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/soc/codecs/wm8753.c: In function 'wm8753_probe':
sound/soc/codecs/wm8753.c:1577: error: implicit declaration of function 'wm8753_add_controls'

Probably introduced by commit c2bac1606a937d4700f8fdd8e051a4c49593c41b
("ASoC: Convert WM8753 to register via normal device probe").

I have dropped the sound tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Thu, 26 Feb 2009 14:07:46 +1100,
Stephen Rothwell wrote:
> 
> [1  <text/plain; US-ASCII (quoted-printable)>]
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/soc/codecs/wm8753.c: In function 'wm8753_probe':
> sound/soc/codecs/wm8753.c:1577: error: implicit declaration of function 'wm8753_add_controls'
> 
> Probably introduced by commit c2bac1606a937d4700f8fdd8e051a4c49593c41b
> ("ASoC: Convert WM8753 to register via normal device probe").

Indeed it is.  Sorry, I skipped the build test yesterday after this
merge.

I think the patch below fixes the problem, but as I'm not sure where is
Mark's intention, I'd like to let him checking.


thanks,

Takashi

---
diff --git a/sound/soc/codecs/wm8753.c b/sound/soc/codecs/wm8753.c
index 2241204..7f353e9 100644
--- a/sound/soc/codecs/wm8753.c
+++ b/sound/soc/codecs/wm8753.c
@@ -1574,7 +1574,8 @@ static int wm8753_probe(struct platform_device *pdev)
 		goto pcm_err;
 	}
 
-	wm8753_add_controls(codec);
+	snd_soc_add_controls(codec, wm8753_snd_controls,
+			     ARRAY_SIZE(wm8753_snd_controls));
 	wm8753_add_widgets(codec);
 	ret = snd_soc_init_card(socdev);
 	if (ret < 0) {

Re: linux-next: sound tree build failure

[Mark Brown]

On Thu, Feb 26, 2009 at 09:46:18AM +0100, Takashi Iwai wrote:

> I think the patch below fixes the problem, but as I'm not sure where is
> Mark's intention, I'd like to let him checking.

Yes, that's it, thanks - sorry, I could've sworn I'd done a mainline
build test.

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Thu, 26 Feb 2009 10:25:48 +0000,
Mark Brown wrote:
> 
> On Thu, Feb 26, 2009 at 09:46:18AM +0100, Takashi Iwai wrote:
> 
> > I think the patch below fixes the problem, but as I'm not sure where is
> > Mark's intention, I'd like to let him checking.
> 
> Yes, that's it, thanks - sorry, I could've sworn I'd done a mainline
> build test.

OK, committed now.  Thanks.


Takashi

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/soc/codecs/cs4270.c:152: error: expected identifier or '(' before '[' token
sound/soc/codecs/cs4270.c: In function 'cs4270_set_dai_sysclk':
sound/soc/codecs/cs4270.c:203: error: 'cs4270_mode_ratios' undeclared (first use in this function)
sound/soc/codecs/cs4270.c:203: error: (Each undeclared identifier is reported only once
sound/soc/codecs/cs4270.c:203: error: for each function it appears in.)
sound/soc/codecs/cs4270.c:203: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:203: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:203: error: size of array 'type name' is negative
sound/soc/codecs/cs4270.c: In function 'cs4270_hw_params':
sound/soc/codecs/cs4270.c:387: error: 'cs4270_mode_ratios' undeclared (first use in this function)
sound/soc/codecs/cs4270.c:387: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:387: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:387: error: size of array 'type name' is negative
sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:392: error: size of array 'type name' is negative
sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:392: error: size of array 'type name' is negative
sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
sound/soc/codecs/cs4270.c:392: error: size of array 'type name' is negative

Caused by commit ff7bf02f630ae93cad4feda0f6a5a19b25a5019a ("ASoC: fix
documentation in CS4270 codec driver") which does somewhat more than fix
documentation.  It clearly wasn't even build tested.

I have dropped the sound tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Tue, 3 Feb 2009 14:10:11 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/soc/codecs/cs4270.c:152: error: expected identifier or '(' before '[' token
> sound/soc/codecs/cs4270.c: In function 'cs4270_set_dai_sysclk':
> sound/soc/codecs/cs4270.c:203: error: 'cs4270_mode_ratios' undeclared (first use in this function)
> sound/soc/codecs/cs4270.c:203: error: (Each undeclared identifier is reported only once
> sound/soc/codecs/cs4270.c:203: error: for each function it appears in.)
> sound/soc/codecs/cs4270.c:203: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:203: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:203: error: size of array 'type name' is negative
> sound/soc/codecs/cs4270.c: In function 'cs4270_hw_params':
> sound/soc/codecs/cs4270.c:387: error: 'cs4270_mode_ratios' undeclared (first use in this function)
> sound/soc/codecs/cs4270.c:387: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:387: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:387: error: size of array 'type name' is negative
> sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:392: error: size of array 'type name' is negative
> sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:392: error: size of array 'type name' is negative
> sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:392: warning: type defaults to 'int' in declaration of 'type name'
> sound/soc/codecs/cs4270.c:392: error: size of array 'type name' is negative
> 
> Caused by commit ff7bf02f630ae93cad4feda0f6a5a19b25a5019a ("ASoC: fix
> documentation in CS4270 codec driver") which does somewhat more than fix
> documentation.  It clearly wasn't even build tested.

Fixed now.


thanks,

Takashi

Re: linux-next: sound tree build failure

[Timur Tabi]

Takashi Iwai wrote:

>> Caused by commit ff7bf02f630ae93cad4feda0f6a5a19b25a5019a ("ASoC: fix
>> documentation in CS4270 codec driver") which does somewhat more than fix
>> documentation.  It clearly wasn't even build tested.

Yes, I apologize for that.  I thought I tested it, but I guess I either forgot
or got confused.

-- 
Timur Tabi
Linux kernel developer at Freescale

linux-next: sound tree build failure

[Stephen Rothwell]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/core/hrtimer.c: In function 'snd_hrtimer_open':
sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)

An interaction between commit bbaf5e97337287479eb78dbc3822d9560bbfd2e2
("ALSA: Add hrtimer backend for ALSA timer interface") from the sound
tree and commit ca109491f612aab5c8152207631c0444f63da97f ("hrtimer:
removing all ur callback modes") from the timers tree.

I have added the below fixup for the merge and can carry it as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 15 Dec 2008 15:38:14 +1100
Subject: [PATCH] sound: fixup for timers tree interaction

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 sound/core/hrtimer.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/sound/core/hrtimer.c b/sound/core/hrtimer.c
index c1d2859..34c7d48 100644
--- a/sound/core/hrtimer.c
+++ b/sound/core/hrtimer.c
@@ -57,7 +57,6 @@ static int snd_hrtimer_open(struct snd_timer *t)
 		return -ENOMEM;
 	hrtimer_init(&stime->hrt, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	stime->timer = t;
-	stime->hrt.cb_mode = HRTIMER_CB_IRQSAFE_UNLOCKED;
 	stime->hrt.function = snd_hrtimer_callback;
 	t->private_data = stime;
 	return 0;
-- 
1.6.0.5

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Mon, 15 Dec 2008 15:43:01 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/core/hrtimer.c: In function 'snd_hrtimer_open':
> sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
> sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)
> 
> An interaction between commit bbaf5e97337287479eb78dbc3822d9560bbfd2e2
> ("ALSA: Add hrtimer backend for ALSA timer interface") from the sound
> tree and commit ca109491f612aab5c8152207631c0444f63da97f ("hrtimer:
> removing all ur callback modes") from the timers tree.
> 
> I have added the below fixup for the merge and can carry it as necessary.

Thanks, the fix must be correct.

I'm not sure what I should do.  Putting this fix only for linux-next
might be a fix, but this wouldn't work if the affecting patch is
changed or dropped.

If you can keep this one-liner in your tree, it'd be helpful.


Takashi


> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 15 Dec 2008 15:38:14 +1100
> Subject: [PATCH] sound: fixup for timers tree interaction
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  sound/core/hrtimer.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/sound/core/hrtimer.c b/sound/core/hrtimer.c
> index c1d2859..34c7d48 100644
> --- a/sound/core/hrtimer.c
> +++ b/sound/core/hrtimer.c
> @@ -57,7 +57,6 @@ static int snd_hrtimer_open(struct snd_timer *t)
>  		return -ENOMEM;
>  	hrtimer_init(&stime->hrt, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>  	stime->timer = t;
> -	stime->hrt.cb_mode = HRTIMER_CB_IRQSAFE_UNLOCKED;
>  	stime->hrt.function = snd_hrtimer_callback;
>  	t->private_data = stime;
>  	return 0;
> -- 
> 1.6.0.5
> 

Re: linux-next: sound tree build failure

[Ingo Molnar]

* Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 15 Dec 2008 15:43:01 +1100,
> Stephen Rothwell wrote:
> > 
> > Hi Takashi,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > sound/core/hrtimer.c: In function 'snd_hrtimer_open':
> > sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
> > sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)
> > 
> > An interaction between commit bbaf5e97337287479eb78dbc3822d9560bbfd2e2
> > ("ALSA: Add hrtimer backend for ALSA timer interface") from the sound
> > tree and commit ca109491f612aab5c8152207631c0444f63da97f ("hrtimer:
> > removing all ur callback modes") from the timers tree.
> > 
> > I have added the below fixup for the merge and can carry it as necessary.
> 
> Thanks, the fix must be correct.
> 
> I'm not sure what I should do.  Putting this fix only for linux-next 
> might be a fix, but this wouldn't work if the affecting patch is changed 
> or dropped.
> 
> If you can keep this one-liner in your tree, it'd be helpful.

if it becomes a logistical problem, there's a Git approach to resolving 
this: we are keeping those bits separate in tip/timers/hrtimers, so you 
could pull that into the sound tree. Your sound tree would be fully 
combinable in linux-next.

	Ingo

-------------->
The latest timers/hrtimers git tree can be pulled from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git timers/hrtimers

 Thanks,

	Ingo

------------------>
Peter Zijlstra (3):
      hrtimer: removing all ur callback modes
      hrtimer: removing all ur callback modes, fix hotplug
      hrtimer: removing all ur callback modes, fix


 drivers/input/touchscreen/ads7846.c |    4 +-
 include/linux/hrtimer.h             |   34 +----
 include/linux/interrupt.h           |    3 -
 kernel/hrtimer.c                    |  327 ++++++-----------------------------
 kernel/sched.c                      |    2 -
 kernel/time/ntp.c                   |    4 +-
 kernel/time/tick-sched.c            |    1 -
 kernel/trace/trace_sysprof.c        |    1 -
 sound/drivers/pcsp/pcsp.c           |    1 -
 9 files changed, 62 insertions(+), 315 deletions(-)

diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index b9b7fc6..e1ece89 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -697,7 +697,7 @@ static enum hrtimer_restart ads7846_timer(struct hrtimer *handle)
 	struct ads7846	*ts = container_of(handle, struct ads7846, timer);
 	int		status = 0;
 
-	spin_lock_irq(&ts->lock);
+	spin_lock(&ts->lock);
 
 	if (unlikely(!get_pendown_state(ts) ||
 		     device_suspended(&ts->spi->dev))) {
@@ -728,7 +728,7 @@ static enum hrtimer_restart ads7846_timer(struct hrtimer *handle)
 			dev_err(&ts->spi->dev, "spi_async --> %d\n", status);
 	}
 
-	spin_unlock_irq(&ts->lock);
+	spin_unlock(&ts->lock);
 	return HRTIMER_NORESTART;
 }
 
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 3eba438..bd37078 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -43,26 +43,6 @@ enum hrtimer_restart {
 };
 
 /*
- * hrtimer callback modes:
- *
- *	HRTIMER_CB_SOFTIRQ:		Callback must run in softirq context
- *	HRTIMER_CB_IRQSAFE_PERCPU:	Callback must run in hardirq context
- *					Special mode for tick emulation and
- *					scheduler timer. Such timers are per
- *					cpu and not allowed to be migrated on
- *					cpu unplug.
- *	HRTIMER_CB_IRQSAFE_UNLOCKED:	Callback should run in hardirq context
- *					with timer->base lock unlocked
- *					used for timers which call wakeup to
- *					avoid lock order problems with rq->lock
- */
-enum hrtimer_cb_mode {
-	HRTIMER_CB_SOFTIRQ,
-	HRTIMER_CB_IRQSAFE_PERCPU,
-	HRTIMER_CB_IRQSAFE_UNLOCKED,
-};
-
-/*
  * Values to track state of the timer
  *
  * Possible states:
@@ -70,7 +50,6 @@ enum hrtimer_cb_mode {
  * 0x00		inactive
  * 0x01		enqueued into rbtree
  * 0x02		callback function running
- * 0x04		callback pending (high resolution mode)
  *
  * Special cases:
  * 0x03		callback function running and enqueued
@@ -92,8 +71,7 @@ enum hrtimer_cb_mode {
 #define HRTIMER_STATE_INACTIVE	0x00
 #define HRTIMER_STATE_ENQUEUED	0x01
 #define HRTIMER_STATE_CALLBACK	0x02
-#define HRTIMER_STATE_PENDING	0x04
-#define HRTIMER_STATE_MIGRATE	0x08
+#define HRTIMER_STATE_MIGRATE	0x04
 
 /**
  * struct hrtimer - the basic hrtimer structure
@@ -109,8 +87,6 @@ enum hrtimer_cb_mode {
  * @function:	timer expiry callback function
  * @base:	pointer to the timer base (per cpu and per clock)
  * @state:	state information (See bit values above)
- * @cb_mode:	high resolution timer feature to select the callback execution
- *		 mode
  * @cb_entry:	list head to enqueue an expired timer into the callback list
  * @start_site:	timer statistics field to store the site where the timer
  *		was started
@@ -129,7 +105,6 @@ struct hrtimer {
 	struct hrtimer_clock_base	*base;
 	unsigned long			state;
 	struct list_head		cb_entry;
-	enum hrtimer_cb_mode		cb_mode;
 #ifdef CONFIG_TIMER_STATS
 	int				start_pid;
 	void				*start_site;
@@ -188,15 +163,11 @@ struct hrtimer_clock_base {
  * @check_clocks:	Indictator, when set evaluate time source and clock
  *			event devices whether high resolution mode can be
  *			activated.
- * @cb_pending:		Expired timers are moved from the rbtree to this
- *			list in the timer interrupt. The list is processed
- *			in the softirq.
  * @nr_events:		Total number of timer interrupt events
  */
 struct hrtimer_cpu_base {
 	spinlock_t			lock;
 	struct hrtimer_clock_base	clock_base[HRTIMER_MAX_CLOCK_BASES];
-	struct list_head		cb_pending;
 #ifdef CONFIG_HIGH_RES_TIMERS
 	ktime_t				expires_next;
 	int				hres_active;
@@ -404,8 +375,7 @@ static inline int hrtimer_active(const struct hrtimer *timer)
  */
 static inline int hrtimer_is_queued(struct hrtimer *timer)
 {
-	return timer->state &
-		(HRTIMER_STATE_ENQUEUED | HRTIMER_STATE_PENDING);
+	return timer->state & HRTIMER_STATE_ENQUEUED;
 }
 
 /*
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index f58a0cf..d6210a9 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -251,9 +251,6 @@ enum
 	BLOCK_SOFTIRQ,
 	TASKLET_SOFTIRQ,
 	SCHED_SOFTIRQ,
-#ifdef CONFIG_HIGH_RES_TIMERS
-	HRTIMER_SOFTIRQ,
-#endif
 	RCU_SOFTIRQ, 	/* Preferable RCU should always be the last softirq */
 
 	NR_SOFTIRQS
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 47e6334..b741f85 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -442,22 +442,6 @@ static inline void debug_hrtimer_activate(struct hrtimer *timer) { }
 static inline void debug_hrtimer_deactivate(struct hrtimer *timer) { }
 #endif
 
-/*
- * Check, whether the timer is on the callback pending list
- */
-static inline int hrtimer_cb_pending(const struct hrtimer *timer)
-{
-	return timer->state & HRTIMER_STATE_PENDING;
-}
-
-/*
- * Remove a timer from the callback pending list
- */
-static inline void hrtimer_remove_cb_pending(struct hrtimer *timer)
-{
-	list_del_init(&timer->cb_entry);
-}
-
 /* High resolution timer related functions */
 #ifdef CONFIG_HIGH_RES_TIMERS
 
@@ -651,6 +635,8 @@ static inline void hrtimer_init_timer_hres(struct hrtimer *timer)
 {
 }
 
+static void __run_hrtimer(struct hrtimer *timer);
+
 /*
  * When High resolution timers are active, try to reprogram. Note, that in case
  * the state has HRTIMER_STATE_CALLBACK set, no reprogramming and no expiry
@@ -661,31 +647,14 @@ static inline int hrtimer_enqueue_reprogram(struct hrtimer *timer,
 					    struct hrtimer_clock_base *base)
 {
 	if (base->cpu_base->hres_active && hrtimer_reprogram(timer, base)) {
-
-		/* Timer is expired, act upon the callback mode */
-		switch(timer->cb_mode) {
-		case HRTIMER_CB_IRQSAFE_PERCPU:
-		case HRTIMER_CB_IRQSAFE_UNLOCKED:
-			/*
-			 * This is solely for the sched tick emulation with
-			 * dynamic tick support to ensure that we do not
-			 * restart the tick right on the edge and end up with
-			 * the tick timer in the softirq ! The calling site
-			 * takes care of this. Also used for hrtimer sleeper !
-			 */
-			debug_hrtimer_deactivate(timer);
-			return 1;
-		case HRTIMER_CB_SOFTIRQ:
-			/*
-			 * Move everything else into the softirq pending list !
-			 */
-			list_add_tail(&timer->cb_entry,
-				      &base->cpu_base->cb_pending);
-			timer->state = HRTIMER_STATE_PENDING;
-			return 1;
-		default:
-			BUG();
-		}
+		/*
+		 * XXX: recursion check?
+		 * hrtimer_forward() should round up with timer granularity
+		 * so that we never get into inf recursion here,
+		 * it doesn't do that though
+		 */
+		__run_hrtimer(timer);
+		return 1;
 	}
 	return 0;
 }
@@ -724,11 +693,6 @@ static int hrtimer_switch_to_hres(void)
 	return 1;
 }
 
-static inline void hrtimer_raise_softirq(void)
-{
-	raise_softirq(HRTIMER_SOFTIRQ);
-}
-
 #else
 
 static inline int hrtimer_hres_active(void) { return 0; }
@@ -747,7 +711,6 @@ static inline int hrtimer_reprogram(struct hrtimer *timer,
 {
 	return 0;
 }
-static inline void hrtimer_raise_softirq(void) { }
 
 #endif /* CONFIG_HIGH_RES_TIMERS */
 
@@ -890,10 +853,7 @@ static void __remove_hrtimer(struct hrtimer *timer,
 			     struct hrtimer_clock_base *base,
 			     unsigned long newstate, int reprogram)
 {
-	/* High res. callback list. NOP for !HIGHRES */
-	if (hrtimer_cb_pending(timer))
-		hrtimer_remove_cb_pending(timer);
-	else {
+	if (timer->state & HRTIMER_STATE_ENQUEUED) {
 		/*
 		 * Remove the timer from the rbtree and replace the
 		 * first entry pointer if necessary.
@@ -953,7 +913,7 @@ hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim, unsigned long delta_n
 {
 	struct hrtimer_clock_base *base, *new_base;
 	unsigned long flags;
-	int ret, raise;
+	int ret;
 
 	base = lock_hrtimer_base(timer, &flags);
 
@@ -988,26 +948,8 @@ hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim, unsigned long delta_n
 	enqueue_hrtimer(timer, new_base,
 			new_base->cpu_base == &__get_cpu_var(hrtimer_bases));
 
-	/*
-	 * The timer may be expired and moved to the cb_pending
-	 * list. We can not raise the softirq with base lock held due
-	 * to a possible deadlock with runqueue lock.
-	 */
-	raise = timer->state == HRTIMER_STATE_PENDING;
-
-	/*
-	 * We use preempt_disable to prevent this task from migrating after
-	 * setting up the softirq and raising it. Otherwise, if me migrate
-	 * we will raise the softirq on the wrong CPU.
-	 */
-	preempt_disable();
-
 	unlock_hrtimer_base(timer, &flags);
 
-	if (raise)
-		hrtimer_raise_softirq();
-	preempt_enable();
-
 	return ret;
 }
 EXPORT_SYMBOL_GPL(hrtimer_start_range_ns);
@@ -1192,75 +1134,6 @@ int hrtimer_get_res(const clockid_t which_clock, struct timespec *tp)
 }
 EXPORT_SYMBOL_GPL(hrtimer_get_res);
 
-static void run_hrtimer_pending(struct hrtimer_cpu_base *cpu_base)
-{
-	spin_lock_irq(&cpu_base->lock);
-
-	while (!list_empty(&cpu_base->cb_pending)) {
-		enum hrtimer_restart (*fn)(struct hrtimer *);
-		struct hrtimer *timer;
-		int restart;
-		int emulate_hardirq_ctx = 0;
-
-		timer = list_entry(cpu_base->cb_pending.next,
-				   struct hrtimer, cb_entry);
-
-		debug_hrtimer_deactivate(timer);
-		timer_stats_account_hrtimer(timer);
-
-		fn = timer->function;
-		/*
-		 * A timer might have been added to the cb_pending list
-		 * when it was migrated during a cpu-offline operation.
-		 * Emulate hardirq context for such timers.
-		 */
-		if (timer->cb_mode == HRTIMER_CB_IRQSAFE_PERCPU ||
-		    timer->cb_mode == HRTIMER_CB_IRQSAFE_UNLOCKED)
-			emulate_hardirq_ctx = 1;
-
-		__remove_hrtimer(timer, timer->base, HRTIMER_STATE_CALLBACK, 0);
-		spin_unlock_irq(&cpu_base->lock);
-
-		if (unlikely(emulate_hardirq_ctx)) {
-			local_irq_disable();
-			restart = fn(timer);
-			local_irq_enable();
-		} else
-			restart = fn(timer);
-
-		spin_lock_irq(&cpu_base->lock);
-
-		timer->state &= ~HRTIMER_STATE_CALLBACK;
-		if (restart == HRTIMER_RESTART) {
-			BUG_ON(hrtimer_active(timer));
-			/*
-			 * Enqueue the timer, allow reprogramming of the event
-			 * device
-			 */
-			enqueue_hrtimer(timer, timer->base, 1);
-		} else if (hrtimer_active(timer)) {
-			/*
-			 * If the timer was rearmed on another CPU, reprogram
-			 * the event device.
-			 */
-			struct hrtimer_clock_base *base = timer->base;
-
-			if (base->first == &timer->node &&
-			    hrtimer_reprogram(timer, base)) {
-				/*
-				 * Timer is expired. Thus move it from tree to
-				 * pending list again.
-				 */
-				__remove_hrtimer(timer, base,
-						 HRTIMER_STATE_PENDING, 0);
-				list_add_tail(&timer->cb_entry,
-					      &base->cpu_base->cb_pending);
-			}
-		}
-	}
-	spin_unlock_irq(&cpu_base->lock);
-}
-
 static void __run_hrtimer(struct hrtimer *timer)
 {
 	struct hrtimer_clock_base *base = timer->base;
@@ -1268,25 +1141,21 @@ static void __run_hrtimer(struct hrtimer *timer)
 	enum hrtimer_restart (*fn)(struct hrtimer *);
 	int restart;
 
+	WARN_ON(!irqs_disabled());
+
 	debug_hrtimer_deactivate(timer);
 	__remove_hrtimer(timer, base, HRTIMER_STATE_CALLBACK, 0);
 	timer_stats_account_hrtimer(timer);
-
 	fn = timer->function;
-	if (timer->cb_mode == HRTIMER_CB_IRQSAFE_PERCPU ||
-	    timer->cb_mode == HRTIMER_CB_IRQSAFE_UNLOCKED) {
-		/*
-		 * Used for scheduler timers, avoid lock inversion with
-		 * rq->lock and tasklist_lock.
-		 *
-		 * These timers are required to deal with enqueue expiry
-		 * themselves and are not allowed to migrate.
-		 */
-		spin_unlock(&cpu_base->lock);
-		restart = fn(timer);
-		spin_lock(&cpu_base->lock);
-	} else
-		restart = fn(timer);
+
+	/*
+	 * Because we run timers from hardirq context, there is no chance
+	 * they get migrated to another cpu, therefore its safe to unlock
+	 * the timer base.
+	 */
+	spin_unlock(&cpu_base->lock);
+	restart = fn(timer);
+	spin_lock(&cpu_base->lock);
 
 	/*
 	 * Note: We clear the CALLBACK bit after enqueue_hrtimer to avoid
@@ -1311,7 +1180,7 @@ void hrtimer_interrupt(struct clock_event_device *dev)
 	struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
 	struct hrtimer_clock_base *base;
 	ktime_t expires_next, now;
-	int i, raise = 0;
+	int i;
 
 	BUG_ON(!cpu_base->hres_active);
 	cpu_base->nr_events++;
@@ -1360,16 +1229,6 @@ void hrtimer_interrupt(struct clock_event_device *dev)
 				break;
 			}
 
-			/* Move softirq callbacks to the pending list */
-			if (timer->cb_mode == HRTIMER_CB_SOFTIRQ) {
-				__remove_hrtimer(timer, base,
-						 HRTIMER_STATE_PENDING, 0);
-				list_add_tail(&timer->cb_entry,
-					      &base->cpu_base->cb_pending);
-				raise = 1;
-				continue;
-			}
-
 			__run_hrtimer(timer);
 		}
 		spin_unlock(&cpu_base->lock);
@@ -1383,10 +1242,6 @@ void hrtimer_interrupt(struct clock_event_device *dev)
 		if (tick_program_event(expires_next, 0))
 			goto retry;
 	}
-
-	/* Raise softirq ? */
-	if (raise)
-		raise_softirq(HRTIMER_SOFTIRQ);
 }
 
 /**
@@ -1413,11 +1268,6 @@ void hrtimer_peek_ahead_timers(void)
 	local_irq_restore(flags);
 }
 
-static void run_hrtimer_softirq(struct softirq_action *h)
-{
-	run_hrtimer_pending(&__get_cpu_var(hrtimer_bases));
-}
-
 #endif	/* CONFIG_HIGH_RES_TIMERS */
 
 /*
@@ -1429,8 +1279,6 @@ static void run_hrtimer_softirq(struct softirq_action *h)
  */
 void hrtimer_run_pending(void)
 {
-	struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
-
 	if (hrtimer_hres_active())
 		return;
 
@@ -1444,8 +1292,6 @@ void hrtimer_run_pending(void)
 	 */
 	if (tick_check_oneshot_change(!hrtimer_is_hres_enabled()))
 		hrtimer_switch_to_hres();
-
-	run_hrtimer_pending(cpu_base);
 }
 
 /*
@@ -1482,14 +1328,6 @@ void hrtimer_run_queues(void)
 					hrtimer_get_expires_tv64(timer))
 				break;
 
-			if (timer->cb_mode == HRTIMER_CB_SOFTIRQ) {
-				__remove_hrtimer(timer, base,
-					HRTIMER_STATE_PENDING, 0);
-				list_add_tail(&timer->cb_entry,
-					&base->cpu_base->cb_pending);
-				continue;
-			}
-
 			__run_hrtimer(timer);
 		}
 		spin_unlock(&cpu_base->lock);
@@ -1516,9 +1354,6 @@ void hrtimer_init_sleeper(struct hrtimer_sleeper *sl, struct task_struct *task)
 {
 	sl->timer.function = hrtimer_wakeup;
 	sl->task = task;
-#ifdef CONFIG_HIGH_RES_TIMERS
-	sl->timer.cb_mode = HRTIMER_CB_IRQSAFE_UNLOCKED;
-#endif
 }
 
 static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode mode)
@@ -1655,18 +1490,16 @@ static void __cpuinit init_hrtimers_cpu(int cpu)
 	for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++)
 		cpu_base->clock_base[i].cpu_base = cpu_base;
 
-	INIT_LIST_HEAD(&cpu_base->cb_pending);
 	hrtimer_init_hres(cpu_base);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
 
-static int migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
-				struct hrtimer_clock_base *new_base, int dcpu)
+static void migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
+				struct hrtimer_clock_base *new_base)
 {
 	struct hrtimer *timer;
 	struct rb_node *node;
-	int raise = 0;
 
 	while ((node = rb_first(&old_base->active))) {
 		timer = rb_entry(node, struct hrtimer, node);
@@ -1674,18 +1507,6 @@ static int migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
 		debug_hrtimer_deactivate(timer);
 
 		/*
-		 * Should not happen. Per CPU timers should be
-		 * canceled _before_ the migration code is called
-		 */
-		if (timer->cb_mode == HRTIMER_CB_IRQSAFE_PERCPU) {
-			__remove_hrtimer(timer, old_base,
-					 HRTIMER_STATE_INACTIVE, 0);
-			WARN(1, "hrtimer (%p %p)active but cpu %d dead\n",
-			     timer, timer->function, dcpu);
-			continue;
-		}
-
-		/*
 		 * Mark it as STATE_MIGRATE not INACTIVE otherwise the
 		 * timer could be seen as !active and just vanish away
 		 * under us on another CPU
@@ -1693,69 +1514,34 @@ static int migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
 		__remove_hrtimer(timer, old_base, HRTIMER_STATE_MIGRATE, 0);
 		timer->base = new_base;
 		/*
-		 * Enqueue the timer. Allow reprogramming of the event device
+		 * Enqueue the timers on the new cpu, but do not reprogram 
+		 * the timer as that would enable a deadlock between
+		 * hrtimer_enqueue_reprogramm() running the timer and us still
+		 * holding a nested base lock.
+		 *
+		 * Instead we tickle the hrtimer interrupt after the migration
+		 * is done, which will run all expired timers and re-programm
+		 * the timer device.
 		 */
-		enqueue_hrtimer(timer, new_base, 1);
+		enqueue_hrtimer(timer, new_base, 0);
 
-#ifdef CONFIG_HIGH_RES_TIMERS
-		/*
-		 * Happens with high res enabled when the timer was
-		 * already expired and the callback mode is
-		 * HRTIMER_CB_IRQSAFE_UNLOCKED (hrtimer_sleeper). The
-		 * enqueue code does not move them to the soft irq
-		 * pending list for performance/latency reasons, but
-		 * in the migration state, we need to do that
-		 * otherwise we end up with a stale timer.
-		 */
-		if (timer->state == HRTIMER_STATE_MIGRATE) {
-			timer->state = HRTIMER_STATE_PENDING;
-			list_add_tail(&timer->cb_entry,
-				      &new_base->cpu_base->cb_pending);
-			raise = 1;
-		}
-#endif
 		/* Clear the migration state bit */
 		timer->state &= ~HRTIMER_STATE_MIGRATE;
 	}
-	return raise;
 }
 
-#ifdef CONFIG_HIGH_RES_TIMERS
-static int migrate_hrtimer_pending(struct hrtimer_cpu_base *old_base,
-				   struct hrtimer_cpu_base *new_base)
-{
-	struct hrtimer *timer;
-	int raise = 0;
-
-	while (!list_empty(&old_base->cb_pending)) {
-		timer = list_entry(old_base->cb_pending.next,
-				   struct hrtimer, cb_entry);
-
-		__remove_hrtimer(timer, timer->base, HRTIMER_STATE_PENDING, 0);
-		timer->base = &new_base->clock_base[timer->base->index];
-		list_add_tail(&timer->cb_entry, &new_base->cb_pending);
-		raise = 1;
-	}
-	return raise;
-}
-#else
-static int migrate_hrtimer_pending(struct hrtimer_cpu_base *old_base,
-				   struct hrtimer_cpu_base *new_base)
-{
-	return 0;
-}
-#endif
-
-static void migrate_hrtimers(int cpu)
+static int migrate_hrtimers(int scpu)
 {
 	struct hrtimer_cpu_base *old_base, *new_base;
-	int i, raise = 0;
+	int dcpu, i;
 
-	BUG_ON(cpu_online(cpu));
-	old_base = &per_cpu(hrtimer_bases, cpu);
+	BUG_ON(cpu_online(scpu));
+	old_base = &per_cpu(hrtimer_bases, scpu);
 	new_base = &get_cpu_var(hrtimer_bases);
 
-	tick_cancel_sched_timer(cpu);
+	dcpu = smp_processor_id();
+
+	tick_cancel_sched_timer(scpu);
 	/*
 	 * The caller is globally serialized and nobody else
 	 * takes two locks at once, deadlock is not possible.
@@ -1764,40 +1550,42 @@ static void migrate_hrtimers(int cpu)
 	spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING);
 
 	for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
-		if (migrate_hrtimer_list(&old_base->clock_base[i],
-					 &new_base->clock_base[i], cpu))
-			raise = 1;
+		migrate_hrtimer_list(&old_base->clock_base[i],
+				     &new_base->clock_base[i]);
 	}
 
-	if (migrate_hrtimer_pending(old_base, new_base))
-		raise = 1;
-
 	spin_unlock(&old_base->lock);
 	spin_unlock_irq(&new_base->lock);
 	put_cpu_var(hrtimer_bases);
 
-	if (raise)
-		hrtimer_raise_softirq();
+	return dcpu;
 }
+
+static void tickle_timers(void *arg)
+{
+	hrtimer_peek_ahead_timers();
+}
+
 #endif /* CONFIG_HOTPLUG_CPU */
 
 static int __cpuinit hrtimer_cpu_notify(struct notifier_block *self,
 					unsigned long action, void *hcpu)
 {
-	unsigned int cpu = (long)hcpu;
+	int dcpu, scpu = (long)hcpu;
 
 	switch (action) {
 
 	case CPU_UP_PREPARE:
 	case CPU_UP_PREPARE_FROZEN:
-		init_hrtimers_cpu(cpu);
+		init_hrtimers_cpu(scpu);
 		break;
 
 #ifdef CONFIG_HOTPLUG_CPU
 	case CPU_DEAD:
 	case CPU_DEAD_FROZEN:
-		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, &cpu);
-		migrate_hrtimers(cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, &scpu);
+		dcpu = migrate_hrtimers(scpu);
+		smp_call_function_single(dcpu, tickle_timers, NULL, 0);
 		break;
 #endif
 
@@ -1817,9 +1605,6 @@ void __init hrtimers_init(void)
 	hrtimer_cpu_notify(&hrtimers_nb, (unsigned long)CPU_UP_PREPARE,
 			  (void *)(long)smp_processor_id());
 	register_cpu_notifier(&hrtimers_nb);
-#ifdef CONFIG_HIGH_RES_TIMERS
-	open_softirq(HRTIMER_SOFTIRQ, run_hrtimer_softirq);
-#endif
 }
 
 /**
diff --git a/kernel/sched.c b/kernel/sched.c
index 9b1e793..5ac5e95 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -203,7 +203,6 @@ void init_rt_bandwidth(struct rt_bandwidth *rt_b, u64 period, u64 runtime)
 	hrtimer_init(&rt_b->rt_period_timer,
 			CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	rt_b->rt_period_timer.function = sched_rt_period_timer;
-	rt_b->rt_period_timer.cb_mode = HRTIMER_CB_IRQSAFE_UNLOCKED;
 }
 
 static inline int rt_bandwidth_enabled(void)
@@ -1139,7 +1138,6 @@ static void init_rq_hrtick(struct rq *rq)
 
 	hrtimer_init(&rq->hrtick_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	rq->hrtick_timer.function = hrtick;
-	rq->hrtick_timer.cb_mode = HRTIMER_CB_IRQSAFE_PERCPU;
 }
 #else	/* CONFIG_SCHED_HRTICK */
 static inline void hrtick_clear(struct rq *rq)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 8ff15e5..f5f793d 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -131,7 +131,7 @@ static enum hrtimer_restart ntp_leap_second(struct hrtimer *timer)
 {
 	enum hrtimer_restart res = HRTIMER_NORESTART;
 
-	write_seqlock_irq(&xtime_lock);
+	write_seqlock(&xtime_lock);
 
 	switch (time_state) {
 	case TIME_OK:
@@ -164,7 +164,7 @@ static enum hrtimer_restart ntp_leap_second(struct hrtimer *timer)
 	}
 	update_vsyscall(&xtime, clock);
 
-	write_sequnlock_irq(&xtime_lock);
+	write_sequnlock(&xtime_lock);
 
 	return res;
 }
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 342fc9c..502a81e 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -681,7 +681,6 @@ void tick_setup_sched_timer(void)
 	 */
 	hrtimer_init(&ts->sched_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
 	ts->sched_timer.function = tick_sched_timer;
-	ts->sched_timer.cb_mode = HRTIMER_CB_IRQSAFE_PERCPU;
 
 	/* Get the next period (per cpu) */
 	hrtimer_set_expires(&ts->sched_timer, tick_init_jiffy_update());
diff --git a/kernel/trace/trace_sysprof.c b/kernel/trace/trace_sysprof.c
index 9587d3b..ae542e2 100644
--- a/kernel/trace/trace_sysprof.c
+++ b/kernel/trace/trace_sysprof.c
@@ -202,7 +202,6 @@ static void start_stack_timer(int cpu)
 
 	hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	hrtimer->function = stack_trace_timer_fn;
-	hrtimer->cb_mode = HRTIMER_CB_IRQSAFE_PERCPU;
 
 	hrtimer_start(hrtimer, ns_to_ktime(sample_period), HRTIMER_MODE_REL);
 }
diff --git a/sound/drivers/pcsp/pcsp.c b/sound/drivers/pcsp/pcsp.c
index 1899cf0..8e52b2a 100644
--- a/sound/drivers/pcsp/pcsp.c
+++ b/sound/drivers/pcsp/pcsp.c
@@ -96,7 +96,6 @@ static int __devinit snd_card_pcsp_probe(int devnum, struct device *dev)
 		return -EINVAL;
 
 	hrtimer_init(&pcsp_chip.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
-	pcsp_chip.timer.cb_mode = HRTIMER_CB_SOFTIRQ;
 	pcsp_chip.timer.function = pcsp_do_timer;
 
 	card = snd_card_new(index, id, THIS_MODULE, 0);

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Tue, 16 Dec 2008 21:59:00 +0100,
Ingo Molnar wrote:
> 
> 
> * Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Mon, 15 Dec 2008 15:43:01 +1100,
> > Stephen Rothwell wrote:
> > > 
> > > Hi Takashi,
> > > 
> > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > 
> > > sound/core/hrtimer.c: In function 'snd_hrtimer_open':
> > > sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
> > > sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)
> > > 
> > > An interaction between commit bbaf5e97337287479eb78dbc3822d9560bbfd2e2
> > > ("ALSA: Add hrtimer backend for ALSA timer interface") from the sound
> > > tree and commit ca109491f612aab5c8152207631c0444f63da97f ("hrtimer:
> > > removing all ur callback modes") from the timers tree.
> > > 
> > > I have added the below fixup for the merge and can carry it as necessary.
> > 
> > Thanks, the fix must be correct.
> > 
> > I'm not sure what I should do.  Putting this fix only for linux-next 
> > might be a fix, but this wouldn't work if the affecting patch is changed 
> > or dropped.
> > 
> > If you can keep this one-liner in your tree, it'd be helpful.
> 
> if it becomes a logistical problem, there's a Git approach to resolving 
> this: we are keeping those bits separate in tip/timers/hrtimers, so you 
> could pull that into the sound tree. Your sound tree would be fully 
> combinable in linux-next.

Yes, that'll work.  I merged your branch now and created a new branch,
topic/hrtimer-fix, with the conflict and build fixes on sound git
tree.  Let's see whether it goes well tomorrow :)

FYI, the hrtimer-related topics on sound git tree
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
are:
    topic/snd-hrtimer
    topic/pcsp-fix


Thanks,

Takashi

linux-next: sound tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

Hi Takashi,

Today's linux-next build (powerpc allyesconfig) failed like this:

sound/soc/codecs/twl4030.c:1278: error: conflicting types for 'twl4030_init'
sound/soc/codecs/twl4030.c:1187: error: previous definition of 'twl4030_init' was here

Caused by commit 64089b84abfe2f26a864ebd968429302dcb071de ("ASoC:
Register non-AC97 codec DAIs").

I have reverted the sound tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Wed, 10 Dec 2008 16:23:09 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> sound/soc/codecs/twl4030.c:1278: error: conflicting types for 'twl4030_init'
> sound/soc/codecs/twl4030.c:1187: error: previous definition of 'twl4030_init' was here
> 
> Caused by commit 64089b84abfe2f26a864ebd968429302dcb071de ("ASoC:
> Register non-AC97 codec DAIs").
> 
> I have reverted the sound tree for today.

Thanks for noticing.  I fixed it on sound git tree now.
FWIW, the patch below should fix the build problem.


thanks,

Takashi

===
>From 24e07db8cceb7dfe2d4005e4450a27f4bcda6499 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Wed, 10 Dec 2008 07:40:24 +0100
Subject: [PATCH] ALSA: ASoC - Fix module init entry for twl4030.c

Fixed the function name of module init entry for twl4030.c, which
conflicted with the existing hardware init function:
  sound/soc/codecs/twl4030.c:1278: error: conflicting types for 'twl4030_init'
  sound/soc/codecs/twl4030.c:1187: error: previous definition of 'twl4030_init' was here

Also fixed the section type of init function.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/soc/codecs/twl4030.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 373daa4..71ab534 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -1275,11 +1275,11 @@ struct snd_soc_codec_device soc_codec_dev_twl4030 = {
 };
 EXPORT_SYMBOL_GPL(soc_codec_dev_twl4030);
 
-static int __devinit twl4030_init(void)
+static int __init twl4030_modinit(void)
 {
 	return snd_soc_register_dai(&twl4030_dai);
 }
-module_init(twl4030_init);
+module_init(twl4030_modinit);
 
 static void __exit twl4030_exit(void)
 {
-- 
1.6.0.4

Re: linux-next: sound tree build failure

[Mark Brown]

On Wed, Dec 10, 2008 at 07:53:21AM +0100, Takashi Iwai wrote:

> Thanks for noticing.  I fixed it on sound git tree now.
> FWIW, the patch below should fix the build problem.

Thanks for taking care of this.

linux-next: sound tree build failure

[Stephen Rothwell]

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/soc/soc-dapm.c: In function 'snd_soc_dapm_sys_add':
sound/soc/soc-dapm.c:828: error: 'ret' undeclared (first use in this function)

Caused by commit 12ef193d5817504621e503e78d641265f6a86ac4 ("ASoC: Allow
setting codec register with debugfs filesystem") which removed the
declaration.

I applied the following patch.  More care required.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 31 Oct 2008 14:39:03 +1100
Subject: [PATCH] ALSA: restore removeed variable declaration

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 sound/soc/soc-dapm.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 407092c..7bf3c40 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -822,6 +822,8 @@ static DEVICE_ATTR(dapm_widget, 0444, dapm_widget_show, NULL);
 
 int snd_soc_dapm_sys_add(struct device *dev)
 {
+	int ret;
+
 	if (!dapm_status)
 		return 0;
 
-- 
1.5.6.5

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 31 Oct 2008 14:41:06 +1100,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/soc/soc-dapm.c: In function 'snd_soc_dapm_sys_add':
> sound/soc/soc-dapm.c:828: error: 'ret' undeclared (first use in this function)
> 
> Caused by commit 12ef193d5817504621e503e78d641265f6a86ac4 ("ASoC: Allow
> setting codec register with debugfs filesystem") which removed the
> declaration.
> 
> I applied the following patch.  More care required.

Thanks.  Applied now.
I wonder why I didn't this in my build test...


Takashi

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 31 Oct 2008 14:39:03 +1100
> Subject: [PATCH] ALSA: restore removeed variable declaration
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  sound/soc/soc-dapm.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
> index 407092c..7bf3c40 100644
> --- a/sound/soc/soc-dapm.c
> +++ b/sound/soc/soc-dapm.c
> @@ -822,6 +822,8 @@ static DEVICE_ATTR(dapm_widget, 0444, dapm_widget_show, NULL);
>  
>  int snd_soc_dapm_sys_add(struct device *dev)
>  {
> +	int ret;
> +
>  	if (!dapm_status)
>  		return 0;
>  
> -- 
> 1.5.6.5
> 

Re: linux-next: sound tree build failure

[Troy Kisky]

Stephen Rothwell wrote:
> Hi Takashi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> sound/soc/soc-dapm.c: In function 'snd_soc_dapm_sys_add':
> sound/soc/soc-dapm.c:828: error: 'ret' undeclared (first use in this function)
> 
> Caused by commit 12ef193d5817504621e503e78d641265f6a86ac4 ("ASoC: Allow
> setting codec register with debugfs filesystem") which removed the
> declaration.
> 
> I applied the following patch.  More care required.

My patch had
@@ -822,23 +818,9 @@ static DEVICE_ATTR(dapm_widget, 0444, dapm_widget_show, NULL);

 int snd_soc_dapm_sys_add(struct device *dev)
 {
-	int ret = 0;
-
 	if (!dapm_status)
 		return 0;
-
-	ret = device_create_file(dev, &dev_attr_dapm_widget);
-	if (ret != 0)
-		return ret;
-
-	asoc_debugfs = debugfs_create_dir("asoc", NULL);
-	if (!IS_ERR(asoc_debugfs))
-		debugfs_create_u32("dapm_pop_time", 0744, asoc_debugfs,
-				   &pop_time);
-	else
-		asoc_debugfs = NULL;
-
-	return 0;
+	return device_create_file(dev, &dev_attr_dapm_widget);
 }



which somehow got changed to
@@ -821,23 +817,13 @@ static DEVICE_ATTR(dapm_widget, 0444, dapm_widget_show, NULL);

 int snd_soc_dapm_sys_add(struct device *dev)
 {
-	int ret = 0;
-
 	if (!dapm_status)
 		return 0;

 	ret = device_create_file(dev, &dev_attr_dapm_widget);
 	if (ret != 0)
 		return ret;
-
-	asoc_debugfs = debugfs_create_dir("asoc", NULL);
-	if (!IS_ERR(asoc_debugfs) && asoc_debugfs)
-		debugfs_create_u32("dapm_pop_time", 0744, asoc_debugfs,
-				   &pop_time);
-	else
-		asoc_debugfs = NULL;
-
-	return 0;
+	return device_create_file(dev, &dev_attr_dapm_widget);
 }


which will call device_create_file twice

Troy

Re: linux-next: sound tree build failure

[Takashi Iwai]

At Fri, 31 Oct 2008 13:49:44 -0700,
Troy Kisky wrote:
> 
> Stephen Rothwell wrote:
> > Hi Takashi,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > sound/soc/soc-dapm.c: In function 'snd_soc_dapm_sys_add':
> > sound/soc/soc-dapm.c:828: error: 'ret' undeclared (first use in this function)
> > 
> > Caused by commit 12ef193d5817504621e503e78d641265f6a86ac4 ("ASoC: Allow
> > setting codec register with debugfs filesystem") which removed the
> > declaration.
> > 
> > I applied the following patch.  More care required.
> 
> My patch had
> @@ -822,23 +818,9 @@ static DEVICE_ATTR(dapm_widget, 0444, dapm_widget_show, NULL);
> 
>  int snd_soc_dapm_sys_add(struct device *dev)
>  {
> -	int ret = 0;
> -
>  	if (!dapm_status)
>  		return 0;
> -
> -	ret = device_create_file(dev, &dev_attr_dapm_widget);
> -	if (ret != 0)
> -		return ret;
> -
> -	asoc_debugfs = debugfs_create_dir("asoc", NULL);
> -	if (!IS_ERR(asoc_debugfs))
> -		debugfs_create_u32("dapm_pop_time", 0744, asoc_debugfs,
> -				   &pop_time);
> -	else
> -		asoc_debugfs = NULL;
> -
> -	return 0;
> +	return device_create_file(dev, &dev_attr_dapm_widget);
>  }
> 
> 
> 
> which somehow got changed to
> @@ -821,23 +817,13 @@ static DEVICE_ATTR(dapm_widget, 0444, dapm_widget_show, NULL);
> 
>  int snd_soc_dapm_sys_add(struct device *dev)
>  {
> -	int ret = 0;
> -
>  	if (!dapm_status)
>  		return 0;
> 
>  	ret = device_create_file(dev, &dev_attr_dapm_widget);
>  	if (ret != 0)
>  		return ret;
> -
> -	asoc_debugfs = debugfs_create_dir("asoc", NULL);
> -	if (!IS_ERR(asoc_debugfs) && asoc_debugfs)
> -		debugfs_create_u32("dapm_pop_time", 0744, asoc_debugfs,
> -				   &pop_time);
> -	else
> -		asoc_debugfs = NULL;
> -
> -	return 0;
> +	return device_create_file(dev, &dev_attr_dapm_widget);
>  }
> 
> 
> which will call device_create_file twice

Hm, looks like a merge error or so.
Care to create the fix patch against the latest tree?


thanks,

Takashi