Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.

Changes since v3:
Patch order inverted as requested by Mauro.
Now adjusting of the image dimensions is made using v4l_bound_align_image(). Some coding style fixes.

i.MX2x SoCs have a PrP which is capable of resizing and format conversion of video frames. This driver provides support for resizing and format conversion from YUYV to YUV420.

This operation is of the utmost importance since some of these SoCs like i.MX27 include an H.264 video codec which only accepts YUV420 as input.

---
 drivers/media/video/Kconfig       |   10 +
 drivers/media/video/Makefile      |    2 +
 drivers/media/video/mx2_emmaprp.c | 1008 +++++++++++++++++++++++++++++++++++++
 3 files changed, 1020 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mx2_emmaprp.c

index b303a3f..e8ce0c2 100644
@@ -1107,4 +1107,14 @@ config VIDEO_SAMSUNG_S5P_MFC
 	help
 	    MFC 5.1 driver for V4L2.
 
+config VIDEO_MX2_EMMAPRP
+	tristate "MX2 eMMa-PrP support"
+	depends on VIDEO_DEV && VIDEO_V4L2 && SOC_IMX27
+	select VIDEOBUF2_DMA_CONTIG
+	select V4L2_MEM2MEM_DEV
+	help
+	    MX2X chips have a PrP that can be used to process buffers from
+	    memory to memory. Operations include resizing and format
+	    conversion.
+
 endif # V4L_MEM2MEM_DRIVERS

index 117f9c4..7ae711e 100644
@@ -176,6 +176,8 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)	+= sh_mobile_ceu_camera.o
 obj-$(CONFIG_VIDEO_OMAP1)		+= omap1_camera.o
 obj-$(CONFIG_VIDEO_ATMEL_ISI)		+= atmel-isi.o
 
+obj-$(CONFIG_VIDEO_MX2_EMMAPRP)		+= mx2_emmaprp.o
+
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) 	+= s5p-fimc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)	+= s5p-mfc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)	+= s5p-tv/

1.7.0.4

eMMa-PrP device included in Freescale i.MX2 chips can also be used separately to process memory buffers. This patch provides arch glue code for the driver which provides this functionality.

---
 arch/arm/mach-imx/clock-imx27.c                 |    2 +-
 arch/arm/mach-imx/devices-imx27.h               |    2 ++
 arch/arm/plat-mxc/devices/platform-mx2-camera.c |   18 ++++++++++++++++++
 arch/arm/plat-mxc/include/mach/devices-common.h |    2 ++
 4 files changed, 23 insertions(+), 1 deletions(-)

index 88fe00a..dc2d7a5 100644
@@ -661,7 +661,7 @@ static struct clk_lookup lookups[] = {
 	_REGISTER_CLOCK(NULL, "dma", dma_clk)
 	_REGISTER_CLOCK(NULL, "rtic", rtic_clk)
 	_REGISTER_CLOCK(NULL, "brom", brom_clk)
-	_REGISTER_CLOCK(NULL, "emma", emma_clk)
+	_REGISTER_CLOCK("m2m-emmaprp.0", NULL, emma_clk)
 	_REGISTER_CLOCK(NULL, "slcdc", slcdc_clk)
 	_REGISTER_CLOCK("imx27-fec.0", NULL, fec_clk)
 	_REGISTER_CLOCK(NULL, "emi", emi_clk)

index 2f727d7..28537a5 100644
@@ -50,6 +50,8 @@ extern const struct imx_imx_uart_1irq_data imx27_imx_uart_data[];
 extern const struct imx_mx2_camera_data imx27_mx2_camera_data;
 #define imx27_add_mx2_camera(pdata)	\
 	imx_add_mx2_camera(&imx27_mx2_camera_data, pdata)
+#define imx27_add_mx2_emmaprp(pdata)	\
+	imx_add_mx2_emmaprp(&imx27_mx2_camera_data)
 
 extern const struct imx_mxc_ehci_data imx27_mxc_ehci_otg_data;
 #define imx27_add_mxc_ehci_otg(pdata)	\

index b3f4828..11eace9 100644
@@ -62,3 +62,21 @@ struct platform_device *__init imx_add_mx2_camera(
 			res, data->iobaseemmaprp ? 4 : 2,
 			pdata, sizeof(*pdata), DMA_BIT_MASK(32));
 }
+
+struct platform_device *__init imx_add_mx2_emmaprp(
+		const struct imx_mx2_camera_data *data)
+{
+	struct resource res[] = {
+		{
+			.start = data->iobaseemmaprp,
+			.end = data->iobaseemmaprp + data->iosizeemmaprp - 1,
+			.flags = IORESOURCE_MEM,
+		}, {
+			.start = data->irqemmaprp,
+			.end = data->irqemmaprp,
+			.flags = IORESOURCE_IRQ,
+		},
+	};
+	return imx_add_platform_device_dmamask("m2m-emmaprp", 0,
+			res, 2, NULL, 0, DMA_BIT_MASK(32));
+}

index def9ba5..1b2258d 100644
@@ -223,6 +223,8 @@ struct imx_mx2_camera_data {
 struct platform_device *__init imx_add_mx2_camera(
 		const struct imx_mx2_camera_data *data,
 		const struct mx2_camera_platform_data *pdata);
+struct platform_device *__init imx_add_mx2_emmaprp(
+		const struct imx_mx2_camera_data *data);
 
 #include <mach/mxc_ehci.h>
 struct imx_mxc_ehci_data {

1.7.0.4

Hi,
do you have any more concerns or comments on this patch? I can't find it in media_tree. Has it been merged somewhere else?

Thank you.

Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com

Hi Javier,

If you think your driver is good enough for merging, if you didn't do so already, you should normally send Mauro a git pull request. Please see:

http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#how_to_submit_a_-git_pull_request

And here you can find some examples:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=PULL&archive=both

--

Regards,
Sylwester

Do you mean I have to set up a public GIT repository? Is this mandatory? I am not a subsystem maintainer, just casual developer.

What about this?

http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#Patches_submitted_via_email

Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com

Added Mauro to CC.

Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com

It's not mandatory. But it helps Mauro to distinguish between RFC and patches for merging AFAIK. I think you can ask him to pickup patches from the mailing list directly.

Regards,

Sylwester Nawrocki
Samsung Poland R&D Center

Em 03-01-2012 07:53, Sylwester Nawrocki escreveu:

We have a high patch traffic at the ML. While all patches are stored there, I generally wait for a while, for the driver maintainers to catch their patches.

Also, those SoC patches in general generate lots of discussions and versions (it is not unusual to have about 20 versions of big patch series, where most of the changes are driver-specific logic, where I can't contribute, as I lack resources to analyze those small implementation-specific details).

So, what I generally do with SoC drivers is to mark them all as RFC at patchwork, and I wait for the SoC maintainer to send me a pull request.

Anyway, as you've send me a git pull request, and the driver looks ok, I'm applying it on my tree.

Regards,
Mauro