Re: Latest OMAP4 build errors
On Tue, Mar 06, 2012 at 05:01:53PM +, 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 a...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
Hi, Arnd Olof, some urgent changes are needed, see below. * Russell King - ARM Linux li...@arm.linux.org.uk [120307 01:34]: On Tue, Mar 06, 2012 at 05:01:53PM +, 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 a...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
Hi, On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren t...@atomide.com wrote: Hi, Arnd Olof, some urgent changes are needed, see below. * Russell King - ARM Linux li...@arm.linux.org.uk [120307 01:34]: On Tue, Mar 06, 2012 at 05:01:53PM +, 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 a...@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 a...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
* Olof Johansson o...@lixom.net [120307 13:46]: On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren t...@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 a...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
* Russell King - ARM Linux li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
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 a...@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)? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
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 a...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
On Tue, Mar 6, 2012 at 7:01 PM, Arnd Bergmann a...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Latest OMAP4 build errors
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' -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
On Tue, Feb 28, 2012 at 11:02 AM, Russell King - ARM Linux li...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
On Tuesday 28 February 2012, Ohad Ben-Cohen wrote: On Tue, Feb 28, 2012 at 11:02 AM, Russell King - ARM Linux li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP4 build errors
On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
