[PATCH 00/26] ARM: pxa specific randconfig fixes

[PATCH 00/26] ARM: pxa specific randconfig fixes

[Arnd Bergmann]

Hi Eric (and others),

Here are lots of tiny bug fixes (and a few bigger ones)
for the pxa platform that I found by running 'make randconfig'.

Could you take a look at these and see if they make sense to
you? The majority is just for corner cases that we are not
generally interested in, except for making sure that
randconfig works, but some are regressions from a previously
working state or are for relevant configurations.

It would be nice if you could either give me an ok to put
all off them into the arm-soc tree for the coming merge window
or cherry-pick the ones that are good and send them back
to me in a pull request.

The series is also available in git at
 git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/pxa

but I haven't added it to the for-next branch for now.

	Arnd

Arnd Bergmann (26): 
  usb/gadget/pxa25x: is_vbus_present is gone
  sound/pxa-zylonite: use a valid device for dev_err()
  scsi/mvsas: use proper namespace for IRQ_* symbols
  net/pxa168_eth: add missing include of interrupt.h
  ARM: pxa: make zylonite_pxa*_init declaration match code
  ARM: pxa: add missing header inclusions
  ARM: pxa: mbxfb: disable broken debugfs code
  ARM: pxa: move z2 to generic cpu_suspend
  ARM: pxa: export symbols from pxa3xx-ulpi
  ARM: pxa: allow selecting just one of TREO680/CENTRO
  ARM: pxa: allow building palm27x without pxafb
  ARM: pxa: pxa95x/saarb depends on pxa3xx code
  ARM: pxa: use correct __iomem annotations
  mtd: nand_h1900 never worked
  irda/ficp: only works on some pxa models
  ARM: pxa: CPU_PJ4 requires IWMMXT
  ARM: pxa: pxa95x is incompatible with earlier pxa
  ARM: pxa: MTD_XIP is not actually working any more
  ARM: pxa: CPU_FREQ_TABLE is needed for CPU_FREQ
  ARM: pxa: select FB_PXA on saar and tevorevb
  ARM: pxa: select POWER_SUPPLY on raumfeld
  ARM: pxa: only select SMC91x on xcep when networking is enabled
  ARM: pxa: viper: select I2C_GPIO only when I2C is on
  ARM: pxa: centro and treo680 need palm27x
  ARM: pxa: eseries does not require FB
  ARM: pxa: sharpsl pm needs SPI

 arch/arm/Kconfig                          |    4 +-
 arch/arm/include/asm/hardware/it8152.h    |    2 +-
 arch/arm/mach-mmp/clock.h                 |    8 ++--
 arch/arm/mach-mmp/common.c                |    4 +-
 arch/arm/mach-mmp/include/mach/addr-map.h |   10 ++++-
 arch/arm/mach-mmp/mmp2.c                  |    3 +-
 arch/arm/mach-pxa/Kconfig                 |   48 ++++++++++++++++++------
 arch/arm/mach-pxa/Makefile                |    2 +-
 arch/arm/mach-pxa/balloon3.c              |   10 ++--
 arch/arm/mach-pxa/cm-x2xx-pci.c           |    2 +-
 arch/arm/mach-pxa/cm-x2xx.c               |    4 +-
 arch/arm/mach-pxa/include/mach/addr-map.h |    8 ++--
 arch/arm/mach-pxa/include/mach/balloon3.h |    2 +-
 arch/arm/mach-pxa/include/mach/hardware.h |    9 ++--
 arch/arm/mach-pxa/include/mach/lpd270.h   |    4 +-
 arch/arm/mach-pxa/include/mach/mtd-xip.h  |    1 -
 arch/arm/mach-pxa/include/mach/palm27x.h  |    2 +-
 arch/arm/mach-pxa/include/mach/palmtx.h   |    6 +-
 arch/arm/mach-pxa/include/mach/smemc.h    |    2 +-
 arch/arm/mach-pxa/include/mach/zeus.h     |    4 +-
 arch/arm/mach-pxa/include/mach/zylonite.h |    4 +-
 arch/arm/mach-pxa/irq.c                   |    5 +-
 arch/arm/mach-pxa/lpd270.c                |    2 +-
 arch/arm/mach-pxa/palmtreo.c              |    8 ++++
 arch/arm/mach-pxa/palmtx.c                |    8 ++--
 arch/arm/mach-pxa/pxa25x.c                |    2 +-
 arch/arm/mach-pxa/pxa27x.c                |    2 +-
 arch/arm/mach-pxa/pxa3xx-ulpi.c           |    2 +
 arch/arm/mach-pxa/pxa3xx.c                |    2 +-
 arch/arm/mach-pxa/saarb.c                 |    2 +
 arch/arm/mach-pxa/z2.c                    |    3 +-
 arch/arm/mach-pxa/zeus.c                  |    8 ++--
 arch/arm/plat-pxa/gpio.c                  |    2 +-
 arch/arm/plat-pxa/include/plat/mfp.h      |    2 +-
 arch/arm/plat-pxa/mfp.c                   |    4 +-
 drivers/mtd/nand/Kconfig                  |    2 +-
 drivers/net/irda/Kconfig                  |    2 +-
 drivers/net/pxa168_eth.c                  |    1 +
 drivers/pcmcia/pxa2xx_balloon3.c          |    2 +-
 drivers/scsi/mvsas/mv_94xx.c              |   10 ++--
 drivers/scsi/mvsas/mv_94xx.h              |   58 ++++++++++++++--------------
 drivers/usb/gadget/pxa25x_udc.h           |    8 +---
 drivers/video/Kconfig                     |    2 +-
 drivers/video/mbx/Makefile                |    2 +-
 drivers/video/mbx/mbxfb.c                 |    6 +-
 sound/soc/pxa/zylonite.c                  |    8 ++--
 46 files changed, 166 insertions(+), 126 deletions(-)

-- 
1.7.5.4

[PATCH 01/26] usb/gadget/pxa25x: is_vbus_present is gone

[Arnd Bergmann]

A recent commit obsoleted the is_vbus_present function, so
we must not use it any more.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/gadget/pxa25x_udc.h |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/pxa25x_udc.h b/drivers/usb/gadget/pxa25x_udc.h
index f572c56..6119900 100644
--- a/drivers/usb/gadget/pxa25x_udc.h
+++ b/drivers/usb/gadget/pxa25x_udc.h
@@ -161,8 +161,6 @@ static struct pxa25x_udc *the_controller;
 
 #ifdef DEBUG
 
-static int is_vbus_present(void);
-
 static const char *state_name[] = {
 	"EP0_IDLE",
 	"EP0_IN_DATA_PHASE", "EP0_OUT_DATA_PHASE",
@@ -214,8 +212,7 @@ dump_state(struct pxa25x_udc *dev)
 	u32		tmp;
 	unsigned	i;
 
-	DMSG("%s %s, uicr %02X.%02X, usir %02X.%02x, ufnr %02X.%02X\n",
-		is_vbus_present() ? "host " : "disconnected",
+	DMSG("%s, uicr %02X.%02X, usir %02X.%02x, ufnr %02X.%02X\n",
 		state_name[dev->ep0state],
 		UICR1, UICR0, USIR1, USIR0, UFNRH, UFNRL);
 	dump_udccr("udccr");
@@ -232,9 +229,6 @@ dump_state(struct pxa25x_udc *dev)
 	} else
 		DMSG("ep0 driver '%s'\n", dev->driver->driver.name);
 
-	if (!is_vbus_present())
-		return;
-
 	dump_udccs0 ("udccs0");
 	DMSG("ep0 IN %lu/%lu, OUT %lu/%lu\n",
 		dev->stats.write.bytes, dev->stats.write.ops,
-- 
1.7.5.4

[PATCH 01/26] usb/gadget/pxa25x: is_vbus_present is gone

[Felipe Balbi]

Hi,

On Sat, Oct 01, 2011 at 10:03:33PM +0200, Arnd Bergmann wrote:
> A recent commit obsoleted the is_vbus_present function, so
> we must not use it any more.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>

If you want to carry this through your tree, I'm fine with it:

Acked-by: Felipe Balbi <balbi@ti.com>

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111006/25b7f08e/attachment.sig>

[PATCH 01/26] usb/gadget/pxa25x: is_vbus_present is gone

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> A recent commit obsoleted the is_vbus_present function, so
> we must not use it any more.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>

Acked-by: Eric Miao <eric.y.miao@gmail.com>

> ---
> ?drivers/usb/gadget/pxa25x_udc.h | ? ?8 +-------
> ?1 files changed, 1 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/gadget/pxa25x_udc.h b/drivers/usb/gadget/pxa25x_udc.h
> index f572c56..6119900 100644
> --- a/drivers/usb/gadget/pxa25x_udc.h
> +++ b/drivers/usb/gadget/pxa25x_udc.h
> @@ -161,8 +161,6 @@ static struct pxa25x_udc *the_controller;
>
> ?#ifdef DEBUG
>
> -static int is_vbus_present(void);
> -
> ?static const char *state_name[] = {
> ? ? ? ?"EP0_IDLE",
> ? ? ? ?"EP0_IN_DATA_PHASE", "EP0_OUT_DATA_PHASE",
> @@ -214,8 +212,7 @@ dump_state(struct pxa25x_udc *dev)
> ? ? ? ?u32 ? ? ? ? ? ? tmp;
> ? ? ? ?unsigned ? ? ? ?i;
>
> - ? ? ? DMSG("%s %s, uicr %02X.%02X, usir %02X.%02x, ufnr %02X.%02X\n",
> - ? ? ? ? ? ? ? is_vbus_present() ? "host " : "disconnected",
> + ? ? ? DMSG("%s, uicr %02X.%02X, usir %02X.%02x, ufnr %02X.%02X\n",
> ? ? ? ? ? ? ? ?state_name[dev->ep0state],
> ? ? ? ? ? ? ? ?UICR1, UICR0, USIR1, USIR0, UFNRH, UFNRL);
> ? ? ? ?dump_udccr("udccr");
> @@ -232,9 +229,6 @@ dump_state(struct pxa25x_udc *dev)
> ? ? ? ?} else
> ? ? ? ? ? ? ? ?DMSG("ep0 driver '%s'\n", dev->driver->driver.name);
>
> - ? ? ? if (!is_vbus_present())
> - ? ? ? ? ? ? ? return;
> -
> ? ? ? ?dump_udccs0 ("udccs0");
> ? ? ? ?DMSG("ep0 IN %lu/%lu, OUT %lu/%lu\n",
> ? ? ? ? ? ? ? ?dev->stats.write.bytes, dev->stats.write.ops,
> --
> 1.7.5.4
>
>

[PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()

[Arnd Bergmann]

A recent conversion has introduced references to &pdev->dev, which does
not actually exist in all the contexts it's used in.

Replace this with card->dev where necessary, in order to let
the driver build again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 sound/soc/pxa/zylonite.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/pxa/zylonite.c b/sound/soc/pxa/zylonite.c
index b644575..2b8350b 100644
--- a/sound/soc/pxa/zylonite.c
+++ b/sound/soc/pxa/zylonite.c
@@ -196,20 +196,20 @@ static int zylonite_probe(struct snd_soc_card *card)
 	if (clk_pout) {
 		pout = clk_get(NULL, "CLK_POUT");
 		if (IS_ERR(pout)) {
-			dev_err(&pdev->dev, "Unable to obtain CLK_POUT: %ld\n",
+			dev_err(card->dev, "Unable to obtain CLK_POUT: %ld\n",
 				PTR_ERR(pout));
 			return PTR_ERR(pout);
 		}
 
 		ret = clk_enable(pout);
 		if (ret != 0) {
-			dev_err(&pdev->dev, "Unable to enable CLK_POUT: %d\n",
+			dev_err(card->dev, "Unable to enable CLK_POUT: %d\n",
 				ret);
 			clk_put(pout);
 			return ret;
 		}
 
-		dev_dbg(&pdev->dev, "MCLK enabled at %luHz\n",
+		dev_dbg(card->dev, "MCLK enabled at %luHz\n",
 			clk_get_rate(pout));
 	}
 
@@ -241,7 +241,7 @@ static int zylonite_resume_pre(struct snd_soc_card *card)
 	if (clk_pout) {
 		ret = clk_enable(pout);
 		if (ret != 0)
-			dev_err(&pdev->dev, "Unable to enable CLK_POUT: %d\n",
+			dev_err(card->dev, "Unable to enable CLK_POUT: %d\n",
 				ret);
 	}
 
-- 
1.7.5.4

[PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()

[Mark Brown]

On Sat, Oct 01, 2011 at 10:03:34PM +0200, Arnd Bergmann wrote:
> A recent conversion has introduced references to &pdev->dev, which does
> not actually exist in all the contexts it's used in.

> Replace this with card->dev where necessary, in order to let
> the driver build again.

Applied, thanks.  I'm a bit confused about why this is buried in the
middle of some enormous series of some kind?

[PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()

[Arnd Bergmann]

On Sunday 02 October 2011 19:16:11 Mark Brown wrote:
> On Sat, Oct 01, 2011 at 10:03:34PM +0200, Arnd Bergmann wrote:
> > A recent conversion has introduced references to &pdev->dev, which does
> > not actually exist in all the contexts it's used in.
> 
> > Replace this with card->dev where necessary, in order to let
> > the driver build again.
> 
> Applied, thanks.  I'm a bit confused about why this is buried in the
> middle of some enormous series of some kind?

The series is about trivial build fixes that are specific to pxa.
I was expecting most of them to go through the pxa tree because
I figured out would be easier to keep them together like this.

I also have a few sound/soc fixes in the respective samsung and
omap series, so if you prefer I can move them to a sound/soc
series and submit them all at once to you instead.

> Oh, and please do try to use subject lines which match up with the rest
> of the code you're patching - in this case it even looks like whatever
> you're using to autogenerate is misfiring as you've got a combination of
> - and / in filenames.

The subject line was hand-written, any problem in there is purely
my own. What is the naming you want for sound/soc, should I use
"ASoC: pxa-zylonite:" or "sound/soc/pxa/zylonite:" or something
else?

	Arnd

[PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()

[Mark Brown]

On Sun, Oct 02, 2011 at 08:36:14PM +0200, Arnd Bergmann wrote:

> I also have a few sound/soc fixes in the respective samsung and
> omap series, so if you prefer I can move them to a sound/soc
> series and submit them all at once to you instead.

Please do.  It's probably not so important at this point in the release
cycle but we've got a tendency to run into cross tree issues with ASoC
and when it's not trivial build stuff I'd rather review anyway.

Please split the OMAP stuff out, Liam manages the tree for those when
he's available (though right now he's only intermittently online so I'm
applying those too).

> The subject line was hand-written, any problem in there is purely
> my own. What is the naming you want for sound/soc, should I use
> "ASoC: pxa-zylonite:" or "sound/soc/pxa/zylonite:" or something
> else?

ASoC: is the bit that I'm looking for.

[PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()

[Arnd Bergmann]

On Sunday 02 October 2011 19:44:17 Mark Brown wrote:
> On Sun, Oct 02, 2011 at 08:36:14PM +0200, Arnd Bergmann wrote:
> 
> > I also have a few sound/soc fixes in the respective samsung and
> > omap series, so if you prefer I can move them to a sound/soc
> > series and submit them all at once to you instead.
> 
> Please do.  It's probably not so important at this point in the release
> cycle but we've got a tendency to run into cross tree issues with ASoC
> and when it's not trivial build stuff I'd rather review anyway.
> 
> Please split the OMAP stuff out, Liam manages the tree for those when
> he's available (though right now he's only intermittently online so I'm
> applying those too).

Almost all the patches I have are both trivial and unimportant corner
cases. I'm removing the ones I have from all the other branches now
and will try to get them to you both asap.

> > The subject line was hand-written, any problem in there is purely
> > my own. What is the naming you want for sound/soc, should I use
> > "ASoC: pxa-zylonite:" or "sound/soc/pxa/zylonite:" or something
> > else?
> 
> ASoC: is the bit that I'm looking for.

Ok, got it.

	Arnd

[PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()

[Mark Brown]

On Sat, Oct 01, 2011 at 10:03:34PM +0200, Arnd Bergmann wrote:
> A recent conversion has introduced references to &pdev->dev, which does
> not actually exist in all the contexts it's used in.

Oh, and please do try to use subject lines which match up with the rest
of the code you're patching - in this case it even looks like whatever
you're using to autogenerate is misfiring as you've got a combination of
- and / in filenames.

[PATCH 03/26] scsi/mvsas: use proper namespace for IRQ_* symbols

[Arnd Bergmann]

The identifiers in the mvsas driver conflict with platform specific
interrupt definitions of the same name, so better prefix them
with MVS_ to avoid the collision.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Xiangliang Yu <yuxiangl@marvell.com>
Cc: James Bottomley <James.Bottomley@suse.de>
Cc: linux-scsi at vger.kernel.org
---
 drivers/scsi/mvsas/mv_94xx.c |   10 +++---
 drivers/scsi/mvsas/mv_94xx.h |   58 +++++++++++++++++++++---------------------
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_94xx.c b/drivers/scsi/mvsas/mv_94xx.c
index 3501291..9c12e03 100644
--- a/drivers/scsi/mvsas/mv_94xx.c
+++ b/drivers/scsi/mvsas/mv_94xx.c
@@ -534,7 +534,7 @@ static void mvs_94xx_interrupt_enable(struct mvs_info *mvi)
 	u32 tmp;
 
 	tmp = mr32(MVS_GBL_CTL);
-	tmp |= (IRQ_SAS_A | IRQ_SAS_B);
+	tmp |= (MVS_IRQ_SAS_A | MVS_IRQ_SAS_B);
 	mw32(MVS_GBL_INT_STAT, tmp);
 	writel(tmp, regs + 0x0C);
 	writel(tmp, regs + 0x10);
@@ -550,7 +550,7 @@ static void mvs_94xx_interrupt_disable(struct mvs_info *mvi)
 
 	tmp = mr32(MVS_GBL_CTL);
 
-	tmp &= ~(IRQ_SAS_A | IRQ_SAS_B);
+	tmp &= ~(MVS_IRQ_SAS_A | MVS_IRQ_SAS_B);
 	mw32(MVS_GBL_INT_STAT, tmp);
 	writel(tmp, regs + 0x0C);
 	writel(tmp, regs + 0x10);
@@ -566,7 +566,7 @@ static u32 mvs_94xx_isr_status(struct mvs_info *mvi, int irq)
 	if (!(mvi->flags & MVF_FLAG_SOC)) {
 		stat = mr32(MVS_GBL_INT_STAT);
 
-		if (!(stat & (IRQ_SAS_A | IRQ_SAS_B)))
+		if (!(stat & (MVS_IRQ_SAS_A | MVS_IRQ_SAS_B)))
 			return 0;
 	}
 	return stat;
@@ -576,8 +576,8 @@ static irqreturn_t mvs_94xx_isr(struct mvs_info *mvi, int irq, u32 stat)
 {
 	void __iomem *regs = mvi->regs;
 
-	if (((stat & IRQ_SAS_A) && mvi->id == 0) ||
-			((stat & IRQ_SAS_B) && mvi->id == 1)) {
+	if (((stat & MVS_IRQ_SAS_A) && mvi->id == 0) ||
+			((stat & MVS_IRQ_SAS_B) && mvi->id == 1)) {
 		mw32_f(MVS_INT_STAT, CINT_DONE);
 
 		spin_lock(&mvi->lock);
diff --git a/drivers/scsi/mvsas/mv_94xx.h b/drivers/scsi/mvsas/mv_94xx.h
index 8f7eb4f..5bc7656 100644
--- a/drivers/scsi/mvsas/mv_94xx.h
+++ b/drivers/scsi/mvsas/mv_94xx.h
@@ -150,35 +150,35 @@ enum chip_register_bits {
 
 enum pci_interrupt_cause {
 	/*  MAIN_IRQ_CAUSE (R10200) Bits*/
-	IRQ_COM_IN_I2O_IOP0            = (1 << 0),
-	IRQ_COM_IN_I2O_IOP1            = (1 << 1),
-	IRQ_COM_IN_I2O_IOP2            = (1 << 2),
-	IRQ_COM_IN_I2O_IOP3            = (1 << 3),
-	IRQ_COM_OUT_I2O_HOS0           = (1 << 4),
-	IRQ_COM_OUT_I2O_HOS1           = (1 << 5),
-	IRQ_COM_OUT_I2O_HOS2           = (1 << 6),
-	IRQ_COM_OUT_I2O_HOS3           = (1 << 7),
-	IRQ_PCIF_TO_CPU_DRBL0          = (1 << 8),
-	IRQ_PCIF_TO_CPU_DRBL1          = (1 << 9),
-	IRQ_PCIF_TO_CPU_DRBL2          = (1 << 10),
-	IRQ_PCIF_TO_CPU_DRBL3          = (1 << 11),
-	IRQ_PCIF_DRBL0                 = (1 << 12),
-	IRQ_PCIF_DRBL1                 = (1 << 13),
-	IRQ_PCIF_DRBL2                 = (1 << 14),
-	IRQ_PCIF_DRBL3                 = (1 << 15),
-	IRQ_XOR_A                      = (1 << 16),
-	IRQ_XOR_B                      = (1 << 17),
-	IRQ_SAS_A                      = (1 << 18),
-	IRQ_SAS_B                      = (1 << 19),
-	IRQ_CPU_CNTRL                  = (1 << 20),
-	IRQ_GPIO                       = (1 << 21),
-	IRQ_UART                       = (1 << 22),
-	IRQ_SPI                        = (1 << 23),
-	IRQ_I2C                        = (1 << 24),
-	IRQ_SGPIO                      = (1 << 25),
-	IRQ_COM_ERR                    = (1 << 29),
-	IRQ_I2O_ERR                    = (1 << 30),
-	IRQ_PCIE_ERR                   = (1 << 31),
+	MVS_IRQ_COM_IN_I2O_IOP0            = (1 << 0),
+	MVS_IRQ_COM_IN_I2O_IOP1            = (1 << 1),
+	MVS_IRQ_COM_IN_I2O_IOP2            = (1 << 2),
+	MVS_IRQ_COM_IN_I2O_IOP3            = (1 << 3),
+	MVS_IRQ_COM_OUT_I2O_HOS0           = (1 << 4),
+	MVS_IRQ_COM_OUT_I2O_HOS1           = (1 << 5),
+	MVS_IRQ_COM_OUT_I2O_HOS2           = (1 << 6),
+	MVS_IRQ_COM_OUT_I2O_HOS3           = (1 << 7),
+	MVS_IRQ_PCIF_TO_CPU_DRBL0          = (1 << 8),
+	MVS_IRQ_PCIF_TO_CPU_DRBL1          = (1 << 9),
+	MVS_IRQ_PCIF_TO_CPU_DRBL2          = (1 << 10),
+	MVS_IRQ_PCIF_TO_CPU_DRBL3          = (1 << 11),
+	MVS_IRQ_PCIF_DRBL0                 = (1 << 12),
+	MVS_IRQ_PCIF_DRBL1                 = (1 << 13),
+	MVS_IRQ_PCIF_DRBL2                 = (1 << 14),
+	MVS_IRQ_PCIF_DRBL3                 = (1 << 15),
+	MVS_IRQ_XOR_A                      = (1 << 16),
+	MVS_IRQ_XOR_B                      = (1 << 17),
+	MVS_IRQ_SAS_A                      = (1 << 18),
+	MVS_IRQ_SAS_B                      = (1 << 19),
+	MVS_IRQ_CPU_CNTRL                  = (1 << 20),
+	MVS_IRQ_GPIO                       = (1 << 21),
+	MVS_IRQ_UART                       = (1 << 22),
+	MVS_IRQ_SPI                        = (1 << 23),
+	MVS_IRQ_I2C                        = (1 << 24),
+	MVS_IRQ_SGPIO                      = (1 << 25),
+	MVS_IRQ_COM_ERR                    = (1 << 29),
+	MVS_IRQ_I2O_ERR                    = (1 << 30),
+	MVS_IRQ_PCIE_ERR                   = (1 << 31),
 };
 
 union reg_phy_cfg {
-- 
1.7.5.4

[PATCH 04/26] net/pxa168_eth: add missing include of interrupt.h

[Arnd Bergmann]

interrupt.h is no longer implicitly included here, so manually
add it instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/pxa168_eth.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
index 1a3033d..d5a6cfc 100644
--- a/drivers/net/pxa168_eth.c
+++ b/drivers/net/pxa168_eth.c
@@ -41,6 +41,7 @@
 #include <linux/phy.h>
 #include <linux/io.h>
 #include <linux/types.h>
+#include <linux/interrupt.h>
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/cacheflush.h>
-- 
1.7.5.4

[PATCH 04/26] net/pxa168_eth: add missing include of interrupt.h

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> interrupt.h is no longer implicitly included here, so manually
> add it instead.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

> ---
> ?drivers/net/pxa168_eth.c | ? ?1 +
> ?1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
> index 1a3033d..d5a6cfc 100644
> --- a/drivers/net/pxa168_eth.c
> +++ b/drivers/net/pxa168_eth.c
> @@ -41,6 +41,7 @@
> ?#include <linux/phy.h>
> ?#include <linux/io.h>
> ?#include <linux/types.h>
> +#include <linux/interrupt.h>
> ?#include <asm/pgtable.h>
> ?#include <asm/system.h>
> ?#include <asm/cacheflush.h>
> --
> 1.7.5.4
>
>

[PATCH 05/26] ARM: pxa: make zylonite_pxa*_init declaration match code

[Arnd Bergmann]

When support for zylonite is disabled, the zylonite_pxa300_init
and zylonite_pxa320_init functions are not there, but the declaration
is still kept around if any other boards for the same soc are
enabled. This changes the declaration to be conditional on the
same symbol as the code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/include/mach/zylonite.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-pxa/include/mach/zylonite.h b/arch/arm/mach-pxa/include/mach/zylonite.h
index ea24998..ecca976 100644
--- a/arch/arm/mach-pxa/include/mach/zylonite.h
+++ b/arch/arm/mach-pxa/include/mach/zylonite.h
@@ -19,7 +19,7 @@ extern int wm9713_irq;
 extern int lcd_id;
 extern int lcd_orientation;
 
-#ifdef CONFIG_CPU_PXA300
+#ifdef CONFIG_MACH_ZYLONITE300
 extern void zylonite_pxa300_init(void);
 #else
 static inline void zylonite_pxa300_init(void)
@@ -29,7 +29,7 @@ static inline void zylonite_pxa300_init(void)
 }
 #endif
 
-#ifdef CONFIG_CPU_PXA320
+#ifdef CONFIG_MACH_ZYLONITE320
 extern void zylonite_pxa320_init(void);
 #else
 static inline void zylonite_pxa320_init(void)
-- 
1.7.5.4

[PATCH 05/26] ARM: pxa: make zylonite_pxa*_init declaration match code

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> When support for zylonite is disabled, the zylonite_pxa300_init
> and zylonite_pxa320_init functions are not there, but the declaration
> is still kept around if any other boards for the same soc are
> enabled. This changes the declaration to be conditional on the
> same symbol as the code.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

> ---
> ?arch/arm/mach-pxa/include/mach/zylonite.h | ? ?4 ++--
> ?1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/include/mach/zylonite.h b/arch/arm/mach-pxa/include/mach/zylonite.h
> index ea24998..ecca976 100644
> --- a/arch/arm/mach-pxa/include/mach/zylonite.h
> +++ b/arch/arm/mach-pxa/include/mach/zylonite.h
> @@ -19,7 +19,7 @@ extern int wm9713_irq;
> ?extern int lcd_id;
> ?extern int lcd_orientation;
>
> -#ifdef CONFIG_CPU_PXA300
> +#ifdef CONFIG_MACH_ZYLONITE300
> ?extern void zylonite_pxa300_init(void);
> ?#else
> ?static inline void zylonite_pxa300_init(void)
> @@ -29,7 +29,7 @@ static inline void zylonite_pxa300_init(void)
> ?}
> ?#endif
>
> -#ifdef CONFIG_CPU_PXA320
> +#ifdef CONFIG_MACH_ZYLONITE320
> ?extern void zylonite_pxa320_init(void);
> ?#else
> ?static inline void zylonite_pxa320_init(void)
> --
> 1.7.5.4
>
>

[PATCH 06/26] ARM: pxa: add missing header inclusions

[Arnd Bergmann]

These resulted in build breakage in some configurations:

arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/irq.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index b09e848..848e96d 100644
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/syscore_ops.h>
+#include <linux/ftrace.h>
 #include <linux/io.h>
 #include <linux/irq.h>
 
-- 
1.7.5.4

[PATCH 06/26] ARM: pxa: add missing header inclusions

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> These resulted in build breakage in some configurations:
>
> arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/irq.c | ? ?1 +
> ?1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> index b09e848..848e96d 100644
> --- a/arch/arm/mach-pxa/irq.c
> +++ b/arch/arm/mach-pxa/irq.c
> @@ -16,6 +16,7 @@
> ?#include <linux/module.h>
> ?#include <linux/interrupt.h>
> ?#include <linux/syscore_ops.h>
> +#include <linux/ftrace.h>

It's actually __irq_entry being defined in <linux/ftrace.h> and in turn
__exception_irq_entry being conditionally defined to that.

I think it's better to fix this in <asm/system.h> instead of in the
cases where this macro is referenced?

Russell?

> ?#include <linux/io.h>
> ?#include <linux/irq.h>
>
> --
> 1.7.5.4
>
>

[PATCH 06/26] ARM: pxa: add missing header inclusions

[Russell King - ARM Linux]

On Fri, Oct 07, 2011 at 01:08:23PM +0800, Eric Miao wrote:
> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > These resulted in build breakage in some configurations:
> >
> > arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > ?arch/arm/mach-pxa/irq.c | ? ?1 +
> > ?1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> > index b09e848..848e96d 100644
> > --- a/arch/arm/mach-pxa/irq.c
> > +++ b/arch/arm/mach-pxa/irq.c
> > @@ -16,6 +16,7 @@
> > ?#include <linux/module.h>
> > ?#include <linux/interrupt.h>
> > ?#include <linux/syscore_ops.h>
> > +#include <linux/ftrace.h>
> 
> It's actually __irq_entry being defined in <linux/ftrace.h> and in turn
> __exception_irq_entry being conditionally defined to that.
> 
> I think it's better to fix this in <asm/system.h> instead of in the
> cases where this macro is referenced?
> 
> Russell?

There's a patch in the patch system which fixes this (7115/3) but I
can't apply it because it doesn't apply to anything in my for-next
tree (it applies to the obsolete 'devel' branch which is rather old
now.)

[PATCH 06/26] ARM: pxa: add missing header inclusions

[Jamie Iles]

On Sat, Oct 08, 2011 at 09:03:09AM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 07, 2011 at 01:08:23PM +0800, Eric Miao wrote:
> > On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > These resulted in build breakage in some configurations:
> > >
> > > arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > ?arch/arm/mach-pxa/irq.c | ? ?1 +
> > > ?1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> > > index b09e848..848e96d 100644
> > > --- a/arch/arm/mach-pxa/irq.c
> > > +++ b/arch/arm/mach-pxa/irq.c
> > > @@ -16,6 +16,7 @@
> > > ?#include <linux/module.h>
> > > ?#include <linux/interrupt.h>
> > > ?#include <linux/syscore_ops.h>
> > > +#include <linux/ftrace.h>
> > 
> > It's actually __irq_entry being defined in <linux/ftrace.h> and in turn
> > __exception_irq_entry being conditionally defined to that.
> > 
> > I think it's better to fix this in <asm/system.h> instead of in the
> > cases where this macro is referenced?
> > 
> > Russell?
> 
> There's a patch in the patch system which fixes this (7115/3) but I
> can't apply it because it doesn't apply to anything in my for-next
> tree (it applies to the obsolete 'devel' branch which is rather old
> now.)

OK, I wasn't aware that devel was obsolete (though I guess if I'd paid 
closer attention to the commit dates I'd have suspected something).

Anyhow, new patch in the tracker as 7115/4 rebased onto for-next.

Jamie

[PATCH 06/26] ARM: pxa: add missing header inclusions

[Eric Miao]

On Sat, Oct 8, 2011 at 6:23 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> On Sat, Oct 08, 2011 at 09:03:09AM +0100, Russell King - ARM Linux wrote:
>> On Fri, Oct 07, 2011 at 01:08:23PM +0800, Eric Miao wrote:
>> > On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > > These resulted in build breakage in some configurations:
>> > >
>> > > arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'
>> > >
>> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> > > ---
>> > > ?arch/arm/mach-pxa/irq.c | ? ?1 +
>> > > ?1 files changed, 1 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
>> > > index b09e848..848e96d 100644
>> > > --- a/arch/arm/mach-pxa/irq.c
>> > > +++ b/arch/arm/mach-pxa/irq.c
>> > > @@ -16,6 +16,7 @@
>> > > ?#include <linux/module.h>
>> > > ?#include <linux/interrupt.h>
>> > > ?#include <linux/syscore_ops.h>
>> > > +#include <linux/ftrace.h>
>> >
>> > It's actually __irq_entry being defined in <linux/ftrace.h> and in turn
>> > __exception_irq_entry being conditionally defined to that.
>> >
>> > I think it's better to fix this in <asm/system.h> instead of in the
>> > cases where this macro is referenced?
>> >
>> > Russell?
>>
>> There's a patch in the patch system which fixes this (7115/3) but I
>> can't apply it because it doesn't apply to anything in my for-next
>> tree (it applies to the obsolete 'devel' branch which is rather old
>> now.)
>
> OK, I wasn't aware that devel was obsolete (though I guess if I'd paid
> closer attention to the commit dates I'd have suspected something).
>
> Anyhow, new patch in the tracker as 7115/4 rebased onto for-next.

Thanks, Jamie.

[PATCH 07/26] ARM: pxa: mbxfb: disable broken debugfs code

[Arnd Bergmann]

This code has not worked for a long time, and even the
Makefile entry for building the file was misspelled.
Mark it as broken.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/video/Kconfig      |    2 +-
 drivers/video/mbx/Makefile |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 549b960..45494c0 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1932,7 +1932,7 @@ config FB_MBX
 
 config FB_MBX_DEBUG
        bool "Enable debugging info via debugfs"
-       depends on FB_MBX && DEBUG_FS
+       depends on FB_MBX && DEBUG_FS && BROKEN
        default n
        ---help---
          Enable this if you want debugging information using the debug
diff --git a/drivers/video/mbx/Makefile b/drivers/video/mbx/Makefile
index 16c1165..a315abc 100644
--- a/drivers/video/mbx/Makefile
+++ b/drivers/video/mbx/Makefile
@@ -1,4 +1,4 @@
 # Makefile for the 2700G controller driver.
 
 obj-$(CONFIG_FB_MBX)	   += mbxfb.o
-obj-$(CONFIG_FB_MBX_DEBUG) += mbxfbdebugfs.o
+obj-$(CONFIG_FB_MBX_DEBUG) += mbxdebugfs.o
-- 
1.7.5.4

[PATCH 07/26] ARM: pxa: mbxfb: disable broken debugfs code

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This code has not worked for a long time, and even the
> Makefile entry for building the file was misspelled.
> Mark it as broken.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Eric Miao <eric.y.miao@gmail.com>

> ---
> ?drivers/video/Kconfig ? ? ?| ? ?2 +-
> ?drivers/video/mbx/Makefile | ? ?2 +-
> ?2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 549b960..45494c0 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1932,7 +1932,7 @@ config FB_MBX
>
> ?config FB_MBX_DEBUG
> ? ? ? ?bool "Enable debugging info via debugfs"
> - ? ? ? depends on FB_MBX && DEBUG_FS
> + ? ? ? depends on FB_MBX && DEBUG_FS && BROKEN
> ? ? ? ?default n
> ? ? ? ?---help---
> ? ? ? ? ?Enable this if you want debugging information using the debug
> diff --git a/drivers/video/mbx/Makefile b/drivers/video/mbx/Makefile
> index 16c1165..a315abc 100644
> --- a/drivers/video/mbx/Makefile
> +++ b/drivers/video/mbx/Makefile
> @@ -1,4 +1,4 @@
> ?# Makefile for the 2700G controller driver.
>
> ?obj-$(CONFIG_FB_MBX) ? ? ?+= mbxfb.o
> -obj-$(CONFIG_FB_MBX_DEBUG) += mbxfbdebugfs.o
> +obj-$(CONFIG_FB_MBX_DEBUG) += mbxdebugfs.o
> --
> 1.7.5.4
>
>

[PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend

[Arnd Bergmann]

The cpu_suspend code on pxa has recently changed, and the
z2 board did not get updated yet. This makes it do the
same as the other boards.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/z2.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index 6c9275a..109447b 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -31,6 +31,7 @@
 #include <linux/regulator/machine.h>
 #include <linux/i2c/pxa-i2c.h>
 
+#include <asm/suspend.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
@@ -686,7 +687,7 @@ static void z2_power_off(void)
 	 */
 	PSPR = 0x0;
 	local_irq_disable();
-	pxa27x_cpu_suspend(PWRMODE_DEEPSLEEP, PLAT_PHYS_OFFSET - PAGE_OFFSET);
+	cpu_suspend(PWRMODE_DEEPSLEEP, pxa27x_finish_suspend);
 }
 #else
 #define z2_power_off   NULL
-- 
1.7.5.4

[PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The cpu_suspend code on pxa has recently changed, and the
> z2 board did not get updated yet. This makes it do the
> same as the other boards.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/z2.c | ? ?3 ++-
> ?1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
> index 6c9275a..109447b 100644
> --- a/arch/arm/mach-pxa/z2.c
> +++ b/arch/arm/mach-pxa/z2.c
> @@ -31,6 +31,7 @@
> ?#include <linux/regulator/machine.h>
> ?#include <linux/i2c/pxa-i2c.h>
>
> +#include <asm/suspend.h>
> ?#include <asm/mach-types.h>
> ?#include <asm/mach/arch.h>
>
> @@ -686,7 +687,7 @@ static void z2_power_off(void)
> ? ? ? ? */
> ? ? ? ?PSPR = 0x0;
> ? ? ? ?local_irq_disable();
> - ? ? ? pxa27x_cpu_suspend(PWRMODE_DEEPSLEEP, PLAT_PHYS_OFFSET - PAGE_OFFSET);
> + ? ? ? cpu_suspend(PWRMODE_DEEPSLEEP, pxa27x_finish_suspend);
> ?}
> ?#else
> ?#define z2_power_off ? NULL
> --
> 1.7.5.4
>

This might not be the safest way to convert. I've proposed a patch weeks ago
as below:

commit 3f7961cbd3428c8639d42d1a51870466e4cbb0eb
Author: Eric Miao <eric.y.miao@gmail.com>
Date:   Sun Sep 11 17:19:11 2011 +0800

    ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available

    Cc: Vasily Khoruzhick <anarsoul@gmail.com>
    Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index 6c9275a..6fa4e74 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -679,6 +679,8 @@ static inline void z2_pmic_init(void) {}
 #endif

 #ifdef CONFIG_PM
+extern void pxa27x_cpu_pm_enter(suspend_state_t state);
+
 static void z2_power_off(void)
 {
 	/* We're using deep sleep as poweroff, so clear PSPR to ensure that
@@ -686,7 +688,8 @@ static void z2_power_off(void)
 	 */
 	PSPR = 0x0;
 	local_irq_disable();
-	pxa27x_cpu_suspend(PWRMODE_DEEPSLEEP, PLAT_PHYS_OFFSET - PAGE_OFFSET);
+	pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
+	pxa27x_cpu_pm_enter(PM_SUSPEND_MEM);
 }
 #else
 #define z2_power_off   NULL

>

[PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend

[Arnd Bergmann]

On Friday 07 October 2011, Eric Miao wrote:
> commit 3f7961cbd3428c8639d42d1a51870466e4cbb0eb
> Author: Eric Miao <eric.y.miao@gmail.com>
> Date:   Sun Sep 11 17:19:11 2011 +0800
> 
>     ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available
> 
>     Cc: Vasily Khoruzhick <anarsoul@gmail.com>
>     Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
> 
> diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
> index 6c9275a..6fa4e74 100644
> --- a/arch/arm/mach-pxa/z2.c
> +++ b/arch/arm/mach-pxa/z2.c
> @@ -679,6 +679,8 @@ static inline void z2_pmic_init(void) {}
>  #endif
> 
>  #ifdef CONFIG_PM
> +extern void pxa27x_cpu_pm_enter(suspend_state_t state);
> +
>  static void z2_power_off(void)
>  {
>         /* We're using deep sleep as poweroff, so clear PSPR to ensure that

You really shouldn't have an extern declaration in a .c file. Otherwise
looks good to me.

	Arnd

[PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend

[Eric Miao]

On Fri, Oct 7, 2011 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 07 October 2011, Eric Miao wrote:
>> commit 3f7961cbd3428c8639d42d1a51870466e4cbb0eb
>> Author: Eric Miao <eric.y.miao@gmail.com>
>> Date: ? Sun Sep 11 17:19:11 2011 +0800
>>
>> ? ? ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available
>>
>> ? ? Cc: Vasily Khoruzhick <anarsoul@gmail.com>
>> ? ? Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
>>
>> diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
>> index 6c9275a..6fa4e74 100644
>> --- a/arch/arm/mach-pxa/z2.c
>> +++ b/arch/arm/mach-pxa/z2.c
>> @@ -679,6 +679,8 @@ static inline void z2_pmic_init(void) {}
>> ?#endif
>>
>> ?#ifdef CONFIG_PM
>> +extern void pxa27x_cpu_pm_enter(suspend_state_t state);
>> +
>> ?static void z2_power_off(void)
>> ?{
>> ? ? ? ? /* We're using deep sleep as poweroff, so clear PSPR to ensure that
>
> You really shouldn't have an extern declaration in a .c file. Otherwise
> looks good to me.

How about this one?

diff --git a/arch/arm/mach-pxa/include/mach/pxa27x.h
b/arch/arm/mach-pxa/include/mach/pxa27x.h
index b9b1bdc..7cff640 100644
--- a/arch/arm/mach-pxa/include/mach/pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/pxa27x.h
@@ -1,6 +1,7 @@
 #ifndef __MACH_PXA27x_H
 #define __MACH_PXA27x_H

+#include <linux/suspend.h>
 #include <mach/hardware.h>
 #include <mach/pxa2xx-regs.h>
 #include <mach/mfp-pxa27x.h>
@@ -21,6 +22,7 @@
 extern void __init pxa27x_map_io(void);
 extern void __init pxa27x_init_irq(void);
 extern int __init pxa27x_set_pwrmode(unsigned int mode);
+extern void pxa27x_cpu_pm_enter(suspend_state_t state);

 #define pxa27x_handle_irq      ichp_handle_irq

diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index 6c9275a..a82d420 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -686,7 +686,8 @@ static void z2_power_off(void)
         */
        PSPR = 0x0;
        local_irq_disable();
-       pxa27x_cpu_suspend(PWRMODE_DEEPSLEEP, PLAT_PHYS_OFFSET - PAGE_OFFSET);
+       pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
+       pxa27x_cpu_pm_enter(PM_SUSPEND_MEM);
 }
 #else
 #define z2_power_off   NULL

[PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend

[Arnd Bergmann]

On Saturday 08 October 2011 20:37:53 Eric Miao wrote:
> >>
> >>  #ifdef CONFIG_PM
> >> +extern void pxa27x_cpu_pm_enter(suspend_state_t state);
> >> +
> >>  static void z2_power_off(void)
> >>  {
> >>         /* We're using deep sleep as poweroff, so clear PSPR to ensure that
> >
> > You really shouldn't have an extern declaration in a .c file. Otherwise
> > looks good to me.
> 
> How about this one?

Yes, looks good as far as I can tell (I still don't quite understand how the
cpu power management all fits together, but I don't see anything wrong with
it either.

Acked-by: Arnd Bergmann <arnd@arndb.de>

[PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend

[Eric Miao]

On Sat, Oct 8, 2011 at 9:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 08 October 2011 20:37:53 Eric Miao wrote:
>> >>
>> >> ?#ifdef CONFIG_PM
>> >> +extern void pxa27x_cpu_pm_enter(suspend_state_t state);
>> >> +
>> >> ?static void z2_power_off(void)
>> >> ?{
>> >> ? ? ? ? /* We're using deep sleep as poweroff, so clear PSPR to ensure that
>> >
>> > You really shouldn't have an extern declaration in a .c file. Otherwise
>> > looks good to me.
>>
>> How about this one?
>
> Yes, looks good as far as I can tell (I still don't quite understand how the
> cpu power management all fits together, but I don't see anything wrong with
> it either.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Applied, thanks.

[PATCH 09/26] ARM: pxa: export symbols from pxa3xx-ulpi

[Arnd Bergmann]

The pxa3xx_u2d_start_hc/pxa3xx_u2d_stop_hc symbols are used by the
ohci-pxa27x driver, which can be a module.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/pxa3xx-ulpi.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
index ce7168b..e28dfb8 100644
--- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
+++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
@@ -265,6 +265,7 @@ int pxa3xx_u2d_start_hc(struct usb_bus *host)
 
 	return err;
 }
+EXPORT_SYMBOL_GPL(pxa3xx_u2d_start_hc);
 
 void pxa3xx_u2d_stop_hc(struct usb_bus *host)
 {
@@ -277,6 +278,7 @@ void pxa3xx_u2d_stop_hc(struct usb_bus *host)
 
 	clk_disable(u2d->clk);
 }
+EXPORT_SYMBOL_GPL(pxa3xx_u2d_stop_hc);
 
 static int pxa3xx_u2d_probe(struct platform_device *pdev)
 {
-- 
1.7.5.4

[PATCH 09/26] ARM: pxa: export symbols from pxa3xx-ulpi

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The pxa3xx_u2d_start_hc/pxa3xx_u2d_stop_hc symbols are used by the
> ohci-pxa27x driver, which can be a module.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied. Cc'ed Igor Grinberg <grinberg@compulab.co.il>.

> ---
> ?arch/arm/mach-pxa/pxa3xx-ulpi.c | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
> index ce7168b..e28dfb8 100644
> --- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
> +++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
> @@ -265,6 +265,7 @@ int pxa3xx_u2d_start_hc(struct usb_bus *host)
>
> ? ? ? ?return err;
> ?}
> +EXPORT_SYMBOL_GPL(pxa3xx_u2d_start_hc);
>
> ?void pxa3xx_u2d_stop_hc(struct usb_bus *host)
> ?{
> @@ -277,6 +278,7 @@ void pxa3xx_u2d_stop_hc(struct usb_bus *host)
>
> ? ? ? ?clk_disable(u2d->clk);
> ?}
> +EXPORT_SYMBOL_GPL(pxa3xx_u2d_stop_hc);
>
> ?static int pxa3xx_u2d_probe(struct platform_device *pdev)
> ?{
> --
> 1.7.5.4
>
>

[PATCH 10/26] ARM: pxa: allow selecting just one of TREO680/CENTRO

[Arnd Bergmann]

There are two variants of the palmtreo machine, the 680 and the
centro, and Kconfig allows selecting one or both of them.
This changes the board file so that it's actually possible
to build all configurations that are allowed.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/palmtreo.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/palmtreo.c b/arch/arm/mach-pxa/palmtreo.c
index bb27d4b..30364b0 100644
--- a/arch/arm/mach-pxa/palmtreo.c
+++ b/arch/arm/mach-pxa/palmtreo.c
@@ -423,6 +423,7 @@ static void __init palmphone_common_init(void)
 	palmtreo_leds_init();
 }
 
+#ifdef CONFIG_MACH_TREO680
 static void __init treo680_init(void)
 {
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(treo680_pin_config));
@@ -430,7 +431,9 @@ static void __init treo680_init(void)
 	palm27x_mmc_init(GPIO_NR_TREO_SD_DETECT_N, GPIO_NR_TREO680_SD_READONLY,
 			GPIO_NR_TREO680_SD_POWER, 0);
 }
+#endif
 
+#ifdef CONFIG_MACH_CENTRO
 static void __init centro_init(void)
 {
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(centro685_pin_config));
@@ -438,7 +441,9 @@ static void __init centro_init(void)
 	palm27x_mmc_init(GPIO_NR_TREO_SD_DETECT_N, -1,
 			GPIO_NR_CENTRO_SD_POWER, 1);
 }
+#endif
 
+#ifdef CONFIG_MACH_TREO680
 MACHINE_START(TREO680, "Palm Treo 680")
 	.boot_params    = 0xa0000100,
 	.map_io         = pxa27x_map_io,
@@ -448,7 +453,9 @@ MACHINE_START(TREO680, "Palm Treo 680")
 	.timer          = &pxa_timer,
 	.init_machine   = treo680_init,
 MACHINE_END
+#endif
 
+#ifdef CONFIG_MACH_CENTRO
 MACHINE_START(CENTRO, "Palm Centro 685")
 	.boot_params    = 0xa0000100,
 	.map_io         = pxa27x_map_io,
@@ -458,3 +465,4 @@ MACHINE_START(CENTRO, "Palm Centro 685")
 	.timer          = &pxa_timer,
 	.init_machine	= centro_init,
 MACHINE_END
+#endif
-- 
1.7.5.4

[PATCH 10/26] ARM: pxa: allow selecting just one of TREO680/CENTRO

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> There are two variants of the palmtreo machine, the 680 and the
> centro, and Kconfig allows selecting one or both of them.
> This changes the board file so that it's actually possible
> to build all configurations that are allowed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Looks good to me. Applied.

Cc'ed Marek Vasut.

> ---
> ?arch/arm/mach-pxa/palmtreo.c | ? ?8 ++++++++
> ?1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/palmtreo.c b/arch/arm/mach-pxa/palmtreo.c
> index bb27d4b..30364b0 100644
> --- a/arch/arm/mach-pxa/palmtreo.c
> +++ b/arch/arm/mach-pxa/palmtreo.c
> @@ -423,6 +423,7 @@ static void __init palmphone_common_init(void)
> ? ? ? ?palmtreo_leds_init();
> ?}
>
> +#ifdef CONFIG_MACH_TREO680
> ?static void __init treo680_init(void)
> ?{
> ? ? ? ?pxa2xx_mfp_config(ARRAY_AND_SIZE(treo680_pin_config));
> @@ -430,7 +431,9 @@ static void __init treo680_init(void)
> ? ? ? ?palm27x_mmc_init(GPIO_NR_TREO_SD_DETECT_N, GPIO_NR_TREO680_SD_READONLY,
> ? ? ? ? ? ? ? ? ? ? ? ?GPIO_NR_TREO680_SD_POWER, 0);
> ?}
> +#endif
>
> +#ifdef CONFIG_MACH_CENTRO
> ?static void __init centro_init(void)
> ?{
> ? ? ? ?pxa2xx_mfp_config(ARRAY_AND_SIZE(centro685_pin_config));
> @@ -438,7 +441,9 @@ static void __init centro_init(void)
> ? ? ? ?palm27x_mmc_init(GPIO_NR_TREO_SD_DETECT_N, -1,
> ? ? ? ? ? ? ? ? ? ? ? ?GPIO_NR_CENTRO_SD_POWER, 1);
> ?}
> +#endif
>
> +#ifdef CONFIG_MACH_TREO680
> ?MACHINE_START(TREO680, "Palm Treo 680")
> ? ? ? ?.boot_params ? ?= 0xa0000100,
> ? ? ? ?.map_io ? ? ? ? = pxa27x_map_io,
> @@ -448,7 +453,9 @@ MACHINE_START(TREO680, "Palm Treo 680")
> ? ? ? ?.timer ? ? ? ? ?= &pxa_timer,
> ? ? ? ?.init_machine ? = treo680_init,
> ?MACHINE_END
> +#endif
>
> +#ifdef CONFIG_MACH_CENTRO
> ?MACHINE_START(CENTRO, "Palm Centro 685")
> ? ? ? ?.boot_params ? ?= 0xa0000100,
> ? ? ? ?.map_io ? ? ? ? = pxa27x_map_io,
> @@ -458,3 +465,4 @@ MACHINE_START(CENTRO, "Palm Centro 685")
> ? ? ? ?.timer ? ? ? ? ?= &pxa_timer,
> ? ? ? ?.init_machine ? = centro_init,
> ?MACHINE_END
> +#endif
> --
> 1.7.5.4
>
>

[PATCH 11/26] ARM: pxa: allow building palm27x without pxafb

[Arnd Bergmann]

The frame buffer device is defined conditionally on whether the
driver is configured. However, the #ifdef guard around the
declaration of palm27x_lcd_init also removes the visibility
of the lcd mode declarations, which need to be available in
order to build correctly, even if they are not defined in the
end.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/include/mach/palm27x.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-pxa/include/mach/palm27x.h b/arch/arm/mach-pxa/include/mach/palm27x.h
index 0a5e5ea..030a916 100644
--- a/arch/arm/mach-pxa/include/mach/palm27x.h
+++ b/arch/arm/mach-pxa/include/mach/palm27x.h
@@ -27,10 +27,10 @@ extern void __init palm27x_pm_init(unsigned long str_base);
 static inline void palm27x_pm_init(unsigned long str_base) {}
 #endif
 
-#if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
 extern struct pxafb_mode_info palm_320x480_lcd_mode;
 extern struct pxafb_mode_info palm_320x320_lcd_mode;
 extern struct pxafb_mode_info palm_320x320_new_lcd_mode;
+#if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
 extern void __init palm27x_lcd_init(int power,
 					struct pxafb_mode_info *mode);
 #else
-- 
1.7.5.4

[PATCH 11/26] ARM: pxa: allow building palm27x without pxafb

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The frame buffer device is defined conditionally on whether the
> driver is configured. However, the #ifdef guard around the
> declaration of palm27x_lcd_init also removes the visibility
> of the lcd mode declarations, which need to be available in
> order to build correctly, even if they are not defined in the
> end.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/include/mach/palm27x.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/include/mach/palm27x.h b/arch/arm/mach-pxa/include/mach/palm27x.h
> index 0a5e5ea..030a916 100644
> --- a/arch/arm/mach-pxa/include/mach/palm27x.h
> +++ b/arch/arm/mach-pxa/include/mach/palm27x.h
> @@ -27,10 +27,10 @@ extern void __init palm27x_pm_init(unsigned long str_base);
> ?static inline void palm27x_pm_init(unsigned long str_base) {}
> ?#endif
>
> -#if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
> ?extern struct pxafb_mode_info palm_320x480_lcd_mode;
> ?extern struct pxafb_mode_info palm_320x320_lcd_mode;
> ?extern struct pxafb_mode_info palm_320x320_new_lcd_mode;
> +#if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
> ?extern void __init palm27x_lcd_init(int power,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct pxafb_mode_info *mode);
> ?#else
> --
> 1.7.5.4

Marek and I actually came up with a patch to fix this as below, this
way to cover the declarations of those modes in the CONFIG_FB_PXA
as well.

commit e227e88ae46e921f608b056e27e1d8704b7d12fa
Author: Eric Miao <eric.y.miao@gmail.com>
Date:   Sun Sep 11 16:56:58 2011 +0800

    ARM: pxa: fix building error by palm27x_lcd_init() when FB_PXA not defined

    Cc: Marek Vasut <marek.vasut@gmail.com>
    Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

diff --git a/arch/arm/mach-pxa/include/mach/palm27x.h
b/arch/arm/mach-pxa/include/mach/palm27x.h
index 0a5e5ea..f80bbe2 100644
--- a/arch/arm/mach-pxa/include/mach/palm27x.h
+++ b/arch/arm/mach-pxa/include/mach/palm27x.h
@@ -34,7 +34,7 @@ extern struct pxafb_mode_info palm_320x320_new_lcd_mode;
 extern void __init palm27x_lcd_init(int power,
 					struct pxafb_mode_info *mode);
 #else
-static inline void palm27x_lcd_init(int power, struct pxafb_mode_info *mode) {}
+#define palm27x_lcd_init(power, mode)	do {} while (0)
 #endif

 #if	defined(CONFIG_USB_GADGET_PXA27X) || \

>
>

[PATCH 11/26] ARM: pxa: allow building palm27x without pxafb

[Arnd Bergmann]

On Friday 07 October 2011, Eric Miao wrote:
> Marek and I actually came up with a patch to fix this as below, this
> way to cover the declarations of those modes in the CONFIG_FB_PXA
> as well.
> 
> commit e227e88ae46e921f608b056e27e1d8704b7d12fa
> Author: Eric Miao <eric.y.miao@gmail.com>
> Date:   Sun Sep 11 16:56:58 2011 +0800
> 
>     ARM: pxa: fix building error by palm27x_lcd_init() when FB_PXA not defined
> 
>     Cc: Marek Vasut <marek.vasut@gmail.com>
>     Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

Yes, that looks better than my solution

	Arnd

[PATCH 12/26] ARM: pxa: pxa95x/saarb depends on pxa3xx code

[Arnd Bergmann]

saarb uses pxa3xx_map_io and pxa3xx_handle_irq, which are part
of the pxa3xx code. This makes sure the necessary header and
implementation is used when building the board file.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Makefile |    2 +-
 arch/arm/mach-pxa/saarb.c  |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
index cc39d17..be0f7df 100644
--- a/arch/arm/mach-pxa/Makefile
+++ b/arch/arm/mach-pxa/Makefile
@@ -19,7 +19,7 @@ endif
 obj-$(CONFIG_PXA25x)		+= mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa25x.o
 obj-$(CONFIG_PXA27x)		+= mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa27x.o
 obj-$(CONFIG_PXA3xx)		+= mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o smemc.o pxa3xx-ulpi.o
-obj-$(CONFIG_PXA95x)		+= mfp-pxa3xx.o clock-pxa3xx.o pxa95x.o smemc.o
+obj-$(CONFIG_PXA95x)		+= mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o pxa95x.o smemc.o
 obj-$(CONFIG_CPU_PXA300)	+= pxa300.o
 obj-$(CONFIG_CPU_PXA320)	+= pxa320.o
 obj-$(CONFIG_CPU_PXA930)	+= pxa930.o
diff --git a/arch/arm/mach-pxa/saarb.c b/arch/arm/mach-pxa/saarb.c
index ebd6379..829c514 100644
--- a/arch/arm/mach-pxa/saarb.c
+++ b/arch/arm/mach-pxa/saarb.c
@@ -25,6 +25,8 @@
 #include <mach/mfp-pxa930.h>
 #include <mach/gpio.h>
 
+#include <mach/pxa930.h>
+
 #include "generic.h"
 
 #define SAARB_NR_IRQS	(IRQ_BOARD_START + 40)
-- 
1.7.5.4

[PATCH 12/26] ARM: pxa: pxa95x/saarb depends on pxa3xx code

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> saarb uses pxa3xx_map_io and pxa3xx_handle_irq, which are part
> of the pxa3xx code. This makes sure the necessary header and
> implementation is used when building the board file.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Makefile | ? ?2 +-
> ?arch/arm/mach-pxa/saarb.c ?| ? ?2 ++
> ?2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
> index cc39d17..be0f7df 100644
> --- a/arch/arm/mach-pxa/Makefile
> +++ b/arch/arm/mach-pxa/Makefile
> @@ -19,7 +19,7 @@ endif
> ?obj-$(CONFIG_PXA25x) ? ? ? ? ? += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa25x.o
> ?obj-$(CONFIG_PXA27x) ? ? ? ? ? += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa27x.o
> ?obj-$(CONFIG_PXA3xx) ? ? ? ? ? += mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o smemc.o pxa3xx-ulpi.o
> -obj-$(CONFIG_PXA95x) ? ? ? ? ? += mfp-pxa3xx.o clock-pxa3xx.o pxa95x.o smemc.o
> +obj-$(CONFIG_PXA95x) ? ? ? ? ? += mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o pxa95x.o smemc.o
> ?obj-$(CONFIG_CPU_PXA300) ? ? ? += pxa300.o
> ?obj-$(CONFIG_CPU_PXA320) ? ? ? += pxa320.o
> ?obj-$(CONFIG_CPU_PXA930) ? ? ? += pxa930.o
> diff --git a/arch/arm/mach-pxa/saarb.c b/arch/arm/mach-pxa/saarb.c
> index ebd6379..829c514 100644
> --- a/arch/arm/mach-pxa/saarb.c
> +++ b/arch/arm/mach-pxa/saarb.c
> @@ -25,6 +25,8 @@
> ?#include <mach/mfp-pxa930.h>
> ?#include <mach/gpio.h>
>
> +#include <mach/pxa930.h>
> +
> ?#include "generic.h"
>
> ?#define SAARB_NR_IRQS ?(IRQ_BOARD_START + 40)
> --
> 1.7.5.4
>
>

PXA95x is actually PJ4 based, which is ARMv7/v6 compatible, not
like it's predecessor PXA93x. Although they are currently sharing
some code, I expect a fork in the near future. To cause less confusion
here, I'd propose to further introduce pxa95x.h, and to remove
the unnecessary #include of <mach/mfp.h> and <mach/mfp-pxa930.h>

diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
index cc39d17..be0f7df 100644
--- a/arch/arm/mach-pxa/Makefile
+++ b/arch/arm/mach-pxa/Makefile
@@ -19,7 +19,7 @@ endif
 obj-$(CONFIG_PXA25x)		+= mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa25x.o
 obj-$(CONFIG_PXA27x)		+= mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa27x.o
 obj-$(CONFIG_PXA3xx)		+= mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o smemc.o
pxa3xx-ulpi.o
-obj-$(CONFIG_PXA95x)		+= mfp-pxa3xx.o clock-pxa3xx.o pxa95x.o smemc.o
+obj-$(CONFIG_PXA95x)		+= mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o pxa95x.o smemc.o
 obj-$(CONFIG_CPU_PXA300)	+= pxa300.o
 obj-$(CONFIG_CPU_PXA320)	+= pxa320.o
 obj-$(CONFIG_CPU_PXA930)	+= pxa930.o
diff --git a/arch/arm/mach-pxa/include/mach/pxa95x.h
b/arch/arm/mach-pxa/include/mach/pxa95x.h
new file mode 100644
index 0000000..cbb097c
--- /dev/null
+++ b/arch/arm/mach-pxa/include/mach/pxa95x.h
@@ -0,0 +1,7 @@
+#ifndef __MACH_PXA95X_H
+#define __MACH_PXA95X_H
+
+#include <mach/pxa3xx.h>
+#include <mach/mfp-pxa930.h>
+
+#endif /* __MACH_PXA95X_H */
diff --git a/arch/arm/mach-pxa/saarb.c b/arch/arm/mach-pxa/saarb.c
index ebd6379..aebd5d9 100644
--- a/arch/arm/mach-pxa/saarb.c
+++ b/arch/arm/mach-pxa/saarb.c
@@ -21,9 +21,8 @@

 #include <mach/irqs.h>
 #include <mach/hardware.h>
-#include <mach/mfp.h>
-#include <mach/mfp-pxa930.h>
 #include <mach/gpio.h>
+#include <mach/pxa95x.h>

 #include "generic.h"

[PATCH 12/26] ARM: pxa: pxa95x/saarb depends on pxa3xx code

[Arnd Bergmann]

On Friday 07 October 2011, Eric Miao wrote:
> PXA95x is actually PJ4 based, which is ARMv7/v6 compatible, not
> like it's predecessor PXA93x. Although they are currently sharing
> some code, I expect a fork in the near future. To cause less confusion
> here, I'd propose to further introduce pxa95x.h, and to remove
> the unnecessary #include of <mach/mfp.h> and <mach/mfp-pxa930.h>

Yes, looks good.

	Arnd

[PATCH 13/26] ARM: pxa: use correct __iomem annotations

[Arnd Bergmann]

This tries to clear up the confusion between integers and iomem pointers
in the marvell pxa platform. MMIO addresses are supposed to be __iomem*
values, in order to let the Linux type checking work correctly. This
patch moves the cast to __iomem as far back as possible, to the place
where the MMIO virtual address windows are defined.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/hardware/it8152.h    |    2 +-
 arch/arm/mach-mmp/clock.h                 |    8 ++++----
 arch/arm/mach-mmp/common.c                |    4 ++--
 arch/arm/mach-mmp/include/mach/addr-map.h |   10 ++++++++--
 arch/arm/mach-mmp/mmp2.c                  |    3 ++-
 arch/arm/mach-pxa/balloon3.c              |   10 +++++-----
 arch/arm/mach-pxa/cm-x2xx-pci.c           |    2 +-
 arch/arm/mach-pxa/cm-x2xx.c               |    4 ++--
 arch/arm/mach-pxa/include/mach/addr-map.h |    8 ++++----
 arch/arm/mach-pxa/include/mach/balloon3.h |    2 +-
 arch/arm/mach-pxa/include/mach/hardware.h |    9 +++++----
 arch/arm/mach-pxa/include/mach/lpd270.h   |    4 ++--
 arch/arm/mach-pxa/include/mach/mtd-xip.h  |    1 -
 arch/arm/mach-pxa/include/mach/palmtx.h   |    6 +++---
 arch/arm/mach-pxa/include/mach/smemc.h    |    2 +-
 arch/arm/mach-pxa/include/mach/zeus.h     |    4 ++--
 arch/arm/mach-pxa/irq.c                   |    4 ++--
 arch/arm/mach-pxa/lpd270.c                |    2 +-
 arch/arm/mach-pxa/palmtx.c                |    8 ++++----
 arch/arm/mach-pxa/pxa25x.c                |    2 +-
 arch/arm/mach-pxa/pxa27x.c                |    2 +-
 arch/arm/mach-pxa/pxa3xx.c                |    2 +-
 arch/arm/mach-pxa/zeus.c                  |    8 ++++----
 arch/arm/plat-pxa/gpio.c                  |    2 +-
 arch/arm/plat-pxa/include/plat/mfp.h      |    2 +-
 arch/arm/plat-pxa/mfp.c                   |    4 ++--
 drivers/pcmcia/pxa2xx_balloon3.c          |    2 +-
 drivers/video/mbx/mbxfb.c                 |    6 +++---
 28 files changed, 65 insertions(+), 58 deletions(-)

diff --git a/arch/arm/include/asm/hardware/it8152.h b/arch/arm/include/asm/hardware/it8152.h
index b3fea38..43cab49 100644
--- a/arch/arm/include/asm/hardware/it8152.h
+++ b/arch/arm/include/asm/hardware/it8152.h
@@ -9,7 +9,7 @@
 
 #ifndef __ASM_HARDWARE_IT8152_H
 #define __ASM_HARDWARE_IT8152_H
-extern unsigned long it8152_base_address;
+extern void __iomem *it8152_base_address;
 
 #define IT8152_IO_BASE			(it8152_base_address + 0x03e00000)
 #define IT8152_CFGREG_BASE		(it8152_base_address + 0x03f00000)
diff --git a/arch/arm/mach-mmp/clock.h b/arch/arm/mach-mmp/clock.h
index 3143e99..149b30c 100644
--- a/arch/arm/mach-mmp/clock.h
+++ b/arch/arm/mach-mmp/clock.h
@@ -30,7 +30,7 @@ extern struct clkops apmu_clk_ops;
 
 #define APBC_CLK(_name, _reg, _fnclksel, _rate)			\
 struct clk clk_##_name = {					\
-		.clk_rst	= (void __iomem *)APBC_##_reg,	\
+		.clk_rst	= APBC_##_reg,			\
 		.fnclksel	= _fnclksel,			\
 		.rate		= _rate,			\
 		.ops		= &apbc_clk_ops,		\
@@ -38,7 +38,7 @@ struct clk clk_##_name = {					\
 
 #define APBC_CLK_OPS(_name, _reg, _fnclksel, _rate, _ops)	\
 struct clk clk_##_name = {					\
-		.clk_rst	= (void __iomem *)APBC_##_reg,	\
+		.clk_rst	= APBC_##_reg,			\
 		.fnclksel	= _fnclksel,			\
 		.rate		= _rate,			\
 		.ops		= _ops,				\
@@ -46,7 +46,7 @@ struct clk clk_##_name = {					\
 
 #define APMU_CLK(_name, _reg, _eval, _rate)			\
 struct clk clk_##_name = {					\
-		.clk_rst	= (void __iomem *)APMU_##_reg,	\
+		.clk_rst	= APMU_##_reg,			\
 		.enable_val	= _eval,			\
 		.rate		= _rate,			\
 		.ops		= &apmu_clk_ops,		\
@@ -54,7 +54,7 @@ struct clk clk_##_name = {					\
 
 #define APMU_CLK_OPS(_name, _reg, _eval, _rate, _ops)		\
 struct clk clk_##_name = {					\
-		.clk_rst	= (void __iomem *)APMU_##_reg,	\
+		.clk_rst	= APMU_##_reg,			\
 		.enable_val	= _eval,			\
 		.rate		= _rate,			\
 		.ops		= _ops,				\
diff --git a/arch/arm/mach-mmp/common.c b/arch/arm/mach-mmp/common.c
index 0ec0ca8..5720674 100644
--- a/arch/arm/mach-mmp/common.c
+++ b/arch/arm/mach-mmp/common.c
@@ -27,12 +27,12 @@ EXPORT_SYMBOL(mmp_chip_id);
 static struct map_desc standard_io_desc[] __initdata = {
 	{
 		.pfn		= __phys_to_pfn(APB_PHYS_BASE),
-		.virtual	= APB_VIRT_BASE,
+		.virtual	= (unsigned long)APB_VIRT_BASE,
 		.length		= APB_PHYS_SIZE,
 		.type		= MT_DEVICE,
 	}, {
 		.pfn		= __phys_to_pfn(AXI_PHYS_BASE),
-		.virtual	= AXI_VIRT_BASE,
+		.virtual	= (unsigned long)AXI_VIRT_BASE,
 		.length		= AXI_PHYS_SIZE,
 		.type		= MT_DEVICE,
 	},
diff --git a/arch/arm/mach-mmp/include/mach/addr-map.h b/arch/arm/mach-mmp/include/mach/addr-map.h
index 3254089..3e404ac 100644
--- a/arch/arm/mach-mmp/include/mach/addr-map.h
+++ b/arch/arm/mach-mmp/include/mach/addr-map.h
@@ -11,6 +11,12 @@
 #ifndef __ASM_MACH_ADDR_MAP_H
 #define __ASM_MACH_ADDR_MAP_H
 
+#ifndef __ASSEMBLER__
+#define IOMEM(x)	((void __iomem *)(x))
+#else
+#define IOMEM(x)	(x)
+#endif
+
 /* APB - Application Subsystem Peripheral Bus
  *
  * NOTE: the DMA controller registers are actually on the AXI fabric #1
@@ -18,11 +24,11 @@
  * peripherals on APB, let's count it into the ABP mapping area.
  */
 #define APB_PHYS_BASE		0xd4000000
-#define APB_VIRT_BASE		0xfe000000
+#define APB_VIRT_BASE		IOMEM(0xfe000000)
 #define APB_PHYS_SIZE		0x00200000
 
 #define AXI_PHYS_BASE		0xd4200000
-#define AXI_VIRT_BASE		0xfe200000
+#define AXI_VIRT_BASE		IOMEM(0xfe200000)
 #define AXI_PHYS_SIZE		0x00200000
 
 /* Static Memory Controller - Chip Select 0 and 1 */
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index 079c188..a80cbea 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -87,7 +87,8 @@ static struct mfp_addr_map mmp2_addr_map[] __initdata = {
 
 void mmp2_clear_pmic_int(void)
 {
-	unsigned long mfpr_pmic, data;
+	void __iomem *mfpr_pmic;
+	unsigned long data;
 
 	mfpr_pmic = APB_VIRT_BASE + 0x1e000 + 0x2c4;
 	data = __raw_readl(mfpr_pmic);
diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index ef3e8b1..d0f1411 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -591,7 +591,7 @@ static void balloon3_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ct
 				BALLOON3_NAND_CONTROL_REG);
 		if (balloon3_ctl_set)
 			__raw_writel(balloon3_ctl_set,
-				BALLOON3_NAND_CONTROL_REG |
+				BALLOON3_NAND_CONTROL_REG +
 				BALLOON3_FPGA_SETnCLR);
 	}
 
@@ -608,7 +608,7 @@ static void balloon3_nand_select_chip(struct mtd_info *mtd, int chip)
 	__raw_writew(
 		BALLOON3_NAND_CONTROL_FLCE0 | BALLOON3_NAND_CONTROL_FLCE1 |
 		BALLOON3_NAND_CONTROL_FLCE2 | BALLOON3_NAND_CONTROL_FLCE3,
-		BALLOON3_NAND_CONTROL_REG | BALLOON3_FPGA_SETnCLR);
+		BALLOON3_NAND_CONTROL_REG + BALLOON3_FPGA_SETnCLR);
 
 	/* Deassert correct nCE line */
 	__raw_writew(BALLOON3_NAND_CONTROL_FLCE0 << chip,
@@ -626,7 +626,7 @@ static int balloon3_nand_probe(struct platform_device *pdev)
 	int ret;
 
 	__raw_writew(BALLOON3_NAND_CONTROL2_16BIT,
-		BALLOON3_NAND_CONTROL2_REG | BALLOON3_FPGA_SETnCLR);
+		BALLOON3_NAND_CONTROL2_REG + BALLOON3_FPGA_SETnCLR);
 
 	ver = __raw_readw(BALLOON3_FPGA_VER);
 	if (ver < 0x4f08)
@@ -649,7 +649,7 @@ static int balloon3_nand_probe(struct platform_device *pdev)
 		BALLOON3_NAND_CONTROL_FLCE0 | BALLOON3_NAND_CONTROL_FLCE1 |
 		BALLOON3_NAND_CONTROL_FLCE2 | BALLOON3_NAND_CONTROL_FLCE3 |
 		BALLOON3_NAND_CONTROL_FLWP,
-		BALLOON3_NAND_CONTROL_REG | BALLOON3_FPGA_SETnCLR);
+		BALLOON3_NAND_CONTROL_REG + BALLOON3_FPGA_SETnCLR);
 	return 0;
 
 err2:
@@ -807,7 +807,7 @@ static void __init balloon3_init(void)
 
 static struct map_desc balloon3_io_desc[] __initdata = {
 	{	/* CPLD/FPGA */
-		.virtual	=  BALLOON3_FPGA_VIRT,
+		.virtual	= (unsigned long)BALLOON3_FPGA_VIRT,
 		.pfn		= __phys_to_pfn(BALLOON3_FPGA_PHYS),
 		.length		= BALLOON3_FPGA_LENGTH,
 		.type		= MT_DEVICE,
diff --git a/arch/arm/mach-pxa/cm-x2xx-pci.c b/arch/arm/mach-pxa/cm-x2xx-pci.c
index 6bf479d..ebd9259 100644
--- a/arch/arm/mach-pxa/cm-x2xx-pci.c
+++ b/arch/arm/mach-pxa/cm-x2xx-pci.c
@@ -26,7 +26,7 @@
 
 #include <asm/hardware/it8152.h>
 
-unsigned long it8152_base_address;
+void __iomem *it8152_base_address;
 static int cmx2xx_it8152_irq_gpio;
 
 static void cmx2xx_it8152_irq_demux(unsigned int irq, struct irq_desc *desc)
diff --git a/arch/arm/mach-pxa/cm-x2xx.c b/arch/arm/mach-pxa/cm-x2xx.c
index 13cf518..4f07e16 100644
--- a/arch/arm/mach-pxa/cm-x2xx.c
+++ b/arch/arm/mach-pxa/cm-x2xx.c
@@ -39,7 +39,7 @@ extern void cmx270_init(void);
 #define CMX2XX_NR_IRQS		(IRQ_BOARD_START + 40)
 
 /* virtual addresses for statically mapped regions */
-#define CMX2XX_VIRT_BASE	(0xe8000000)
+#define CMX2XX_VIRT_BASE	(void __iomem *)(0xe8000000)
 #define CMX2XX_IT8152_VIRT	(CMX2XX_VIRT_BASE)
 
 /* physical address if local-bus attached devices */
@@ -482,7 +482,7 @@ static void __init cmx2xx_init_irq(void)
 /* Map PCI companion statically */
 static struct map_desc cmx2xx_io_desc[] __initdata = {
 	[0] = { /* PCI bridge */
-		.virtual	= CMX2XX_IT8152_VIRT,
+		.virtual	= (unsigned long)CMX2XX_IT8152_VIRT,
 		.pfn		= __phys_to_pfn(PXA_CS4_PHYS),
 		.length		= SZ_64M,
 		.type		= MT_DEVICE
diff --git a/arch/arm/mach-pxa/include/mach/addr-map.h b/arch/arm/mach-pxa/include/mach/addr-map.h
index f4c0365..bbf9df3 100644
--- a/arch/arm/mach-pxa/include/mach/addr-map.h
+++ b/arch/arm/mach-pxa/include/mach/addr-map.h
@@ -20,7 +20,7 @@
  * Peripheral Bus
  */
 #define PERIPH_PHYS		0x40000000
-#define PERIPH_VIRT		0xf2000000
+#define PERIPH_VIRT		IOMEM(0xf2000000)
 #define PERIPH_SIZE		0x02000000
 
 /*
@@ -28,21 +28,21 @@
  */
 #define PXA2XX_SMEMC_PHYS	0x48000000
 #define PXA3XX_SMEMC_PHYS	0x4a000000
-#define SMEMC_VIRT		0xf6000000
+#define SMEMC_VIRT		IOMEM(0xf6000000)
 #define SMEMC_SIZE		0x00100000
 
 /*
  * Dynamic Memory Controller (only on PXA3xx)
  */
 #define DMEMC_PHYS		0x48100000
-#define DMEMC_VIRT		0xf6100000
+#define DMEMC_VIRT		IOMEM(0xf6100000)
 #define DMEMC_SIZE		0x00100000
 
 /*
  * Internal Memory Controller (PXA27x and later)
  */
 #define IMEMC_PHYS		0x58000000
-#define IMEMC_VIRT		0xfe000000
+#define IMEMC_VIRT		IOMEM(0xfe000000)
 #define IMEMC_SIZE		0x00100000
 
 #endif /* __ASM_MACH_ADDR_MAP_H */
diff --git a/arch/arm/mach-pxa/include/mach/balloon3.h b/arch/arm/mach-pxa/include/mach/balloon3.h
index 7074e76..6d7eab3 100644
--- a/arch/arm/mach-pxa/include/mach/balloon3.h
+++ b/arch/arm/mach-pxa/include/mach/balloon3.h
@@ -23,7 +23,7 @@ enum balloon3_features {
 };
 
 #define BALLOON3_FPGA_PHYS	PXA_CS4_PHYS
-#define BALLOON3_FPGA_VIRT	(0xf1000000)	/* as per balloon2 */
+#define BALLOON3_FPGA_VIRT	IOMEM(0xf1000000)	/* as per balloon2 */
 #define BALLOON3_FPGA_LENGTH	0x01000000
 
 #define	BALLOON3_FPGA_SETnCLR		(0x1000)
diff --git a/arch/arm/mach-pxa/include/mach/hardware.h b/arch/arm/mach-pxa/include/mach/hardware.h
index de63ca3..8184669 100644
--- a/arch/arm/mach-pxa/include/mach/hardware.h
+++ b/arch/arm/mach-pxa/include/mach/hardware.h
@@ -36,22 +36,23 @@
  * Note that not all PXA2xx chips implement all those addresses, and the
  * kernel only maps the minimum needed range of this mapping.
  */
-#define io_p2v(x) (0xf2000000 + ((x) & 0x01ffffff) + (((x) & 0x1c000000) >> 1))
 #define io_v2p(x) (0x3c000000 + ((x) & 0x01ffffff) + (((x) & 0x0e000000) << 1))
+#define io_p2v(x) IOMEM(0xf2000000 + ((x) & 0x01ffffff) + (((x) & 0x1c000000) >> 1))
 
 #ifndef __ASSEMBLY__
-
-# define __REG(x)	(*((volatile u32 *)io_p2v(x)))
+# define IOMEM(x) ((void __iomem *)(x))
+# define __REG(x)	(*((volatile u32 __iomem *)io_p2v(x)))
 
 /* With indexed regs we don't want to feed the index through io_p2v()
    especially if it is a variable, otherwise horrible code will result. */
 # define __REG2(x,y)	\
-	(*(volatile u32 *)((u32)&__REG(x) + (y)))
+	(*(volatile u32 __iomem*)((u32)&__REG(x) + (y)))
 
 # define __PREG(x)	(io_v2p((u32)&(x)))
 
 #else
 
+# define IOMEM(x)	x 
 # define __REG(x)	io_p2v(x)
 # define __PREG(x)	io_v2p(x)
 
diff --git a/arch/arm/mach-pxa/include/mach/lpd270.h b/arch/arm/mach-pxa/include/mach/lpd270.h
index cd07009..4edc712 100644
--- a/arch/arm/mach-pxa/include/mach/lpd270.h
+++ b/arch/arm/mach-pxa/include/mach/lpd270.h
@@ -13,13 +13,13 @@
 #define __ASM_ARCH_LPD270_H
 
 #define LPD270_CPLD_PHYS	PXA_CS2_PHYS
-#define LPD270_CPLD_VIRT	0xf0000000
+#define LPD270_CPLD_VIRT	IOMEM(0xf0000000)
 #define LPD270_CPLD_SIZE	0x00100000
 
 #define LPD270_ETH_PHYS		(PXA_CS2_PHYS + 0x01000000)
 
 /* CPLD registers  */
-#define LPD270_CPLD_REG(x)	((unsigned long)(LPD270_CPLD_VIRT + (x)))
+#define LPD270_CPLD_REG(x)	(LPD270_CPLD_VIRT + (x))
 #define LPD270_CONTROL		LPD270_CPLD_REG(0x00)
 #define LPD270_PERIPHERAL0	LPD270_CPLD_REG(0x04)
 #define LPD270_PERIPHERAL1	LPD270_CPLD_REG(0x08)
diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
index 297387e..990d2bf 100644
--- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
+++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
@@ -16,7 +16,6 @@
 #define __ARCH_PXA_MTD_XIP_H__
 
 #include <mach/regs-ost.h>
-#include <mach/regs-intc.h>
 
 #define xip_irqpending()	(ICIP & ICMR)
 
diff --git a/arch/arm/mach-pxa/include/mach/palmtx.h b/arch/arm/mach-pxa/include/mach/palmtx.h
index 10abc4f..7074a6e 100644
--- a/arch/arm/mach-pxa/include/mach/palmtx.h
+++ b/arch/arm/mach-pxa/include/mach/palmtx.h
@@ -71,7 +71,7 @@
 
 /* Various addresses  */
 #define PALMTX_PCMCIA_PHYS	0x28000000
-#define PALMTX_PCMCIA_VIRT	0xf0000000
+#define PALMTX_PCMCIA_VIRT	IOMEM(0xf0000000)
 #define PALMTX_PCMCIA_SIZE	0x100000
 
 #define PALMTX_PHYS_RAM_START	0xa0000000
@@ -84,8 +84,8 @@
 
 #define PALMTX_NAND_ALE_PHYS	(PALMTX_PHYS_NAND_START | (1 << 24))
 #define PALMTX_NAND_CLE_PHYS	(PALMTX_PHYS_NAND_START | (1 << 25))
-#define PALMTX_NAND_ALE_VIRT	0xff100000
-#define PALMTX_NAND_CLE_VIRT	0xff200000
+#define PALMTX_NAND_ALE_VIRT	IOMEM(0xff100000)
+#define PALMTX_NAND_CLE_VIRT	IOMEM(0xff200000)
 
 /* TOUCHSCREEN */
 #define AC97_LINK_FRAME			21
diff --git a/arch/arm/mach-pxa/include/mach/smemc.h b/arch/arm/mach-pxa/include/mach/smemc.h
index 654adc9..b7de471 100644
--- a/arch/arm/mach-pxa/include/mach/smemc.h
+++ b/arch/arm/mach-pxa/include/mach/smemc.h
@@ -13,7 +13,7 @@
 
 #define PXA2XX_SMEMC_BASE	0x48000000
 #define PXA3XX_SMEMC_BASE	0x4a000000
-#define SMEMC_VIRT		0xf6000000
+#define SMEMC_VIRT		IOMEM(0xf6000000)
 
 #define MDCNFG		(SMEMC_VIRT + 0x00)  /* SDRAM Configuration Register 0 */
 #define MDREFR		(SMEMC_VIRT + 0x04)  /* SDRAM Refresh Control Register */
diff --git a/arch/arm/mach-pxa/include/mach/zeus.h b/arch/arm/mach-pxa/include/mach/zeus.h
index 0641f31..56024f8 100644
--- a/arch/arm/mach-pxa/include/mach/zeus.h
+++ b/arch/arm/mach-pxa/include/mach/zeus.h
@@ -68,7 +68,7 @@
  * Be gentle, and remap that over 32kB...
  */
 
-#define ZEUS_CPLD		(0xf0000000)
+#define ZEUS_CPLD		IOMEM(0xf0000000)
 #define ZEUS_CPLD_VERSION	(ZEUS_CPLD + 0x0000)
 #define ZEUS_CPLD_ISA_IRQ	(ZEUS_CPLD + 0x1000)
 #define ZEUS_CPLD_CONTROL	(ZEUS_CPLD + 0x2000)
@@ -76,7 +76,7 @@
 /* CPLD register bits */
 #define ZEUS_CPLD_CONTROL_CF_RST        0x01
 
-#define ZEUS_PC104IO		(0xf1000000)
+#define ZEUS_PC104IO		IOMEM(0xf1000000)
 
 #define ZEUS_SRAM_SIZE		(256 * 1024)
 
diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index 848e96d..5344f05 100644
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@ -26,7 +26,7 @@
 
 #include "generic.h"
 
-#define IRQ_BASE		(void __iomem *)io_p2v(0x40d00000)
+#define IRQ_BASE		io_p2v(0x40d00000)
 
 #define ICIP			(0x000)
 #define ICMR			(0x004)
@@ -64,7 +64,7 @@ static inline void __iomem *irq_base(int i)
 		0x40d00130,
 	};
 
-	return (void __iomem *)io_p2v(phys_base[i]);
+	return io_p2v(phys_base[i]);
 }
 
 void pxa_mask_irq(struct irq_data *d)
diff --git a/arch/arm/mach-pxa/lpd270.c b/arch/arm/mach-pxa/lpd270.c
index c171d6e..e30cdc8 100644
--- a/arch/arm/mach-pxa/lpd270.c
+++ b/arch/arm/mach-pxa/lpd270.c
@@ -480,7 +480,7 @@ static void __init lpd270_init(void)
 
 static struct map_desc lpd270_io_desc[] __initdata = {
 	{
-		.virtual	= LPD270_CPLD_VIRT,
+		.virtual	= (unsigned long)LPD270_CPLD_VIRT,
 		.pfn		= __phys_to_pfn(LPD270_CPLD_PHYS),
 		.length		= LPD270_CPLD_SIZE,
 		.type		= MT_DEVICE,
diff --git a/arch/arm/mach-pxa/palmtx.c b/arch/arm/mach-pxa/palmtx.c
index fc42855..00c318f 100644
--- a/arch/arm/mach-pxa/palmtx.c
+++ b/arch/arm/mach-pxa/palmtx.c
@@ -247,7 +247,7 @@ static void palmtx_nand_cmd_ctl(struct mtd_info *mtd, int cmd,
 				 unsigned int ctrl)
 {
 	struct nand_chip *this = mtd->priv;
-	unsigned long nandaddr = (unsigned long)this->IO_ADDR_W;
+	char __iomem *nandaddr = this->IO_ADDR_W;
 
 	if (cmd == NAND_CMD_NONE)
 		return;
@@ -315,17 +315,17 @@ static inline void palmtx_nand_init(void) {}
  ******************************************************************************/
 static struct map_desc palmtx_io_desc[] __initdata = {
 {
-	.virtual	= PALMTX_PCMCIA_VIRT,
+	.virtual	= (unsigned long)PALMTX_PCMCIA_VIRT,
 	.pfn		= __phys_to_pfn(PALMTX_PCMCIA_PHYS),
 	.length		= PALMTX_PCMCIA_SIZE,
 	.type		= MT_DEVICE,
 }, {
-	.virtual	= PALMTX_NAND_ALE_VIRT,
+	.virtual	= (unsigned long)PALMTX_NAND_ALE_VIRT,
 	.pfn		= __phys_to_pfn(PALMTX_NAND_ALE_PHYS),
 	.length		= SZ_1M,
 	.type		= MT_DEVICE,
 }, {
-	.virtual	= PALMTX_NAND_CLE_VIRT,
+	.virtual	= (unsigned long)PALMTX_NAND_CLE_VIRT,
 	.pfn		= __phys_to_pfn(PALMTX_NAND_CLE_PHYS),
 	.length		= SZ_1M,
 	.type		= MT_DEVICE,
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 9c434d2..6c49c7c 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -324,7 +324,7 @@ void __init pxa26x_init_irq(void)
 
 static struct map_desc pxa25x_io_desc[] __initdata = {
 	{	/* Mem Ctl */
-		.virtual	= SMEMC_VIRT,
+		.virtual	= (unsigned long)SMEMC_VIRT,
 		.pfn		= __phys_to_pfn(PXA2XX_SMEMC_BASE),
 		.length		= 0x00200000,
 		.type		= MT_DEVICE
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 9d2400b..729af54 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -390,7 +390,7 @@ void __init pxa27x_init_irq(void)
 
 static struct map_desc pxa27x_io_desc[] __initdata = {
 	{	/* Mem Ctl */
-		.virtual	= SMEMC_VIRT,
+		.virtual	= (unsigned long)SMEMC_VIRT,
 		.pfn		= __phys_to_pfn(PXA2XX_SMEMC_BASE),
 		.length		= 0x00200000,
 		.type		= MT_DEVICE
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index b5cd9e5..b2479cb 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -394,7 +394,7 @@ void __init pxa3xx_init_irq(void)
 
 static struct map_desc pxa3xx_io_desc[] __initdata = {
 	{	/* Mem Ctl */
-		.virtual	= SMEMC_VIRT,
+		.virtual	= (unsigned long)SMEMC_VIRT,
 		.pfn		= __phys_to_pfn(PXA3XX_SMEMC_BASE),
 		.length		= 0x00200000,
 		.type		= MT_DEVICE
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index 99c49bc..9188492 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -860,25 +860,25 @@ static void __init zeus_init(void)
 
 static struct map_desc zeus_io_desc[] __initdata = {
 	{
-		.virtual = ZEUS_CPLD_VERSION,
+		.virtual = (unsigned long)ZEUS_CPLD_VERSION,
 		.pfn     = __phys_to_pfn(ZEUS_CPLD_VERSION_PHYS),
 		.length  = 0x1000,
 		.type    = MT_DEVICE,
 	},
 	{
-		.virtual = ZEUS_CPLD_ISA_IRQ,
+		.virtual = (unsigned long)ZEUS_CPLD_ISA_IRQ,
 		.pfn     = __phys_to_pfn(ZEUS_CPLD_ISA_IRQ_PHYS),
 		.length  = 0x1000,
 		.type    = MT_DEVICE,
 	},
 	{
-		.virtual = ZEUS_CPLD_CONTROL,
+		.virtual = (unsigned long)ZEUS_CPLD_CONTROL,
 		.pfn     = __phys_to_pfn(ZEUS_CPLD_CONTROL_PHYS),
 		.length  = 0x1000,
 		.type    = MT_DEVICE,
 	},
 	{
-		.virtual = ZEUS_PC104IO,
+		.virtual = (unsigned long)ZEUS_PC104IO,
 		.pfn     = __phys_to_pfn(ZEUS_PC104IO_PHYS),
 		.length  = 0x00800000,
 		.type    = MT_DEVICE,
diff --git a/arch/arm/plat-pxa/gpio.c b/arch/arm/plat-pxa/gpio.c
index a11dc36..0db7615 100644
--- a/arch/arm/plat-pxa/gpio.c
+++ b/arch/arm/plat-pxa/gpio.c
@@ -122,7 +122,7 @@ static int __init pxa_init_gpio_chip(int gpio_end)
 		struct gpio_chip *c = &chips[i].chip;
 
 		sprintf(chips[i].label, "gpio-%d", i);
-		chips[i].regbase = (void __iomem *)GPIO_BANK(i);
+		chips[i].regbase = GPIO_BANK(i);
 
 		c->base  = gpio;
 		c->label = chips[i].label;
diff --git a/arch/arm/plat-pxa/include/plat/mfp.h b/arch/arm/plat-pxa/include/plat/mfp.h
index 89e68e0..5c79c29 100644
--- a/arch/arm/plat-pxa/include/plat/mfp.h
+++ b/arch/arm/plat-pxa/include/plat/mfp.h
@@ -456,7 +456,7 @@ struct mfp_addr_map {
 
 #define MFP_ADDR_END	{ MFP_PIN_INVALID, 0 }
 
-void __init mfp_init_base(unsigned long mfpr_base);
+void __init mfp_init_base(void __iomem *mfpr_base);
 void __init mfp_init_addr(struct mfp_addr_map *map);
 
 /*
diff --git a/arch/arm/plat-pxa/mfp.c b/arch/arm/plat-pxa/mfp.c
index be12ead..2c4dbb1 100644
--- a/arch/arm/plat-pxa/mfp.c
+++ b/arch/arm/plat-pxa/mfp.c
@@ -229,7 +229,7 @@ void mfp_write(int mfp, unsigned long val)
 	spin_unlock_irqrestore(&mfp_spin_lock, flags);
 }
 
-void __init mfp_init_base(unsigned long mfpr_base)
+void __init mfp_init_base(void __iomem *mfpr_base)
 {
 	int i;
 
@@ -237,7 +237,7 @@ void __init mfp_init_base(unsigned long mfpr_base)
 	for (i = 0; i < ARRAY_SIZE(mfp_table); i++)
 		mfp_table[i].config = -1;
 
-	mfpr_mmio_base = (void __iomem *)mfpr_base;
+	mfpr_mmio_base = mfpr_base;
 }
 
 void __init mfp_init_addr(struct mfp_addr_map *map)
diff --git a/drivers/pcmcia/pxa2xx_balloon3.c b/drivers/pcmcia/pxa2xx_balloon3.c
index f56d7de..22a75e6 100644
--- a/drivers/pcmcia/pxa2xx_balloon3.c
+++ b/drivers/pcmcia/pxa2xx_balloon3.c
@@ -97,7 +97,7 @@ static void balloon3_pcmcia_socket_state(struct soc_pcmcia_socket *skt,
 static int balloon3_pcmcia_configure_socket(struct soc_pcmcia_socket *skt,
 				       const socket_state_t *state)
 {
-	__raw_writew(BALLOON3_CF_RESET, BALLOON3_CF_CONTROL_REG |
+	__raw_writew(BALLOON3_CF_RESET, BALLOON3_CF_CONTROL_REG +
 			((state->flags & SS_RESET) ?
 			BALLOON3_FPGA_SETnCLR : 0));
 	return 0;
diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
index afea9ab..6ce3416 100644
--- a/drivers/video/mbx/mbxfb.c
+++ b/drivers/video/mbx/mbxfb.c
@@ -34,7 +34,7 @@
 #include "regs.h"
 #include "reg_bits.h"
 
-static unsigned long virt_base_2700;
+static void __iomem *virt_base_2700;
 
 #define write_reg(val, reg) do { writel((val), (reg)); } while(0)
 
@@ -850,7 +850,7 @@ static int mbxfb_suspend(struct platform_device *dev, pm_message_t state)
 {
 	/* make frame buffer memory enter self-refresh mode */
 	write_reg_dly(LMPWR_MC_PWR_SRM, LMPWR);
-	while (LMPWRSTAT != LMPWRSTAT_MC_PWR_SRM)
+	while (readl(LMPWRSTAT) != LMPWRSTAT_MC_PWR_SRM)
 		; /* empty statement */
 
 	/* reset the device, since it's initial state is 'mostly sleeping' */
@@ -946,7 +946,7 @@ static int __devinit mbxfb_probe(struct platform_device *dev)
 		ret = -EINVAL;
 		goto err3;
 	}
-	virt_base_2700 = (unsigned long)mfbi->reg_virt_addr;
+	virt_base_2700 = mfbi->reg_virt_addr;
 
 	mfbi->fb_virt_addr = ioremap_nocache(mfbi->fb_phys_addr,
 					     res_size(mfbi->fb_req));
-- 
1.7.5.4

[PATCH 13/26] ARM: pxa: use correct __iomem annotations

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This tries to clear up the confusion between integers and iomem pointers
> in the marvell pxa platform. MMIO addresses are supposed to be __iomem*
> values, in order to let the Linux type checking work correctly. This
> patch moves the cast to __iomem as far back as possible, to the place
> where the MMIO virtual address windows are defined.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/include/asm/hardware/it8152.h ? ?| ? ?2 +-
> ?arch/arm/mach-mmp/clock.h ? ? ? ? ? ? ? ? | ? ?8 ++++----
> ?arch/arm/mach-mmp/common.c ? ? ? ? ? ? ? ?| ? ?4 ++--
> ?arch/arm/mach-mmp/include/mach/addr-map.h | ? 10 ++++++++--
> ?arch/arm/mach-mmp/mmp2.c ? ? ? ? ? ? ? ? ?| ? ?3 ++-
> ?arch/arm/mach-pxa/balloon3.c ? ? ? ? ? ? ?| ? 10 +++++-----
> ?arch/arm/mach-pxa/cm-x2xx-pci.c ? ? ? ? ? | ? ?2 +-
> ?arch/arm/mach-pxa/cm-x2xx.c ? ? ? ? ? ? ? | ? ?4 ++--
> ?arch/arm/mach-pxa/include/mach/addr-map.h | ? ?8 ++++----
> ?arch/arm/mach-pxa/include/mach/balloon3.h | ? ?2 +-
> ?arch/arm/mach-pxa/include/mach/hardware.h | ? ?9 +++++----
> ?arch/arm/mach-pxa/include/mach/lpd270.h ? | ? ?4 ++--
> ?arch/arm/mach-pxa/include/mach/mtd-xip.h ?| ? ?1 -
> ?arch/arm/mach-pxa/include/mach/palmtx.h ? | ? ?6 +++---
> ?arch/arm/mach-pxa/include/mach/smemc.h ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/include/mach/zeus.h ? ? | ? ?4 ++--
> ?arch/arm/mach-pxa/irq.c ? ? ? ? ? ? ? ? ? | ? ?4 ++--
> ?arch/arm/mach-pxa/lpd270.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/palmtx.c ? ? ? ? ? ? ? ?| ? ?8 ++++----
> ?arch/arm/mach-pxa/pxa25x.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/pxa27x.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/pxa3xx.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/zeus.c ? ? ? ? ? ? ? ? ?| ? ?8 ++++----
> ?arch/arm/plat-pxa/gpio.c ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/plat-pxa/include/plat/mfp.h ? ? ?| ? ?2 +-
> ?arch/arm/plat-pxa/mfp.c ? ? ? ? ? ? ? ? ? | ? ?4 ++--
> ?drivers/pcmcia/pxa2xx_balloon3.c ? ? ? ? ?| ? ?2 +-
> ?drivers/video/mbx/mbxfb.c ? ? ? ? ? ? ? ? | ? ?6 +++---
> ?28 files changed, 65 insertions(+), 58 deletions(-)
>
> diff --git a/arch/arm/include/asm/hardware/it8152.h b/arch/arm/include/asm/hardware/it8152.h
> index b3fea38..43cab49 100644
> --- a/arch/arm/include/asm/hardware/it8152.h
> +++ b/arch/arm/include/asm/hardware/it8152.h
> @@ -9,7 +9,7 @@
>
> ?#ifndef __ASM_HARDWARE_IT8152_H
> ?#define __ASM_HARDWARE_IT8152_H
> -extern unsigned long it8152_base_address;
> +extern void __iomem *it8152_base_address;
>
> ?#define IT8152_IO_BASE ? ? ? ? ? ? ? ? (it8152_base_address + 0x03e00000)
> ?#define IT8152_CFGREG_BASE ? ? ? ? ? ? (it8152_base_address + 0x03f00000)
> diff --git a/arch/arm/mach-mmp/clock.h b/arch/arm/mach-mmp/clock.h
> index 3143e99..149b30c 100644
> --- a/arch/arm/mach-mmp/clock.h
> +++ b/arch/arm/mach-mmp/clock.h
> @@ -30,7 +30,7 @@ extern struct clkops apmu_clk_ops;
>
> ?#define APBC_CLK(_name, _reg, _fnclksel, _rate) ? ? ? ? ? ? ? ? ? ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APBC_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APBC_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.fnclksel ? ? ? = _fnclksel, ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= &apbc_clk_ops, ? ? ? ? ? ? ? ?\
> @@ -38,7 +38,7 @@ struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>
> ?#define APBC_CLK_OPS(_name, _reg, _fnclksel, _rate, _ops) ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APBC_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APBC_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.fnclksel ? ? ? = _fnclksel, ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= _ops, ? ? ? ? ? ? ? ? ? ? ? ? \
> @@ -46,7 +46,7 @@ struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>
> ?#define APMU_CLK(_name, _reg, _eval, _rate) ? ? ? ? ? ? ? ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APMU_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APMU_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.enable_val ? ? = _eval, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= &apmu_clk_ops, ? ? ? ? ? ? ? ?\
> @@ -54,7 +54,7 @@ struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>
> ?#define APMU_CLK_OPS(_name, _reg, _eval, _rate, _ops) ? ? ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APMU_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APMU_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.enable_val ? ? = _eval, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= _ops, ? ? ? ? ? ? ? ? ? ? ? ? \
> diff --git a/arch/arm/mach-mmp/common.c b/arch/arm/mach-mmp/common.c
> index 0ec0ca8..5720674 100644
> --- a/arch/arm/mach-mmp/common.c
> +++ b/arch/arm/mach-mmp/common.c
> @@ -27,12 +27,12 @@ EXPORT_SYMBOL(mmp_chip_id);
> ?static struct map_desc standard_io_desc[] __initdata = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(APB_PHYS_BASE),
> - ? ? ? ? ? ? ? .virtual ? ? ? ?= APB_VIRT_BASE,
> + ? ? ? ? ? ? ? .virtual ? ? ? ?= (unsigned long)APB_VIRT_BASE,
> ? ? ? ? ? ? ? ?.length ? ? ? ? = APB_PHYS_SIZE,
> ? ? ? ? ? ? ? ?.type ? ? ? ? ? = MT_DEVICE,
> ? ? ? ?}, {
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(AXI_PHYS_BASE),
> - ? ? ? ? ? ? ? .virtual ? ? ? ?= AXI_VIRT_BASE,
> + ? ? ? ? ? ? ? .virtual ? ? ? ?= (unsigned long)AXI_VIRT_BASE,
> ? ? ? ? ? ? ? ?.length ? ? ? ? = AXI_PHYS_SIZE,
> ? ? ? ? ? ? ? ?.type ? ? ? ? ? = MT_DEVICE,
> ? ? ? ?},
> diff --git a/arch/arm/mach-mmp/include/mach/addr-map.h b/arch/arm/mach-mmp/include/mach/addr-map.h
> index 3254089..3e404ac 100644
> --- a/arch/arm/mach-mmp/include/mach/addr-map.h
> +++ b/arch/arm/mach-mmp/include/mach/addr-map.h
> @@ -11,6 +11,12 @@
> ?#ifndef __ASM_MACH_ADDR_MAP_H
> ?#define __ASM_MACH_ADDR_MAP_H
>
> +#ifndef __ASSEMBLER__
> +#define IOMEM(x) ? ? ? ((void __iomem *)(x))
> +#else
> +#define IOMEM(x) ? ? ? (x)
> +#endif
> +
> ?/* APB - Application Subsystem Peripheral Bus
> ?*
> ?* NOTE: the DMA controller registers are actually on the AXI fabric #1
> @@ -18,11 +24,11 @@
> ?* peripherals on APB, let's count it into the ABP mapping area.
> ?*/
> ?#define APB_PHYS_BASE ? ? ? ? ?0xd4000000
> -#define APB_VIRT_BASE ? ? ? ? ?0xfe000000
> +#define APB_VIRT_BASE ? ? ? ? ?IOMEM(0xfe000000)

To be honest, I'd really like to keep the *_VIRT_BASE definitions to be
type independent.

And have the actual register definitions to be casted to void __iomem *
when being defined, e.g.

#define APBC_REG(x)	IOMEM(APBC_VIRT_BASE + (x))

#define APBC_UART1	APBC_REG(0x000)

Arnd, do we have some standard guidelines on this for all SoCs
to follow? As I know, it's currently still being a mess.

[PATCH 13/26] ARM: pxa: use correct __iomem annotations

[Russell King - ARM Linux]

On Fri, Oct 07, 2011 at 04:11:01PM +0800, Eric Miao wrote:
> To be honest, I'd really like to keep the *_VIRT_BASE definitions to be
> type independent.
> 
> And have the actual register definitions to be casted to void __iomem *
> when being defined, e.g.
> 
> #define APBC_REG(x)	IOMEM(APBC_VIRT_BASE + (x))
> 
> #define APBC_UART1	APBC_REG(0x000)
> 
> Arnd, do we have some standard guidelines on this for all SoCs
> to follow? As I know, it's currently still being a mess.

It makes much more sense for the base address to be correctly typed (even
though it does mean a cast in the map_desc tables).  It avoids type
problems if someone does readl(APBC_VIRT_BASE + reg) somewhere, and
also avoids type problems should someone decide to pass the base address
around.

[PATCH 13/26] ARM: pxa: use correct __iomem annotations

[Arnd Bergmann]

On Friday 07 October 2011, Eric Miao wrote:
> > @@ -18,11 +24,11 @@
> >  * peripherals on APB, let's count it into the ABP mapping area.
> >  */
> >  #define APB_PHYS_BASE          0xd4000000
> > -#define APB_VIRT_BASE          0xfe000000
> > +#define APB_VIRT_BASE          IOMEM(0xfe000000)
> 
> To be honest, I'd really like to keep the *_VIRT_BASE definitions to be
> type independent.
> 
> And have the actual register definitions to be casted to void __iomem *
> when being defined, e.g.
> 
> #define APBC_REG(x)     IOMEM(APBC_VIRT_BASE + (x))
> 
> #define APBC_UART1      APBC_REG(0x000)
> 
> Arnd, do we have some standard guidelines on this for all SoCs
> to follow? As I know, it's currently still being a mess.

We don't have any formal guidelines yet, but I'd really love to get
rid of all the arbitrary type casts to make use of the built-in
type checking of the compiler and sparse. A virtual base address
for registers is conventionally an __iomem pointer, so defining it
as something else is completely bogus. I have started making patches
for a number of platforms for this.

Ideally we should have very little code directly using, but the fact
is that they are there and we won't remove them all anytime soon, so
we should at least use the correct types here.

Another issue that goes together with this is that right now our
readl/writel macros accept any input type (pointer, __iomem pointer,
unsigned long, unsigned int), and I have a patch to make that stricter
but that requires fixing up all the places where we do a
readl(APBC_VIRT_BASE + x) that Russell mentioned.

The only place where this requires adding extra type casts right now is
the iotable setup, which I hope we can also fix eventually by splitting
the static I/O mapping setup from other static mappings (MT_MEMORY,
MT_MEMORY_NONCACHED, ...).

	Arnd

[PATCH 13/26] ARM: pxa: use correct __iomem annotations

[Eric Miao]

On Fri, Oct 7, 2011 at 6:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 07 October 2011, Eric Miao wrote:
>> > @@ -18,11 +24,11 @@
>> > ?* peripherals on APB, let's count it into the ABP mapping area.
>> > ?*/
>> > ?#define APB_PHYS_BASE ? ? ? ? ?0xd4000000
>> > -#define APB_VIRT_BASE ? ? ? ? ?0xfe000000
>> > +#define APB_VIRT_BASE ? ? ? ? ?IOMEM(0xfe000000)
>>
>> To be honest, I'd really like to keep the *_VIRT_BASE definitions to be
>> type independent.
>>
>> And have the actual register definitions to be casted to void __iomem *
>> when being defined, e.g.
>>
>> #define APBC_REG(x) ? ? IOMEM(APBC_VIRT_BASE + (x))
>>
>> #define APBC_UART1 ? ? ?APBC_REG(0x000)
>>
>> Arnd, do we have some standard guidelines on this for all SoCs
>> to follow? As I know, it's currently still being a mess.
>
> We don't have any formal guidelines yet, but I'd really love to get
> rid of all the arbitrary type casts to make use of the built-in
> type checking of the compiler and sparse. A virtual base address
> for registers is conventionally an __iomem pointer, so defining it
> as something else is completely bogus. I have started making patches
> for a number of platforms for this.
>
> Ideally we should have very little code directly using, but the fact
> is that they are there and we won't remove them all anytime soon, so
> we should at least use the correct types here.
>
> Another issue that goes together with this is that right now our
> readl/writel macros accept any input type (pointer, __iomem pointer,
> unsigned long, unsigned int), and I have a patch to make that stricter
> but that requires fixing up all the places where we do a
> readl(APBC_VIRT_BASE + x) that Russell mentioned.
>
> The only place where this requires adding extra type casts right now is
> the iotable setup, which I hope we can also fix eventually by splitting
> the static I/O mapping setup from other static mappings (MT_MEMORY,
> MT_MEMORY_NONCACHED, ...).

Sounds fair enough. Applied.

[PATCH 14/26] mtd: nand_h1900 never worked

[Arnd Bergmann]

This driver has been broken through all of git history and
cannot even be built. Better mark it as broken. Next stop is
removing from the tree.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Jamie Iles <jamie@jamieiles.com>
---
 drivers/mtd/nand/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4c342523..f85af18 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -92,7 +92,7 @@ config MTD_NAND_EDB7312
 
 config MTD_NAND_H1900
 	tristate "iPAQ H1900 flash"
-	depends on ARCH_PXA
+	depends on ARCH_PXA && BROKEN
 	help
 	  This enables the driver for the iPAQ h1900 flash.
 
-- 
1.7.5.4

[PATCH 14/26] mtd: nand_h1900 never worked

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This driver has been broken through all of git history and
> cannot even be built. Better mark it as broken. Next stop is
> removing from the tree.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> Cc: Jamie Iles <jamie@jamieiles.com>

Acked-by: Eric Miao <eric.y.miao@gmail.com>

> ---
> ?drivers/mtd/nand/Kconfig | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 4c342523..f85af18 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -92,7 +92,7 @@ config MTD_NAND_EDB7312
>
> ?config MTD_NAND_H1900
> ? ? ? ?tristate "iPAQ H1900 flash"
> - ? ? ? depends on ARCH_PXA
> + ? ? ? depends on ARCH_PXA && BROKEN
> ? ? ? ?help
> ? ? ? ? ?This enables the driver for the iPAQ h1900 flash.
>
> --
> 1.7.5.4
>
>

[PATCH 14/26] mtd: nand_h1900 never worked

[Artem Bityutskiy]

On Sat, 2011-10-01 at 22:03 +0200, Arnd Bergmann wrote:
> This driver has been broken through all of git history and
> cannot even be built. Better mark it as broken. Next stop is
> removing from the tree.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Pushed to l2-mtd-2.6.git, thanks!

NB: I'd just killed it instead...

-- 
Best Regards,
Artem Bityutskiy

[PATCH 15/26] irda/ficp: only works on some pxa models

[Arnd Bergmann]

This driver can only be built for pxa25x and pxa27x at the moment,
so encode that in Kconfig.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Samuel Ortiz <samuel@sortiz.org>
---
 drivers/net/irda/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index 25bb2a0..8cffd38 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -373,7 +373,7 @@ config VIA_FIR
 
 config PXA_FICP
 	tristate "Intel PXA2xx Internal FICP"
-	depends on ARCH_PXA && IRDA
+	depends on ARCH_PXA && IRDA && (PXA25x || PXA27x)
 	help
 	  Say Y or M here if you want to build support for the PXA2xx
 	  built-in IRDA interface which can support both SIR and FIR.
-- 
1.7.5.4

[PATCH 15/26] irda/ficp: only works on some pxa models

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This driver can only be built for pxa25x and pxa27x at the moment,
> so encode that in Kconfig.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <samuel@sortiz.org>

Acked-by: Eric Miao <eric.y.miao@gmail.com>

> ---
> ?drivers/net/irda/Kconfig | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
> index 25bb2a0..8cffd38 100644
> --- a/drivers/net/irda/Kconfig
> +++ b/drivers/net/irda/Kconfig
> @@ -373,7 +373,7 @@ config VIA_FIR
>
> ?config PXA_FICP
> ? ? ? ?tristate "Intel PXA2xx Internal FICP"
> - ? ? ? depends on ARCH_PXA && IRDA
> + ? ? ? depends on ARCH_PXA && IRDA && (PXA25x || PXA27x)
> ? ? ? ?help
> ? ? ? ? ?Say Y or M here if you want to build support for the PXA2xx
> ? ? ? ? ?built-in IRDA interface which can support both SIR and FIR.
> --
> 1.7.5.4
>
>

[PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT

[Arnd Bergmann]

The PJ4 based pxa95x cpus all have iwmmxt and there is no way to
build that code conditionally, so better not ask the user
in that configuration, in order to prevent broken builds.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..570c9fd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1071,7 +1071,7 @@ config ARM_TIMER_SP804
 source arch/arm/mm/Kconfig
 
 config IWMMXT
-	bool "Enable iWMMXt support"
+	bool "Enable iWMMXt support" if !CPU_PJ4
 	depends on CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_PJ4
 	default y if PXA27x || PXA3xx || PXA95x || ARCH_MMP
 	help
-- 
1.7.5.4

[PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT

[Russell King - ARM Linux]

On Sat, Oct 01, 2011 at 10:03:48PM +0200, Arnd Bergmann wrote:
> The PJ4 based pxa95x cpus all have iwmmxt and there is no way to
> build that code conditionally, so better not ask the user
> in that configuration, in order to prevent broken builds.

This suggests we want IWMMXT=y if PJ4=y...

>  config IWMMXT
> -	bool "Enable iWMMXt support"
> +	bool "Enable iWMMXt support" if !CPU_PJ4
>  	depends on CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_PJ4
>  	default y if PXA27x || PXA3xx || PXA95x || ARCH_MMP
>  	help

This hides the option if CPU_PJ4 is enabled, but it will only be set
to 'y' if PXA27x || PXA3xx || PXA95x || ARCH_MMP are set.  Luckily,
ARCH_MMP will be - but is that really what's intended?  It's a little
obscure to work that out.

[PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT

[Arnd Bergmann]

On Sunday 02 October 2011 17:03:28 Russell King - ARM Linux wrote:
> On Sat, Oct 01, 2011 at 10:03:48PM +0200, Arnd Bergmann wrote:
> > The PJ4 based pxa95x cpus all have iwmmxt and there is no way to
> > build that code conditionally, so better not ask the user
> > in that configuration, in order to prevent broken builds.
> 
> This suggests we want IWMMXT=y if PJ4=y...
> 
> >  config IWMMXT
> > -     bool "Enable iWMMXt support"
> > +     bool "Enable iWMMXt support" if !CPU_PJ4
> >       depends on CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_PJ4
> >       default y if PXA27x || PXA3xx || PXA95x || ARCH_MMP
> >       help
> 
> This hides the option if CPU_PJ4 is enabled, but it will only be set
> to 'y' if PXA27x || PXA3xx || PXA95x || ARCH_MMP are set.  Luckily,
> ARCH_MMP will be - but is that really what's intended?  It's a little
> obscure to work that out.

It was the idea at least, but you are right: adding an explicit || CPU_PJ4
to the default makes it more robust and more obvious to the reader.

I've replaced this patch with the version below and pushed the result to
same location.

	Arnd

8<-----
Subject: [PATCH] ARM: pxa: CPU_PJ4 requires IWMMXT

The PJ4 based pxa95x cpus all have iwmmxt and there is no way to
build that code conditionally, so better not ask the user
in that configuration, in order to prevent broken builds.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..8d66c32 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1071,9 +1071,10 @@ config ARM_TIMER_SP804
 source arch/arm/mm/Kconfig
 
 config IWMMXT
-	bool "Enable iWMMXt support"
+	bool "Enable iWMMXt support" if !CPU_PJ4
 	depends on CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_PJ4
 	default y if PXA27x || PXA3xx || PXA95x || ARCH_MMP
+	default y if CPU_PJ4
 	help
 	  Enable support for iWMMXt context switching at run time if
 	  running on a CPU that supports it.

[PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT

[Eric Miao]

> 8<-----
> Subject: [PATCH] ARM: pxa: CPU_PJ4 requires IWMMXT
>
> The PJ4 based pxa95x cpus all have iwmmxt and there is no way to
> build that code conditionally, so better not ask the user
> in that configuration, in order to prevent broken builds.

I think this is true for other xscale CPUs as well, so either we make
them unconditionally all at once, or we still leave an option here.

It actually looks quite odd to me that CPU_PJ4 is made special here,
what're the real broken builds errors?

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5ebc5d9..8d66c32 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1071,9 +1071,10 @@ config ARM_TIMER_SP804
> ?source arch/arm/mm/Kconfig
>
> ?config IWMMXT
> - ? ? ? bool "Enable iWMMXt support"
> + ? ? ? bool "Enable iWMMXt support" if !CPU_PJ4
> ? ? ? ?depends on CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_PJ4
> ? ? ? ?default y if PXA27x || PXA3xx || PXA95x || ARCH_MMP
> + ? ? ? default y if CPU_PJ4
> ? ? ? ?help
> ? ? ? ? ?Enable support for iWMMXt context switching at run time if
> ? ? ? ? ?running on a CPU that supports it.
>

[PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT

[Arnd Bergmann]

On Tuesday 04 October 2011, Eric Miao wrote:
> I think this is true for other xscale CPUs as well, so either we make
> them unconditionally all at once, or we still leave an option here.

Do all xscale have iwmmxt?

> It actually looks quite odd to me that CPU_PJ4 is made special here,
> what're the real broken builds errors?

Yes.

I should probably have provided a longer description of the problem.
The build error is in arch/arm/kernel/pj4-cp0.c, which calls
iwmmxt_task_release unconditionally. The code is obviously
copy-pasted from arch/arm/kernel/xscale-cp0.c, which does much
of the same, but uses both run-time and compile-time conditionals
for iwmmxt.

	Arnd

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Arnd Bergmann]

We cannot support ARMv5 and ARMv7 based boards in a single kernel,
so introduce a new option in mach-pxa to select between the two.

The PJ4 (ARMv7) based boards are now only visible when
CONFIG_ARCH_PXA_V7 is set, the other boards are only visible
when it's not set.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |   31 ++++++++++++++++++++++---------
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index cd19309..bb310d0 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -2,6 +2,27 @@ if ARCH_PXA
 
 menu "Intel PXA2xx/PXA3xx Implementations"
 
+config ARCH_PXA_V7
+	bool "ARMv7 (PXA95x) based systems"
+
+if ARCH_PXA_V7
+comment "Marvell Dev Platforms (sorted by hardware release time)"
+config MACH_TAVOREVB3
+	bool "PXA95x Development Platform (aka TavorEVB III)"
+	select CPU_PXA955
+
+config MACH_SAARB
+	bool "PXA955 Handheld Platform (aka SAARB)"
+	select CPU_PXA955
+endif
+
+config PXA_V7_MACH_AUTO
+	def_bool y
+	depends on ARCH_PXA_V7
+	depends on !MACH_SAARB
+	select MACH_TAVOREVB3
+
+if !ARCH_PXA_V7
 comment "Intel/Marvell Dev Platforms (sorted by hardware release time)"
 
 config ARCH_LUBBOCK
@@ -41,19 +62,11 @@ config MACH_TAVOREVB
 	select PXA3xx
 	select CPU_PXA930
 
-config MACH_TAVOREVB3
-	bool "PXA95x Development Platform (aka TavorEVB III)"
-	select CPU_PXA950
-
 config MACH_SAAR
 	bool "PXA930 Handheld Platform (aka SAAR)"
 	select PXA3xx
 	select CPU_PXA930
 
-config MACH_SAARB
-	bool "PXA955 Handheld Platform (aka SAARB)"
-	select CPU_PXA955
-
 comment "Third Party Dev Platforms (sorted by vendor name)"
 
 config ARCH_PXA_IDP
@@ -598,7 +611,7 @@ config MACH_ZIPIT2
 	bool "Zipit Z2 Handheld"
 	select PXA27x
 	select HAVE_PWM
-
+endif
 endmenu
 
 config PXA25x
-- 
1.7.5.4

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Haojian Zhuang]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> We cannot support ARMv5 and ARMv7 based boards in a single kernel,
> so introduce a new option in mach-pxa to select between the two.
>
> The PJ4 (ARMv7) based boards are now only visible when
> CONFIG_ARCH_PXA_V7 is set, the other boards are only visible
> when it's not set.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Kconfig | ? 31 ++++++++++++++++++++++---------
> ?1 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index cd19309..bb310d0 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -2,6 +2,27 @@ if ARCH_PXA
>
> ?menu "Intel PXA2xx/PXA3xx Implementations"
>
> +config ARCH_PXA_V7
> + ? ? ? bool "ARMv7 (PXA95x) based systems"
> +
> +if ARCH_PXA_V7
> +comment "Marvell Dev Platforms (sorted by hardware release time)"
> +config MACH_TAVOREVB3
> + ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
> + ? ? ? select CPU_PXA955
> +
> +config MACH_SAARB
> + ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
> + ? ? ? select CPU_PXA955
> +endif
> +
> +config PXA_V7_MACH_AUTO
> + ? ? ? def_bool y
> + ? ? ? depends on ARCH_PXA_V7
> + ? ? ? depends on !MACH_SAARB
> + ? ? ? select MACH_TAVOREVB3
> +
Could we avoid to use PXA_V7_MACH_AUTO? I think the better way is
defining a new ARCH (ARCH_PXA95X or something else), and sharing the
code in arch/arm/mach-pxa. I think that it's easy to implement.

How about you, Russell & Eric?

> +if !ARCH_PXA_V7
> ?comment "Intel/Marvell Dev Platforms (sorted by hardware release time)"
>
> ?config ARCH_LUBBOCK
> @@ -41,19 +62,11 @@ config MACH_TAVOREVB
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
>
> -config MACH_TAVOREVB3
> - ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
> - ? ? ? select CPU_PXA950
> -
> ?config MACH_SAAR
> ? ? ? ?bool "PXA930 Handheld Platform (aka SAAR)"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
>
> -config MACH_SAARB
> - ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
> - ? ? ? select CPU_PXA955
> -
> ?comment "Third Party Dev Platforms (sorted by vendor name)"
>
> ?config ARCH_PXA_IDP
> @@ -598,7 +611,7 @@ config MACH_ZIPIT2
> ? ? ? ?bool "Zipit Z2 Handheld"
> ? ? ? ?select PXA27x
> ? ? ? ?select HAVE_PWM
> -
> +endif
> ?endmenu
>
> ?config PXA25x
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Eric Miao]

On Sat, Oct 8, 2011 at 10:57 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> We cannot support ARMv5 and ARMv7 based boards in a single kernel,
>> so introduce a new option in mach-pxa to select between the two.
>>
>> The PJ4 (ARMv7) based boards are now only visible when
>> CONFIG_ARCH_PXA_V7 is set, the other boards are only visible
>> when it's not set.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> ?arch/arm/mach-pxa/Kconfig | ? 31 ++++++++++++++++++++++---------
>> ?1 files changed, 22 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
>> index cd19309..bb310d0 100644
>> --- a/arch/arm/mach-pxa/Kconfig
>> +++ b/arch/arm/mach-pxa/Kconfig
>> @@ -2,6 +2,27 @@ if ARCH_PXA
>>
>> ?menu "Intel PXA2xx/PXA3xx Implementations"
>>
>> +config ARCH_PXA_V7
>> + ? ? ? bool "ARMv7 (PXA95x) based systems"
>> +
>> +if ARCH_PXA_V7
>> +comment "Marvell Dev Platforms (sorted by hardware release time)"
>> +config MACH_TAVOREVB3
>> + ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
>> + ? ? ? select CPU_PXA955
>> +
>> +config MACH_SAARB
>> + ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
>> + ? ? ? select CPU_PXA955
>> +endif
>> +
>> +config PXA_V7_MACH_AUTO
>> + ? ? ? def_bool y
>> + ? ? ? depends on ARCH_PXA_V7
>> + ? ? ? depends on !MACH_SAARB
>> + ? ? ? select MACH_TAVOREVB3
>> +
> Could we avoid to use PXA_V7_MACH_AUTO? I think the better way is
> defining a new ARCH (ARCH_PXA95X or something else), and sharing the
> code in arch/arm/mach-pxa. I think that it's easy to implement.
>
> How about you, Russell & Eric?

Haojian,

The patch here is to fix the issue of V5 boards and V7 boards being
built together yet it's not supported (there will be building errors).
And this could be easily spotted with auto/random configurations.

I generally think the patch is fine before we'll allow building of both
v5 and v7 code together (which Nico will be definitely interested in)


>
>> +if !ARCH_PXA_V7
>> ?comment "Intel/Marvell Dev Platforms (sorted by hardware release time)"
>>
>> ?config ARCH_LUBBOCK
>> @@ -41,19 +62,11 @@ config MACH_TAVOREVB
>> ? ? ? ?select PXA3xx
>> ? ? ? ?select CPU_PXA930
>>
>> -config MACH_TAVOREVB3
>> - ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
>> - ? ? ? select CPU_PXA950
>> -
>> ?config MACH_SAAR
>> ? ? ? ?bool "PXA930 Handheld Platform (aka SAAR)"
>> ? ? ? ?select PXA3xx
>> ? ? ? ?select CPU_PXA930
>>
>> -config MACH_SAARB
>> - ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
>> - ? ? ? select CPU_PXA955
>> -
>> ?comment "Third Party Dev Platforms (sorted by vendor name)"
>>
>> ?config ARCH_PXA_IDP
>> @@ -598,7 +611,7 @@ config MACH_ZIPIT2
>> ? ? ? ?bool "Zipit Z2 Handheld"
>> ? ? ? ?select PXA27x
>> ? ? ? ?select HAVE_PWM
>> -
>> +endif
>> ?endmenu
>>
>> ?config PXA25x
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at ?http://www.tux.org/lkml/
>>
>

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Haojian Zhuang]

On Sat, Oct 8, 2011 at 11:21 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Sat, Oct 8, 2011 at 10:57 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> We cannot support ARMv5 and ARMv7 based boards in a single kernel,
>>> so introduce a new option in mach-pxa to select between the two.
>>>
>>> The PJ4 (ARMv7) based boards are now only visible when
>>> CONFIG_ARCH_PXA_V7 is set, the other boards are only visible
>>> when it's not set.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> ?arch/arm/mach-pxa/Kconfig | ? 31 ++++++++++++++++++++++---------
>>> ?1 files changed, 22 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
>>> index cd19309..bb310d0 100644
>>> --- a/arch/arm/mach-pxa/Kconfig
>>> +++ b/arch/arm/mach-pxa/Kconfig
>>> @@ -2,6 +2,27 @@ if ARCH_PXA
>>>
>>> ?menu "Intel PXA2xx/PXA3xx Implementations"
>>>
>>> +config ARCH_PXA_V7
>>> + ? ? ? bool "ARMv7 (PXA95x) based systems"
>>> +
>>> +if ARCH_PXA_V7
>>> +comment "Marvell Dev Platforms (sorted by hardware release time)"
>>> +config MACH_TAVOREVB3
>>> + ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
>>> + ? ? ? select CPU_PXA955rds and V7 boards being
built together yet it's not supported (there will be building errors).
And this could be easily spotted with auto/rds and V7 boards being
built together yet it's not supported (there will be building errors).
And this could be easily spotted with auto/
>>> +
>>> +config MACH_SAARB
>>> + ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
>>> + ? ? ? select CPU_PXA955
>>> +endif
>>> +
>>> +config PXA_V7_MACH_AUTO
>>> + ? ? ? def_bool y
>>> + ? ? ? depends on ARCH_PXA_V7
>>> + ? ? ? depends on !MACH_SAARB
>>> + ? ? ? select MACH_TAVOREVB3
>>> +
>> Could we avoid to use PXA_V7_MACH_AUTO? I think the better way is
>> defining a new ARCH (ARCH_PXA95X or something else), and sharing the
>> code in arch/arm/mach-pxa. I think that it's easy to implement.
>>
>> How about you, Russell & Eric?
>
> Haojian,
>
> The patch here is to fix the issue of V5 boards and V7 boards being
> built together yet it's not supported (there will be building errors).
> And this could be easily spotted with auto/random configurations.
>
> I generally think the patch is fine before we'll allow building of both
> v5 and v7 code together (which Nico will be definitely interested in)
>
>

Eric,

At first, a new macro (ARCH_PXA_V7) is defined in
arch/arm/mach-pxa/Kconfig in this patch.
I prefer to move this macro to arch/arm/Kconfig.

Secondly, pxa95x is both used in saarb and tavorevb3.

Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
machines in defconfig or define a new DT machine type to select all
machines.

Thanks
Haojian

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Arnd Bergmann]

On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
> 
> Eric,
> 
> At first, a new macro (ARCH_PXA_V7) is defined in
> arch/arm/mach-pxa/Kconfig in this patch.
> I prefer to move this macro to arch/arm/Kconfig.

If we move it to arch/arm/Kconfig, I would prefer making it a global option,
not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
option, we can make a number of decisions inside of Kconfig depend on that,
especially as we move to allow building multiple v6/v7 platforms together,
or multiple v5 platforms for that matter. I believe we don't need to
worry about v5+v7 at this point and can instead assume that won't ever
happen.

> Secondly, pxa95x is both used in saarb and tavorevb3.

The patch makes that very explicit, doesn't it?

> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
> machines in defconfig or define a new DT machine type to select all
> machines.

Enabling them in defconfig will not help here, it still allows creating
an invalid configuration by disabling both saarb and tavorevb3.
I agree that it would be best to have a single DT machine type that can
handle both saarb and tavorevb3 as well as any future pxa95x based machines,
but nobody has implemented that yet. In the meantime, I think we should
have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
least one of the two board files gets built into any kernel. This is mostly
important to help the 'make randconfig' builds succeed, not for actual
users getting it wrong accidentally.

	Arnd

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Haojian Zhuang]

On Sat, Oct 8, 2011 at 9:24 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
>>
>> Eric,
>>
>> At first, a new macro (ARCH_PXA_V7) is defined in
>> arch/arm/mach-pxa/Kconfig in this patch.
>> I prefer to move this macro to arch/arm/Kconfig.
>
> If we move it to arch/arm/Kconfig, I would prefer making it a global option,
> not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
> option, we can make a number of decisions inside of Kconfig depend on that,
> especially as we move to allow building multiple v6/v7 platforms together,
> or multiple v5 platforms for that matter. I believe we don't need to
> worry about v5+v7 at this point and can instead assume that won't ever
> happen.
>
Nobody is using PJ4 as v6 architecture now. CPUv6 is used in old stepping
of Dove and MMP2. CPU_PJ4 only enables CPU_v7 in the mainline code.

If we used ARCH_PXA_V7 in arch/arm/Kconfig, we would have two ARCH for
pxa. One is ARCH_PXA, and the other is ARCH_PXA_V7. Those v5 machine
should be based on ARCH_PXA. And the saarb, tavorevb3 should be based
on ARCH_PXA_V7. So we can avoid to define PXA_V7_MACH_AUTO. I think
the logic of Kconfig could be easier.

>> Secondly, pxa95x is both used in saarb and tavorevb3.
>
> The patch makes that very explicit, doesn't it?
>
+config PXA_V7_MACH_AUTO
+       def_bool y
+       depends on ARCH_PXA_V7
+       depends on !MACH_SAARB
+       select MACH_TAVOREVB3
+

Please check this. In your patch, SAARB and TAVOREVB3 is a mutex.

>> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
>> machines in defconfig or define a new DT machine type to select all
>> machines.
>
> Enabling them in defconfig will not help here, it still allows creating
> an invalid configuration by disabling both saarb and tavorevb3.
> I agree that it would be best to have a single DT machine type that can
> handle both saarb and tavorevb3 as well as any future pxa95x based machines,
> but nobody has implemented that yet. In the meantime, I think we should
> have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
> least one of the two board files gets built into any kernel. This is mostly
> important to help the 'make randconfig' builds succeed, not for actual
> users getting it wrong accidentally.
>
> ? ? ? ?Arnd
>

Exactly we need to define a single DT machine type in both arch-pxa
and arch-mmp.
I'll register it first.

Thanks
Haojian

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Eric Miao]

On Sun, Oct 9, 2011 at 2:21 PM, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
> On Sat, Oct 8, 2011 at 9:24 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
>>>
>>> Eric,
>>>
>>> At first, a new macro (ARCH_PXA_V7) is defined in
>>> arch/arm/mach-pxa/Kconfig in this patch.
>>> I prefer to move this macro to arch/arm/Kconfig.
>>
>> If we move it to arch/arm/Kconfig, I would prefer making it a global option,
>> not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
>> option, we can make a number of decisions inside of Kconfig depend on that,
>> especially as we move to allow building multiple v6/v7 platforms together,
>> or multiple v5 platforms for that matter. I believe we don't need to
>> worry about v5+v7 at this point and can instead assume that won't ever
>> happen.
>>
> Nobody is using PJ4 as v6 architecture now. CPUv6 is used in old stepping
> of Dove and MMP2. CPU_PJ4 only enables CPU_v7 in the mainline code.
>
> If we used ARCH_PXA_V7 in arch/arm/Kconfig, we would have two ARCH for
> pxa. One is ARCH_PXA, and the other is ARCH_PXA_V7. Those v5 machine
> should be based on ARCH_PXA. And the saarb, tavorevb3 should be based
> on ARCH_PXA_V7. So we can avoid to define PXA_V7_MACH_AUTO. I think
> the logic of Kconfig could be easier.

Haojian,

PXA_V7_MACH_AUTO is to by default auto enable tavorevb3 when
ARCH_PXA_V7 is selected.

>
>>> Secondly, pxa95x is both used in saarb and tavorevb3.
>>
>> The patch makes that very explicit, doesn't it?
>>
> +config PXA_V7_MACH_AUTO
> + ? ? ? def_bool y
> + ? ? ? depends on ARCH_PXA_V7
> + ? ? ? depends on !MACH_SAARB
> + ? ? ? select MACH_TAVOREVB3
> +
>
> Please check this. In your patch, SAARB and TAVOREVB3 is a mutex.

They are actually not mutually exclusive - it's a trick we use to select
MACH_TAVOREVB3 by default but this option also disappears once SAARB
is selected.

Arnd,

The 'depends on ARCH_PXA_V7' could actually be removed here, as the
option is already encapsulated in if ARCH_PXA_V7 ... endif. And this
trick won't work very well when there are more than 2 boards.

>
>>> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
>>> machines in defconfig or define a new DT machine type to select all
>>> machines.
>>
>> Enabling them in defconfig will not help here, it still allows creating
>> an invalid configuration by disabling both saarb and tavorevb3.
>> I agree that it would be best to have a single DT machine type that can
>> handle both saarb and tavorevb3 as well as any future pxa95x based machines,
>> but nobody has implemented that yet. In the meantime, I think we should
>> have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
>> least one of the two board files gets built into any kernel. This is mostly
>> important to help the 'make randconfig' builds succeed, not for actual
>> users getting it wrong accidentally.
>>
>> ? ? ? ?Arnd
>>
>
> Exactly we need to define a single DT machine type in both arch-pxa
> and arch-mmp.
> I'll register it first.

Please go ahead.

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Haojian Zhuang]

On Sun, Oct 9, 2011 at 2:36 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Sun, Oct 9, 2011 at 2:21 PM, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
>> On Sat, Oct 8, 2011 at 9:24 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
>>>>
>>>> Eric,
>>>>
>>>> At first, a new macro (ARCH_PXA_V7) is defined in
>>>> arch/arm/mach-pxa/Kconfig in this patch.
>>>> I prefer to move this macro to arch/arm/Kconfig.
>>>
>>> If we move it to arch/arm/Kconfig, I would prefer making it a global option,
>>> not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
>>> option, we can make a number of decisions inside of Kconfig depend on that,
>>> especially as we move to allow building multiple v6/v7 platforms together,
>>> or multiple v5 platforms for that matter. I believe we don't need to
>>> worry about v5+v7 at this point and can instead assume that won't ever
>>> happen.
>>>
>> Nobody is using PJ4 as v6 architecture now. CPUv6 is used in old stepping
>> of Dove and MMP2. CPU_PJ4 only enables CPU_v7 in the mainline code.
>>
>> If we used ARCH_PXA_V7 in arch/arm/Kconfig, we would have two ARCH for
>> pxa. One is ARCH_PXA, and the other is ARCH_PXA_V7. Those v5 machine
>> should be based on ARCH_PXA. And the saarb, tavorevb3 should be based
>> on ARCH_PXA_V7. So we can avoid to define PXA_V7_MACH_AUTO. I think
>> the logic of Kconfig could be easier.
>ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7iMTlInbItkRaH3yJidg18Bg1SyIYZhbgu4jKpRkG4vavWebU6FwjovIuXoJqWzQimP4dvF4LWVq1xW84jtds8hRIc0a9nI1o2DUyqFzYvHHbqjXq+AJCqmUCaf9mlGn5/Ocd4LDbZKff3rHApCZrP4J/5beIiBDX25sFyRPNFjakJp5FbqwT17L91900rj7O60UeTe/vI9Gaf/oIvxMYriDmF02vsQgNqVNUzFllB8VTVb5HprZFZFX0ulBWhgTfMNqrhcZAxKwAW8tAY2zqa7NZZQhw0Ea8IkZrwA4qAwjQHwY56mNL7JRFLKlLVt3dEfkgx/HHWS8v1D80VGXUw== zhouhong at zhouhong-desktop
> Haojian,
>
> PXA_V7_MACH_AUTO is to by default auto enable tavorevb3 when
> ARCH_PXA_V7 is selected.
>
>>
>>>> Secondly, pxa95x is both used in saarb and tavorevb3.
>>>
>>> The patch makes that very explicit, doesn't it?
>>>
>> +config PXA_V7_MACH_AUTO
>> + ? ? ? def_bool y
>> + ? ? ? depends on ARCH_PXA_V7
>> + ? ? ? depends on !MACH_SAARB
>> + ? ? ? select MACH_TAVOREVB3
>> +
>>
>> Please check this. In your patch, SAARB and TAVOREVB3 is a mutex.
>
> They are actually not mutually exclusive - it's a trick we use to select
> MACH_TAVOREVB3 by default but this option also disappears once SAARB
> is selected.
>
OK. Could I know why saarb should be deselected while tavorevb3 is selected?

> Arnd,
>
> The 'depends on ARCH_PXA_V7' could actually be removed here, as the
> option is already encapsulated in if ARCH_PXA_V7 ... endif. And this
> trick won't work very well when there are more than 2 boards.
>
>>
>>>> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
>>>> machines in defconfig or define a new DT machine type to select all
>>>> machines.
>>>
>>> Enabling them in defconfig will not help here, it still allows creating
>>> an invalid configuration by disabling both saarb and tavorevb3.
>>> I agree that it would be best to have a single DT machine type that can
>>> handle both saarb and tavorevb3 as well as any future pxa95x based machines,
>>> but nobody has implemented that yet. In the meantime, I think we should
>>> have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
>>> least one of the two board files gets built into any kernel. This is mostly
>>> important to help the 'make randconfig' builds succeed, not for actual
>>> users getting it wrong accidentally.
>>>
>>> ? ? ? ?Arnd
>>>
>>
>> Exactly we need to define a single DT machine type in both arch-pxa
>> and arch-mmp.
>> I'll register it first.
>
> Please go ahead.
>

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Eric Miao]

>> They are actually not mutually exclusive - it's a trick we use to select
>> MACH_TAVOREVB3 by default but this option also disappears once SAARB
>> is selected.
>>
> OK. Could I know why saarb should be deselected while tavorevb3 is selected?

Haojian, it's not being deselected, it's just when user selects SAARB,
this config PXA_V7_MACH_AUTO becomes invalid (which means at
least one PXA_V7_MACH is selected), and then you could select
TAVOREVB3 as well.

Just go ahead and apply the patch, make menuconfig and see how
the trick works :-)

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Arnd Bergmann]

On Sunday 09 October 2011 14:36:52 Eric Miao wrote:
> 
> They are actually not mutually exclusive - it's a trick we use to select
> MACH_TAVOREVB3 by default but this option also disappears once SAARB
> is selected.

Right. It's a bit hard to read when there are only two of them, but that
is the idea.

> The 'depends on ARCH_PXA_V7' could actually be removed here, as the
> option is already encapsulated in if ARCH_PXA_V7 ... endif. And this
> trick won't work very well when there are more than 2 boards.

Actually, the option is outside of the if ARCH_PXA_V7, but that could
easily be changed.

The trick works with as many boards as you like, it just gets a
little clumsy after while, as in

config MACH_OMAP_AUTO_BOARD
        def_bool y
        depends on !MACH_OMAP2_TUSB6010
        depends on !MACH_OMAP_H4
        depends on !MACH_OMAP_APOLLON
        depends on !MACH_OMAP_APOLLON
        depends on !MACH_OMAP_2430SDP
        depends on !MACH_OMAP3_BEAGLE
        depends on !MACH_DEVKIT8000
        depends on !MACH_OMAP_LDP
        depends on !MACH_OMAP3530_LV_SOM
        depends on !MACH_OMAP3_TORPEDO
        depends on !MACH_OVERO
        depends on !MACH_OMAP3EVM
        depends on !MACH_OMAP3517EVM
        depends on !MACH_CRANEBOARD
        depends on !MACH_OMAP3_PANDORA
        depends on !MACH_OMAP3_TOUCHBOOK
        depends on !MACH_NOKIA_N8X0
        depends on !MACH_NOKIA_RM680
        depends on !MACH_NOKIA_RX51
        depends on !MACH_OMAP_ZOOM2
        depends on !MACH_OMAP_ZOOM3
        depends on !MACH_CM_T35
        depends on !MACH_CM_T3517
        depends on !MACH_IGEP0020
        depends on !MACH_IGEP0030
        depends on !MACH_SBC3530
        depends on !MACH_OMAP_3630SDP
        depends on !MACH_TI8168EVM
        depends on !MACH_OMAP4_PANDA
        select MACH_OMAP_GENERIC if ARCH_OMAP2
        select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2
        select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2
        help
          The kernel needs to have support for at least one board
          in order to build. If none is selected, default to the
          generic board.

We should probably do something like this for the ARMv5 based PXA boards,
but at least a randconfig won't trigger that normally, just because there
are so many of them that almost always at least one is enabled. However,
an allnoconfig will fail with PXA right now.

	Arnd

[PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa

[Arnd Bergmann]

On Sunday 09 October 2011 14:21:35 Haojian Zhuang wrote:
> > If we move it to arch/arm/Kconfig, I would prefer making it a global option,
> > not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
> > option, we can make a number of decisions inside of Kconfig depend on that,
> > especially as we move to allow building multiple v6/v7 platforms together,
> > or multiple v5 platforms for that matter. I believe we don't need to
> > worry about v5+v7 at this point and can instead assume that won't ever
> > happen.
> >
> Nobody is using PJ4 as v6 architecture now. CPUv6 is used in old stepping
> of Dove and MMP2. CPU_PJ4 only enables CPU_v7 in the mainline code.
> 
> If we used ARCH_PXA_V7 in arch/arm/Kconfig, we would have two ARCH for
> pxa. One is ARCH_PXA, and the other is ARCH_PXA_V7. Those v5 machine
> should be based on ARCH_PXA. And the saarb, tavorevb3 should be based
> on ARCH_PXA_V7. So we can avoid to define PXA_V7_MACH_AUTO. I think
> the logic of Kconfig could be easier.

I was referring to building different subarchitectures together.
We want to eventually be able to build a single kernel that
works on e.g. pxa95x (ARMv7) and omap2 (ARMv6), and we hope to get
there within the next few release. This is completely unrelated to
building a combination of old-world (ARMv3/v4/v5) and new-world
(ARMv6/v7) in a single kernel, which is something that we decided
not to try supporting in the forseeable future.

	Arnd

[PATCH 18/26] ARM: pxa: MTD_XIP is not actually working any more

[Arnd Bergmann]

The headers files required for XIP support have moved around
over the last few years, and the code no longer builds.
Until someone fixes this, let's just disable support, leaving
sa1100 as the only platform still supporting xip.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/Kconfig |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 570c9fd..71b0ccb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -619,7 +619,6 @@ config ARCH_PNX4008
 config ARCH_PXA
 	bool "PXA2xx/PXA3xx-based"
 	depends on MMU
-	select ARCH_MTD_XIP
 	select ARCH_HAS_CPUFREQ
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
-- 
1.7.5.4

[PATCH 18/26] ARM: pxa: MTD_XIP is not actually working any more

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The headers files required for XIP support have moved around
> over the last few years, and the code no longer builds.
> Until someone fixes this, let's just disable support, leaving
> sa1100 as the only platform still supporting xip.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

It is actually fixable, the problem is really mtd-xip.h is referencing
the interrupt registers directly which I moved them to mach-pxa/irq.c
for better modularization.

I'm fine to drop XIP. I'm afraid Nico's gonna be a bit disappointed
as I broke his favorite XIP code :-)

> ---
> ?arch/arm/Kconfig | ? ?1 -
> ?1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 570c9fd..71b0ccb 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -619,7 +619,6 @@ config ARCH_PNX4008
> ?config ARCH_PXA
> ? ? ? ?bool "PXA2xx/PXA3xx-based"
> ? ? ? ?depends on MMU
> - ? ? ? select ARCH_MTD_XIP
> ? ? ? ?select ARCH_HAS_CPUFREQ
> ? ? ? ?select CLKDEV_LOOKUP
> ? ? ? ?select CLKSRC_MMIO
> --
> 1.7.5.4
>
>

[PATCH 18/26] ARM: pxa: MTD_XIP is not actually working any more

[Nicolas Pitre]

On Sat, 8 Oct 2011, Eric Miao wrote:

> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The headers files required for XIP support have moved around
> > over the last few years, and the code no longer builds.
> > Until someone fixes this, let's just disable support, leaving
> > sa1100 as the only platform still supporting xip.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> It is actually fixable, the problem is really mtd-xip.h is referencing
> the interrupt registers directly which I moved them to mach-pxa/irq.c
> for better modularization.
> 
> I'm fine to drop XIP. I'm afraid Nico's gonna be a bit disappointed
> as I broke his favorite XIP code :-)

Well, I don't care much myself.  I have no use for that capability, even 
though this was interesting to implement.  So it only depends if someone 
relies on this or not.

A few months ago I asked on the list if XIP was still useful, and Tim 
Bird replied that Sony was indeed using it.  So if this is not too hard 
to keep this feature alive then I'd go with that option.


Nicolas

[PATCH 19/26] ARM: pxa: CPU_FREQ_TABLE is needed for CPU_FREQ

[Arnd Bergmann]

The pxa specific cpufreq code is based on the cpu_freq_table
module, so we have to select that.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 71b0ccb..3b84eda 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1926,6 +1926,7 @@ config CPU_FREQ_PXA
 	bool
 	depends on CPU_FREQ && ARCH_PXA && PXA25x
 	default y
+	select CPU_FREQ_TABLE
 	select CPU_FREQ_DEFAULT_GOV_USERSPACE
 
 config CPU_FREQ_S3C
-- 
1.7.5.4

[PATCH 19/26] ARM: pxa: CPU_FREQ_TABLE is needed for CPU_FREQ

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The pxa specific cpufreq code is based on the cpu_freq_table
> module, so we have to select that.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

> ---
> ?arch/arm/Kconfig | ? ?1 +
> ?1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 71b0ccb..3b84eda 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1926,6 +1926,7 @@ config CPU_FREQ_PXA
> ? ? ? ?bool
> ? ? ? ?depends on CPU_FREQ && ARCH_PXA && PXA25x
> ? ? ? ?default y
> + ? ? ? select CPU_FREQ_TABLE
> ? ? ? ?select CPU_FREQ_DEFAULT_GOV_USERSPACE
>
> ?config CPU_FREQ_S3C
> --
> 1.7.5.4
>
>

[PATCH 20/26] ARM: pxa: select FB_PXA on saar and tevorevb

[Arnd Bergmann]

The saar and tevorevb platforms call pxafb_smart_flush from board
code, and that function is defined in the framebuffer code, so it
cannot be disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index bb310d0..cd94f2f 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -61,11 +61,15 @@ config MACH_TAVOREVB
 	bool "PXA930 Evaluation Board (aka TavorEVB)"
 	select PXA3xx
 	select CPU_PXA930
+	select FB_PXA
+	select FB
 
 config MACH_SAAR
 	bool "PXA930 Handheld Platform (aka SAAR)"
 	select PXA3xx
 	select CPU_PXA930
+	select FB_PXA
+	select FB
 
 comment "Third Party Dev Platforms (sorted by vendor name)"
 
-- 
1.7.5.4

[PATCH 20/26] ARM: pxa: select FB_PXA on saar and tevorevb

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The saar and tevorevb platforms call pxafb_smart_flush from board
> code, and that function is defined in the framebuffer code, so it
> cannot be disabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?4 ++++
> ?1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index bb310d0..cd94f2f 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -61,11 +61,15 @@ config MACH_TAVOREVB
> ? ? ? ?bool "PXA930 Evaluation Board (aka TavorEVB)"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
> + ? ? ? select FB_PXA
> + ? ? ? select FB
>
> ?config MACH_SAAR
> ? ? ? ?bool "PXA930 Handheld Platform (aka SAAR)"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
> + ? ? ? select FB_PXA
> + ? ? ? select FB

Hi Arnd,

The option really matters is FB_PXA_SMARTPANEL, which adds support
for the display driver to control an external "smart" LCD panel. And how
about the patch below to fix this - as normal, make empty functions
when not enabled?

diff --git a/arch/arm/mach-pxa/include/mach/pxafb.h
b/arch/arm/mach-pxa/include/mach/pxafb.h
index 01a45ac..486b4c5 100644
--- a/arch/arm/mach-pxa/include/mach/pxafb.h
+++ b/arch/arm/mach-pxa/include/mach/pxafb.h
@@ -158,5 +158,18 @@ struct pxafb_mach_info {
 void pxa_set_fb_info(struct device *, struct pxafb_mach_info *);
 unsigned long pxafb_get_hsync_time(struct device *dev);

+#ifdef CONFIG_FB_PXA_SMARTPANEL
 extern int pxafb_smart_queue(struct fb_info *info, uint16_t *cmds, int);
 extern int pxafb_smart_flush(struct fb_info *info);
+#else
+static inline int pxafb_smart_queue(struct fb_info *info,
+				    uint16_t *cmds, int n)
+{
+	return 0;
+}
+
+static inline int pxafb_smart_flush(struct fb_info *info)
+{
+	return 0;
+}
+#endif
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 0f4e8c9..389530b 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -1309,16 +1309,6 @@ static int pxafb_smart_init(struct pxafb_info *fbi)
 	return 0;
 }
 #else
-int pxafb_smart_queue(struct fb_info *info, uint16_t *cmds, int n_cmds)
-{
-	return 0;
-}
-
-int pxafb_smart_flush(struct fb_info *info)
-{
-	return 0;
-}
-
 static inline int pxafb_smart_init(struct pxafb_info *fbi) { return 0; }
 #endif /* CONFIG_FB_PXA_SMARTPANEL */

[PATCH 20/26] ARM: pxa: select FB_PXA on saar and tevorevb

[Arnd Bergmann]

On Saturday 08 October 2011 17:50:31 Eric Miao wrote:
> 
> The option really matters is FB_PXA_SMARTPANEL, which adds support
> for the display driver to control an external "smart" LCD panel. And how
> about the patch below to fix this - as normal, make empty functions
> when not enabled?
> 

Yes, your patch looks better than mine.

Thanks,

	Arnd

[PATCH 21/26] ARM: pxa: select POWER_SUPPLY on raumfeld

[Arnd Bergmann]

The raumfeld platform code calls power_supply_set_battery_charged
which is part of the power supply layer, so that always has
to be enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index cd94f2f..491c522 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -453,15 +453,18 @@ config MACH_RAUMFELD_RC
 	bool "Raumfeld Controller"
 	select PXA3xx
 	select CPU_PXA300
+	select POWER_SUPPLY
 	select HAVE_PWM
 
 config MACH_RAUMFELD_CONNECTOR
 	bool "Raumfeld Connector"
+	select POWER_SUPPLY
 	select PXA3xx
 	select CPU_PXA300
 
 config MACH_RAUMFELD_SPEAKER
 	bool "Raumfeld Speaker"
+	select POWER_SUPPLY
 	select PXA3xx
 	select CPU_PXA300
 
-- 
1.7.5.4

[PATCH 21/26] ARM: pxa: select POWER_SUPPLY on raumfeld

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The raumfeld platform code calls power_supply_set_battery_charged
> which is part of the power supply layer, so that always has
> to be enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

A better way might be for the raumfeld board file to compile the code
based on whether POWER_SUPPLY is selected. However, the power supply
code for raumfeld is a bit difficult to separate indeed, let's merge this
before that happens.

Daniel?

> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index cd94f2f..491c522 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -453,15 +453,18 @@ config MACH_RAUMFELD_RC
> ? ? ? ?bool "Raumfeld Controller"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA300
> + ? ? ? select POWER_SUPPLY
> ? ? ? ?select HAVE_PWM
>
> ?config MACH_RAUMFELD_CONNECTOR
> ? ? ? ?bool "Raumfeld Connector"
> + ? ? ? select POWER_SUPPLY
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA300
>
> ?config MACH_RAUMFELD_SPEAKER
> ? ? ? ?bool "Raumfeld Speaker"
> + ? ? ? select POWER_SUPPLY
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA300
>
> --
> 1.7.5.4
>
>

[PATCH 22/26] ARM: pxa: only select SMC91x on xcep when networking is enabled

[Arnd Bergmann]

The smc91x driver is not strictly required for xcep, but it
can only be enabled if ethernet support is built into the
kernel, so make the dependency more specific.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 491c522..ef35ce9 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -174,7 +174,7 @@ config MACH_XCEP
 	select MTD_CFI_INTELEXT
 	select MTD_CFI
 	select MTD_CHAR
-	select SMC91X
+	select SMC91X if NET_ETHERNET
 	help
 	  PXA255 based Single Board Computer with SMC 91C111 ethernet chip and 64 MB of flash.
 	  Tuned for usage in Libera instruments for particle accelerators.
-- 
1.7.5.4

[PATCH 22/26] ARM: pxa: only select SMC91x on xcep when networking is enabled

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The smc91x driver is not strictly required for xcep, but it
> can only be enabled if ethernet support is built into the
> kernel, so make the dependency more specific.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 491c522..ef35ce9 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -174,7 +174,7 @@ config MACH_XCEP
> ? ? ? ?select MTD_CFI_INTELEXT
> ? ? ? ?select MTD_CFI
> ? ? ? ?select MTD_CHAR
> - ? ? ? select SMC91X
> + ? ? ? select SMC91X if NET_ETHERNET

Or let's just remove this 'select SMC91X' completely as it's not
strictly required?

BTW - how's the Kconfig cleanup works going? I guess going forward,
the best way for such cases might be to introduce HAVE_SMC91X, and
let SMC91X to depend on this? However, that could in turn introduce
a massive number of HAVE_* for various drivers.

> ? ? ? ?help
> ? ? ? ? ?PXA255 based Single Board Computer with SMC 91C111 ethernet chip and 64 MB of flash.
> ? ? ? ? ?Tuned for usage in Libera instruments for particle accelerators.
> --
> 1.7.5.4
>
>

[PATCH 23/26] ARM: pxa: viper: select I2C_GPIO only when I2C is on

[Arnd Bergmann]

The viper platform selects the i2c_gpio driver, but that does
not build when i2c itself is disabled. Rather than also selecting
i2c, this makes the select conditional.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index ef35ce9..568b7f6 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -81,7 +81,7 @@ config ARCH_VIPER
 	bool "Arcom/Eurotech VIPER SBC"
 	select PXA25x
 	select ISA
-	select I2C_GPIO
+	select I2C_GPIO if I2C
 	select HAVE_PWM
 	select PXA_HAVE_ISA_IRQS
 	select ARCOM_PCMCIA
-- 
1.7.5.4

[PATCH 24/26] ARM: pxa: centro and treo680 need palm27x

[Arnd Bergmann]

The two platforms are part of the palm27x family and use the same
code. Select the palm27x symbol to make sure they can be built
standalone.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 568b7f6..da6fca0 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -431,6 +431,7 @@ config MACH_CENTRO
 	bool "Palm Centro 685 (GSM)"
 	default y
 	depends on ARCH_PXA_PALM
+	select MACH_PALM27X
 	select PXA27x
 	select IWMMXT
 	select PALM_TREO
@@ -442,6 +443,7 @@ config MACH_TREO680
 	bool "Palm Treo 680"
 	default y
 	depends on ARCH_PXA_PALM
+	select MACH_PALM27X
 	select PXA27x
 	select IWMMXT
 	select PALM_TREO
-- 
1.7.5.4

[PATCH 24/26] ARM: pxa: centro and treo680 need palm27x

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The two platforms are part of the palm27x family and use the same
> code. Select the palm27x symbol to make sure they can be built
> standalone.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 568b7f6..da6fca0 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -431,6 +431,7 @@ config MACH_CENTRO
> ? ? ? ?bool "Palm Centro 685 (GSM)"
> ? ? ? ?default y
> ? ? ? ?depends on ARCH_PXA_PALM
> + ? ? ? select MACH_PALM27X
> ? ? ? ?select PXA27x
> ? ? ? ?select IWMMXT
> ? ? ? ?select PALM_TREO
> @@ -442,6 +443,7 @@ config MACH_TREO680
> ? ? ? ?bool "Palm Treo 680"
> ? ? ? ?default y
> ? ? ? ?depends on ARCH_PXA_PALM
> + ? ? ? select MACH_PALM27X
> ? ? ? ?select PXA27x
> ? ? ? ?select IWMMXT
> ? ? ? ?select PALM_TREO
> --
> 1.7.5.4
>
>

[PATCH 24/26] ARM: pxa: centro and treo680 need palm27x

[Marek Vasut]

On Saturday, October 08, 2011 12:20:57 PM Eric Miao wrote:
> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The two platforms are part of the palm27x family and use the same
> > code. Select the palm27x symbol to make sure they can be built
> > standalone.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Applied.

Thanks Eric.

[PATCH 25/26] ARM: pxa: eseries does not require FB

[Arnd Bergmann]

It is possible to build a kernel for eseries without framebuffer support,
so it must not select the w100 driver unconditionally.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index da6fca0..3733971 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -566,7 +566,7 @@ config MACH_ICONTROL
 config ARCH_PXA_ESERIES
 	bool "PXA based Toshiba e-series PDAs"
 	select PXA25x
-	select FB_W100
+	select FB_W100 if FB=y
 
 config MACH_E330
 	bool "Toshiba e330"
-- 
1.7.5.4

[PATCH 26/26] ARM: pxa: sharpsl pm needs SPI

[Arnd Bergmann]

The sharpsl code selects the max1111 spi driver, so it must also
ensure that SPI itself is enabled. The platform does not work
without max1111.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-pxa/Kconfig |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 3733971..6dee18e 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -710,6 +710,8 @@ config SHARPSL_PM
 config SHARPSL_PM_MAX1111
 	bool
 	select HWMON
+	select SPI
+	select SPI_MASTER
 	select SENSORS_MAX1111
 
 config PXA_HAVE_ISA_IRQS
-- 
1.7.5.4

[PATCH 26/26] ARM: pxa: sharpsl pm needs SPI

[Eric Miao]

On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The sharpsl code selects the max1111 spi driver, so it must also
> ensure that SPI itself is enabled. The platform does not work
> without max1111.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 3733971..6dee18e 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -710,6 +710,8 @@ config SHARPSL_PM
> ?config SHARPSL_PM_MAX1111
> ? ? ? ?bool
> ? ? ? ?select HWMON
> + ? ? ? select SPI
> + ? ? ? select SPI_MASTER
> ? ? ? ?select SENSORS_MAX1111
>
> ?config PXA_HAVE_ISA_IRQS
> --
> 1.7.5.4
>
>