Re: [PATCH] staging: tidspbridge - configure full L1 MMU range
On Wed, Jan 5, 2011 at 8:20 AM, Fernando Guzman Lugo fernando.l...@ti.com wrote: Otherwise a virtual address beyond of the L1 size is used, the MMU hardware will look into a memory that does not belong to L1 translation tables. IOW; the MMU would allow to access any memory, configured or not. Reported-by: Felipe Contreras felipe.contre...@nokia.com Signed-off-by: Fernando Guzman Lugo fernando.l...@ti.com Signed-off-by: Felipe Contreras felipe.contre...@nokia.com People rarely use ' - ' in the commit summary: % git log --oneline -1000 | grep -e ' - ' | wc -l 32 Which means about only 3%. If you do the same on drivers/staging/tidspbridge, you'll see that the only commits that have that are from you. staging: tidspbridge: configure full L1 MMU range Other than that, I think this is is a critical bugfix, and should be applied ASAP. Cheers. -- Felipe Contreras -- 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] staging: tidspbridge - configure full L1 MMU range
Hi,
On Wed, Jan 5, 2011 at 12:20 AM, Fernando Guzman Lugo
fernando.l...@ti.com wrote:
Otherwise a virtual address beyond of the L1 size is used,
the MMU hardware will look into a memory that does not belong to
L1 translation tables. IOW; the MMU would allow to access any
memory, configured or not.
How about:
IVA MMU can manage up to 4GB of address space through its page tables,
given that it's L1 is divided into 1MB sections it requires at least
16KB for its table which represents 4096 entries of 32 bits each.
Previously, only 1GB was being handled by setting the page table size
to 4KB, any virtual address beyond of the L1 size used, would fall
into memory that does not belong to L1 translation tables, leading to
unpredictable results.
So, set the L1 table size to cover the entire MMU range (4GB) whether
is meant to be used or not.
Reported-by: Felipe Contreras felipe.contre...@nokia.com
Signed-off-by: Fernando Guzman Lugo fernando.l...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 1be081f..ec96d1e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -70,6 +70,7 @@
#define MMU_LARGE_PAGE_MASK 0x
#define MMU_SMALL_PAGE_MASK 0xF000
#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
+#define MMU_L1_SIZE 0x4000
#define PAGES_II_LVL_TABLE 512
#define PHYS_TO_PAGE(phys) pfn_to_page((phys) PAGE_SHIFT)
@@ -786,10 +787,7 @@ static int bridge_dev_create(struct bridge_dev_context
pt_attrs = kzalloc(sizeof(struct pg_table_attrs), GFP_KERNEL);
if (pt_attrs != NULL) {
- /* Assuming that we use only DSP's memory map
- * until 0x4000: , we would need only 1024
- * L1 enties i.e L1 size = 4K */
- pt_attrs-l1_size = 0x1000;
+ pt_attrs-l1_size = MMU_L1_SIZE;
How about using SZ_16K instead, struct member name already specifies
it is L1 size, is the new define needed?
Regards,
Omar
--
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] staging: tidspbridge - configure full L1 MMU range
On Wed, Jan 5, 2011 at 12:46 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
Hi,
On Wed, Jan 5, 2011 at 12:20 AM, Fernando Guzman Lugo
fernando.l...@ti.com wrote:
Otherwise a virtual address beyond of the L1 size is used,
the MMU hardware will look into a memory that does not belong to
L1 translation tables. IOW; the MMU would allow to access any
memory, configured or not.
How about:
IVA MMU can manage up to 4GB of address space through its page tables,
given that it's L1 is divided into 1MB sections it requires at least
16KB for its table which represents 4096 entries of 32 bits each.
Previously, only 1GB was being handled by setting the page table size
to 4KB, any virtual address beyond of the L1 size used, would fall
into memory that does not belong to L1 translation tables, leading to
unpredictable results.
So, set the L1 table size to cover the entire MMU range (4GB) whether
is meant to be used or not.
looks good to me.
Reported-by: Felipe Contreras felipe.contre...@nokia.com
Signed-off-by: Fernando Guzman Lugo fernando.l...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 1be081f..ec96d1e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -70,6 +70,7 @@
#define MMU_LARGE_PAGE_MASK 0x
#define MMU_SMALL_PAGE_MASK 0xF000
#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
+#define MMU_L1_SIZE 0x4000
#define PAGES_II_LVL_TABLE 512
#define PHYS_TO_PAGE(phys) pfn_to_page((phys) PAGE_SHIFT)
@@ -786,10 +787,7 @@ static int bridge_dev_create(struct bridge_dev_context
pt_attrs = kzalloc(sizeof(struct pg_table_attrs), GFP_KERNEL);
if (pt_attrs != NULL) {
- /* Assuming that we use only DSP's memory map
- * until 0x4000: , we would need only 1024
- * L1 enties i.e L1 size = 4K */
- pt_attrs-l1_size = 0x1000;
+ pt_attrs-l1_size = MMU_L1_SIZE;
How about using SZ_16K instead, struct member name already specifies
it is L1 size, is the new define needed?
Ok, maybe a comment to state why 16K is used should be good.
I will make the changes.
Regards,
Fernando.
Regards,
Omar
--
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] staging: tidspbridge - configure full L1 MMU range
Otherwise a virtual address beyond of the L1 size is used,
the MMU hardware will look into a memory that does not belong to
L1 translation tables. IOW; the MMU would allow to access any
memory, configured or not.
Reported-by: Felipe Contreras felipe.contre...@nokia.com
Signed-off-by: Fernando Guzman Lugo fernando.l...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
drivers/staging/tidspbridge/core/tiomap3430.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 1be081f..ec96d1e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -70,6 +70,7 @@
#define MMU_LARGE_PAGE_MASK 0x
#define MMU_SMALL_PAGE_MASK 0xF000
#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
+#define MMU_L1_SIZE 0x4000
#define PAGES_II_LVL_TABLE 512
#define PHYS_TO_PAGE(phys) pfn_to_page((phys) PAGE_SHIFT)
@@ -786,10 +787,7 @@ static int bridge_dev_create(struct bridge_dev_context
pt_attrs = kzalloc(sizeof(struct pg_table_attrs), GFP_KERNEL);
if (pt_attrs != NULL) {
- /* Assuming that we use only DSP's memory map
-* until 0x4000: , we would need only 1024
-* L1 enties i.e L1 size = 4K */
- pt_attrs-l1_size = 0x1000;
+ pt_attrs-l1_size = MMU_L1_SIZE;
align_size = pt_attrs-l1_size;
/* Align sizes are expected to be power of 2 */
/* we like to get aligned on L1 table size */
--
1.7.1
--
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
