[PATCH 02/13] video: omap2dss: fix LPAE warnings

[PATCH 02/13] video: omap2dss: fix LPAE warnings

[Peter Griffin]

From: Arnd Bergmann <arnd@arndb.de>

If LPAE is enabled, dma_addr_t is 64 bit, so we have to
change a few type for everything in this driver to match
again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
 drivers/video/fbdev/omap2/dss/dispc.c |    6 +++---
 include/video/omapdss.h               |    4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c
index f18397c..4fe1431 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2577,9 +2577,9 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
 
 	channel = dispc_ovl_get_channel_out(plane);
 
-	DSSDBG("dispc_ovl_setup %d, pa %x, pa_uv %x, sw %d, %d,%d, %dx%d -> "
-		"%dx%d, cmode %x, rot %d, mir %d, chan %d repl %d\n",
-		plane, oi->paddr, oi->p_uv_addr, oi->screen_width, oi->pos_x,
+	DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
+		" %dx%d, cmode %x, rot %d, mir %d, chan %d repl %d\n",
+		plane, &oi->paddr, &oi->p_uv_addr, oi->screen_width, oi->pos_x,
 		oi->pos_y, oi->width, oi->height, oi->out_width, oi->out_height,
 		oi->color_mode, oi->rotation, oi->mirror, channel, replication);
 
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 6adb445..ded61a9 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -388,8 +388,8 @@ struct omap_dss_cpr_coefs {
 };
 
 struct omap_overlay_info {
-	u32 paddr;
-	u32 p_uv_addr;  /* for NV12 format */
+	dma_addr_t paddr;
+	dma_addr_t p_uv_addr;  /* for NV12 format */
 	u16 screen_width;
 	u16 width;
 	u16 height;
-- 
1.7.9.5

[PATCH 04/13] video/omap: fix modular build

[Peter Griffin]

From: Arnd Bergmann <arnd@arndb.de>

The framebuffer layer can be a loadable module, which forces
omapfb to be a module as well. However, this breaks the lcd
drivers, which are linked into the omapfb driver but each
have their own module_init() function. To solve this,
we split out the lcd drivers into separate modules and
export omapfb_register_panel, which is the only interface
required between the main omapfb driver and the lcd panel
drivers.

We also have to introduce a new Kconfig symbol for H3, since
that lcd driver has a dependency on TPS65010, which we can
express better in Kconfig than Makefile syntax.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
 drivers/video/fbdev/omap/Kconfig       |    9 +++++++++
 drivers/video/fbdev/omap/Makefile      |   23 ++++++++++++-----------
 drivers/video/fbdev/omap/omapfb_main.c |    1 +
 include/linux/omap-dma.h               |    2 +-
 4 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig
index 0bc3a93..18c4cb0 100644
--- a/drivers/video/fbdev/omap/Kconfig
+++ b/drivers/video/fbdev/omap/Kconfig
@@ -39,6 +39,15 @@ config FB_OMAP_LCD_MIPID
 	  the Mobile Industry Processor Interface DBI-C/DCS
 	  specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
 
+config FB_OMAP_LCD_H3
+	bool "TPS65010 LCD controller on OMAP-H3"
+	depends on MACH_OMAP_H3
+	depends on TPS65010
+	default y
+	help
+	  Say Y here if you want to have support for the LCD on the
+	  H3 board.
+
 config FB_OMAP_DMA_TUNE
         bool "Set DMA SDRAM access priority high"
         depends on FB_OMAP
diff --git a/drivers/video/fbdev/omap/Makefile b/drivers/video/fbdev/omap/Makefile
index 1927faf..732e071 100644
--- a/drivers/video/fbdev/omap/Makefile
+++ b/drivers/video/fbdev/omap/Makefile
@@ -10,17 +10,18 @@ objs-y$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
 
 objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
 
-objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o
-objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o
-objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o
-objs-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o
-objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
-objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
-objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
-objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
-
-objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
-objs-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o
+lcds-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o
+lcds-y$(CONFIG_FB_OMAP_LCD_H3) += lcd_h3.o
+lcds-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o
+lcds-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o
+lcds-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
+lcds-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
+lcds-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
+lcds-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
+
+lcds-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
+lcds-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o
 
 omapfb-objs := $(objs-yy)
 
+obj-$(CONFIG_FB_OMAP) += $(lcds-yy)
diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c
index e4fc6d9..d8d028d 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -1823,6 +1823,7 @@ void omapfb_register_panel(struct lcd_panel *panel)
 	if (fbdev_pdev != NULL)
 		omapfb_do_probe(fbdev_pdev, fbdev_panel);
 }
+EXPORT_SYMBOL_GPL(omapfb_register_panel);
 
 /* Called when the device is being detached from the driver */
 static int omapfb_remove(struct platform_device *pdev)
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 41a13e7..0a1a2e2 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -393,7 +393,7 @@ extern int omap_modify_dma_chain_params(int chain_id,
 extern int omap_dma_chain_status(int chain_id);
 #endif
 
-#if defined(CONFIG_ARCH_OMAP1) && defined(CONFIG_FB_OMAP)
+#if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP)
 #include <mach/lcd_dma.h>
 #else
 static inline int omap_lcd_dma_running(void)
-- 
1.7.9.5

[PATCH 13/13] video: omap: allow building on !MMU

[Peter Griffin]

From: Arnd Bergmann <arnd@arndb.de>

The omap lcdc driver has an elaborate mmap_kern function
to map the frame buffer into kernel address space as
write-combined. This uses functions that are only available
on MMU-enabled builds.

It does seem equivalent to ioremap_wc though, so we should
be able to just use that instead.

This patch is build-tested only, it needs to be run on real
hardware before applying.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
 drivers/video/fbdev/omap/lcdc.c |   28 +++++-----------------------
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/drivers/video/fbdev/omap/lcdc.c b/drivers/video/fbdev/omap/lcdc.c
index b52f625..40e8200 100644
--- a/drivers/video/fbdev/omap/lcdc.c
+++ b/drivers/video/fbdev/omap/lcdc.c
@@ -613,29 +613,11 @@ static void lcdc_dma_handler(u16 status, void *data)
 
 static int mmap_kern(void)
 {
-	struct vm_struct	*kvma;
-	struct vm_area_struct	vma;
-	pgprot_t		pgprot;
-	unsigned long		vaddr;
-
-	kvma = get_vm_area(lcdc.vram_size, VM_IOREMAP);
-	if (kvma == NULL) {
-		dev_err(lcdc.fbdev->dev, "can't get kernel vm area\n");
+	void __iomem *vaddr;
+
+	vaddr = ioremap_wc(lcdc.vram_phys, lcdc.vram_size);
+	if (!vaddr)
 		return -ENOMEM;
-	}
-	vma.vm_mm = &init_mm;
-
-	vaddr = (unsigned long)kvma->addr;
-	vma.vm_start = vaddr;
-	vma.vm_end = vaddr + lcdc.vram_size;
-
-	pgprot = pgprot_writecombine(pgprot_kernel);
-	if (io_remap_pfn_range(&vma, vaddr,
-			   lcdc.vram_phys >> PAGE_SHIFT,
-			   lcdc.vram_size, pgprot) < 0) {
-		dev_err(lcdc.fbdev->dev, "kernel mmap for FB memory failed\n");
-		return -EAGAIN;
-	}
 
 	lcdc.vram_virt = (void *)vaddr;
 
@@ -644,7 +626,7 @@ static int mmap_kern(void)
 
 static void unmap_kern(void)
 {
-	vunmap(lcdc.vram_virt);
+	iounmap(lcdc.vram_virt);
 }
 
 static int alloc_palette_ram(void)
-- 
1.7.9.5

Re: [PATCH 13/13] video: omap: allow building on !MMU

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On 24/04/14 15:28, Peter Griffin wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> The omap lcdc driver has an elaborate mmap_kern function
> to map the frame buffer into kernel address space as
> write-combined. This uses functions that are only available
> on MMU-enabled builds.
> 
> It does seem equivalent to ioremap_wc though, so we should
> be able to just use that instead.
> 
> This patch is build-tested only, it needs to be run on real
> hardware before applying.

I don't have omap1 boards, and I don't know anyone that has. I don't
even know if the omap1 fb is working or not...

Tony, any idea of omap1's fb? Are you able to test this?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 13/13] video: omap: allow building on !MMU

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]:
> On 24/04/14 15:28, Peter Griffin wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> > 
> > The omap lcdc driver has an elaborate mmap_kern function
> > to map the frame buffer into kernel address space as
> > write-combined. This uses functions that are only available
> > on MMU-enabled builds.
> > 
> > It does seem equivalent to ioremap_wc though, so we should
> > be able to just use that instead.
> > 
> > This patch is build-tested only, it needs to be run on real
> > hardware before applying.
> 
> I don't have omap1 boards, and I don't know anyone that has. I don't
> even know if the omap1 fb is working or not...
> 
> Tony, any idea of omap1's fb? Are you able to test this?

I have three omap1 boards in my rack that I use for my boot
testing. Tried to enable framebuffer but so far no luck on
any of them. So I'm not much of a help here. Looks like the
patch should work though..

Aaro & Janusz, care to take a look at the patch in this
thread?

Regards,

Tony

Re: [PATCH 13/13] video: omap: allow building on !MMU

[Aaro Koskinen]

Hi,

On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]:
> > I don't have omap1 boards, and I don't know anyone that has. I don't
> > even know if the omap1 fb is working or not...

OMAP1 fb is working very well. As a matter of fact, it's much more usable
for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
in mainline yet. :-(

> > Tony, any idea of omap1's fb? Are you able to test this?
> 
> I have three omap1 boards in my rack that I use for my boot
> testing. Tried to enable framebuffer but so far no luck on
> any of them. So I'm not much of a help here. Looks like the
> patch should work though..
> 
> Aaro & Janusz, care to take a look at the patch in this
> thread?

I couldn't figure out how to enter this code path. Amstrad E3 & Nokia
770 will take the alloc_fbmem() path & exit, and based on quick look
I could not see way to enter mmap_kern(). Is that dead code?

A.

Re: [PATCH 13/13] video: omap: allow building on !MMU

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [140508 16:09]:
> Hi,
> 
> On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]:
> > > I don't have omap1 boards, and I don't know anyone that has. I don't
> > > even know if the omap1 fb is working or not...
> 
> OMAP1 fb is working very well. As a matter of fact, it's much more usable
> for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
> with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
> in mainline yet. :-(

I hear you.. What do you have in the .config for omap1?
Would be nice to enable the framebuffer in omap1_defconfig?
 
> > > Tony, any idea of omap1's fb? Are you able to test this?
> > 
> > I have three omap1 boards in my rack that I use for my boot
> > testing. Tried to enable framebuffer but so far no luck on
> > any of them. So I'm not much of a help here. Looks like the
> > patch should work though..
> > 
> > Aaro & Janusz, care to take a look at the patch in this
> > thread?
> 
> I couldn't figure out how to enter this code path. Amstrad E3 & Nokia
> 770 will take the alloc_fbmem() path & exit, and based on quick look
> I could not see way to enter mmap_kern(). Is that dead code?

Could be. It may be something left from when we had code to keep
the bootloader logo displayed while booting kernel.

Regards,

Tony

Re: [PATCH 13/13] video: omap: allow building on !MMU

[Aaro Koskinen]

Hi,

On Thu, May 08, 2014 at 04:17:11PM -0700, Tony Lindgren wrote:
> > OMAP1 fb is working very well. As a matter of fact, it's much more usable
> > for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
> > with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
> > in mainline yet. :-(
> 
> I hear you.. What do you have in the .config for omap1?
> Would be nice to enable the framebuffer in omap1_defconfig?

Looks like the needed stuff is enabled there. Unfortunately I cannot
test the full omap1_defconfig because of size limitations.

> > > > Tony, any idea of omap1's fb? Are you able to test this?
> > > 
> > > I have three omap1 boards in my rack that I use for my boot
> > > testing. Tried to enable framebuffer but so far no luck on
> > > any of them. So I'm not much of a help here. Looks like the
> > > patch should work though..
> > > 
> > > Aaro & Janusz, care to take a look at the patch in this
> > > thread?
> > 
> > I couldn't figure out how to enter this code path. Amstrad E3 & Nokia
> > 770 will take the alloc_fbmem() path & exit, and based on quick look
> > I could not see way to enter mmap_kern(). Is that dead code?
> 
> Could be. It may be something left from when we had code to keep
> the bootloader logo displayed while booting kernel.

The support for early fbmem alloc was removed in 2011
(1e434f9318efc3dddc0c0b8d2071712668154c2b, OMAPFB: remove early mem
alloc from old omapfb), so I think we can safely delete this code.
I can prepare & test a patch for this.

A.

Re: [PATCH 13/13] video: omap: allow building on !MMU

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [140509 14:26]:
> Hi,
> 
> On Thu, May 08, 2014 at 04:17:11PM -0700, Tony Lindgren wrote:
> > > OMAP1 fb is working very well. As a matter of fact, it's much more usable
> > > for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
> > > with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
> > > in mainline yet. :-(
> > 
> > I hear you.. What do you have in the .config for omap1?
> > Would be nice to enable the framebuffer in omap1_defconfig?
> 
> Looks like the needed stuff is enabled there. Unfortunately I cannot
> test the full omap1_defconfig because of size limitations.

OK maybe it's just a question of loading the backlight modules.
 
> > > > > Tony, any idea of omap1's fb? Are you able to test this?
> > > > 
> > > > I have three omap1 boards in my rack that I use for my boot
> > > > testing. Tried to enable framebuffer but so far no luck on
> > > > any of them. So I'm not much of a help here. Looks like the
> > > > patch should work though..
> > > > 
> > > > Aaro & Janusz, care to take a look at the patch in this
> > > > thread?
> > > 
> > > I couldn't figure out how to enter this code path. Amstrad E3 & Nokia
> > > 770 will take the alloc_fbmem() path & exit, and based on quick look
> > > I could not see way to enter mmap_kern(). Is that dead code?
> > 
> > Could be. It may be something left from when we had code to keep
> > the bootloader logo displayed while booting kernel.
> 
> The support for early fbmem alloc was removed in 2011
> (1e434f9318efc3dddc0c0b8d2071712668154c2b, OMAPFB: remove early mem
> alloc from old omapfb), so I think we can safely delete this code.
> I can prepare & test a patch for this.

OK thanks that makes sense to me.

Regards,

Tony