Re: [PATCH 2/3] doc-rst:c-domain: function-like macros arguments

[Markus Heiser]

Am 06.09.2016 um 14:27 schrieb Jonathan Corbet :

> So I'm going into total nit-picking territory here, but since I'm looking
> at it and I think the series needs a respin anyway...
> 
> On Wed, 31 Aug 2016 17:29:31 +0200
> Markus Heiser  wrote:
> 
>> +m = c_funcptr_sig_re.match(sig)
>> +if m is None:
>> +m = c_sig_re.match(sig)
>> +if m is None:
>> +raise ValueError('no match')
> 
> How about we put that second test inside the first if block and avoid the
> redundant None test if the first match works?  The energy saved may
> prevent a hurricane someday :)

And prohibit the MS-Windows update installer will save the climate ;)
It is a habit of mine to avoid indentations, but you are right,
it is not appropriate here.

>> +
>> +rettype, fullname, arglist, _const = m.groups()
>> +if rettype or not arglist.strip():
>> +return False
>> +
>> +arglist = arglist.replace('`', '').replace('\\ ', '').strip()  # 
>> remove markup
>> +arglist = [a.strip() for a in arglist.split(",")]
> 
> Similarly, stripping the args three times seems a bit much.  The middle
> one is totally redundant and could go at a minimum.

Thanks for pointing this. You are right, I will fix it.

-- Markus --

> 
> Thanks,
> 
> jon

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] vcodec: mediatek: fix odd_ptr_err.cocci warnings

[Tiffany Lin]

On Tue, 2016-09-06 at 22:51 +0800, Julia Lawall wrote:
> PTR_ERR should access the value just tested by IS_ERR
> 
> Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
> 
> CC: Tiffany Lin 
> Signed-off-by: Julia Lawall 
> Signed-off-by: Fengguang Wu 

Reviewed-by:Tiffany Lin 

> ---
> 
>  mtk_vcodec_dec_drv.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> @@ -255,7 +255,7 @@ static int mtk_vcodec_probe(struct platf
>   }
>   dev->reg_base[i] = devm_ioremap_resource(>dev, res);
>   if (IS_ERR((__force void *)dev->reg_base[i])) {
> - ret = PTR_ERR((__force void *)dev->reg_base);
> + ret = PTR_ERR((__force void *)dev->reg_base[i]);
>   goto err_res;
>   }
>   mtk_v4l2_debug(2, "reg[%d] base=%p", i, dev->reg_base[i]);


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Wed Sep  7 04:00:21 CEST 2016
git branch: test
git hash:   036bbb8213ecca49799217f30497dc0484178e53
gcc version:i686-linux-gcc (GCC) 5.4.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-i686: WARNINGS
linux-4.8-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-x86_64: OK
linux-4.8-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] v4l: vsp1: Add support for capture and output in HSV formats

[Laurent Pinchart]

Support both the HSV24 and HSV32 formats. From a hardware point of view
pretend the formats are RGB, the RPF and WPF will just pass the data
through without performing any processing.

Signed-off-by: Laurent Pinchart 
---

This patch is based on top of Ricardo's "[PATCH v5 00/12] Add HSV format"
series. I have tested it with the VSP test suite available at

git://git.ideasonboard.com/renesas/vsp-tests.git hsv

 drivers/media/platform/vsp1/vsp1_pipe.c  | 8 
 drivers/media/platform/vsp1/vsp1_rwpf.c  | 2 ++
 drivers/media/platform/vsp1/vsp1_video.c | 5 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 052a6037b9cb..c0b8641d2158 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -80,6 +80,14 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
  VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
  1, { 32, 0, 0 }, false, false, 1, 1, false },
+   { V4L2_PIX_FMT_HSV24, MEDIA_BUS_FMT_AHSV_1X32,
+ VI6_FMT_RGB_888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
+ VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
+ 1, { 24, 0, 0 }, false, false, 1, 1, false },
+   { V4L2_PIX_FMT_HSV32, MEDIA_BUS_FMT_AHSV_1X32,
+ VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
+ VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
+ 1, { 32, 0, 0 }, false, false, 1, 1, false },
{ V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
  VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c 
b/drivers/media/platform/vsp1/vsp1_rwpf.c
index 8d461b375e91..13e969ac1538 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
@@ -37,6 +37,7 @@ static int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev 
*subdev,
 {
static const unsigned int codes[] = {
MEDIA_BUS_FMT_ARGB_1X32,
+   MEDIA_BUS_FMT_AHSV_1X32,
MEDIA_BUS_FMT_AYUV8_1X32,
};
 
@@ -74,6 +75,7 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
 
/* Default to YUV if the requested format is not supported. */
if (fmt->format.code != MEDIA_BUS_FMT_ARGB_1X32 &&
+   fmt->format.code != MEDIA_BUS_FMT_AHSV_1X32 &&
fmt->format.code != MEDIA_BUS_FMT_AYUV8_1X32)
fmt->format.code = MEDIA_BUS_FMT_AYUV8_1X32;
 
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 7215e08eff6e..325377d7c444 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -126,6 +126,11 @@ static int __vsp1_video_try_format(struct vsp1_video 
*video,
pix->pixelformat = info->fourcc;
pix->colorspace = V4L2_COLORSPACE_SRGB;
pix->field = V4L2_FIELD_NONE;
+
+   if (info->fourcc == V4L2_PIX_FMT_HSV24 ||
+   info->fourcc == V4L2_PIX_FMT_HSV32)
+   pix->hsv_enc = V4L2_HSV_ENC_256;
+
memset(pix->reserved, 0, sizeof(pix->reserved));
 
/* Align the width and height for YUV 4:2:2 and 4:2:0 formats. */
-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] squash lines for simple wrapper functions

[Masahiro Yamada]

Remove unneeded variables and assignments.

Signed-off-by: Masahiro Yamada 
---

 drivers/media/dvb-core/dvb_frontend.c |  8 ++--
 drivers/media/pci/meye/meye.c |  5 +
 drivers/media/pci/ttpci/av7110.c  |  4 +---
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 17 +++--
 drivers/media/platform/ti-vpe/cal.c   |  6 +-
 drivers/media/rc/fintek-cir.c |  6 +-
 drivers/media/usb/dvb-usb-v2/lmedm04.c| 14 ++
 drivers/media/usb/dvb-usb/m920x.c | 10 +++---
 drivers/media/usb/gspca/jl2005bcd.c   |  5 +
 drivers/media/usb/gspca/sq905c.c  |  5 +
 10 files changed, 20 insertions(+), 60 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index be99c8d..43fcbb8 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -1515,12 +1515,8 @@ static int dtv_set_frontend(struct dvb_frontend *fe);
 
 static bool is_dvbv3_delsys(u32 delsys)
 {
-   bool status;
-
-   status = (delsys == SYS_DVBT) || (delsys == SYS_DVBC_ANNEX_A) ||
-(delsys == SYS_DVBS) || (delsys == SYS_ATSC);
-
-   return status;
+   return (delsys == SYS_DVBT) || (delsys == SYS_DVBC_ANNEX_A) ||
+  (delsys == SYS_DVBS) || (delsys == SYS_ATSC);
 }
 
 /**
diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
index ba887e8..7727d59 100644
--- a/drivers/media/pci/meye/meye.c
+++ b/drivers/media/pci/meye/meye.c
@@ -587,10 +587,7 @@ static void mchip_hic_stop(void)
 /* get the next ready frame from the dma engine */
 static u32 mchip_get_frame(void)
 {
-   u32 v;
-
-   v = mchip_read(MCHIP_MM_FIR(meye.mchip_fnum));
-   return v;
+   return mchip_read(MCHIP_MM_FIR(meye.mchip_fnum));
 }
 
 /* frees the current frame from the dma engine */
diff --git a/drivers/media/pci/ttpci/av7110.c b/drivers/media/pci/ttpci/av7110.c
index 382caf2..aee26af 100644
--- a/drivers/media/pci/ttpci/av7110.c
+++ b/drivers/media/pci/ttpci/av7110.c
@@ -2930,9 +2930,7 @@ static struct saa7146_extension av7110_extension_driver = 
{
 
 static int __init av7110_init(void)
 {
-   int retval;
-   retval = saa7146_register_extension(_extension_driver);
-   return retval;
+   return saa7146_register_extension(_extension_driver);
 }
 
 
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index 0912d0a..a1d823a 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -178,20 +178,12 @@ void exynos4_jpeg_set_interrupt(void __iomem *base, 
unsigned int version)
 
 unsigned int exynos4_jpeg_get_int_status(void __iomem *base)
 {
-   unsigned intint_status;
-
-   int_status = readl(base + EXYNOS4_INT_STATUS_REG);
-
-   return int_status;
+   return readl(base + EXYNOS4_INT_STATUS_REG);
 }
 
 unsigned int exynos4_jpeg_get_fifo_status(void __iomem *base)
 {
-   unsigned int fifo_status;
-
-   fifo_status = readl(base + EXYNOS4_FIFO_STATUS_REG);
-
-   return fifo_status;
+   return readl(base + EXYNOS4_FIFO_STATUS_REG);
 }
 
 void exynos4_jpeg_set_huf_table_enable(void __iomem *base, int value)
@@ -296,10 +288,7 @@ void exynos4_jpeg_set_encode_hoff_cnt(void __iomem *base, 
unsigned int fmt)
 
 unsigned int exynos4_jpeg_get_stream_size(void __iomem *base)
 {
-   unsigned int size;
-
-   size = readl(base + EXYNOS4_BITSTREAM_SIZE_REG);
-   return size;
+   return readl(base + EXYNOS4_BITSTREAM_SIZE_REG);
 }
 
 void exynos4_jpeg_set_dec_bitstream_size(void __iomem *base, unsigned int size)
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index e967fcf..2a9de42 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -483,11 +483,7 @@ static void cal_get_hwinfo(struct cal_dev *dev)
 
 static inline int cal_runtime_get(struct cal_dev *dev)
 {
-   int r;
-
-   r = pm_runtime_get_sync(>pdev->dev);
-
-   return r;
+   return pm_runtime_get_sync(>pdev->dev);
 }
 
 static inline void cal_runtime_put(struct cal_dev *dev)
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index bd7b3bd..ecab69e 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -104,11 +104,7 @@ static inline void fintek_cir_reg_write(struct fintek_dev 
*fintek, u8 val, u8 of
 /* read val from cir config register */
 static u8 fintek_cir_reg_read(struct fintek_dev *fintek, u8 offset)
 {
-   u8 val;
-
-   val = inb(fintek->cir_addr + offset);
-
-   return val;
+   return inb(fintek->cir_addr + offset);
 }
 
 /* dump current cir register contents */
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c 

Re: [PATCHv2 2/2] v4l: vsp1: Add HGT support

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday 06 Sep 2016 16:38:56 Niklas Söderlund wrote:
> The HGT is a Histogram Generator Two-Dimensions. It computes a weighted
> frequency histograms for hue and saturation areas over a configurable
> region of the image with optional subsampling.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/vsp1/Makefile  |   2 +-
>  drivers/media/platform/vsp1/vsp1.h|   3 +
>  drivers/media/platform/vsp1/vsp1_drv.c|  33 -
>  drivers/media/platform/vsp1/vsp1_entity.c |  33 +++--
>  drivers/media/platform/vsp1/vsp1_entity.h |   1 +
>  drivers/media/platform/vsp1/vsp1_hgt.c| 217 +++
>  drivers/media/platform/vsp1/vsp1_hgt.h|  42 ++
>  drivers/media/platform/vsp1/vsp1_pipe.c   |  16 +++
>  drivers/media/platform/vsp1/vsp1_pipe.h   |   2 +
>  drivers/media/platform/vsp1/vsp1_regs.h   |   9 ++
>  drivers/media/platform/vsp1/vsp1_video.c  |  10 +-
>  11 files changed, 352 insertions(+), 16 deletions(-)
>  create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
>  create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h

[snip]

> diff --git a/drivers/media/platform/vsp1/vsp1_hgt.c
> b/drivers/media/platform/vsp1/vsp1_hgt.c new file mode 100644
> index 000..4e3f762
> --- /dev/null
> +++ b/drivers/media/platform/vsp1/vsp1_hgt.c

[snip]

> +/* 
> + * Controls
> + */
> +
> +#define V4L2_CID_VSP1_HGT_HUE_AREAS  (V4L2_CID_USER_BASE | 0x1001)
> +
> +static int hgt_hue_areas_s_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct vsp1_hgt *hgt = container_of(ctrl->handler, struct vsp1_hgt,
> + ctrls);
> + u8 *value = ctrl->p_new.p_u8;

Nitpicking, I'd call the variable values.

> + unsigned int i;
> + bool ok = true;
> +
> + /*
> +  * Make sure values meet one of two possible hardware constrains

s/constrains/constraints./

> +  * 0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 
5U
> +  * 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 
0L
> +  */
> +
> + if ((value[0] > value[1]) && (value[11] > value[0]))
> + ok = false;
> + for (i = 1; i < (HGT_NUM_HUE_AREAS * 2) - 1; ++i)
> + if (value[i] > value[i+1])
> + ok = false;
> +
> + /* Values do not match hardware, adjust to valid settings. */
> + if (!ok) {
> + for (i = 0; i < (HGT_NUM_HUE_AREAS * 2) - 1; ++i) {
> + if (value[i] > value[i+1])
> + value[i] = value[i+1];
> + }
> + }

I'm afraid this won't work. Let's assume value[0] = 100, value[1] = 50, 
value[2] = 25. The loop will unroll to

if (value[0] /* 100 */ > value[1] /* 50 */)
value[0] = value[1] /* 50 */;
if (value[1] /* 50 */ > value[2] /* 25 */)
value[1] = value[2] /* 25 */;

You will end up with value[0] = 50, value[1] = 25, value[2] = 25, which 
doesn't match the hardware constraints.

How about the following, which tests and fixes the values in a single 
operation ?

static int hgt_hue_areas_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct vsp1_hgt *hgt = container_of(ctrl->handler, struct vsp1_hgt,
ctrls);
u8 *values = ctrl->p_new.p_u8;
unsigned int i;

/*
 * Adjust the values if they don't meet the hardware constraints:
 *
 * 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U
 */ 
for (i = 1; i < (HGT_NUM_HUE_AREAS * 2) - 1; ++i) {
if (values[i] > values[i+1])
values[i+1] = values[i];
}

/* 0L <= 0U or 5U <= 0L */
if (values[0] > values[1] && values[11] > values[0])
values[0] = values[1];

memcpy(hgt->hue_areas, ctrl->p_new.p_u8, sizeof(hgt->hue_areas));

return 0;
}

I'm also beginning to wonder whether it wouldn't make sense to return -EINVAL 
when the values don't match the constraints instead of trying to fix them.

> + memcpy(hgt->hue_areas, ctrl->p_new.p_u8, sizeof(hgt->hue_areas));
> +
> + return 0;
> +}

[snip]

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 3/4] pulse8-cec: add notes about behavior in autonomous mode

[Mauro Carvalho Chehab]

Em Mon, 22 Aug 2016 11:04:53 +0200
Johan Fjeldtvedt  escreveu:

> The pulse8 dongle has some quirky behaviors when in autonomous mode.
> Document these.
> 
> Signed-off-by: Johan Fjeldtvedt 

While it is ok to add this at a note on the driver, IMHO, the best would
be to write a rst file for this driver, when it moves from staging,
adding those notes there too.

Regards,
Mauro

> ---
>  drivers/staging/media/pulse8-cec/pulse8-cec.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/staging/media/pulse8-cec/pulse8-cec.c 
> b/drivers/staging/media/pulse8-cec/pulse8-cec.c
> index 37c8418..aa679a3 100644
> --- a/drivers/staging/media/pulse8-cec/pulse8-cec.c
> +++ b/drivers/staging/media/pulse8-cec/pulse8-cec.c
> @@ -10,6 +10,29 @@
>   * this archive for more details.
>   */
>  
> +/*
> + * Notes:
> + *
> + * - Devices with firmware version < 2 do not store their configuration in
> + *   EEPROM.
> + *
> + * - In autonomous mode, only messages from a TV will be acknowledged, even
> + *   polling messages. Upon receiving a message from a TV, the dongle will
> + *   respond to messages from any logical address.
> + *
> + * - In autonomous mode, the dongle will by default reply Feature Abort
> + *   [Unrecognized Opcode] when it receives Give Device Vendor ID. It will
> + *   however observe vendor ID's reported by other devices and possibly
> + *   alter this behavior. When TV's (and TV's only) report that their vendor 
> ID
> + *   is LG (0x00e091), the dongle will itself reply that it has the same 
> vendor
> + *   ID, and it will respond to at least one vendor specific command.
> + *
> + * - In autonomous mode, the dongle is known to attempt wakeup if it receives
> + *["Power On"], ["Power] or ["Power Toggle"], or 
> if it
> + *   receives  with its own physical address. It also does 
> this
> + *   if it receives  [0x03 0x00] from an LG TV.
> + */
> +
>  #include 
>  #include 
>  #include 



Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Nicolas Dufresne]

Le mercredi 20 juillet 2016 à 16:20 +0300, Sakari Ailus a écrit :
> Hi Javier,
> 
> On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas
> wrote:
> > The buffer planes' dma-buf are currently mapped when buffers are queued
> > from userspace but it's more appropriate to do the mapping when buffers
> > are queued in the driver since that's when the actual DMA operation are
> > going to happen.
> > 
> > Suggested-by: Nicolas Dufresne 
> > Signed-off-by: Javier Martinez Canillas 
> > 
> > ---
> > 
> > Hello,
> > 
> > A side effect of this change is that if the dmabuf map fails for some
> > reasons (i.e: a driver using the DMA contig memory allocator but CMA
> > not being enabled), the fail will no longer happen on VIDIOC_QBUF but
> > later (i.e: in VIDIOC_STREAMON).
> > 
> > I don't know if that's an issue though but I think is worth mentioning.
> 
> I have the same question has Hans --- why?
> 
> I rather think we should keep the buffers mapped all the time. That'd
> require a bit of extra from the DMA-BUF framework I suppose, to support
> streaming mappings.
> 
> The reason for that is performance. If you're passing the buffer between a
> couple of hardware devices, there's no need to map and unmap it every time
> the buffer is accessed by the said devices. That'd avoid an unnecessary
> cache flush as well, something that tends to be quite expensive. On a PC
> with resolutions typically used on webcams that might not really matter. But
> if you have an embedded system with a relatively modest 10 MP camera sensor,
> it's one of the first things you'll notice if you check where the CPU time
> is being spent.

That is very interesting since the initial discussion started from the
idea of adding an implicit fence wait to the map operation. This way we
could have a dma-buf fence attached without having to modify the
drivers to support it. Buffer handles could be dispatched before there
is any data in it. Though, if we keep it mapped, I believe this idea is
simply incompatible and fences should remain explicit for extra
flexibility.

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Nicolas Dufresne]

Le lundi 18 juillet 2016 à 12:27 +0200, Marek Szyprowski a écrit :
> Hello,
> 
> 
> On 2016-07-15 18:26, Javier Martinez Canillas wrote:
> > The buffer planes' dma-buf are currently mapped when buffers are queued
> > from userspace but it's more appropriate to do the mapping when buffers
> > are queued in the driver since that's when the actual DMA operation are
> > going to happen.
> > 
> > Suggested-by: Nicolas Dufresne 
> > Signed-off-by: Javier Martinez Canillas 
> 
> Sorry, but I don't get why such change is really needed. If possible it is
> better to report errors to userspace as early as possible, not postpone them
> to the moment, when they cannot be easily debugged.

Postponing errors is not the goal. It's an unwanted side effect of this
proposed patch (should have been marque RFQ, as Javier corrected). A
correct solution would figure-out the error without paying the cost of
mapping the memory (which is often expensive).

> 
> > 
> > ---
> > 
> > Hello,
> > 
> > A side effect of this change is that if the dmabuf map fails for
> > some
> > reasons (i.e: a driver using the DMA contig memory allocator but
> > CMA
> > not being enabled), the fail will no longer happen on VIDIOC_QBUF
> > but
> > later (i.e: in VIDIOC_STREAMON).
> > 
> > I don't know if that's an issue though but I think is worth
> > mentioning.
> > 
> > Best regards,
> > Javier
> > 
> >   drivers/media/v4l2-core/videobuf2-core.c | 88
> > 
> >   1 file changed, 54 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index ca8ffeb56d72..3fdf882bf279 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -186,7 +186,7 @@ module_param(debug, int, 0644);
> >   })
> >   
> >   static void __vb2_queue_cancel(struct vb2_queue *q);
> > -static void __enqueue_in_driver(struct vb2_buffer *vb);
> > +static int __enqueue_in_driver(struct vb2_buffer *vb);
> >   
> >   /**
> >    * __vb2_buf_mem_alloc() - allocate video memory for the given
> > buffer
> > @@ -1271,20 +1271,6 @@ static int __qbuf_dmabuf(struct vb2_buffer
> > *vb, const void *pb)
> >     vb->planes[plane].mem_priv = mem_priv;
> >     }
> >   
> > -   /* TODO: This pins the buffer(s)
> > with  dma_buf_map_attachment()).. but
> > -    * really we want to do this just before the DMA, not
> > while queueing
> > -    * the buffer(s)..
> > -    */
> > -   for (plane = 0; plane < vb->num_planes; ++plane) {
> > -   ret = call_memop(vb, map_dmabuf, vb-
> > >planes[plane].mem_priv);
> > -   if (ret) {
> > -   dprintk(1, "failed to map dmabuf for plane
> > %d\n",
> > -   plane);
> > -   goto err;
> > -   }
> > -   vb->planes[plane].dbuf_mapped = 1;
> > -   }
> > -
> >     /*
> >      * Now that everything is in order, copy relevant
> > information
> >      * provided by userspace.
> > @@ -1296,51 +1282,79 @@ static int __qbuf_dmabuf(struct vb2_buffer
> > *vb, const void *pb)
> >     vb->planes[plane].data_offset =
> > planes[plane].data_offset;
> >     }
> >   
> > -   if (reacquired) {
> > -   /*
> > -    * Call driver-specific initialization on the
> > newly acquired buffer,
> > -    * if provided.
> > -    */
> > -   ret = call_vb_qop(vb, buf_init, vb);
> > +   return 0;
> > +err:
> > +   /* In case of errors, release planes that were already
> > acquired */
> > +   __vb2_buf_dmabuf_put(vb);
> > +
> > +   return ret;
> > +}
> > +
> > +/**
> > + * __buf_map_dmabuf() - map dmabuf for buffer planes
> > + */
> > +static int __buf_map_dmabuf(struct vb2_buffer *vb)
> > +{
> > +   int ret;
> > +   unsigned int plane;
> > +
> > +   for (plane = 0; plane < vb->num_planes; ++plane) {
> > +   ret = call_memop(vb, map_dmabuf, vb-
> > >planes[plane].mem_priv);
> >     if (ret) {
> > -   dprintk(1, "buffer initialization
> > failed\n");
> > -   goto err;
> > +   dprintk(1, "failed to map dmabuf for plane
> > %d\n",
> > +   plane);
> > +   return ret;
> >     }
> > +   vb->planes[plane].dbuf_mapped = 1;
> > +   }
> > +
> > +   /*
> > +    * Call driver-specific initialization on the newly
> > +    * acquired buffer, if provided.
> > +    */
> > +   ret = call_vb_qop(vb, buf_init, vb);
> > +   if (ret) {
> > +   dprintk(1, "buffer initialization failed\n");
> > +   return ret;
> >     }
> >   
> >     ret = call_vb_qop(vb, buf_prepare, vb);
> >     if (ret) {
> >     dprintk(1, "buffer preparation failed\n");
> >     call_void_vb_qop(vb, buf_cleanup, vb);
> > -   goto err;
> > +   return ret;
> >     }
> >   
> >     return 0;
> > -err:
> > -   /* In case of 

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Nicolas Dufresne]

Le lundi 18 juillet 2016 à 10:34 +0200, Hans Verkuil a écrit :
> On 07/15/2016 06:26 PM, Javier Martinez Canillas wrote:
> > The buffer planes' dma-buf are currently mapped when buffers are queued
> > from userspace but it's more appropriate to do the mapping when buffers
> > are queued in the driver since that's when the actual DMA operation are
> > going to happen.
> 
> Does this solve anything? Once the DMA has started the behavior is the same
> as before (QBUF maps the dmabuf), only while the DMA engine hasn't started
> yet are the QBUF calls just accepted and the mapping takes place when the
> DMA is kickstarted. This makes QBUF behave inconsistently.

The reflection (yes it's just a reflection) is that userspace won't
have to wait for the map before it can go back on retrieving and
submitting the next buffer. I think this could help userspace ability
to fill in the queue on time, without having to introduce threads to
protect against long kernel operations. Basically, it may improve
parallelism between userspace and kernel.

> 
> You don't describe here WHY this change is needed.
> 
> I'm not sure I agree with the TODO, and even if I did, I'm not sure I agree
> with this solution. Since queuing the buffer to the driver is not the same
> as 'just before the DMA', since there may be many buffers queued up in the
> driver and you don't know in vb2 when the buffer is at the 'just before the 
> DMA'
> stage.
> 
> Regards,
> 
>   Hans
> 
> > 
> > Suggested-by: Nicolas Dufresne 
> > Signed-off-by: Javier Martinez Canillas 
> > 
> > ---
> > 
> > Hello,
> > 
> > A side effect of this change is that if the dmabuf map fails for
> > some
> > reasons (i.e: a driver using the DMA contig memory allocator but
> > CMA
> > not being enabled), the fail will no longer happen on VIDIOC_QBUF
> > but
> > later (i.e: in VIDIOC_STREAMON).
> > 
> > I don't know if that's an issue though but I think is worth
> > mentioning.
> > 
> > Best regards,
> > Javier
> > 
> >  drivers/media/v4l2-core/videobuf2-core.c | 88
> > 
> >  1 file changed, 54 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index ca8ffeb56d72..3fdf882bf279 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -186,7 +186,7 @@ module_param(debug, int, 0644);
> >  })
> >  
> >  static void __vb2_queue_cancel(struct vb2_queue *q);
> > -static void __enqueue_in_driver(struct vb2_buffer *vb);
> > +static int __enqueue_in_driver(struct vb2_buffer *vb);
> >  
> >  /**
> >   * __vb2_buf_mem_alloc() - allocate video memory for the given
> > buffer
> > @@ -1271,20 +1271,6 @@ static int __qbuf_dmabuf(struct vb2_buffer
> > *vb, const void *pb)
> >     vb->planes[plane].mem_priv = mem_priv;
> >     }
> >  
> > -   /* TODO: This pins the buffer(s)
> > with  dma_buf_map_attachment()).. but
> > -    * really we want to do this just before the DMA, not
> > while queueing
> > -    * the buffer(s)..
> > -    */
> > -   for (plane = 0; plane < vb->num_planes; ++plane) {
> > -   ret = call_memop(vb, map_dmabuf, vb-
> > >planes[plane].mem_priv);
> > -   if (ret) {
> > -   dprintk(1, "failed to map dmabuf for plane
> > %d\n",
> > -   plane);
> > -   goto err;
> > -   }
> > -   vb->planes[plane].dbuf_mapped = 1;
> > -   }
> > -
> >     /*
> >      * Now that everything is in order, copy relevant
> > information
> >      * provided by userspace.
> > @@ -1296,51 +1282,79 @@ static int __qbuf_dmabuf(struct vb2_buffer
> > *vb, const void *pb)
> >     vb->planes[plane].data_offset =
> > planes[plane].data_offset;
> >     }
> >  
> > -   if (reacquired) {
> > -   /*
> > -    * Call driver-specific initialization on the
> > newly acquired buffer,
> > -    * if provided.
> > -    */
> > -   ret = call_vb_qop(vb, buf_init, vb);
> > +   return 0;
> > +err:
> > +   /* In case of errors, release planes that were already
> > acquired */
> > +   __vb2_buf_dmabuf_put(vb);
> > +
> > +   return ret;
> > +}
> > +
> > +/**
> > + * __buf_map_dmabuf() - map dmabuf for buffer planes
> > + */
> > +static int __buf_map_dmabuf(struct vb2_buffer *vb)
> > +{
> > +   int ret;
> > +   unsigned int plane;
> > +
> > +   for (plane = 0; plane < vb->num_planes; ++plane) {
> > +   ret = call_memop(vb, map_dmabuf, vb-
> > >planes[plane].mem_priv);
> >     if (ret) {
> > -   dprintk(1, "buffer initialization
> > failed\n");
> > -   goto err;
> > +   dprintk(1, "failed to map dmabuf for plane
> > %d\n",
> > +   plane);
> > +   return ret;
> >     }
> > +   vb->planes[plane].dbuf_mapped = 1;
> > +   }
> > +
> > +   /*

Re: [PATCH v2 2/4] v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine

[Mauro Carvalho Chehab]

Em Tue, 06 Sep 2016 21:11:10 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Tuesday 06 Sep 2016 14:06:51 Mauro Carvalho Chehab wrote:
> > Em Wed, 17 Aug 2016 15:20:28 +0300 Laurent Pinchart escreveu:  
> > > The format is used on the R-Car VSP1 video queues that carry
> > > 1-D histogram statistics data.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > > Acked-by: Sakari Ailus 
> > > ---
> > > Changes since v1:
> > > 
> > > - Rebased on top of the DocBook to reST conversion
> > > 
> > >  Documentation/media/uapi/v4l/meta-formats.rst  |  15 ++
> > >  .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 170 
> > >  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
> > >  drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
> > >  include/uapi/linux/videodev2.h |   3 +
> > >  5 files changed, 190 insertions(+)
> > >  create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst
> > >  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> > > 
> > > diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> > > b/Documentation/media/uapi/v4l/meta-formats.rst new file mode 100644
> > > index ..05ab91e12f10
> > > --- /dev/null
> > > +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> > > @@ -0,0 +1,15 @@
> > > +.. -*- coding: utf-8; mode: rst -*-
> > > +
> > > +.. _meta-formats:
> > > +
> > > +
> > > +Metadata Formats
> > > +
> > > +
> > > +These formats are used for the :ref:`metadata` interface only.
> > > +
> > > +
> > > +.. toctree::
> > > +:maxdepth: 1
> > > +
> > > +pixfmt-meta-vsp1-hgo
> > > diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> > > b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst new file mode
> > > 100644
> > > index ..e935e4525b10
> > > --- /dev/null
> > > +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> > > @@ -0,0 +1,170 @@
> > > +.. -*- coding: utf-8; mode: rst -*-
> > > +
> > > +.. _v4l2-meta-fmt-vsp1-hgo:
> > > +
> > > +***
> > > +V4L2_META_FMT_VSP1_HGO ('VSPH')
> > > +***
> > > +
> > > +*man V4L2_META_FMT_VSP1_HGO(2)*  
> > 
> > Just remove it. This is some trash that came from the conversions.
> > I have a set of patches removing it on the existing man pages.  
> 
> Sure, I will do.

Thanks!

> > > +
> > > +Renesas R-Car VSP1 1-D Histogram Data
> > > +
> > > +
> > > +Description
> > > +===
> > > +
> > > +This format describes histogram data generated by the Renesas R-Car VSP1
> > > 1-D +Histogram (HGO) engine.
> > > +
> > > +The VSP1 HGO is a histogram computation engine that can operate on RGB,
> > > YCrCb +or HSV data. It operates on a possibly cropped and subsampled
> > > input image and +computes the minimum, maximum and sum of all pixels as
> > > well as per-channel +histograms.
> > > +
> > > +The HGO can compute histograms independently per channel, on the maximum
> > > of the +three channels (RGB data only) or on the Y channel only (YCbCr
> > > only). It can +additionally output the histogram with 64 or 256 bins,
> > > resulting in four +possible modes of operation.
> > > +
> > > +- In *64 bins normal mode*, the HGO operates on the three channels
> > > independently +  to compute three 64-bins histograms. RGB, YCbCr and HSV
> > > image formats are +  supported.
> > > +- In *64 bins maximum mode*, the HGO operates on the maximum of the (R,
> > > G, B) +  channels to compute a single 64-bins histogram. Only the RGB
> > > image format is +  supported.
> > > +- In *256 bins normal mode*, the HGO operates on the Y channel to compute
> > > a +  single 256-bins histogram. Only the YCbCr image format is supported.
> > > +- In *256 bins maximum mode*, the HGO operates on the maximum of the (R,
> > > G, B) +  channels to compute a single 256-bins histogram. Only the RGB
> > > image format is +  supported.  
> > 
> > As they all share the same FOURCC format, according with the documentation,
> > how the user is supposed to switch between those modes? Or is it depend on
> > the video format? In any case, please add some explanation, and cross-refs
> > if needed.  
> 
> The modes are selected using controls, they don't depend on the video format. 
> Do you think it would make sense to cross-reference between formats and 
> controls ?

It probably makes a way more sense to use enum_fmt/s_fmt/g_fmt ioctls and
add one different fourcc per format.

Using a control instead of *fmt to select the format seems really weird,
as it is not what it is expected for the fourcc formats.


Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine

[Laurent Pinchart]

Hi Mauro,

On Tuesday 06 Sep 2016 14:06:51 Mauro Carvalho Chehab wrote:
> Em Wed, 17 Aug 2016 15:20:28 +0300 Laurent Pinchart escreveu:
> > The format is used on the R-Car VSP1 video queues that carry
> > 1-D histogram statistics data.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > Acked-by: Sakari Ailus 
> > ---
> > Changes since v1:
> > 
> > - Rebased on top of the DocBook to reST conversion
> > 
> >  Documentation/media/uapi/v4l/meta-formats.rst  |  15 ++
> >  .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 170 
> >  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
> >  drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
> >  include/uapi/linux/videodev2.h |   3 +
> >  5 files changed, 190 insertions(+)
> >  create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst
> >  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> > 
> > diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> > b/Documentation/media/uapi/v4l/meta-formats.rst new file mode 100644
> > index ..05ab91e12f10
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> > @@ -0,0 +1,15 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _meta-formats:
> > +
> > +
> > +Metadata Formats
> > +
> > +
> > +These formats are used for the :ref:`metadata` interface only.
> > +
> > +
> > +.. toctree::
> > +:maxdepth: 1
> > +
> > +pixfmt-meta-vsp1-hgo
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> > b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst new file mode
> > 100644
> > index ..e935e4525b10
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> > @@ -0,0 +1,170 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _v4l2-meta-fmt-vsp1-hgo:
> > +
> > +***
> > +V4L2_META_FMT_VSP1_HGO ('VSPH')
> > +***
> > +
> > +*man V4L2_META_FMT_VSP1_HGO(2)*
> 
> Just remove it. This is some trash that came from the conversions.
> I have a set of patches removing it on the existing man pages.

Sure, I will do.

> > +
> > +Renesas R-Car VSP1 1-D Histogram Data
> > +
> > +
> > +Description
> > +===
> > +
> > +This format describes histogram data generated by the Renesas R-Car VSP1
> > 1-D +Histogram (HGO) engine.
> > +
> > +The VSP1 HGO is a histogram computation engine that can operate on RGB,
> > YCrCb +or HSV data. It operates on a possibly cropped and subsampled
> > input image and +computes the minimum, maximum and sum of all pixels as
> > well as per-channel +histograms.
> > +
> > +The HGO can compute histograms independently per channel, on the maximum
> > of the +three channels (RGB data only) or on the Y channel only (YCbCr
> > only). It can +additionally output the histogram with 64 or 256 bins,
> > resulting in four +possible modes of operation.
> > +
> > +- In *64 bins normal mode*, the HGO operates on the three channels
> > independently +  to compute three 64-bins histograms. RGB, YCbCr and HSV
> > image formats are +  supported.
> > +- In *64 bins maximum mode*, the HGO operates on the maximum of the (R,
> > G, B) +  channels to compute a single 64-bins histogram. Only the RGB
> > image format is +  supported.
> > +- In *256 bins normal mode*, the HGO operates on the Y channel to compute
> > a +  single 256-bins histogram. Only the YCbCr image format is supported.
> > +- In *256 bins maximum mode*, the HGO operates on the maximum of the (R,
> > G, B) +  channels to compute a single 256-bins histogram. Only the RGB
> > image format is +  supported.
> 
> As they all share the same FOURCC format, according with the documentation,
> how the user is supposed to switch between those modes? Or is it depend on
> the video format? In any case, please add some explanation, and cross-refs
> if needed.

The modes are selected using controls, they don't depend on the video format. 
Do you think it would make sense to cross-reference between formats and 
controls ?

[snip]

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v4l: vsp1: Move subdev operations from HGO to common histogram code

[Laurent Pinchart]

Hi Niklas,

On Tuesday 06 Sep 2016 12:28:00 Niklas Söderlund wrote:
> On 2016-09-05 18:13:39 +0300, Laurent Pinchart wrote:
> > The code will be shared with the HGT entity, move it to the generic
> > histogram implementation.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/media/platform/vsp1/vsp1_drv.c   |   7 +-
> >  drivers/media/platform/vsp1/vsp1_hgo.c   | 308 ++---
> >  drivers/media/platform/vsp1/vsp1_hgo.h   |   7 +-
> >  drivers/media/platform/vsp1/vsp1_histo.c | 334 +++--
> >  drivers/media/platform/vsp1/vsp1_histo.h |  25 ++-
> >  5 files changed, 355 insertions(+), 326 deletions(-)

[snip]

> > @@ -268,7 +559,16 @@ int vsp1_histogram_init(struct vsp1_device *vsp1,
> > struct vsp1_histogram *histo,> 
> > INIT_LIST_HEAD(>irqqueue);
> > init_waitqueue_head(>wait_queue);
> > 
> > -   /* Initialize the media entity... */
> > +   /* Initialize the VSP entity... */
> > +   histo->entity.ops = ops;
> > +   histo->entity.type = type;
> > +
> > +   ret = vsp1_entity_init(vsp1, >entity, name, 2, _ops,
> > +  MEDIA_ENT_F_PROC_VIDEO_STATISTICS);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   /* ... and the media entity... */
> > ret = media_entity_pads_init(>video.entity, 1, >pad);
> > if (ret < 0)
> > return ret;
> 
> You forgot to update the histo video device name to match the subdevice
> name here. Something like this makes vsp-tests work for me again.
> 
> @@ -577,7 +577,7 @@ int vsp1_histogram_init(struct vsp1_device *vsp1, struct
> vsp1_histogram *histo, histo->video.v4l2_dev = >v4l2_dev;
> histo->video.fops = _v4l2_fops;
> snprintf(histo->video.name, sizeof(histo->video.name),
> -"%s histo", name);
> +"%s histo", histo->entity.subdev.name);
> histo->video.vfl_type = VFL_TYPE_GRABBER;
> histo->video.release = video_device_release_empty;
> histo->video.ioctl_ops = _v4l2_ioctl_ops;
> 
> Without this fix the names listed using media-ctl -p show:
> 
> - entity 1: hgo histo (1 pad, 1 link)
> 
> Instead as it did before:
> 
> - entity 1: fe928000.vsp1 hgo histo (1 pad, 1 link)
> 
> Other then that
> 
> Tested-by: Niklas Söderlund 

Thank you. I'll fix that in the next version.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine

[Mauro Carvalho Chehab]

Hi Laurent,

Em Wed, 17 Aug 2016 15:20:28 +0300
Laurent Pinchart  escreveu:

> The format is used on the R-Car VSP1 video queues that carry
> 1-D histogram statistics data.
> 
> Signed-off-by: Laurent Pinchart 
> Acked-by: Sakari Ailus 
> ---
> Changes since v1:
> 
> - Rebased on top of the DocBook to reST conversion
> 
>  Documentation/media/uapi/v4l/meta-formats.rst  |  15 ++
>  .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 170 
> +
>  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
>  drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
>  include/uapi/linux/videodev2.h |   3 +
>  5 files changed, 190 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> 
> diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
> b/Documentation/media/uapi/v4l/meta-formats.rst
> new file mode 100644
> index ..05ab91e12f10
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> @@ -0,0 +1,15 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _meta-formats:
> +
> +
> +Metadata Formats
> +
> +
> +These formats are used for the :ref:`metadata` interface only.
> +
> +
> +.. toctree::
> +:maxdepth: 1
> +
> +pixfmt-meta-vsp1-hgo
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst 
> b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> new file mode 100644
> index ..e935e4525b10
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
> @@ -0,0 +1,170 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _v4l2-meta-fmt-vsp1-hgo:
> +
> +***
> +V4L2_META_FMT_VSP1_HGO ('VSPH')
> +***
> +
> +*man V4L2_META_FMT_VSP1_HGO(2)*

Just remove it. This is some trash that came from the conversions.
I have a set of patches removing it on the existing man pages.

> +
> +Renesas R-Car VSP1 1-D Histogram Data
> +
> +
> +Description
> +===
> +
> +This format describes histogram data generated by the Renesas R-Car VSP1 1-D
> +Histogram (HGO) engine.
> +
> +The VSP1 HGO is a histogram computation engine that can operate on RGB, YCrCb
> +or HSV data. It operates on a possibly cropped and subsampled input image and
> +computes the minimum, maximum and sum of all pixels as well as per-channel
> +histograms.
> +
> +The HGO can compute histograms independently per channel, on the maximum of 
> the
> +three channels (RGB data only) or on the Y channel only (YCbCr only). It can
> +additionally output the histogram with 64 or 256 bins, resulting in four
> +possible modes of operation.
> +
> +- In *64 bins normal mode*, the HGO operates on the three channels 
> independently
> +  to compute three 64-bins histograms. RGB, YCbCr and HSV image formats are
> +  supported.
> +- In *64 bins maximum mode*, the HGO operates on the maximum of the (R, G, B)
> +  channels to compute a single 64-bins histogram. Only the RGB image format 
> is
> +  supported.
> +- In *256 bins normal mode*, the HGO operates on the Y channel to compute a
> +  single 256-bins histogram. Only the YCbCr image format is supported.
> +- In *256 bins maximum mode*, the HGO operates on the maximum of the (R, G, 
> B)
> +  channels to compute a single 256-bins histogram. Only the RGB image format 
> is
> +  supported.

As they all share the same FOURCC format, according with the documentation,
how the user is supposed to switch between those modes? Or is it depend on
the video format? In any case, please add some explanation, and cross-refs
if needed.

> +
> +**Byte Order.**
> +All data is stored in memory in little endian format. Each cell in the tables
> +contains one byte.
> +
> +.. flat-table:: VSP1 HGO Data - 64 Bins, Normal Mode (792 bytes)
> +:header-rows:  2
> +:stub-columns: 0
> +
> +* - Offset
> +  - :cspan:`4` Memory
> +* -
> +  - [31:24]
> +  - [23:16]
> +  - [15:8]
> +  - [7:0]
> +* - 0
> +  - -
> +  - R/Cr/H max [7:0]
> +  - -
> +  - R/Cr/H min [7:0]
> +* - 4
> +  - -
> +  - G/Y/S max [7:0]
> +  - -
> +  - G/Y/S min [7:0]
> +* - 8
> +  - -
> +  - B/Cb/V max [7:0]
> +  - -
> +  - B/Cb/V min [7:0]
> +* - 12
> +  - :cspan:`4` R/Cr/H sum [31:0]
> +* - 16
> +  - :cspan:`4` G/Y/S sum [31:0]
> +* - 20
> +  - :cspan:`4` B/Cb/V sum [31:0]
> +* - 24
> +  - :cspan:`4` R/Cr/H bin 0 [31:0]
> +* -
> +  - :cspan:`4` ...
> +* - 276
> +  - :cspan:`4` R/Cr/H bin 63 [31:0]
> +* - 280
> +  - :cspan:`4` G/Y/S bin 0 [31:0]
> +* -
> +  - :cspan:`4` ...
> +* - 532
> +  - :cspan:`4` G/Y/S bin 63 [31:0]
> +* - 536
> +  - :cspan:`4` B/Cb/V bin 0 [31:0]
> +* 

Re: [PATCH 1/3] doc-rst:c-domain: fix sphinx version incompatibility

[Mauro Carvalho Chehab]

Em Tue, 6 Sep 2016 17:10:53 +0200
Markus Heiser  escreveu:

> Am 06.09.2016 um 15:34 schrieb Jani Nikula :
> 
> > On Tue, 06 Sep 2016, Jonathan Corbet  wrote:  
> >> On Wed, 31 Aug 2016 17:29:30 +0200
> >> Markus Heiser  wrote:
> >>   
> >>> +if major >= 1 and minor < 4:
> >>> +# indexnode's tuple changed in 1.4
> >>> +# 
> >>> https://github.com/sphinx-doc/sphinx/commit/e6a5a3a92e938fcd75866b4227db9e0524d58f7c
> >>> +self.indexnode['entries'].append(
> >>> +('single', indextext, targetname, ''))
> >>> +else:
> >>> +self.indexnode['entries'].append(
> >>> +('single', indextext, targetname, '', None))  
> >> 
> >> So this doesn't seem right.  We'll get the four-entry tuple behavior with
> >> 1.3 and the five-entry behavior with 1.4...but what happens when 2.0
> >> comes out?
> >> 
> >> Did you want maybe:
> >> 
> >>if major == 1 and minor < 4:
> >> 
> >> ?
> >> 
> >> (That will fail on 0.x, but we've already stated that we don't support
> >> below 1.2).  
> > 
> > Is there a way to check the number of entries expected in the tuples
> > instead of trying to match the version?  
> 
> Sadly not, the dissection of the tuple is spread around the source :(
> 
> Sphinx has some more of these tuples with fixed length (remember
> conf.py, the latex_documents settings) where IMHO hash/value pairs
> (dicts) are more suitable.

Well, the LaTeX stuff at conf.py seems to have a new field on version
1.4.x. At least, our config has:

# (source start file, name, description, authors, manual section).

but 1.4.x docs mentions another tuple: toctree_only.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Em Tue, 6 Sep 2016 08:16:22 -0700
VDR User  escreveu:

> I can tell you that people do still use VDR-1.6.0-3. It would be
> unwise (and unnecessary) to break backwards compatible, which would be
> grounds for NACK if you ask me. Knowingly causing breakage has always
> been an unpopular thing in the VDR community, and this sounds like
> it's going beyond fixing a small issue to fixing it til it breaks.

Well, the libdvbv5 VDR output support was written aiming VDR version 2.1.6.
I've no idea if it works with VDR 1.6.0. Don't remember if I tested support
for such version when I wrote the code.

Also, as it seems that VDR 1.6.0 was released in 2008, it probably won't
support DVB-T2 (with was added in 2011) and may not support DVB-S2
(added in 2008, but support for DTV_STREAM_ID seems to be added only
in 2012).

So, at least for DVB-T2/DVB-S2, people likely need some version newer
than VDR 1.6.0 for full support. If so, the changes proposed by Markus
and Chris won't be disruptive for 1.6, as they seem to be touching only
on DVB-T2 and DVB-S2 support, right?

Please correct me if I'm wrong.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[VDR User]

I can tell you that people do still use VDR-1.6.0-3. It would be
unwise (and unnecessary) to break backwards compatible, which would be
grounds for NACK if you ask me. Knowingly causing breakage has always
been an unpopular thing in the VDR community, and this sounds like
it's going beyond fixing a small issue to fixing it til it breaks.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] doc-rst:c-domain: fix sphinx version incompatibility

[Markus Heiser]

Am 06.09.2016 um 15:34 schrieb Jani Nikula :

> On Tue, 06 Sep 2016, Jonathan Corbet  wrote:
>> On Wed, 31 Aug 2016 17:29:30 +0200
>> Markus Heiser  wrote:
>> 
>>> +if major >= 1 and minor < 4:
>>> +# indexnode's tuple changed in 1.4
>>> +# 
>>> https://github.com/sphinx-doc/sphinx/commit/e6a5a3a92e938fcd75866b4227db9e0524d58f7c
>>> +self.indexnode['entries'].append(
>>> +('single', indextext, targetname, ''))
>>> +else:
>>> +self.indexnode['entries'].append(
>>> +('single', indextext, targetname, '', None))
>> 
>> So this doesn't seem right.  We'll get the four-entry tuple behavior with
>> 1.3 and the five-entry behavior with 1.4...but what happens when 2.0
>> comes out?
>> 
>> Did you want maybe:
>> 
>>  if major == 1 and minor < 4:
>> 
>> ?
>> 
>> (That will fail on 0.x, but we've already stated that we don't support
>> below 1.2).
> 
> Is there a way to check the number of entries expected in the tuples
> instead of trying to match the version?

Sadly not, the dissection of the tuple is spread around the source :(

Sphinx has some more of these tuples with fixed length (remember
conf.py, the latex_documents settings) where IMHO hash/value pairs
(dicts) are more suitable.

-- Markus --
> BR,
> Jani.
> -- 
> Jani Nikula, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday 06 Sep 2016 16:38:55 Niklas Söderlund wrote:
> The format is used on the R-Car VSP1 video queues that carry
> 2-D histogram statistics data.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  Documentation/media/uapi/v4l/meta-formats.rst  |   1 +
>  .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 122 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
>  include/uapi/linux/videodev2.h |   3 +-
>  4 files changed, 126 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
> 
> diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> b/Documentation/media/uapi/v4l/meta-formats.rst index 05ab91e..01e24e3
> 100644
> --- a/Documentation/media/uapi/v4l/meta-formats.rst
> +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> @@ -13,3 +13,4 @@ These formats are used for the :ref:`metadata` interface
> only.
>  :maxdepth: 1
> 
>  pixfmt-meta-vsp1-hgo
> +pixfmt-meta-vsp1-hgt
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
> b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst new file mode
> 100644
> index 000..0393148
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
> @@ -0,0 +1,122 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _v4l2-meta-fmt-vsp1-hgt:
> +
> +***
> +V4L2_META_FMT_VSP1_HGT ('VSPT')
> +***
> +
> +*man V4L2_META_FMT_VSP1_HGT(2)*
> +
> +Renesas R-Car VSP1 2-D Histogram Data
> +
> +
> +Description
> +===
> +
> +This format describes histogram data generated by the Renesas R-Car VSP1
> +2-D Histogram (HGT) engine.
> +
> +The VSP1 HGT is a histogram computation engine that operates on HSV
> +data. It operates on a possibly cropped and subsampled input image and
> +computes the sum, maximum and minimum of the S component as well as a
> +weighted frequency histogram based on the H and S components.
> +
> +The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in
> +total. Each HSV value is added to one or more buckets with a weight
> +between 1 and 16 depending on the Hue areas configuration. Finding the
> +corresponding buckets is done by inspecting the H and S value
> independently. +
> +The Saturation position **n** (0 - 31) of the bucket in the matrix is
> +found by the expression:
> +
> +n = S / 8
> +
> +The Hue position **m** (0 - 5) of the bucket in the matrix depends on
> +how the HGT Hue areas are configured. There are 6 user configurable Hue
> +Areas which can be configured to cover overlapping Hue values:
> +
> +::
> +
> + Area 0   Area 1   Area 2   Area 3   Area 4  
> Area 5 +   
>   +   \   /|  |\   /|  |\   /|  |\   /|
>  |\   /|  |\   /|  |\   / +\ / |  | \ / |  | \ / | 
> | \ / |  | \ / |  | \ / |  | \ / + X  |  |  X  |  |
>  X  |  |  X  |  |  X  |  |  X  |  |  X +/ \ |  | /
> \ |  | / \ |  | / \ |  | / \ |  | / \ |  | / \ +   /  
> \|  |/   \|  |/   \|  |/   \|  |/   \|  |/   \|  |/
>   \ +  5U   0L  0U   1L  1U   2L  2U   3L  3U   4L  4U 
>  5L  5U   0L +<0..Hue
> Value255> +
> +When two consecutive areas don't overlap (n+1L is equal to nU) the boundary
> +value is considered as part of the lower area.
> +
> +Pixels with a hue value included in the centre of an area (between nL and
> nU +included) are are attributed to that single area and given a weight of

s/are are/are/

> 16. +Pixels with a hue value included in the overlapping region between two
> areas +(between n+1L and nU excluded) are attributed to both areas and
> given a weight +for each of these areas proportional to their position
> along the diagonal +lines (rounded down)."

s/"//

Apart from that,

Reviewed-by: Laurent Pinchart 

and applied to my tree with the above fixes.

> +
> +The Hue area setup must match one of the following constrains:
> +
> +::
> +
> +0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U
> +
> +::
> +
> +0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L
> +
> +**Byte Order.**
> +All data is stored in memory in little endian format. Each cell in the
> tables +contains one byte.
> +
> +.. flat-table:: VSP1 HGT Data - (776 bytes)
> +:header-rows:  2
> +:stub-columns: 0
> +
> +* - Offset
> +  - :cspan:`4` Memory
> +* -
> +  - [31:24]
> +  - [23:16]
> +  - [15:8]
> +  - [7:0]
> +* - 0
> +  - -
> +  - S max [7:0]
> +  - -
> +  - S min [7:0]
> +* - 4
> +  - :cspan:`4` S sum [31:0]
> +* - 8
> +  - 

[PATCH] vcodec: mediatek: fix odd_ptr_err.cocci warnings

[Julia Lawall]

PTR_ERR should access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Tiffany Lin 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

 mtk_vcodec_dec_drv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -255,7 +255,7 @@ static int mtk_vcodec_probe(struct platf
}
dev->reg_base[i] = devm_ioremap_resource(>dev, res);
if (IS_ERR((__force void *)dev->reg_base[i])) {
-   ret = PTR_ERR((__force void *)dev->reg_base);
+   ret = PTR_ERR((__force void *)dev->reg_base[i]);
goto err_res;
}
mtk_v4l2_debug(2, "reg[%d] base=%p", i, dev->reg_base[i]);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 2/2] v4l: vsp1: Add HGT support

[Niklas Söderlund]

The HGT is a Histogram Generator Two-Dimensions. It computes a weighted
frequency histograms for hue and saturation areas over a configurable
region of the image with optional subsampling.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   3 +
 drivers/media/platform/vsp1/vsp1_drv.c|  33 -
 drivers/media/platform/vsp1/vsp1_entity.c |  33 +++--
 drivers/media/platform/vsp1/vsp1_entity.h |   1 +
 drivers/media/platform/vsp1/vsp1_hgt.c| 217 ++
 drivers/media/platform/vsp1/vsp1_hgt.h|  42 ++
 drivers/media/platform/vsp1/vsp1_pipe.c   |  16 +++
 drivers/media/platform/vsp1/vsp1_pipe.h   |   2 +
 drivers/media/platform/vsp1/vsp1_regs.h   |   9 ++
 drivers/media/platform/vsp1/vsp1_video.c  |  10 +-
 11 files changed, 352 insertions(+), 16 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index 8ab6a06..a33afc3 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,7 +3,7 @@ vsp1-y  += vsp1_dl.o vsp1_drm.o 
vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
-vsp1-y += vsp1_hgo.o vsp1_histo.o
+vsp1-y += vsp1_hgo.o vsp1_hgt.o vsp1_histo.o
 vsp1-y += vsp1_lif.o
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1.o
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 9dce3ea..012ce40 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -33,6 +33,7 @@ struct vsp1_platform_data;
 struct vsp1_bru;
 struct vsp1_clu;
 struct vsp1_hgo;
+struct vsp1_hgt;
 struct vsp1_hsit;
 struct vsp1_lif;
 struct vsp1_lut;
@@ -52,6 +53,7 @@ struct vsp1_uds;
 #define VSP1_HAS_WPF_VFLIP (1 << 5)
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
 #define VSP1_HAS_HGO   (1 << 7)
+#define VSP1_HAS_HGT   (1 << 8)
 
 struct vsp1_device_info {
u32 version;
@@ -74,6 +76,7 @@ struct vsp1_device {
struct vsp1_bru *bru;
struct vsp1_clu *clu;
struct vsp1_hgo *hgo;
+   struct vsp1_hgt *hgt;
struct vsp1_hsit *hsi;
struct vsp1_hsit *hst;
struct vsp1_lif *lif;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 9ea4244..df97b57 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -31,6 +31,7 @@
 #include "vsp1_dl.h"
 #include "vsp1_drm.h"
 #include "vsp1_hgo.h"
+#include "vsp1_hgt.h"
 #include "vsp1_hsit.h"
 #include "vsp1_lif.h"
 #include "vsp1_lut.h"
@@ -107,6 +108,7 @@ static int vsp1_create_sink_links(struct vsp1_device *vsp1,
continue;
 
if (source->type == VSP1_ENTITY_HGO ||
+   source->type == VSP1_ENTITY_HGT ||
source->type == VSP1_ENTITY_LIF ||
source->type == VSP1_ENTITY_WPF)
continue;
@@ -160,6 +162,16 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1)
return ret;
}
 
+   if (vsp1->hgt) {
+   ret = 
media_create_pad_link(>hgt->histo.entity.subdev.entity,
+   HISTO_PAD_SOURCE,
+   >hgt->histo.video.entity, 0,
+   MEDIA_LNK_FL_ENABLED |
+   MEDIA_LNK_FL_IMMUTABLE);
+   if (ret < 0)
+   return ret;
+   }
+
if (vsp1->lif) {
ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
RWPF_PAD_SOURCE,
@@ -301,6 +313,17 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
  >entities);
}
 
+   if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) {
+   vsp1->hgt = vsp1_hgt_create(vsp1);
+   if (IS_ERR(vsp1->hgt)) {
+   ret = PTR_ERR(vsp1->hgt);
+   goto done;
+   }
+
+   list_add_tail(>hgt->histo.entity.list_dev,
+ >entities);
+   }
+
/* The LIF is only supported when used in conjunction with the DU, in
 * which case the userspace API is disabled. If the userspace API is
 * enabled skip the LIF, even when present.
@@ -584,7 +607,8 @@ static const struct vsp1_device_info vsp1_device_infos[] 

[PATCHv2 1/2] v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine

[Niklas Söderlund]

The format is used on the R-Car VSP1 video queues that carry
2-D histogram statistics data.

Signed-off-by: Niklas Söderlund 
---
 Documentation/media/uapi/v4l/meta-formats.rst  |   1 +
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 122 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/uapi/linux/videodev2.h |   3 +-
 4 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst

diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
b/Documentation/media/uapi/v4l/meta-formats.rst
index 05ab91e..01e24e3 100644
--- a/Documentation/media/uapi/v4l/meta-formats.rst
+++ b/Documentation/media/uapi/v4l/meta-formats.rst
@@ -13,3 +13,4 @@ These formats are used for the :ref:`metadata` interface only.
 :maxdepth: 1
 
 pixfmt-meta-vsp1-hgo
+pixfmt-meta-vsp1-hgt
diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst 
b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
new file mode 100644
index 000..0393148
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
@@ -0,0 +1,122 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _v4l2-meta-fmt-vsp1-hgt:
+
+***
+V4L2_META_FMT_VSP1_HGT ('VSPT')
+***
+
+*man V4L2_META_FMT_VSP1_HGT(2)*
+
+Renesas R-Car VSP1 2-D Histogram Data
+
+
+Description
+===
+
+This format describes histogram data generated by the Renesas R-Car VSP1
+2-D Histogram (HGT) engine.
+
+The VSP1 HGT is a histogram computation engine that operates on HSV
+data. It operates on a possibly cropped and subsampled input image and
+computes the sum, maximum and minimum of the S component as well as a
+weighted frequency histogram based on the H and S components.
+
+The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in
+total. Each HSV value is added to one or more buckets with a weight
+between 1 and 16 depending on the Hue areas configuration. Finding the
+corresponding buckets is done by inspecting the H and S value independently.
+
+The Saturation position **n** (0 - 31) of the bucket in the matrix is
+found by the expression:
+
+n = S / 8
+
+The Hue position **m** (0 - 5) of the bucket in the matrix depends on
+how the HGT Hue areas are configured. There are 6 user configurable Hue
+Areas which can be configured to cover overlapping Hue values:
+
+::
+
+ Area 0   Area 1   Area 2   Area 3   Area 4   Area 
5
+     

+   \   /|  |\   /|  |\   /|  |\   /|  |\   /|  |\   /| 
 |\   /
+\ / |  | \ / |  | \ / |  | \ / |  | \ / |  | \ / | 
 | \ /
+ X  |  |  X  |  |  X  |  |  X  |  |  X  |  |  X  | 
 |  X
+/ \ |  | / \ |  | / \ |  | / \ |  | / \ |  | / \ | 
 | / \
+   /   \|  |/   \|  |/   \|  |/   \|  |/   \|  |/   \| 
 |/   \
+  5U   0L  0U   1L  1U   2L  2U   3L  3U   4L  4U   5L 
 5U   0L
+<0..Hue 
Value255>
+
+When two consecutive areas don't overlap (n+1L is equal to nU) the boundary
+value is considered as part of the lower area.
+
+Pixels with a hue value included in the centre of an area (between nL and nU
+included) are are attributed to that single area and given a weight of 16.
+Pixels with a hue value included in the overlapping region between two areas
+(between n+1L and nU excluded) are attributed to both areas and given a weight
+for each of these areas proportional to their position along the diagonal
+lines (rounded down)."
+
+The Hue area setup must match one of the following constrains:
+
+::
+
+0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U
+
+::
+
+0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L
+
+**Byte Order.**
+All data is stored in memory in little endian format. Each cell in the tables
+contains one byte.
+
+.. flat-table:: VSP1 HGT Data - (776 bytes)
+:header-rows:  2
+:stub-columns: 0
+
+* - Offset
+  - :cspan:`4` Memory
+* -
+  - [31:24]
+  - [23:16]
+  - [15:8]
+  - [7:0]
+* - 0
+  - -
+  - S max [7:0]
+  - -
+  - S min [7:0]
+* - 4
+  - :cspan:`4` S sum [31:0]
+* - 8
+  - :cspan:`4` Histogram bucket (m=0, n=0) [31:0]
+* - 12
+  - :cspan:`4` Histogram bucket (m=0, n=1) [31:0]
+* -
+  - :cspan:`4` ...
+* - 132
+  - :cspan:`4` Histogram bucket (m=0, n=31) [31:0]
+* - 136
+  - :cspan:`4` Histogram bucket (m=1, n=0) [31:0]
+* -
+  - :cspan:`4` ...
+* - 264
+  - :cspan:`4` Histogram bucket (m=2, n=0) [31:0]
+* -
+  - :cspan:`4` ...
+* - 392
+  - :cspan:`4` Histogram bucket (m=3, n=0) [31:0]
+ 

[PATCHv2 0/2] v4l: vsp1: Add HGT support

[Niklas Söderlund]

Hi,

This series add support for the VSP1 2-D histogram engine HGT.

It's based on top of Laurent Pinchart tree at 
git://linuxtv.org/pinchartl/media.git hgo. And depends on Laurents patch 
'[PATCH] v4l: vsp1: Move subdev operations from HGO to common histogram 
code'.

It is tested on Koelsch using a modified vsp-tests suite package,
modifications can be found at https://git.ragnatech.se/vsp-tests hgt.

* Changes since v1
- Rebased on top of Laurents patch which made all subdev operations 
  common for HGO and HGT. This removed a lot of code that is now shared.
- Removed the Hue area configuration for the histogram pixel format.  
  These values are set by userspace so it already knows them.
- Updated pixel format documentation after input from Laurent.
- Better aligned the code to the existing VSP code base.
- Simplify check that hue areas are valid for the hardware.
- Fixed spelling.

Niklas Söderlund (2):
  v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine
  v4l: vsp1: Add HGT support

 Documentation/media/uapi/v4l/meta-formats.rst  |   1 +
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 122 
 drivers/media/platform/vsp1/Makefile   |   2 +-
 drivers/media/platform/vsp1/vsp1.h |   3 +
 drivers/media/platform/vsp1/vsp1_drv.c |  33 +++-
 drivers/media/platform/vsp1/vsp1_entity.c  |  33 +++-
 drivers/media/platform/vsp1/vsp1_entity.h  |   1 +
 drivers/media/platform/vsp1/vsp1_hgt.c | 217 +
 drivers/media/platform/vsp1/vsp1_hgt.h |  42 
 drivers/media/platform/vsp1/vsp1_pipe.c|  16 ++
 drivers/media/platform/vsp1/vsp1_pipe.h|   2 +
 drivers/media/platform/vsp1/vsp1_regs.h|   9 +
 drivers/media/platform/vsp1/vsp1_video.c   |  10 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/uapi/linux/videodev2.h |   3 +-
 15 files changed, 478 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h

-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] doc-rst:c-domain: fix sphinx version incompatibility

[Jani Nikula]

On Tue, 06 Sep 2016, Jonathan Corbet  wrote:
> On Wed, 31 Aug 2016 17:29:30 +0200
> Markus Heiser  wrote:
>
>> +if major >= 1 and minor < 4:
>> +# indexnode's tuple changed in 1.4
>> +# 
>> https://github.com/sphinx-doc/sphinx/commit/e6a5a3a92e938fcd75866b4227db9e0524d58f7c
>> +self.indexnode['entries'].append(
>> +('single', indextext, targetname, ''))
>> +else:
>> +self.indexnode['entries'].append(
>> +('single', indextext, targetname, '', None))
>
> So this doesn't seem right.  We'll get the four-entry tuple behavior with
> 1.3 and the five-entry behavior with 1.4...but what happens when 2.0
> comes out?
>
> Did you want maybe:
>
>   if major == 1 and minor < 4:
>
> ?
>
> (That will fail on 0.x, but we've already stated that we don't support
> below 1.2).

Is there a way to check the number of entries expected in the tuples
instead of trying to match the version?

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.9] ad5820 driver cleanup

[Sakari Ailus]

Hi Mauro,

This patch fixes the int bitfield issue you found in the ad5820 driver.

Please pull.


The following changes since commit e62c30e76829d46bf11d170fd81b735f13a014ac:

  [media] smiapp: Remove set_xclk() callback from hwconfig (2016-09-05 15:53:20 
-0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git ad5820

for you to fetch changes up to 021a6d55696421194b72fbc3c6abc50b7f3f1dc4:

  ad5820: Use bool for boolean values (2016-09-06 15:23:46 +0300)


Sakari Ailus (1):
  ad5820: Use bool for boolean values

 drivers/media/i2c/ad5820.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] variable name is never null, so remove null check

[Colin King]

From: Colin Ian King 

The variable name is always assigned to a literal string in the
proceeding switch statement, so it is never null and hence the
null check is redundant. Remove null the check.

Signed-off-by: Colin Ian King 
---
 drivers/media/usb/pvrusb2/pvrusb2-sysfs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c 
b/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c
index 06fe63c..d977976 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c
@@ -116,7 +116,6 @@ static ssize_t show_type(struct device *class_dev,
}
pvr2_sysfs_trace("pvr2_sysfs(%p) show_type(cid=%d) is %s",
 cip->chptr, cip->ctl_id, name);
-   if (!name) return -EINVAL;
return scnprintf(buf, PAGE_SIZE, "%s\n", name);
 }
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] doc-rst:c-domain: fix sphinx version incompatibility

[Jonathan Corbet]

On Tue, 6 Sep 2016 14:24:11 +0200
Markus Heiser  wrote:

> Should I send a new patch .. or could you fix it?

Please just regenerate the series and I'll apply it.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] doc-rst:c-domain: function-like macros index entry

[Jonathan Corbet]

On Wed, 31 Aug 2016 17:29:32 +0200
Markus Heiser  wrote:

> For function-like macros, sphinx creates 'FOO (C function)' entries.
> With this patch 'FOO (C macro)' are created for function-like macros,
> which is the same for object-like macros.

As others have pointed out, we generally want to hide the difference
between functions and macros, so this is probably one change we don't
want.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: uvcvideo error on second capture from USB device, leading to V4L2_BUF_FLAG_ERROR

[Andrey Utkin]

On Tue, Sep 06, 2016 at 01:51:51PM +0300, Oliver Collyer wrote:
> So today I installed Ubuntu 16.04 on another PC (this one a high spec machine 
> with a Rampage V Extreme motherboard) and I reproduced exactly the same 
> errors and trace.
> 
> Rebooting the same PC back into Windows 10 and using the same USB 3.0 port, I 
> had no problems capturing using FFmpeg via DirectShow. I could start and stop 
> the capture repeatedly without any warnings or errors appearing in FFmpeg 
> (built from the same source).
> 
> If the hardware is misbehaving, on both these capture devices, then DS must 
> be handling it better than V4L2. Or there is simply an obscure bug in V4L2 
> which only manifests itself with certain devices.
> 
> Would providing ssh access to the machine be of interest to anyone who wants 
> to debug this?

I am curious to tinker with this, just not sure about free time for it.
Please go through the following instruction, and then we'll see if ssh
is going to help to debug this.

Also I think it is worth to CC actual manufacturers. There are addresses
for technical support of both devices in public on maker websites.
Please CC them when replying with new logs, to let them catch up.

So, I am still not certain what confuses the device, i.e. where the
faulty usage pattern comes from: ffmpeg or driver. So I'd like you to
check the difference with various userspace applications which involve
streaming from device.

For each of your two devices, alone (not two at same time), do this:

For each command from this list:
"v4l2-compliance -s -d /dev/video0",
"ffmpeg -f v4l2 -i /dev/video0 -vcodec rawvideo -f null -y /dev/null",
""
(feel free to add more, maybe mplayer invocation or such)

dmesg -C
plug in the device
modprobe uvcvideo module
run the command twice or more in row
save uncut commands output (with command lines) to separate file
rmmod uvcvideo
unplug the device
save "dmesg" output to separate file


Done.

I guess this test makes sense, or am I missing something you've already
told us?

If you go making a script for this, make sure to notice if rmmod fails
for any reason, etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] doc-rst:c-domain: function-like macros arguments

[Jonathan Corbet]

So I'm going into total nit-picking territory here, but since I'm looking
at it and I think the series needs a respin anyway...

On Wed, 31 Aug 2016 17:29:31 +0200
Markus Heiser  wrote:

> +m = c_funcptr_sig_re.match(sig)
> +if m is None:
> +m = c_sig_re.match(sig)
> +if m is None:
> +raise ValueError('no match')

How about we put that second test inside the first if block and avoid the
redundant None test if the first match works?  The energy saved may
prevent a hurricane someday :)

> +
> +rettype, fullname, arglist, _const = m.groups()
> +if rettype or not arglist.strip():
> +return False
> +
> +arglist = arglist.replace('`', '').replace('\\ ', '').strip()  # 
> remove markup
> +arglist = [a.strip() for a in arglist.split(",")]

Similarly, stripping the args three times seems a bit much.  The middle
one is totally redundant and could go at a minimum.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] doc-rst:c-domain: fix sphinx version incompatibility

[Markus Heiser]

Am 06.09.2016 um 14:19 schrieb Jonathan Corbet :

> On Wed, 31 Aug 2016 17:29:30 +0200
> Markus Heiser  wrote:
> 
>> +if major >= 1 and minor < 4:
>> +# indexnode's tuple changed in 1.4
>> +# 
>> https://github.com/sphinx-doc/sphinx/commit/e6a5a3a92e938fcd75866b4227db9e0524d58f7c
>> +self.indexnode['entries'].append(
>> +('single', indextext, targetname, ''))
>> +else:
>> +self.indexnode['entries'].append(
>> +('single', indextext, targetname, '', None))
> 
> So this doesn't seem right.  We'll get the four-entry tuple behavior with
> 1.3 and the five-entry behavior with 1.4...but what happens when 2.0
> comes out?
> 
> Did you want maybe:
> 
>   if major == 1 and minor < 4:
> 
> ?

Ups, yes you are right.

Should I send a new patch .. or could you fix it?

-- Markus --

> 
> (That will fail on 0.x, but we've already stated that we don't support
> below 1.2).
> 
> jon

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] doc-rst:c-domain: fix sphinx version incompatibility

[Jonathan Corbet]

On Wed, 31 Aug 2016 17:29:30 +0200
Markus Heiser  wrote:

> +if major >= 1 and minor < 4:
> +# indexnode's tuple changed in 1.4
> +# 
> https://github.com/sphinx-doc/sphinx/commit/e6a5a3a92e938fcd75866b4227db9e0524d58f7c
> +self.indexnode['entries'].append(
> +('single', indextext, targetname, ''))
> +else:
> +self.indexnode['entries'].append(
> +('single', indextext, targetname, '', None))

So this doesn't seem right.  We'll get the four-entry tuple behavior with
1.3 and the five-entry behavior with 1.4...but what happens when 2.0
comes out?

Did you want maybe:

if major == 1 and minor < 4:

?

(That will fail on 0.x, but we've already stated that we don't support
below 1.2).

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.9] Add an operations callback struct for the media device

[Sakari Ailus]

Hi Mauro,

This request contains a single patch, one that moves the link_notify()
callback to a separate struct.

As the patch touches several drivers and is required by anything that's
adding new callbacks to the media device, I think it makes sense to merge it
now rather than later on.

Please pull.


The following changes since commit e62c30e76829d46bf11d170fd81b735f13a014ac:

  [media] smiapp: Remove set_xclk() callback from hwconfig (2016-09-05 15:53:20 
-0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git media-request-prepare

for you to fetch changes up to ff299860f5ae379a336d462ee9d8c987c60e7de5:

  media: Move media_device link_notify operation to an ops structure 
(2016-09-06 10:34:51 +0300)


Laurent Pinchart (1):
  media: Move media_device link_notify operation to an ops structure

 drivers/media/media-entity.c  | 11 ++-
 drivers/media/platform/exynos4-is/media-dev.c |  6 +-
 drivers/media/platform/omap3isp/isp.c |  6 +-
 drivers/staging/media/omap4iss/iss.c  |  6 +-
 include/media/media-device.h  | 16 
 5 files changed, 33 insertions(+), 12 deletions(-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.9] Raw bayer media bus codes and fixes, raw bayer pixelformat cleanups

[Sakari Ailus]

Hi Mauro,

Here are cleanups for the raw bayer pixelformats and new media bus codes for
the 14 and 16 bits per sample variants. The smiapp driver uses the newly
added formats.

Please pull.


The following changes since commit e62c30e76829d46bf11d170fd81b735f13a014ac:

  [media] smiapp: Remove set_xclk() callback from hwconfig (2016-09-05 15:53:20 
-0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git packed12

for you to fetch changes up to 903dc2ce0604199f2984640e229e82397434:

  smiapp: Add support for 14 and 16 bits per sample depths (2016-09-06 14:46:36 
+0300)


Jouni Ukkonen (1):
  media: Add 1X14 14-bit raw bayer media bus code definitions

Sakari Ailus (7):
  doc-rst: Correct the ordering of LSBs of the 10-bit raw packed formats
  doc-rst: Fix number of zeroed high order bits in 12-bit raw format defs
  doc-rst: Clean up raw bayer pixel format definitions
  doc-rst: Unify documentation of the 8-bit bayer formats
  doc-rst: 16-bit BGGR is always 16 bits
  media: Add 1X16 16-bit raw bayer media bus code definitions
  smiapp: Add support for 14 and 16 bits per sample depths

 Documentation/media/uapi/v4l/pixfmt-rgb.rst  |   3 -
 Documentation/media/uapi/v4l/pixfmt-sbggr16.rst  |   5 -
 Documentation/media/uapi/v4l/pixfmt-sbggr8.rst   |  77 
 Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst   |  80 
 Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst   |  80 
 Documentation/media/uapi/v4l/pixfmt-srggb10.rst  |  15 +-
 Documentation/media/uapi/v4l/pixfmt-srggb10p.rst |  24 +-
 Documentation/media/uapi/v4l/pixfmt-srggb12.rst  |   5 +-
 Documentation/media/uapi/v4l/pixfmt-srggb8.rst   |  38 +-
 Documentation/media/uapi/v4l/subdev-formats.rst  | 546 ++-
 drivers/media/i2c/smiapp/smiapp-core.c   |   8 +
 drivers/media/i2c/smiapp/smiapp.h|   2 +-
 include/uapi/linux/media-bus-format.h|  10 +-
 13 files changed, 606 insertions(+), 287 deletions(-)
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/8] doc-rst: Unify documentation of the 8-bit bayer formats

[Sakari Ailus]

The other raw bayer formats had a single sample depth dependent definition
whereas the 8-bit formats had one page for each. Unify the documentation
of the 8-bit formats.

Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/pixfmt-rgb.rst|  3 -
 Documentation/media/uapi/v4l/pixfmt-sbggr8.rst | 77 -
 Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst | 80 --
 Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst | 80 --
 Documentation/media/uapi/v4l/pixfmt-srggb8.rst | 38 ++--
 5 files changed, 20 insertions(+), 258 deletions(-)
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst 
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 4b3651c..9cc9808 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -11,9 +11,6 @@ RGB Formats
 :maxdepth: 1
 
 pixfmt-packed-rgb
-pixfmt-sbggr8
-pixfmt-sgbrg8
-pixfmt-sgrbg8
 pixfmt-srggb8
 pixfmt-sbggr16
 pixfmt-srggb10
diff --git a/Documentation/media/uapi/v4l/pixfmt-sbggr8.rst 
b/Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
deleted file mode 100644
index e880ba0..000
--- a/Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
+++ /dev/null
@@ -1,77 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SBGGR8:
-
-
-V4L2_PIX_FMT_SBGGR8 ('BA81')
-
-
-Bayer RGB format
-
-
-Description
-===
-
-This is commonly the native format of digital cameras, reflecting the
-arrangement of sensors on the CCD device. Only one red, green or blue
-value is given for each pixel. Missing components must be interpolated
-from neighbouring pixels. From left to right the first row consists of a
-blue and green value, the second row of a green and red value. This
-scheme repeats to the right and down for every two columns and rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  start + 0:
-
-   -  B\ :sub:`00`
-
-   -  G\ :sub:`01`
-
-   -  B\ :sub:`02`
-
-   -  G\ :sub:`03`
-
--  .. row 2
-
-   -  start + 4:
-
-   -  G\ :sub:`10`
-
-   -  R\ :sub:`11`
-
-   -  G\ :sub:`12`
-
-   -  R\ :sub:`13`
-
--  .. row 3
-
-   -  start + 8:
-
-   -  B\ :sub:`20`
-
-   -  G\ :sub:`21`
-
-   -  B\ :sub:`22`
-
-   -  G\ :sub:`23`
-
--  .. row 4
-
-   -  start + 12:
-
-   -  G\ :sub:`30`
-
-   -  R\ :sub:`31`
-
-   -  G\ :sub:`32`
-
-   -  R\ :sub:`33`
diff --git a/Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst 
b/Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
deleted file mode 100644
index 5cd40d6..000
--- a/Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SGBRG8:
-
-
-V4L2_PIX_FMT_SGBRG8 ('GBRG')
-
-
-
-Bayer RGB format
-
-
-Description
-===
-
-This is commonly the native format of digital cameras, reflecting the
-arrangement of sensors on the CCD device. Only one red, green or blue
-value is given for each pixel. Missing components must be interpolated
-from neighbouring pixels. From left to right the first row consists of a
-green and blue value, the second row of a red and green value. This
-scheme repeats to the right and down for every two columns and rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  start + 0:
-
-   -  G\ :sub:`00`
-
-   -  B\ :sub:`01`
-
-   -  G\ :sub:`02`
-
-   -  B\ :sub:`03`
-
--  .. row 2
-
-   -  start + 4:
-
-   -  R\ :sub:`10`
-
-   -  G\ :sub:`11`
-
-   -  R\ :sub:`12`
-
-   -  G\ :sub:`13`
-
--  .. row 3
-
-   -  start + 8:
-
-   -  G\ :sub:`20`
-
-   -  B\ :sub:`21`
-
-   -  G\ :sub:`22`
-
-   -  B\ :sub:`23`
-
--  .. row 4
-
-   -  start + 12:
-
-   -  R\ :sub:`30`
-
-   -  G\ :sub:`31`
-
-   -  R\ :sub:`32`
-
-   -  G\ :sub:`33`
diff --git a/Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst 
b/Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst
deleted file mode 100644
index 05a09db..000
--- a/Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SGRBG8:
-
-
-V4L2_PIX_FMT_SGRBG8 ('GRBG')
-
-
-
-Bayer RGB format
-
-
-Description
-===
-
-This is commonly the native format of digital cameras, reflecting the
-arrangement of sensors on the CCD device. 

[PATCH v4 1/8] doc-rst: Correct the ordering of LSBs of the 10-bit raw packed formats

[Sakari Ailus]

The 10-bit packed raw bayer format documented that the data of the first
pixel of a four-pixel group was found in the first byte and the two
highest bits of the fifth byte. This was not entirely correct. The two
bits in the fifth byte are the two lowest bits. The second pixel occupies
the second byte and third and fourth least significant bits and so on.

Signed-off-by: Sakari Ailus 
Acked-by: Aviv Greenberg 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/pixfmt-srggb10p.rst | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
index a5752b9..cc573c9 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
@@ -56,8 +56,8 @@ Each cell is one byte.
 
-  G\ :sub:`03high`
 
-   -  B\ :sub:`00low`\ (bits 7--6) G\ :sub:`01low`\ (bits 5--4)
- B\ :sub:`02low`\ (bits 3--2) G\ :sub:`03low`\ (bits 1--0)
+   -  G\ :sub:`03low`\ (bits 7--6) B\ :sub:`02low`\ (bits 5--4)
+ G\ :sub:`01low`\ (bits 3--2) B\ :sub:`00low`\ (bits 1--0)
 
 -  .. row 2
 
@@ -71,8 +71,8 @@ Each cell is one byte.
 
-  R\ :sub:`13high`
 
-   -  G\ :sub:`10low`\ (bits 7--6) R\ :sub:`11low`\ (bits 5--4)
- G\ :sub:`12low`\ (bits 3--2) R\ :sub:`13low`\ (bits 1--0)
+   -  R\ :sub:`13low`\ (bits 7--6) G\ :sub:`12low`\ (bits 5--4)
+ R\ :sub:`11low`\ (bits 3--2) G\ :sub:`10low`\ (bits 1--0)
 
 -  .. row 3
 
@@ -86,8 +86,8 @@ Each cell is one byte.
 
-  G\ :sub:`23high`
 
-   -  B\ :sub:`20low`\ (bits 7--6) G\ :sub:`21low`\ (bits 5--4)
- B\ :sub:`22low`\ (bits 3--2) G\ :sub:`23low`\ (bits 1--0)
+   -  G\ :sub:`23low`\ (bits 7--6) B\ :sub:`22low`\ (bits 5--4)
+ G\ :sub:`21low`\ (bits 3--2) B\ :sub:`20low`\ (bits 1--0)
 
 -  .. row 4
 
@@ -101,8 +101,8 @@ Each cell is one byte.
 
-  R\ :sub:`33high`
 
-   -  G\ :sub:`30low`\ (bits 7--6) R\ :sub:`31low`\ (bits 5--4)
- G\ :sub:`32low`\ (bits 3--2) R\ :sub:`33low`\ (bits 1--0)
+   -  R\ :sub:`33low`\ (bits 7--6) G\ :sub:`32low`\ (bits 5--4)
+ R\ :sub:`31low`\ (bits 3--2) G\ :sub:`30low`\ (bits 1--0)
 
 .. raw:: latex
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 5/8] doc-rst: 16-bit BGGR is always 16 bits

[Sakari Ailus]

The V4L2_PIX_FMT_SBGGR16 format is documented to contain samples of fewer
than 16 bits. However, we do have specific definitions for smaller sample
sizes. Therefore, this note is redundant from the API point of view.

Currently only two drivers, am437x and davinci, use the
V4L2_PIX_FMT_SBGGR16 pixelformat currently. The sampling precision is
understood to be 16 bits in all current cases.

Remove the note on sampling precision.

Signed-off-by: Sakari Ailus 
Acked-by: Lad, Prabhakar 
---
 Documentation/media/uapi/v4l/pixfmt-sbggr16.rst | 5 -
 1 file changed, 5 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst 
b/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
index 801b78c..e3b53e3 100644
--- a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
@@ -17,11 +17,6 @@ This format is similar to
 has a depth of 16 bits. The least significant byte is stored at lower
 memory addresses (little-endian).
 
-.. note::
-
-The actual sampling precision may be lower than 16 bits,
-for example 10 bits per pixel with values in tange 0 to 1023.
-
 **Byte Order.**
 Each cell is one byte.
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 6/8] media: Add 1X14 14-bit raw bayer media bus code definitions

[Sakari Ailus]

From: Jouni Ukkonen 

The codes will be called:

MEDIA_BUS_FMT_SBGGR14_1X14
MEDIA_BUS_FMT_SGBRG14_1X14
MEDIA_BUS_FMT_SGRBG14_1X14
MEDIA_BUS_FMT_SRGGB14_1X14

Signed-off-by: Jouni Ukkonen 
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 258 +++-
 include/uapi/linux/media-bus-format.h   |   6 +-
 2 files changed, 262 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 52013b5..07e7cf98 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -2812,7 +2812,7 @@ organization is given as an example for the first pixel 
only.
-  Code
 
-
-   -  :cspan:`11` Data organization
+   -  :cspan:`13` Data organization
 
 -  .. row 2
 
@@ -2820,6 +2820,10 @@ organization is given as an example for the first pixel 
only.
-
-  Bit
 
+   -  13
+
+   -  12
+
-  11
 
-  10
@@ -2859,6 +2863,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -2890,6 +2898,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -2921,6 +2933,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -2952,6 +2968,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  r\ :sub:`7`
 
-  r\ :sub:`6`
@@ -2983,6 +3003,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3014,6 +3038,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3045,6 +3073,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3076,6 +3108,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  r\ :sub:`7`
 
-  r\ :sub:`6`
@@ -3107,6 +3143,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3138,6 +3178,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3169,6 +3213,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3200,6 +3248,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  r\ :sub:`7`
 
-  r\ :sub:`6`
@@ -3231,6 +3283,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  0
 
-  0
@@ -3260,6 +3316,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3291,6 +3351,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3320,6 +3384,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  0
 
-  0
@@ -3351,6 +3419,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`9`
 
-  b\ :sub:`8`
@@ -3380,6 +3452,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`1`
 
-  b\ :sub:`0`
@@ -3411,6 +3487,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`1`
 
-  b\ :sub:`0`
@@ -3440,6 +3520,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`9`
 
-  b\ :sub:`8`
@@ -3467,6 +3551,10 @@ organization is given as an example for the first pixel 
only.
 
-
 
+   -  -
+
+   -  -
+
-  b\ :sub:`9`
 
-  b\ :sub:`8`
@@ -3498,6 +3586,10 @@ organization is given as an example for the first pixel 
only.
 

[PATCH v4 0/8] New raw bayer format definitions, fixes

[Sakari Ailus]

Hi folks,

Here's the fourth version of the new raw bayer format definition patchset.

On Mauro's request, I've dropped the patches adding the new pixel formats
as they're not being used in a driver now. I'm keeping these patches
around in order to later on merge them once needed:



Since v3:

- Remove new pixelformat definitions

- Add support for the new media bus codes in the smiapp driver

-- 
Kind regards,
Sakari


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/8] doc-rst: Clean up raw bayer pixel format definitions

[Sakari Ailus]

- Explicitly state that the most significant n bits are zeroed on 10 and
  12 bpp formats.
- Remove extra comma from the last entry of the format list
- Add a missing colon before a list
- Use figures versus word numerals consistently

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/pixfmt-srggb10.rst  | 15 ---
 Documentation/media/uapi/v4l/pixfmt-srggb10p.rst |  8 
 Documentation/media/uapi/v4l/pixfmt-srggb12.rst  |  5 +++--
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb10.rst
index 8af7569..b145c75 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb10.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb10.rst
@@ -20,15 +20,16 @@ Description
 ===
 
 These four pixel formats are raw sRGB / Bayer formats with 10 bits per
-colour. Each colour component is stored in a 16-bit word, with 6 unused
-high bits filled with zeros. Each n-pixel row contains n/2 green samples
-and n/2 blue or red samples, with alternating red and blue rows. Bytes
-are stored in memory in little endian order. They are conventionally
-described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example
-of one of these formats
+sample. Each sample is stored in a 16-bit word, with 6 unused
+high bits filled with zeros. Each n-pixel row contains n/2 green samples and
+n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of
+these formats:
 
 **Byte Order.**
-Each cell is one byte, high 6 bits in high bytes are 0.
+Each cell is one byte, the 6 most significant bits in the high bytes
+are 0.
 
 
 
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
index cc573c9..80e3457 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
@@ -20,10 +20,10 @@ Description
 ===
 
 These four pixel formats are packed raw sRGB / Bayer formats with 10
-bits per colour. Every four consecutive colour components are packed
-into 5 bytes. Each of the first 4 bytes contain the 8 high order bits of
-the pixels, and the fifth byte contains the two least significants bits
-of each pixel, in the same order.
+bits per sample. Every four consecutive samples are packed into 5
+bytes. Each of the first 4 bytes contain the 8 high order bits
+of the pixels, and the 5th byte contains the 2 least significants
+bits of each pixel, in the same order.
 
 Each n-pixel row contains n/2 green samples and n/2 blue or red samples,
 with alternating green-red and green-blue rows. They are conventionally
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst
index b2880df..4776f3f 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst
@@ -26,10 +26,11 @@ high bits filled with zeros. Each n-pixel row contains n/2 
green samples
 and n/2 blue or red samples, with alternating red and blue rows. Bytes
 are stored in memory in little endian order. They are conventionally
 described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example
-of one of these formats
+of one of these formats:
 
 **Byte Order.**
-Each cell is one byte, high 4 bits in high bytes are 0.
+Each cell is one byte, the 4 most significant bits in the high bytes are
+0.
 
 
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 8/8] smiapp: Add support for 14 and 16 bits per sample depths

[Sakari Ailus]

SMIA++ supports 14 and 16 bits per pixel formats as well. Add support to
these formats in the driver.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c | 8 
 drivers/media/i2c/smiapp/smiapp.h  | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index d8b78c6..44f8c7e 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -328,6 +328,14 @@ static void __smiapp_update_exposure_limits(struct 
smiapp_sensor *sensor)
  *orders must be defined.
  */
 static const struct smiapp_csi_data_format smiapp_csi_data_formats[] = {
+   { MEDIA_BUS_FMT_SGRBG16_1X16, 16, 16, SMIAPP_PIXEL_ORDER_GRBG, },
+   { MEDIA_BUS_FMT_SRGGB16_1X16, 16, 16, SMIAPP_PIXEL_ORDER_RGGB, },
+   { MEDIA_BUS_FMT_SBGGR16_1X16, 16, 16, SMIAPP_PIXEL_ORDER_BGGR, },
+   { MEDIA_BUS_FMT_SGBRG16_1X16, 16, 16, SMIAPP_PIXEL_ORDER_GBRG, },
+   { MEDIA_BUS_FMT_SGRBG14_1X14, 14, 14, SMIAPP_PIXEL_ORDER_GRBG, },
+   { MEDIA_BUS_FMT_SRGGB14_1X14, 14, 14, SMIAPP_PIXEL_ORDER_RGGB, },
+   { MEDIA_BUS_FMT_SBGGR14_1X14, 14, 14, SMIAPP_PIXEL_ORDER_BGGR, },
+   { MEDIA_BUS_FMT_SGBRG14_1X14, 14, 14, SMIAPP_PIXEL_ORDER_GBRG, },
{ MEDIA_BUS_FMT_SGRBG12_1X12, 12, 12, SMIAPP_PIXEL_ORDER_GRBG, },
{ MEDIA_BUS_FMT_SRGGB12_1X12, 12, 12, SMIAPP_PIXEL_ORDER_RGGB, },
{ MEDIA_BUS_FMT_SBGGR12_1X12, 12, 12, SMIAPP_PIXEL_ORDER_BGGR, },
diff --git a/drivers/media/i2c/smiapp/smiapp.h 
b/drivers/media/i2c/smiapp/smiapp.h
index c504bd8..aae72bc 100644
--- a/drivers/media/i2c/smiapp/smiapp.h
+++ b/drivers/media/i2c/smiapp/smiapp.h
@@ -151,7 +151,7 @@ struct smiapp_csi_data_format {
 #define SMIAPP_PADS2
 
 #define SMIAPP_COMPRESSED_BASE 8
-#define SMIAPP_COMPRESSED_MAX  12
+#define SMIAPP_COMPRESSED_MAX  16
 #define SMIAPP_NR_OF_COMPRESSED(SMIAPP_COMPRESSED_MAX - \
 SMIAPP_COMPRESSED_BASE + 1)
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/8] doc-rst: Fix number of zeroed high order bits in 12-bit raw format defs

[Sakari Ailus]

The number of high order bits in samples was documented to be 6 for 12-bit
data. This is clearly wrong, fix it.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/pixfmt-srggb12.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst
index 109772f..b2880df 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst
@@ -29,7 +29,7 @@ described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is 
an example
 of one of these formats
 
 **Byte Order.**
-Each cell is one byte, high 6 bits in high bytes are 0.
+Each cell is one byte, high 4 bits in high bytes are 0.
 
 
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 7/8] media: Add 1X16 16-bit raw bayer media bus code definitions

[Sakari Ailus]

The codes will be called:

MEDIA_BUS_FMT_SBGGR16_1X16
MEDIA_BUS_FMT_SGBRG16_1X16
MEDIA_BUS_FMT_SGRBG16_1X16
MEDIA_BUS_FMT_SRGGB16_1X16

Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 290 +++-
 include/uapi/linux/media-bus-format.h   |   6 +-
 2 files changed, 294 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 07e7cf98..06d8981 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -2812,7 +2812,7 @@ organization is given as an example for the first pixel 
only.
-  Code
 
-
-   -  :cspan:`13` Data organization
+   -  :cspan:`15` Data organization
 
 -  .. row 2
 
@@ -2820,6 +2820,10 @@ organization is given as an example for the first pixel 
only.
-
-  Bit
 
+   -  15
+
+   -  14
+
-  13
 
-  12
@@ -2867,6 +2871,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -2902,6 +2910,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -2937,6 +2949,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -2972,6 +2988,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  r\ :sub:`7`
 
-  r\ :sub:`6`
@@ -3007,6 +3027,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3042,6 +3066,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3077,6 +3105,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3112,6 +3144,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  r\ :sub:`7`
 
-  r\ :sub:`6`
@@ -3147,6 +3183,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3182,6 +3222,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3217,6 +3261,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  g\ :sub:`7`
 
-  g\ :sub:`6`
@@ -3252,6 +3300,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  r\ :sub:`7`
 
-  r\ :sub:`6`
@@ -3287,6 +3339,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  0
 
-  0
@@ -3320,6 +3376,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3355,6 +3415,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`7`
 
-  b\ :sub:`6`
@@ -3388,6 +3452,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  0
 
-  0
@@ -3423,6 +3491,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`9`
 
-  b\ :sub:`8`
@@ -3456,6 +3528,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`1`
 
-  b\ :sub:`0`
@@ -3491,6 +3567,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`1`
 
-  b\ :sub:`0`
@@ -3524,6 +3604,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`9`
 
-  b\ :sub:`8`
@@ -3555,6 +3639,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  b\ :sub:`9`
 
-  b\ :sub:`8`
@@ -3590,6 +3678,10 @@ organization is given as an example for the first pixel 
only.
 
-  -
 
+   -  -
+
+   -  -
+
-  g\ :sub:`9`
 
-  g\ 

Re: [PATCH] pxa_camera: allow building it if COMPILE_TEST is set

[Robert Jarzmik]

Hans Verkuil  writes:

> Allow building this driver if COMPILE_TEST is set.
>
> Signed-off-by: Hans Verkuil 
Acked-by: Robert Jarzmik 

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: uvcvideo error on second capture from USB device, leading to V4L2_BUF_FLAG_ERROR

[Oliver Collyer]

So today I installed Ubuntu 16.04 on another PC (this one a high spec machine 
with a Rampage V Extreme motherboard) and I reproduced exactly the same errors 
and trace.

Rebooting the same PC back into Windows 10 and using the same USB 3.0 port, I 
had no problems capturing using FFmpeg via DirectShow. I could start and stop 
the capture repeatedly without any warnings or errors appearing in FFmpeg 
(built from the same source).

If the hardware is misbehaving, on both these capture devices, then DS must be 
handling it better than V4L2. Or there is simply an obscure bug in V4L2 which 
only manifests itself with certain devices.

Would providing ssh access to the machine be of interest to anyone who wants to 
debug this?

> On 5 Sep 2016, at 23:19, Andrey Utkin  wrote:
> 
> On Mon, Sep 05, 2016 at 10:43:49PM +0300, Oliver Collyer wrote:
>> I do not have any knowledge of uvcvideo and the associated classes apart 
>> from the studying I’ve done the past day or two, but it seems likely that 
>> error -71 and the later setting of V4L2_BUF_FLAG_ERROR are linked. Also, the 
>> fact it only happens in captures after the first one suggests something 
>> isn’t being cleared down or released properly in uvcvideo/v4l2-core at the 
>> end of the first capture.
>> 
>> Let me know what I need to do next to further narrow it down.
> 
> Have tried to reproduce this (with kernel 4.6.0 and fresh build of
> ffmpeg) with uvcvideo-driven laptop webcam, and it doesn't happen to me.
> Also -EPROTO in uvcvideo comes from low-level USB stuff, see
> drivers/media/usb/uvc/uvc_status.c:127:
> 
>   case -EPROTO:   /* Device is disconnected (reported by some
>* host controller). */
> 
> So it seems like hardware misbehaves. To further clairify situation, I
> have such question: do the devices work in other operation systems on
> the same machine?
> 
> Reviewing your original email mentioning that two different devices
> reproduce same problem, which is apparently related to disconnection in
> the middle of USB communication, I came to me that the connected device
> may be underpowered. So,
> - try plugging your devices through reliable _active_ USB hub,
> - use the most reliable cables you can get,
> - plug into USB 3.0 port if available - it should provide more power
>   than 1.0 and 2.0.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.9] Make pxa_camera standalone

[Hans Verkuil]

This patch series removes the soc-camera dependency of pxa_camera.

Another step closer to being able to drop soc-camera as a framework.

Regards,

Hans

The following changes since commit e62c30e76829d46bf11d170fd81b735f13a014ac:

  [media] smiapp: Remove set_xclk() callback from hwconfig (2016-09-05 
15:53:20 -0300)


are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git pxa

for you to fetch changes up to 3c8f129464dcd351a34e27daafc01e2baf259729:

  pxa_camera: allow building it if COMPILE_TEST is set (2016-09-06 
12:37:45 +0200)



Hans Verkuil (1):
  pxa_camera: allow building it if COMPILE_TEST is set

Robert Jarzmik (14):
  media: mt9m111: make a standalone v4l2 subdevice
  media: mt9m111: use only the SRGB colorspace
  media: mt9m111: move mt9m111 out of soc_camera
  media: platform: pxa_camera: convert to vb2
  media: platform: pxa_camera: trivial move of functions
  media: platform: pxa_camera: introduce sensor_call
  media: platform: pxa_camera: make printk consistent
  media: platform: pxa_camera: add buffer sequencing
  media: platform: pxa_camera: remove set_selection
  media: platform: pxa_camera: make a standalone v4l2 device
  media: platform: pxa_camera: add debug register access
  media: platform: pxa_camera: change stop_streaming semantics
  media: platform: pxa_camera: move pxa_camera out of soc_camera
  media: platform: pxa_camera: fix style

 drivers/media/i2c/Kconfig|7 +
 drivers/media/i2c/Makefile   |1 +
 drivers/media/i2c/{soc_camera => }/mt9m111.c |   59 ++--
 drivers/media/i2c/soc_camera/Kconfig |7 +-
 drivers/media/i2c/soc_camera/Makefile|1 -
 drivers/media/platform/Kconfig   |9 +
 drivers/media/platform/Makefile  |1 +
 drivers/media/platform/{soc_camera => }/pxa_camera.c | 1449 
++-

 drivers/media/platform/soc_camera/Kconfig|8 -
 drivers/media/platform/soc_camera/Makefile   |1 -
 include/linux/platform_data/media/camera-pxa.h   |2 +
 11 files changed, 881 insertions(+), 664 deletions(-)
 rename drivers/media/i2c/{soc_camera => }/mt9m111.c (94%)
 rename drivers/media/platform/{soc_camera => }/pxa_camera.c (61%)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Build fails

[Hans Verkuil]

On 09/06/16 12:21, Timo Helkiö wrote:

make -C /omat/media_build/v4l allyesconfig
make[1]: Entering directory '/omat/media_build/v4l'
No version yet, using 4.4.0-36-generic
make[2]: Entering directory '/omat/media_build/linux'
Syncing with dir ../media/
Applying patches for kernel 4.4.0-36-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.7_dma_attrs.patch
patch -s -f -N -p1 -i ../backports/v4.6_i2c_mux.patch
1 out of 2 hunks FAILED
Makefile:138: recipe for target 'apply_patches' failed
make[2]: *** [apply_patches] Error 1
make[2]: Leaving directory '/omat/media_build/linux'
Makefile:369: recipe for target 'allyesconfig' failed
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory '/omat/media_build/v4l'
Makefile:26: recipe for target 'allyesconfig' failed
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 490.


Fixed 15 minutes ago in the media_build repo!

Hans




 Timo Helkiö
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] pxa_camera: allow building it if COMPILE_TEST is set

[Hans Verkuil]

Allow building this driver if COMPILE_TEST is set.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 09ad065..2ebf170 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -93,7 +93,8 @@ config VIDEO_OMAP3_DEBUG

 config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
-   depends on VIDEO_DEV && PXA27x && HAS_DMA
+   depends on VIDEO_DEV && HAS_DMA
+   depends on PXA27x || COMPILE_TEST
select VIDEOBUF2_DMA_SG
select SG_SPLIT
---help---
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v4l: vsp1: Move subdev operations from HGO to common histogram code

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2016-09-05 18:13:39 +0300, Laurent Pinchart wrote:
> The code will be shared with the HGT entity, move it to the generic
> histogram implementation.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/platform/vsp1/vsp1_drv.c   |   7 +-
>  drivers/media/platform/vsp1/vsp1_hgo.c   | 308 ++--
>  drivers/media/platform/vsp1/vsp1_hgo.h   |   7 +-
>  drivers/media/platform/vsp1/vsp1_histo.c | 334 
> +--
>  drivers/media/platform/vsp1/vsp1_histo.h |  25 ++-
>  5 files changed, 355 insertions(+), 326 deletions(-)
> 



>  int vsp1_histogram_init(struct vsp1_device *vsp1, struct vsp1_histogram 
> *histo,
> - const char *name, size_t data_size, u32 format)
> + enum vsp1_entity_type type, const char *name,
> + const struct vsp1_entity_operations *ops,
> + const unsigned int *formats, unsigned int num_formats,
> + size_t data_size, u32 meta_format)
>  {
>   int ret;
>  
> - histo->vsp1 = vsp1;
> + histo->formats = formats;
> + histo->num_formats = num_formats;
>   histo->data_size = data_size;
> - histo->format = format;
> + histo->meta_format = meta_format;
>  
>   histo->pad.flags = MEDIA_PAD_FL_SINK;
>   histo->video.vfl_dir = VFL_DIR_RX;
> @@ -268,7 +559,16 @@ int vsp1_histogram_init(struct vsp1_device *vsp1, struct 
> vsp1_histogram *histo,
>   INIT_LIST_HEAD(>irqqueue);
>   init_waitqueue_head(>wait_queue);
>  
> - /* Initialize the media entity... */
> + /* Initialize the VSP entity... */
> + histo->entity.ops = ops;
> + histo->entity.type = type;
> +
> + ret = vsp1_entity_init(vsp1, >entity, name, 2, _ops,
> +MEDIA_ENT_F_PROC_VIDEO_STATISTICS);
> + if (ret < 0)
> + return ret;
> +
> + /* ... and the media entity... */
>   ret = media_entity_pads_init(>video.entity, 1, >pad);
>   if (ret < 0)
>   return ret;


You forgot to update the histo video device name to match the subdevice 
name here. Something like this makes vsp-tests work for me again.

@@ -577,7 +577,7 @@ int vsp1_histogram_init(struct vsp1_device *vsp1, struct 
vsp1_histogram *histo,
histo->video.v4l2_dev = >v4l2_dev;
histo->video.fops = _v4l2_fops;
snprintf(histo->video.name, sizeof(histo->video.name),
-"%s histo", name);
+"%s histo", histo->entity.subdev.name);
histo->video.vfl_type = VFL_TYPE_GRABBER;
histo->video.release = video_device_release_empty;
histo->video.ioctl_ops = _v4l2_ioctl_ops;

Without this fix the names listed using media-ctl -p show:

- entity 1: hgo histo (1 pad, 1 link)

Instead as it did before:

- entity 1: fe928000.vsp1 hgo histo (1 pad, 1 link)

Other then that

Tested-by: Niklas Söderlund 

> @@ -293,10 +593,10 @@ int vsp1_histogram_init(struct vsp1_device *vsp1, 
> struct vsp1_histogram *histo,
>   histo->queue.ops = _video_queue_qops;
>   histo->queue.mem_ops = _vmalloc_memops;
>   histo->queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> - histo->queue.dev = histo->vsp1->dev;
> + histo->queue.dev = vsp1->dev;
>   ret = vb2_queue_init(>queue);
>   if (ret < 0) {
> - dev_err(histo->vsp1->dev, "failed to initialize vb2 queue\n");
> + dev_err(vsp1->dev, "failed to initialize vb2 queue\n");
>   goto error;
>   }
>  
> @@ -304,7 +604,7 @@ int vsp1_histogram_init(struct vsp1_device *vsp1, struct 
> vsp1_histogram *histo,
>   histo->video.queue = >queue;
>   ret = video_register_device(>video, VFL_TYPE_GRABBER, -1);
>   if (ret < 0) {
> - dev_err(histo->vsp1->dev, "failed to register video device\n");
> + dev_err(vsp1->dev, "failed to register video device\n");
>   goto error;
>   }
>  
> @@ -314,11 +614,3 @@ error:
>   vsp1_histogram_cleanup(histo);
>   return ret;
>  }
> -
> -void vsp1_histogram_cleanup(struct vsp1_histogram *histo)
> -{
> - if (video_is_registered(>video))
> - video_unregister_device(>video);
> -
> - media_entity_cleanup(>video.entity);
> -}



-- 
Regards,
Niklas Söderlund
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Build fails

[Timo Helkiö]

make -C /omat/media_build/v4l allyesconfig
make[1]: Entering directory '/omat/media_build/v4l'
No version yet, using 4.4.0-36-generic
make[2]: Entering directory '/omat/media_build/linux'
Syncing with dir ../media/
Applying patches for kernel 4.4.0-36-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.7_dma_attrs.patch
patch -s -f -N -p1 -i ../backports/v4.6_i2c_mux.patch
1 out of 2 hunks FAILED
Makefile:138: recipe for target 'apply_patches' failed
make[2]: *** [apply_patches] Error 1
make[2]: Leaving directory '/omat/media_build/linux'
Makefile:369: recipe for target 'allyesconfig' failed
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory '/omat/media_build/v4l'
Makefile:26: recipe for target 'allyesconfig' failed
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 490.


 Timo Helkiö
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 13/14] media: platform: pxa_camera: move pxa_camera out of soc_camera

[Hans Verkuil]

Hi Robert,

On 09/06/16 11:04, Robert Jarzmik wrote:

As the conversion to a v4l2 standalone device is finished, move
pxa_camera one directory up and finish severing any dependency to
soc_camera.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/Kconfig   | 8 
 drivers/media/platform/Makefile  | 1 +
 drivers/media/platform/{soc_camera => }/pxa_camera.c | 0
 drivers/media/platform/soc_camera/Kconfig| 8 
 drivers/media/platform/soc_camera/Makefile   | 1 -
 5 files changed, 9 insertions(+), 9 deletions(-)
 rename drivers/media/platform/{soc_camera => }/pxa_camera.c (100%)


Can you make a new patch that adds an entry to the MAINTAINERS file for 
this driver?


Thanks!

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2-ctl does not show all parameters for HVR-1900

[Hans Verkuil]

On 09/05/16 21:01, de_witte_k...@telenet.be wrote:


In short:
Is it normal that I can use the v4l2-ctl command to adjust brightness, 
saturation, hue, etc but not to adjust more interesting parameters like 
bitrate, aspect ration, etc?

Working:
pi@raspberrypi:~ $ cat /sys/class/pvrusb2/sn-4034395926/ctl_hue/cur_val
0
pi@raspberrypi:~ $ v4l2-ctl -c hue=1
pi@raspberrypi:~ $ cat /sys/class/pvrusb2/sn-4034395926/ctl_hue/cur_val
1


Not working:
pi@raspberrypi:~ $ cat 
/sys/class/pvrusb2/sn-4034395926/ctl_video_bitrate/cur_val
600
pi@raspberrypi:~ $ v4l2-ctl -c bitrate=600
unknown control 'bitrate'
pi@raspberrypi:~ $ v4l2-ctl -c video_bitrate=600
unknown control 'video_bitrate'
pi@raspberrypi:~ $ v4l2-ctl -c ctl_video_bitrate=600
unknown control 'ctl_video_bitrate'

the pvrusb2 driver has created all sysfs parameters and they work using the 
"echo" method but I thought this was also the purpose of the v4l2-ctl command, 
correct?

Some details, let me know if you need more.


The problem here is that the pvrusb2 driver predates the V4L2 control 
framework for handling controls. Instead it has its own implementation 
and that is known to be buggy. For a variety of reasons it is not easy 
to rework this driver to use the control framework.


I've CC-ed the maintainer, perhaps he can make a patch that at least 
exposes these controls through the QUERYCTRL ioctl (they don't seem to 
turn up when enumerating the controls, which is why the above fails).


Regards,

Hans



Regards,
Koen


pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.13+ #894 Mon Jun 13 12:43:26 BST 2016 armv6l GNU/Linux
pi@raspberrypi:~ $



pi@raspberrypi:~ $ v4l2-ctl --all
Driver Info (not using libv4l2):
Driver name   : pvrusb2
Card type : WinTV HVR-1900 Model 73xxx
Bus info  : usb-2098.usb-1.3
Driver version: 4.4.13
Capabilities  : 0x81270001
Video Capture
Tuner
Audio
Radio
Read/Write
Extended Pix Format
Device Capabilities
Device Caps   : 0x01230001
Video Capture
Tuner
Audio
Read/Write
Extended Pix Format
Priority: 2
Frequency for tuner 0: 980 (61.25 MHz)
Tuner 0:
Name :
Capabilities : 62.5 kHz multi-standard stereo lang1 lang2 
freq-bands
Frequency range  : 44.000 MHz - 958.000 MHz
Signal strength/AFC  : 0%/0
Current audio mode   : stereo
Available subchannels: mono lang2
Video input : 0 (television: ok)
Audio input : 0 (PVRUSB2 Audio)
Video Standard = 0x
Format Video Capture:
Width/Height  : 720/480
Pixel Format  : ''
Field : Interlaced
Bytes per Line: 0
Size Image: 32768
Colorspace: Unknown ()
Flags :
Crop Capability Video Capture:
Bounds  : Left 0, Top 0, Width 0, Height 0
Default : Left 0, Top 0, Width 0, Height 0
Pixel Aspect: 0/0
Crop: Left 0, Top 0, Width 720, Height 480
Streaming Parameters Video Capture:
Frames per second: 25.000 (25/1)
Read buffers : 2
 brightness (int): min=0 max=255 step=1 default=128 
value=128
   contrast (int): min=0 max=127 step=1 default=68 
value=68
 saturation (int): min=0 max=127 step=1 default=64 
value=64
hue (int): min=-128 max=127 step=1 default=0 
value=0
 volume (int): min=0 max=65535 step=1 default=62000 
value=62000
balance (int): min=-32768 max=32767 step=1 
default=0 value=0
   bass (int): min=-32768 max=32767 step=1 
default=0 value=0
 treble (int): min=-32768 max=32767 step=1 
default=0 value=0
   mute (bool)   : default=0 value=0

dmesg output:


[4.162258] scsi host0: usb-storage 1-1.2:1.0
[4.258220] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[4.382814] usb 1-1.3: New USB device found, idVendor=2040, idProduct=7300
[4.391713] usb 1-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[4.400866] usb 1-1.3: Product: WinTV
[4.406259] usb 1-1.3: Manufacturer: Hauppauge
[4.412471] usb 1-1.3: SerialNumber: 7300-00-F077FF16
...
[   10.463517] media: Linux media interface: v0.10
[   10.547654] Linux video capture interface: v2.00
[   10.660771] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[   10.781359] pvrusb2: Hardware description: WinTV HVR-1900 Model 73xxx
[   10.798664] usbcore: registered new interface driver pvrusb2
[   10.798702] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 
Encoder/Tuner
[   10.798721] pvrusb2: Debug mask is 1 (0x1)
[   11.484744] 

Re: [PATCH v4 1/5] media: Determine early whether an IOCTL is supported

[Mauro Carvalho Chehab]

Em Thu, 11 Aug 2016 23:29:14 +0300
Sakari Ailus  escreveu:

> Preparation for refactoring media IOCTL handling to unify common parts.
> 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/media-device.c | 54 
> ++--
>  1 file changed, 52 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 1795abe..aedd64e 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -419,13 +419,41 @@ static long media_device_get_topology(struct 
> media_device *mdev,
>   return 0;
>  }
>  
> -static long media_device_ioctl(struct file *filp, unsigned int cmd,
> -unsigned long arg)
> +#define MEDIA_IOC(__cmd) \
> + [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd }
> +
> +/* the table is indexed by _IOC_NR(cmd) */
> +struct media_ioctl_info {
> + unsigned int cmd;
> +};
> +
> +static const struct media_ioctl_info ioctl_info[] = {
> + MEDIA_IOC(DEVICE_INFO),
> + MEDIA_IOC(ENUM_ENTITIES),
> + MEDIA_IOC(ENUM_LINKS),
> + MEDIA_IOC(SETUP_LINK),
> + MEDIA_IOC(G_TOPOLOGY),
> +};
> +
> +static inline long is_valid_ioctl(const struct media_ioctl_info *info,
> +   unsigned int cmd)
> +{
> + return (_IOC_NR(cmd) >= ARRAY_SIZE(ioctl_info)
> + || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0;
> +}
> +
> +static long __media_device_ioctl(
> + struct file *filp, unsigned int cmd, void __user *arg,
> + const struct media_ioctl_info *info_array)
>  {
>   struct media_devnode *devnode = media_devnode_data(filp);
>   struct media_device *dev = devnode->media_dev;
>   long ret;
>  
> + ret = is_valid_ioctl(info_array, cmd);
> + if (ret)
> + return ret;
> +
>   mutex_lock(>graph_mutex);
>   switch (cmd) {
>   case MEDIA_IOC_DEVICE_INFO:
> @@ -461,6 +489,13 @@ static long media_device_ioctl(struct file *filp, 
> unsigned int cmd,
>   return ret;
>  }
>  
> +static long media_device_ioctl(struct file *filp, unsigned int cmd,
> +unsigned long arg)
> +{
> + return __media_device_ioctl(
> + filp, cmd, (void __user *)arg, ioctl_info);
> +}
> +
>  #ifdef CONFIG_COMPAT
>  
>  struct media_links_enum32 {
> @@ -491,6 +526,14 @@ static long media_device_enum_links32(struct 
> media_device *mdev,
>  
>  #define MEDIA_IOC_ENUM_LINKS32   _IOWR('|', 0x02, struct 
> media_links_enum32)


Hmm...

> +static const struct media_ioctl_info compat_ioctl_info[] = {
> + MEDIA_IOC(DEVICE_INFO),
> + MEDIA_IOC(ENUM_ENTITIES),
> + MEDIA_IOC(ENUM_LINKS32),
> + MEDIA_IOC(SETUP_LINK),
> + MEDIA_IOC(G_TOPOLOGY),
> +};
> +
>  static long media_device_compat_ioctl(struct file *filp, unsigned int cmd,
> unsigned long arg)
>  {
> @@ -498,6 +541,13 @@ static long media_device_compat_ioctl(struct file *filp, 
> unsigned int cmd,
>   struct media_device *dev = devnode->media_dev;
>   long ret;
>  
> + /*
> +  * The number of supported IOCTLs is the same for both regular and
> +  * compat cases. Instead of passing the sizes around, ensure that
> +  * they match.
> +  */
> + BUILD_BUG_ON(ARRAY_SIZE(ioctl_info) != ARRAY_SIZE(compat_ioctl_info));
> +
>   switch (cmd) {
>   case MEDIA_IOC_ENUM_LINKS32:
>   mutex_lock(>graph_mutex);


Why do we need the above? The only ioctl that it is handled inside
the compat logic is MEDIA_IOC_ENUM_LINKS. all the others fall back
to the usual handler, and we don't intend to add any other new
special case, as we're now using a different logic to handle 32 bit
pointers passed to a 64 bit Kernel that it is compatible with both 32
and 64 bits.

So, we don't expect to have the V4L2 compat32 mess here, but, instead,
to keep this untouched as we add more ioctl's.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Em Mon, 5 Sep 2016 20:01:22 +0100
Chris Mayo  escreveu:

> On 05/09/16 14:25, Mauro Carvalho Chehab wrote:
> > Em Mon, 5 Sep 2016 15:13:04 +0200
> > Markus Heiser  escreveu:
> >   
> >> Hi Mauro, (Hi Chris)
> >>
> >> sorry for my late reply. I test the v4-utils on my HTPC,
> >> where I'am not often have time for experimentation ;-)
> >>
> >> Am 24.08.2016 um 16:52 schrieb Mauro Carvalho Chehab 
> >> :
> >>  
> >>> Em Wed, 24 Aug 2016 11:49:27 -0300
> >>> Mauro Carvalho Chehab  escreveu:
> >>> 
>  Hi Markus,
> 
>  Em Wed, 10 Aug 2016 11:52:19 +0200
>  Markus Heiser  escreveu:
>  
> > From: Markus Heiser 
> >
> > From: Heiser, Markus 
> >
> > The vdr format was broken, I got '(null)' entries
> >
> > HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
> > 0-:1:2--:3:4-:
> >
> > refering to the VDR Wikis ...
> >
> > * LinuxTV: 
> > http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
> > * german comunity Wiki: 
> > http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
> >
> > There is no field at position 4 / in between "Source" and "SRate" which
> > might have a value. I suppose the '(null):' is the result of pointing
> > to *nothing*.
> >
> > An other mistake is the ending colon (":") at the line. It is not
> > explicit specified but adding an collon to the end of an channel entry
> > will prevent players (like mpv or mplayer) from parsing the line (they
> > will ignore these lines).
> >
> > At least: generating a channel list with
> >
> >  dvbv5-scan --output-format=vdr ...
> >
> > will result in the same defective channel entry, containing "(null):"
> > and the leading collon ":".  
> 
>  Sorry for taking too long to handle that. I usually stop handling
>  patches one week before the merge window, returning to merge only
>  after -rc1. This time, it took a little more time, due to the Sphinx
>  changes, as I was needing some patches to be merged upstream, in order
>  to change my handling scripts to work with the new way.
> 
>  Anyway, with regards to this patch, not sure if you saw, but
>  Chris Mayo sent us a different fix for it:
> 
>   https://patchwork.linuxtv.org/patch/35803/
> 
>  With is meant to support VDR format as used on version 2.2. Not sure
>  if this format is backward-compatible with versions 1.x, but usually
>  VDR just adds new parameters to the lines.
> 
>  So, I'm inclined to merge Chris patch instead of yours.
> 
>  So, could you please test if his patch does what's needed?
> >>>
> >>> PS.: If the formats for v 1.x are not compatible with the ones for
> >>> v2.x, then the best would be to change the code to add a new format
> >>> for vdr v2.x, while keep supporting vdr v1.x.
> >>
> >> Hmm, I'am a bit confused about vdr's channel.conf v1.x and v2.x.
> >>
> >> I can't find any documentation on this and since there is no
> >> version control system for vdr it is hard to dig the history.  
> > 
> > Yeah, I see your pain.
> >   
> >> As far as I can see, Chris fixes an issue with DVB-T and the
> >> issue with the leading ":".
> >>
> >> My patch fixes an issue with DVB-S/2 entry-location (and the
> >> issue with the leading ":").
> >>
> >> I will give it a try to merge my changes on top of Chris's
> >> patch and test DVB-T & DVB-S2 on my HTPC with an vdr server.  
> 
> Thanks. I can't test DVB-S(2) so I decided to leave that part alone.
> 
> > 
> > Ok, that would be great! it would also be good if either of you could
> > take a look on how to allow libdvbv5 to support both VDR versions 1.x and
> > 2.x. I don't use VDR here (afaikt, it doesn't support ISDB-T - and nowadays
> > I only have DVB/ATSC via my RF test generators), but, IMHO, being able to
> > provide output on both formats can be useful for other VDR users.
> >   
> 
> Is supporting vdr v1.x necessary?

That is a good question. I don't have a strong opinion here.

> 
> I believe v1.7.x were developer releases leading up to v2.0.
> Last stable v1.x was 2012-02-14: Version 1.6.0-3. With v1.6.0 being from 2008!

Hmm... 4 years ago... LTS distros usually lasts 5 years. So, it is possible
that someone might have a LTS version shipped with it. On the other hand,
it sounds unlikely that someone would be running vdr from LTS while using
the latest v4l-utils version (except if there are some VDR extensions people
would need that only runs on 1.x versions).

> Looks like v2.2.0 added parameters N, Q and X for S2 and T2. But libdvbv5 does
> not currently appear to output these (at least Q and X for T2).

I guess the latest version at the time I 

[PATCH 1/1] ad5820: Use bool for boolean values

[Sakari Ailus]

The driver used integers for what boolean would have been a better fit.
Use boolean instead.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/ad5820.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
index d7ad5c1..fd4c5f6 100644
--- a/drivers/media/i2c/ad5820.c
+++ b/drivers/media/i2c/ad5820.c
@@ -58,7 +58,7 @@ struct ad5820_device {
struct mutex power_lock;
int power_count;
 
-   unsigned int standby : 1;
+   bool standby;
 };
 
 static int ad5820_write(struct ad5820_device *coil, u16 data)
@@ -108,7 +108,7 @@ static int ad5820_update_hw(struct ad5820_device *coil)
 /*
  * Power handling
  */
-static int ad5820_power_off(struct ad5820_device *coil, int standby)
+static int ad5820_power_off(struct ad5820_device *coil, bool standby)
 {
int ret = 0, ret2;
 
@@ -117,7 +117,7 @@ static int ad5820_power_off(struct ad5820_device *coil, int 
standby)
 * (single power line control for both coil and sensor).
 */
if (standby) {
-   coil->standby = 1;
+   coil->standby = true;
ret = ad5820_update_hw(coil);
}
 
@@ -127,7 +127,7 @@ static int ad5820_power_off(struct ad5820_device *coil, int 
standby)
return ret2;
 }
 
-static int ad5820_power_on(struct ad5820_device *coil, int restore)
+static int ad5820_power_on(struct ad5820_device *coil, bool restore)
 {
int ret;
 
@@ -137,7 +137,7 @@ static int ad5820_power_on(struct ad5820_device *coil, int 
restore)
 
if (restore) {
/* Restore the hardware settings. */
-   coil->standby = 0;
+   coil->standby = false;
ret = ad5820_update_hw(coil);
if (ret)
goto fail;
@@ -145,7 +145,7 @@ static int ad5820_power_on(struct ad5820_device *coil, int 
restore)
return 0;
 
 fail:
-   coil->standby = 1;
+   coil->standby = true;
regulator_disable(coil->vana);
 
return ret;
@@ -227,7 +227,8 @@ ad5820_set_power(struct v4l2_subdev *subdev, int on)
 * update the power state.
 */
if (coil->power_count == !on) {
-   ret = on ? ad5820_power_on(coil, 1) : ad5820_power_off(coil, 1);
+   ret = on ? ad5820_power_on(coil, true) :
+   ad5820_power_off(coil, true);
if (ret < 0)
goto done;
}
@@ -279,7 +280,7 @@ static int ad5820_suspend(struct device *dev)
if (!coil->power_count)
return 0;
 
-   return ad5820_power_off(coil, 0);
+   return ad5820_power_off(coil, false);
 }
 
 static int ad5820_resume(struct device *dev)
@@ -291,7 +292,7 @@ static int ad5820_resume(struct device *dev)
if (!coil->power_count)
return 0;
 
-   return ad5820_power_on(coil, 1);
+   return ad5820_power_on(coil, true);
 }
 
 #else
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 13/14] media: platform: pxa_camera: move pxa_camera out of soc_camera

[Robert Jarzmik]

As the conversion to a v4l2 standalone device is finished, move
pxa_camera one directory up and finish severing any dependency to
soc_camera.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/Kconfig   | 8 
 drivers/media/platform/Makefile  | 1 +
 drivers/media/platform/{soc_camera => }/pxa_camera.c | 0
 drivers/media/platform/soc_camera/Kconfig| 8 
 drivers/media/platform/soc_camera/Makefile   | 1 -
 5 files changed, 9 insertions(+), 9 deletions(-)
 rename drivers/media/platform/{soc_camera => }/pxa_camera.c (100%)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 46f14ddeee65..09ad0659e1f8 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -91,6 +91,14 @@ config VIDEO_OMAP3_DEBUG
---help---
  Enable debug messages on OMAP 3 camera controller driver.
 
+config VIDEO_PXA27x
+   tristate "PXA27x Quick Capture Interface driver"
+   depends on VIDEO_DEV && PXA27x && HAS_DMA
+   select VIDEOBUF2_DMA_SG
+   select SG_SPLIT
+   ---help---
+ This is a v4l2 driver for the PXA27x Quick Capture Interface
+
 config VIDEO_S3C_CAMIF
tristate "Samsung S3C24XX/S3C64XX SoC Camera Interface driver"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 536d1d8ef022..44baff208452 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
 obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
 
 obj-$(CONFIG_VIDEO_OMAP3)  += omap3isp/
+obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o soc_camera/soc_mediabus.o
 
 obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
 
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/pxa_camera.c
similarity index 100%
rename from drivers/media/platform/soc_camera/pxa_camera.c
rename to drivers/media/platform/pxa_camera.c
diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 6b87b3a9d546..8b046dc49392 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -17,14 +17,6 @@ config SOC_CAMERA_PLATFORM
help
  This is a generic SoC camera platform driver, useful for testing
 
-config VIDEO_PXA27x
-   tristate "PXA27x Quick Capture Interface driver"
-   depends on VIDEO_DEV && PXA27x && HAS_DMA
-   select VIDEOBUF2_DMA_SG
-   select SG_SPLIT
-   ---help---
- This is a v4l2 driver for the PXA27x Quick Capture Interface
-
 config VIDEO_RCAR_VIN_OLD
tristate "R-Car Video Input (VIN) support (DEPRECATED)"
depends on VIDEO_DEV && SOC_CAMERA
diff --git a/drivers/media/platform/soc_camera/Makefile 
b/drivers/media/platform/soc_camera/Makefile
index ee8f9a4ae2a4..e189870a333d 100644
--- a/drivers/media/platform/soc_camera/Makefile
+++ b/drivers/media/platform/soc_camera/Makefile
@@ -7,6 +7,5 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM)   += soc_camera_platform.o
 
 # soc-camera host drivers have to be linked after camera drivers
 obj-$(CONFIG_VIDEO_ATMEL_ISI)  += atmel-isi.o
-obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
 obj-$(CONFIG_VIDEO_RCAR_VIN_OLD)   += rcar_vin.o
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 06/14] media: platform: pxa_camera: introduce sensor_call

[Robert Jarzmik]

Introduce sensor_call(), which will be used for all sensor invocations.
This is a preparation move to v4l2 device conversion, ie. soc_camera
adherence removal.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/pxa_camera.c | 27 ++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index 62e3f69a17ec..3091ec708a46 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -168,6 +168,9 @@
CICR0_PERRM | CICR0_QDM | CICR0_CDM | CICR0_SOFM | \
CICR0_EOFM | CICR0_FOM)
 
+#define sensor_call(cam, o, f, args...) \
+   v4l2_subdev_call(sd, o, f, ##args)
+
 /*
  * Structures
  */
@@ -731,7 +734,7 @@ static void pxa_camera_setup_cicr(struct soc_camera_device 
*icd,
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
unsigned long dw, bpp;
u32 cicr0, cicr1, cicr2, cicr3, cicr4 = 0, y_skip_top;
-   int ret = v4l2_subdev_call(sd, sensor, g_skip_top_lines, _skip_top);
+   int ret = sensor_call(pcdev, sensor, g_skip_top_lines, _skip_top);
 
if (ret < 0)
y_skip_top = 0;
@@ -1073,7 +1076,7 @@ static int pxa_camera_set_bus_param(struct 
soc_camera_device *icd)
if (ret < 0)
return ret;
 
-   ret = v4l2_subdev_call(sd, video, g_mbus_config, );
+   ret = sensor_call(pcdev, video, g_mbus_config, );
if (!ret) {
common_flags = soc_mbus_config_compatible(,
  bus_flags);
@@ -1117,7 +1120,7 @@ static int pxa_camera_set_bus_param(struct 
soc_camera_device *icd)
}
 
cfg.flags = common_flags;
-   ret = v4l2_subdev_call(sd, video, s_mbus_config, );
+   ret = sensor_call(pcdev, video, s_mbus_config, );
if (ret < 0 && ret != -ENOIOCTLCMD) {
dev_dbg(icd->parent, "camera s_mbus_config(0x%lx) returned 
%d\n",
common_flags, ret);
@@ -1144,7 +1147,7 @@ static int pxa_camera_try_bus_param(struct 
soc_camera_device *icd,
if (ret < 0)
return ret;
 
-   ret = v4l2_subdev_call(sd, video, g_mbus_config, );
+   ret = sensor_call(pcdev, video, g_mbus_config, );
if (!ret) {
common_flags = soc_mbus_config_compatible(,
  bus_flags);
@@ -1195,7 +1198,7 @@ static int pxa_camera_get_formats(struct 
soc_camera_device *icd, unsigned int id
};
const struct soc_mbus_pixelfmt *fmt;
 
-   ret = v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, );
+   ret = sensor_call(pcdev, pad, enum_mbus_code, NULL, );
if (ret < 0)
/* No more formats */
return 0;
@@ -1303,7 +1306,7 @@ static int pxa_camera_set_selection(struct 
soc_camera_device *icd,
if (pcdev->platform_flags & PXA_CAMERA_PCLK_EN)
icd->sense = 
 
-   ret = v4l2_subdev_call(sd, pad, set_selection, NULL, );
+   ret = sensor_call(pcdev, pad, set_selection, NULL, );
 
icd->sense = NULL;
 
@@ -1314,7 +1317,7 @@ static int pxa_camera_set_selection(struct 
soc_camera_device *icd,
}
sel->r = sdsel.r;
 
-   ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, );
+   ret = sensor_call(pcdev, pad, get_fmt, NULL, );
if (ret < 0)
return ret;
 
@@ -1326,7 +1329,7 @@ static int pxa_camera_set_selection(struct 
soc_camera_device *icd,
v4l_bound_align_image(>width, 48, 2048, 1,
>height, 32, 2048, 0,
fourcc == V4L2_PIX_FMT_YUV422P ? 4 : 0);
-   ret = v4l2_subdev_call(sd, pad, set_fmt, NULL, );
+   ret = sensor_call(pcdev, pad, set_fmt, NULL, );
if (ret < 0)
return ret;
 
@@ -1391,7 +1394,7 @@ static int pxa_camera_set_fmt(struct soc_camera_device 
*icd,
mf->colorspace  = pix->colorspace;
mf->code= xlate->code;
 
-   ret = v4l2_subdev_call(sd, pad, set_fmt, NULL, );
+   ret = sensor_call(pcdev, pad, set_fmt, NULL, );
 
if (mf->code != xlate->code)
return -EINVAL;
@@ -1466,7 +1469,7 @@ static int pxa_camera_try_fmt(struct soc_camera_device 
*icd,
mf->colorspace  = pix->colorspace;
mf->code= xlate->code;
 
-   ret = v4l2_subdev_call(sd, pad, set_fmt, _cfg, );
+   ret = sensor_call(pcdev, pad, set_fmt, _cfg, );
if (ret < 0)
return ret;
 
@@ -1524,7 +1527,7 @@ static int pxa_camera_suspend(struct device *dev)
 
if (pcdev->soc_host.icd) {
struct v4l2_subdev *sd = 
soc_camera_to_subdev(pcdev->soc_host.icd);
-   ret = v4l2_subdev_call(sd, core, s_power, 0);
+   ret = 

[PATCH v6 12/14] media: platform: pxa_camera: change stop_streaming semantics

[Robert Jarzmik]

Instead of the legacy behavior where it was required to wait for all
video buffers to be finished by the hardware, use a cancel like strategy
: as soon as the stop_streaming() call is done, abort all DMA transfers,
report the already buffers as failed and return.

This makes stop_streaming() more a "cancel capture" than a "wait for end
of capture" semantic.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/pxa_camera.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index fb89b85f59ab..868c6ad4784c 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -523,7 +523,8 @@ static void pxa_camera_stop_capture(struct pxa_camera_dev 
*pcdev)
 }
 
 static void pxa_camera_wakeup(struct pxa_camera_dev *pcdev,
- struct pxa_buffer *buf)
+ struct pxa_buffer *buf,
+ enum vb2_buffer_state state)
 {
struct vb2_buffer *vb = >vbuf.vb2_buf;
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
@@ -645,7 +646,7 @@ static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
}
buf->active_dma &= ~act_dma;
if (!buf->active_dma) {
-   pxa_camera_wakeup(pcdev, buf);
+   pxa_camera_wakeup(pcdev, buf, VB2_BUF_STATE_DONE);
pxa_camera_check_link_miss(pcdev, last_buf->cookie[chan],
   last_issued);
}
@@ -1087,7 +1088,15 @@ static int pxac_vb2_start_streaming(struct vb2_queue 
*vq, unsigned int count)
 
 static void pxac_vb2_stop_streaming(struct vb2_queue *vq)
 {
-   vb2_wait_for_all_buffers(vq);
+   struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vq);
+   struct pxa_buffer *buf, *tmp;
+
+   dev_dbg(pcdev_to_dev(pcdev), "%s active=%p\n",
+   __func__, pcdev->active);
+   pxa_camera_stop_capture(pcdev);
+
+   list_for_each_entry_safe(buf, tmp, >capture, queue)
+   pxa_camera_wakeup(pcdev, buf, VB2_BUF_STATE_ERROR);
 }
 
 static struct vb2_ops pxac_vb2_ops = {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 11/14] media: platform: pxa_camera: add debug register access

[Robert Jarzmik]

Add pxa_camera registers access through advanced video debugging.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/pxa_camera.c | 32 ++
 1 file changed, 32 insertions(+)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index 395cd398c32b..fb89b85f59ab 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -1342,6 +1342,34 @@ static int pxa_camera_check_frame(u32 width, u32 height)
(width & 0x01);
 }
 
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int pxac_vidioc_g_register(struct file *file, void *priv,
+ struct v4l2_dbg_register *reg)
+{
+   struct pxa_camera_dev *pcdev = video_drvdata(file);
+
+   if (reg->reg > CIBR2)
+   return -ERANGE;
+
+   reg->val = __raw_readl(pcdev->base + reg->reg);
+   reg->size = sizeof(__u32);
+   return 0;
+}
+
+static int pxac_vidioc_s_register(struct file *file, void *priv,
+ const struct v4l2_dbg_register *reg)
+{
+   struct pxa_camera_dev *pcdev = video_drvdata(file);
+
+   if (reg->reg > CIBR2)
+   return -ERANGE;
+   if (reg->size != sizeof(__u32))
+   return -EINVAL;
+   __raw_writel(reg->val, pcdev->base + reg->reg);
+   return 0;
+}
+#endif
+
 static int pxac_vidioc_enum_fmt_vid_cap(struct file *filp, void  *priv,
struct v4l2_fmtdesc *f)
 {
@@ -1592,6 +1620,10 @@ static const struct v4l2_ioctl_ops pxa_camera_ioctl_ops 
= {
.vidioc_expbuf  = vb2_ioctl_expbuf,
.vidioc_streamon= vb2_ioctl_streamon,
.vidioc_streamoff   = vb2_ioctl_streamoff,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+   .vidioc_g_register  = pxac_vidioc_g_register,
+   .vidioc_s_register  = pxac_vidioc_s_register,
+#endif
 };
 
 static struct v4l2_clk_ops pxa_camera_mclk_ops = {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 07/14] media: platform: pxa_camera: make printk consistent

[Robert Jarzmik]

Make all print consistent by always using :
 - dev_xxx(pcdev_to_dev(pcdev), )

This prepares the soc_camera adherence removal by making these call rely
on only pcdev, and not the soc_camera icd structure.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/pxa_camera.c | 70 --
 1 file changed, 43 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index 3091ec708a46..026ed308fea8 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -236,6 +236,14 @@ struct pxa_cam {
 
 static const char *pxa_cam_driver_description = "PXA_Camera";
 
+static struct pxa_camera_dev *icd_to_pcdev(struct soc_camera_device *icd)
+{
+   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
+   struct pxa_camera_dev *pcdev = ici->priv;
+
+   return pcdev;
+}
+
 /*
  *  Videobuf operations
  */
@@ -465,7 +473,6 @@ static void pxa_camera_check_link_miss(struct 
pxa_camera_dev *pcdev,
 static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
   enum pxa_camera_active_dma act_dma)
 {
-   struct device *dev = pcdev_to_dev(pcdev);
struct pxa_buffer *buf, *last_buf;
unsigned long flags;
u32 camera_status, overrun;
@@ -476,7 +483,7 @@ static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
spin_lock_irqsave(>lock, flags);
 
camera_status = __raw_readl(pcdev->base + CISR);
-   dev_dbg(dev, "camera dma irq, cisr=0x%x dma=%d\n",
+   dev_dbg(pcdev_to_dev(pcdev), "camera dma irq, cisr=0x%x dma=%d\n",
camera_status, act_dma);
overrun = CISR_IFO_0;
if (pcdev->channels == 3)
@@ -522,7 +529,7 @@ static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
   NULL, _issued);
if (camera_status & overrun &&
last_status != DMA_COMPLETE) {
-   dev_dbg(dev, "FIFO overrun! CISR: %x\n",
+   dev_dbg(pcdev_to_dev(pcdev), "FIFO overrun! CISR: %x\n",
camera_status);
pxa_camera_stop_capture(pcdev);
list_for_each_entry(buf, >capture, queue)
@@ -545,7 +552,6 @@ static u32 mclk_get_divisor(struct platform_device *pdev,
struct pxa_camera_dev *pcdev)
 {
unsigned long mclk = pcdev->mclk;
-   struct device *dev = >dev;
u32 div;
unsigned long lcdclk;
 
@@ -555,7 +561,8 @@ static u32 mclk_get_divisor(struct platform_device *pdev,
/* mclk <= ciclk / 4 (27.4.2) */
if (mclk > lcdclk / 4) {
mclk = lcdclk / 4;
-   dev_warn(dev, "Limiting master clock to %lu\n", mclk);
+   dev_warn(pcdev_to_dev(pcdev),
+"Limiting master clock to %lu\n", mclk);
}
 
/* We verify mclk != 0, so if anyone breaks it, here comes their Oops */
@@ -565,7 +572,7 @@ static u32 mclk_get_divisor(struct platform_device *pdev,
if (pcdev->platform_flags & PXA_CAMERA_MCLK_EN)
pcdev->mclk = lcdclk / (2 * (div + 1));
 
-   dev_dbg(dev, "LCD clock %luHz, target freq %luHz, divisor %u\n",
+   dev_dbg(pcdev_to_dev(pcdev), "LCD clock %luHz, target freq %luHz, 
divisor %u\n",
lcdclk, mclk, div);
 
return div;
@@ -662,7 +669,9 @@ static irqreturn_t pxa_camera_irq(int irq, void *data)
 
 static int pxa_camera_add_device(struct soc_camera_device *icd)
 {
-   dev_info(icd->parent, "PXA Camera driver attached to camera %d\n",
+   struct pxa_camera_dev *pcdev = icd_to_pcdev(icd);
+
+   dev_info(pcdev_to_dev(pcdev), "PXA Camera driver attached to camera 
%d\n",
 icd->devnum);
 
return 0;
@@ -670,7 +679,9 @@ static int pxa_camera_add_device(struct soc_camera_device 
*icd)
 
 static void pxa_camera_remove_device(struct soc_camera_device *icd)
 {
-   dev_info(icd->parent, "PXA Camera driver detached from camera %d\n",
+   struct pxa_camera_dev *pcdev = icd_to_pcdev(icd);
+
+   dev_info(pcdev_to_dev(pcdev), "PXA Camera driver detached from camera 
%d\n",
 icd->devnum);
 }
 
@@ -1081,7 +1092,7 @@ static int pxa_camera_set_bus_param(struct 
soc_camera_device *icd)
common_flags = soc_mbus_config_compatible(,
  bus_flags);
if (!common_flags) {
-   dev_warn(icd->parent,
+   dev_warn(pcdev_to_dev(pcdev),
 "Flags incompatible: camera 0x%x, host 
0x%lx\n",
 cfg.flags, bus_flags);
return -EINVAL;
@@ -1122,7 +1133,7 @@ static int pxa_camera_set_bus_param(struct 
soc_camera_device *icd)
cfg.flags = common_flags;
ret = sensor_call(pcdev, 

[PATCH v6 14/14] media: platform: pxa_camera: fix style

[Robert Jarzmik]

This is a tiny fix for a switch case which quiets 2 checkpatch harmless
warnings. The generated code is not affected.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/pxa_camera.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/pxa_camera.c 
b/drivers/media/platform/pxa_camera.c
index 868c6ad4784c..c2d1ceaea49b 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -1296,6 +1296,7 @@ static int pxa_camera_get_formats(struct v4l2_device 
*v4l2_dev,
"Providing format %s using code %d\n",
pxa_camera_formats[0].name, code.code);
}
+   /* fall through */
case MEDIA_BUS_FMT_VYUY8_2X8:
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_YVYU8_2X8:
@@ -1313,6 +1314,7 @@ static int pxa_camera_get_formats(struct v4l2_device 
*v4l2_dev,
dev_dbg(pcdev_to_dev(pcdev),
"Providing format %s in pass-through mode\n",
fmt->name);
+   break;
}
 
/* Generic pass-through */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 02/14] media: mt9m111: use only the SRGB colorspace

[Robert Jarzmik]

mt9m111 being a camera sensor, its colorspace should always be SRGB, for
both RGB based formats or YCbCr based ones.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/i2c/soc_camera/mt9m111.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/mt9m111.c 
b/drivers/media/i2c/soc_camera/mt9m111.c
index 7faf49f0d9f9..72e71b762827 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -188,10 +188,10 @@ struct mt9m111_datafmt {
 };
 
 static const struct mt9m111_datafmt mt9m111_colour_fmts[] = {
-   {MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG},
-   {MEDIA_BUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG},
-   {MEDIA_BUS_FMT_UYVY8_2X8, V4L2_COLORSPACE_JPEG},
-   {MEDIA_BUS_FMT_VYUY8_2X8, V4L2_COLORSPACE_JPEG},
+   {MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_SRGB},
+   {MEDIA_BUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_SRGB},
+   {MEDIA_BUS_FMT_UYVY8_2X8, V4L2_COLORSPACE_SRGB},
+   {MEDIA_BUS_FMT_VYUY8_2X8, V4L2_COLORSPACE_SRGB},
{MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
{MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE, V4L2_COLORSPACE_SRGB},
{MEDIA_BUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB},
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 05/14] media: platform: pxa_camera: trivial move of functions

[Robert Jarzmik]

Move the functions in the file to be regrouped into meaningful blocks :
 1. pxa camera core handling functions, manipulating the herdware
 2. videobuf2 functions, dealing with video buffers
 3. video ioctl (vidioc) related functions
 4. driver probing, removal, suspend and resume

This patch doesn't modify a single line of code.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/pxa_camera.c | 473 +
 1 file changed, 241 insertions(+), 232 deletions(-)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index d565bcb9f2d6..62e3f69a17ec 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -538,238 +538,6 @@ out:
spin_unlock_irqrestore(>lock, flags);
 }
 
-static void pxa_buffer_cleanup(struct pxa_buffer *buf)
-{
-   int i;
-
-   for (i = 0; i < 3 && buf->descs[i]; i++) {
-   dmaengine_desc_free(buf->descs[i]);
-   kfree(buf->sg[i]);
-   buf->descs[i] = NULL;
-   buf->sg[i] = NULL;
-   buf->sg_len[i] = 0;
-   buf->plane_sizes[i] = 0;
-   }
-   buf->nb_planes = 0;
-}
-
-static int pxa_buffer_init(struct pxa_camera_dev *pcdev,
-  struct pxa_buffer *buf)
-{
-   struct vb2_buffer *vb = >vbuf.vb2_buf;
-   struct sg_table *sgt = vb2_dma_sg_plane_desc(vb, 0);
-   int nb_channels = pcdev->channels;
-   int i, ret = 0;
-   unsigned long size = vb2_plane_size(vb, 0);
-
-   switch (nb_channels) {
-   case 1:
-   buf->plane_sizes[0] = size;
-   break;
-   case 3:
-   buf->plane_sizes[0] = size / 2;
-   buf->plane_sizes[1] = size / 4;
-   buf->plane_sizes[2] = size / 4;
-   break;
-   default:
-   return -EINVAL;
-   };
-   buf->nb_planes = nb_channels;
-
-   ret = sg_split(sgt->sgl, sgt->nents, 0, nb_channels,
-  buf->plane_sizes, buf->sg, buf->sg_len, GFP_KERNEL);
-   if (ret < 0) {
-   dev_err(pcdev_to_dev(pcdev),
-   "sg_split failed: %d\n", ret);
-   return ret;
-   }
-   for (i = 0; i < nb_channels; i++) {
-   ret = pxa_init_dma_channel(pcdev, buf, i,
-  buf->sg[i], buf->sg_len[i]);
-   if (ret) {
-   pxa_buffer_cleanup(buf);
-   return ret;
-   }
-   }
-   INIT_LIST_HEAD(>queue);
-
-   return ret;
-}
-
-static void pxac_vb2_cleanup(struct vb2_buffer *vb)
-{
-   struct pxa_buffer *buf = vb2_to_pxa_buffer(vb);
-   struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vb->vb2_queue);
-
-   dev_dbg(pcdev_to_dev(pcdev),
-"%s(vb=%p)\n", __func__, vb);
-   pxa_buffer_cleanup(buf);
-}
-
-static void pxac_vb2_queue(struct vb2_buffer *vb)
-{
-   struct pxa_buffer *buf = vb2_to_pxa_buffer(vb);
-   struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vb->vb2_queue);
-
-   dev_dbg(pcdev_to_dev(pcdev),
-"%s(vb=%p) nb_channels=%d size=%lu active=%p\n",
-   __func__, vb, pcdev->channels, vb2_get_plane_payload(vb, 0),
-   pcdev->active);
-
-   list_add_tail(>queue, >capture);
-
-   pxa_dma_add_tail_buf(pcdev, buf);
-}
-
-/*
- * Please check the DMA prepared buffer structure in :
- *   Documentation/video4linux/pxa_camera.txt
- * Please check also in pxa_camera_check_link_miss() to understand why DMA 
chain
- * modification while DMA chain is running will work anyway.
- */
-static int pxac_vb2_prepare(struct vb2_buffer *vb)
-{
-   struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vb->vb2_queue);
-   struct pxa_buffer *buf = vb2_to_pxa_buffer(vb);
-   struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
-   int ret = 0;
-
-   switch (pcdev->channels) {
-   case 1:
-   case 3:
-   vb2_set_plane_payload(vb, 0, icd->sizeimage);
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   dev_dbg(pcdev_to_dev(pcdev),
-"%s (vb=%p) nb_channels=%d size=%lu\n",
-   __func__, vb, pcdev->channels, vb2_get_plane_payload(vb, 0));
-
-   WARN_ON(!icd->current_fmt);
-
-#ifdef DEBUG
-   /*
-* This can be useful if you want to see if we actually fill
-* the buffer with something
-*/
-   for (i = 0; i < vb->num_planes; i++)
-   memset((void *)vb2_plane_vaddr(vb, i),
-  0xaa, vb2_get_plane_payload(vb, i));
-#endif
-
-   /*
-* I think, in buf_prepare you only have to protect global data,
-* the actual buffer is yours
-*/
-   buf->inwork = 0;
-   pxa_videobuf_set_actdma(pcdev, buf);
-
-   return ret;
-}
-
-static int 

[PATCH v6 01/14] media: mt9m111: make a standalone v4l2 subdevice

[Robert Jarzmik]

Remove the soc_camera adherence. Mostly the change removes the power
manipulation provided by soc_camera, and instead :
 - powers on the sensor when the s_power control is activated
 - powers on the sensor in initial probe
 - enables and disables the MCLK provided to it in power on/off

This patch also drops support for inverters on synchronisation and clock
lines. It is assumed, if any board ever needs such inverters, support
for them can be added in the future

Acked-by: Guennadi Liakhovetski 
Signed-off-by: Robert Jarzmik 
---
 drivers/media/i2c/soc_camera/mt9m111.c | 51 ++
 1 file changed, 15 insertions(+), 36 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/mt9m111.c 
b/drivers/media/i2c/soc_camera/mt9m111.c
index 6c8d1123658c..7faf49f0d9f9 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -16,10 +16,11 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 /*
  * MT9M111, MT9M112 and MT9M131:
@@ -391,7 +392,7 @@ static int mt9m111_set_selection(struct v4l2_subdev *sd,
struct mt9m111 *mt9m111 = to_mt9m111(client);
struct v4l2_rect rect = sel->r;
int width, height;
-   int ret;
+   int ret, align = 0;
 
if (sel->which != V4L2_SUBDEV_FORMAT_ACTIVE ||
sel->target != V4L2_SEL_TGT_CROP)
@@ -400,17 +401,19 @@ static int mt9m111_set_selection(struct v4l2_subdev *sd,
if (mt9m111->fmt->code == MEDIA_BUS_FMT_SBGGR8_1X8 ||
mt9m111->fmt->code == MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE) {
/* Bayer format - even size lengths */
-   rect.width  = ALIGN(rect.width, 2);
-   rect.height = ALIGN(rect.height, 2);
+   align = 1;
/* Let the user play with the starting pixel */
}
 
/* FIXME: the datasheet doesn't specify minimum sizes */
-   soc_camera_limit_side(, ,
-MT9M111_MIN_DARK_COLS, 2, MT9M111_MAX_WIDTH);
-
-   soc_camera_limit_side(, ,
-MT9M111_MIN_DARK_ROWS, 2, MT9M111_MAX_HEIGHT);
+   v4l_bound_align_image(, 2, MT9M111_MAX_WIDTH, align,
+ , 2, MT9M111_MAX_HEIGHT, align, 0);
+   rect.left = clamp(rect.left, MT9M111_MIN_DARK_COLS,
+ MT9M111_MIN_DARK_COLS + MT9M111_MAX_WIDTH -
+ (__s32)rect.width);
+   rect.top = clamp(rect.top, MT9M111_MIN_DARK_ROWS,
+MT9M111_MIN_DARK_ROWS + MT9M111_MAX_HEIGHT -
+(__s32)rect.height);
 
width = min(mt9m111->width, rect.width);
height = min(mt9m111->height, rect.height);
@@ -779,17 +782,16 @@ static int mt9m111_init(struct mt9m111 *mt9m111)
 static int mt9m111_power_on(struct mt9m111 *mt9m111)
 {
struct i2c_client *client = v4l2_get_subdevdata(>subdev);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
int ret;
 
-   ret = soc_camera_power_on(>dev, ssdd, mt9m111->clk);
+   ret = v4l2_clk_enable(mt9m111->clk);
if (ret < 0)
return ret;
 
ret = mt9m111_resume(mt9m111);
if (ret < 0) {
dev_err(>dev, "Failed to resume the sensor: %d\n", ret);
-   soc_camera_power_off(>dev, ssdd, mt9m111->clk);
+   v4l2_clk_disable(mt9m111->clk);
}
 
return ret;
@@ -797,11 +799,8 @@ static int mt9m111_power_on(struct mt9m111 *mt9m111)
 
 static void mt9m111_power_off(struct mt9m111 *mt9m111)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(>subdev);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
mt9m111_suspend(mt9m111);
-   soc_camera_power_off(>dev, ssdd, mt9m111->clk);
+   v4l2_clk_disable(mt9m111->clk);
 }
 
 static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
@@ -858,14 +857,10 @@ static int mt9m111_enum_mbus_code(struct v4l2_subdev *sd,
 static int mt9m111_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_HIGH |
V4L2_MBUS_DATA_ACTIVE_HIGH;
cfg->type = V4L2_MBUS_PARALLEL;
-   cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
 
return 0;
 }
@@ -936,20 +931,8 @@ static int mt9m111_probe(struct i2c_client *client,
 {
struct mt9m111 *mt9m111;
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
int ret;
 
-   if (client->dev.of_node) {
-   ssdd = devm_kzalloc(>dev, 

[PATCH v6 03/14] media: mt9m111: move mt9m111 out of soc_camera

[Robert Jarzmik]

As the mt9m111 is now working as a standalone v4l2 subdevice sensor,
move it out of soc_camera directory and severe its dependency on
soc_camera.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/i2c/Kconfig| 7 +++
 drivers/media/i2c/Makefile   | 1 +
 drivers/media/i2c/{soc_camera => }/mt9m111.c | 0
 drivers/media/i2c/soc_camera/Kconfig | 7 +--
 drivers/media/i2c/soc_camera/Makefile| 1 -
 5 files changed, 13 insertions(+), 3 deletions(-)
 rename drivers/media/i2c/{soc_camera => }/mt9m111.c (100%)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 92cc54401339..7f929336c409 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -578,6 +578,13 @@ config VIDEO_MT9M032
  This driver supports MT9M032 camera sensors from Aptina, monochrome
  models only.
 
+config VIDEO_MT9M111
+   tristate "mt9m111, mt9m112 and mt9m131 support"
+   depends on I2C && VIDEO_V4L2
+   help
+ This driver supports MT9M111, MT9M112 and MT9M131 cameras from
+ Micron/Aptina
+
 config VIDEO_MT9P031
tristate "Aptina MT9P031 support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 0216af0f9281..92773b2e6225 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
+obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
 obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
diff --git a/drivers/media/i2c/soc_camera/mt9m111.c 
b/drivers/media/i2c/mt9m111.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/mt9m111.c
rename to drivers/media/i2c/mt9m111.c
diff --git a/drivers/media/i2c/soc_camera/Kconfig 
b/drivers/media/i2c/soc_camera/Kconfig
index 23d352f0adf0..7704bcf5cc25 100644
--- a/drivers/media/i2c/soc_camera/Kconfig
+++ b/drivers/media/i2c/soc_camera/Kconfig
@@ -14,11 +14,14 @@ config SOC_CAMERA_MT9M001
  and colour models.
 
 config SOC_CAMERA_MT9M111
-   tristate "mt9m111, mt9m112 and mt9m131 support"
+   tristate "legacy soc_camera mt9m111, mt9m112 and mt9m131 support"
depends on SOC_CAMERA && I2C
+   select VIDEO_MT9M111
help
  This driver supports MT9M111, MT9M112 and MT9M131 cameras from
- Micron/Aptina
+ Micron/Aptina.
+ This is the legacy configuration which shouldn't be used anymore,
+ while VIDEO_MT9M111 should be used instead.
 
 config SOC_CAMERA_MT9T031
tristate "mt9t031 support"
diff --git a/drivers/media/i2c/soc_camera/Makefile 
b/drivers/media/i2c/soc_camera/Makefile
index d0421feaa796..6f994f9353a0 100644
--- a/drivers/media/i2c/soc_camera/Makefile
+++ b/drivers/media/i2c/soc_camera/Makefile
@@ -1,6 +1,5 @@
 obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
 obj-$(CONFIG_SOC_CAMERA_MT9M001)   += mt9m001.o
-obj-$(CONFIG_SOC_CAMERA_MT9M111)   += mt9m111.o
 obj-$(CONFIG_SOC_CAMERA_MT9T031)   += mt9t031.o
 obj-$(CONFIG_SOC_CAMERA_MT9T112)   += mt9t112.o
 obj-$(CONFIG_SOC_CAMERA_MT9V022)   += mt9v022.o
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 10/14] media: platform: pxa_camera: make a standalone v4l2 device

[Robert Jarzmik]

This patch removes the soc_camera API dependency from pxa_camera.
In the current status :
 - all previously captures are working the same on pxa270
 - the s_crop() call was removed, judged not working
   (see what happens soc_camera_s_crop() when get_crop() == NULL)
 - if the pixel clock is provided by then sensor, ie. not MCLK, the dual
   stage change is not handled yet.
   => there is no in-tree user of this, so I'll let it that way

 - the MCLK is not yet finished, it's as in the legacy way,
   ie. activated at video device opening and closed at video device
   closing.
   In a subsequence patch pxa_camera_mclk_ops should be used, and
   platform data MCLK ignored. It will be the sensor's duty to request
   the clock and enable it, which will end in pxa_camera_mclk_ops.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/Kconfig  |   2 +-
 drivers/media/platform/soc_camera/pxa_camera.c | 753 +
 include/linux/platform_data/media/camera-pxa.h |   2 +
 3 files changed, 518 insertions(+), 239 deletions(-)

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index de1767899ddc..6b87b3a9d546 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -19,7 +19,7 @@ config SOC_CAMERA_PLATFORM
 
 config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
-   depends on VIDEO_DEV && PXA27x && SOC_CAMERA && HAS_DMA
+   depends on VIDEO_DEV && PXA27x && HAS_DMA
select VIDEOBUF2_DMA_SG
select SG_SPLIT
---help---
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index 8f329d0b2cda..395cd398c32b 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2006, Sascha Hauer, Pengutronix
  * Copyright (C) 2008, Guennadi Liakhovetski 
+ * Copyright (C) 2016, Robert Jarzmik 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -14,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,13 +35,16 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
 
+#include 
+#include 
+
 #include 
 
 #include 
@@ -46,6 +52,9 @@
 #define PXA_CAM_VERSION "0.0.6"
 #define PXA_CAM_DRV_NAME "pxa27x-camera"
 
+#define DEFAULT_WIDTH  640
+#define DEFAULT_HEIGHT 480
+
 /* Camera Interface */
 #define CICR0  0x
 #define CICR1  0x0004
@@ -169,7 +178,25 @@
CICR0_EOFM | CICR0_FOM)
 
 #define sensor_call(cam, o, f, args...) \
-   v4l2_subdev_call(sd, o, f, ##args)
+   v4l2_subdev_call(cam->sensor, o, f, ##args)
+
+/*
+ * Format handling
+ */
+/**
+ * struct soc_camera_format_xlate - match between host and sensor formats
+ * @code: code of a sensor provided format
+ * @host_fmt: host format after host translation from code
+ *
+ * Host and sensor translation structure. Used in table of host and sensor
+ * formats matchings in soc_camera_device. A host can override the generic list
+ * generation by implementing get_formats(), and use it for format checks and
+ * format setup.
+ */
+struct soc_camera_format_xlate {
+   u32 code;
+   const struct soc_mbus_pixelfmt *host_fmt;
+};
 
 /*
  * Structures
@@ -198,7 +225,18 @@ struct pxa_buffer {
 };
 
 struct pxa_camera_dev {
-   struct soc_camera_host  soc_host;
+   struct v4l2_device  v4l2_dev;
+   struct video_device vdev;
+   struct v4l2_async_notifier notifier;
+   struct vb2_queuevb2_vq;
+   struct v4l2_subdev  *sensor;
+   struct soc_camera_format_xlate *user_formats;
+   const struct soc_camera_format_xlate *current_fmt;
+   struct v4l2_pix_format  current_pix;
+
+   struct v4l2_async_subdev asd;
+   struct v4l2_async_subdev *asds[1];
+
/*
 * PXA27x is only supposed to handle one camera on its Quick Capture
 * interface. If anyone ever builds hardware to enable more than
@@ -218,11 +256,13 @@ struct pxa_camera_dev {
unsigned long   ciclk;
unsigned long   mclk;
u32 mclk_divisor;
+   struct v4l2_clk *mclk_clk;
u16 width_flags;/* max 10 bits */
 
struct list_headcapture;
 
spinlock_t  lock;
+   struct mutexmlock;
unsigned intbuf_sequence;
 
struct pxa_buffer   *active;
@@ -237,12 +277,69 @@ struct pxa_cam {
 
 static const char 

[PATCH v6 08/14] media: platform: pxa_camera: add buffer sequencing

[Robert Jarzmik]

Add sequence numbers to completed buffers.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/pxa_camera.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index 026ed308fea8..d9e2570d3931 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -223,6 +223,7 @@ struct pxa_camera_dev {
struct list_headcapture;
 
spinlock_t  lock;
+   unsigned intbuf_sequence;
 
struct pxa_buffer   *active;
struct tasklet_struct   task_eof;
@@ -423,10 +424,13 @@ static void pxa_camera_wakeup(struct pxa_camera_dev 
*pcdev,
  struct pxa_buffer *buf)
 {
struct vb2_buffer *vb = >vbuf.vb2_buf;
+   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
 
/* _init is used to debug races, see comment in pxa_camera_reqbufs() */
list_del_init(>queue);
vb->timestamp = ktime_get_ns();
+   vbuf->sequence = pcdev->buf_sequence++;
+   vbuf->field = V4L2_FIELD_NONE;
vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
dev_dbg(pcdev_to_dev(pcdev), "%s dequeud buffer (buf=0x%p)\n",
__func__, buf);
@@ -1022,6 +1026,7 @@ static int pxac_vb2_start_streaming(struct vb2_queue *vq, 
unsigned int count)
dev_dbg(pcdev_to_dev(pcdev), "%s(count=%d) active=%p\n",
__func__, count, pcdev->active);
 
+   pcdev->buf_sequence = 0;
if (!pcdev->active)
pxa_camera_start_capture(pcdev);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 04/14] media: platform: pxa_camera: convert to vb2

[Robert Jarzmik]

Convert pxa_camera from videobuf to videobuf2.

As the soc_camera was already compatible with videobuf2, the port is
quite straightforward.

The special case of this code in which the vb2 to prepare is "too
big" in terms of size for the new capture format, the pxa_camera will
fail.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/Kconfig  |   4 +-
 drivers/media/platform/soc_camera/pxa_camera.c | 579 -
 2 files changed, 269 insertions(+), 314 deletions(-)

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 99cf471a5fc0..de1767899ddc 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -19,8 +19,8 @@ config SOC_CAMERA_PLATFORM
 
 config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
-   depends on VIDEO_DEV && PXA27x && SOC_CAMERA
-   select VIDEOBUF_DMA_SG
+   depends on VIDEO_DEV && PXA27x && SOC_CAMERA && HAS_DMA
+   select VIDEOBUF2_DMA_SG
select SG_SPLIT
---help---
  This is a v4l2 driver for the PXA27x Quick Capture Interface
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index ebbe514d64e2..d565bcb9f2d6 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -34,7 +34,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -180,13 +180,16 @@ enum pxa_camera_active_dma {
 /* buffer for one video frame */
 struct pxa_buffer {
/* common v4l buffer stuff -- must be first */
-   struct videobuf_buffer  vb;
+   struct vb2_v4l2_buffer  vbuf;
+   struct list_headqueue;
u32 code;
+   int nb_planes;
/* our descriptor lists for Y, U and V channels */
struct dma_async_tx_descriptor  *descs[3];
dma_cookie_tcookie[3];
struct scatterlist  *sg[3];
int sg_len[3];
+   size_t  plane_sizes[3];
int inwork;
enum pxa_camera_active_dma  active_dma;
 };
@@ -230,59 +233,19 @@ struct pxa_cam {
 
 static const char *pxa_cam_driver_description = "PXA_Camera";
 
-static unsigned int vid_limit = 16;/* Video memory limit, in Mb */
-
 /*
  *  Videobuf operations
  */
-static int pxa_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
- unsigned int *size)
+static struct pxa_buffer *vb2_to_pxa_buffer(struct vb2_buffer *vb)
 {
-   struct soc_camera_device *icd = vq->priv_data;
-
-   dev_dbg(icd->parent, "count=%d, size=%d\n", *count, *size);
-
-   *size = icd->sizeimage;
-
-   if (0 == *count)
-   *count = 32;
-   if (*size * *count > vid_limit * 1024 * 1024)
-   *count = (vid_limit * 1024 * 1024) / *size;
+   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
 
-   return 0;
+   return container_of(vbuf, struct pxa_buffer, vbuf);
 }
 
-static void free_buffer(struct videobuf_queue *vq, struct pxa_buffer *buf)
+static struct device *pcdev_to_dev(struct pxa_camera_dev *pcdev)
 {
-   struct soc_camera_device *icd = vq->priv_data;
-   struct videobuf_dmabuf *dma = videobuf_to_dma(>vb);
-   int i;
-
-   BUG_ON(in_interrupt());
-
-   dev_dbg(icd->parent, "%s (vb=0x%p) 0x%08lx %d\n", __func__,
-   >vb, buf->vb.baddr, buf->vb.bsize);
-
-   /*
-* This waits until this buffer is out of danger, i.e., until it is no
-* longer in STATE_QUEUED or STATE_ACTIVE
-*/
-   videobuf_waiton(vq, >vb, 0, 0);
-
-   for (i = 0; i < 3 && buf->descs[i]; i++) {
-   dmaengine_desc_free(buf->descs[i]);
-   kfree(buf->sg[i]);
-   buf->descs[i] = NULL;
-   buf->sg[i] = NULL;
-   buf->sg_len[i] = 0;
-   }
-   videobuf_dma_unmap(vq->dev, dma);
-   videobuf_dma_free(dma);
-
-   buf->vb.state = VIDEOBUF_NEEDS_INIT;
-
-   dev_dbg(icd->parent, "%s end (vb=0x%p) 0x%08lx %d\n", __func__,
-   >vb, buf->vb.baddr, buf->vb.bsize);
+   return pcdev->soc_host.v4l2_dev.dev;
 }
 
 static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
@@ -312,31 +275,26 @@ static void pxa_camera_dma_irq_v(void *data)
 /**
  * pxa_init_dma_channel - init dma descriptors
  * @pcdev: pxa camera device
- * @buf: pxa buffer to find pxa dma channel
+ * @vb: videobuffer2 buffer
  * @dma: dma video buffer
  * @channel: dma channel (0 => 'Y', 1 => 'U', 2 => 'V')
  * @cibr: camera Receive Buffer Register
- * @size: bytes to transfer
- * @offset: offset in videobuffer of the first byte to transfer
  *
  * Prepares the pxa dma descriptors to transfer one camera channel.
  *
  * 

[PATCH v6 09/14] media: platform: pxa_camera: remove set_selection

[Robert Jarzmik]

This is to be seen as a regression as the set_selection (former
set_crop) function is removed. This is a temporary situation in the v4l2
porting, and will have to be added later.

Signed-off-by: Robert Jarzmik 
---
 drivers/media/platform/soc_camera/pxa_camera.c | 83 --
 1 file changed, 83 deletions(-)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index d9e2570d3931..8f329d0b2cda 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -1294,88 +1294,6 @@ static int pxa_camera_check_frame(u32 width, u32 height)
(width & 0x01);
 }
 
-static int pxa_camera_set_selection(struct soc_camera_device *icd,
-   struct v4l2_selection *sel)
-{
-   const struct v4l2_rect *rect = >r;
-   struct device *dev = icd->parent;
-   struct soc_camera_host *ici = to_soc_camera_host(dev);
-   struct pxa_camera_dev *pcdev = ici->priv;
-   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
-   struct soc_camera_sense sense = {
-   .master_clock = pcdev->mclk,
-   .pixel_clock_max = pcdev->ciclk / 4,
-   };
-   struct v4l2_subdev_format fmt = {
-   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
-   };
-   struct v4l2_mbus_framefmt *mf = 
-   struct pxa_cam *cam = icd->host_priv;
-   u32 fourcc = icd->current_fmt->host_fmt->fourcc;
-   struct v4l2_subdev_selection sdsel = {
-   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
-   .target = sel->target,
-   .flags = sel->flags,
-   .r = sel->r,
-   };
-   int ret;
-
-   /* If PCLK is used to latch data from the sensor, check sense */
-   if (pcdev->platform_flags & PXA_CAMERA_PCLK_EN)
-   icd->sense = 
-
-   ret = sensor_call(pcdev, pad, set_selection, NULL, );
-
-   icd->sense = NULL;
-
-   if (ret < 0) {
-   dev_warn(pcdev_to_dev(pcdev), "Failed to crop to %ux%u@%u:%u\n",
-rect->width, rect->height, rect->left, rect->top);
-   return ret;
-   }
-   sel->r = sdsel.r;
-
-   ret = sensor_call(pcdev, pad, get_fmt, NULL, );
-   if (ret < 0)
-   return ret;
-
-   if (pxa_camera_check_frame(mf->width, mf->height)) {
-   /*
-* Camera cropping produced a frame beyond our capabilities.
-* FIXME: just extract a subframe, that we can process.
-*/
-   v4l_bound_align_image(>width, 48, 2048, 1,
-   >height, 32, 2048, 0,
-   fourcc == V4L2_PIX_FMT_YUV422P ? 4 : 0);
-   ret = sensor_call(pcdev, pad, set_fmt, NULL, );
-   if (ret < 0)
-   return ret;
-
-   if (pxa_camera_check_frame(mf->width, mf->height)) {
-   dev_warn(pcdev_to_dev(pcdev),
-"Inconsistent state. Use S_FMT to repair\n");
-   return -EINVAL;
-   }
-   }
-
-   if (sense.flags & SOCAM_SENSE_PCLK_CHANGED) {
-   if (sense.pixel_clock > sense.pixel_clock_max) {
-   dev_err(pcdev_to_dev(pcdev),
-   "pixel clock %lu set by the camera too high!",
-   sense.pixel_clock);
-   return -EIO;
-   }
-   recalculate_fifo_timeout(pcdev, sense.pixel_clock);
-   }
-
-   icd->user_width = mf->width;
-   icd->user_height= mf->height;
-
-   pxa_camera_setup_cicr(icd, cam->flags, fourcc);
-
-   return ret;
-}
-
 static int pxa_camera_set_fmt(struct soc_camera_device *icd,
  struct v4l2_format *f)
 {
@@ -1588,7 +1506,6 @@ static struct soc_camera_host_ops pxa_soc_camera_host_ops 
= {
.remove = pxa_camera_remove_device,
.clock_start= pxa_camera_clock_start,
.clock_stop = pxa_camera_clock_stop,
-   .set_selection  = pxa_camera_set_selection,
.get_formats= pxa_camera_get_formats,
.put_formats= pxa_camera_put_formats,
.set_fmt= pxa_camera_set_fmt,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 00/13] pxa_camera transition to v4l2 standalone device

[Robert Jarzmik]

Hans Verkuil  writes:

> On 08/29/2016 07:55 PM, Robert Jarzmik wrote:
>> There is no change between v4 and v5, ie. the global diff is empty, only one
>> line was shifted to prevent breaking bisectablility.
>
> Against which tree do you develop? Unfortunately this patch series doesn't 
> apply
> to the media_tree master branch anymore due to conflicts with a merged patch 
> that
> converts s/g_crop to s/g_selection in all subdev drivers.
v4.8-rc1 is their base, so Linus's master.

> When you make the new patch series, please use the -M option with git 
> send-email so
> patches that move files around are handled cleanly. That makes it much easier
> to review.
Ok.

> BTW, checkpatch reported issues in a switch statement in function
> pxa_camera_get_formats():
Yep, I noticed.

> switch (code.code) {
> case MEDIA_BUS_FMT_UYVY8_2X8:
> formats++;
> if (xlate) {
> xlate->host_fmt = _camera_formats[0];
> xlate->code = code.code;
> xlate++;
> dev_dbg(dev, "Providing format %s using code %d\n",
> pxa_camera_formats[0].name, code.code);
> }
> case MEDIA_BUS_FMT_VYUY8_2X8:
> case MEDIA_BUS_FMT_YUYV8_2X8:
> case MEDIA_BUS_FMT_YVYU8_2X8:
> case MEDIA_BUS_FMT_RGB565_2X8_LE:
> case MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE:
> if (xlate)
> dev_dbg(dev, "Providing format %s packed\n",
> fmt->name);
> break;
> default:
> if (!pxa_camera_packing_supported(fmt))
> return 0;
> if (xlate)
> dev_dbg(dev,
> "Providing format %s in pass-through mode\n",
> fmt->name);
> }
>
> Before 'case MEDIA_BUS_FMT_VYUY8_2X8' should there be a break? If not, then
> there should be a '/* fall through */' comment.
There should have been a '/* fall through */' in the original code, even if that
was not strictly "required" at the time of writing.
>
> At the end of the default case there should also be a break statement.
>
> This is already in the existing code, so just make a separate patch fixing
> this.
Ok, will do.

Cheers.

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] v4l: omap_vout: vrfb: Convert to dmaengine

[Peter Ujfalusi]

Hi,

On 08/18/16 13:22, Peter Ujfalusi wrote:
> The dmaengine driver for sDMA now have support for interleaved transfer.
> This trasnfer type was open coded with the legacy omap-dma API, but now
> we can move it to dmaengine.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
> The dmaengine driver for sDMA now have support for interleaved transfer.
> This trasnfer type was open coded with the legacy omap-dma API, but now
> we can move it to dmaengine.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
> Hi,
> 
> I do not have access to any hardware where I could test if the conversion 
> works
> correctly. I think it should. The dmaengine part looks fine to me - not that
> this means too much as I have written it ;)
> Based on debugging the code with starring at it I think the old and the new 
> way
> would end up setting up the DMA in a same way. However the dmaengine driver 
> will
> set CSDP_DST_PACKED | CSDP_SRC_PACKED.
> 
> Laurent: would you be able to test this?

I managed to test the dmaengine interleaved with:
https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/drivers/misc/ovv_dmaengine.c

Basically I have ripped the relevant code from omap_vout_vrfb.c, added the
dmaengine implementation. Then:
0. allocate and init the three buffers
1. copy from buffer0 to buffer1 with legacy omap-dma
2. copy from buffer0 to buffer2 with legacy omap-dma
3. compare buffer1 and buffer2
4. reinit buffer2
5. copy from buffer0 to buffer2 with dmaengine
6. compare buffer1 and buffer2

The result is:
[  100.578943] ovv_init: ENTER
[  100.626871] ovv_setup_buffers: pattern is good
[  100.774526] ovv_setup_buffers: pattern is good
[  100.911386] ovv_setup_buffers: pattern is good
[  101.136397] ovv_get_legacy_dma: got channel: 6
[  101.140859] ovv_get_dmaengine_dma: got channel
[  101.160475] omap_vout_vrfb_dma_tx_callback: ENTER
[  101.180357] omap_vout_vrfb_dma_tx_callback: ENTER
[  101.470146] ovv_init: Legacy vs Legacy: they are identical
[  101.595408] ovv_init: pattern is good
[  101.599104] dmaengine_callback: ENTER
[  101.888070] ovv_init: Legacy vs dmaengine: they are identical

-- 
Péter

> 
> Regards,
> Peter
> 
>  drivers/media/platform/omap/omap_vout_vrfb.c | 133 
> ---
>  drivers/media/platform/omap/omap_voutdef.h   |   6 +-
>  2 files changed, 83 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c 
> b/drivers/media/platform/omap/omap_vout_vrfb.c
> index b8638e4e1627..957ff7621652 100644
> --- a/drivers/media/platform/omap/omap_vout_vrfb.c
> +++ b/drivers/media/platform/omap/omap_vout_vrfb.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
> 
> -#include 
>  #include 
> 
>  #include "omap_voutdef.h"
> @@ -63,7 +62,7 @@ static int omap_vout_allocate_vrfb_buffers(struct 
> omap_vout_device *vout,
>  /*
>   * Wakes up the application once the DMA transfer to VRFB space is completed.
>   */
> -static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void 
> *data)
> +static void omap_vout_vrfb_dma_tx_callback(void *data)
>  {
>   struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
> 
> @@ -94,6 +93,7 @@ int omap_vout_setup_vrfb_bufs(struct platform_device *pdev, 
> int vid_num,
>   int ret = 0, i, j;
>   struct omap_vout_device *vout;
>   struct video_device *vfd;
> + dma_cap_mask_t mask;
>   int image_width, image_height;
>   int vrfb_num_bufs = VRFB_NUM_BUFS;
>   struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
> @@ -131,17 +131,26 @@ int omap_vout_setup_vrfb_bufs(struct platform_device 
> *pdev, int vid_num,
>   /*
>* Request and Initialize DMA, for DMA based VRFB transfer
>*/
> - vout->vrfb_dma_tx.dev_id = OMAP_DMA_NO_DEVICE;
> - vout->vrfb_dma_tx.dma_ch = -1;
> - vout->vrfb_dma_tx.req_status = DMA_CHAN_ALLOTED;
> - ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
> - omap_vout_vrfb_dma_tx_callback,
> - (void *) >vrfb_dma_tx, >vrfb_dma_tx.dma_ch);
> - if (ret < 0) {
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_INTERLEAVE, mask);
> + vout->vrfb_dma_tx.chan = dma_request_chan_by_mask();
> + if (IS_ERR(vout->vrfb_dma_tx.chan)) {
>   vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
> + } else {
> + size_t xt_size = sizeof(struct dma_interleaved_template) +
> +  sizeof(struct data_chunk);
> +
> + vout->vrfb_dma_tx.xt = kzalloc(xt_size, GFP_KERNEL);
> + if (!vout->vrfb_dma_tx.xt) {
> + dma_release_channel(vout->vrfb_dma_tx.chan);
> + vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
> + }
> + }
> +
> + if (vout->vrfb_dma_tx.req_status == DMA_CHAN_NOT_ALLOTED)
>   dev_info(>dev, ": failed to allocate DMA Channel for"
>   " video%d\n", vfd->minor);
> - }
> +

[PATCH] [media] coda: add missing header dependencies

[Baoyou Xie]

We get 1 warning when building kernel with W=1:
drivers/media/platform/coda/coda-h264.c:22:5: warning: no previous prototype 
for 'coda_h264_padding' [-Wmissing-prototypes]

In fact, this function is declared in coda.h, so this patch
add missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/media/platform/coda/coda-h264.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/coda/coda-h264.c 
b/drivers/media/platform/coda/coda-h264.c
index 456773a..09dfcca 100644
--- a/drivers/media/platform/coda/coda-h264.c
+++ b/drivers/media/platform/coda/coda-h264.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] [media] vimc: Virtual Media Controller core, capture and sensor

[Hans Verkuil]

On 09/04/16 22:02, Helen Koike wrote:

From: Helen Fornazier 

First version of the Virtual Media Controller.
Add a simple version of the core of the driver, the capture and
sensor nodes in the topology, generating a grey image in a hardcoded
format.

Signed-off-by: Helen Koike 



One thing is missing: a MAINTAINERS entry. Can you make a separate patch
updating the MAINTAINERS file?

Thanks!

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mediatek decoder: compiler/sparse warnings

[Hans Verkuil]

Hi Tiffany,

I get a bunch of warnings when I compile the decoder driver in my daily build 
setup:

/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c:
 In function 'put_fb_to_free':
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c:242:47:
 warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
   list->fb_list[list->write_idx].vdec_fb_va = (u64)fb;
   ^
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c:
 In function 'vdec_h264_decode':
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c:353:24:
 warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
  uint64_t vdec_fb_va = (u64)fb;
^
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c:
 In function 'vdec_h264_get_fb':
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c:446:7:
 warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
  fb = (struct vdec_fb *)list->fb_list[list->read_idx].vdec_fb_va;
   ^
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c:
 In function 'vdec_vp9_decode':
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c:794:37:
 warning: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat=]
  mtk_vcodec_debug(inst, "Input BS Size = %ld", bs->size);
 ^

^^ Should be %zu.

/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c:
 In function 'handle_init_ack_msg':
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c:22:30:
 warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
  struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)msg->ap_inst_addr;
  ^
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c:
 In function 'vpu_dec_ipi_handler':
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c:41:30:
 warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
  struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)msg->ap_inst_addr;
  ^

sparse: ERRORS
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c:404:16:
 error: undefined identifier 'kzalloc'
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c:436:9:
 error: undefined identifier 'kfree'
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c:618:9:
 error: undefined identifier 'kfree'
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c:404:9:
 error: implicit declaration of function
'kzalloc' [-Werror=implicit-function-declaration]
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c:404:7:
 warning: assignment makes pointer from integer
without a cast [-Wint-conversion]
/home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c:436:2:
 error: implicit declaration of function 'kfree'
[-Werror=implicit-function-declaration]

 Apparently a slab.h include is missing here that breaks building it with 
sparse.

Can you look at these and provide a patch fixing these? I'll fold it in the 
patch series.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] v4l: vsp1: Add HGT support

[Niklas Söderlund]

Hi Laurent,

Thanks for your review.

On 2016-09-05 18:43:58 +0300, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Friday 02 Sep 2016 15:47:14 Niklas Söderlund wrote:
> > The HGT is a Histogram Generator Two-Dimensions. It computes a weighted
> > frequency histograms for hue and saturation areas over a configurable
> > region of the image with optional subsampling.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/platform/vsp1/Makefile  |   2 +-
> >  drivers/media/platform/vsp1/vsp1.h|   3 +
> >  drivers/media/platform/vsp1/vsp1_drv.c|  32 +-
> >  drivers/media/platform/vsp1/vsp1_entity.c |  33 +-
> >  drivers/media/platform/vsp1/vsp1_entity.h |   1 +
> >  drivers/media/platform/vsp1/vsp1_hgt.c| 495 +++
> >  drivers/media/platform/vsp1/vsp1_hgt.h|  51 +++
> >  drivers/media/platform/vsp1/vsp1_pipe.c   |  16 +
> >  drivers/media/platform/vsp1/vsp1_pipe.h   |   2 +
> >  drivers/media/platform/vsp1/vsp1_regs.h   |   9 +
> >  drivers/media/platform/vsp1/vsp1_video.c  |  10 +-
> >  11 files changed, 638 insertions(+), 16 deletions(-)
> >  create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
> >  create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h
> 
> [snip]
> 
> > diff --git a/drivers/media/platform/vsp1/vsp1_hgt.c
> > b/drivers/media/platform/vsp1/vsp1_hgt.c new file mode 100644
> > index 000..c43373d
> > --- /dev/null
> > +++ b/drivers/media/platform/vsp1/vsp1_hgt.c
> > @@ -0,0 +1,495 @@
> > +/*
> > + * vsp1_hgt.c  --  R-Car VSP1 Histogram Generator 2D
> > + *
> > + * Copyright (C) 2016 Renesas Electronics Corporation
> > + *
> > + * Contact: Niklas Söderlund (niklas.soderl...@ragnatech.se)
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#include "vsp1.h"
> > +#include "vsp1_dl.h"
> > +#include "vsp1_hgt.h"
> > +
> > +#define HGT_MIN_SIZE   4U
> > +#define HGT_MAX_SIZE   8192U
> > +#define HGT_DATA_SIZE  ((2 + 6 + 6 * 32) * 4)
> > +
> > +/* 
> > + * Device Access
> > + */
> > +
> > +static inline u32 vsp1_hgt_read(struct vsp1_hgt *hgt, u32 reg)
> > +{
> > +   return vsp1_read(hgt->entity.vsp1, reg);
> > +}
> > +
> > +static inline void vsp1_hgt_write(struct vsp1_hgt *hgt, struct vsp1_dl_list
> > *dl,
> > + u32 reg, u32 data)
> > +{
> > +   vsp1_dl_list_write(dl, reg, data);
> > +}
> > +
> > +/* 
> > + * Frame End Handler
> > + */
> > +
> > +void vsp1_hgt_frame_end(struct vsp1_entity *entity)
> > +{
> > +   struct vsp1_hgt *hgt = to_hgt(>subdev);
> > +   struct vsp1_histogram_buffer *buf;
> > +   unsigned int m, n;
> > +   u32 *data;
> > +
> > +   buf = vsp1_histogram_buffer_get(>histo);
> > +   if (!buf)
> > +   return;
> > +
> > +   data = buf->addr;
> > +
> > +   *data++ = vsp1_hgt_read(hgt, VI6_HGT_MAXMIN);
> > +   *data++ = vsp1_hgt_read(hgt, VI6_HGT_SUM);
> > +
> > +   for (n = 0; n < 6; n++)
> 
> Nitpicking, the driver uses pre-increment in for loops (++n), not post-
> increment. This used to be a best-practice rule in C++, where pre-increment 
> can be faster for non-native types (see 
> http://antonym.org/2008/05/stl-iterators-and-performance.html for instance). 
> I'm not sure if that's still 
> relevant, but I've taken the habit of using the pre-increment operator in for 
> loops, and that's what the rest of this driver does. This comment applies to 
> all other locations in this file.

Will update this for v2.

> 
> > +   *data++ = vsp1_hgt_read(hgt, VI6_HGT_HUE_AREA(n));
> 
> As commented on patch 1/2, I don't think this is needed. Userspace has 
> configured the hue areas, it should already have access to this information. 
> Note that if you wanted to keep this code you would need to synchronize it 
> with the .s_ctrl() handler to avoid race conditions. That's not trivial, and 
> in my opinion not needed.

Will drop the hue area configuration in v2.

> 
> > +   for (m = 0; m < 6; m++)
> > +   for (n = 0; n < 32; n++)
> > +   *data++ = vsp1_hgt_read(hgt, VI6_HGT_HISTO(m, n));
> > +
> > +   vsp1_histogram_buffer_complete(>histo, buf, HGT_DATA_SIZE);
> > +}
> > +
> > +/* 
> > + * Controls
> > + */
> > +
> > +#define V4L2_CID_VSP1_HGT_HUE_AREAS(V4L2_CID_USER_BASE | 0x1001)
> > +
> > +static int hgt_hue_areas_s_ctrl(struct v4l2_ctrl *ctrl)
> > +{
> > +   struct 

[PATCH] vcodec: mediatek: add Maintainers entry for Mediatek MT8173 vcodec drivers

[Tiffany Lin]

Add Tiffany Lin and Andrew-CT Chen as maintainers for
Mediatek MT8173 vcodec drivers

Signed-off-by: Tiffany Lin 
Signed-off-by: Andrew-CT Chen 
---
 MAINTAINERS |9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a16a82..ed830c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7590,6 +7590,15 @@ F:   include/uapi/linux/meye.h
 F: include/uapi/linux/ivtv*
 F: include/uapi/linux/uvcvideo.h
 
+MT8173 MEDIA DRIVER
+M: Tiffany Lin 
+M: Andrew-CT Chen 
+S: Supported
+F: drivers/media/platform/mtk-vcodec/
+F: drivers/media/platform/mtk-vpu/
+F: Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+F: Documentation/devicetree/bindings/media/mediatek-vpu.txt
+
 MEDIATEK ETHERNET DRIVER
 M: Felix Fietkau 
 M: John Crispin 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html