"ARM: MX3: fix CPU revision number detection" breaks QONG support

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[Wolfgang Denk]

Dear Daniel,

commit v2.6.32-rc6-49-g52939c0 "ARM: MX3: fix CPU revision number
detection" breaks booting on the QONG board - there is no output on
the console any more after this commit is added.

Do you have any idea in which area I should start looking for the
cause of this problem?

Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Steal five dollars and you were a petty  thief.  Steal  thousands  of
dollars and you are either a government or a hero.
                                   - Terry Pratchett, _Going_Postal_

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[Daniel Mack]

On Fri, Dec 11, 2009 at 03:33:18PM +0100, Wolfgang Denk wrote:
> commit v2.6.32-rc6-49-g52939c0 "ARM: MX3: fix CPU revision number
> detection" breaks booting on the QONG board - there is no output on
> the console any more after this commit is added.
> 
> Do you have any idea in which area I should start looking for the
> cause of this problem?

Yes, Vaentin Lonchamp (cc) also reported that problem. The problem seems
to be related to things the bootloader does to your board, and I'm not
sure yet where the difference is between the MX31 LiteKit and others. My
suspect was that the clocks are not set up properly, but they have been
reported to be ok. What fails is a single register access. Maybe access
to this function block needs to be enabled or unlocked or something?
Unfortunately, as the LoLo bootloader on this board does not ship with
sources, I'm fishing in muddy waters.

Next problem is that I'm currently abroad and don't have access to MX3
hardware. As soon as I'm back, I'll try more boards and see if they
behave differently.

In the meantime, if nobody is able to figure out the root cause, we
might consider reverthing this patch.

Sorry for the trouble caused.

Daniel

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[Wolfgang Denk]

Dear Daniel Mack,

In message <20091211234714.GT28375@buzzloop.caiaq.de> you wrote:
> 
> Yes, Vaentin Lonchamp (cc) also reported that problem. The problem seems
> to be related to things the bootloader does to your board, and I'm not
> sure yet where the difference is between the MX31 LiteKit and others. My
> suspect was that the clocks are not set up properly, but they have been
> reported to be ok. What fails is a single register access. Maybe access
> to this function block needs to be enabled or unlocked or something?

I don't think this is a boot loader issue.

In Linux, the kernel hangs here:

	/* read SREV register from IIM module */
	srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);

In U-Boot, I can read this register just fine:

	=> md 5001c024 1
	5001c024: 00000028    (...

In Linux, the IO_ADDRESS() makes this a read from 0xFC11C024, which
hangs.

So if this is a clock thing, then it must be a clock being disabled by
Linux.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
But the only way of discovering the limits  of  the  possible  is  to
venture a little way past them into the impossible.
                         - _Profiles of the Future_ (1962; rev. 1973)
                  ``Hazards of Prophecy: The Failure of Imagination''

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[Andy Green]

On 12/14/09 13:57, Somebody in the thread at some point said:

Hi Wolfgang -

> In Linux, the kernel hangs here:
>
> 	/* read SREV register from IIM module */
> 	srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);

In iMX31 IIM is very strangely a specifically 8-bit peripheral on a 
32-bit bus.  I wrote some code to read and write the fuses recently.

Maybe it's required to change it to __raw_readb; mine are already byte 
operations.

> In U-Boot, I can read this register just fine:
>
> 	=>  md 5001c024 1
> 	5001c024: 00000028    (...
>
> In Linux, the IO_ADDRESS() makes this a read from 0xFC11C024, which
> hangs.
>
> So if this is a clock thing, then it must be a clock being disabled by
> Linux.

Around my (working) IIM operations I have this code:

	iim_clk = clk_get(NULL, "iim");
	if (IS_ERR(iim_clk)) {
		pr_err("No IIM clock defined\n");
		return -EINVAL;
	}
	clk_enable(iim_clk);

...

	clk_disable(iim_clk);
	clk_put(iim_clk);

-Andy

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[Daniel Mack]

On Mon, Dec 14, 2009 at 02:57:22PM +0100, Wolfgang Denk wrote:
> I don't think this is a boot loader issue.
> 
> In Linux, the kernel hangs here:
> 
> 	/* read SREV register from IIM module */
> 	srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);
> 
> In U-Boot, I can read this register just fine:
> 
> 	=> md 5001c024 1
> 	5001c024: 00000028    (...
> 
> In Linux, the IO_ADDRESS() makes this a read from 0xFC11C024, which
> hangs.
> 
> So if this is a clock thing, then it must be a clock being disabled by
> Linux.

Well, clocks are explicitly enabled for that module, so I really don't
know. And I can't debug as I'm not at my office where the hardware is I
developed this on. Can anyone help check what's the matter? As I said,
on my MX31LiteKit, that works as expected and the register definition
reads as something that must have been there for a longer time (taking
into account that possible values for that register cover ancient
variants of that hardware).

As I said already, we could also consider reverting this patch - I'll
have another look and ask for more testers when I'm back. I would,
however, greatly prefer a fixup patch.

Daniel

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[valentin.longchamp at epfl.ch]

Daniel Mack <daniel@caiaq.de> a ?crit?:

> On Mon, Dec 14, 2009 at 02:57:22PM +0100, Wolfgang Denk wrote:
>> I don't think this is a boot loader issue.
>>
>> In Linux, the kernel hangs here:
>>
>> 	/* read SREV register from IIM module */
>> 	srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);
>>
>> In U-Boot, I can read this register just fine:
>>
>> 	=> md 5001c024 1
>> 	5001c024: 00000028    (...
>>
>> In Linux, the IO_ADDRESS() makes this a read from 0xFC11C024, which
>> hangs.
>>
>> So if this is a clock thing, then it must be a clock being disabled by
>> Linux.

I have looked more carefully at the bootloader code, and it does not  
seem to configure anything for SPBA0. Furthermore, Redboot actually  
reads this register at boot time to determine the CPU revision just as  
Daniel with its patch.

As for Wolfgang, when I ask Redboot to dump this memory region, I can  
read the revision as well (0x28 here too). I would then also rule the  
bootloader out of the culprits. It would be interesting to see what  
CPU revisions have the people who experience the problem and the ones  
who don't (but I don't think it does play a role).

For the IO_ADDRESS stuff, it may be the problem. This macro is  
supposed to do the physical address -> virtual address translation. If  
I have understood correctly (correct if wrong, I don't really know  
when whe have to use it or not), it is used when the memory region was  
not allocated and then mapped with request_mem_region and ioremap  
calls. The 0xFC11C024 is the virtual address defined by the IO_ADDRESS  
macro succession for the SPBA0 memory region. Now how was this defined  
and may this fail on certain systems/configuration because other  
memory definitions ?

>
> Well, clocks are explicitly enabled for that module, so I really don't
> know. And I can't debug as I'm not at my office where the hardware is I
> developed this on. Can anyone help check what's the matter? As I said,
> on my MX31LiteKit, that works as expected and the register definition
> reads as something that must have been there for a longer time (taking
> into account that possible values for that register cover ancient
> variants of that hardware).

The iim clock is explicitely enabled in clock.c, just before the call  
to mx31_read_cpu_rev(), and from what I had checked, the clock  
effectively seemed enabled for me. I have no clue about the register  
definition since I have found no real documentation about it, but from  
my point of view, this would more look like 8 bit registers as Andy  
pointed out in an earlier mail.

>
> As I said already, we could also consider reverting this patch - I'll
> have another look and ask for more testers when I'm back. I would,
> however, greatly prefer a fixup patch.
>

Let's wait a few more days so that we maybe can find a solution, but  
in case no solution is found when -rc1 is approaching, we maybe should  
revert it.

Val

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[Andy Green]

On 12/14/09 21:41, Somebody in the thread at some point said:

Hi Valentin -

> The iim clock is explicitely enabled in clock.c, just before the call to
> mx31_read_cpu_rev(), and from what I had checked, the clock effectively
> seemed enabled for me. I have no clue about the register definition
> since I have found no real documentation about it, but from my point of
> view, this would more look like 8 bit registers as Andy pointed out in
> an earlier mail.

Some Google-fu last week got me this not very well publicised doucment:

  http://www.freescale.com/files/dsp/doc/app_note/AN3682.pdf

the fuse "memory map" is specific to iMX25, but it also documents the 
structure of Freescale's IIM peripheral register mapping, gives sample 
code (which works on iMX31, so presumably it deploys the same IIM IP).

The sample code is also entirely byte operations.

I don't think the globally unique CPU ID fuses are set by Freescale, 
because when I dumped the entire fuse space of a few iMX31 devices, 
there was only a handful of bytes that differed: I assumed these were 
stuff like die placement X Y.

Unfortunately Freescale did some "security by obscurity" in their main 
reference manual and while it talks about what kinds of fields are in 
the fuses, it doesn't give their bank and row indexes.  Annoyingly that 
information is right there in the iMX25-specific thing linked above.

-Andy

[PATCH] ARM: MX3: make CPU revision number detection work on all boards

[Wolfgang Denk]

Commit 52939c03 (ARM: MX3: fix CPU revision number detection) started
using the CPU's SREV register for revision number detection. This
makes it mandatory to have a valid SPBA0 mapping. Add this to the
global map_io code instead of adding multiple copies for each board.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Daniel Mack <daniel@caiaq.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>

Tested on Qong (EVB-Lite)
Tested-by: Wolfgang Denk <wd@denx.de>
---
 arch/arm/mach-mx3/mm.c       |    5 +++++
 arch/arm/mach-mx3/mx31ads.c  |    5 -----
 arch/arm/mach-mx3/mx31lite.c |    5 -----
 arch/arm/mach-mx3/mx31pdk.c  |    5 -----
 4 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-mx3/mm.c b/arch/arm/mach-mx3/mm.c
index bedf5b8..6858a4f 100644
--- a/arch/arm/mach-mx3/mm.c
+++ b/arch/arm/mach-mx3/mm.c
@@ -65,6 +65,11 @@ static struct map_desc mxc_io_desc[] __initdata = {
 		.pfn		= __phys_to_pfn(AIPS2_BASE_ADDR),
 		.length		= AIPS2_SIZE,
 		.type		= MT_DEVICE_NONSHARED
+	}, {
+		.virtual = SPBA0_BASE_ADDR_VIRT,
+		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
+		.length = SPBA0_SIZE,
+		.type = MT_DEVICE_NONSHARED
 	},
 };
 
diff --git a/arch/arm/mach-mx3/mx31ads.c b/arch/arm/mach-mx3/mx31ads.c
index 0497c15..3e7bafa 100644
--- a/arch/arm/mach-mx3/mx31ads.c
+++ b/arch/arm/mach-mx3/mx31ads.c
@@ -494,11 +494,6 @@ static void mxc_init_i2c(void)
  */
 static struct map_desc mx31ads_io_desc[] __initdata = {
 	{
-		.virtual	= SPBA0_BASE_ADDR_VIRT,
-		.pfn		= __phys_to_pfn(SPBA0_BASE_ADDR),
-		.length		= SPBA0_SIZE,
-		.type		= MT_DEVICE_NONSHARED
-	}, {
 		.virtual	= CS4_BASE_ADDR_VIRT,
 		.pfn		= __phys_to_pfn(CS4_BASE_ADDR),
 		.length		= CS4_SIZE / 2,
diff --git a/arch/arm/mach-mx3/mx31lite.c b/arch/arm/mach-mx3/mx31lite.c
index def6b67..4697164 100644
--- a/arch/arm/mach-mx3/mx31lite.c
+++ b/arch/arm/mach-mx3/mx31lite.c
@@ -212,11 +212,6 @@ static struct platform_device physmap_flash_device = {
  */
 static struct map_desc mx31lite_io_desc[] __initdata = {
 	{
-		.virtual = SPBA0_BASE_ADDR_VIRT,
-		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
-		.length = SPBA0_SIZE,
-		.type = MT_DEVICE_NONSHARED
-	}, {
 		.virtual = CS4_BASE_ADDR_VIRT,
 		.pfn = __phys_to_pfn(CS4_BASE_ADDR),
 		.length = CS4_SIZE,
diff --git a/arch/arm/mach-mx3/mx31pdk.c b/arch/arm/mach-mx3/mx31pdk.c
index 0f7a2f0..18715f1 100644
--- a/arch/arm/mach-mx3/mx31pdk.c
+++ b/arch/arm/mach-mx3/mx31pdk.c
@@ -211,11 +211,6 @@ static int __init mx31pdk_init_expio(void)
  */
 static struct map_desc mx31pdk_io_desc[] __initdata = {
 	{
-		.virtual = SPBA0_BASE_ADDR_VIRT,
-		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
-		.length = SPBA0_SIZE,
-		.type = MT_DEVICE_NONSHARED,
-	}, {
 		.virtual = CS5_BASE_ADDR_VIRT,
 		.pfn = __phys_to_pfn(CS5_BASE_ADDR),
 		.length = CS5_SIZE,
-- 
1.6.2.5

"ARM: MX3: fix CPU revision number detection" breaks QONG support

[Wolfgang Denk]

Dear Valentin,

In message <20091214224109.20623gout4jbbdo5@webmail.epfl.ch> you wrote:
> 
> >> In Linux, the kernel hangs here:
> >>
> >> 	/* read SREV register from IIM module */
> >> 	srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);
> >>
> >> In U-Boot, I can read this register just fine:
> >>
> >> 	=> md 5001c024 1
> >> 	5001c024: 00000028    (...

0x28 translates into "i.MX31", chip rev. 2.0/2.0.1, mask M91E

> I have looked more carefully at the bootloader code, and it does not  
> seem to configure anything for SPBA0. Furthermore, Redboot actually  
> reads this register at boot time to determine the CPU revision just as  
> Daniel with its patch.

True - U-Boot does not do anything for SPBA0.

> For the IO_ADDRESS stuff, it may be the problem. This macro is  

This is my guess, too.

> supposed to do the physical address -> virtual address translation. If  
> I have understood correctly (correct if wrong, I don't really know  
> when whe have to use it or not), it is used when the memory region was  
> not allocated and then mapped with request_mem_region and ioremap  
> calls. The 0xFC11C024 is the virtual address defined by the IO_ADDRESS  
> macro succession for the SPBA0 memory region. Now how was this defined  
> and may this fail on certain systems/configuration because other  
> memory definitions ?

The 0xfc100000 offset is from MX3x_SPBA0_BASE_ADDR_VIRT in
"arch/arm/plat-mxc/include/mach/mx3x.h". And indeed this is the key
question... See below...

> The iim clock is explicitely enabled in clock.c, just before the call  
> to mx31_read_cpu_rev(), and from what I had checked, the clock  
> effectively seemed enabled for me...

I have verified that clk_get(NULL, "iim") succeeds (immediately before
attempting to read MXC_IIMSREV).

>                                ... I have no clue about the register  
> definition since I have found no real documentation about it, but from  
> my point of view, this would more look like 8 bit registers as Andy  
> pointed out in an earlier mail.

See the reference manual, pages 13-1 (=479) 
(http://www.freescale.com/files/32bit/doc/ref_manual/MCIMX31RM.pdf):

        "The IIM is accessible using an 8-bit IP bus interface. An
        8-bit interface is used because it matches the natural width
        of the fuse arrays."

See especially Table 13-2. SILICON_REV Settings on page 13-4 (=482).

> Let's wait a few more days so that we maybe can find a solution, but  
> in case no solution is found when -rc1 is approaching, we maybe should  
> revert it.

I tried changing the __raw_readl() into a __raw_readb(), but this
doesn't change anything.


Now. After realizing that the SPBA0 mapping seems to be an issue I
found that all boards add a mapping for it in their own, private
map_io code. Qong did not - because we never accessed any SPBA0 stuff
so far. Add this, and the problem goes away.

But then, now that the "CPU revision number detection" commit makes
this mapping mandatory for all boards, this should be moved from board
specific to SoC specific code. Patch following.

[Note: I still think the __raw_readl() should be changed into a
__raw_readb(), even though this has no immediately visible effect.]


Valentin, thanks again for asking the right questions :-)



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Business is like a wheelbarrow. Nothing ever happens until you  start
pushing.

[PATCH] ARM: MX3: make CPU revision number detection work on all boards

[Daniel Mack]

On Tue, Dec 15, 2009 at 12:27:42AM +0100, Wolfgang Denk wrote:
> Commit 52939c03 (ARM: MX3: fix CPU revision number detection) started
> using the CPU's SREV register for revision number detection. This
> makes it mandatory to have a valid SPBA0 mapping. Add this to the
> global map_io code instead of adding multiple copies for each board.
> 
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Daniel Mack <daniel@caiaq.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>

Ah, that explains it of course. Sorry I didn't see that.

Daniel


> Tested on Qong (EVB-Lite)
> Tested-by: Wolfgang Denk <wd@denx.de>
> ---
>  arch/arm/mach-mx3/mm.c       |    5 +++++
>  arch/arm/mach-mx3/mx31ads.c  |    5 -----
>  arch/arm/mach-mx3/mx31lite.c |    5 -----
>  arch/arm/mach-mx3/mx31pdk.c  |    5 -----
>  4 files changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/mach-mx3/mm.c b/arch/arm/mach-mx3/mm.c
> index bedf5b8..6858a4f 100644
> --- a/arch/arm/mach-mx3/mm.c
> +++ b/arch/arm/mach-mx3/mm.c
> @@ -65,6 +65,11 @@ static struct map_desc mxc_io_desc[] __initdata = {
>  		.pfn		= __phys_to_pfn(AIPS2_BASE_ADDR),
>  		.length		= AIPS2_SIZE,
>  		.type		= MT_DEVICE_NONSHARED
> +	}, {
> +		.virtual = SPBA0_BASE_ADDR_VIRT,
> +		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
> +		.length = SPBA0_SIZE,
> +		.type = MT_DEVICE_NONSHARED
>  	},
>  };
>  
> diff --git a/arch/arm/mach-mx3/mx31ads.c b/arch/arm/mach-mx3/mx31ads.c
> index 0497c15..3e7bafa 100644
> --- a/arch/arm/mach-mx3/mx31ads.c
> +++ b/arch/arm/mach-mx3/mx31ads.c
> @@ -494,11 +494,6 @@ static void mxc_init_i2c(void)
>   */
>  static struct map_desc mx31ads_io_desc[] __initdata = {
>  	{
> -		.virtual	= SPBA0_BASE_ADDR_VIRT,
> -		.pfn		= __phys_to_pfn(SPBA0_BASE_ADDR),
> -		.length		= SPBA0_SIZE,
> -		.type		= MT_DEVICE_NONSHARED
> -	}, {
>  		.virtual	= CS4_BASE_ADDR_VIRT,
>  		.pfn		= __phys_to_pfn(CS4_BASE_ADDR),
>  		.length		= CS4_SIZE / 2,
> diff --git a/arch/arm/mach-mx3/mx31lite.c b/arch/arm/mach-mx3/mx31lite.c
> index def6b67..4697164 100644
> --- a/arch/arm/mach-mx3/mx31lite.c
> +++ b/arch/arm/mach-mx3/mx31lite.c
> @@ -212,11 +212,6 @@ static struct platform_device physmap_flash_device = {
>   */
>  static struct map_desc mx31lite_io_desc[] __initdata = {
>  	{
> -		.virtual = SPBA0_BASE_ADDR_VIRT,
> -		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
> -		.length = SPBA0_SIZE,
> -		.type = MT_DEVICE_NONSHARED
> -	}, {
>  		.virtual = CS4_BASE_ADDR_VIRT,
>  		.pfn = __phys_to_pfn(CS4_BASE_ADDR),
>  		.length = CS4_SIZE,
> diff --git a/arch/arm/mach-mx3/mx31pdk.c b/arch/arm/mach-mx3/mx31pdk.c
> index 0f7a2f0..18715f1 100644
> --- a/arch/arm/mach-mx3/mx31pdk.c
> +++ b/arch/arm/mach-mx3/mx31pdk.c
> @@ -211,11 +211,6 @@ static int __init mx31pdk_init_expio(void)
>   */
>  static struct map_desc mx31pdk_io_desc[] __initdata = {
>  	{
> -		.virtual = SPBA0_BASE_ADDR_VIRT,
> -		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
> -		.length = SPBA0_SIZE,
> -		.type = MT_DEVICE_NONSHARED,
> -	}, {
>  		.virtual = CS5_BASE_ADDR_VIRT,
>  		.pfn = __phys_to_pfn(CS5_BASE_ADDR),
>  		.length = CS5_SIZE,
> -- 
> 1.6.2.5
> 

[PATCH] ARM: MX3: make CPU revision number detection work on all boards

[Sascha Hauer]

Hi Wolfgang,

On Tue, Dec 15, 2009 at 12:27:42AM +0100, Wolfgang Denk wrote:
> Commit 52939c03 (ARM: MX3: fix CPU revision number detection) started
> using the CPU's SREV register for revision number detection. This
> makes it mandatory to have a valid SPBA0 mapping. Add this to the
> global map_io code instead of adding multiple copies for each board.
> 
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Daniel Mack <daniel@caiaq.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>

ok for -rc.

Sascha

> 
> Tested on Qong (EVB-Lite)
> Tested-by: Wolfgang Denk <wd@denx.de>
> ---
>  arch/arm/mach-mx3/mm.c       |    5 +++++
>  arch/arm/mach-mx3/mx31ads.c  |    5 -----
>  arch/arm/mach-mx3/mx31lite.c |    5 -----
>  arch/arm/mach-mx3/mx31pdk.c  |    5 -----
>  4 files changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/mach-mx3/mm.c b/arch/arm/mach-mx3/mm.c
> index bedf5b8..6858a4f 100644
> --- a/arch/arm/mach-mx3/mm.c
> +++ b/arch/arm/mach-mx3/mm.c
> @@ -65,6 +65,11 @@ static struct map_desc mxc_io_desc[] __initdata = {
>  		.pfn		= __phys_to_pfn(AIPS2_BASE_ADDR),
>  		.length		= AIPS2_SIZE,
>  		.type		= MT_DEVICE_NONSHARED
> +	}, {
> +		.virtual = SPBA0_BASE_ADDR_VIRT,
> +		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
> +		.length = SPBA0_SIZE,
> +		.type = MT_DEVICE_NONSHARED
>  	},
>  };
>  
> diff --git a/arch/arm/mach-mx3/mx31ads.c b/arch/arm/mach-mx3/mx31ads.c
> index 0497c15..3e7bafa 100644
> --- a/arch/arm/mach-mx3/mx31ads.c
> +++ b/arch/arm/mach-mx3/mx31ads.c
> @@ -494,11 +494,6 @@ static void mxc_init_i2c(void)
>   */
>  static struct map_desc mx31ads_io_desc[] __initdata = {
>  	{
> -		.virtual	= SPBA0_BASE_ADDR_VIRT,
> -		.pfn		= __phys_to_pfn(SPBA0_BASE_ADDR),
> -		.length		= SPBA0_SIZE,
> -		.type		= MT_DEVICE_NONSHARED
> -	}, {
>  		.virtual	= CS4_BASE_ADDR_VIRT,
>  		.pfn		= __phys_to_pfn(CS4_BASE_ADDR),
>  		.length		= CS4_SIZE / 2,
> diff --git a/arch/arm/mach-mx3/mx31lite.c b/arch/arm/mach-mx3/mx31lite.c
> index def6b67..4697164 100644
> --- a/arch/arm/mach-mx3/mx31lite.c
> +++ b/arch/arm/mach-mx3/mx31lite.c
> @@ -212,11 +212,6 @@ static struct platform_device physmap_flash_device = {
>   */
>  static struct map_desc mx31lite_io_desc[] __initdata = {
>  	{
> -		.virtual = SPBA0_BASE_ADDR_VIRT,
> -		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
> -		.length = SPBA0_SIZE,
> -		.type = MT_DEVICE_NONSHARED
> -	}, {
>  		.virtual = CS4_BASE_ADDR_VIRT,
>  		.pfn = __phys_to_pfn(CS4_BASE_ADDR),
>  		.length = CS4_SIZE,
> diff --git a/arch/arm/mach-mx3/mx31pdk.c b/arch/arm/mach-mx3/mx31pdk.c
> index 0f7a2f0..18715f1 100644
> --- a/arch/arm/mach-mx3/mx31pdk.c
> +++ b/arch/arm/mach-mx3/mx31pdk.c
> @@ -211,11 +211,6 @@ static int __init mx31pdk_init_expio(void)
>   */
>  static struct map_desc mx31pdk_io_desc[] __initdata = {
>  	{
> -		.virtual = SPBA0_BASE_ADDR_VIRT,
> -		.pfn = __phys_to_pfn(SPBA0_BASE_ADDR),
> -		.length = SPBA0_SIZE,
> -		.type = MT_DEVICE_NONSHARED,
> -	}, {
>  		.virtual = CS5_BASE_ADDR_VIRT,
>  		.pfn = __phys_to_pfn(CS5_BASE_ADDR),
>  		.length = CS5_SIZE,
> -- 
> 1.6.2.5
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |