Updated mach-types update
Subsystems (5)
Some may notice that the mach-types update in my tree has been replaced by a new update to the file, but with a difference:
arch/arm/tools/mach-types | 2406 ++------------------------------------------- 1 files changed, 89 insertions(+), 2317 deletions(-)
It deletes a lot of entries.
For a while now, I've been running a script each day after a pull from mainline which updates a flag in the machine database indicating whether an entry has existed in mainline at any point in time. The database also tracks the time which the last change made to any entry.
Coupling these two bits of data together means that we can select entries from the machine database which are or have been in mainline, and which have been updated within the last twelve months. The above file reflects that, and reduces the file down to 1090 lines (including header).
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
This does have the potential to go wrong if people start randomly changing the format of how they write the MACHINE_START() macro. If it's not found by:
grep -rh --exclude=include --include='*.c' MACHINE_START arch/arm |
grep -v '^#' | sed "s@[^(]*(\([^,]*\).*@ ('\1')@;2,\$s@^@,@"
(which generates a subset of SQL) then it won't be kept. In other words, one line containing _at least_ this is the safest way:
MACHINE_START(NAME,
but this definitely won't work:
MACHINE_START(
NAME,
"Gobovision's Funky Platform")
Quoted 34 lines · Russell King - ARM Linux
Some may notice that the mach-types update in my tree has been replaced by a new update to the file, but with a difference:
arch/arm/tools/mach-types | 2406 ++------------------------------------------- 1 files changed, 89 insertions(+), 2317 deletions(-)It deletes a lot of entries.
For a while now, I've been running a script each day after a pull from mainline which updates a flag in the machine database indicating whether an entry has existed in mainline at any point in time. The database also tracks the time which the last change made to any entry.
Coupling these two bits of data together means that we can select entries from the machine database which are or have been in mainline, and which have been updated within the last twelve months. The above file reflects that, and reduces the file down to 1090 lines (including header).
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
This does have the potential to go wrong if people start randomly changing the format of how they write the
MACHINE_START()macro. If it's not found by:grep -rh --exclude=include --include='*.c'
MACHINE_STARTarch/arm|
grep -v '^#' | sed "s@[^(]*(\([^,]*\).*@ ('\1')@;2,\$s@^@,@"(which generates a subset of SQL) then it won't be kept. In other words, one line containing
_atleast_this is the safest way:
Quoted 7 lines
MACHINE_START(NAME,
but this definitely won't work:
MACHINE_START(
NAME,
"Gobovision's Funky Platform")
Note that OMAP references machine_is_omap2evm() yet this has never been merged.
arch/arm/plat-omap/include/plat/uncompress.h:
DEBUG_LL_OMAP2(1, omap2evm);
so this entry needs to be removed.
Quoted 10 lines · Russell King - ARM Linux
On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
Note that OMAP references
machine_is_omap2evm()yet this has never been merged.
arch/arm/plat-omap/include/plat/uncompress.h:DEBUG_LL_OMAP2(1, omap2evm);so this entry needs to be removed.
Hmm looks like we have LCD support and ASoC support for it, but no board :)
Anybody working with this board?
If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support.
Regards,
Tony
Quoted 12 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux
On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
Note that OMAP references
machine_is_omap2evm()yet this has never been merged.
arch/arm/plat-omap/include/plat/uncompress.h:DEBUG_LL_OMAP2(1, omap2evm);so this entry needs to be removed.
Quoted 7 lines
Hmm looks like we have LCD support and ASoC support for it, but no board :)
Anybody working with this board?
If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evm
The board support has never been merged for it as noticed by Russell King <[email protected]>. So let's remove the related dead code.
arch/arm/plat-omap/include/plat/uncompress.h +0 -1
@@ -129,7 +129,6 @@ static inline void __arch_decomp_setup(unsigned long arch_id)DEBUG_LL_OMAP1 (3 , sx1);/* omap2 based boards using UART1 */ -DEBUG_LL_OMAP2 (1 , omap2evm);DEBUG_LL_OMAP2 (1 , omap_2430sdp);DEBUG_LL_OMAP2 (1 , omap_apollon);DEBUG_LL_OMAP2 (1 , omap_h4);
drivers/video/omap/Makefile +0 -1
@@ -30,7 +30,6 @@ objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o -objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
drivers/video/omap/lcd_omap2evm.c deleted +0 -192
192 lines not on this page · raw message
sound/soc/omap/Makefile +0 -1
@@ -13,7 +13,6 @@ snd-soc-rx51-objs := rx51.o snd-soc-ams-delta-objs := ams-delta.o snd-soc-osk5912-objs := osk5912.o snd-soc-overo-objs := overo.o -snd-soc-omap2evm-objs := omap2evm.o snd-soc-omap3evm-objs := omap3evm.o snd-soc-am3517evm-objs := am3517evm.o snd-soc-sdp3430-objs := sdp3430.o
sound/soc/omap/omap2evm.c deleted +0 -139
139 lines not on this page · raw message
Jarkko Nikula
Acked-byQuoted 16 lines · On Fri, 13 May 2011 04:54:07 -0700 Tony Lindgren <[email protected]> wrote:
Quoted 15 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux
On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
Note that OMAP references
machine_is_omap2evm()yet this has never been merged.
arch/arm/plat-omap/include/plat/uncompress.h:DEBUG_LL_OMAP2(1, omap2evm);so this entry needs to be removed.
Hmm looks like we have LCD support and ASoC support for it, but no board :)
Quoted 8 lines
Quoted 4 lines
Anybody working with this board?
If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch.
Remove also from sound/soc/omap/Kconfig as well. You could put my ack for sound/soc/omap part but remember cc also Mark and Liam.
PATCH 1/1 omap: Remove support for omap2evm (Re: Updated mach-types update)
Quoted 21 lines · Jarkko Nikula
Quoted 18 lines · On Fri, 13 May 2011 04:54:07 -0700 Tony Lindgren <[email protected]> wrote:
Quoted 17 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux
On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
Note that OMAP references
machine_is_omap2evm()yet this has never been merged.
arch/arm/plat-omap/include/plat/uncompress.h:DEBUG_LL_OMAP2(1, omap2evm);so this entry needs to be removed.
Hmm looks like we have LCD support and ASoC support for it, but no board :)
Anybody working with this board?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch.
Remove also from
sound/soc/omap/Kconfigas well. You could put my ack forsound/soc/omappart but remember cc also Mark and Liam.
Thanks, here's the updated patch.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evm
The board support has never been merged for it as noticed by Russell King <[email protected]>. So let's remove the related dead code.
arch/arm/plat-omap/include/plat/uncompress.h +0 -1
@@ -129,7 +129,6 @@ static inline void __arch_decomp_setup(unsigned long arch_id)DEBUG_LL_OMAP1 (3 , sx1);/* omap2 based boards using UART1 */ -DEBUG_LL_OMAP2 (1 , omap2evm);DEBUG_LL_OMAP2 (1 , omap_2430sdp);DEBUG_LL_OMAP2 (1 , omap_apollon);DEBUG_LL_OMAP2 (1 , omap_h4);
drivers/video/omap/Makefile +0 -1
@@ -30,7 +30,6 @@ objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o -objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
drivers/video/omap/lcd_omap2evm.c deleted +0 -192
192 lines not on this page · raw message
sound/soc/omap/Kconfig +0 -8
@@ -65,14 +65,6 @@ config SND_OMAP_SOC_OVERO Say Y if you want to add support for SoC audio on the Gumstix Overo or CompuLab CM-T35 -config SND_OMAP_SOC_OMAP2EVM - tristate "SoC Audio support for OMAP2EVM board" - depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP2EVM - select SND_OMAP_SOC_MCBSP - select SND_SOC_TWL4030 - help - Say Y if you want to add support for SoC audio on the omap2evm board. - config SND_OMAP_SOC_OMAP3EVM tristate "SoC Audio support for OMAP3EVM board" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3EVM
sound/soc/omap/Makefile +0 -1
@@ -13,7 +13,6 @@ snd-soc-rx51-objs := rx51.o snd-soc-ams-delta-objs := ams-delta.o snd-soc-osk5912-objs := osk5912.o snd-soc-overo-objs := overo.o -snd-soc-omap2evm-objs := omap2evm.o snd-soc-omap3evm-objs := omap3evm.o snd-soc-am3517evm-objs := am3517evm.o snd-soc-sdp3430-objs := sdp3430.o
sound/soc/omap/omap2evm.c deleted +0 -139
139 lines not on this page · raw message
Re: [PATCH] omap: Remove support for omap2evm (Re: Updated mach-types update)
Quoted 6 lines · Tony Lindgren
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evmThe board support has never been merged for it as noticed by Russell King <[email protected]>. So let's remove the related dead code.
Re: [PATCH] omap: Remove support for omap2evm (Re: Updated mach-types update)
In reply to Tony LindgrenQuoted 46 lines · Tony Lindgren
Quoted 21 lines · Jarkko Nikula
Quoted 18 lines · On Fri, 13 May 2011 04:54:07 -0700 Tony Lindgren <[email protected]> wrote:
Quoted 17 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux
On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
Note that OMAP references
machine_is_omap2evm()yet this has never been merged.
arch/arm/plat-omap/include/plat/uncompress.h:DEBUG_LL_OMAP2(1, omap2evm);so this entry needs to be removed.
Hmm looks like we have LCD support and ASoC support for it, but no board :)
Anybody working with this board?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch.
Remove also from
sound/soc/omap/Kconfigas well. You could put my ack forsound/soc/omappart but remember cc also Mark and Liam.Thanks, here's the updated patch.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evmThe board support has never been merged for it as noticed by Russell King <[email protected]>. So let's remove the related dead code.
Quoted 9 lines
Cc linux-fbdev at vger.kernel.orgCc alsa-devel at alsa-project.orgCc Mark Brown <[email protected]>Cc Liam Girdwood <[email protected]>Cc Paul Mundt <[email protected]>Cc Tomi Valkeinen <[email protected]>Acked-by Jarkko Nikula <[email protected]>Signed-off-by Tony Lindgren <[email protected]>
Tomi Valkeinen
Acked-byQuoted 16 lines · Tony Lindgren
Quoted 15 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux
On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
Note that OMAP references
machine_is_omap2evm()yet this has never been merged.
arch/arm/plat-omap/include/plat/uncompress.h:DEBUG_LL_OMAP2(1, omap2evm);so this entry needs to be removed.
Hmm looks like we have LCD support and ASoC support for it, but no board :)
Quoted 7 lines
Quoted 4 lines
Anybody working with this board?
If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch.
For removing the lcd driver:
Tomi
Quoted 5 lines · On Sun, 20 Mar 2011 11:03:22 Russell King - ARM Linux <[email protected]>…
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
So what happens to the number that was allocated for a platform that got dropped? Will it be recycled for another platform or is it safe to use it in code that is not intended to go mainline (to avoid cluttering mainline with code that doesn't need to be mainline)?
Detlef
Quoted 8 lines · Detlef Vollmann
Quoted 5 lines · On Sun, 20 Mar 2011 11:03:22 Russell King - ARM Linux <[email protected]>…
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
Quoted 4 lines
So what happens to the number that was allocated for a platform that got dropped? Will it be recycled for another platform or is it safe to use it in code that is not intended to go mainline (to avoid cluttering mainline with code that doesn't need to be mainline)?
You've completely misunderstood what I said. Nothing has been deleted from the database. The file downloadable off the website continues to give the full set of entries.
All that's happened is some filtering on the version I include in the mainline kernel to make it saner. There's no point including 2000 lines (which expand to about 700K of generated file) which aren't used in the mainline kernel.
Quoted 8 lines · On Mon, 21 Mar 2011 23:10:13 Russell King - ARM Linux <[email protected]>…
You've completely misunderstood what I said. Nothing has been deleted from the database. The file downloadable off the website continues to give the full set of entries.
All that's happened is some filtering on the version I include in the mainline kernel to make it saner. There's no point including 2000 lines (which expand to about 700K of generated file) which aren't used in the mainline kernel.
That makes sense.
Thanks for the clarification.
Detlef
Hi Russell,
Quoted 7 lines · Russell King - ARM Linux
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
I think this statement matches the needs of those, like me, are trying to add a new board.
My patch [0] applies but does not build any more. How does it work in this case?
I may include a new bit which adds the right entry in mach-types (so that my patch is actually
buildable and testable before inclusion), in taking my patch set then you should drop the
mach-types bit because it will be updated by you script later.
Quoted 7 lines
This does have the potential to go wrong if people start randomly changing the format of how they write the
MACHINE_START()macro. If it's not found by:grep -rh --exclude=include --include='*.c'
MACHINE_STARTarch/arm|
grep -v '^#' | sed "s@[^(]*(\([^,]*\).*@ ('\1')@;2,\$s@^@,@"
maybe it could be useful to add this regex in the top of mach-types or put it in scripts/ so that everybody can validate his/her changes.
anyway I would add some comment in mach-types that explains how the files is managed.
thanks,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110322/3a89c019/attachment-0001.html>
Quoted 9 lines · Domenico Andreoli
Hi Russell,
Quoted 4 lines · Russell King - ARM Linux
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 1 line
Quoted 1 line
to either talk to me to get it reinstated before submission, or update the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 1 line
Quoted 1 line
entry in some way to 'freshen' it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 6 lines
Quoted 1 line
I think this statement matches the needs of those, like me, are trying to add a new board.
My patch [0] applies but does not build any more. How does it work in this case?
Precisely in the way I said above - see the bit I've underlined.
Frankly, if you are a platform developer, and you are unable to submit your code within 12 months, and stuff you need for that platform gets dropped, that's not _our_ problem to deal with.
Quoted 5 lines
I may include a new bit which adds the right entry in mach-types (so that my patch is actually
buildable and testable before inclusion), in taking my patch set then you should drop the mach-types bit because it will be updated by you script later.
Or you could follow the instructions I said above.
Quoted 10 lines
Quoted 7 lines
This does have the potential to go wrong if people start randomly changing the format of how they write the
MACHINE_START()macro. If it's not found by:grep -rh --exclude=include --include='*.c'
MACHINE_STARTarch/arm|
grep -v '^#' | sed "s@[^(]*(\([^,]*\).*@ ('\1')@;2,\$s@^@,@"maybe it could be useful to add this regex in the top of mach-types or put it in
scripts/so that everybody can validate his/her changes.
Why? It's not actually useful to anyone else as all it does is produce a big amount of SQL-formatted stuff to indicate what's in mainline. You know what's in mainline already - and it's really the case that you have to be extremely obscure to avoid it matching.
Even if it was included, it wouldn't prompt people to check that their new stuff matches.
Quoted 2 lines
anyway I would add some comment in mach-types that explains how the files is managed.
You mean like the comment that's in there - have you even looked at the cut down version yet?
Hi,
Quoted 13 lines · ext Russell King - ARM Linux
Quoted 5 lines · Domenico Andreoli
Quoted 4 lines · Russell King - ARM Linux
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Quoted 1 line
Quoted 1 line
to either talk to me to get it reinstated before submission, or update the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Quoted 1 line
Quoted 1 line
entry in some way to 'freshen' it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Quoted 2 lines
Quoted 1 line
Quoted 6 lines
Quoted 4 lines
I think this statement matches the needs of those, like me, are trying to add a new board.
My patch [0] applies but does not build any more. How does it work in this case?Precisely in the way I said above - see the bit I've underlined.
So it looks like I cannot be of any help improving my QQ2440 patch :)
Could you please reintroduce the qq2440 mach type? I have one patch
[0] sitting, I got some feedback but nobody has Revieved-by the v3 yet. The networking part has been already pulled by Linus trough netdev.
Thank you.
Quoted 5 lines
Quoted 2 lines
anyway I would add some comment in mach-types that explains how the files is managed.
You mean like the comment that's in there - have you even looked at the cut down version yet?
Yes, after I sent the email. It took a while for me to find your git tree, it was not obvious that rmk is you :) Sorry for the noise.
Regards,
Domenico
[0] http://article.gmane.org/gmane.linux.ports.arm.kernel/110583/match=qq2440
Hello Russell,
I will be submitting the platform init for MACH_VISION_EP9307 for review soon. I have a bit more testing to do before it will be ready. Possibly by the end of the week or early next week.
Should this submission include the necessary patch to add back:
+vision_ep9307 MACH_VISION_EP9307 VISION_EP9307 1578
Or do I just need to inform you so that it can be added back to mach-types?
Thanks,
Hartley
Quoted 34 lines · Russell King - ARM Linux
Some may notice that the mach-types update in my tree has been replaced by a new update to the file, but with a difference:
?arch/arm/tools/mach-types | 2406 ++------------------------------------------- ?1 files changed, 89 insertions(+), 2317 deletions(-)
It deletes a lot of entries.
For a while now, I've been running a script each day after a pull from mainline which updates a flag in the machine database indicating whether an entry has existed in mainline at any point in time. ?The database also tracks the time which the last change made to any entry.
Coupling these two bits of data together means that we can select entries from the machine database which are or have been in mainline, and which have been updated within the last twelve months. ?The above file reflects that, and reduces the file down to 1090 lines (including header).
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
This does have the potential to go wrong if people start randomly changing the format of how they write the
MACHINE_START()macro. ?If it's not found by:grep -rh --exclude=include --include='*.c'
MACHINE_STARTarch/arm| ?grep -v '^#' | sed "s@[^(]*(\([^,]*\).*@ ('\1')@;2,\$s@^@,@"(which generates a subset of SQL) then it won't be kept. ?In other words, one line containing
_atleast_this is the safest way:
Quoted 8 lines
MACHINE_START(NAME,
but this definitely won't work:
MACHINE_START(
? ? ? ?NAME,
? ? ? ?"Gobovision's Funky Platform")
This breaks master with CONFIG_PCI=y:
CC arch/arm/kernel/bios32.oarch/arm/kernel/bios32.c: In function 'pci_fixup_prpmc1100':arch/arm/kernel/bios32.c:174: error: implicit declaration of function 'machine_is_prpmc1100'
I can't tell what the right fix is. Deleting pci_fixup_prpmc1100 fixes it. There is no machine for prpmc1100, but there is CONFIG_ARCH_PRPMC1100 that enables machine IXCDP1100 in arch/arm/mach-ixp4xx/ixdp425-setup.c. Should bios32.c be using machine_is_ixcdp1100? The history is all pre-git.
arch/arm/kernel/bios32.c +0 -0
@@ -159,31 +159,6 @@ static void __devinit pci_fixup_dec21285(struct
pci_dev *dev)
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21285,pci_fixup_dec21285);
/*
- * Same as above. The PrPMC800 carrier board for the PrPMC1100
- * card maps the host-bridge @ 00:01:00 for some reason and it
- * ends up getting scanned. Note that we only want to do this
- * fixup when we find the IXP4xx on a PrPMC system, which is why
- * we check the machine type. We could be running on a board
- * with an IXP4xx target device and we don't want to kill the
- * resources in that case.
- */
-static void __devinit pci_fixup_prpmc1100(struct pci_dev *dev) -{
- int i;
-
- if (machine_is_prpmc1100()) {
- dev->class &= 0xff;
- dev->class |= PCI_CLASS_BRIDGE_HOST << 8;
- for (i = 0; i < PCI_NUM_RESOURCES; i++) {
- dev->resource[i].start = 0;
- dev->resource[i].end = 0;
- dev->resource[i].flags = 0;
- }
- }
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IXP4XX, pci_fixup_prpmc1100);
-
-/*
* PCI IDE controllers use non-standard I/O port decoding, respect it. */
static void __devinit pci_fixup_ide_bases(struct pci_dev *dev)
Quoted 11 lines · Colin Cross
This breaks master with
CONFIG_PCI=y:
CCarch/arm/kernel/bios32.oarch/arm/kernel/bios32.c: In function 'pci_fixup_prpmc1100':arch/arm/kernel/bios32.c:174: error: implicit declaration of function 'machine_is_prpmc1100'I can't tell what the right fix is. Deleting
pci_fixup_prpmc1100fixes it. There is no machine for prpmc1100, but there isCONFIG_ARCH_PRPMC1100that enables machine IXCDP1100 inarch/arm/mach-ixp4xx/ixdp425-setup.c. Shouldbios32.cbe usingmachine_is_ixcdp1100? The history is all pre-git.
http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=40a29db2qiY8UR8FWw0U1i4DgOLsRA
Looks like Deepak submitted it as part of the IXP4xx stuff. However, prpmc1100-pci.c no longer exists... but can be found:
which lead to:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2448%2F1
So, your patch below looks like the right thing.
Quoted 18 lines · Russell King - ARM Linux
Quoted 11 lines · Colin Cross
This breaks master with
CONFIG_PCI=y:
CCarch/arm/kernel/bios32.oarch/arm/kernel/bios32.c: In function 'pci_fixup_prpmc1100':arch/arm/kernel/bios32.c:174: error: implicit declaration of function 'machine_is_prpmc1100'I can't tell what the right fix is. Deleting
pci_fixup_prpmc1100fixes it. There is no machine for prpmc1100, but there isCONFIG_ARCH_PRPMC1100that enables machine IXCDP1100 inarch/arm/mach-ixp4xx/ixdp425-setup.c. Shouldbios32.cbe usingmachine_is_ixcdp1100? The history is all pre-git.http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=40a29db2qiY8UR8FWw0U1i4DgOLsRA
Looks like Deepak submitted it as part of the IXP4xx stuff. However,
prpmc1100-pci.cno longer exists... but can be found:
Quoted 7 lines
which lead to:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2448%2F1
So, your patch below looks like the right thing.
Could you submit this to the patch system please?
Thanks.
Quoted 21 lines · Russell King - ARM Linux
Quoted 20 lines · Russell King - ARM Linux
Quoted 11 lines · Colin Cross
This breaks master with
CONFIG_PCI=y:
CCarch/arm/kernel/bios32.oarch/arm/kernel/bios32.c: In function 'pci_fixup_prpmc1100':arch/arm/kernel/bios32.c:174: error: implicit declaration of function 'machine_is_prpmc1100'I can't tell what the right fix is. Deleting
pci_fixup_prpmc1100fixes it. There is no machine for prpmc1100, but there isCONFIG_ARCH_PRPMC1100that enables machine IXCDP1100 inarch/arm/mach-ixp4xx/ixdp425-setup.c. Shouldbios32.cbe usingmachine_is_ixcdp1100? The history is all pre-git.http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=40a29db2qiY8UR8FWw0U1i4DgOLsRA
Looks like Deepak submitted it as part of the IXP4xx stuff. However,
prpmc1100-pci.cno longer exists... but can be found:
Quoted 7 lines
Quoted 5 lines
which lead to:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2448%2F1
So, your patch below looks like the right thing.
Could you submit this to the patch system please?
Ignore that, you already did.
Quoted 7 lines · Russell King - ARM Linux
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
Hi Russell,
Apologies, I just realized this patch removed an entry for a board I am working with. Could you reinstate the following entry:
2363 WAYLAND wayland Ofer Zaarur
I plan to submit support for this board as soon as I can.
Thanks,
jaya
Quoted 10 lines · Jaya Kumar
Quoted 7 lines · Russell King - ARM Linux
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
Quoted 8 lines
Hi Russell,
Apologies, I just realized this patch removed an entry for a board I am working with. Could you reinstate the following entry:
2363 WAYLAND wayland Ofer Zaarur
I plan to submit support for this board as soon as I can.
I'm not sure how that squares with Linus' complaint during the last merge window - I'm currently nervous about sending Linus updates to mach-types as it is. Maybe our new sub-architecture people can comment on their perception of the situation with new board support.
Quoted 13 lines · Russell King - ARM Linux
Quoted 12 lines · Jaya Kumar
Quoted 6 lines · Russell King - ARM Linux
What this means is that any platform in the machine database which has not been submitted to mainline for 12 months since it was registered will be automatically dropped from the file, and the platform maintainer will need to either talk to me to get it reinstated before submission, or update the entry in some way to 'freshen' it.
Apologies, I just realized this patch removed an entry for a board I am working with. Could you reinstate the following entry:
Quoted 8 lines
Quoted 3 lines
2363 WAYLAND wayland Ofer Zaarur
I plan to submit support for this board as soon as I can.
I'm not sure how that squares with Linus' complaint during the last merge window - I'm currently nervous about sending Linus updates to mach-types as it is. Maybe our new sub-architecture people can comment on their perception of the situation with new board support.
We discussed this in Budapest and basically agreed that we wouldn't stop new board numbers and board files from being added until there is enough infrastructure present to add new boards with the device tree only. I would certainly not stop anyone from adding new boards in the current merge window, or probably the next one.
However, for each subarchitecture that has gains support for device tree probing, I would no longer add any new boards, and also not add new subarchitectures that require board files.
Since we are not planning to enforce removal of board files any time soon, I think we should also keep maintaining the mach-types for now, including updates. If you are worried about Linus complaining about it, I guess we can add arch/arm/tools/ to the files that we maintain along with mach-* and plat-*.
Arnd
Quoted 5 lines · Arnd Bergmann
We discussed this in Budapest and basically agreed that we wouldn't stop new board numbers and board files from being added until there is enough infrastructure present to add new boards with the device tree only. I would certainly not stop anyone from adding new boards in the current merge window, or probably the next one.
Given my discussion with Linus over merging what's in my tree yesterday, the indication is that Linus is _only_ going to take git trees which remove code or "don't add tons of new lines", in other words only small growth is acceptable.
Given that I don't see how new board files, which tend to be around the thousand-line mark could be added, which rather makes updating mach-types rather pointless.
Quoted 4 lines · Russell King - ARM Linux
Given my discussion with Linus over merging what's in my tree yesterday, the indication is that Linus is _only_ going to take git trees which remove code or "don't add tons of new lines", in other words only small growth is acceptable.
Is this only for this merge window?
Quoted 3 lines
Given that I don't see how new board files, which tend to be around the thousand-line mark could be added, which rather makes updating mach-types rather pointless.
Having the machine type there at least helps people working with out of tree board support to do the right thing. We can't very well complain about people reusing machine IDs or patching mach-types.h if it's not possible to get updates made to the file and until device tree actually works usably on the active ARM platforms (or there's a realistic prospect of people contributing the code to make it do so as a condition for getting their work in) it seems better to permit updates and allow people to follow the current best practices even if we're not letting them merge the code itself.
Quoted 8 lines · Mark Brown
Quoted 4 lines · Russell King - ARM Linux
Given my discussion with Linus over merging what's in my tree yesterday, the indication is that Linus is _only_ going to take git trees which remove code or "don't add tons of new lines", in other words only small growth is acceptable.
Is this only for this merge window?
Let me turn this around. Given that Linus has complained about the 60k LOC growth of ARM at every merge window, and at this window we've been able to achieve a net reduction of 15k LOC, what do you think the chances of adding another 60k LOC at the next merge window are?
Don't get me wrong - 15k LOC removal is a good start, but it's just that, a start. It's well below what I was hoping for.
Quoted 7 lines · Russell King - ARM Linux
Let me turn this around. Given that Linus has complained about the 60k LOC growth of ARM at every merge window, and at this window we've been able to achieve a net reduction of 15k LOC, what do you think the chances of adding another 60k LOC at the next merge window are?
Don't get me wrong - 15k LOC removal is a good start, but it's just that, a start. It's well below what I was hoping for.
Agreed. The 15k LOC were also partially just the low-hanging fruit, so we won't be able to do much larger reductions without doing more groundwork first, like the stuff that is going in now (clkdev, irq, clksource, device tree, ...).
We need to do more of those before we see significant reductions from being able to remove a lot of the existing board files. At the same time, a number of people obviously have new boards that they want to see supported. The tactical answer that I'd give to them is that they can still add board files, provided that they also help do the work that is required to remove them later (depends the specific capabilities of the people and the complexity of the code they want to add).
Only after we have dealt with board-level code and moved that over to device tree probing within a given subarchitecture, we can really start addressing the issue across SoCs inside of the same subarchitecture. Similarly, I would not try to keep out new SoCs from getting merged until then (as long as they don't try to add code that is worse than the existing SoCs) but instead ask the people that are interested in merging them to help the consolidation on that level. The reason for doing cross-soc stuff after cross-board stuff is that it's more work to do that in the device tree and that there is less to gain.
Another area where I think we will see initial growth is the device tree source files -- as we discussed, we want to put them into the kernel at first, until the dust has settled down a bit and they stop changing. At that point, we will start a new source code repo that is OS independent and just contains all the device trees so we can delete them again. My hope is that we get Linus to agree to this because it's a useful step in the right direction and only adds code that we are planning to remove later.
Arnd
Quoted 8 lines · Arnd Bergmann
We need to do more of those before we see significant reductions from being able to remove a lot of the existing board files. At the same time, a number of people obviously have new boards that they want to see supported. The tactical answer that I'd give to them is that they can still add board files, provided that they also help do the work that is required to remove them later (depends the specific capabilities of the people and the complexity of the code they want to add).
Hi Arnd,
Thanks for the feedback. I think this thread went from the specific case of this 2363, Wayland board into a broader discussion. I understand this is because of the arm subarch cleanup goals. To help people like me who aren't familiar with the details, could you elaborate on "can still add board files" and "the work that is required to remove them later". Do you mean I could still submit a patch like arch/arm/mach-mmp/wayland* and you'd be willing to take it, but with the expectation that it would be removed at a later date? Is the removal work to do with adding device tree support (I assume that's a bootloader task as well as a subarch/board support task)? I'm happy to help with what I can but I'm very slow. I'm even having trouble just getting mainline to boot on the board. [1]
Thanks,
jaya
Quoted 4 lines · Jaya Kumar
Thanks for the feedback. I think this thread went from the specific case of this 2363, Wayland board into a broader discussion. I understand this is because of the arm subarch cleanup goals. To help people like me who aren't familiar with the details, could you
Quoted 8 lines
elaborate on "can still add board files" and "the work that is required to remove them later". Do you mean I could still submit a patch like
arch/arm/mach-mmp/wayland*and you'd be willing to take it, but with the expectation that it would be removed at a later date? Is the removal work to do with adding device tree support (I assume that's a bootloader task as well as a subarch/board support task)? I'm happy to help with what I can but I'm very slow. I'm even having trouble just getting mainline to boot on the board. [1]
Hi Jaya,
Our long-term goal is to replace all board files that are today written in C with device tree files that describe a board independent of the kernel.
This clearly isn't happening over night and we need a lot of people to help out with that. You can definitely submit a patch to add the board (if you haven't already) and then we review it with the goal of finding a solution that helps you get the board supported while at the same time making some progress towards removing board files. What exactly that solution is depends a lot on the contents of your board file and what the mmp maintainers think of it.
I haven't seen the board code, so I could only guess that it will be one of these:
* If your board is very simple, we can help make that board use the device tree to describe all devices on your board, so you don't need a board file, while other mmp boards still use it.
* If there is something particularly ugly that is shared with other mmp board files, I'd ask you to clean up the same wart in all mmp board files but add yours without further changes.
* If the new board file looks good but too complex to convert to device tree right away, you could choose an area that stands in the way of moving all mmp boards over to device tree, and create a binding for that area. One such area might be describing the mfp pin config in the device tree.
Arnd
Quoted 9 lines · Arnd Bergmann
Quoted 2 lines · Russell King - ARM Linux
Don't get me wrong - 15k LOC removal is a good start, but it's just that, a start. It's well below what I was hoping for.
Agreed. The 15k LOC were also partially just the low-hanging fruit, so we won't be able to do much larger reductions without doing more groundwork first, like the stuff that is going in now (clkdev, irq, clksource, device tree, ...).
Indeed.
Quoted 7 lines
We need to do more of those before we see significant reductions from being able to remove a lot of the existing board files. At the same time, a number of people obviously have new boards that they want to see supported. The tactical answer that I'd give to them is that they can still add board files, provided that they also help do the work that is required to remove them later (depends the specific capabilities of the people and the complexity of the code they want to add).
This should also be really helpful for getting people to actually work on the infrastructure. If we're just telling anyone working on actual systems on ARM to go away then we're creating additional barriers to working with the improved infrastructure and reducing the visibility the community has of what's going on, pushing people back into BSP land which really isn't where we want things to be going.
It's also coming back to the thing I was saying when this approach was originally announced - if we're just telling people that there's no way they can work with mainline until some non-specific set of generic ARM improvements has been done that's really not going them anything concrete they can work with. The work that needs doing is both open ended and long term, it's not something with any end in sight and it requires a good degree of comfortability with working with tree wide changes. That's tough and it seems more likely to put people off than to stimulate new contributors.
If we can give people specific feedback on their code that they can directly address that's entirely reasonable. Saying things like "your code isn't up to standard, you should be doing this other thing" or "this thing you're doing is actually pretty generic, you should submit some infrastructure for it then build on top of that" gives people a clear thing they can actually do that they can relate to the work they're doing. Saying that we're not going to be accepting any support for new hardware into Linux for the forseeable future is more of an impenetrable cliff face.
If Linus is pushing back in this way it seems like the thing to do is push back on him, it seems like we should be able to point to concrete things that are being done to improve the situation without also stalling work on new platforms.