Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1656365 > unrolled thread

[PATCH 0/9] [media] s5p-jpeg: Various fixes and improvements

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/9] [media] s5p-jpeg: Various fixes and improvements Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
    [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
      Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-06-02 23:50 +0200
      Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support Shuah Khan <shuahkhan@gmail.com> - 2017-06-03 02:50 +0200
      Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support Sylwester Nawrocki <s.nawrocki@samsung.com> - 2017-06-05 13:40 +0200
    [PATCH 2/9] [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
      Re: [PATCH 2/9] [media] s5p-jpeg: Call jpeg_bound_align_image after  qbuf Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-06-02 23:30 +0200
    [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250 Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
      Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for  Exynos5250 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-06-03 00:00 +0200
        Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for  Exynos5250 Sylwester Nawrocki <s.nawrocki@samsung.com> - 2017-06-05 12:30 +0200
    [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
      Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft  reset Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-06-02 22:00 +0200
        Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft  reset Thierry Escande <thierry.escande@collabora.com> - 2017-06-07 14:40 +0200
    [PATCH 4/9] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
      Re: [PATCH 4/9] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling  format Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-06-02 23:40 +0200
    [PATCH 3/9] [media] s5p-jpeg: Correct WARN_ON statement for checking subsampling Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
    [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs Thierry Escande <thierry.escande@collabora.com> - 2017-06-02 18:10 +0200
      Re: [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-06-03 00:10 +0200

#1656365 — [PATCH 0/9] [media] s5p-jpeg: Various fixes and improvements

Hi,

This series contains various fixes and improvements for the Samsung
s5p-jpeg driver. All these patches come from the Chromium v3.8 kernel
tree.

Regards,
 Thierry

Abhilash Kesavan (1):
  [media] s5p-jpeg: Reset the Codec before doing a soft reset

Ricky Liang (1):
  [media] s5p-jpeg: Add support for multi-planar APIs

Tony K Nadackal (4):
  [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf
  [media] s5p-jpeg: Correct WARN_ON statement for checking subsampling
  [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format
  [media] s5p-jpeg: Add IOMMU support

henryhsu (3):
  [media] s5p-jpeg: Add support for resolution change event
  [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250
  [media] s5p-jpeg: Add stream error handling for Exynos5420

 drivers/media/platform/s5p-jpeg/jpeg-core.c       | 387 ++++++++++++++++++++--
 drivers/media/platform/s5p-jpeg/jpeg-core.h       |   9 +
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c |   4 +
 3 files changed, 368 insertions(+), 32 deletions(-)

-- 
2.7.4

[toc] | [next] | [standalone]

#1656366 — [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

From: Tony K Nadackal <tony.kn@samsung.com>

This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU
and ARM DMA IOMMU configurations are supported. The address space is
created with size limited to 256M and base address set to 0x20000000.

Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 77 +++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 770a709..5569b99 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -28,6 +28,14 @@
 #include <media/v4l2-ioctl.h>
 #include <media/videobuf2-v4l2.h>
 #include <media/videobuf2-dma-contig.h>
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
+#include <asm/dma-iommu.h>
+#include <linux/dma-iommu.h>
+#include <linux/dma-mapping.h>
+#include <linux/iommu.h>
+#include <linux/kref.h>
+#include <linux/of_platform.h>
+#endif
 
 #include "jpeg-core.h"
 #include "jpeg-hw-s5p.h"
@@ -35,6 +43,10 @@
 #include "jpeg-hw-exynos3250.h"
 #include "jpeg-regs.h"
 
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
+static struct dma_iommu_mapping *mapping;
+#endif
+
 static struct s5p_jpeg_fmt sjpeg_formats[] = {
 	{
 		.name		= "JPEG JFIF",
@@ -956,6 +968,60 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx *ctx)
 	}
 }
 
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
+static int jpeg_iommu_init(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	int err;
+
+	mapping = arm_iommu_create_mapping(&platform_bus_type, 0x20000000,
+					   SZ_512M);
+	if (IS_ERR(mapping)) {
+		dev_err(dev, "IOMMU mapping failed\n");
+		return PTR_ERR(mapping);
+	}
+
+	dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL);
+	if (!dev->dma_parms) {
+		err = -ENOMEM;
+		goto error_alloc;
+	}
+
+	err = dma_set_max_seg_size(dev, 0xffffffffu);
+	if (err)
+		goto error;
+
+	err = arm_iommu_attach_device(dev, mapping);
+	if (err)
+		goto error;
+
+	return 0;
+
+error:
+	devm_kfree(dev, dev->dma_parms);
+	dev->dma_parms = NULL;
+
+error_alloc:
+	arm_iommu_release_mapping(mapping);
+	mapping = NULL;
+
+	return err;
+}
+
+static void jpeg_iommu_deinit(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+
+	if (mapping) {
+		arm_iommu_detach_device(dev);
+		devm_kfree(dev, dev->dma_parms);
+		dev->dma_parms = NULL;
+		arm_iommu_release_mapping(mapping);
+		mapping = NULL;
+	}
+}
+#endif
+
 /*
  * ============================================================================
  * Device file operations
@@ -2816,6 +2882,13 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
 	spin_lock_init(&jpeg->slock);
 	jpeg->dev = &pdev->dev;
 
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
+	ret = jpeg_iommu_init(pdev);
+	if (ret) {
+		dev_err(&pdev->dev, "IOMMU Initialization failed\n");
+		return ret;
+	}
+#endif
 	/* memory-mapped registers */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
@@ -2962,6 +3035,10 @@ static int s5p_jpeg_remove(struct platform_device *pdev)
 			clk_disable_unprepare(jpeg->clocks[i]);
 	}
 
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
+	jpeg_iommu_deinit(pdev);
+#endif
+
 	return 0;
 }
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1656580 — Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

Cc Marek Szyprowski.

Marek, could you share your opinion about this patch?

On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: Tony K Nadackal <tony.kn@samsung.com>
> 
> This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU
> and ARM DMA IOMMU configurations are supported. The address space is
> created with size limited to 256M and base address set to 0x20000000.
> 
> Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 77 +++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 770a709..5569b99 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -28,6 +28,14 @@
>  #include <media/v4l2-ioctl.h>
>  #include <media/videobuf2-v4l2.h>
>  #include <media/videobuf2-dma-contig.h>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +#include <asm/dma-iommu.h>
> +#include <linux/dma-iommu.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/iommu.h>
> +#include <linux/kref.h>
> +#include <linux/of_platform.h>
> +#endif
>  
>  #include "jpeg-core.h"
>  #include "jpeg-hw-s5p.h"
> @@ -35,6 +43,10 @@
>  #include "jpeg-hw-exynos3250.h"
>  #include "jpeg-regs.h"
>  
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static struct dma_iommu_mapping *mapping;
> +#endif
> +
>  static struct s5p_jpeg_fmt sjpeg_formats[] = {
>  	{
>  		.name		= "JPEG JFIF",
> @@ -956,6 +968,60 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx *ctx)
>  	}
>  }
>  
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static int jpeg_iommu_init(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int err;
> +
> +	mapping = arm_iommu_create_mapping(&platform_bus_type, 0x20000000,
> +					   SZ_512M);
> +	if (IS_ERR(mapping)) {
> +		dev_err(dev, "IOMMU mapping failed\n");
> +		return PTR_ERR(mapping);
> +	}
> +
> +	dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL);
> +	if (!dev->dma_parms) {
> +		err = -ENOMEM;
> +		goto error_alloc;
> +	}
> +
> +	err = dma_set_max_seg_size(dev, 0xffffffffu);
> +	if (err)
> +		goto error;
> +
> +	err = arm_iommu_attach_device(dev, mapping);
> +	if (err)
> +		goto error;
> +
> +	return 0;
> +
> +error:
> +	devm_kfree(dev, dev->dma_parms);
> +	dev->dma_parms = NULL;
> +
> +error_alloc:
> +	arm_iommu_release_mapping(mapping);
> +	mapping = NULL;
> +
> +	return err;
> +}
> +
> +static void jpeg_iommu_deinit(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +
> +	if (mapping) {
> +		arm_iommu_detach_device(dev);
> +		devm_kfree(dev, dev->dma_parms);
> +		dev->dma_parms = NULL;
> +		arm_iommu_release_mapping(mapping);
> +		mapping = NULL;
> +	}
> +}
> +#endif
> +
>  /*
>   * ============================================================================
>   * Device file operations
> @@ -2816,6 +2882,13 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
>  	spin_lock_init(&jpeg->slock);
>  	jpeg->dev = &pdev->dev;
>  
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +	ret = jpeg_iommu_init(pdev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "IOMMU Initialization failed\n");
> +		return ret;
> +	}
> +#endif
>  	/* memory-mapped registers */
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  
> @@ -2962,6 +3035,10 @@ static int s5p_jpeg_remove(struct platform_device *pdev)
>  			clk_disable_unprepare(jpeg->clocks[i]);
>  	}
>  
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +	jpeg_iommu_deinit(pdev);
> +#endif
> +
>  	return 0;
>  }
>  
> 

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1656649 — Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

On Fri, Jun 2, 2017 at 10:02 AM, Thierry Escande
<thierry.escande@collabora.com> wrote:
> From: Tony K Nadackal <tony.kn@samsung.com>
>
> This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU
> and ARM DMA IOMMU configurations are supported. The address space is
> created with size limited to 256M and base address set to 0x20000000.
>
> Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 77 +++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 770a709..5569b99 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -28,6 +28,14 @@
>  #include <media/v4l2-ioctl.h>
>  #include <media/videobuf2-v4l2.h>
>  #include <media/videobuf2-dma-contig.h>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +#include <asm/dma-iommu.h>
> +#include <linux/dma-iommu.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/iommu.h>
> +#include <linux/kref.h>
> +#include <linux/of_platform.h>
> +#endif
>
>  #include "jpeg-core.h"
>  #include "jpeg-hw-s5p.h"
> @@ -35,6 +43,10 @@
>  #include "jpeg-hw-exynos3250.h"
>  #include "jpeg-regs.h"
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static struct dma_iommu_mapping *mapping;
> +#endif
> +
>  static struct s5p_jpeg_fmt sjpeg_formats[] = {
>         {
>                 .name           = "JPEG JFIF",
> @@ -956,6 +968,60 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx *ctx)
>         }
>  }
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static int jpeg_iommu_init(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       int err;
> +
> +       mapping = arm_iommu_create_mapping(&platform_bus_type, 0x20000000,
> +                                          SZ_512M);

Change log says 256M??

What happens when another driver uses the same start point?
exynos drm uses the same  looks like

EXYNOS_DEV_ADDR_START   0x20000000

> +       if (IS_ERR(mapping)) {
> +               dev_err(dev, "IOMMU mapping failed\n");
> +               return PTR_ERR(mapping);
> +       }
> +
> +       dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL);
> +       if (!dev->dma_parms) {
> +               err = -ENOMEM;
> +               goto error_alloc;
> +       }
> +
> +       err = dma_set_max_seg_size(dev, 0xffffffffu);

You could use DMA_BIT_MASK(32) instead of 0xffffffffu

> +       if (err)
> +               goto error;
> +
> +       err = arm_iommu_attach_device(dev, mapping);
> +       if (err)
> +               goto error;
> +
> +       return 0;
> +
> +error:
> +       devm_kfree(dev, dev->dma_parms);
> +       dev->dma_parms = NULL;
> +
> +error_alloc:
> +       arm_iommu_release_mapping(mapping);
> +       mapping = NULL;
> +
> +       return err;
> +}
> +
> +static void jpeg_iommu_deinit(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +
> +       if (mapping) {
> +               arm_iommu_detach_device(dev);
> +               devm_kfree(dev, dev->dma_parms);
> +               dev->dma_parms = NULL;
> +               arm_iommu_release_mapping(mapping);
> +               mapping = NULL;
> +       }
> +}
> +#endif
> +
>  /*
>   * ============================================================================
>   * Device file operations
> @@ -2816,6 +2882,13 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
>         spin_lock_init(&jpeg->slock);
>         jpeg->dev = &pdev->dev;
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +       ret = jpeg_iommu_init(pdev);
> +       if (ret) {
> +               dev_err(&pdev->dev, "IOMMU Initialization failed\n");
> +               return ret;
> +       }
> +#endif

You might be able to avoid use of ifdefs if you define stubs for !defines case.

>         /* memory-mapped registers */
>         res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> @@ -2962,6 +3035,10 @@ static int s5p_jpeg_remove(struct platform_device *pdev)
>                         clk_disable_unprepare(jpeg->clocks[i]);
>         }
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +       jpeg_iommu_deinit(pdev);
> +#endif
> +
>         return 0;
>  }
>
> --
> 2.7.4
>

[toc] | [prev] | [next] | [standalone]

#1657528 — Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: Tony K Nadackal <tony.kn@samsung.com>
> 
> This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU
> and ARM DMA IOMMU configurations are supported. The address space is
> created with size limited to 256M and base address set to 0x20000000.

I don't think this patch is needed now, a few things changed in mainline
since v3.8. The mapping is being created automatically now for this single
JPEG CODEC device by the driver core/dma-mapping code AFAICS.
See dma_configure() in drivers/base/dd.c.
I doubt we need a specific CPU address range, but even if we would shouldn't
it be specified through the dma-ranges DT property?

> Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>   drivers/media/platform/s5p-jpeg/jpeg-core.c | 77 +++++++++++++++++++++++++++++
>   1 file changed, 77 insertions(+)

> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static int jpeg_iommu_init(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int err;
> +
> +	mapping = arm_iommu_create_mapping(&platform_bus_type, 0x20000000,
> +					   SZ_512M);
> +	if (IS_ERR(mapping)) {
> +		dev_err(dev, "IOMMU mapping failed\n");
> +		return PTR_ERR(mapping);
> +	}
> +
> +	dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL);

dev->dma_parms seems to be unused.

> +	if (!dev->dma_parms) {
> +		err = -ENOMEM;
> +		goto error_alloc;
> +	}
> +
> +	err = dma_set_max_seg_size(dev, 0xffffffffu);
> +	if (err)
> +		goto error;
> +
> +	err = arm_iommu_attach_device(dev, mapping);
> +	if (err)
> +		goto error;
> +
> +	return 0;
> +
> +error:
> +	devm_kfree(dev, dev->dma_parms);

There is no need for this devm_kfree() call.

> +	dev->dma_parms = NULL;
> +
> +error_alloc:
> +	arm_iommu_release_mapping(mapping);
> +	mapping = NULL;
> +
> +	return err;
> +}
> +
> +static void jpeg_iommu_deinit(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +
> +	if (mapping) {
> +		arm_iommu_detach_device(dev);
> +		devm_kfree(dev, dev->dma_parms);

Ditto.

> +		dev->dma_parms = NULL;
> +		arm_iommu_release_mapping(mapping);
> +		mapping = NULL;
> +	}
> +}

>   /*
>    * ============================================================================
>    * Device file operations
> @@ -2816,6 +2882,13 @@ static int s5p_jpeg_probe(struct platform_device *pdev)

> +	ret = jpeg_iommu_init(pdev);

> @@ -2962,6 +3035,10 @@ static int s5p_jpeg_remove(struct platform_device *pdev)

> +	jpeg_iommu_deinit(pdev);

>   	return 0;
>   }

--
Thanks,
Sylwester

[toc] | [prev] | [next] | [standalone]

#1656368 — [PATCH 2/9] [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf

From: Tony K Nadackal <tony.kn@samsung.com>

When queuing an OUTPUT buffer for decoder, s5p_jpeg_parse_hdr()
function parses the input jpeg file and takes the width and height
parameters from its header. These new width/height values will be used
for the calculation of stride. HX_JPEG Hardware needs the width and
height values aligned on a 16 bits boundary. This width/height alignment
is handled in the s5p_jpeg_s_fmt_vid_cap() function during the S_FMT
ioctl call.

But if user space calls the QBUF of OUTPUT buffer after the S_FMT of
CAPTURE buffer, these aligned values will be replaced by the values in
jpeg header. If the width/height values of jpeg are not aligned, the
decoder output will be corrupted. So in this patch we call
jpeg_bound_align_image() to align the width/height values of Capture
buffer in s5p_jpeg_buf_queue().

Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 52dc794..6fb1ab4 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2523,6 +2523,13 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
 		q_data = &ctx->cap_q;
 		q_data->w = tmp.w;
 		q_data->h = tmp.h;
+
+		jpeg_bound_align_image(ctx, &q_data->w, S5P_JPEG_MIN_WIDTH,
+				       S5P_JPEG_MAX_WIDTH, q_data->fmt->h_align,
+				       &q_data->h, S5P_JPEG_MIN_HEIGHT,
+				       S5P_JPEG_MAX_HEIGHT, q_data->fmt->v_align
+				      );
+		q_data->size = q_data->w * q_data->h * q_data->fmt->depth >> 3;
 	}
 
 	v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1656569 — Re: [PATCH 2/9] [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf

Hi Thierry,

Thanks for the patch.

On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: Tony K Nadackal <tony.kn@samsung.com>
> 
> When queuing an OUTPUT buffer for decoder, s5p_jpeg_parse_hdr()
> function parses the input jpeg file and takes the width and height
> parameters from its header. These new width/height values will be used
> for the calculation of stride. HX_JPEG Hardware needs the width and
> height values aligned on a 16 bits boundary. This width/height alignment
> is handled in the s5p_jpeg_s_fmt_vid_cap() function during the S_FMT
> ioctl call.
> 
> But if user space calls the QBUF of OUTPUT buffer after the S_FMT of
> CAPTURE buffer, these aligned values will be replaced by the values in
> jpeg header.

I assume that you may want to avoid re-setting the capture buf format
when decoding a stream of JPEGs and you are certain that all of them
have the same subsampling. Nonetheless, please keep in mind that in case
of Exynos4x12 SoCs there is a risk of permanent decoder hangup if you'd
try to decode to a YUV with lower subsampling than the one of input
JPEG. s5p_jpeg_try_fmt_vid_cap() does a suitable adjustment to avoid the
problem.

I'd add a comment over this call to jpeg_bound_align_image() that
resigning from executing S_FMT on capture buf for each JPEG image
can result in a hardware hangup if forbidden decoding will be enforced.

> If the width/height values of jpeg are not aligned, the
> decoder output will be corrupted. So in this patch we call
> jpeg_bound_align_image() to align the width/height values of Capture
> buffer in s5p_jpeg_buf_queue().
> 
> Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 52dc794..6fb1ab4 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -2523,6 +2523,13 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
>  		q_data = &ctx->cap_q;
>  		q_data->w = tmp.w;
>  		q_data->h = tmp.h;
> +
> +		jpeg_bound_align_image(ctx, &q_data->w, S5P_JPEG_MIN_WIDTH,
> +				       S5P_JPEG_MAX_WIDTH, q_data->fmt->h_align,
> +				       &q_data->h, S5P_JPEG_MIN_HEIGHT,
> +				       S5P_JPEG_MAX_HEIGHT, q_data->fmt->v_align
> +				      );
> +		q_data->size = q_data->w * q_data->h * q_data->fmt->depth >> 3;
>  	}
>  
>  	v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
> 

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1656369 — [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250

From: henryhsu <henryhsu@chromium.org>

The default clock parent of jpeg on Exynos5250 is fin_pll, which is
24MHz. We have to change the clock parent to CPLL, which is 333MHz,
and set sclk_jpeg to 166MHz.

Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 47 +++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 7a7acbc..430e925 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -969,6 +969,44 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx *ctx)
 	}
 }
 
+static int exynos4_jpeg_set_sclk_rate(struct s5p_jpeg *jpeg, struct clk *sclk)
+{
+	struct clk *mout_jpeg;
+	struct clk *sclk_cpll;
+	int ret;
+
+	mout_jpeg = clk_get(jpeg->dev, "mout_jpeg");
+	if (IS_ERR(mout_jpeg)) {
+		dev_err(jpeg->dev, "mout_jpeg clock not available: %ld\n",
+			PTR_ERR(mout_jpeg));
+		return PTR_ERR(mout_jpeg);
+	}
+
+	sclk_cpll = clk_get(jpeg->dev, "sclk_cpll");
+	if (IS_ERR(sclk_cpll)) {
+		dev_err(jpeg->dev, "sclk_cpll clock not available: %ld\n",
+			PTR_ERR(sclk_cpll));
+		clk_put(mout_jpeg);
+		return PTR_ERR(sclk_cpll);
+	}
+
+	ret = clk_set_parent(mout_jpeg, sclk_cpll);
+	clk_put(sclk_cpll);
+	clk_put(mout_jpeg);
+	if (ret) {
+		dev_err(jpeg->dev, "clk_set_parent failed: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_set_rate(sclk, 166500 * 1000);
+	if (ret) {
+		dev_err(jpeg->dev, "clk_set_rate failed: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
 #if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
 static int jpeg_iommu_init(struct platform_device *pdev)
 {
@@ -2974,6 +3012,15 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
 				jpeg->variant->clk_names[i]);
 			return PTR_ERR(jpeg->clocks[i]);
 		}
+
+		if (jpeg->variant->version == SJPEG_EXYNOS4 &&
+		    !strncmp(jpeg->variant->clk_names[i],
+			     "sclk", strlen("sclk"))) {
+			ret = exynos4_jpeg_set_sclk_rate(jpeg,
+							 jpeg->clocks[i]);
+			if (ret)
+				return ret;
+		}
 	}
 
 	/* v4l2 device */
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1656594 — Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250

Cc Marek and Sylwester.

On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: henryhsu <henryhsu@chromium.org>
> 
> The default clock parent of jpeg on Exynos5250 is fin_pll, which is
> 24MHz. We have to change the clock parent to CPLL, which is 333MHz,
> and set sclk_jpeg to 166MHz.
> 
> Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 47 +++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 7a7acbc..430e925 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -969,6 +969,44 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx *ctx)
>  	}
>  }
>  
> +static int exynos4_jpeg_set_sclk_rate(struct s5p_jpeg *jpeg, struct clk *sclk)

Why here exynos4 and in the subject Exynos5250?

> +{
> +	struct clk *mout_jpeg;
> +	struct clk *sclk_cpll;
> +	int ret;
> +
> +	mout_jpeg = clk_get(jpeg->dev, "mout_jpeg");
> +	if (IS_ERR(mout_jpeg)) {
> +		dev_err(jpeg->dev, "mout_jpeg clock not available: %ld\n",
> +			PTR_ERR(mout_jpeg));
> +		return PTR_ERR(mout_jpeg);
> +	}
> +
> +	sclk_cpll = clk_get(jpeg->dev, "sclk_cpll");
> +	if (IS_ERR(sclk_cpll)) {
> +		dev_err(jpeg->dev, "sclk_cpll clock not available: %ld\n",
> +			PTR_ERR(sclk_cpll));
> +		clk_put(mout_jpeg);
> +		return PTR_ERR(sclk_cpll);
> +	}
> +
> +	ret = clk_set_parent(mout_jpeg, sclk_cpll);
> +	clk_put(sclk_cpll);
> +	clk_put(mout_jpeg);
> +	if (ret) {
> +		dev_err(jpeg->dev, "clk_set_parent failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = clk_set_rate(sclk, 166500 * 1000);
> +	if (ret) {
> +		dev_err(jpeg->dev, "clk_set_rate failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
>  #if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
>  static int jpeg_iommu_init(struct platform_device *pdev)
>  {
> @@ -2974,6 +3012,15 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
>  				jpeg->variant->clk_names[i]);
>  			return PTR_ERR(jpeg->clocks[i]);
>  		}
> +
> +		if (jpeg->variant->version == SJPEG_EXYNOS4 &&
> +		    !strncmp(jpeg->variant->clk_names[i],
> +			     "sclk", strlen("sclk"))) {
> +			ret = exynos4_jpeg_set_sclk_rate(jpeg,
> +							 jpeg->clocks[i]);
> +			if (ret)
> +				return ret;
> +		}
>  	}
>  
>  	/* v4l2 device */
> 

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1657486 — Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250

On 06/02/2017 11:58 PM, Jacek Anaszewski wrote:
> On 06/02/2017 06:02 PM, Thierry Escande wrote:
>> From: henryhsu<henryhsu@chromium.org>
>>
>> The default clock parent of jpeg on Exynos5250 is fin_pll, which is
>> 24MHz. We have to change the clock parent to CPLL, which is 333MHz,
>> and set sclk_jpeg to 166MHz.

There is no need to patch the driver for these platform specific clock
settings, it can be specified in the device tree with the "assigned-clocks"
properties. There is an example in mainline for exynos3250 SoC already [1].

-- 
Thanks,
Sylwester

[1] 
http://elixir.free-electrons.com/linux/v4.6/source/arch/arm/boot/dts/exynos3250.dtsi#L263

[toc] | [prev] | [next] | [standalone]

#1656371 — [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset

From: Abhilash Kesavan <a.kesavan@samsung.com>

This patch resets the encoding and decoding register bits before doing a
soft reset.

Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index a1d823a..9ad8f6d 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base)
 	unsigned int reg;
 
 	reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
+	writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE),
+	       base + EXYNOS4_JPEG_CNTL_REG);
+
+	reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
 	writel(reg & ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
 
 	udelay(100);
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1656510 — Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset

Hi Thierry,

On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: Abhilash Kesavan <a.kesavan@samsung.com>
> 
> This patch resets the encoding and decoding register bits before doing a
> soft reset.
> 
> Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> index a1d823a..9ad8f6d 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> @@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base)
>  	unsigned int reg;
>  
>  	reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
> +	writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE),
> +	       base + EXYNOS4_JPEG_CNTL_REG);

Why is it required? It would be nice if commit message explained that.

> +	reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
>  	writel(reg & ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
>  
>  	udelay(100);
> 

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1659761 — Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset

Hi Jacek,

On 02/06/2017 21:50, Jacek Anaszewski wrote:
> Hi Thierry,
> 
> On 06/02/2017 06:02 PM, Thierry Escande wrote:
>> From: Abhilash Kesavan <a.kesavan@samsung.com>
>>
>> This patch resets the encoding and decoding register bits before doing a
>> soft reset.
>>
>> Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
>> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
>> ---
>>   drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
>> index a1d823a..9ad8f6d 100644
>> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
>> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
>> @@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base)
>>   	unsigned int reg;
>>   
>>   	reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
>> +	writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE),
>> +	       base + EXYNOS4_JPEG_CNTL_REG);
> 
> Why is it required? It would be nice if commit message explained that.

Unfortunately the bug entry in the ChromeOS issue tracker does not 
mention more information about that and the patch author is no more 
reachable on that email address.

So unless someone else knows the answer I won't be able to give more 
explanation in the commit message...

Regards,
  Thierry

[toc] | [prev] | [next] | [standalone]

#1656372 — [PATCH 4/9] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format

From: Tony K Nadackal <tony.kn@samsung.com>

This patch adds support for decoding 4:1:1 chroma subsampling in the
jpeg header parsing function.

Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 0d83948..770a709 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1236,6 +1236,9 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 	case 0x33:
 		ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
 		break;
+	case 0x41:
+		ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_411;
+		break;
 	default:
 		return false;
 	}
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1656575 — Re: [PATCH 4/9] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format

Hi Thierry,

On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: Tony K Nadackal <tony.kn@samsung.com>
> 
> This patch adds support for decoding 4:1:1 chroma subsampling in the
> jpeg header parsing function.
> 
> Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 0d83948..770a709 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -1236,6 +1236,9 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
>  	case 0x33:
>  		ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
>  		break;
> +	case 0x41:
> +		ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_411;
> +		break;
>  	default:
>  		return false;
>  	}
> 

Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1656373 — [PATCH 3/9] [media] s5p-jpeg: Correct WARN_ON statement for checking subsampling

From: Tony K Nadackal <tony.kn@samsung.com>

Corrects the WARN_ON statement for subsampling based on the
JPEG Hardware version.

Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 6fb1ab4..0d83948 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -614,24 +614,26 @@ static inline struct s5p_jpeg_ctx *fh_to_ctx(struct v4l2_fh *fh)
 
 static int s5p_jpeg_to_user_subsampling(struct s5p_jpeg_ctx *ctx)
 {
-	WARN_ON(ctx->subsampling > 3);
-
 	switch (ctx->jpeg->variant->version) {
 	case SJPEG_S5P:
+		WARN_ON(ctx->subsampling > 3);
 		if (ctx->subsampling > 2)
 			return V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
 		return ctx->subsampling;
 	case SJPEG_EXYNOS3250:
 	case SJPEG_EXYNOS5420:
+		WARN_ON(ctx->subsampling > 6);
 		if (ctx->subsampling > 3)
 			return V4L2_JPEG_CHROMA_SUBSAMPLING_411;
 		return exynos3250_decoded_subsampling[ctx->subsampling];
 	case SJPEG_EXYNOS4:
 	case SJPEG_EXYNOS5433:
+		WARN_ON(ctx->subsampling > 3);
 		if (ctx->subsampling > 2)
 			return V4L2_JPEG_CHROMA_SUBSAMPLING_420;
 		return exynos4x12_decoded_subsampling[ctx->subsampling];
 	default:
+		WARN_ON(ctx->subsampling > 3);
 		return V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
 	}
 }
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1656374 — [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs

From: Ricky Liang <jcliang@chromium.org>

This patch adds multi-planar APIs to the s5p-jpeg driver. The multi-planar
APIs are identical to the exisiting single-planar APIs except the plane
format info is stored in the v4l2_pixel_format_mplan struct instead
of the v4l2_pixel_format struct.

Signed-off-by: Ricky Liang <jcliang@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 152 +++++++++++++++++++++++++---
 drivers/media/platform/s5p-jpeg/jpeg-core.h |   2 +
 2 files changed, 139 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index db56135..a8fd7ed 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1371,6 +1371,15 @@ static int s5p_jpeg_querycap(struct file *file, void *priv,
 		 dev_name(ctx->jpeg->dev));
 	cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M;
 	cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+	/*
+	 * Advertise multi-planar capabilities. The driver supports only
+	 * single-planar pixel format at this moment so all the buffers will
+	 * have only one plane.
+	 */
+	cap->capabilities |= V4L2_CAP_VIDEO_M2M_MPLANE |
+			     V4L2_CAP_VIDEO_CAPTURE_MPLANE |
+			     V4L2_CAP_VIDEO_OUTPUT_MPLANE;
+
 	return 0;
 }
 
@@ -1430,12 +1439,10 @@ static int s5p_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
 static struct s5p_jpeg_q_data *get_q_data(struct s5p_jpeg_ctx *ctx,
 					  enum v4l2_buf_type type)
 {
-	if (type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+	if (V4L2_TYPE_IS_OUTPUT(type))
 		return &ctx->out_q;
-	if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
-		return &ctx->cap_q;
 
-	return NULL;
+	return &ctx->cap_q;
 }
 
 static int s5p_jpeg_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
@@ -1449,16 +1456,14 @@ static int s5p_jpeg_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 	if (!vq)
 		return -EINVAL;
 
-	if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+	if (!V4L2_TYPE_IS_OUTPUT(f->type) &&
 	    ct->mode == S5P_JPEG_DECODE && !ct->hdr_parsed)
 		return -EINVAL;
 	q_data = get_q_data(ct, f->type);
 	BUG_ON(q_data == NULL);
 
-	if ((f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
-	     ct->mode == S5P_JPEG_ENCODE) ||
-	    (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT &&
-	     ct->mode == S5P_JPEG_DECODE)) {
+	if ((!V4L2_TYPE_IS_OUTPUT(f->type) && ct->mode == S5P_JPEG_ENCODE) ||
+	    (V4L2_TYPE_IS_OUTPUT(f->type) && ct->mode == S5P_JPEG_DECODE)) {
 		pix->width = 0;
 		pix->height = 0;
 	} else {
@@ -1715,6 +1720,8 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct v4l2_format *f)
 
 	q_data = get_q_data(ct, f->type);
 	BUG_ON(q_data == NULL);
+	vq->type = f->type;
+	q_data->type = f->type;
 
 	if (vb2_is_busy(vq)) {
 		v4l2_err(&ct->jpeg->v4l2_dev, "%s queue busy\n", __func__);
@@ -1919,7 +1926,9 @@ static int s5p_jpeg_g_selection(struct file *file, void *priv,
 	struct s5p_jpeg_ctx *ctx = fh_to_ctx(priv);
 
 	if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT &&
-	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+	    s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
+	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
 		return -EINVAL;
 
 	/* For JPEG blob active == default == bounds */
@@ -1957,7 +1966,8 @@ static int s5p_jpeg_s_selection(struct file *file, void *fh,
 	struct v4l2_rect *rect = &s->r;
 	int ret = -EINVAL;
 
-	if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+	if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
 		return -EINVAL;
 
 	if (s->target == V4L2_SEL_TGT_COMPOSE) {
@@ -2118,6 +2128,107 @@ static int s5p_jpeg_controls_create(struct s5p_jpeg_ctx *ctx)
 	return ret;
 }
 
+static void v4l2_format_pixmp_to_pix(struct v4l2_format *fmt_pix_mp,
+				     struct v4l2_format *fmt_pix) {
+	struct v4l2_pix_format *pix = &fmt_pix->fmt.pix;
+	struct v4l2_pix_format_mplane *pix_mp = &fmt_pix_mp->fmt.pix_mp;
+
+	fmt_pix->type = fmt_pix_mp->type;
+	pix->width = pix_mp->width;
+	pix->height = pix_mp->height;
+	pix->pixelformat = pix_mp->pixelformat;
+	pix->field = pix_mp->field;
+	pix->colorspace = pix_mp->colorspace;
+	pix->bytesperline = pix_mp->plane_fmt[0].bytesperline;
+	pix->sizeimage = pix_mp->plane_fmt[0].sizeimage;
+}
+
+static void v4l2_format_pixmp_from_pix(struct v4l2_format *fmt_pix_mp,
+				       struct v4l2_format *fmt_pix) {
+	struct v4l2_pix_format *pix = &fmt_pix->fmt.pix;
+	struct v4l2_pix_format_mplane *pix_mp = &fmt_pix_mp->fmt.pix_mp;
+
+	fmt_pix_mp->type = fmt_pix->type;
+	pix_mp->width = pix->width;
+	pix_mp->height = pix->height;
+	pix_mp->pixelformat = pix->pixelformat;
+	pix_mp->field = pix->field;
+	pix_mp->colorspace = pix->colorspace;
+	pix_mp->plane_fmt[0].bytesperline = pix->bytesperline;
+	pix_mp->plane_fmt[0].sizeimage = pix->sizeimage;
+	pix_mp->num_planes = 1;
+}
+
+static int s5p_jpeg_g_fmt_mplane(struct file *file, void *priv,
+				 struct v4l2_format *f)
+{
+	struct v4l2_format tmp;
+	int ret;
+
+	memset(&tmp, 0, sizeof(tmp));
+	v4l2_format_pixmp_to_pix(f, &tmp);
+	ret = s5p_jpeg_g_fmt(file, priv, &tmp);
+	v4l2_format_pixmp_from_pix(f, &tmp);
+
+	return ret;
+}
+
+static int s5p_jpeg_try_fmt_vid_cap_mplane(struct file *file, void *priv,
+					   struct v4l2_format *f)
+{
+	struct v4l2_format tmp;
+	int ret;
+
+	memset(&tmp, 0, sizeof(tmp));
+	v4l2_format_pixmp_to_pix(f, &tmp);
+	ret = s5p_jpeg_try_fmt_vid_cap(file, priv, &tmp);
+	v4l2_format_pixmp_from_pix(f, &tmp);
+
+	return ret;
+}
+
+static int s5p_jpeg_try_fmt_vid_out_mplane(struct file *file, void *priv,
+					   struct v4l2_format *f)
+{
+	struct v4l2_format tmp;
+	int ret;
+
+	memset(&tmp, 0, sizeof(tmp));
+	v4l2_format_pixmp_to_pix(f, &tmp);
+	ret = s5p_jpeg_try_fmt_vid_out(file, priv, &tmp);
+	v4l2_format_pixmp_from_pix(f, &tmp);
+
+	return ret;
+}
+
+static int s5p_jpeg_s_fmt_vid_cap_mplane(struct file *file, void *priv,
+					 struct v4l2_format *f)
+{
+	struct v4l2_format tmp;
+	int ret;
+
+	memset(&tmp, 0, sizeof(tmp));
+	v4l2_format_pixmp_to_pix(f, &tmp);
+	ret = s5p_jpeg_s_fmt_vid_cap(file, priv, &tmp);
+	v4l2_format_pixmp_from_pix(f, &tmp);
+
+	return ret;
+}
+
+static int s5p_jpeg_s_fmt_vid_out_mplane(struct file *file, void *priv,
+					 struct v4l2_format *f)
+{
+	struct v4l2_format tmp;
+	int ret;
+
+	memset(&tmp, 0, sizeof(tmp));
+	v4l2_format_pixmp_to_pix(f, &tmp);
+	ret = s5p_jpeg_s_fmt_vid_out(file, priv, &tmp);
+	v4l2_format_pixmp_from_pix(f, &tmp);
+
+	return ret;
+}
+
 static const struct v4l2_ioctl_ops s5p_jpeg_ioctl_ops = {
 	.vidioc_querycap		= s5p_jpeg_querycap,
 
@@ -2133,6 +2244,18 @@ static const struct v4l2_ioctl_ops s5p_jpeg_ioctl_ops = {
 	.vidioc_s_fmt_vid_cap		= s5p_jpeg_s_fmt_vid_cap,
 	.vidioc_s_fmt_vid_out		= s5p_jpeg_s_fmt_vid_out,
 
+	.vidioc_enum_fmt_vid_cap_mplane	= s5p_jpeg_enum_fmt_vid_cap,
+	.vidioc_enum_fmt_vid_out_mplane	= s5p_jpeg_enum_fmt_vid_out,
+
+	.vidioc_g_fmt_vid_cap_mplane	= s5p_jpeg_g_fmt_mplane,
+	.vidioc_g_fmt_vid_out_mplane	= s5p_jpeg_g_fmt_mplane,
+
+	.vidioc_try_fmt_vid_cap_mplane	= s5p_jpeg_try_fmt_vid_cap_mplane,
+	.vidioc_try_fmt_vid_out_mplane	= s5p_jpeg_try_fmt_vid_out_mplane,
+
+	.vidioc_s_fmt_vid_cap_mplane	= s5p_jpeg_s_fmt_vid_cap_mplane,
+	.vidioc_s_fmt_vid_out_mplane	= s5p_jpeg_s_fmt_vid_out_mplane,
+
 	.vidioc_reqbufs			= v4l2_m2m_ioctl_reqbufs,
 	.vidioc_querybuf		= v4l2_m2m_ioctl_querybuf,
 	.vidioc_qbuf			= v4l2_m2m_ioctl_qbuf,
@@ -2648,7 +2771,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
 	struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
 
 	if (ctx->mode == S5P_JPEG_DECODE &&
-	    vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+	    vb->vb2_queue->type == ctx->out_q.type) {
 		static const struct v4l2_event ev_src_ch = {
 			.type = V4L2_EVENT_SOURCE_CHANGE,
 			.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
@@ -2657,8 +2780,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
 		u32 ori_w;
 		u32 ori_h;
 
-		dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
-					 V4L2_BUF_TYPE_VIDEO_CAPTURE);
+		dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, ctx->cap_q.type);
 		ori_w = ctx->out_q.w;
 		ori_h = ctx->out_q.h;
 
@@ -2708,7 +2830,7 @@ static void s5p_jpeg_stop_streaming(struct vb2_queue *q)
 	 * subsampling. Update capture queue when the stream is off.
 	 */
 	if (ctx->state == JPEGCTX_RESOLUTION_CHANGE &&
-	    q->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+	    !V4L2_TYPE_IS_OUTPUT(q->type)) {
 		s5p_jpeg_set_capture_queue_data(ctx);
 		ctx->state = JPEGCTX_RUNNING;
 	}
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h b/drivers/media/platform/s5p-jpeg/jpeg-core.h
index 9aa26bd..302a297 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -196,6 +196,7 @@ struct s5p_jpeg_marker {
  * @sof_len:	SOF0 marker's payload length (without length field itself)
  * @components:	number of image components
  * @size:	image buffer size in bytes
+ * @type:	buffer type of the queue (enum v4l2_buf_type)
  */
 struct s5p_jpeg_q_data {
 	struct s5p_jpeg_fmt	*fmt;
@@ -208,6 +209,7 @@ struct s5p_jpeg_q_data {
 	u32			sof_len;
 	u32			components;
 	u32			size;
+	u32			type;
 };
 
 /**
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1656600 — Re: [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs

Hi Thierry,

What is the gain of introducing multiplanar API for this hardware?
AFAIR all the HW implementations store the data in a single contiguous
memory region and use suitable padding between planes.

On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: Ricky Liang <jcliang@chromium.org>
> 
> This patch adds multi-planar APIs to the s5p-jpeg driver. The multi-planar
> APIs are identical to the exisiting single-planar APIs except the plane
> format info is stored in the v4l2_pixel_format_mplan struct instead
> of the v4l2_pixel_format struct.
> 
> Signed-off-by: Ricky Liang <jcliang@chromium.org>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 152 +++++++++++++++++++++++++---
>  drivers/media/platform/s5p-jpeg/jpeg-core.h |   2 +
>  2 files changed, 139 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index db56135..a8fd7ed 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -1371,6 +1371,15 @@ static int s5p_jpeg_querycap(struct file *file, void *priv,
>  		 dev_name(ctx->jpeg->dev));
>  	cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M;
>  	cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
> +	/*
> +	 * Advertise multi-planar capabilities. The driver supports only
> +	 * single-planar pixel format at this moment so all the buffers will
> +	 * have only one plane.
> +	 */
> +	cap->capabilities |= V4L2_CAP_VIDEO_M2M_MPLANE |
> +			     V4L2_CAP_VIDEO_CAPTURE_MPLANE |
> +			     V4L2_CAP_VIDEO_OUTPUT_MPLANE;
> +
>  	return 0;
>  }
>  
> @@ -1430,12 +1439,10 @@ static int s5p_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
>  static struct s5p_jpeg_q_data *get_q_data(struct s5p_jpeg_ctx *ctx,
>  					  enum v4l2_buf_type type)
>  {
> -	if (type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
> +	if (V4L2_TYPE_IS_OUTPUT(type))
>  		return &ctx->out_q;
> -	if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> -		return &ctx->cap_q;
>  
> -	return NULL;
> +	return &ctx->cap_q;
>  }
>  
>  static int s5p_jpeg_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
> @@ -1449,16 +1456,14 @@ static int s5p_jpeg_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
>  	if (!vq)
>  		return -EINVAL;
>  
> -	if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
> +	if (!V4L2_TYPE_IS_OUTPUT(f->type) &&
>  	    ct->mode == S5P_JPEG_DECODE && !ct->hdr_parsed)
>  		return -EINVAL;
>  	q_data = get_q_data(ct, f->type);
>  	BUG_ON(q_data == NULL);
>  
> -	if ((f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
> -	     ct->mode == S5P_JPEG_ENCODE) ||
> -	    (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT &&
> -	     ct->mode == S5P_JPEG_DECODE)) {
> +	if ((!V4L2_TYPE_IS_OUTPUT(f->type) && ct->mode == S5P_JPEG_ENCODE) ||
> +	    (V4L2_TYPE_IS_OUTPUT(f->type) && ct->mode == S5P_JPEG_DECODE)) {
>  		pix->width = 0;
>  		pix->height = 0;
>  	} else {
> @@ -1715,6 +1720,8 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct v4l2_format *f)
>  
>  	q_data = get_q_data(ct, f->type);
>  	BUG_ON(q_data == NULL);
> +	vq->type = f->type;
> +	q_data->type = f->type;
>  
>  	if (vb2_is_busy(vq)) {
>  		v4l2_err(&ct->jpeg->v4l2_dev, "%s queue busy\n", __func__);
> @@ -1919,7 +1926,9 @@ static int s5p_jpeg_g_selection(struct file *file, void *priv,
>  	struct s5p_jpeg_ctx *ctx = fh_to_ctx(priv);
>  
>  	if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT &&
> -	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> +	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE &&
> +	    s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
> +	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
>  		return -EINVAL;
>  
>  	/* For JPEG blob active == default == bounds */
> @@ -1957,7 +1966,8 @@ static int s5p_jpeg_s_selection(struct file *file, void *fh,
>  	struct v4l2_rect *rect = &s->r;
>  	int ret = -EINVAL;
>  
> -	if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> +	if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE &&
> +	    s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
>  		return -EINVAL;
>  
>  	if (s->target == V4L2_SEL_TGT_COMPOSE) {
> @@ -2118,6 +2128,107 @@ static int s5p_jpeg_controls_create(struct s5p_jpeg_ctx *ctx)
>  	return ret;
>  }
>  
> +static void v4l2_format_pixmp_to_pix(struct v4l2_format *fmt_pix_mp,
> +				     struct v4l2_format *fmt_pix) {
> +	struct v4l2_pix_format *pix = &fmt_pix->fmt.pix;
> +	struct v4l2_pix_format_mplane *pix_mp = &fmt_pix_mp->fmt.pix_mp;
> +
> +	fmt_pix->type = fmt_pix_mp->type;
> +	pix->width = pix_mp->width;
> +	pix->height = pix_mp->height;
> +	pix->pixelformat = pix_mp->pixelformat;
> +	pix->field = pix_mp->field;
> +	pix->colorspace = pix_mp->colorspace;
> +	pix->bytesperline = pix_mp->plane_fmt[0].bytesperline;
> +	pix->sizeimage = pix_mp->plane_fmt[0].sizeimage;
> +}
> +
> +static void v4l2_format_pixmp_from_pix(struct v4l2_format *fmt_pix_mp,
> +				       struct v4l2_format *fmt_pix) {
> +	struct v4l2_pix_format *pix = &fmt_pix->fmt.pix;
> +	struct v4l2_pix_format_mplane *pix_mp = &fmt_pix_mp->fmt.pix_mp;
> +
> +	fmt_pix_mp->type = fmt_pix->type;
> +	pix_mp->width = pix->width;
> +	pix_mp->height = pix->height;
> +	pix_mp->pixelformat = pix->pixelformat;
> +	pix_mp->field = pix->field;
> +	pix_mp->colorspace = pix->colorspace;
> +	pix_mp->plane_fmt[0].bytesperline = pix->bytesperline;
> +	pix_mp->plane_fmt[0].sizeimage = pix->sizeimage;
> +	pix_mp->num_planes = 1;
> +}
> +
> +static int s5p_jpeg_g_fmt_mplane(struct file *file, void *priv,
> +				 struct v4l2_format *f)
> +{
> +	struct v4l2_format tmp;
> +	int ret;
> +
> +	memset(&tmp, 0, sizeof(tmp));
> +	v4l2_format_pixmp_to_pix(f, &tmp);
> +	ret = s5p_jpeg_g_fmt(file, priv, &tmp);
> +	v4l2_format_pixmp_from_pix(f, &tmp);
> +
> +	return ret;
> +}
> +
> +static int s5p_jpeg_try_fmt_vid_cap_mplane(struct file *file, void *priv,
> +					   struct v4l2_format *f)
> +{
> +	struct v4l2_format tmp;
> +	int ret;
> +
> +	memset(&tmp, 0, sizeof(tmp));
> +	v4l2_format_pixmp_to_pix(f, &tmp);
> +	ret = s5p_jpeg_try_fmt_vid_cap(file, priv, &tmp);
> +	v4l2_format_pixmp_from_pix(f, &tmp);
> +
> +	return ret;
> +}
> +
> +static int s5p_jpeg_try_fmt_vid_out_mplane(struct file *file, void *priv,
> +					   struct v4l2_format *f)
> +{
> +	struct v4l2_format tmp;
> +	int ret;
> +
> +	memset(&tmp, 0, sizeof(tmp));
> +	v4l2_format_pixmp_to_pix(f, &tmp);
> +	ret = s5p_jpeg_try_fmt_vid_out(file, priv, &tmp);
> +	v4l2_format_pixmp_from_pix(f, &tmp);
> +
> +	return ret;
> +}
> +
> +static int s5p_jpeg_s_fmt_vid_cap_mplane(struct file *file, void *priv,
> +					 struct v4l2_format *f)
> +{
> +	struct v4l2_format tmp;
> +	int ret;
> +
> +	memset(&tmp, 0, sizeof(tmp));
> +	v4l2_format_pixmp_to_pix(f, &tmp);
> +	ret = s5p_jpeg_s_fmt_vid_cap(file, priv, &tmp);
> +	v4l2_format_pixmp_from_pix(f, &tmp);
> +
> +	return ret;
> +}
> +
> +static int s5p_jpeg_s_fmt_vid_out_mplane(struct file *file, void *priv,
> +					 struct v4l2_format *f)
> +{
> +	struct v4l2_format tmp;
> +	int ret;
> +
> +	memset(&tmp, 0, sizeof(tmp));
> +	v4l2_format_pixmp_to_pix(f, &tmp);
> +	ret = s5p_jpeg_s_fmt_vid_out(file, priv, &tmp);
> +	v4l2_format_pixmp_from_pix(f, &tmp);
> +
> +	return ret;
> +}
> +
>  static const struct v4l2_ioctl_ops s5p_jpeg_ioctl_ops = {
>  	.vidioc_querycap		= s5p_jpeg_querycap,
>  
> @@ -2133,6 +2244,18 @@ static const struct v4l2_ioctl_ops s5p_jpeg_ioctl_ops = {
>  	.vidioc_s_fmt_vid_cap		= s5p_jpeg_s_fmt_vid_cap,
>  	.vidioc_s_fmt_vid_out		= s5p_jpeg_s_fmt_vid_out,
>  
> +	.vidioc_enum_fmt_vid_cap_mplane	= s5p_jpeg_enum_fmt_vid_cap,
> +	.vidioc_enum_fmt_vid_out_mplane	= s5p_jpeg_enum_fmt_vid_out,
> +
> +	.vidioc_g_fmt_vid_cap_mplane	= s5p_jpeg_g_fmt_mplane,
> +	.vidioc_g_fmt_vid_out_mplane	= s5p_jpeg_g_fmt_mplane,
> +
> +	.vidioc_try_fmt_vid_cap_mplane	= s5p_jpeg_try_fmt_vid_cap_mplane,
> +	.vidioc_try_fmt_vid_out_mplane	= s5p_jpeg_try_fmt_vid_out_mplane,
> +
> +	.vidioc_s_fmt_vid_cap_mplane	= s5p_jpeg_s_fmt_vid_cap_mplane,
> +	.vidioc_s_fmt_vid_out_mplane	= s5p_jpeg_s_fmt_vid_out_mplane,
> +
>  	.vidioc_reqbufs			= v4l2_m2m_ioctl_reqbufs,
>  	.vidioc_querybuf		= v4l2_m2m_ioctl_querybuf,
>  	.vidioc_qbuf			= v4l2_m2m_ioctl_qbuf,
> @@ -2648,7 +2771,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
>  	struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
>  
>  	if (ctx->mode == S5P_JPEG_DECODE &&
> -	    vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> +	    vb->vb2_queue->type == ctx->out_q.type) {
>  		static const struct v4l2_event ev_src_ch = {
>  			.type = V4L2_EVENT_SOURCE_CHANGE,
>  			.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
> @@ -2657,8 +2780,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
>  		u32 ori_w;
>  		u32 ori_h;
>  
> -		dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
> -					 V4L2_BUF_TYPE_VIDEO_CAPTURE);
> +		dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, ctx->cap_q.type);
>  		ori_w = ctx->out_q.w;
>  		ori_h = ctx->out_q.h;
>  
> @@ -2708,7 +2830,7 @@ static void s5p_jpeg_stop_streaming(struct vb2_queue *q)
>  	 * subsampling. Update capture queue when the stream is off.
>  	 */
>  	if (ctx->state == JPEGCTX_RESOLUTION_CHANGE &&
> -	    q->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> +	    !V4L2_TYPE_IS_OUTPUT(q->type)) {
>  		s5p_jpeg_set_capture_queue_data(ctx);
>  		ctx->state = JPEGCTX_RUNNING;
>  	}
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h b/drivers/media/platform/s5p-jpeg/jpeg-core.h
> index 9aa26bd..302a297 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
> @@ -196,6 +196,7 @@ struct s5p_jpeg_marker {
>   * @sof_len:	SOF0 marker's payload length (without length field itself)
>   * @components:	number of image components
>   * @size:	image buffer size in bytes
> + * @type:	buffer type of the queue (enum v4l2_buf_type)
>   */
>  struct s5p_jpeg_q_data {
>  	struct s5p_jpeg_fmt	*fmt;
> @@ -208,6 +209,7 @@ struct s5p_jpeg_q_data {
>  	u32			sof_len;
>  	u32			components;
>  	u32			size;
> +	u32			type;
>  };
>  
>  /**
> 

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web