i.MX51 Framebuffer support

The IPU is the Image Processing Unit found on i.MX50/51/53 SoCs. It features several units for image processing, this patch adds support for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different approach. The Freescale code implements logical idmac channels and the handling of the subunits is hidden in common idmac code pathes in big switch/case statements. This patch instead just provides code and resource management for the different subunits. The user, in this case the framebuffer driver, decides how the different units play together.

The IPU has other units missing in this patch:

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

So expect more files to come in this directory.

Signed-off-by Sascha Hauer <[email protected]>

Quoted 26 lines · Sascha Hauer

The IPU is the Image Processing Unit found on i.MX50/51/53 SoCs. It features several units for image processing, this patch adds support for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different approach. The Freescale code implements logical idmac channels and the handling of the subunits is hidden in common idmac code pathes in big switch/case statements. This patch instead just provides code and resource management for the different subunits. The user, in this case the framebuffer driver, decides how the different units play together.

The IPU has other units missing in this patch:

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

Quoted 3 lines

So expect more files to come in this directory.

Signed-off-by Sascha Hauer <[email protected]>

Hello Samuel,

I see no further comments on this series. Does this mean you are ok with the patch or didn't you find the time looking at it?

This patch can go via the mfd tree or I can push this via my i.MX tree. Going via the i.MX tree makes life a bit easier for me because we do not run into merge order dependencies. Please let me know what you prefer.

Hi Sascha,

Quoted 29 lines · Sascha Hauer

Quoted 28 lines · Sascha Hauer

The IPU is the Image Processing Unit found on i.MX50/51/53 SoCs. It features several units for image processing, this patch adds support for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different approach. The Freescale code implements logical idmac channels and the handling of the subunits is hidden in common idmac code pathes in big switch/case statements. This patch instead just provides code and resource management for the different subunits. The user, in this case the framebuffer driver, decides how the different units play together.

The IPU has other units missing in this patch:

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

So expect more files to come in this directory.

Quoted 6 lines

Quoted 1 line

Signed-off-by Sascha Hauer <[email protected]>

Hello Samuel,

I see no further comments on this series. Does this mean you are ok with the patch or didn't you find the time looking at it?

I'm coming back from my xmas holidays today, and haven't had time to look at it yet. Hopefully next week.

The IPU is the Image Processing Unit found on i.MX50/51/53 SoCs. It features several units for image processing, this patch adds support for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different approach. The Freescale code implements logical idmac channels and the handling of the subunits is hidden in common idmac code pathes in big switch/case statements. This patch instead just provides code and resource management for the different subunits. The user, in this case the framebuffer driver, decides how the different units play together.

The IPU has other units missing in this patch:

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

So expect more files to come in this directory.

Hi Sascha,

Quoted 20 lines · Sascha Hauer

The IPU is the Image Processing Unit found on i.MX50/51/53 SoCs. It features several units for image processing, this patch adds support for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different approach. The Freescale code implements logical idmac channels and the handling of the subunits is hidden in common idmac code pathes in big switch/case statements. This patch instead just provides code and resource management for the different subunits. The user, in this case the framebuffer driver, decides how the different units play together.

The IPU has other units missing in this patch:

Quoted 7 lines

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

So expect more files to come in this directory.

I couldn't look into details as the patch is huge, but it looks mostly good. One thing I don't really like is the

drivers/mfd/imx-ipu-v3/ipu-common.c new file +3 -0

+static struct device *ipu_dev;
+void __iomem *ipu_cm_reg;
+void __iomem *ipu_idmac_reg;

part. I know there is currently no HW supporting more than one of those controllers, but as a general principle I find this is not a good programming habit.

Now, on a less technical note: I don't really see how this driver fits in the MFD category, unless the upcoming units support brings something new. If I were looking for the i.MX5x image processing unit, I would be looking under drivers/video/.

Quoted 37 lines · Samuel Ortiz

Hi Sascha,

Quoted 20 lines · Sascha Hauer

The IPU is the Image Processing Unit found on i.MX50/51/53 SoCs. It features several units for image processing, this patch adds support for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different approach. The Freescale code implements logical idmac channels and the handling of the subunits is hidden in common idmac code pathes in big switch/case statements. This patch instead just provides code and resource management for the different subunits. The user, in this case the framebuffer driver, decides how the different units play together.

The IPU has other units missing in this patch:

Quoted 7 lines

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

So expect more files to come in this directory.

I couldn't look into details as the patch is huge, but it looks mostly good. One thing I don't really like is the

drivers/mfd/imx-ipu-v3/ipu-common.c new file +3 -0

+static struct device *ipu_dev;
+void __iomem *ipu_cm_reg;
+void __iomem *ipu_idmac_reg;

Quoted 3 lines

part. I know there is currently no HW supporting more than one of those controllers, but as a general principle I find this is not a good programming habit.

Ok, will look into it.

Quoted 1 line

Quoted 4 lines

Now, on a less technical note: I don't really see how this driver fits in the MFD category, unless the upcoming units support brings something new. If I were looking for the i.MX5x image processing unit, I would be looking under drivers/video/.

The ipu unit also supports cameras which would go to drivers/media/video. This is the original reason for putting it into drivers/mfd.

That said,
I'm not very comfortable with putting it there, mostly because it contains a lot of code to which a mfd maintainer can hardly say anything to

and because it's one framework more which has to synchronized when changes to the IPU come.

Ok, so would moving it do drivers/video/ make sense ?

Quoted 1 line · Samuel Ortiz

Ok, so would moving it do drivers/video/ make sense ?

Isn't that for framebuffer drivers?

Hi,

Quoted 4 lines · Russell King - ARM Linux

Quoted 1 line · Samuel Ortiz

Ok, so would moving it do drivers/video/ make sense ?

Isn't that for framebuffer drivers?

For now, the ipu driver is used for framebuffer on imx5.

Quoted 7 lines · Arnaud Patard

Hi,

Quoted 3 lines · Russell King - ARM Linux

Quoted 1 line · Samuel Ortiz

Ok, so would moving it do drivers/video/ make sense ?

Quoted 3 lines

Quoted 1 line

Isn't that for framebuffer drivers?

For now, the ipu driver is used for framebuffer on imx5.

But it will hopefully be used for camera aswell.

How about arch/arm/plat-mxc?

Quoted 1 line · Samuel Ortiz

Ok, so would moving it do drivers/video/ make sense ?

Isn't that for framebuffer drivers?

Signed-off-by Sascha Hauer <[email protected]>

---
?arch/arm/mach-mx5/Kconfig ? ? ? ? ? ? ?| ? ?1 + ?arch/arm/mach-mx5/board-mx51_babbage.c | ? 74 ++++++++++++++++++++++++++++++++ ?2 files changed, 75 insertions(+), 0 deletions(-)

arch/arm/mach-mx5/Kconfig +0 -0

index 5011f42..2a936b7 100644
@@ -22,6 +22,7 @@ config MACH_MX51_BABBAGE

? ? ? ?select IMX_HAVE_PLATFORM_IMX_UART
? ? ? ?select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
? ? ? ?select IMX_HAVE_PLATFORM_SPI_IMX
+ ? ? ? select IMX_HAVE_PLATFORM_IMX_IPUV3
? ? ? ?help
? ? ? ? ?Include support for MX51 Babbage platform, also known as MX51EVK in ? ? ? ? ?u-boot. This includes specific configurations for the board and its

arch/arm/mach-mx5/board-mx51_babbage.c +0 -0

index 368a315..6c1576c 100644
@@ -22,11 +22,13 @@

?#include <linux/input.h>
?#include <linux/spi/flash.h>
?#include <linux/spi/spi.h>
+#include <linux/mfd/imx-ipu-v3.h>

?#include <mach/common.h>
?#include <mach/hardware.h>
?#include <mach/iomux-mx51.h>
?#include <mach/mxc_ehci.h>
+#include <mach/ipu-v3.h>

?#include <asm/irq.h>
?#include <asm/setup.h>

arch/arm/mach-mx5/board-mx51_babbage.c +35 -0

@@ -158,6 +160,41 @@ static iomux_v3_cfg_t mx51babbage_pads[] = {
 ? ? ? ?MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
 ? ? ? ?MX51_PAD_CSPI1_SS0__GPIO_4_24,
 ? ? ? ?MX51_PAD_CSPI1_SS1__GPIO_4_25,
+
+ ? ? ? /* Display */
+ ? ? ? MX51_PAD_DISPB2_SER_DIN__GPIO_3_5,
+ ? ? ? MX51_PAD_DISPB2_SER_DIO__GPIO_3_6,
+ ? ? ? MX51_PAD_NANDF_D12__GPIO_3_28,
+
+ ? ? ? MX51_PAD_DISP1_DAT0__DISP1_DAT0,
+ ? ? ? MX51_PAD_DISP1_DAT1__DISP1_DAT1,
+ ? ? ? MX51_PAD_DISP1_DAT2__DISP1_DAT2,
+ ? ? ? MX51_PAD_DISP1_DAT3__DISP1_DAT3,
+ ? ? ? MX51_PAD_DISP1_DAT4__DISP1_DAT4,
+ ? ? ? MX51_PAD_DISP1_DAT5__DISP1_DAT5,
+ ? ? ? MX51_PAD_DISP1_DAT6__DISP1_DAT6,
+ ? ? ? MX51_PAD_DISP1_DAT7__DISP1_DAT7,
+ ? ? ? MX51_PAD_DISP1_DAT8__DISP1_DAT8,
+ ? ? ? MX51_PAD_DISP1_DAT9__DISP1_DAT9,
+ ? ? ? MX51_PAD_DISP1_DAT10__DISP1_DAT10,
+ ? ? ? MX51_PAD_DISP1_DAT11__DISP1_DAT11,
+ ? ? ? MX51_PAD_DISP1_DAT12__DISP1_DAT12,
+ ? ? ? MX51_PAD_DISP1_DAT13__DISP1_DAT13,
+ ? ? ? MX51_PAD_DISP1_DAT14__DISP1_DAT14,
+ ? ? ? MX51_PAD_DISP1_DAT15__DISP1_DAT15,
+ ? ? ? MX51_PAD_DISP1_DAT16__DISP1_DAT16,
+ ? ? ? MX51_PAD_DISP1_DAT17__DISP1_DAT17,
+ ? ? ? MX51_PAD_DISP1_DAT18__DISP1_DAT18,
+ ? ? ? MX51_PAD_DISP1_DAT19__DISP1_DAT19,
+ ? ? ? MX51_PAD_DISP1_DAT20__DISP1_DAT20,
+ ? ? ? MX51_PAD_DISP1_DAT21__DISP1_DAT21,
+ ? ? ? MX51_PAD_DISP1_DAT22__DISP1_DAT22,
+ ? ? ? MX51_PAD_DISP1_DAT23__DISP1_DAT23,
+#define MX51_PAD_DI_GP4__IPU_DI2_PIN15 ? ? ? ? ? ? ? ? IOMUX_PAD(0x758, 0x350, 4, 0x0, ? 0, NO_PAD_CTRL)
+ ? ? ? MX51_PAD_DI_GP4__IPU_DI2_PIN15,
+
+ ? ? ? /* I2C DVI enable */
+ ? ? ? MX51_PAD_CSI2_HSYNC__GPIO_4_14,
 ?};
 

?/* Serial ports */

arch/arm/mach-mx5/board-mx51_babbage.c +17 -0

@@ -346,6 +383,23 @@ static const struct spi_imx_master mx51_babbage_spi_pdata __initconst = {
 ? ? ? ?.num_chipselect = ARRAY_SIZE(mx51_babbage_spi_cs),
 ?};
 
+static struct ipuv3_fb_platform_data babbage_fb0_data = {
+ ? ? ? .interface_pix_fmt = IPU_PIX_FMT_RGB24,
+ ? ? ? .flags = IMX_IPU_FB_USE_MODEDB | IMX_IPU_FB_USE_OVERLAY,
+ ? ? ? .display = 0,
+};
+
+static struct ipuv3_fb_platform_data babbage_fb1_data = {
+ ? ? ? .interface_pix_fmt = IPU_PIX_FMT_RGB565,
+ ? ? ? .flags = IMX_IPU_FB_USE_MODEDB,
+ ? ? ? .display = 1,
+};
+
+static struct imx_ipuv3_platform_data ipu_data = {
+ ? ? ? .fb_head0_platform_data = &babbage_fb0_data,
+ ? ? ? .fb_head1_platform_data = &babbage_fb1_data,
+};
+

?/*
?* Board specific initialization.
?*/

arch/arm/mach-mx5/board-mx51_babbage.c +4 -0

+
+ ? ? ? /* DVI Detect */
+ ? ? ? gpio_request(GPIO_DVI_DETECT, "dvi detect");
+ ? ? ? gpio_direction_input(GPIO_DVI_DETECT);

arch/arm/mach-mx5/board-mx51_babbage.c +1 -1

+ ? ? ? imx51_add_ipuv3(&ipu_data);
 ?}
 
 ?static void __init mx51_babbage_timer_init(void)
--

1.7.2.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html Please read the FAQ at ?http://www.tux.org/lkml/

The following series adds i.MX51 framebuffer support based on the IPUv3. It is not perfect but I decided it is good enough to open it for a wider audience and collect first reviews. I tested this on a babbage board using both outputs (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths. I also tested it on one custom board using a fixed display setting.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Arnaud" == Arnaud Patard (Rtp) <[email protected]> writes:

Quoted 6 lines

The following series adds i.MX51 framebuffer support based on the IPUv3. It is not perfect but I decided it is good enough to open it for a wider audience and collect first reviews. I tested this on a babbage board using both outputs (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths. I also tested it on one custom board using a fixed display setting.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Arnaud" == Arnaud Patard (Rtp) <[email protected]> writes:

Arnaud> Sascha Hauer <[email protected]> writes:
Arnaud> Hi,

Quoted 6 lines

Quoted 6 lines

The following series adds i.MX51 framebuffer support based on the IPUv3. It is not perfect but I decided it is good enough to open it for a wider audience and collect first reviews. I tested this on a babbage board using both outputs (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths. I also tested it on one custom board using a fixed display setting.

Arnaud> After adding code to my efika sb machine file and your patchset, I've Arnaud> seen the light. Err, no. It was a penguin and a login prompt. I guess Arnaud> it means your patchset is working here.

Cool. Care to submit that machine file support?

The following series adds i.MX51 framebuffer support based on the IPUv3. It is not perfect but I decided it is good enough to open it for a wider audience and collect first reviews. I tested this on a babbage board using both outputs (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths. I also tested it on one custom board using a fixed display setting.

Hello,

Sascha Hauer a ?crit :

Quoted 6 lines

The following series adds i.MX51 framebuffer support based on the IPUv3. It is not perfect but I decided it is good enough to open it for a wider audience and collect first reviews. I tested this on a babbage board using both outputs (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths. I also tested it on one custom board using a fixed display setting.

This driver is also working fine for me on a custom i.MX51 board with a 800x480 18 bits TFT LCD (16bpp mode).

The only strange thing I noticed was a kind of uggly sprite/artefact (32x32, I would say) appearing at the same time as the Linux console. I think it may be related to a hardware cursor badly (?) initialised, but I didn't find a fix yet.
It disappears when I launch a graphical application (Qt or SDL).

Quoted 7 lines

The only strange thing I noticed was a kind of uggly sprite/artefact (32x32, I would say) appearing at the same time as the Linux console. I think it may be related to a hardware cursor badly (?) initialised, but I didn't find a fix yet.
It disappears when I launch a graphical application (Qt or SDL).

In the top left corner? That'll be the linux penguin logo, and if it's not coming out correctly, your framebuffer driver is badly broken. Maybe your RGB bitfield information or visual is wrong?

Hello,

Sascha Hauer a ?crit :

Quoted 6 lines

The following series adds i.MX51 framebuffer support based on the IPUv3. It is not perfect but I decided it is good enough to open it for a wider audience and collect first reviews. I tested this on a babbage board using both outputs (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths. I also tested it on one custom board using a fixed display setting.

This driver is also working fine for me on a custom i.MX51 board with a 800x480 18 bits TFT LCD (16bpp mode).

The only strange thing I noticed was a kind of uggly sprite/artefact (32x32, I would say) appearing at the same time as the Linux console. I think it may be related to a hardware cursor badly (?) initialised, but I didn't find a fix yet.
It disappears when I launch a graphical application (Qt or SDL).

Quoted 9 lines · Julien Boibessot

Hello,

Sascha Hauer a ?crit :

Quoted 6 lines

The following series adds i.MX51 framebuffer support based on the IPUv3. It is not perfect but I decided it is good enough to open it for a wider audience and collect first reviews. I tested this on a babbage board using both outputs (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths. I also tested it on one custom board using a fixed display setting.

Quoted 8 lines

This driver is also working fine for me on a custom i.MX51 board with a 800x480 18 bits TFT LCD (16bpp mode).

The only strange thing I noticed was a kind of uggly sprite/artefact (32x32, I would say) appearing at the same time as the Linux console. I think it may be related to a hardware cursor badly (?) initialised, but I didn't find a fix yet.
It disappears when I launch a graphical application (Qt or SDL).

It may be the penguin, but I remember a similar report also talkling about hardware cursors. I can't reproduce this. You could search for cursor in the IPU section of the manual and play with the corresponding registers.