Re: [PATCH] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating chip-select address space based on DT
Hi Tony,
On 08/23/2014 02:01 AM, Tony Lindgren wrote:
* Pekon Gupta pe...@ti.com [140723 11:20]:
Each GPMC chip-select needs to be configured for (base-address,CS-size) so
that
GPMC understands the address-space allocated to device connected externally.
These chip-select configurations (base-address, CS-size) follow some basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a power
of 2)
and is defined by the mask field. Attached memory smaller than the
programmed
CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size' boundary and
be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
Any intermediate values creates holes in the chip-select memory-map.
This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT reg property can be filtered before actually allocating the
address space.
Signed-off-by: Pekon Gupta pe...@ti.com
Looks like size typos Roger mentioned are fixed in this one, so
applying into omap-for-v3.17/fixes thanks.
I don't see the typos fixed here. I'll reply with a v2 patch.
cheers,
-roger
---
arch/arm/mach-omap2/gpmc.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8bc1338..4a4cc04 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -521,26 +521,42 @@ static int gpmc_cs_delete_mem(int cs)
* base. Returns 0 on success and appropriate negative error code
* on failure.
*/
-static int gpmc_cs_remap(int cs, u32 base)
+static int gpmc_cs_remap(int cs, u32 base, u32 size)
{
int ret;
-u32 old_base, size;
if (cs gpmc_cs_num) {
pr_err(%s: requested chip-select is disabled\n, __func__);
return -ENODEV;
}
-/*
- * Make sure we ignore any device offsets from the GPMC partition
- * allocated for the chip select and that the new base confirms
- * to the GPMC 16MB minimum granularity.
- */
-base = ~(SZ_16M - 1);
-
-gpmc_cs_get_memconf(cs, old_base, size);
-if (base == old_base)
-return 0;
+/* allocate enough address-space under GPMC chip-select to device */
+if (size SZ_256M) {
+pr_err(%s: memory device 256MB not supported\n, __func__);
+return -ENODEV;
+} else if (size SZ_128M) {
+WARN((size != SZ_256M), cs=%d: allocating 256MB\n, cs);
+size = SZ_256M;
+} else if (size SZ_64M) {
+WARN((size != SZ_128M), cs=%d: allocating 128MB\n, cs);
+size = SZ_128M;
+} else if (size SZ_32M) {
+WARN((size != SZ_64M), cs=%d: allocating 64MB\n, cs);
+size = SZ_64M;
+} else if (size SZ_16M) {
+WARN((size != SZ_32M), cs=%d: allocating 64MB\n, cs);
+size = SZ_32M;
+} else {
+WARN((size != SZ_16M), cs=%d: allocating 64MB\n, cs);
+size = SZ_16M;
+}
+
+/* base address should be aligned with address-space size */
+if (base (size - 1)) {
+pr_err(base-addr=%x should be aligned to size=%x, base, size);
+return -EINVAL;
+}
+
gpmc_cs_disable_mem(cs);
ret = gpmc_cs_delete_mem(cs);
if (ret 0)
@@ -1551,7 +1567,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
* CS to this location. Once DT migration is complete should
* just make gpmc_cs_request() map a specific address.
*/
-ret = gpmc_cs_remap(cs, res.start);
+ret = gpmc_cs_remap(cs, res.start, resource_size(res));
if (ret 0) {
dev_err(pdev-dev, cannot remap GPMC CS %d to %pa\n,
cs, res.start);
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating chip-select address space based on DT
* Roger Quadros rog...@ti.com [140825 03:39]:
Hi Tony,
On 08/23/2014 02:01 AM, Tony Lindgren wrote:
* Pekon Gupta pe...@ti.com [140723 11:20]:
Each GPMC chip-select needs to be configured for (base-address,CS-size) so
that
GPMC understands the address-space allocated to device connected
externally.
These chip-select configurations (base-address, CS-size) follow some basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a
power of 2)
and is defined by the mask field. Attached memory smaller than the
programmed
CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size' boundary
and
be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
Any intermediate values creates holes in the chip-select memory-map.
This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT reg property can be filtered before actually allocating the
address space.
Signed-off-by: Pekon Gupta pe...@ti.com
Looks like size typos Roger mentioned are fixed in this one, so
applying into omap-for-v3.17/fixes thanks.
I don't see the typos fixed here. I'll reply with a v2 patch.
Oops indeed. I'll redo the fixes branch to avoid extra churn
and apply your updated version into omap-for-v3.17/fixes-v2.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating chip-select address space based on DT
* Tony Lindgren t...@atomide.com [140825 09:45]:
* Roger Quadros rog...@ti.com [140825 03:39]:
Hi Tony,
On 08/23/2014 02:01 AM, Tony Lindgren wrote:
* Pekon Gupta pe...@ti.com [140723 11:20]:
Each GPMC chip-select needs to be configured for (base-address,CS-size)
so that
GPMC understands the address-space allocated to device connected
externally.
These chip-select configurations (base-address, CS-size) follow some
basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a
power of 2)
and is defined by the mask field. Attached memory smaller than the
programmed
CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size'
boundary and
be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
Any intermediate values creates holes in the chip-select memory-map.
This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT reg property can be filtered before actually allocating
the
address space.
Signed-off-by: Pekon Gupta pe...@ti.com
Looks like size typos Roger mentioned are fixed in this one, so
applying into omap-for-v3.17/fixes thanks.
I don't see the typos fixed here. I'll reply with a v2 patch.
Oops indeed. I'll redo the fixes branch to avoid extra churn
and apply your updated version into omap-for-v3.17/fixes-v2.
Hmm actually dropping this one, it causes warnings for smsc911x.
Will comment on your v2 patch.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating chip-select address space based on DT
* Pekon Gupta pe...@ti.com [140723 11:20]:
Each GPMC chip-select needs to be configured for (base-address,CS-size) so
that
GPMC understands the address-space allocated to device connected externally.
These chip-select configurations (base-address, CS-size) follow some basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a power
of 2)
and is defined by the mask field. Attached memory smaller than the
programmed
CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size' boundary and
be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
Any intermediate values creates holes in the chip-select memory-map.
This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT reg property can be filtered before actually allocating the
address space.
Signed-off-by: Pekon Gupta pe...@ti.com
Looks like size typos Roger mentioned are fixed in this one, so
applying into omap-for-v3.17/fixes thanks.
Tony
---
arch/arm/mach-omap2/gpmc.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8bc1338..4a4cc04 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -521,26 +521,42 @@ static int gpmc_cs_delete_mem(int cs)
* base. Returns 0 on success and appropriate negative error code
* on failure.
*/
-static int gpmc_cs_remap(int cs, u32 base)
+static int gpmc_cs_remap(int cs, u32 base, u32 size)
{
int ret;
- u32 old_base, size;
if (cs gpmc_cs_num) {
pr_err(%s: requested chip-select is disabled\n, __func__);
return -ENODEV;
}
- /*
- * Make sure we ignore any device offsets from the GPMC partition
- * allocated for the chip select and that the new base confirms
- * to the GPMC 16MB minimum granularity.
- */
- base = ~(SZ_16M - 1);
-
- gpmc_cs_get_memconf(cs, old_base, size);
- if (base == old_base)
- return 0;
+ /* allocate enough address-space under GPMC chip-select to device */
+ if (size SZ_256M) {
+ pr_err(%s: memory device 256MB not supported\n, __func__);
+ return -ENODEV;
+ } else if (size SZ_128M) {
+ WARN((size != SZ_256M), cs=%d: allocating 256MB\n, cs);
+ size = SZ_256M;
+ } else if (size SZ_64M) {
+ WARN((size != SZ_128M), cs=%d: allocating 128MB\n, cs);
+ size = SZ_128M;
+ } else if (size SZ_32M) {
+ WARN((size != SZ_64M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_64M;
+ } else if (size SZ_16M) {
+ WARN((size != SZ_32M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_32M;
+ } else {
+ WARN((size != SZ_16M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_16M;
+ }
+
+ /* base address should be aligned with address-space size */
+ if (base (size - 1)) {
+ pr_err(base-addr=%x should be aligned to size=%x, base, size);
+ return -EINVAL;
+ }
+
gpmc_cs_disable_mem(cs);
ret = gpmc_cs_delete_mem(cs);
if (ret 0)
@@ -1551,7 +1567,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
* CS to this location. Once DT migration is complete should
* just make gpmc_cs_request() map a specific address.
*/
- ret = gpmc_cs_remap(cs, res.start);
+ ret = gpmc_cs_remap(cs, res.start, resource_size(res));
if (ret 0) {
dev_err(pdev-dev, cannot remap GPMC CS %d to %pa\n,
cs, res.start);
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating chip-select address space based on DT
Hi Pekon,
On 07/23/2014 09:17 PM, Pekon Gupta wrote:
Each GPMC chip-select needs to be configured for (base-address,CS-size) so
that
GPMC understands the address-space allocated to device connected externally.
These chip-select configurations (base-address, CS-size) follow some basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a power
of 2)
and is defined by the mask field. Attached memory smaller than the
programmed
CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size' boundary and
be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
Any intermediate values creates holes in the chip-select memory-map.
This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT reg property can be filtered before actually allocating the
address space.
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8bc1338..4a4cc04 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -521,26 +521,42 @@ static int gpmc_cs_delete_mem(int cs)
* base. Returns 0 on success and appropriate negative error code
* on failure.
*/
-static int gpmc_cs_remap(int cs, u32 base)
+static int gpmc_cs_remap(int cs, u32 base, u32 size)
{
int ret;
- u32 old_base, size;
if (cs gpmc_cs_num) {
pr_err(%s: requested chip-select is disabled\n, __func__);
return -ENODEV;
}
- /*
- * Make sure we ignore any device offsets from the GPMC partition
- * allocated for the chip select and that the new base confirms
- * to the GPMC 16MB minimum granularity.
- */
- base = ~(SZ_16M - 1);
-
- gpmc_cs_get_memconf(cs, old_base, size);
- if (base == old_base)
- return 0;
+ /* allocate enough address-space under GPMC chip-select to device */
+ if (size SZ_256M) {
+ pr_err(%s: memory device 256MB not supported\n, __func__);
+ return -ENODEV;
+ } else if (size SZ_128M) {
+ WARN((size != SZ_256M), cs=%d: allocating 256MB\n, cs);
+ size = SZ_256M;
+ } else if (size SZ_64M) {
+ WARN((size != SZ_128M), cs=%d: allocating 128MB\n, cs);
+ size = SZ_128M;
+ } else if (size SZ_32M) {
+ WARN((size != SZ_64M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_64M;
+ } else if (size SZ_16M) {
+ WARN((size != SZ_32M), cs=%d: allocating 64MB\n, cs);
Print message should be allocating 32MB
+ size = SZ_32M;
+ } else {
+ WARN((size != SZ_16M), cs=%d: allocating 64MB\n, cs);
Print message should be allocating 16MB
+ size = SZ_16M;
+ }
+
+ /* base address should be aligned with address-space size */
+ if (base (size - 1)) {
+ pr_err(base-addr=%x should be aligned to size=%x, base, size);
+ return -EINVAL;
+ }
+
gpmc_cs_disable_mem(cs);
ret = gpmc_cs_delete_mem(cs);
if (ret 0)
@@ -1551,7 +1567,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
* CS to this location. Once DT migration is complete should
* just make gpmc_cs_request() map a specific address.
*/
- ret = gpmc_cs_remap(cs, res.start);
+ ret = gpmc_cs_remap(cs, res.start, resource_size(res));
if (ret 0) {
dev_err(pdev-dev, cannot remap GPMC CS %d to %pa\n,
cs, res.start);
Otherwise it is fine. I can make the changes and resend.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating chip-select address space based on DT
Hi Roger,
On Fri, Aug 1, 2014 at 4:30 PM, Roger Quadros rog...@ti.com wrote:
On 07/23/2014 09:17 PM, Pekon Gupta wrote:
+ /* allocate enough address-space under GPMC chip-select to device */
+ if (size SZ_256M) {
+ pr_err(%s: memory device 256MB not supported\n, __func__);
+ return -ENODEV;
+ } else if (size SZ_128M) {
+ WARN((size != SZ_256M), cs=%d: allocating 256MB\n, cs);
+ size = SZ_256M;
+ } else if (size SZ_64M) {
+ WARN((size != SZ_128M), cs=%d: allocating 128MB\n, cs);
+ size = SZ_128M;
+ } else if (size SZ_32M) {
+ WARN((size != SZ_64M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_64M;
+ } else if (size SZ_16M) {
+ WARN((size != SZ_32M), cs=%d: allocating 64MB\n, cs);
Print message should be allocating 32MB
yes, my bad, copy-paste errors..
[...]
Otherwise it is fine. I can make the changes and resend.
cheers,
-roger
Yes please re-send. Thanks much.
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating chip-select address space based on DT
Each GPMC chip-select needs to be configured for (base-address,CS-size) so that
GPMC understands the address-space allocated to device connected externally.
These chip-select configurations (base-address, CS-size) follow some basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a power of
2)
and is defined by the mask field. Attached memory smaller than the programmed
CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size' boundary and
be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
Any intermediate values creates holes in the chip-select memory-map.
This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT reg property can be filtered before actually allocating the
address space.
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8bc1338..4a4cc04 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -521,26 +521,42 @@ static int gpmc_cs_delete_mem(int cs)
* base. Returns 0 on success and appropriate negative error code
* on failure.
*/
-static int gpmc_cs_remap(int cs, u32 base)
+static int gpmc_cs_remap(int cs, u32 base, u32 size)
{
int ret;
- u32 old_base, size;
if (cs gpmc_cs_num) {
pr_err(%s: requested chip-select is disabled\n, __func__);
return -ENODEV;
}
- /*
-* Make sure we ignore any device offsets from the GPMC partition
-* allocated for the chip select and that the new base confirms
-* to the GPMC 16MB minimum granularity.
-*/
- base = ~(SZ_16M - 1);
-
- gpmc_cs_get_memconf(cs, old_base, size);
- if (base == old_base)
- return 0;
+ /* allocate enough address-space under GPMC chip-select to device */
+ if (size SZ_256M) {
+ pr_err(%s: memory device 256MB not supported\n, __func__);
+ return -ENODEV;
+ } else if (size SZ_128M) {
+ WARN((size != SZ_256M), cs=%d: allocating 256MB\n, cs);
+ size = SZ_256M;
+ } else if (size SZ_64M) {
+ WARN((size != SZ_128M), cs=%d: allocating 128MB\n, cs);
+ size = SZ_128M;
+ } else if (size SZ_32M) {
+ WARN((size != SZ_64M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_64M;
+ } else if (size SZ_16M) {
+ WARN((size != SZ_32M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_32M;
+ } else {
+ WARN((size != SZ_16M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_16M;
+ }
+
+ /* base address should be aligned with address-space size */
+ if (base (size - 1)) {
+ pr_err(base-addr=%x should be aligned to size=%x, base, size);
+ return -EINVAL;
+ }
+
gpmc_cs_disable_mem(cs);
ret = gpmc_cs_delete_mem(cs);
if (ret 0)
@@ -1551,7 +1567,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
* CS to this location. Once DT migration is complete should
* just make gpmc_cs_request() map a specific address.
*/
- ret = gpmc_cs_remap(cs, res.start);
+ ret = gpmc_cs_remap(cs, res.start, resource_size(res));
if (ret 0) {
dev_err(pdev-dev, cannot remap GPMC CS %d to %pa\n,
cs, res.start);
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
