Latest OMAP4 build errors

Latest OMAP4 build errors

[Russell King - ARM Linux]

This is from my tree plus arm-soc's for-next.  This build error was
introduced in arm-soc:

In file included from arch/arm/mach-omap2/iommu2.c:22:
arch/arm/plat-omap/include/plat/iommu.h: In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:135: error: 'struct dev_archdata' has no member named 'iommu'
In file included from arch/arm/mach-omap2/omap-iommu.c:17:
arch/arm/plat-omap/include/plat/iommu.h: In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:135: error: 'struct dev_archdata' has no member named 'iommu'

The problem appears to be that OMAP_IOMMU is selected without IOMMU_API.
This is done by:

config OMAP_REMOTEPROC
        tristate "OMAP remoteproc support"
        depends on ARCH_OMAP4
        select OMAP_IOMMU
...
        default m

This is wrong for two reasons:

1. It selects OMAP_IOMMU which may not have its dependencies satisfied.

warning: (OMAP_REMOTEPROC) selects OMAP_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && ARCH_OMAP)

2. It's a new feature.  It is experimental.  It should not default to 'm'

Re: Latest OMAP4 build errors

[Ohad Ben-Cohen]

On Tue, Feb 28, 2012 at 11:02 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> 1. It selects OMAP_IOMMU which may not have its dependencies satisfied.

I'll select IOMMU_SUPPORT too (I prefer selecting here rather than
depending, because users may have hard time realizing they need to
enable omap's iommu first in order for omap's remoteproc option to
show up).

> 2. It's a new feature.  It is experimental.  It should not default to 'm'

I'll set it to 'n' (by removing that line altogether).

Thanks for reporting this, Russell.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest OMAP4 build errors

[Arnd Bergmann]

On Tuesday 28 February 2012, Ohad Ben-Cohen wrote:
> On Tue, Feb 28, 2012 at 11:02 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > 1. It selects OMAP_IOMMU which may not have its dependencies satisfied.
> 
> I'll select IOMMU_SUPPORT too (I prefer selecting here rather than
> depending, because users may have hard time realizing they need to
> enable omap's iommu first in order for omap's remoteproc option to
> show up).

I think 'depends' would be better here, because selecting IOMMU_SUPPORT
has other side-effects that a user might not want. It's just as likely
that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT.

In most cases, the defconfig should just set both.

> > 2. It's a new feature.  It is experimental.  It should not default to 'm'
> 
> I'll set it to 'n' (by removing that line altogether).

ok.

	Arnd

Re: Latest OMAP4 build errors

[Ohad Ben-Cohen]

On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> I think 'depends' would be better here, because selecting IOMMU_SUPPORT
> has other side-effects that a user might not want. It's just as likely
> that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
> as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT.
>
> In most cases, the defconfig should just set both.

Ok, 'depends on' it is.

Thanks,
Ohad.

Re: Latest OMAP4 build errors

[Russell King - ARM Linux]

On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
> On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I think 'depends' would be better here, because selecting IOMMU_SUPPORT
> > has other side-effects that a user might not want. It's just as likely
> > that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
> > as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT.
> >
> > In most cases, the defconfig should just set both.
> 
> Ok, 'depends on' it is.

We're a week on, which means I now have a full set of 7 builds on the
website for OMAP4430 all of which have failed in part due to this
as yet unresolved problem.

What's happening to get it fixed and those fixes into whatever tree is
necessary for them (presumably arm-soc)?

Re: Latest OMAP4 build errors

[Arnd Bergmann]

On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
> > On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > I think 'depends' would be better here, because selecting IOMMU_SUPPORT
> > > has other side-effects that a user might not want. It's just as likely
> > > that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
> > > as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT.
> > >
> > > In most cases, the defconfig should just set both.
> > 
> > Ok, 'depends on' it is.
> 
> We're a week on, which means I now have a full set of 7 builds on the
> website for OMAP4430 all of which have failed in part due to this
> as yet unresolved problem.
> 
> What's happening to get it fixed and those fixes into whatever tree is
> necessary for them (presumably arm-soc)?

Ohad has sent a series of patches for review and there were no comments
on those. The fix was part of it as far as I remember. I'm still waiting
for a pull request from Ohad.

	Arnd

Re: Latest OMAP4 build errors

[Ohad Ben-Cohen]

On Tue, Mar 6, 2012 at 7:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Ohad has sent a series of patches for review and there were no comments
> on those. The fix was part of it as far as I remember. I'm still waiting
> for a pull request from Ohad.

Yes, sorry for not sending the pull yet. I should have sent this fix
asap, and only wait for comments on the rest of the patches.

Will send the pull request today.

Thanks,
Ohad.

Re: Latest OMAP4 build errors

[Russell King - ARM Linux]

On Tue, Mar 06, 2012 at 05:01:53PM +0000, Arnd Bergmann wrote:
> On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> > On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
> > > On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > I think 'depends' would be better here, because selecting IOMMU_SUPPORT
> > > > has other side-effects that a user might not want. It's just as likely
> > > > that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
> > > > as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT.
> > > >
> > > > In most cases, the defconfig should just set both.
> > > 
> > > Ok, 'depends on' it is.
> > 
> > We're a week on, which means I now have a full set of 7 builds on the
> > website for OMAP4430 all of which have failed in part due to this
> > as yet unresolved problem.
> > 
> > What's happening to get it fixed and those fixes into whatever tree is
> > necessary for them (presumably arm-soc)?
> 
> Ohad has sent a series of patches for review and there were no comments
> on those. The fix was part of it as far as I remember. I'm still waiting
> for a pull request from Ohad.

Given that we're coming to the end of what could be the _final_ week
before the merge window opens, this is not good news.  Read: maybe
three days before final.

The fact is that OMAP is - yet again - in a totally rotten state in terms
of what's queued up in the armsoc tree.  It is - yet again - completely
unbuildable for many configurations.  Just go and have a look at:

	http://www.arm.linux.org.uk/developer/build/

to see what an utterly crappy state OMAP is in again.  Last nights build
was my tree plus latest arm-soc.  Some of those issues have patches (I
had been applying one patch manually to the build tree) but that's not
the point - they're not in arm-soc, so the OMAP code in arm-soc is not
yet ready for mainline.

So, as OMAP is soo broken, and as promised after the last merge window -
I don't want any OMAP stuff going upstream from armsoc until we get error
free builds from the allno and old configs on the builder.

Re: Latest OMAP4 build errors

[Tony Lindgren]

Hi,

Arnd & Olof, some urgent changes are needed, see below.

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120307 01:34]:
> On Tue, Mar 06, 2012 at 05:01:53PM +0000, Arnd Bergmann wrote:
> > On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> > > On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
> > > > On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > I think 'depends' would be better here, because selecting IOMMU_SUPPORT
> > > > > has other side-effects that a user might not want. It's just as likely
> > > > > that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
> > > > > as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT.
> > > > >
> > > > > In most cases, the defconfig should just set both.
> > > > 
> > > > Ok, 'depends on' it is.
> > > 
> > > We're a week on, which means I now have a full set of 7 builds on the
> > > website for OMAP4430 all of which have failed in part due to this
> > > as yet unresolved problem.
> > > 
> > > What's happening to get it fixed and those fixes into whatever tree is
> > > necessary for them (presumably arm-soc)?
> > 
> > Ohad has sent a series of patches for review and there were no comments
> > on those. The fix was part of it as far as I remember. I'm still waiting
> > for a pull request from Ohad.
> 
> Given that we're coming to the end of what could be the _final_ week
> before the merge window opens, this is not good news.  Read: maybe
> three days before final.
> 
> The fact is that OMAP is - yet again - in a totally rotten state in terms
> of what's queued up in the armsoc tree.  It is - yet again - completely
> unbuildable for many configurations.  Just go and have a look at:
> 
> 	http://www.arm.linux.org.uk/developer/build/
> 
> to see what an utterly crappy state OMAP is in again.  Last nights build
> was my tree plus latest arm-soc.  Some of those issues have patches (I
> had been applying one patch manually to the build tree) but that's not
> the point - they're not in arm-soc, so the OMAP code in arm-soc is not
> yet ready for mainline.

Yes looks like there's an issue with getting urgent patches applied into
the arm-soc tree.. The patches to fix these issues are known and
other issues and warnings should be all sorted out now except for some
MMC changes that are still being discussed.
 
> So, as OMAP is soo broken, and as promised after the last merge window -
> I don't want any OMAP stuff going upstream from armsoc until we get error
> free builds from the allno and old configs on the builder.

What I got queued up in fixes-non-critical-part2 should fix all those
errors and warnings.

Arnd & Olof, I've posted one fix that should be applied to arm-soc tree
at [1]. I've also posted a request to revert one commit in arm-soc tree
at [2].

As it seems that you did not apply those to arm-soc, please apply them,
or repull the following two branches ASAP:

Re-pull fixes-non-critical containing one revert:

Revert "ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP"

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical

Re-pull cleanup again containing one fix:

ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup

Note that the second one I just pushed, however the patch is known to
work for the build errors after merging arm-soc with Russell's changes.

Arnd & Olof, for future, how you want to handle urgent issues like this?

Regards,

Tony


[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg64149.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg64151.html

Re: Latest OMAP4 build errors

[Olof Johansson]

Hi,

On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren <tony@atomide.com> wrote:
> Hi,
>
> Arnd & Olof, some urgent changes are needed, see below.
>
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120307 01:34]:
>> On Tue, Mar 06, 2012 at 05:01:53PM +0000, Arnd Bergmann wrote:
>> > On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
>> > > On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
>> > > > On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > > > > I think 'depends' would be better here, because selecting IOMMU_SUPPORT
>> > > > > has other side-effects that a user might not want. It's just as likely
>> > > > > that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
>> > > > > as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT.
>> > > > >
>> > > > > In most cases, the defconfig should just set both.
>> > > >
>> > > > Ok, 'depends on' it is.
>> > >
>> > > We're a week on, which means I now have a full set of 7 builds on the
>> > > website for OMAP4430 all of which have failed in part due to this
>> > > as yet unresolved problem.
>> > >
>> > > What's happening to get it fixed and those fixes into whatever tree is
>> > > necessary for them (presumably arm-soc)?
>> >
>> > Ohad has sent a series of patches for review and there were no comments
>> > on those. The fix was part of it as far as I remember. I'm still waiting
>> > for a pull request from Ohad.
>>
>> Given that we're coming to the end of what could be the _final_ week
>> before the merge window opens, this is not good news.  Read: maybe
>> three days before final.
>>
>> The fact is that OMAP is - yet again - in a totally rotten state in terms
>> of what's queued up in the armsoc tree.  It is - yet again - completely
>> unbuildable for many configurations.  Just go and have a look at:
>>
>>       http://www.arm.linux.org.uk/developer/build/
>>
>> to see what an utterly crappy state OMAP is in again.  Last nights build
>> was my tree plus latest arm-soc.  Some of those issues have patches (I
>> had been applying one patch manually to the build tree) but that's not
>> the point - they're not in arm-soc, so the OMAP code in arm-soc is not
>> yet ready for mainline.
>
> Yes looks like there's an issue with getting urgent patches applied into
> the arm-soc tree.. The patches to fix these issues are known and
> other issues and warnings should be all sorted out now except for some
> MMC changes that are still being discussed.
>
>> So, as OMAP is soo broken, and as promised after the last merge window -
>> I don't want any OMAP stuff going upstream from armsoc until we get error
>> free builds from the allno and old configs on the builder.
>
> What I got queued up in fixes-non-critical-part2 should fix all those
> errors and warnings.
>
> Arnd & Olof, I've posted one fix that should be applied to arm-soc tree
> at [1]. I've also posted a request to revert one commit in arm-soc tree
> at [2].
>
> As it seems that you did not apply those to arm-soc, please apply them,
> or repull the following two branches ASAP:

Done (repulled the branches). Stephen Rothwell has not surfaced on irc
yet, so hopefully this means it'll make it into today's linux-next.

>
> Re-pull fixes-non-critical containing one revert:
>
> Revert "ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP"
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical
>
> Re-pull cleanup again containing one fix:
>
> ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup
>
> Note that the second one I just pushed, however the patch is known to
> work for the build errors after merging arm-soc with Russell's changes.

Looks like you pasted the wrong subject above -- the mail below
contains the patch that you added though so it looked OK to me (the
subject above was the previous top-of-branch before you added the last
one).

> Arnd & Olof, for future, how you want to handle urgent issues like this?

Personally I missed the requests since they ended up in the chain of
replies and I didn't notice them, my mistake. A separate email
requesting pulls or patch application it to arm@kernel.org would
reduce the risk of that happening (Flagging the subject with [URGENT]
wouldn't hurt).


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest OMAP4 build errors

[Tony Lindgren]

* Olof Johansson <olof@lixom.net> [120307 13:46]:
> On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > What I got queued up in fixes-non-critical-part2 should fix all those
> > errors and warnings.
> >
> > Arnd & Olof, I've posted one fix that should be applied to arm-soc tree
> > at [1]. I've also posted a request to revert one commit in arm-soc tree
> > at [2].
> >
> > As it seems that you did not apply those to arm-soc, please apply them,
> > or repull the following two branches ASAP:
> 
> Done (repulled the branches). Stephen Rothwell has not surfaced on irc
> yet, so hopefully this means it'll make it into today's linux-next.

Thanks!
 
> > Re-pull fixes-non-critical containing one revert:
> >
> > Revert "ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP"
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical
> >
> > Re-pull cleanup again containing one fix:
> >
> > ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup
> >
> > Note that the second one I just pushed, however the patch is known to
> > work for the build errors after merging arm-soc with Russell's changes.
> 
> Looks like you pasted the wrong subject above -- the mail below
> contains the patch that you added though so it looked OK to me (the
> subject above was the previous top-of-branch before you added the last
> one).

Oops, sorry about that. The end result looks right.
 
> > Arnd & Olof, for future, how you want to handle urgent issues like this?
> 
> Personally I missed the requests since they ended up in the chain of
> replies and I didn't notice them, my mistake. A separate email
> requesting pulls or patch application it to arm@kernel.org would
> reduce the risk of that happening (Flagging the subject with [URGENT]
> wouldn't hurt).

OK thanks, will do that next time if there's something urgent.

I'll send a pull request shortly for fixes-non-critical-part2 that
should sort out the remaining issues.

Regards,

Tony

Re: Latest OMAP4 build errors

[Russell King - ARM Linux]

On Wed, Mar 07, 2012 at 02:44:59PM -0800, Tony Lindgren wrote:
> OK thanks, will do that next time if there's something urgent.
> 
> I'll send a pull request shortly for fixes-non-critical-part2 that
> should sort out the remaining issues.

FYI, I've just updated the build tree with what's in arm-soc (as of
a couple of minutes ago), which contained a bunch of OMAP updates, so
I'm hopeful that tomorrows results should show an improvement.

It'll start its run in about 2h20.

Re: Latest OMAP4 build errors

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120307 15:11]:
> On Wed, Mar 07, 2012 at 02:44:59PM -0800, Tony Lindgren wrote:
> > OK thanks, will do that next time if there's something urgent.
> > 
> > I'll send a pull request shortly for fixes-non-critical-part2 that
> > should sort out the remaining issues.
> 
> FYI, I've just updated the build tree with what's in arm-soc (as of
> a couple of minutes ago), which contained a bunch of OMAP updates, so
> I'm hopeful that tomorrows results should show an improvement.
> 
> It'll start its run in about 2h20.

Looks like there one new section warning with omap_hsmmc_init_one
depending on the compiler. I'll post a fix for that.

Not seeing that with codesourcery/linaro compilers, but seeing
with the emdebian gcc 4.3.5.

Regards,

Tony