more omap clean-up for ARCH_MULTIPLATFORM

Omap no longer needs this option, mach/gpio.h is
empty.

Also remove mach/irqs.h from gpio-omap.h and
include it directly from the related omap1
gpio init files.

Otherwise omap2+ build fails for MULTI_PLATFORM.

This file has only omap_init_consistent_dma_size() left that can be moved to plat-omap/dma.c.

This file has only omap_init_consistent_dma_size() left that can be moved to plat-omap/dma.c.

Signed-off-by Tony Lindgren <[email protected]>

---
  arch/arm/plat-omap/Makefile |    2 +-
  arch/arm/plat-omap/common.c |   26 --------------------------
  arch/arm/plat-omap/dma.c    |    8 ++++++++
  3 files changed, 9 insertions(+), 27 deletions(-)

delete mode 100644 arch/arm/plat-omap/common.c

arch/arm/plat-omap/dma.c +0 -0

index c288b76..00a3a53 100644
@@ -2146,6 +2146,14 @@ static struct platform_driver omap_system_dma_driver = {
  	},

This file has only omap_init_consistent_dma_size() left that can be moved to plat-omap/dma.c.

Signed-off-by Tony Lindgren <[email protected]>

---
  arch/arm/plat-omap/Makefile |    2 +-
  arch/arm/plat-omap/common.c |   26 --------------------------
  arch/arm/plat-omap/dma.c    |    8 ++++++++
  3 files changed, 9 insertions(+), 27 deletions(-)

delete mode 100644 arch/arm/plat-omap/common.c

arch/arm/plat-omap/dma.c +0 -0

index c288b76..00a3a53 100644
@@ -2146,6 +2146,14 @@ static struct platform_driver omap_system_dma_driver = {
  	},

Tony,

Quoted 11 lines · Tony Lindgren

This file has only omap_init_consistent_dma_size() left that can be moved to plat-omap/dma.c.

Signed-off-by Tony Lindgren <[email protected]>

---
  arch/arm/plat-omap/Makefile |    2 +-
  arch/arm/plat-omap/common.c |   26 --------------------------
  arch/arm/plat-omap/dma.c    |    8 ++++++++
  3 files changed, 9 insertions(+), 27 deletions(-)

delete mode 100644 arch/arm/plat-omap/common.c

[..]

Quoted 7 lines

arch/arm/plat-omap/dma.c +0 -0

index c288b76..00a3a53 100644
@@ -2146,6 +2146,14 @@ static struct platform_driver
 omap_system_dma_driver = {
      },

arch/arm/plat-omap/dma.c static struct platform_driver · line 2157

Quoted 10 lines

arch/arm/plat-omap/dma.c +8 -0

  };
 
+/* This must be called from init_early() */
+void __init omap_init_consistent_dma_size(void)
+{
+#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
+    init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE << 20);
+#endif
+}
+

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Tomi,
Can we not get rid of the above memory reservation ?

From 65c22c93928fbaaae846dd7df53343050bbcfc64 Mon Sep 17 00:00:00 2001

Quoted 39 lines · Santosh Shilimkar

Tony,

Quoted 11 lines · Tony Lindgren

This file has only omap_init_consistent_dma_size() left that can be moved to plat-omap/dma.c.

Signed-off-by Tony Lindgren <[email protected]>

---
   arch/arm/plat-omap/Makefile |    2 +-
   arch/arm/plat-omap/common.c |   26 --------------------------
   arch/arm/plat-omap/dma.c    |    8 ++++++++
   3 files changed, 9 insertions(+), 27 deletions(-)

delete mode 100644 arch/arm/plat-omap/common.c

[..]

Quoted 7 lines

arch/arm/plat-omap/dma.c +0 -0

index c288b76..00a3a53 100644
@@ -2146,6 +2146,14 @@ static struct platform_driver
 omap_system_dma_driver = {
       },

arch/arm/plat-omap/dma.c static struct platform_driver · line 2157

Quoted 10 lines

arch/arm/plat-omap/dma.c +8 -0

   };
 
+/* This must be called from init_early() */
+void __init omap_init_consistent_dma_size(void)
+{
+#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
+    init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE << 20);
+#endif
+}
+

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Quoted 2 lines

Tomi,
Can we not get rid of the above memory reservation ?

Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later.

Quoted 10 lines · Tomi Valkeinen

Quoted 8 lines · Santosh Shilimkar

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Tomi,
Can we not get rid of the above memory reservation ?

Quoted 7 lines

Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later.

Great !!
Thanks for the patches Tomi.

For both the patches, feel free add.

Acked-by Santosh Shilimkar <[email protected]>

Quoted 11 lines · Tomi Valkeinen

Quoted 10 lines · Santosh Shilimkar

Quoted 8 lines

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Tomi,
Can we not get rid of the above memory reservation ?

Quoted 6 lines

Quoted 6 lines

Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later.

Quoted 12 lines · Santosh Shilimkar

Quoted 11 lines · Tomi Valkeinen

Quoted 10 lines · Santosh Shilimkar

Quoted 8 lines

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Tomi,
Can we not get rid of the above memory reservation ?

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later.

Hmm actually, is it safe to remove for omap1, or should we still keep it around for omap1?

Quoted 19 lines · Tony Lindgren

Quoted 18 lines · Santosh Shilimkar

Quoted 17 lines · Tomi Valkeinen

Quoted 16 lines · Santosh Shilimkar

Quoted 8 lines

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Tomi,
Can we not get rid of the above memory reservation ?

Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later.

Quoted 2 lines

Hmm actually, is it safe to remove for omap1, or should we still keep it around for omap1?

Why wouldn't it be safe? Do you mean that CMA doesn't work on omap1, or...? I'm no expert on CMA, but as far as I can see with it's ARM generic stuff.

Quoted 23 lines · Tomi Valkeinen

Quoted 21 lines · Tony Lindgren

Quoted 12 lines · Santosh Shilimkar

Quoted 11 lines · Tomi Valkeinen

Quoted 10 lines · Santosh Shilimkar

Quoted 8 lines

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Tomi,
Can we not get rid of the above memory reservation ?

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later.

Hmm actually, is it safe to remove for omap1, or should we still keep it around for omap1?

Quoted 3 lines

Why wouldn't it be safe? Do you mean that CMA doesn't work on omap1, or...? I'm no expert on CMA, but as far as I can see with it's ARM generic stuff.

Just wondering after your comment "This one is only used for the old omapfb, i.e. omap1". But sounds like it should no longer be needed there either if I parse that right.

Quoted 24 lines · Tony Lindgren

Quoted 23 lines · Tomi Valkeinen

Quoted 21 lines · Tony Lindgren

Quoted 12 lines · Santosh Shilimkar

Quoted 11 lines · Tomi Valkeinen

Quoted 10 lines · Santosh Shilimkar

Quoted 8 lines

Lets not move this in DMA code since the above is really related to frame buffer. It reserves more DMA area for dma_alloc_coherent() etc than default 2 MB. Infact, we should no longer need this with CMA and memblock in place.

Tomi,
Can we not get rid of the above memory reservation ?

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Yes, I think so. This one is only used for the old omapfb, i.e. omap1, and I have no means to test it out, though. But below is a patch to remove it. I also attached the patch, as it looks like thunderbird wants to reformat the pasted patch... I'll remove the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file in my tree later.

Hmm actually, is it safe to remove for omap1, or should we still keep it around for omap1?

Quoted 7 lines

Quoted 3 lines

Why wouldn't it be safe? Do you mean that CMA doesn't work on omap1, or...? I'm no expert on CMA, but as far as I can see with it's ARM generic stuff.

Just wondering after your comment "This one is only used for the old omapfb, i.e. omap1". But sounds like it should no longer be needed there either if I parse that right.

I meant that the code that was moved in the patch "Remove plat-omap/common.c" is only compiled and ran on omap1, when the old omapfb has been enabled in the Kconfig. It's not used on omap2+.

old omapfb uses dma_alloc_*() to allocate memory, so if CMA works on omap1, I think this code in question can be removed, as done in my patch.