Updated mach-types update

Updated mach-types update

[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_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")

Updated mach-types update

[Russell King - ARM Linux]

On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
> 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")

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.

Updated mach-types update

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> 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

Updated mach-types update

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110324 10:57]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > 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.

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 <tony@atomide.com>
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 <linux@arm.linux.org.uk>. So let's remove the
related dead code.

Cc: linux-fbdev at vger.kernel.org
Cc: alsa-devel at alsa-project.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index 30b891c..2b576f1 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -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);
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 49226a1..25db556 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -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
diff --git a/drivers/video/omap/lcd_omap2evm.c b/drivers/video/omap/lcd_omap2evm.c
deleted file mode 100644
index 7e7a65c..0000000
--- a/drivers/video/omap/lcd_omap2evm.c
+++ /dev/null
@@ -1,192 +0,0 @@
-/*
- * LCD panel support for the MISTRAL OMAP2EVM board
- *
- * Author: Arun C <arunedarath@mistralsolutions.com>
- *
- * Derived from drivers/video/omap/lcd_omap3evm.c
- * Derived from drivers/video/omap/lcd-apollon.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- */
-
-#include <linux/module.h>
-#include <linux/platform_device.h>
-#include <linux/gpio.h>
-#include <linux/i2c/twl.h>
-
-#include <plat/mux.h>
-#include <asm/mach-types.h>
-
-#include "omapfb.h"
-
-#define LCD_PANEL_ENABLE_GPIO	154
-#define LCD_PANEL_LR		128
-#define LCD_PANEL_UD		129
-#define LCD_PANEL_INI		152
-#define LCD_PANEL_QVGA		148
-#define LCD_PANEL_RESB		153
-
-#define TWL_LED_LEDEN		0x00
-#define TWL_PWMA_PWMAON		0x00
-#define TWL_PWMA_PWMAOFF	0x01
-
-static unsigned int bklight_level;
-
-static int omap2evm_panel_init(struct lcd_panel *panel,
-				struct omapfb_device *fbdev)
-{
-	gpio_request(LCD_PANEL_ENABLE_GPIO, "LCD enable");
-	gpio_request(LCD_PANEL_LR, "LCD lr");
-	gpio_request(LCD_PANEL_UD, "LCD ud");
-	gpio_request(LCD_PANEL_INI, "LCD ini");
-	gpio_request(LCD_PANEL_QVGA, "LCD qvga");
-	gpio_request(LCD_PANEL_RESB, "LCD resb");
-
-	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
-	gpio_direction_output(LCD_PANEL_RESB, 1);
-	gpio_direction_output(LCD_PANEL_INI, 1);
-	gpio_direction_output(LCD_PANEL_QVGA, 0);
-	gpio_direction_output(LCD_PANEL_LR, 1);
-	gpio_direction_output(LCD_PANEL_UD, 1);
-
-	twl_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
-	twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
-	twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02, TWL_PWMA_PWMAOFF);
-	bklight_level = 100;
-
-	return 0;
-}
-
-static void omap2evm_panel_cleanup(struct lcd_panel *panel)
-{
-	gpio_free(LCD_PANEL_RESB);
-	gpio_free(LCD_PANEL_QVGA);
-	gpio_free(LCD_PANEL_INI);
-	gpio_free(LCD_PANEL_UD);
-	gpio_free(LCD_PANEL_LR);
-	gpio_free(LCD_PANEL_ENABLE_GPIO);
-}
-
-static int omap2evm_panel_enable(struct lcd_panel *panel)
-{
-	gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0);
-	return 0;
-}
-
-static void omap2evm_panel_disable(struct lcd_panel *panel)
-{
-	gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1);
-}
-
-static unsigned long omap2evm_panel_get_caps(struct lcd_panel *panel)
-{
-	return 0;
-}
-
-static int omap2evm_bklight_setlevel(struct lcd_panel *panel,
-						unsigned int level)
-{
-	u8 c;
-	if ((level >= 0) && (level <= 100)) {
-		c = (125 * (100 - level)) / 100 + 2;
-		twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
-		bklight_level = level;
-	}
-	return 0;
-}
-
-static unsigned int omap2evm_bklight_getlevel(struct lcd_panel *panel)
-{
-	return bklight_level;
-}
-
-static unsigned int omap2evm_bklight_getmaxlevel(struct lcd_panel *panel)
-{
-	return 100;
-}
-
-struct lcd_panel omap2evm_panel = {
-	.name		= "omap2evm",
-	.config		= OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
-			  OMAP_LCDC_INV_HSYNC,
-
-	.bpp		= 16,
-	.data_lines	= 18,
-	.x_res		= 480,
-	.y_res		= 640,
-	.hsw		= 3,
-	.hfp		= 0,
-	.hbp		= 28,
-	.vsw		= 2,
-	.vfp		= 1,
-	.vbp		= 0,
-
-	.pixel_clock	= 20000,
-
-	.init		= omap2evm_panel_init,
-	.cleanup	= omap2evm_panel_cleanup,
-	.enable		= omap2evm_panel_enable,
-	.disable	= omap2evm_panel_disable,
-	.get_caps	= omap2evm_panel_get_caps,
-	.set_bklight_level      = omap2evm_bklight_setlevel,
-	.get_bklight_level      = omap2evm_bklight_getlevel,
-	.get_bklight_max        = omap2evm_bklight_getmaxlevel,
-};
-
-static int omap2evm_panel_probe(struct platform_device *pdev)
-{
-	omapfb_register_panel(&omap2evm_panel);
-	return 0;
-}
-
-static int omap2evm_panel_remove(struct platform_device *pdev)
-{
-	return 0;
-}
-
-static int omap2evm_panel_suspend(struct platform_device *pdev,
-				   pm_message_t mesg)
-{
-	return 0;
-}
-
-static int omap2evm_panel_resume(struct platform_device *pdev)
-{
-	return 0;
-}
-
-struct platform_driver omap2evm_panel_driver = {
-	.probe		= omap2evm_panel_probe,
-	.remove		= omap2evm_panel_remove,
-	.suspend	= omap2evm_panel_suspend,
-	.resume		= omap2evm_panel_resume,
-	.driver		= {
-		.name	= "omap2evm_lcd",
-		.owner	= THIS_MODULE,
-	},
-};
-
-static int __init omap2evm_panel_drv_init(void)
-{
-	return platform_driver_register(&omap2evm_panel_driver);
-}
-
-static void __exit omap2evm_panel_drv_exit(void)
-{
-	platform_driver_unregister(&omap2evm_panel_driver);
-}
-
-module_init(omap2evm_panel_drv_init);
-module_exit(omap2evm_panel_drv_exit);
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index ba9fc65..6c2c87e 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -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
diff --git a/sound/soc/omap/omap2evm.c b/sound/soc/omap/omap2evm.c
deleted file mode 100644
index 29b60d6..0000000
--- a/sound/soc/omap/omap2evm.c
+++ /dev/null
@@ -1,139 +0,0 @@
-/*
- * omap2evm.c  --  SoC audio machine driver for omap2evm board
- *
- * Author: Arun KS <arunks@mistralsolutions.com>
- *
- * Based on sound/soc/omap/overo.c by Steve Sakoman
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include <linux/clk.h>
-#include <linux/platform_device.h>
-#include <sound/core.h>
-#include <sound/pcm.h>
-#include <sound/soc.h>
-
-#include <asm/mach-types.h>
-#include <mach/hardware.h>
-#include <mach/gpio.h>
-#include <plat/mcbsp.h>
-
-#include "omap-mcbsp.h"
-#include "omap-pcm.h"
-
-static int omap2evm_hw_params(struct snd_pcm_substream *substream,
-	struct snd_pcm_hw_params *params)
-{
-	struct snd_soc_pcm_runtime *rtd = substream->private_data;
-	struct snd_soc_dai *codec_dai = rtd->codec_dai;
-	struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
-	int ret;
-
-	/* Set codec DAI configuration */
-	ret = snd_soc_dai_set_fmt(codec_dai,
-				  SND_SOC_DAIFMT_I2S |
-				  SND_SOC_DAIFMT_NB_NF |
-				  SND_SOC_DAIFMT_CBM_CFM);
-	if (ret < 0) {
-		printk(KERN_ERR "can't set codec DAI configuration\n");
-		return ret;
-	}
-
-	/* Set cpu DAI configuration */
-	ret = snd_soc_dai_set_fmt(cpu_dai,
-				  SND_SOC_DAIFMT_I2S |
-				  SND_SOC_DAIFMT_NB_NF |
-				  SND_SOC_DAIFMT_CBM_CFM);
-	if (ret < 0) {
-		printk(KERN_ERR "can't set cpu DAI configuration\n");
-		return ret;
-	}
-
-	/* Set the codec system clock for DAC and ADC */
-	ret = snd_soc_dai_set_sysclk(codec_dai, 0, 26000000,
-					    SND_SOC_CLOCK_IN);
-	if (ret < 0) {
-		printk(KERN_ERR "can't set codec system clock\n");
-		return ret;
-	}
-
-	return 0;
-}
-
-static struct snd_soc_ops omap2evm_ops = {
-	.hw_params = omap2evm_hw_params,
-};
-
-/* Digital audio interface glue - connects codec <--> CPU */
-static struct snd_soc_dai_link omap2evm_dai = {
-	.name = "TWL4030",
-	.stream_name = "TWL4030",
-	.cpu_dai_name = "omap-mcbsp-dai.1",
-	.codec_dai_name = "twl4030-hifi",
-	.platform_name = "omap-pcm-audio",
-	.codec_name = "twl4030-codec",
-	.ops = &omap2evm_ops,
-};
-
-/* Audio machine driver */
-static struct snd_soc_card snd_soc_omap2evm = {
-	.name = "omap2evm",
-	.dai_link = &omap2evm_dai,
-	.num_links = 1,
-};
-
-static struct platform_device *omap2evm_snd_device;
-
-static int __init omap2evm_soc_init(void)
-{
-	int ret;
-
-	if (!machine_is_omap2evm())
-		return -ENODEV;
-	printk(KERN_INFO "omap2evm SoC init\n");
-
-	omap2evm_snd_device = platform_device_alloc("soc-audio", -1);
-	if (!omap2evm_snd_device) {
-		printk(KERN_ERR "Platform device allocation failed\n");
-		return -ENOMEM;
-	}
-
-	platform_set_drvdata(omap2evm_snd_device, &snd_soc_omap2evm);
-
-	ret = platform_device_add(omap2evm_snd_device);
-	if (ret)
-		goto err1;
-
-	return 0;
-
-err1:
-	printk(KERN_ERR "Unable to add platform device\n");
-	platform_device_put(omap2evm_snd_device);
-
-	return ret;
-}
-module_init(omap2evm_soc_init);
-
-static void __exit omap2evm_soc_exit(void)
-{
-	platform_device_unregister(omap2evm_snd_device);
-}
-module_exit(omap2evm_soc_exit);
-
-MODULE_AUTHOR("Arun KS <arunks@mistralsolutions.com>");
-MODULE_DESCRIPTION("ALSA SoC omap2evm");
-MODULE_LICENSE("GPL");

Updated mach-types update

[Jarkko Nikula]

On Fri, 13 May 2011 04:54:07 -0700
Tony Lindgren <tony@atomide.com> wrote:

> * Tony Lindgren <tony@atomide.com> [110324 10:57]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > > 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.
> 
> 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.

Acked-by: Jarkko Nikula <jhnikula@gmail.com>

[PATCH] omap: Remove support for omap2evm (Re: Updated mach-types update)

[Tony Lindgren]

* Jarkko Nikula <jhnikula@gmail.com> [110513 05:15]:
> On Fri, 13 May 2011 04:54:07 -0700
> Tony Lindgren <tony@atomide.com> wrote:
> 
> > * Tony Lindgren <tony@atomide.com> [110324 10:57]:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > > > 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.
> > 
> > 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.

Thanks, here's the updated patch.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
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 <linux@arm.linux.org.uk>. So let's remove the
related dead code.

Cc: linux-fbdev at vger.kernel.org
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index 30b891c..2b576f1 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -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);
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 49226a1..25db556 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -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
diff --git a/drivers/video/omap/lcd_omap2evm.c b/drivers/video/omap/lcd_omap2evm.c
deleted file mode 100644
index 7e7a65c..0000000
--- a/drivers/video/omap/lcd_omap2evm.c
+++ /dev/null
@@ -1,192 +0,0 @@
-/*
- * LCD panel support for the MISTRAL OMAP2EVM board
- *
- * Author: Arun C <arunedarath@mistralsolutions.com>
- *
- * Derived from drivers/video/omap/lcd_omap3evm.c
- * Derived from drivers/video/omap/lcd-apollon.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- */
-
-#include <linux/module.h>
-#include <linux/platform_device.h>
-#include <linux/gpio.h>
-#include <linux/i2c/twl.h>
-
-#include <plat/mux.h>
-#include <asm/mach-types.h>
-
-#include "omapfb.h"
-
-#define LCD_PANEL_ENABLE_GPIO	154
-#define LCD_PANEL_LR		128
-#define LCD_PANEL_UD		129
-#define LCD_PANEL_INI		152
-#define LCD_PANEL_QVGA		148
-#define LCD_PANEL_RESB		153
-
-#define TWL_LED_LEDEN		0x00
-#define TWL_PWMA_PWMAON		0x00
-#define TWL_PWMA_PWMAOFF	0x01
-
-static unsigned int bklight_level;
-
-static int omap2evm_panel_init(struct lcd_panel *panel,
-				struct omapfb_device *fbdev)
-{
-	gpio_request(LCD_PANEL_ENABLE_GPIO, "LCD enable");
-	gpio_request(LCD_PANEL_LR, "LCD lr");
-	gpio_request(LCD_PANEL_UD, "LCD ud");
-	gpio_request(LCD_PANEL_INI, "LCD ini");
-	gpio_request(LCD_PANEL_QVGA, "LCD qvga");
-	gpio_request(LCD_PANEL_RESB, "LCD resb");
-
-	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
-	gpio_direction_output(LCD_PANEL_RESB, 1);
-	gpio_direction_output(LCD_PANEL_INI, 1);
-	gpio_direction_output(LCD_PANEL_QVGA, 0);
-	gpio_direction_output(LCD_PANEL_LR, 1);
-	gpio_direction_output(LCD_PANEL_UD, 1);
-
-	twl_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
-	twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
-	twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02, TWL_PWMA_PWMAOFF);
-	bklight_level = 100;
-
-	return 0;
-}
-
-static void omap2evm_panel_cleanup(struct lcd_panel *panel)
-{
-	gpio_free(LCD_PANEL_RESB);
-	gpio_free(LCD_PANEL_QVGA);
-	gpio_free(LCD_PANEL_INI);
-	gpio_free(LCD_PANEL_UD);
-	gpio_free(LCD_PANEL_LR);
-	gpio_free(LCD_PANEL_ENABLE_GPIO);
-}
-
-static int omap2evm_panel_enable(struct lcd_panel *panel)
-{
-	gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0);
-	return 0;
-}
-
-static void omap2evm_panel_disable(struct lcd_panel *panel)
-{
-	gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1);
-}
-
-static unsigned long omap2evm_panel_get_caps(struct lcd_panel *panel)
-{
-	return 0;
-}
-
-static int omap2evm_bklight_setlevel(struct lcd_panel *panel,
-						unsigned int level)
-{
-	u8 c;
-	if ((level >= 0) && (level <= 100)) {
-		c = (125 * (100 - level)) / 100 + 2;
-		twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
-		bklight_level = level;
-	}
-	return 0;
-}
-
-static unsigned int omap2evm_bklight_getlevel(struct lcd_panel *panel)
-{
-	return bklight_level;
-}
-
-static unsigned int omap2evm_bklight_getmaxlevel(struct lcd_panel *panel)
-{
-	return 100;
-}
-
-struct lcd_panel omap2evm_panel = {
-	.name		= "omap2evm",
-	.config		= OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
-			  OMAP_LCDC_INV_HSYNC,
-
-	.bpp		= 16,
-	.data_lines	= 18,
-	.x_res		= 480,
-	.y_res		= 640,
-	.hsw		= 3,
-	.hfp		= 0,
-	.hbp		= 28,
-	.vsw		= 2,
-	.vfp		= 1,
-	.vbp		= 0,
-
-	.pixel_clock	= 20000,
-
-	.init		= omap2evm_panel_init,
-	.cleanup	= omap2evm_panel_cleanup,
-	.enable		= omap2evm_panel_enable,
-	.disable	= omap2evm_panel_disable,
-	.get_caps	= omap2evm_panel_get_caps,
-	.set_bklight_level      = omap2evm_bklight_setlevel,
-	.get_bklight_level      = omap2evm_bklight_getlevel,
-	.get_bklight_max        = omap2evm_bklight_getmaxlevel,
-};
-
-static int omap2evm_panel_probe(struct platform_device *pdev)
-{
-	omapfb_register_panel(&omap2evm_panel);
-	return 0;
-}
-
-static int omap2evm_panel_remove(struct platform_device *pdev)
-{
-	return 0;
-}
-
-static int omap2evm_panel_suspend(struct platform_device *pdev,
-				   pm_message_t mesg)
-{
-	return 0;
-}
-
-static int omap2evm_panel_resume(struct platform_device *pdev)
-{
-	return 0;
-}
-
-struct platform_driver omap2evm_panel_driver = {
-	.probe		= omap2evm_panel_probe,
-	.remove		= omap2evm_panel_remove,
-	.suspend	= omap2evm_panel_suspend,
-	.resume		= omap2evm_panel_resume,
-	.driver		= {
-		.name	= "omap2evm_lcd",
-		.owner	= THIS_MODULE,
-	},
-};
-
-static int __init omap2evm_panel_drv_init(void)
-{
-	return platform_driver_register(&omap2evm_panel_driver);
-}
-
-static void __exit omap2evm_panel_drv_exit(void)
-{
-	platform_driver_unregister(&omap2evm_panel_driver);
-}
-
-module_init(omap2evm_panel_drv_init);
-module_exit(omap2evm_panel_drv_exit);
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index b592298..99054cf 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -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
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index ba9fc65..6c2c87e 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -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
diff --git a/sound/soc/omap/omap2evm.c b/sound/soc/omap/omap2evm.c
deleted file mode 100644
index 29b60d6..0000000
--- a/sound/soc/omap/omap2evm.c
+++ /dev/null
@@ -1,139 +0,0 @@
-/*
- * omap2evm.c  --  SoC audio machine driver for omap2evm board
- *
- * Author: Arun KS <arunks@mistralsolutions.com>
- *
- * Based on sound/soc/omap/overo.c by Steve Sakoman
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include <linux/clk.h>
-#include <linux/platform_device.h>
-#include <sound/core.h>
-#include <sound/pcm.h>
-#include <sound/soc.h>
-
-#include <asm/mach-types.h>
-#include <mach/hardware.h>
-#include <mach/gpio.h>
-#include <plat/mcbsp.h>
-
-#include "omap-mcbsp.h"
-#include "omap-pcm.h"
-
-static int omap2evm_hw_params(struct snd_pcm_substream *substream,
-	struct snd_pcm_hw_params *params)
-{
-	struct snd_soc_pcm_runtime *rtd = substream->private_data;
-	struct snd_soc_dai *codec_dai = rtd->codec_dai;
-	struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
-	int ret;
-
-	/* Set codec DAI configuration */
-	ret = snd_soc_dai_set_fmt(codec_dai,
-				  SND_SOC_DAIFMT_I2S |
-				  SND_SOC_DAIFMT_NB_NF |
-				  SND_SOC_DAIFMT_CBM_CFM);
-	if (ret < 0) {
-		printk(KERN_ERR "can't set codec DAI configuration\n");
-		return ret;
-	}
-
-	/* Set cpu DAI configuration */
-	ret = snd_soc_dai_set_fmt(cpu_dai,
-				  SND_SOC_DAIFMT_I2S |
-				  SND_SOC_DAIFMT_NB_NF |
-				  SND_SOC_DAIFMT_CBM_CFM);
-	if (ret < 0) {
-		printk(KERN_ERR "can't set cpu DAI configuration\n");
-		return ret;
-	}
-
-	/* Set the codec system clock for DAC and ADC */
-	ret = snd_soc_dai_set_sysclk(codec_dai, 0, 26000000,
-					    SND_SOC_CLOCK_IN);
-	if (ret < 0) {
-		printk(KERN_ERR "can't set codec system clock\n");
-		return ret;
-	}
-
-	return 0;
-}
-
-static struct snd_soc_ops omap2evm_ops = {
-	.hw_params = omap2evm_hw_params,
-};
-
-/* Digital audio interface glue - connects codec <--> CPU */
-static struct snd_soc_dai_link omap2evm_dai = {
-	.name = "TWL4030",
-	.stream_name = "TWL4030",
-	.cpu_dai_name = "omap-mcbsp-dai.1",
-	.codec_dai_name = "twl4030-hifi",
-	.platform_name = "omap-pcm-audio",
-	.codec_name = "twl4030-codec",
-	.ops = &omap2evm_ops,
-};
-
-/* Audio machine driver */
-static struct snd_soc_card snd_soc_omap2evm = {
-	.name = "omap2evm",
-	.dai_link = &omap2evm_dai,
-	.num_links = 1,
-};
-
-static struct platform_device *omap2evm_snd_device;
-
-static int __init omap2evm_soc_init(void)
-{
-	int ret;
-
-	if (!machine_is_omap2evm())
-		return -ENODEV;
-	printk(KERN_INFO "omap2evm SoC init\n");
-
-	omap2evm_snd_device = platform_device_alloc("soc-audio", -1);
-	if (!omap2evm_snd_device) {
-		printk(KERN_ERR "Platform device allocation failed\n");
-		return -ENOMEM;
-	}
-
-	platform_set_drvdata(omap2evm_snd_device, &snd_soc_omap2evm);
-
-	ret = platform_device_add(omap2evm_snd_device);
-	if (ret)
-		goto err1;
-
-	return 0;
-
-err1:
-	printk(KERN_ERR "Unable to add platform device\n");
-	platform_device_put(omap2evm_snd_device);
-
-	return ret;
-}
-module_init(omap2evm_soc_init);
-
-static void __exit omap2evm_soc_exit(void)
-{
-	platform_device_unregister(omap2evm_snd_device);
-}
-module_exit(omap2evm_soc_exit);
-
-MODULE_AUTHOR("Arun KS <arunks@mistralsolutions.com>");
-MODULE_DESCRIPTION("ALSA SoC omap2evm");
-MODULE_LICENSE("GPL");

[PATCH] omap: Remove support for omap2evm (Re: Updated mach-types update)

[Mark Brown]

On Fri, May 13, 2011 at 07:40:32AM -0700, Tony Lindgren wrote:

> 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 <linux@arm.linux.org.uk>. So let's remove the
> related dead code.

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

[PATCH] omap: Remove support for omap2evm (Re: Updated mach-types update)

[Liam Girdwood]

On 13/05/11 15:40, Tony Lindgren wrote:
> * Jarkko Nikula <jhnikula@gmail.com> [110513 05:15]:
>> On Fri, 13 May 2011 04:54:07 -0700
>> Tony Lindgren <tony@atomide.com> wrote:
>>
>>> * Tony Lindgren <tony@atomide.com> [110324 10:57]:
>>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
>>>>> 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.
>>>
>>> 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.
> 
> Thanks, here's the updated patch.
> 
> Regards,
> 
> Tony
> 
> 
> From: Tony Lindgren <tony@atomide.com>
> 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 <linux@arm.linux.org.uk>. So let's remove the
> related dead code.
> 
> Cc: linux-fbdev at vger.kernel.org
> Cc: alsa-devel at alsa-project.org
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Acked-by: Jarkko Nikula <jhnikula@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 

Acked-by: Liam Girdwood <lrg@ti.com>

Updated mach-types update

[Tomi Valkeinen]

On Fri, 2011-05-13 at 04:54 -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [110324 10:57]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > > 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.
> 
> 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:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

 Tomi

Updated mach-types update

[Detlef Vollmann]

On Sun, 20 Mar 2011 11:03:22 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> 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

Updated mach-types update

[Russell King - ARM Linux]

On Mon, Mar 21, 2011 at 11:41:50PM +0100, Detlef Vollmann wrote:
> On Sun, 20 Mar 2011 11:03:22 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > 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)?

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.

Updated mach-types update

[Detlef Vollmann]

On Mon, 21 Mar 2011 23:10:13 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> 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

Updated mach-types update

[Domenico Andreoli]

Hi Russell,

On Sun, Mar 20, 2011 at 12:03 PM, Russell King - ARM Linux <
linux@arm.linux.org.uk> wrote:

>
> 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.


> 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@^@,@"
>

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>

Updated mach-types update

[Russell King - ARM Linux]

On Tue, Mar 22, 2011 at 02:19:11PM +0100, Domenico Andreoli wrote:
> Hi Russell,
> 
> On Sun, Mar 20, 2011 at 12:03 PM, Russell King - ARM Linux <
> linux at arm.linux.org.uk> wrote:
> 
> >
> > 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?

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.

> 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.

> > 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@^@,@"
> >
> 
> 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.

> 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?

Updated mach-types update

[Domenico Andreoli]

Hi,

On Tue, Mar 22, 2011 at 07:30:26PM +0000, ext Russell King - ARM Linux wrote:
> On Tue, Mar 22, 2011 at 02:19:11PM +0100, Domenico Andreoli wrote:
> > On Sun, Mar 20, 2011 at 12:03 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > >
> > > 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?
> 
> 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.

> > 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

Updated mach-types update

[H Hartley Sweeten]

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

Updated mach-types update

[Colin Cross]

On Sun, Mar 20, 2011 at 4:03 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> 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")
>

This breaks master with CONFIG_PCI=y:
  CC      arch/arm/kernel/bios32.o
arch/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.

diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index d86fcd4..e4ee050 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -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)

Updated mach-types update

[Russell King - ARM Linux]

On Sat, Mar 26, 2011 at 03:52:04PM -0700, Colin Cross wrote:
> This breaks master with CONFIG_PCI=y:
>   CC      arch/arm/kernel/bios32.o
> arch/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.

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:

http://linux.bkbits.net:8080/linux-2.6/BitKeeper/deleted/.del-prpmc1100-pci.c~da88e9014dd6125b?PAGE=related

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.

Updated mach-types update

[Russell King - ARM Linux]

On Sat, Mar 26, 2011 at 11:14:19PM +0000, Russell King - ARM Linux wrote:
> On Sat, Mar 26, 2011 at 03:52:04PM -0700, Colin Cross wrote:
> > This breaks master with CONFIG_PCI=y:
> >   CC      arch/arm/kernel/bios32.o
> > arch/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.
> 
> 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:
> 
> http://linux.bkbits.net:8080/linux-2.6/BitKeeper/deleted/.del-prpmc1100-pci.c~da88e9014dd6125b?PAGE=related
> 
> 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.

Updated mach-types update

[Russell King - ARM Linux]

On Mon, Mar 28, 2011 at 07:00:24PM +0100, Russell King - ARM Linux wrote:
> On Sat, Mar 26, 2011 at 11:14:19PM +0000, Russell King - ARM Linux wrote:
> > On Sat, Mar 26, 2011 at 03:52:04PM -0700, Colin Cross wrote:
> > > This breaks master with CONFIG_PCI=y:
> > >   CC      arch/arm/kernel/bios32.o
> > > arch/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.
> > 
> > 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:
> > 
> > http://linux.bkbits.net:8080/linux-2.6/BitKeeper/deleted/.del-prpmc1100-pci.c~da88e9014dd6125b?PAGE=related
> > 
> > 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.

Updated mach-types update

[Jaya Kumar]

On Sun, Mar 20, 2011 at 7:03 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> 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

Updated mach-types update

[Russell King - ARM Linux]

On Sat, May 21, 2011 at 09:35:29AM +0800, Jaya Kumar wrote:
> On Sun, Mar 20, 2011 at 7:03 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > 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.

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.

Updated mach-types update

[Arnd Bergmann]

On Sunday 22 May 2011, Russell King - ARM Linux wrote:
> On Sat, May 21, 2011 at 09:35:29AM +0800, Jaya Kumar wrote:
> > On Sun, Mar 20, 2011 at 7:03 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > >
> > > 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:
> > 
> > 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

Updated mach-types update

[Russell King - ARM Linux]

On Mon, May 23, 2011 at 04:52:28PM +0200, Arnd Bergmann wrote:
> 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.

Updated mach-types update

[Mark Brown]

On Mon, May 23, 2011 at 03:59:14PM +0100, Russell King - ARM Linux wrote:

> 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?

> 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.

Updated mach-types update

[Russell King - ARM Linux]

On Mon, May 23, 2011 at 04:10:51PM +0100, Mark Brown wrote:
> On Mon, May 23, 2011 at 03:59:14PM +0100, Russell King - ARM Linux wrote:
> 
> > 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.

Updated mach-types update

[Arnd Bergmann]

On Monday 23 May 2011, Russell King - ARM Linux wrote:
> 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

Updated mach-types update

[Jaya Kumar]

On Tue, May 24, 2011 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> 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

[1] http://www.spinics.net/lists/arm-kernel/msg125769.html

Updated mach-types update

[Arnd Bergmann]

On Tuesday 24 May 2011, Jaya Kumar wrote:

> 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]

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

Updated mach-types update

[Mark Brown]

On Mon, May 23, 2011 at 06:39:56PM +0200, Arnd Bergmann wrote:
> On Monday 23 May 2011, Russell King - ARM Linux wrote:

> > 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.

> 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.