Patches merged to split OMAP2_IO_ADDRESS

Patches merged to split OMAP2_IO_ADDRESS

[Tony Lindgren]

Hi all,

I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into *_L3_IO_ADDRESS
and *_L4_IO_ADDRESS so we can claim more kernel address space and support
over 512MB of memory instead of 256MB.

Of course, our goal is to convert everything except the .S files to
use ioremap() instead, but that can now be done parallel and in smaller
chunks.

Please everybody, please convert your code to use ioremap(), there are
static mappings already in place so it should work out of the box.

I also had add two quick patches to keep things compiling,
Paul can you take a look at them? I could not really test them as all
the code is not there yet. Will post them as a reply to this thread.

Regards,

Tony

[PATCH] omap: Use ioremap for omap_hwmod instead of OMAP2_IO_ADDRESS

[Tony Lindgren]

>From f05ba4e3427bc0dc216f2fca32a9b1e8f0e38695 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 7 Oct 2009 17:10:18 -0700
Subject: [PATCH] omap: Use ioremap for omap_hwmod instead of OMAP2_IO_ADDRESS

Otherwise we cannot get rid of OMAP2_IO_ADDRESS.

Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d2e0f1c..8ac8798 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -496,6 +496,7 @@ static void __iomem *_find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
 	struct omap_hwmod_addr_space *mem;
 	int i;
 	int found = 0;
+	void __iomem *va_start;
 
 	if (!oh || oh->slaves_cnt == 0)
 		return NULL;
@@ -509,16 +510,20 @@ static void __iomem *_find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
 		}
 	}
 
-	/* XXX use ioremap() instead? */
-
-	if (found)
+	if (found) {
+		va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start);
+		if (!va_start) {
+			pr_err("omap_hwmod: %s: Could not ioremap\n", oh->name);
+			return NULL;
+		}
 		pr_debug("omap_hwmod: %s: MPU register target at va %p\n",
-			 oh->name, OMAP2_IO_ADDRESS(mem->pa_start));
-	else
+			 oh->name, va_start);
+	} else {
 		pr_debug("omap_hwmod: %s: no MPU register target found\n",
 			 oh->name);
+	}
 
-	return (found) ? OMAP2_IO_ADDRESS(mem->pa_start) : NULL;
+	return (found) ? va_start : NULL;
 }
 
 /**
@@ -1148,6 +1153,7 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
 	pr_debug("omap_hwmod: %s: unregistering\n", oh->name);
 
 	mutex_lock(&omap_hwmod_mutex);
+	iounmap(oh->_rt_va);
 	list_del(&oh->node);
 	mutex_unlock(&omap_hwmod_mutex);
 

[PATCH] omap: Use getnstimeofday for omap_device

[Tony Lindgren]

Don't know if this generic solution is accurate enough?

Tony


>From 4b059c50262954ae4ce466983b5cf088851eab19 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 7 Oct 2009 17:10:18 -0700
Subject: [PATCH] omap: Use getnstimeofday for omap_device

Otherwise we cannot remove OMAP2_IO_ADDRESS.

Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 2c409fc..12513f4 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -103,21 +103,6 @@
 /* Private functions */
 
 /**
- * _read_32ksynct - read the OMAP 32K sync timer
- *
- * Returns the current value of the 32KiHz synchronization counter.
- * XXX this should be generalized to simply read the system clocksource.
- * XXX this should be moved to a separate synctimer32k.c file
- */
-static u32 _read_32ksynct(void)
-{
-	if (!cpu_class_is_omap2())
-		BUG();
-
-	return __raw_readl(OMAP2_IO_ADDRESS(OMAP_32KSYNCT_BASE + 0x010));
-}
-
-/**
  * _omap_device_activate - increase device readiness
  * @od: struct omap_device *
  * @ignore_lat: increase to latency target (0) or full readiness (1)?
@@ -133,13 +118,13 @@ static u32 _read_32ksynct(void)
  */
 static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
 {
-	u32 a, b;
+	struct timespec a, b, c;
 
 	pr_debug("omap_device: %s: activating\n", od->pdev.name);
 
 	while (od->pm_lat_level > 0) {
 		struct omap_device_pm_latency *odpl;
-		int act_lat = 0;
+		unsigned long long act_lat = 0;
 
 		od->pm_lat_level--;
 
@@ -149,20 +134,22 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
 		    (od->dev_wakeup_lat <= od->_dev_wakeup_lat_limit))
 			break;
 
-		a = _read_32ksynct();
+		getnstimeofday(&a);
 
 		/* XXX check return code */
 		odpl->activate_func(od);
 
-		b = _read_32ksynct();
+		getnstimeofday(&b);
 
-		act_lat = (b - a) >> 15; /* 32KiHz cycles to microseconds */
+		c = timespec_sub(b, a);
+		act_lat = timespec_to_ns(&c) * NSEC_PER_USEC;
 
 		pr_debug("omap_device: %s: pm_lat %d: activate: elapsed time "
-			 "%d usec\n", od->pdev.name, od->pm_lat_level, act_lat);
+			 "%llu usec\n", od->pdev.name, od->pm_lat_level,
+			 act_lat);
 
 		WARN(act_lat > odpl->activate_lat, "omap_device: %s.%d: "
-		     "activate step %d took longer than expected (%d > %d)\n",
+		     "activate step %d took longer than expected (%llu > %d)\n",
 		     od->pdev.name, od->pdev.id, od->pm_lat_level,
 		     act_lat, odpl->activate_lat);
 
@@ -188,13 +175,13 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
  */
 static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
 {
-	u32 a, b;
+	struct timespec a, b, c;
 
 	pr_debug("omap_device: %s: deactivating\n", od->pdev.name);
 
 	while (od->pm_lat_level < od->pm_lats_cnt) {
 		struct omap_device_pm_latency *odpl;
-		int deact_lat = 0;
+		unsigned long long deact_lat = 0;
 
 		odpl = od->pm_lats + od->pm_lat_level;
 
@@ -203,23 +190,24 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
 		     od->_dev_wakeup_lat_limit))
 			break;
 
-		a = _read_32ksynct();
+		getnstimeofday(&a);
 
 		/* XXX check return code */
 		odpl->deactivate_func(od);
 
-		b = _read_32ksynct();
+		getnstimeofday(&b);
 
-		deact_lat = (b - a) >> 15; /* 32KiHz cycles to microseconds */
+		c = timespec_sub(b, a);
+		deact_lat = timespec_to_ns(&c) * NSEC_PER_USEC;
 
 		pr_debug("omap_device: %s: pm_lat %d: deactivate: elapsed time "
-			 "%d usec\n", od->pdev.name, od->pm_lat_level,
+			 "%llu usec\n", od->pdev.name, od->pm_lat_level,
 			 deact_lat);
 
 		WARN(deact_lat > odpl->deactivate_lat, "omap_device: %s.%d: "
-		     "deactivate step %d took longer than expected (%d > %d)\n",
-		     od->pdev.name, od->pdev.id, od->pm_lat_level,
-		     deact_lat, odpl->deactivate_lat);
+		     "deactivate step %d took longer than expected "
+		     "(%llu > %d)\n", od->pdev.name, od->pdev.id,
+		     od->pm_lat_level, deact_lat, odpl->deactivate_lat);
 
 		od->dev_wakeup_lat += odpl->activate_lat;
 

Re: [PATCH] omap: Use getnstimeofday for omap_device

[Paul Walmsley]

On Wed, 7 Oct 2009, Tony Lindgren wrote:

> Don't know if this generic solution is accurate enough?

Looks fine to me.  Thanks -

Acked-by: Paul Walmsley <paul@pwsan.com>

> 
> Tony
> 
> 
> >From 4b059c50262954ae4ce466983b5cf088851eab19 Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 7 Oct 2009 17:10:18 -0700
> Subject: [PATCH] omap: Use getnstimeofday for omap_device
> 
> Otherwise we cannot remove OMAP2_IO_ADDRESS.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> index 2c409fc..12513f4 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -103,21 +103,6 @@
>  /* Private functions */
>  
>  /**
> - * _read_32ksynct - read the OMAP 32K sync timer
> - *
> - * Returns the current value of the 32KiHz synchronization counter.
> - * XXX this should be generalized to simply read the system clocksource.
> - * XXX this should be moved to a separate synctimer32k.c file
> - */
> -static u32 _read_32ksynct(void)
> -{
> -	if (!cpu_class_is_omap2())
> -		BUG();
> -
> -	return __raw_readl(OMAP2_IO_ADDRESS(OMAP_32KSYNCT_BASE + 0x010));
> -}
> -
> -/**
>   * _omap_device_activate - increase device readiness
>   * @od: struct omap_device *
>   * @ignore_lat: increase to latency target (0) or full readiness (1)?
> @@ -133,13 +118,13 @@ static u32 _read_32ksynct(void)
>   */
>  static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
>  {
> -	u32 a, b;
> +	struct timespec a, b, c;
>  
>  	pr_debug("omap_device: %s: activating\n", od->pdev.name);
>  
>  	while (od->pm_lat_level > 0) {
>  		struct omap_device_pm_latency *odpl;
> -		int act_lat = 0;
> +		unsigned long long act_lat = 0;
>  
>  		od->pm_lat_level--;
>  
> @@ -149,20 +134,22 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
>  		    (od->dev_wakeup_lat <= od->_dev_wakeup_lat_limit))
>  			break;
>  
> -		a = _read_32ksynct();
> +		getnstimeofday(&a);
>  
>  		/* XXX check return code */
>  		odpl->activate_func(od);
>  
> -		b = _read_32ksynct();
> +		getnstimeofday(&b);
>  
> -		act_lat = (b - a) >> 15; /* 32KiHz cycles to microseconds */
> +		c = timespec_sub(b, a);
> +		act_lat = timespec_to_ns(&c) * NSEC_PER_USEC;
>  
>  		pr_debug("omap_device: %s: pm_lat %d: activate: elapsed time "
> -			 "%d usec\n", od->pdev.name, od->pm_lat_level, act_lat);
> +			 "%llu usec\n", od->pdev.name, od->pm_lat_level,
> +			 act_lat);
>  
>  		WARN(act_lat > odpl->activate_lat, "omap_device: %s.%d: "
> -		     "activate step %d took longer than expected (%d > %d)\n",
> +		     "activate step %d took longer than expected (%llu > %d)\n",
>  		     od->pdev.name, od->pdev.id, od->pm_lat_level,
>  		     act_lat, odpl->activate_lat);
>  
> @@ -188,13 +175,13 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
>   */
>  static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
>  {
> -	u32 a, b;
> +	struct timespec a, b, c;
>  
>  	pr_debug("omap_device: %s: deactivating\n", od->pdev.name);
>  
>  	while (od->pm_lat_level < od->pm_lats_cnt) {
>  		struct omap_device_pm_latency *odpl;
> -		int deact_lat = 0;
> +		unsigned long long deact_lat = 0;
>  
>  		odpl = od->pm_lats + od->pm_lat_level;
>  
> @@ -203,23 +190,24 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
>  		     od->_dev_wakeup_lat_limit))
>  			break;
>  
> -		a = _read_32ksynct();
> +		getnstimeofday(&a);
>  
>  		/* XXX check return code */
>  		odpl->deactivate_func(od);
>  
> -		b = _read_32ksynct();
> +		getnstimeofday(&b);
>  
> -		deact_lat = (b - a) >> 15; /* 32KiHz cycles to microseconds */
> +		c = timespec_sub(b, a);
> +		deact_lat = timespec_to_ns(&c) * NSEC_PER_USEC;
>  
>  		pr_debug("omap_device: %s: pm_lat %d: deactivate: elapsed time "
> -			 "%d usec\n", od->pdev.name, od->pm_lat_level,
> +			 "%llu usec\n", od->pdev.name, od->pm_lat_level,
>  			 deact_lat);
>  
>  		WARN(deact_lat > odpl->deactivate_lat, "omap_device: %s.%d: "
> -		     "deactivate step %d took longer than expected (%d > %d)\n",
> -		     od->pdev.name, od->pdev.id, od->pm_lat_level,
> -		     deact_lat, odpl->deactivate_lat);
> +		     "deactivate step %d took longer than expected "
> +		     "(%llu > %d)\n", od->pdev.name, od->pdev.id,
> +		     od->pm_lat_level, deact_lat, odpl->deactivate_lat);
>  
>  		od->dev_wakeup_lat += odpl->activate_lat;
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


- Paul

Re: [PATCH] omap: Use ioremap for omap_hwmod instead of OMAP2_IO_ADDRESS

[Paul Walmsley]

On Wed, 7 Oct 2009, Tony Lindgren wrote:

> >From f05ba4e3427bc0dc216f2fca32a9b1e8f0e38695 Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 7 Oct 2009 17:10:18 -0700
> Subject: [PATCH] omap: Use ioremap for omap_hwmod instead of OMAP2_IO_ADDRESS
> 
> Otherwise we cannot get rid of OMAP2_IO_ADDRESS.

Acked-by: Paul Walmsley <paul@pwsan.com>



> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index d2e0f1c..8ac8798 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -496,6 +496,7 @@ static void __iomem *_find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
>  	struct omap_hwmod_addr_space *mem;
>  	int i;
>  	int found = 0;
> +	void __iomem *va_start;
>  
>  	if (!oh || oh->slaves_cnt == 0)
>  		return NULL;
> @@ -509,16 +510,20 @@ static void __iomem *_find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
>  		}
>  	}
>  
> -	/* XXX use ioremap() instead? */
> -
> -	if (found)
> +	if (found) {
> +		va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start);
> +		if (!va_start) {
> +			pr_err("omap_hwmod: %s: Could not ioremap\n", oh->name);
> +			return NULL;
> +		}
>  		pr_debug("omap_hwmod: %s: MPU register target at va %p\n",
> -			 oh->name, OMAP2_IO_ADDRESS(mem->pa_start));
> -	else
> +			 oh->name, va_start);
> +	} else {
>  		pr_debug("omap_hwmod: %s: no MPU register target found\n",
>  			 oh->name);
> +	}
>  
> -	return (found) ? OMAP2_IO_ADDRESS(mem->pa_start) : NULL;
> +	return (found) ? va_start : NULL;
>  }
>  
>  /**
> @@ -1148,6 +1153,7 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
>  	pr_debug("omap_hwmod: %s: unregistering\n", oh->name);
>  
>  	mutex_lock(&omap_hwmod_mutex);
> +	iounmap(oh->_rt_va);
>  	list_del(&oh->node);
>  	mutex_unlock(&omap_hwmod_mutex);
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


- Paul

RE: Patches merged to split OMAP2_IO_ADDRESS

[Shilimkar, Santosh]

Tony,

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Thursday, October 08, 2009 5:55 AM
> To: linux-omap@vger.kernel.org
> Cc: Paul Walmsley
> Subject: Patches merged to split OMAP2_IO_ADDRESS
> 
> Hi all,
> 
> I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into
> *_L3_IO_ADDRESS
> and *_L4_IO_ADDRESS so we can claim more kernel address space and support
> over 512MB of memory instead of 256MB.
> 
> Of course, our goal is to convert everything except the .S files to
> use ioremap() instead, but that can now be done parallel and in smaller
> chunks.
> 
> Please everybody, please convert your code to use ioremap(), there are
> static mappings already in place so it should work out of the box.
> 
> I also had add two quick patches to keep things compiling,
> Paul can you take a look at them? I could not really test them as all
> the code is not there yet. Will post them as a reply to this thread.
Thanks for the merge!!

I have boot tested below platforms with latest LO master.
 
1. OMAP3430 SDP board - BOOT OK
2. OMAP3 BEAGLE 	- BOOT OK
3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/

Regards,
Santosh

Re: Patches merged to split OMAP2_IO_ADDRESS

[Tony Lindgren]

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [091008 03:59]:
> Tony,
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Thursday, October 08, 2009 5:55 AM
> > To: linux-omap@vger.kernel.org
> > Cc: Paul Walmsley
> > Subject: Patches merged to split OMAP2_IO_ADDRESS
> > 
> > Hi all,
> > 
> > I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into
> > *_L3_IO_ADDRESS
> > and *_L4_IO_ADDRESS so we can claim more kernel address space and support
> > over 512MB of memory instead of 256MB.
> > 
> > Of course, our goal is to convert everything except the .S files to
> > use ioremap() instead, but that can now be done parallel and in smaller
> > chunks.
> > 
> > Please everybody, please convert your code to use ioremap(), there are
> > static mappings already in place so it should work out of the box.
> > 
> > I also had add two quick patches to keep things compiling,
> > Paul can you take a look at them? I could not really test them as all
> > the code is not there yet. Will post them as a reply to this thread.
> Thanks for the merge!!
> 
> I have boot tested below platforms with latest LO master.
>  
> 1. OMAP3430 SDP board - BOOT OK
> 2. OMAP3 BEAGLE 	- BOOT OK
> 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/

Great. I guess we still have some issues on 24xx with the hwmod,
but hopefully we'll get that working again soon.

Can somebody with 512MB memory on a board try the current l-o master
and make sure things work?

Please check the dmesg for no overlaps in virtual address space,
then run some memory test like memtester.

Regards,

Tony

Re: Patches merged to split OMAP2_IO_ADDRESS

[Nishanth Menon]

Tony Lindgren had written, on 10/08/2009 01:08 PM, the following:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [091008 03:59]:
>> Tony,
>>
>>> -----Original Message-----
>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>>> owner@vger.kernel.org] On Behalf Of Tony Lindgren
>>> Sent: Thursday, October 08, 2009 5:55 AM
>>> To: linux-omap@vger.kernel.org
>>> Cc: Paul Walmsley
>>> Subject: Patches merged to split OMAP2_IO_ADDRESS
>>>
>>> Hi all,
>>>
>>> I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into
>>> *_L3_IO_ADDRESS
>>> and *_L4_IO_ADDRESS so we can claim more kernel address space and support
>>> over 512MB of memory instead of 256MB.
>>>
>>> Of course, our goal is to convert everything except the .S files to
>>> use ioremap() instead, but that can now be done parallel and in smaller
>>> chunks.
>>>
>>> Please everybody, please convert your code to use ioremap(), there are
>>> static mappings already in place so it should work out of the box.
>>>
>>> I also had add two quick patches to keep things compiling,
>>> Paul can you take a look at them? I could not really test them as all
>>> the code is not there yet. Will post them as a reply to this thread.
>> Thanks for the merge!!
>>
>> I have boot tested below platforms with latest LO master.
>>  
>> 1. OMAP3430 SDP board - BOOT OK
>> 2. OMAP3 BEAGLE 	- BOOT OK
>> 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/
> 
> Great. I guess we still have some issues on 24xx with the hwmod,
> but hopefully we'll get that working again soon.
> 
> Can somebody with 512MB memory on a board try the current l-o master
> and make sure things work?
http://pastebin.mozilla.org/675489
3630 board with SDPdefconfig +8250 hack (with 3430 OPP values + wrong 
GPIOs) -> boots up mostly fine..
Regards,
Nishanth Menon

RE: Patches merged to split OMAP2_IO_ADDRESS

[Shilimkar, Santosh]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Thursday, October 08, 2009 11:38 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; Paul Walmsley
> Subject: Re: Patches merged to split OMAP2_IO_ADDRESS
> 
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [091008 03:59]:
> > Tony,
> >
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > > Sent: Thursday, October 08, 2009 5:55 AM
> > > To: linux-omap@vger.kernel.org
> > > Cc: Paul Walmsley
> > > Subject: Patches merged to split OMAP2_IO_ADDRESS
> > >
> > > Hi all,
> > >
> > > I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into
> > > *_L3_IO_ADDRESS
> > > and *_L4_IO_ADDRESS so we can claim more kernel address space and
> support
> > > over 512MB of memory instead of 256MB.
> > >
> > > Of course, our goal is to convert everything except the .S files to
> > > use ioremap() instead, but that can now be done parallel and in
> smaller
> > > chunks.
> > >
> > > Please everybody, please convert your code to use ioremap(), there are
> > > static mappings already in place so it should work out of the box.
> > >
> > > I also had add two quick patches to keep things compiling,
> > > Paul can you take a look at them? I could not really test them as all
> > > the code is not there yet. Will post them as a reply to this thread.
> > Thanks for the merge!!
> >
> > I have boot tested below platforms with latest LO master.
> >
> > 1. OMAP3430 SDP board - BOOT OK
> > 2. OMAP3 BEAGLE 	- BOOT OK
> > 3. OMAP 4430 SDP - BOOT OK with variation of patch:
> http://patchwork.kernel.org/patch/50531/
> 
> Great. I guess we still have some issues on 24xx with the hwmod,
> but hopefully we'll get that working again soon.
> 
> Can somebody with 512MB memory on a board try the current l-o master
> and make sure things work?
> 
> Please check the dmesg for no overlaps in virtual address space,
> then run some memory test like memtester.

Boot tested on OMAP4430 with 512MB and dmesg don't show any overlaps. Will run some memory test tomorrow.

Regrads
Santosh

RE: Patches merged to split OMAP2_IO_ADDRESS

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Friday, October 09, 2009 10:51 AM
> To: Tony Lindgren
> Cc: linux-omap@vger.kernel.org; Paul Walmsley
> Subject: RE: Patches merged to split OMAP2_IO_ADDRESS
> 
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Thursday, October 08, 2009 11:38 PM
> > To: Shilimkar, Santosh
> > Cc: linux-omap@vger.kernel.org; Paul Walmsley
> > Subject: Re: Patches merged to split OMAP2_IO_ADDRESS
> >
> > * Shilimkar, Santosh <santosh.shilimkar@ti.com> [091008 03:59]:
> > > Tony,
> > >
> > > > -----Original Message-----
> > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > > owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > > > Sent: Thursday, October 08, 2009 5:55 AM
> > > > To: linux-omap@vger.kernel.org
> > > > Cc: Paul Walmsley
> > > > Subject: Patches merged to split OMAP2_IO_ADDRESS
> > > >
> > > > Hi all,
> > > >
> > > > I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into
> > > > *_L3_IO_ADDRESS
> > > > and *_L4_IO_ADDRESS so we can claim more kernel address space and
> > support
> > > > over 512MB of memory instead of 256MB.
> > > >
> > > > Of course, our goal is to convert everything except the .S files to
> > > > use ioremap() instead, but that can now be done parallel and in
> > smaller
> > > > chunks.
> > > >
> > > > Please everybody, please convert your code to use ioremap(), there
> are
> > > > static mappings already in place so it should work out of the box.
> > > >
> > > > I also had add two quick patches to keep things compiling,
> > > > Paul can you take a look at them? I could not really test them as
> all
> > > > the code is not there yet. Will post them as a reply to this thread.
> > > Thanks for the merge!!
> > >
> > > I have boot tested below platforms with latest LO master.
> > >
> > > 1. OMAP3430 SDP board - BOOT OK
> > > 2. OMAP3 BEAGLE 	- BOOT OK
> > > 3. OMAP 4430 SDP - BOOT OK with variation of patch:
> > http://patchwork.kernel.org/patch/50531/
> >
> > Great. I guess we still have some issues on 24xx with the hwmod,
> > but hopefully we'll get that working again soon.
> >
> > Can somebody with 512MB memory on a board try the current l-o master
> > and make sure things work?
> >
> > Please check the dmesg for no overlaps in virtual address space,
> > then run some memory test like memtester.
> 
> Boot tested on OMAP4430 with 512MB and dmesg don't show any overlaps. Will
> run some memory test tomorrow.
> 
Run the memmark benchmark on OMAP4430 and not seen any issue.

Regards,
Santosh