[PATCH] [media] ir-hix5hd2: make hisilicon,power-syscon property deprecated

[Jiancheng Xue]

From: Ruqiang Ju 

The clock of IR can be provided by the clock provider and controlled
by common clock framework APIs.

Signed-off-by: Ruqiang Ju 
Signed-off-by: Jiancheng Xue 
---
 .../devicetree/bindings/media/hix5hd2-ir.txt   |  6 +++---
 drivers/media/rc/ir-hix5hd2.c  | 25 ++
 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt 
b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
index fb5e760..54e1bed 100644
--- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -8,10 +8,11 @@ Required properties:
  the device. The interrupt specifier format depends on the interrupt
  controller parent.
- clocks: clock phandle and specifier pair.
-   - hisilicon,power-syscon: phandle of syscon used to control power.

 Optional properties:
- linux,rc-map-name : Remote control map name.
+   - hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files.
+   Provide correct clocks instead.

 Example node:

@@ -19,7 +20,6 @@ Example node:
compatible = "hisilicon,hix5hd2-ir";
reg = <0xf8001000 0x1000>;
interrupts = <0 47 4>;
-   clocks = < HIX5HD2_FIXED_24M>;
-   hisilicon,power-syscon = <>;
+   clocks = < HIX5HD2_IR_CLOCK>;
linux,rc-map-name = "rc-tivo";
};
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index d0549fb..d26907e 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -75,15 +75,22 @@ static void hix5hd2_ir_enable(struct hix5hd2_ir_priv *dev, 
bool on)
 {
u32 val;

-   regmap_read(dev->regmap, IR_CLK, );
-   if (on) {
-   val &= ~IR_CLK_RESET;
-   val |= IR_CLK_ENABLE;
+   if (dev->regmap) {
+   regmap_read(dev->regmap, IR_CLK, );
+   if (on) {
+   val &= ~IR_CLK_RESET;
+   val |= IR_CLK_ENABLE;
+   } else {
+   val &= ~IR_CLK_ENABLE;
+   val |= IR_CLK_RESET;
+   }
+   regmap_write(dev->regmap, IR_CLK, val);
} else {
-   val &= ~IR_CLK_ENABLE;
-   val |= IR_CLK_RESET;
+   if (on)
+   clk_prepare_enable(dev->clock);
+   else
+   clk_disable_unprepare(dev->clock);
}
-   regmap_write(dev->regmap, IR_CLK, val);
 }

 static int hix5hd2_ir_config(struct hix5hd2_ir_priv *priv)
@@ -207,8 +214,8 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
priv->regmap = syscon_regmap_lookup_by_phandle(node,
   
"hisilicon,power-syscon");
if (IS_ERR(priv->regmap)) {
-   dev_err(dev, "no power-reg\n");
-   return -EINVAL;
+   dev_info(dev, "no power-reg\n");
+   priv->regmap = NULL;
}

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.9.1

--
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] uvcvideo: Add bayer 16-bit format patterns

[Edgar Thier]

Hi Sakari,

Sorry for the waiting. I hope the patch I just submitted is alright.

I took the freedom and uploaded the lsusb -v output for 3 cameras with
bayer 16-bit patterns. You can find them here:

dfk23up1300_16bitbayer_RG.lsusb:  http://pastebin.com/PDdY7rs0
dfk23ux249_16bitbayer_GB.lsusb: http://pastebin.com/gtjF3Q2k
dfk33ux250_16bitbayer_GR.lsusb: http://pastebin.com/Errz5UMr

Cheers,

Edgar

> Hi Edgar,
>
> On Mon, Nov 14, 2016 at 02:26:56PM +0100, Edgar Thier wrote:
>> From aec97c931cb4b91f91dd0ed38f74d866d4f13347 Mon Sep 17 00:00:00 2001
>> From: Edgar Thier 
>> Date: Mon, 14 Nov 2016 14:17:57 +0100
>> Subject: [PATCH] uvcvideo: Add bayer 16-bit format patterns
>>
>> Add bayer 16-bit GUIDs to uvcvideo and associated them with the
>> corresponding V4L2 pixel formats.
>>
>> Signed-off-by: Edgar Thier 
>> ---
>
> ...
>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 4364ce6..6bdf592 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -605,6 +605,9 @@ struct v4l2_pix_format {
>> #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12  GRGR.. 
>> BGBG.. */
>> #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
>> GBGB.. */
>> #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
>> GRGR.. */
>> +#define V4L2_PIX_FMT_SGBRG16 v4l2_fourcc('G', 'B', '1', '6') /* 16  GBGB.. 
>> RGRG.. */
>> +#define V4L2_PIX_FMT_SRGGB16 v4l2_fourcc('R', 'G', '1', '6') /* 16  RGRG.. 
>> GBGB.. */
>> +#define V4L2_PIX_FMT_SGRBG16 v4l2_fourcc('G', 'R', '1', '6') /* 16  GRGR.. 
>> BGBG.. */
>
> Thanks for the patch!
>
> Could you rebase your uvcvideo changes on this patch, dropping the framework
> changes from yours?
>
> Cc Laurent. Laurent, could you take both of the patches to your tree after
> the rebase?
>
> The patch is also available here:
>
> 
>
>
> From c5b60538b33f993109248a642c8e9b74f7d1abd1 Mon Sep 17 00:00:00 2001
> From: Sakari Ailus 
> Date: Mon, 27 Jun 2016 16:46:16 +0300
> Subject: [PATCH 1/1] v4l: Add 16-bit raw bayer pixel formats
>
> The formats added by this patch are:
>
>   V4L2_PIX_FMT_SBGGR16
>   V4L2_PIX_FMT_SGBRG16
>   V4L2_PIX_FMT_SGRBG16
>
> V4L2_PIX_FMT_SRGGB16 already existed before the patch. Rework the
> documentation to match that of the other sample depths.
>
> Also align the description of V4L2_PIX_FMT_SRGGB16 to match with other
> similar formats.
>
> Signed-off-by: Sakari Ailus 
> Acked-by: Lad, Prabhakar 
> ---
>  Documentation/media/uapi/v4l/pixfmt-rgb.rst |  2 +-
>  Documentation/media/uapi/v4l/pixfmt-sbggr16.rst | 62 --
>  Documentation/media/uapi/v4l/pixfmt-srggb16.rst | 69 
> +
>  drivers/media/v4l2-core/v4l2-ioctl.c|  5 +-
>  include/uapi/linux/videodev2.h  |  3 ++
>  5 files changed, 77 insertions(+), 64 deletions(-)
>  delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb16.rst
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst 
> b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
> index 9cc9808..b0f3513 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
> @@ -12,9 +12,9 @@ RGB Formats
>
>  pixfmt-packed-rgb
>  pixfmt-srggb8
> -pixfmt-sbggr16
>  pixfmt-srggb10
>  pixfmt-srggb10p
>  pixfmt-srggb10alaw8
>  pixfmt-srggb10dpcm8
>  pixfmt-srggb12
> +pixfmt-srggb16
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst 
> b/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
> deleted file mode 100644
> index 6f7f327..000
> --- a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
> +++ /dev/null
> @@ -1,62 +0,0 @@
> -.. -*- coding: utf-8; mode: rst -*-
> -
> -.. _V4L2-PIX-FMT-SBGGR16:
> -
> -*
> -V4L2_PIX_FMT_SBGGR16 ('BYR2')
> -*
> -
> -Bayer RGB format
> -
> -
> -Description
> -===
> -
> -This format is similar to
> -:ref:`V4L2_PIX_FMT_SBGGR8 `, except each pixel
> -has a depth of 16 bits. The least significant byte is stored at lower
> -memory addresses (little-endian).
> -
> -**Byte Order.**
> -Each cell is one byte.
> -
> -.. flat-table::
> -:header-rows:  0
> -:stub-columns: 0
> -
> -* - start + 0:
> -  - B\ :sub:`00low`
> -  - B\ :sub:`00high`
> -  - G\ :sub:`01low`
> -  - G\ :sub:`01high`
> -  - B\ :sub:`02low`
> -  - B\ :sub:`02high`
> -  - G\ :sub:`03low`
> -  - G\ :sub:`03high`
> -* - start + 8:
> -  - G\ :sub:`10low`
> -  - G\ :sub:`10high`
> -  - R\ :sub:`11low`
> -  - R\ :sub:`11high`
> -  - 

[PATCH] uvcvideo: Add bayer 16-bit format patterns

[Edgar Thier]

>From 10ce06db4ab3c037758b3cb5264007f59801f1a1 Mon Sep 17 00:00:00 2001
From: Edgar Thier 
Date: Tue, 15 Nov 2016 06:33:10 +0100
Subject: [PATCH] uvcvideo: Add bayer 16-bit format patterns

Signed-off-by: Edgar Thier 
---
drivers/media/usb/uvc/uvc_driver.c | 20 
drivers/media/usb/uvc/uvcvideo.h   | 12 
2 files changed, 32 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 87b2fc3b..9d1fc33 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -168,6 +168,26 @@ static struct uvc_format_desc uvc_fmts[] = {
.guid   = UVC_GUID_FORMAT_RW10,
.fcc= V4L2_PIX_FMT_SRGGB10P,
},
+   {
+   .name   = "Bayer 16-bit (SBGGR16)",
+   .guid   = UVC_GUID_FORMAT_BG16,
+   .fcc= V4L2_PIX_FMT_SBGGR16,
+   },
+   {
+   .name   = "Bayer 16-bit (SGBRG16)",
+   .guid   = UVC_GUID_FORMAT_GB16,
+   .fcc= V4L2_PIX_FMT_SGBRG16,
+   },
+   {
+   .name   = "Bayer 16-bit (SRGGB16)",
+   .guid   = UVC_GUID_FORMAT_RG16,
+   .fcc= V4L2_PIX_FMT_SRGGB16,
+   },
+   {
+   .name   = "Bayer 16-bit (SGRBG16)",
+   .guid   = UVC_GUID_FORMAT_GR16,
+   .fcc= V4L2_PIX_FMT_SGRBG16,
+   },
};

/* 
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 7e4d3ee..3d6cc62 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -106,6 +106,18 @@
#define UVC_GUID_FORMAT_RGGB \
{ 'R',  'G',  'G',  'B', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_BG16 \
+   { 'B',  'G',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_GB16 \
+   { 'G',  'B',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_RG16 \
+   { 'R',  'G',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_GR16 \
+   { 'G',  'R',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
#define UVC_GUID_FORMAT_RGBP \
{ 'R',  'G',  'B',  'P', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
--
2.10.2
--
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: ERRORS

[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:   Tue Nov 15 05:00:21 CET 2016
media-tree git hash:bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build git hash:   bce0dfbb3eca1600249a7ebc5eaea2e19bfaf56b
v4l-utils git hash: db397c130912446d58c9ad3e0a81bacc0c54c159
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.7.0-164

linux-git-Module.symvers: ERRORS
linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: 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: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
smatch: ERRORS
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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

Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Laurent Pinchart]

Hi Rob,

On Monday 14 Nov 2016 19:40:26 Rob Herring wrote:
> On Mon, Oct 17, 2016 at 7:42 AM, Laurent Pinchart wrote:
> > On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> >> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> >>> On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>  On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
> > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple incompatible data link layers have been used over time to
> > transmit image data to LVDS panels. This binding supports display
> > panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
> > specifications.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  .../bindings/display/panel/panel-lvds.txt  | 119 
> >  1 file changed, 119 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> > b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> > new file mode 100644
> > index ..250861f2673e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> > @@ -0,0 +1,119 @@
> > +Generic LVDS Panel
> > +==
> > +
> > +LVDS is a physical layer specification defined in
> > ANSI/TIA/EIA-644-A. Multiple
> > +incompatible data link layers have been used over time to transmit
> > image data
> > +to LVDS panels. This bindings supports display panels compatible
> > with the
> > +following specifications.
> > +
> > +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> > February
> > +1999 (Version 1.0), Japan Electronic Industry Development
> > Association (JEIDA)
> > +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95),
> > National
> > +Semiconductor
> > +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
> > Video
> > +Electronics Standards Association (VESA)
> > +
> > +Device compatible with those specifications have been marketed under
> > the
> > +FPD-Link and FlatLink brands.
> > +
> > +
> > +Required properties:
> > +- compatible: shall contain "panel-lvds"
>  
>  Maybe as a fallback, but on its own, no way.
> >>> 
> >>> Which brings an interesting question: when designing generic DT
> >>> bindings, what's the rule regarding
> > 
> > Looks like I forgot part of the question. I meant to ask what is the rule
> > regarding usage of more precise compatible strings ?
> 
> When in doubt, always have one. If there's any chance at all that s/w
> will need to know or care, then we should have one.
> 
> > For instance (but perhaps not the best example), the
> > input/rotary-encoder.txt bindings define a "rotary-encoder" compatible
> > string, with no other bindings defining more precise compatible strings
> > for the exact rotary encoder model. When it comes to panels I believe it
> > makes sense to define model-specific compatible strings even if they're
> > unused by drivers. I'm however wondering what the rule is there, and
> > where those device-specific compatible strings should be defined. I'd
> > like to avoid using one file per panel model as done today for the
> > simple-panel bindings.
> 
> There's a few exceptions like this where there is not any sort of
> model to base a compatible on. For example, a GPIO connected LED is
> truly generic. The only way to have a more specific compatible would
> be something with the board name in it.
> 
> Your case here is in the middle. It seems like it's generic and
> passive, but perhaps power control is not. Rather than trying to
> decide, we can just cover our ass and put both a generic and specific
> compatible in.

That sounds good to me. I'll mention in the document that a more precise 
compatible is required.

> >> Call it "simple" so I can easily NAK it. :)
> >> 
> >> Define a generic structure, not a single binding trying to serve all.
> >> 
> > +- width-mm: panel display width in millimeters
> > +- height-mm: panel display height in millimeters
>  
>  This is already documented for all panels IIRC.
> >>> 
> >>> Note that this DT binding has nothing to do with the simple-panel
> >>> binding. It is instead similar to the panel-dpi and panel-dsi-cm
> >>> bindings (which currently don't but should specify the panel size in
> >>> DT). The LVDS panel driver will *not* include any panel-specific
> >>> information such as size or timings, these are specified in DT.
> >> 
> >> The panel bindings aren't really different. The biggest difference was
> >> location in the tree, but we now generally allow panels to be either a
> >> child of the LCD controller or connected with 

Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Rob Herring]

On Mon, Oct 17, 2016 at 7:42 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
>> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
>> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>> >>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple incompatible data link layers have been used over time to
>> >>> transmit image data to LVDS panels. This binding supports display
>> >>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
>> >>> specifications.
>> >>>
>> >>> Signed-off-by: Laurent Pinchart
>> >>> 
>> >>> ---
>> >>>
>> >>>  .../bindings/display/panel/panel-lvds.txt  | 119 ++
>> >>>  1 file changed, 119 insertions(+)
>> >>>  create mode 100644
>> >>>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> new file mode 100644
>> >>> index ..250861f2673e
>> >>> --- /dev/null
>> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> @@ -0,0 +1,119 @@
>> >>> +Generic LVDS Panel
>> >>> +==
>> >>> +
>> >>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple
>> >>> +incompatible data link layers have been used over time to transmit
>> >>> image data
>> >>> +to LVDS panels. This bindings supports display panels compatible with
>> >>> the
>> >>> +following specifications.
>> >>> +
>> >>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
>> >>> February
>> >>> +1999 (Version 1.0), Japan Electronic Industry Development Association
>> >>> (JEIDA)
>> >>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
>> >>> +Semiconductor
>> >>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
>> >>> Video
>> >>> +Electronics Standards Association (VESA)
>> >>> +
>> >>> +Device compatible with those specifications have been marketed under
>> >>> the
>> >>> +FPD-Link and FlatLink brands.
>> >>> +
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: shall contain "panel-lvds"
>> >>
>> >> Maybe as a fallback, but on its own, no way.
>> >
>> > Which brings an interesting question: when designing generic DT bindings,
>> > what's the rule regarding
>
> Looks like I forgot part of the question. I meant to ask what is the rule
> regarding usage of more precise compatible strings ?

When in doubt, always have one. If there's any chance at all that s/w
will need to know or care, then we should have one.

> For instance (but perhaps not the best example), the input/rotary-encoder.txt
> bindings define a "rotary-encoder" compatible string, with no other bindings
> defining more precise compatible strings for the exact rotary encoder model.
> When it comes to panels I believe it makes sense to define model-specific
> compatible strings even if they're unused by drivers. I'm however wondering
> what the rule is there, and where those device-specific compatible strings
> should be defined. I'd like to avoid using one file per panel model as done
> today for the simple-panel bindings.

There's a few exceptions like this where there is not any sort of
model to base a compatible on. For example, a GPIO connected LED is
truly generic. The only way to have a more specific compatible would
be something with the board name in it.

Your case here is in the middle. It seems like it's generic and
passive, but perhaps power control is not. Rather than trying to
decide, we can just cover our ass and put both a generic and specific
compatible in.

>> Call it "simple" so I can easily NAK it. :)
>>
>> Define a generic structure, not a single binding trying to serve all.
>>
>> >> > +- width-mm: panel display width in millimeters
>> >> > +- height-mm: panel display height in millimeters
>> >>
>> >> This is already documented for all panels IIRC.
>> >
>> > Note that this DT binding has nothing to do with the simple-panel binding.
>> > It is instead similar to the panel-dpi and panel-dsi-cm bindings (which
>> > currently don't but should specify the panel size in DT). The LVDS panel
>> > driver will *not* include any panel-specific information such as size or
>> > timings, these are specified in DT.
>>
>> The panel bindings aren't really different. The biggest difference was
>> location in the tree, but we now generally allow panels to be either a
>> child of the LCD controller or connected with OF graph. We probably
>> need to work on restructuring the panel bindings a bit. We should have
>> an inheritance with a base panel binding of things like size, label,
>> graph, backlight, etc, then perhaps an interface specific bindings for
>> LVDS, DSI, and parallel, 

Re: [PATCH] [media] mtk-mdp: allocate video_device dynamically

[Minghsiu Tsai]

On Fri, 2016-11-11 at 11:51 +0100, Hans Verkuil wrote:
> Almost correct:
> 
> On 11/07/2016 01:42 PM, Minghsiu Tsai wrote:
> > It can fix known problems with embedded video_device structs.
> > 
> > Signed-off-by: Minghsiu Tsai 
> > ---
> >  drivers/media/platform/mtk-mdp/mtk_mdp_core.h |  2 +-
> >  drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  | 33 
> > ---
> >  2 files changed, 21 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h 
> > b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > index 848569d..ad1cff3 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > @@ -167,7 +167,7 @@ struct mtk_mdp_dev {
> > struct mtk_mdp_comp *comp[MTK_MDP_COMP_ID_MAX];
> > struct v4l2_m2m_dev *m2m_dev;
> > struct list_headctx_list;
> > -   struct video_device vdev;
> > +   struct video_device *vdev;
> > struct v4l2_device  v4l2_dev;
> > struct workqueue_struct *job_wq;
> > struct platform_device  *vpu_dev;
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c 
> > b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > index 9a747e7..b8dee1c 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > @@ -1236,16 +1236,22 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev 
> > *mdp)
> > int ret;
> >  
> > mdp->variant = _mdp_default_variant;
> > -   mdp->vdev.device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
> > -   mdp->vdev.fops = _mdp_m2m_fops;
> > -   mdp->vdev.ioctl_ops = _mdp_m2m_ioctl_ops;
> > -   mdp->vdev.release = video_device_release_empty;
> > -   mdp->vdev.lock = >lock;
> > -   mdp->vdev.vfl_dir = VFL_DIR_M2M;
> > -   mdp->vdev.v4l2_dev = >v4l2_dev;
> > -   snprintf(mdp->vdev.name, sizeof(mdp->vdev.name), "%s:m2m",
> > +   mdp->vdev = video_device_alloc();
> > +   if (!mdp->vdev) {
> > +   dev_err(dev, "failed to allocate video device\n");
> > +   ret = -ENOMEM;
> > +   goto err_video_alloc;
> > +   }
> > +   mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
> > +   mdp->vdev->fops = _mdp_m2m_fops;
> > +   mdp->vdev->ioctl_ops = _mdp_m2m_ioctl_ops;
> > +   mdp->vdev->release = video_device_release;
> > +   mdp->vdev->lock = >lock;
> > +   mdp->vdev->vfl_dir = VFL_DIR_M2M;
> > +   mdp->vdev->v4l2_dev = >v4l2_dev;
> > +   snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
> >  MTK_MDP_MODULE_NAME);
> > -   video_set_drvdata(>vdev, mdp);
> > +   video_set_drvdata(mdp->vdev, mdp);
> >  
> > mdp->m2m_dev = v4l2_m2m_init(_mdp_m2m_ops);
> > if (IS_ERR(mdp->m2m_dev)) {
> > @@ -1254,26 +1260,27 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev 
> > *mdp)
> > goto err_m2m_init;
> > }
> >  
> > -   ret = video_register_device(>vdev, VFL_TYPE_GRABBER, 2);
> > +   ret = video_register_device(mdp->vdev, VFL_TYPE_GRABBER, 2);
> > if (ret) {
> > dev_err(dev, "failed to register video device\n");
> > goto err_vdev_register;
> > }
> >  
> > v4l2_info(>v4l2_dev, "driver registered as /dev/video%d",
> > - mdp->vdev.num);
> > + mdp->vdev->num);
> > return 0;
> >  
> >  err_vdev_register:
> > v4l2_m2m_release(mdp->m2m_dev);
> >  err_m2m_init:
> > -   video_device_release(>vdev);
> > +   video_unregister_device(mdp->vdev);
> 
> This should remain video_device_release: the video_register_device call 
> failed, so
> the device hasn't been registered. In that case just release the device (i.e.
> free the allocated memory).
> 
Hi Hans,

I have uploaded patch v2 for this. Thanks for your review.


Best regards,
Ming Hsiu

> > +err_video_alloc:
> >  
> > return ret;
> >  }
> >  
> >  void mtk_mdp_unregister_m2m_device(struct mtk_mdp_dev *mdp)
> >  {
> > -   video_device_release(>vdev);
> > +   video_unregister_device(mdp->vdev);
> > v4l2_m2m_release(mdp->m2m_dev);
> >  }
> > 
> 
> 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

[PATCH v2] [media] mtk-mdp: allocate video_device dynamically

[Minghsiu Tsai]

It can fix known problems with embedded video_device structs.

Signed-off-by: Minghsiu Tsai 

---
Changes in v2:
. Call video_device_release() instead of video_unregister_device()
  in mtk_mdp_register_m2m_device()


---
 drivers/media/platform/mtk-mdp/mtk_mdp_core.h |  2 +-
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  | 33 ---
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h 
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
index 848569d..ad1cff3 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
@@ -167,7 +167,7 @@ struct mtk_mdp_dev {
struct mtk_mdp_comp *comp[MTK_MDP_COMP_ID_MAX];
struct v4l2_m2m_dev *m2m_dev;
struct list_headctx_list;
-   struct video_device vdev;
+   struct video_device *vdev;
struct v4l2_device  v4l2_dev;
struct workqueue_struct *job_wq;
struct platform_device  *vpu_dev;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 9a747e7..13afe48 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -1236,16 +1236,22 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
int ret;
 
mdp->variant = _mdp_default_variant;
-   mdp->vdev.device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
-   mdp->vdev.fops = _mdp_m2m_fops;
-   mdp->vdev.ioctl_ops = _mdp_m2m_ioctl_ops;
-   mdp->vdev.release = video_device_release_empty;
-   mdp->vdev.lock = >lock;
-   mdp->vdev.vfl_dir = VFL_DIR_M2M;
-   mdp->vdev.v4l2_dev = >v4l2_dev;
-   snprintf(mdp->vdev.name, sizeof(mdp->vdev.name), "%s:m2m",
+   mdp->vdev = video_device_alloc();
+   if (!mdp->vdev) {
+   dev_err(dev, "failed to allocate video device\n");
+   ret = -ENOMEM;
+   goto err_video_alloc;
+   }
+   mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
+   mdp->vdev->fops = _mdp_m2m_fops;
+   mdp->vdev->ioctl_ops = _mdp_m2m_ioctl_ops;
+   mdp->vdev->release = video_device_release;
+   mdp->vdev->lock = >lock;
+   mdp->vdev->vfl_dir = VFL_DIR_M2M;
+   mdp->vdev->v4l2_dev = >v4l2_dev;
+   snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
 MTK_MDP_MODULE_NAME);
-   video_set_drvdata(>vdev, mdp);
+   video_set_drvdata(mdp->vdev, mdp);
 
mdp->m2m_dev = v4l2_m2m_init(_mdp_m2m_ops);
if (IS_ERR(mdp->m2m_dev)) {
@@ -1254,26 +1260,27 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
goto err_m2m_init;
}
 
-   ret = video_register_device(>vdev, VFL_TYPE_GRABBER, 2);
+   ret = video_register_device(mdp->vdev, VFL_TYPE_GRABBER, 2);
if (ret) {
dev_err(dev, "failed to register video device\n");
goto err_vdev_register;
}
 
v4l2_info(>v4l2_dev, "driver registered as /dev/video%d",
- mdp->vdev.num);
+ mdp->vdev->num);
return 0;
 
 err_vdev_register:
v4l2_m2m_release(mdp->m2m_dev);
 err_m2m_init:
-   video_device_release(>vdev);
+   video_device_release(mdp->vdev);
+err_video_alloc:
 
return ret;
 }
 
 void mtk_mdp_unregister_m2m_device(struct mtk_mdp_dev *mdp)
 {
-   video_device_release(>vdev);
+   video_unregister_device(mdp->vdev);
v4l2_m2m_release(mdp->m2m_dev);
 }
-- 
1.9.1

--
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 v4] media: Driver for Toshiba et8ek8 5MP sensor

[Sebastian Reichel]

Hi Sakari,

On Mon, Nov 14, 2016 at 11:58:28PM +0200, Sakari Ailus wrote:
> [...]
>
> On Fri, Nov 04, 2016 at 01:05:25AM +0100, Sebastian Reichel wrote:
> > I'm not sure what part relevant for video-bus-switch is currently
> > not supported?
> > 
> > video-bus-switch registers its own async notifier and only registers
> > itself as subdevices to omap3isp, once its own subdevices have been
> > registered successfully.
> 
> Do you happen to have patches for this?
> I still think we should clean up the V4L2 async framework though.

http://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/tree/drivers/media/platform/video-bus-switch.c?h=n900-camera-ivo

It was inside of the RFC series Ivo sent in April.

> [...]

-- Sebastian


signature.asc
Description: PGP signature

[PATCH] ARM: shmobile: dts: Switch to panel-lvds bindings for Mitsubishi panels

[Laurent Pinchart]

The aa104xd12 and aa121td01 panels are LVDS panels, not DPI panels.
Use the correct DT bindings.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi | 3 ++-
 arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

Hello,

This patch is an example of how the panel-lvds bindings should be used for
display panels. It isn't meant to be merged upstream at the moment as the
bindings haven't been accepted yet but can already be used as both an example
and a test base for LVDS mode selection.

diff --git a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi 
b/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
index 65cb50f0c29f..238d14bb0ebe 100644
--- a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
+++ b/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
@@ -10,10 +10,11 @@
 
 / {
panel {
-   compatible = "mitsubishi,aa104xd12", "panel-dpi";
+   compatible = "mitsubishi,aa104xd12", "panel-lvds";
 
width-mm = <210>;
height-mm = <158>;
+   data-mapping = "jeida-18";
 
panel-timing {
/* 1024x768 @65Hz */
diff --git a/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi 
b/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
index a07ebf8f6938..04aafd479775 100644
--- a/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
+++ b/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
@@ -10,10 +10,11 @@
 
 / {
panel {
-   compatible = "mitsubishi,aa121td01", "panel-dpi";
+   compatible = "mitsubishi,aa121td01", "panel-lvds";
 
width-mm = <261>;
height-mm = <163>;
+   data-mapping = "jeida-18";
 
panel-timing {
/* 1280x800 @60Hz */
-- 
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: [RFC v4 08/21] media: Enable allocating the media device dynamically

[Shuah Khan]

On 11/14/2016 06:40 AM, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Tue, Nov 08, 2016 at 12:20:29PM -0700, Shuah Khan wrote:
>> On Tue, Nov 8, 2016 at 6:55 AM, Sakari Ailus
>>  wrote:
>>> From: Sakari Ailus 
>>>
>>> Allow allocating the media device dynamically. As the struct media_device
>>> embeds struct media_devnode, the lifetime of that object is that same than
>>> that of the media_device.
>>>
>>> Signed-off-by: Sakari Ailus 
>>> ---
>>>  drivers/media/media-device.c | 15 +++
>>>  include/media/media-device.h | 13 +
>>>  2 files changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
>>> index a31329d..496195e 100644
>>> --- a/drivers/media/media-device.c
>>> +++ b/drivers/media/media-device.c
>>> @@ -684,6 +684,21 @@ void media_device_init(struct media_device *mdev)
>>>  }
>>>  EXPORT_SYMBOL_GPL(media_device_init);
>>>
>>> +struct media_device *media_device_alloc(struct device *dev)
>>> +{
>>> +   struct media_device *mdev;
>>> +
>>> +   mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
>>> +   if (!mdev)
>>> +   return NULL;
>>> +
>>> +   mdev->dev = dev;
>>> +   media_device_init(mdev);
>>> +
>>> +   return mdev;
>>> +}
>>> +EXPORT_SYMBOL_GPL(media_device_alloc);
>>> +
>>
>> One problem with this allocation is, this media device can't be shared across
>> drivers. For au0828 and snd-usb-audio should be able to share the
>> media_device. That is what the Media Allocator API patch series does.
>> This a quick review and I will review the patch series and get back to
>> you.
> 
> The assumption has always been there that a media device has a single struct
> device related to it. It hasn't been visible in the function call API
> though, just in the data structures.
> 
> I have to admit I may have forgotten something that was discussed back then,
> but do you need to share the same media device over multiple devices in the
> system? I don't see that at least in the allocator patch itself. It's
> "[PATCH v3] media: Media Device Allocator API", isn't it?
> 


Hi Sakari,

Remember the work I am doing that adds Media Controller API to snd-usb-audio
and au0828 so they can share the media resources. That is where we need the
media device sharable. Please see the following: this patch series includes
the API and au0828 change to use it. I tested it with snd-usb-audio change,
didn't include it at that time.

https://www.mail-archive.com/linux-media@vger.kernel.org/msg98793.html
https://www.mail-archive.com/linux-media@vger.kernel.org/msg97779.html
https://www.mail-archive.com/linux-media@vger.kernel.org/msg97704.html

I am going to be sending the rebased Media Device Allocator patches with both
au0828 and snd-usb-audio using it in a couple of days. No code changes, just
rebased to Linux 4.9-rc4

thanks,
-- Shuah
--
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 01/12] [media] rc-main: clear rc_map.name in ir_free_table()

[Shuah Khan]

On 08/09/2016 03:32 PM, Max Kellermann wrote:
> rc_unregister_device() will first call ir_free_table(), and later
> device_del(); however, the latter causes a call to rc_dev_uevent(),
> which prints rc_map.name, which at this point has already bee freed.
> 
> This fixes a use-after-free bug found with KASAN.
> 
> Signed-off-by: Max Kellermann 
> ---
>  drivers/media/rc/rc-main.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 8e7f292..1e5a520 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -159,6 +159,7 @@ static void ir_free_table(struct rc_map *rc_map)
>  {
>   rc_map->size = 0;
>   kfree(rc_map->name);
> + rc_map->name = NULL;
>   kfree(rc_map->scan);
>   rc_map->scan = NULL;
>  }
> 

Hi Mauro,

Could you please get this fix into 4.9. I am seeing the following when I do
rmmod on au0828

[  179.010878] 
==
[  179.010895] BUG: KASAN: use-after-free in string+0x170/0x1f0 at addr 
8801bd513000
[  179.010900] Read of size 1 by task rmmod/1831
[  179.010908] CPU: 1 PID: 1831 Comm: rmmod Tainted: GW   4.9.0-rc5 
#5
[  179.010910] Hardware name: Hewlett-Packard HP ProBook 6475b/180F, BIOS 68TTU 
Ver. F.04 08/03/2012
[  179.010914]  8801aea2f680 81b37ad3 8801fa403b80 
8801bd513000
[  179.010922]  8801aea2f6a8 8156c301 8801aea2f738 
8801bd513000
[  179.010930]  8801fa403b80 8801aea2f728 8156c59a 
8801aea2f770
[  179.010937] Call Trace:
[  179.010944]  [] dump_stack+0x67/0x94
[  179.010950]  [] kasan_object_err+0x21/0x70
[  179.010954]  [] kasan_report_error+0x1fa/0x4d0
[  179.010968]  [] ? au0828_exit+0x10/0x21 [au0828]
[  179.010973]  [] __asan_report_load1_noabort+0x43/0x50
[  179.010978]  [] ? string+0x170/0x1f0
[  179.010982]  [] string+0x170/0x1f0
[  179.010987]  [] vsnprintf+0x374/0x1c50
[  179.010992]  [] ? pointer+0xa80/0xa80
[  179.010996]  [] ? save_stack+0x46/0xd0
[  179.011001]  [] ? __kmalloc+0x14a/0x2a0
[  179.011006]  [] ? kobject_get_path+0x9a/0x200
[  179.011010]  [] ? kobject_uevent_env+0x282/0xca0
[  179.011014]  [] ? kobject_uevent+0xb/0x10
[  179.011020]  [] ? device_del+0x434/0x6d0
[  179.011029]  [] ? rc_unregister_device+0x177/0x240 
[rc_core]
[  179.011037]  [] ? au0828_rc_unregister+0x60/0xb0 [au0828]

The problem is fixed with this patch on Linux 4.9-rc4

thanks,
-- Shuah
--
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/2] devicetree/bindings: display: Add bindings for LVDS panels

[Laurent Pinchart]

Hi Rob,

Ping ?

On Monday 17 Oct 2016 15:42:56 Laurent Pinchart wrote:
> On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> > On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> >> On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
> >>> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>  LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>  Multiple incompatible data link layers have been used over time to
>  transmit image data to LVDS panels. This binding supports display
>  panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
>  specifications.
>  
>  Signed-off-by: Laurent Pinchart
>  
>  ---
>  
>   .../bindings/display/panel/panel-lvds.txt  | 119 
>   1 file changed, 119 insertions(+)
>   create mode 100644
>   Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
>  
>  diff --git
>  a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>  b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>  new file mode 100644
>  index ..250861f2673e
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>  @@ -0,0 +1,119 @@
>  +Generic LVDS Panel
>  +==
>  +
>  +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>  Multiple
>  +incompatible data link layers have been used over time to transmit
>  image data
>  +to LVDS panels. This bindings supports display panels compatible with
>  the
>  +following specifications.
>  +
>  +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
>  February
>  +1999 (Version 1.0), Japan Electronic Industry Development Association
>  (JEIDA)
>  +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95),
>  National
>  +Semiconductor
>  +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
>  Video
>  +Electronics Standards Association (VESA)
>  +
>  +Device compatible with those specifications have been marketed under
>  the
>  +FPD-Link and FlatLink brands.
>  +
>  +
>  +Required properties:
>  +- compatible: shall contain "panel-lvds"
> >>> 
> >>> Maybe as a fallback, but on its own, no way.
> >> 
> >> Which brings an interesting question: when designing generic DT
> >> bindings, what's the rule regarding
> 
> Looks like I forgot part of the question. I meant to ask what is the rule
> regarding usage of more precise compatible strings ?
> 
> For instance (but perhaps not the best example), the
> input/rotary-encoder.txt bindings define a "rotary-encoder" compatible
> string, with no other bindings defining more precise compatible strings for
> the exact rotary encoder model. When it comes to panels I believe it makes
> sense to define model-specific compatible strings even if they're unused by
> drivers. I'm however wondering what the rule is there, and where those
> device-specific compatible strings should be defined. I'd like to avoid
> using one file per panel model as done today for the simple-panel bindings.
> 
> > Call it "simple" so I can easily NAK it. :)
> > 
> > Define a generic structure, not a single binding trying to serve all.
> > 
> >>> > +- width-mm: panel display width in millimeters
> >>> > +- height-mm: panel display height in millimeters
> >>> 
> >>> This is already documented for all panels IIRC.
> >> 
> >> Note that this DT binding has nothing to do with the simple-panel
> >> binding. It is instead similar to the panel-dpi and panel-dsi-cm bindings
> >> (which currently don't but should specify the panel size in DT). The LVDS
> >> panel driver will *not* include any panel-specific information such as
> >> size or timings, these are specified in DT.
> > 
> > The panel bindings aren't really different. The biggest difference was
> > location in the tree, but we now generally allow panels to be either a
> > child of the LCD controller or connected with OF graph. We probably
> > need to work on restructuring the panel bindings a bit. We should have
> > an inheritance with a base panel binding of things like size, label,
> > graph, backlight, etc, then perhaps an interface specific bindings for
> > LVDS, DSI, and parallel, then a panel specific binding. With this the
> > panel specific binding is typically just a compatible string and which
> > inherited properties apply to it.
> 
> That sounds good to me, but we have multiple models for panel bindings.
> 
> As you mentioned panels can be referenced through an LCD controller node
> property containing a phandle to the panel node, or through OF graph. That's
> a situation we have today, and we need to keep supporting both (at least
> for existing panels, perhaps not for the new ones).
> 
> Another difference is how to express panel data such as 

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

[Sakari Ailus]

Hi Sebastian,

On Fri, Nov 04, 2016 at 01:05:25AM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Nov 04, 2016 at 01:05:01AM +0200, Sakari Ailus wrote:
> > On Thu, Nov 03, 2016 at 11:48:43PM +0100, Sebastian Reichel wrote:
> > > On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > > > > Thanks, this answered half of my questions already. ;-)
> > > > > :-).
> > > > > 
> > > > > I'll have to go through the patches, et8ek8 driver is probably not
> > > > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > > > camera switching, then some omap3isp patches to bind flash and
> > > > > autofocus into the subdevice.
> > > > > 
> > > > > Then, device tree support on n900 can be added.
> > > > 
> > > > I briefly discussed with with Sebastian.
> > > > 
> > > > Do you think the elusive support for the secondary camera is worth 
> > > > keeping
> > > > out the main camera from the DT in mainline? As long as there's a 
> > > > reasonable
> > > > way to get it working, I'd just merge that. If someone ever gets the
> > > > secondary camera working properly and nicely with the video bus switch,
> > > > that's cool, we'll somehow deal with the problem then. But frankly I 
> > > > don't
> > > > think it's very useful even if we get there: the quality is really bad.
> > > 
> > > If we want to keep open the option to add proper support for the
> > > second camera, we could also add the bus switch and not add the
> > > front camera node in DT. Then adding the front camera does not
> > > require DT or userspace API changes. It would need an additional
> > > DT quirk in arch/arm/mach-omap2/board-generic.c for RX51, which
> > > adds the CCP2 bus settings from the camera node to the bus
> > > switch node to keep isp_of_parse_node happy. That should be
> > > easy to implement and not add much delay in upstreaming.
> > 
> > By adding the video bus switch we have a little bit more complex system as a
> > whole. The V4L2 async does not currently support this. There's more here:
> > 
> > 
> 
> I'm not sure what part relevant for video-bus-switch is currently
> not supported?
> 
> video-bus-switch registers its own async notifier and only registers
> itself as subdevices to omap3isp, once its own subdevices have been
> registered successfully.

Do you happen to have patches for this?

I still think we should clean up the V4L2 async framework though.

> 
> > What I thought was that once we have everything that's required in
> > place, we can just change what's in DT. But the software needs to
> > continue to work with the old DT content.
> 
> Right, so DT is not a problem. But adding the switch would change
> the media-graph, which is exposed to userspace.

Well, yes, indeed. We'll have those cases coming anyway, as support for
multiple streams over a single link is added. In some cases more sub-devices
will be needed to expose all the necessary configurability to the user.

> 
> > > For actually getting both cameras available with runtime-switching
> > > the proper solution would probably involve moving the parsing of
> > > the bus-settings to the sensor driver and providing a callback.
> > > This callback can be called by omap3isp when it wants to configure
> > > the phy (which is basically when it starts streaming). That seems
> > > to be the only place needing the buscfg anyways.
> > > 
> > > Then the video-bus-switch could do something like this (pseudocode):
> > > 
> > > static void get_buscfg(struct *this, struct *buscfg) {
> > > if (selected_cam == 0)
> > > return this->sensor_a->get_buscfg(buscfg);
> > > else
> > > return this->sensor_b->get_buscfg(buscfg);
> > > }
> > > 
> > > Regarding the usefulness: I noticed, that the Neo900 people also
> > > plan to have the bus-switch [0]. It's still the same crappy front-cam,
> > > though. Nevertheless it might be useful for testing. It has nice
> > > test-image capabilities, which might be useful for regression
> > > testing once everything is in place.
> > > 
> > > [0] http://neo900.org/stuff/block-diagrams/neo900/neo900.html
> > 
> > Seriously? I suppose there should be no need for that anymore, is there?
> > 
> > I think they wanted to save one GPIO in order to shave off 0,0001 cents from
> > the manufacturing costs or something like that. And the result is...
> > painful. :-I
> 
> CSI1/CCP2 is more than a single I/O pin, isn't it? Or do you
> reference to the GPIO dual use to enable frontcam and switch
> between the cameras? That is indeed a really ugly solution :(

The GPIO, yes. It was a really bad idea...

-- 
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 dtv-scan-tables] Rename pl-Krosno_Sucha_Gora with only ASCII characters

[Thomas Petazzoni]

The pl-Krosno_Sucha_Gora file, added in commit
4cb113fd15e562f0629000fcad9f41405595198d, is the only file that
contains non-ASCII characters in the tree. This causes a number of
build issues with other packages that don't necessarily handle very
well non-ASCII file name encodings.

Since no other file in the tree contain non-ASCII characters in their
name, this commit renames pl-Krosno_Sucha_Gora similarly.

Examples of files that are named with only ASCII characters even if
the city name really contains non-ASCII characters:

  - pl-Wroclaw should be written pl-Wrocław
  - se-Laxsjo should be written se-Laxsjö
  - de-Dusseldorf should be written de-Düsseldorf
  - vn-Thaibinh should be written vn-Thái_Bình

Since there is no real standardization on the encoding of file names,
we'd better be safe and use only ASCII characters.

Signed-off-by: Thomas Petazzoni 
---
 "dvb-t/pl-Krosno_Sucha_G\303\263ra" => dvb-t/pl-Krosno_Sucha_Gora | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename "dvb-t/pl-Krosno_Sucha_G\303\263ra" => dvb-t/pl-Krosno_Sucha_Gora (100%)

diff --git "a/dvb-t/pl-Krosno_Sucha_G\303\263ra" b/dvb-t/pl-Krosno_Sucha_Gora
similarity index 100%
rename from "dvb-t/pl-Krosno_Sucha_G\303\263ra"
rename to dvb-t/pl-Krosno_Sucha_Gora
-- 
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 5/5] media: platform: rcar_drif: Add DRIF support

[Geert Uytterhoeven]

Hi Rob,

On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring  wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@

>> > +Example
>> > +
>> > +
>> > +SoC common dtsi file
>> > +
>> > +   drif00: rif@e6f4 {
>> > +   compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > +   reg = <0 0xe6f4 0 0x64>;
>> > +   interrupts = ;
>> > +   clocks = < CPG_MOD 515>;
>> > +   clock-names = "fck";
>> > +   dmas = < 0x20>, < 0x20>;
>> > +   dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.

The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.

>> > +   power-domains = < R8A7795_PD_ALWAYS_ON>;
>> > +   status = "disabled";
>> > +   };
>> > +
>> > +   drif01: rif@e6f5 {
>> > +   compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > +   reg = <0 0xe6f5 0 0x64>;
>> > +   interrupts = ;
>> > +   clocks = < CPG_MOD 514>;
>> > +   clock-names = "fck";
>> > +   dmas = < 0x22>, < 0x22>;
>> > +   dma-names = "rx", "rx";
>> > +   power-domains = < R8A7795_PD_ALWAYS_ON>;
>> > +   status = "disabled";
>> > +   };
>> > +
>> > +   drif0: rif@0 {
>> > +   compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > +   sub-channels = <>, <>;
>> > +   status = "disabled";
>> > +   };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two 
>> channels
>> are mostly independent having separate DT nodes makes sense to me. However, 
>> as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a 
>> DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.

Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 5/5] media: platform: rcar_drif: Add DRIF support

[Rob Herring]

On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> Hi Ramesh,
> 
> Thank you for the patch.
> 
> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> > 
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and the
> > tuner device, which is registered as a sub-device, determines the receive
> > sample rate and format.
> > 
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF acts
> > as a slave device and the tuner device acts as a master transmitting the
> > samples. The driver allows asynchronous binding of a tuner device that
> > is registered as a v4l2 sub-device. The driver can learn about the tuner
> > it is interfaced with based on port endpoint properties of the device in
> > device tree. The V4L2 SDR device inherits the controls exposed by the
> > tuner device.
> > 
> > The device can also be configured to use either one or both of the data
> > pins at runtime based on the master (tuner) configuration.
> > 
> > Signed-off-by: Ramesh Shanmugasundaram
> >  ---
> >  .../devicetree/bindings/media/renesas,drif.txt |  136 ++
> >  drivers/media/platform/Kconfig |   25 +
> >  drivers/media/platform/Makefile|1 +
> >  drivers/media/platform/rcar_drif.c | 1574
> >  4 files changed, 1736 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> > 
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
> > 100644
> > index 000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++-++-+
> > +| |-SCK--->|CLK  |
> > +|   Master|-SS>|SYNC  DRIFn (slave)  |
> > +| |-SD0--->|D0   |
> > +| |-SD1--->|D1   |
> > ++-++-+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1).
> > +The sub-channels are like two individual channels in itself that share the
> > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like
> > +irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's sub-channel
> > +as a separate node. The parent channel ties the sub-channels together with
> > +their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> > R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> > device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +-
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +-
> > +- port: child port node of a channel that defines the local and remote
> > +endpoints. The remote endpoint is assumed to be a tuner subdevice
> > +   endpoint.
> > +- renesas,syncmd   : sync mode
> > +0 (Frame start sync pulse mode. 1-bit width pulse
> > +  

Re: [PATCH 2/5] media: i2c: max2175: Add MAX2175 support

[Rob Herring]

On Wed, Nov 09, 2016 at 03:44:41PM +, Ramesh Shanmugasundaram wrote:
> This patch adds driver support for MAX2175 chip. This is Maxim
> Integrated's RF to Bits tuner front end chip designed for software-defined
> radio solutions. This driver exposes the tuner as a sub-device instance
> with standard and custom controls to configure the device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
>  .../devicetree/bindings/media/i2c/max2175.txt  |   61 +

It's preferred that bindings are a separate patch.

>  drivers/media/i2c/Kconfig  |4 +
>  drivers/media/i2c/Makefile |2 +
>  drivers/media/i2c/max2175/Kconfig  |8 +
>  drivers/media/i2c/max2175/Makefile |4 +
>  drivers/media/i2c/max2175/max2175.c| 1558 
> 
>  drivers/media/i2c/max2175/max2175.h|  108 ++
>  7 files changed, 1745 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
>  create mode 100644 drivers/media/i2c/max2175/Kconfig
>  create mode 100644 drivers/media/i2c/max2175/Makefile
>  create mode 100644 drivers/media/i2c/max2175/max2175.c
>  create mode 100644 drivers/media/i2c/max2175/max2175.h
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
> b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> new file mode 100644
> index 000..69f0dad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> @@ -0,0 +1,61 @@
> +Maxim Integrated MAX2175 RF to Bits tuner
> +-
> +
> +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
> +RF to Bits® front-end designed for software-defined radio solutions.
> +
> +Required properties:
> +
> +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> +- clocks: phandle to the fixed xtal clock.
> +- clock-names: name of the fixed xtal clock.
> +- port: child port node of a tuner that defines the local and remote
> +  endpoints. The remote endpoint is assumed to be an SDR device
> +  that is capable of receiving the digital samples from the tuner.
> +
> +Optional properties:
> +
> +- maxim,slave  : empty property indicates this is a slave of
> + another master tuner. This is used to define two
> + tuners in diversity mode (1 master, 1 slave). By
> + default each tuner is an individual master.
> +- maxim,refout-load-pF: load capacitance value (in pF) on reference

Please add 'pF' to property-units.txt.

> + output drive level. The possible load values are
> +  0pF (default - refout disabled)
> + 10pF
> + 20pF
> + 30pF
> + 40pF
> + 60pF
> + 70pF
> +- maxim,am-hiz : empty property indicates AM Hi-Z filter path is
> + selected for AM antenna input. By default this
> + filter path is not used.
> +
> +Example:
> +
> +
> +Board specific DTS file
> +
> +/* Fixed XTAL clock node */
> +maxim_xtal: maximextal {

clock {

> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <36864000>;
> +};
> +
> +/* A tuner device instance under i2c bus */
> +max2175_0: tuner@60 {
> + compatible = "maxim,max2175";
> + reg = <0x60>;
> + clocks = <_xtal>;
> + clock-names = "xtal";
> + maxim,refout-load-pF = <10>;
> +
> + port {
> + max2175_0_ep: endpoint {
> + remote-endpoint = <_rx_v4l2_sdr_device>;

'v4l2' is not something that should appear in a DT.

> + };
> + };
> +
> +};
--
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 v4 7/8] v4l: Add signal lock status to source change events

[Steve Longerbeam]

On 11/14/2016 11:19 AM, Steve Longerbeam wrote:



On 11/14/2016 03:36 AM, Hans Verkuil wrote:

On 08/03/2016 08:03 PM, Steve Longerbeam wrote:

Add a signal lock status change to the source changes bitmask.
This indicates there was a signal lock or unlock event detected
at the input of a video decoder.

Signed-off-by: Steve Longerbeam 
Cc: Mauro Carvalho Chehab 

---

v4:
- converted to rst from DocBook

v3: no changes
v2: no changes
---
  Documentation/media/uapi/v4l/vidioc-dqevent.rst | 9 +
  Documentation/media/videodev2.h.rst.exceptions  | 1 +
  include/uapi/linux/videodev2.h  | 1 +
  3 files changed, 11 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst

index 73c0d5b..7d8a053 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -564,6 +564,15 @@ call.
an input. This can come from an input connector or from a video
decoder.
  +-  .. row 2
+
+   -  ``V4L2_EVENT_SRC_CH_LOCK_STATUS``
+
+   -  0x0002
+
+   -  This event gets triggered when there is a signal lock or
+  unlock detected at the input of a video decoder.
+
Return Value
  
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions

index 9bb9a6c..f412cc8 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -453,6 +453,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS 
ctrl-changes-flags

  replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
+replace define V4L2_EVENT_SRC_CH_LOCK_STATUS src-changes-flags
replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ 
v4l2-event-motion-det
  diff --git a/include/uapi/linux/videodev2.h 
b/include/uapi/linux/videodev2.h

index 724f43e..08a153f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2078,6 +2078,7 @@ struct v4l2_event_frame_sync {
  };
#define V4L2_EVENT_SRC_CH_RESOLUTION(1 << 0)
+#define V4L2_EVENT_SRC_CH_LOCK_STATUS(1 << 1)
struct v4l2_event_src_change {
  __u32 changes;


Quoting from an old (July) conversation about this:

I'm not entirely sure I like this. Typically losing lock means 
that this event
is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and 
userspace has
to check the new timings etc., which will fail if there is no lock 
anymore.


This information is also available through ENUMINPUT.

I would need to know more about why you think this is needed, 
because I don't

see what this adds.

Hi Hans,

At least on the ADV718x, a source resolution change (from an
autodetected video
standard change) and a signal lock status change are distinct events.
For example
there can be a temporary loss of input signal lock without a change in
detected
input video standard/resolution.
OK, but what can the application do with that event? If the glitch 
didn't

affect the video, then it is pointless.


Hi Hans, that's just it, for i.mx6 it does affect video. On i.mx6 a 
temporary
loss of signal from the adv7180 often results in a "split image", or 
rolling

image from captured frame to the next, and the only way to recover
from this failure is to restart the pipeline (stream off -- stream 
on). So

the application needs to be informed of this temporary loss of signal
event in order to restart streaming.




If the lock is lost, then normally you loose video as well. If not, then
applications are not interested in the event.


Yes, the lost lock causes a temporary or permanent loss of video,
but with no other indications from the adv7180 (such as a detected
video standard change). And on i.mx6, the lost lock often (actually
usually) causes a split or rolling image.



Also it seems the sequence of actions from the application due to a
SRC_CH_LOCK_STATUS event would be in line with the action due to
SRC_CH_RESOLUTION. In other words for SRC_CH_RESOLUTION,
the app requests an update on the detected video standard via
QUERYSTD, and for SRC_CH_LOCK_STATUS, it requests an update
on input status (ENUMINPUTS).

Steve

--
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 v4 7/8] v4l: Add signal lock status to source change events

[Steve Longerbeam]

On 11/14/2016 03:36 AM, Hans Verkuil wrote:

On 08/03/2016 08:03 PM, Steve Longerbeam wrote:

Add a signal lock status change to the source changes bitmask.
This indicates there was a signal lock or unlock event detected
at the input of a video decoder.

Signed-off-by: Steve Longerbeam 
Cc: Mauro Carvalho Chehab 

---

v4:
- converted to rst from DocBook

v3: no changes
v2: no changes
---
  Documentation/media/uapi/v4l/vidioc-dqevent.rst | 9 +
  Documentation/media/videodev2.h.rst.exceptions  | 1 +
  include/uapi/linux/videodev2.h  | 1 +
  3 files changed, 11 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index 73c0d5b..7d8a053 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -564,6 +564,15 @@ call.
  an input. This can come from an input connector or from a video
  decoder.
  
+-  .. row 2

+
+   -  ``V4L2_EVENT_SRC_CH_LOCK_STATUS``
+
+   -  0x0002
+
+   -  This event gets triggered when there is a signal lock or
+ unlock detected at the input of a video decoder.
+
  
  Return Value

  
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index 9bb9a6c..f412cc8 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -453,6 +453,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS ctrl-changes-flags
  replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
  
  replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags

+replace define V4L2_EVENT_SRC_CH_LOCK_STATUS src-changes-flags
  
  replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ v4l2-event-motion-det
  
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h

index 724f43e..08a153f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2078,6 +2078,7 @@ struct v4l2_event_frame_sync {
  };
  
  #define V4L2_EVENT_SRC_CH_RESOLUTION		(1 << 0)

+#define V4L2_EVENT_SRC_CH_LOCK_STATUS  (1 << 1)
  
  struct v4l2_event_src_change {

__u32 changes;


Quoting from an old (July) conversation about this:


I'm not entirely sure I like this. Typically losing lock means that this event
is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and userspace has
to check the new timings etc., which will fail if there is no lock anymore.

This information is also available through ENUMINPUT.

I would need to know more about why you think this is needed, because I don't
see what this adds.

Hi Hans,

At least on the ADV718x, a source resolution change (from an
autodetected video
standard change) and a signal lock status change are distinct events.
For example
there can be a temporary loss of input signal lock without a change in
detected
input video standard/resolution.

OK, but what can the application do with that event? If the glitch didn't
affect the video, then it is pointless.


Hi Hans, that's just it, for i.mx6 it does affect video. On i.mx6 a 
temporary

loss of signal from the adv7180 often results in a "split image", or rolling
image from captured frame to the next, and the only way to recover
from this failure is to restart the pipeline (stream off -- stream on). So
the application needs to be informed of this temporary loss of signal
event in order to restart streaming.




If the lock is lost, then normally you loose video as well. If not, then
applications are not interested in the event.


Yes, the lost lock causes a temporary or permanent loss of video,
but with no other indications from the adv7180 (such as a detected
video standard change). And on i.mx6, the lost lock often (actually
usually) causes a split or rolling image.

Steve

--
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] Add basic support for DW CSI-2 Host IPK

[kbuild test robot]

Hi Ramiro,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9-rc5 next-20161114]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ramiro-Oliveira/Add-support-for-the-DW-IP-Prototyping-Kits-for-MIPI-CSI-2-Host/20161115-014759
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/platform/dwc/dw_mipi_csi.c: In function 'mipi_csi_probe':
>> drivers/media/platform/dwc/dw_mipi_csi.c:597:8: error: implicit declaration 
>> of function 'devm_request_irq' [-Werror=implicit-function-declaration]
 ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
   ^~~~
>> drivers/media/platform/dwc/dw_mipi_csi.c:598:29: error: 'IRQF_SHARED' 
>> undeclared (first use in this function)
  dw_mipi_csi_irq1, IRQF_SHARED,
^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:598:29: note: each undeclared 
identifier is reported only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/devm_request_irq +597 drivers/media/platform/dwc/dw_mipi_csi.c

   591  mipi_csi->ctrl_irq_number = platform_get_irq(pdev, 0);
   592  if (mipi_csi->ctrl_irq_number <= 0) {
   593  dev_err(dev, "IRQ number not set.\n");
   594  return mipi_csi->ctrl_irq_number;
   595  }
   596  
 > 597  ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
 > 598 dw_mipi_csi_irq1, IRQF_SHARED,
   599 dev_name(dev), mipi_csi);
   600  if (ret) {
   601  dev_err(dev, "IRQ failed\n");

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/2] Add basic support for DW CSI-2 Host IPK

[kbuild test robot]

Hi Ramiro,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.9-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ramiro-Oliveira/Add-support-for-the-DW-IP-Prototyping-Kits-for-MIPI-CSI-2-Host/20161115-014759
base:   git://linuxtv.org/media_tree.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/dwc/dw_mipi_csi.h:12,
from drivers/media/platform/dwc/dw_mipi_csi.c:14:
   drivers/media/platform/dwc/dw_mipi_csi.c: In function 'dw_mipi_csi_irq1':
>> drivers/media/platform/dwc/dw_mipi_csi.c:437:9: warning: cast from pointer 
>> to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
   include/linux/printk.h:398:17: note: in definition of macro 
'printk_ratelimited'
  printk(fmt, ##__VA_ARGS__);\
^~~
>> drivers/media/platform/dwc/dw_mipi_csi.c:436:3: note: in expansion of macro 
>> 'pr_info_ratelimited'
  pr_info_ratelimited("%08X CSI INT PHY FATAL: %08X\n",
  ^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:443:9: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
   include/linux/printk.h:398:17: note: in definition of macro 
'printk_ratelimited'
  printk(fmt, ##__VA_ARGS__);\
^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:442:3: note: in expansion of macro 
'pr_info_ratelimited'
  pr_info_ratelimited("%08X CSI INT PKT FATAL: %08X\n",
  ^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:449:9: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
   include/linux/printk.h:398:17: note: in definition of macro 
'printk_ratelimited'
  printk(fmt, ##__VA_ARGS__);\
^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:448:3: note: in expansion of macro 
'pr_info_ratelimited'
  pr_info_ratelimited("%08X CSI INT FRAME FATAL: %08X\n",
  ^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:455:9: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
   include/linux/printk.h:398:17: note: in definition of macro 
'printk_ratelimited'
  printk(fmt, ##__VA_ARGS__);\
^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:454:3: note: in expansion of macro 
'pr_info_ratelimited'
  pr_info_ratelimited("%08X CSI INT PHY: %08X\n",
  ^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:461:9: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
   include/linux/printk.h:398:17: note: in definition of macro 
'printk_ratelimited'
  printk(fmt, ##__VA_ARGS__);\
^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:460:3: note: in expansion of macro 
'pr_info_ratelimited'
  pr_info_ratelimited("%08X CSI INT PKT: %08X\n",
  ^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:467:9: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
   include/linux/printk.h:398:17: note: in definition of macro 
'printk_ratelimited'
  printk(fmt, ##__VA_ARGS__);\
^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:466:3: note: in expansion of macro 
'pr_info_ratelimited'
  pr_info_ratelimited("%08X CSI INT LINE: %08X\n",
  ^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:473:9: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
   include/linux/printk.h:398:17: note: in definition of macro 
'printk_ratelimited'
  printk(fmt, ##__VA_ARGS__);\
^~~
   drivers/media/platform/dwc/dw_mipi_csi.c:472:3: note: in expansion of macro 
'pr_info_ratelimited'
  pr_info_ratelimited("%08X CSI INT IPI: %08X\n",
  ^~~

vim +437 drivers/media/platform/dwc/dw_mipi_csi.c

   

Re: [PATCH v6] media: et8ek8: add device tree binding documentation

[Rob Herring]

On Mon, Nov 14, 2016 at 12:30 PM, Pavel Machek  wrote:
> Add device tree binding documentation for toshiba et8ek8 sensor.
>
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 

Acked-by: Rob Herring 
--
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] media: et8ek8: add device tree binding documentation

[Pavel Machek]

Add device tree binding documentation for toshiba et8ek8 sensor.

Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 

---

v6: added missing article, fixed signal polarity.

diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt 
b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
new file mode 100644
index 000..b03b21d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
@@ -0,0 +1,53 @@
+Toshiba et8ek8 5MP sensor
+
+Toshiba et8ek8 5MP sensor is an image sensor found in Nokia N900 device
+
+More detailed documentation can be found in
+Documentation/devicetree/bindings/media/video-interfaces.txt .
+
+
+Mandatory properties
+
+
+- compatible: "toshiba,et8ek8"
+- reg: I2C address (0x3e, or an alternative address)
+- vana-supply: Analogue voltage supply (VANA), 2.8 volts
+- clocks: External clock to the sensor
+- clock-frequency: Frequency of the external clock to the sensor. Camera
+  driver will set this frequency on the external clock. The clock frequency is
+  a pre-determined frequency known to be suitable to the board.
+- reset-gpios: XSHUTDOWN GPIO. The XSHUTDOWN signal is active low. The sensor
+  is in hardware standby mode when the signal is in the low state.
+
+
+Endpoint node mandatory properties
+--
+
+- remote-endpoint: A phandle to the bus receiver's endpoint node.
+
+Endpoint node optional properties
+--
+
+- clock-lanes: <0>
+- data-lanes: <1..n>
+
+Example
+---
+
+ {
+   clock-frequency = <40>;
+
+   cam1: camera@3e {
+   compatible = "toshiba,et8ek8";
+   reg = <0x3e>;
+   vana-supply = <>;
+   clocks = < 0>;
+   clock-frequency = <960>;
+   reset-gpio = < 6 GPIO_ACTIVE_HIGH>; /* 102 */
+   port {
+   csi_cam1: endpoint {
+   remote-endpoint = <_out1>;
+   };
+   };
+   };
+};

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v4 3/8] media: adv7180: add support for NEWAVMODE

[Steve Longerbeam]

On 11/14/2016 03:28 AM, Hans Verkuil wrote:

On 08/03/2016 08:03 PM, Steve Longerbeam wrote:

Parse the optional v4l2 endpoint DT node. If the bus type is
V4L2_MBUS_BT656 and the endpoint node specifies "newavmode",
configure the BT.656 bus in NEWAVMODE.

Signed-off-by: Steve Longerbeam 

---

v4: no changes
v3:
- the newavmode endpoint property is now private to adv7180.
---
  .../devicetree/bindings/media/i2c/adv7180.txt  |  4 ++
  drivers/media/i2c/adv7180.c| 46 --
  2 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
index 0d50115..6c175d2 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
@@ -15,6 +15,10 @@ Required Properties :
"adi,adv7282"
"adi,adv7282-m"
  
+Optional Endpoint Properties :

+- newavmode: a boolean property to indicate the BT.656 bus is operating
+  in Analog Device's NEWAVMODE. Valid for BT.656 busses only.

This is too vague.

Based on the ADV7280/ADV7281/ADV7282/ADV7283 Hardware Reference Manual I
would say something like this:

- newavmode: a boolean property to indicate the BT.656 bus is operating
   in Analog Device's NEWAVMODE. Valid for BT.656 busses only. When enabled
   the generated EAV/SAV codes are suitable for Analog Devices encoders.
   Otherwise these codes are setup according to 
   See bit 4 of user sub map register 0x31 in the Hardware Reference Manual.

I may have asked this before, but do you actually have hardware that needs
this? If so, it may be useful to give it as an example and explain why it
is needed.

If not, then I wonder if this cannot be dropped until we DO see hardware
that needs it.


Hi Hans, thanks for reviewing this, but at least for imx6, I don't
need this patch anymore.

Recently I dug deeper into the current bt.656 programming in
adv7180.c. The driver manually configures the bus to have 21
blank lines in odd fields, and 22 blank lines in even fields (via
NVEND register) for NTSC.

That leaves 525 - (21 +22) = 482 active lines in NTSC.

After configuring the imx6 host bridge to crop those extra 2 lines,
it is capturing good 720x480 NTSC images now.

So I no longer need this patch to enable NEWAVMODE.

However I still see some issues.

First, adv7180.c attempts to enable  BT.656-4 mode, but according
to the datasheet, that cannot be enabled without first enabling
NEWAVMODE. So the attempt to enable BT.656-4 mode is a no-op,
it is currently doing nothing. So I suggest removing that attempt.

Second, it is wrong for the host bridge to have to make an assumption
about cropping for a sensor. The adv7180 needs to communicate to
hosts about the number of field blanking lines it has configured, maybe
via get_selection. I.e., report full sensor frame via get_fmt, and 720x482
via get_selection.


Steve

--
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] Samsung SoC driver updates for 4.10

[Sylwester Nawrocki]

Hi Mauro,

This includes mostly clean up and fixes of the s5p-mfc and exynos-gsc
drivers. Support for the Exynos5433 (64-bit ARM) SoC is added to the
exynos-gsc driver.

The following changes since commit 669c6141ea78dff885b5bf025456c7dffb669a61:

  [media] mtk-mdp: fix double mutex_unlock (2016-10-21 12:09:53 -0200)

are available in the git repository at:

  git://linuxtv.org/snawrocki/samsung.git for-v4.10/media/next

for you to fetch changes up to 37269235bfaab6ad0b801190dc8a8c7397476b5b:

  s5p-mfc: Fix clock management in s5p_mfc_release() function (2016-11-14 
16:04:15 +0100)


Andrzej Hajda (1):
  s5p-mfc: Correct scratch buffer size of H.263 decoder

Donghwa Lee (1):
  s5p-mfc: Skip incomplete frame

Ingi Kim (1):
  s5p-mfc: Fix MFC context buffer size

Javier Martinez Canillas (7):
  exynos-gsc: change spamming try_fmt log message to debug
  exynos-gsc: don't clear format when freeing buffers with REQBUFS(0)
  exynos-gsc: fix supported RGB pixel format
  exynos-gsc: do proper bytesperline and sizeimage calculation
  exynos-gsc: don't release a non-dynamically allocated video_device
  exynos-gsc: unregister video device node on driver removal
  exynos-gsc: cleanup m2m src and dst vb2 queues on STREAMOFF

Marek Szyprowski (8):
  exynos-gsc: Simplify system PM even more
  exynos-gsc: Remove unused lclk_freqency entry
  exynos-gsc: Add missing newline char in debug messages
  exynos-gsc: Use of_device_get_match_data() helper
  exynos-gsc: Enable driver on ARCH_EXYNOS
  exynos-gsc: Add support for Exynos5433 specific version
  s5p-mfc: Use clock gating only on MFC v5 hardware
  s5p-mfc: Fix clock management in s5p_mfc_release() function

Nicolas Dufresne (1):
  exynos4-is: fimc: Roundup imagesize to row size for tiled formats

Shuah Khan (2):
  s5p-mfc: Collapse two error message into one
  s5p-mfc: include buffer size in error message

Ulf Hansson (7):
  exynos-gsc: Simplify clock management
  exynos-gsc: Convert gsc_m2m_resume() from int to void
  exynos-gsc: Make driver functional when CONFIG_PM is unset
  exynos-gsc: Make PM callbacks available conditionally
  exynos-gsc: Fixup clock management at ->remove()
  exynos-gsc: Do full clock gating at runtime PM suspend
  exynos-gsc: Simplify system PM

 .../bindings/media/exynos5-gsc.txt   |   3 +-
 drivers/media/platform/Kconfig   |   2 +-
 .../media/platform/exynos-gsc/gsc-core.c | 279 +++
 .../media/platform/exynos-gsc/gsc-core.h |  11 +-
 .../media/platform/exynos-gsc/gsc-m2m.c  |  38 +-
 .../platform/exynos4-is/fimc-core.c  |  13 +-
 .../media/platform/s5p-mfc/regs-mfc-v6.h |   3 +-
 .../media/platform/s5p-mfc/regs-mfc-v8.h |   2 +-
 .../media/platform/s5p-mfc/regs-mfc.h|   3 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c |  15 +-
 .../platform/s5p-mfc/s5p_mfc_common.h|   2 +
 .../media/platform/s5p-mfc/s5p_mfc_opr.c |   6 +-
 .../media/platform/s5p-mfc/s5p_mfc_pm.c  |  17 +-
 13 files changed, 209 insertions(+), 185 deletions(-)

-- 
Thanks,
Sylwester
--
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 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rob Herring]

On Tue, Nov 08, 2016 at 02:34:38PM +0800, Rick Chang wrote:
> Add a DT binding documentation for Mediatek JPEG Decoder of
> MT2701 SoC.
> 
> Signed-off-by: Rick Chang 
> Signed-off-by: Minghsiu Tsai 
> ---
>  .../bindings/media/mediatek-jpeg-decoder.txt   | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt

Acked-by: Rob Herring 
--
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 v3 1/9] doc: DT: vidc: binding document for Qualcomm video driver

[Rob Herring]

On Mon, Nov 07, 2016 at 07:33:55PM +0200, Stanimir Varbanov wrote:
> Add binding document for Venus video encoder/decoder driver
> 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Stanimir Varbanov 
> ---
>  .../devicetree/bindings/media/qcom,venus.txt   | 98 
> ++
>  1 file changed, 98 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
> b/Documentation/devicetree/bindings/media/qcom,venus.txt
> new file mode 100644
> index ..b2af347fbce4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> @@ -0,0 +1,98 @@
> +* Qualcomm Venus video encode/decode accelerator
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: Value should contain one of:
> + - "qcom,venus-msm8916"
> + - "qcom,venus-msm8996"

The normal ordering is ,-

> +- reg:
> + Usage: required
> + Value type: 
> + Definition: Register ranges as listed in the reg-names property.
> +- reg-names:
> + Usage: required
> + Value type: 
> + Definition: Should contain following entries:
> + - "venus"   Venus register base
> +- reg-names:

I'd prefer these grouped as one entry for reg-names.

> + Usage: optional for msm8996

Why optional?

> + Value type: 
> + Definition: Should contain following entries:
> + - "vmem"Video memory register base
> +- interrupts:
> + Usage: required
> + Value type: 
> + Definition: Should contain interrupts as listed in the interrupt-names
> + property.
> +- interrupt-names:
> + Usage: required
> + Value type: 
> + Definition: Should contain following entries:
> + - "venus"   Venus interrupt line
> +- interrupt-names:
> + Usage: optional for msm8996
> + Value type: 
> + Definition: Should contain following entries:
> + - "vmem"Video memory interrupt line
> +- clocks:
> + Usage: required
> + Value type: 
> + Definition: A List of phandle and clock specifier pairs as listed
> + in clock-names property.
> +- clock-names:
> + Usage: required
> + Value type: 
> + Definition: Should contain the following entries:
> + - "core"Core video accelerator clock
> + - "iface"   Video accelerator AHB clock
> + - "bus" Video accelerator AXI clock
> +- clock-names:
> + Usage: required for msm8996

Plus the 3 above?

> + Value type: 
> + Definition: Should contain the following entries:
> + - "subcore0"Subcore0 video accelerator clock
> + - "subcore1"Subcore1 video accelerator clock
> + - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
> + - "mmss_mmagic_iface"   Multimedia subsystem MMAGIC AHB clock
> + - "mmss_mmagic_mbus"Multimedia subsystem MMAGIC MAXI clock
> + - "mmagic_video_bus"MMAGIC video AXI clock
> + - "video_mbus"  Video MAXI clock
> +- clock-names:
> + Usage: optional for msm8996

Clocks shouldn't be optional unless you failed to add in an initial 
binding.

> + Value type: 
> + Definition: Should contain the following entries:
> + - "vmem_bus"Video memory MAXI clock
> + - "vmem_iface"  Video memory AHB clock
> +- power-domains:
> + Usage: required
> + Value type: 
> + Definition: A phandle and power domain specifier pairs to the
> + power domain which is responsible for collapsing
> + and restoring power to the peripheral.
> +- rproc:
> + Usage: required
> + Value type: 
> + Definition: A phandle to remote processor responsible for
> + firmware loading and processor booting.
> +
> +- iommus:
> + Usage: required
> + Value type: 
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +* An Example
> + video-codec@1d0 {
> + compatible = "qcom,venus-msm8916";
> + reg = <0x01d0 0xff000>;
> + reg-names = "venus";
> + interrupts = ;
> + interrupt-names = "venus";
> + clocks = < GCC_VENUS0_VCODEC0_CLK>,
> +  < GCC_VENUS0_AHB_CLK>,
> +  < GCC_VENUS0_AXI_CLK>;
> + clock-names = "core", "iface", "bus";
> + power-domains = < VENUS_GDSC>;
> + rproc = <_rproc>;
> + iommus = <_iommu 5>;
> + };
> -- 
> 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 3/5] media: Add new SDR formats SC16, SC18 & SC20

[Hans Verkuil]

On 11/14/2016 05:20 PM, Ramesh Shanmugasundaram wrote:
> Hi Hans,
> 
> Thanks for the review comments.
> 
>> Subject: Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20
>>
>> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
>>> This patch adds support for the three new SDR formats. These formats
>>> were prefixed with "sliced" indicating I data constitutes the top half
>>> and Q data constitutes the bottom half of the received buffer.
>>
>> The standard terminology for video formats is "planar". I am leaning
>> towards using that here as well.
>>
>> Any opinions on this?
> 
> Shall I rename the formats as "PC16", "PC18" & "PC20"?

Sounds reasonable to me!

Hans

> For formats that do IQ IQ IQ... I shall use the regular formats "CUXX" when I 
> introduce them.
> 
> Thanks,
> Ramesh
> 
>>
>>  Hans
>>
>>>
>>> V4L2_SDR_FMT_SCU16BE - 14-bit complex (I & Q) unsigned big-endian
>>> sample inside 16-bit. V4L2 FourCC: SC16
>>>
>>> V4L2_SDR_FMT_SCU18BE - 16-bit complex (I & Q) unsigned big-endian
>>> sample inside 18-bit. V4L2 FourCC: SC18
>>>
>>> V4L2_SDR_FMT_SCU20BE - 18-bit complex (I & Q) unsigned big-endian
>>> sample inside 20-bit. V4L2 FourCC: SC20
>>>
>>> Signed-off-by: Ramesh Shanmugasundaram
>>> 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
>>>  include/uapi/linux/videodev2.h   | 3 +++
>>>  2 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> index 181381d..d36b386 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -1207,6 +1207,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
>> *fmt)
>>> case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
>>> case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
>>> case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
>>> +   case V4L2_SDR_FMT_SCU16BE:  descr = "Sliced Complex U16BE"; break;
>>> +   case V4L2_SDR_FMT_SCU18BE:  descr = "Sliced Complex U18BE"; break;
>>> +   case V4L2_SDR_FMT_SCU20BE:  descr = "Sliced Complex U20BE"; break;
>>> case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
>>> case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
>>> case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data";
>> break;
>>> diff --git a/include/uapi/linux/videodev2.h
>>> b/include/uapi/linux/videodev2.h index 4364ce6..34a9c30 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -666,6 +666,9 @@ struct v4l2_pix_format {
>>>  #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /*
>> complex s8 */
>>>  #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /*
>> complex s14le */
>>>  #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /*
>> real u12le */
>>> +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
>> sliced complex u16be */
>>> +#define V4L2_SDR_FMT_SCU18BE v4l2_fourcc('S', 'C', '1', '8') /*
>> sliced complex u18be */
>>> +#define V4L2_SDR_FMT_SCU20BE v4l2_fourcc('S', 'C', '2', '0') /*
>> sliced complex u20be */
>>>
>>>  /* Touch formats - used for Touch devices */
>>>  #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 16-
>> bit signed deltas */
>>>
> --
> 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

Re: [RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

[Jose Abreu]

Hi Hans,



On 11-11-2016 14:52, Hans Verkuil wrote:
> Hi Jose,
>
> On 11/09/2016 06:43 PM, Jose Abreu wrote:
>> Hi All,
>>
>> This is a RFC patch for Synopsys Designware HDMI RX PHY e405.
>> This phy receives and decodes HDMI video that is delivered to
>> a controller. The controller bit is not yet ready for submission
>> but we are planning to submit it as soon as possible.
>>
>> Main included features in this driver are:
>>  - Equalizer algorithm that chooses phy best settings
>>  according to detected HDMI cable characteristics.
>>  - Support for scrambling
>>  - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz)
>>
>> The driver was implemented as a V4L2 subdevice and the phy
>> interface with the controller was implemented using V4L2 ioctls.
>> I do not know if this is the best option but it is not possible
>> to use the existing API functions directly as we need specific
>> functions that will be called by the controller at specific
>> configuration stages. For example, we can only set scrambling
>> when the sink detects the corresponding bit set in SCDC.
>>
>> Please notice that we plan to submit more phy drivers as they
>> are released, maintaining the newly created interface
>> (dw-phy-pdata.h) and using only one controller driver.
>>
>> I realize that this code needs a lot of polishment, specially
>> the equalizer part so I would really apreciate some feedback.
>>
>> Looking forward to your comments!
> I looked it over and I didn't see anything alarming :-)
>
> But it is hard to review without seeing the controller driver as well.
> When I can see how it is used by the controller driver then I can see
> if using ioctls here makes sense or not.
>
> Typically ioctls in subdevs are used for very device-specific actions.
> But perhaps what is happening here is required for all HDMI phys, and in
> that case new subdev ops could be added instead.
>
> Or we start with ioctls and later convert it to ops when it is clear that
> other phys need to do the same.
>
> Anyway, I think I'll have to wait until the controller is posted before I
> can do a proper review.
>
> Regards,
>
>   Hans

Thanks for your answer! I am not sure about other controllers
phys but ours needs a special configuration when in HDMI 2.0
modes (like 4k@60Hz) and also a special bit set when in
scrambling mode so that the equalizing algorithm stabilizes
faster. Besides this it needs configuration parameters, that in
this case are passed by platform data.

I will then wait until I have the controller driver ready and
send a RFC with these two blocks.

Best regards,
Jose Miguel Abreu


>> Best regards,
>> Jose Miguel Abreu
>>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: Mauro Carvalho Chehab 
>> Cc: linux-ker...@vger.kernel.org
>> Cc: linux-media@vger.kernel.org
>> ---
>>  drivers/media/platform/Kconfig   |   1 +
>>  drivers/media/platform/Makefile  |   2 +
>>  drivers/media/platform/dw/Kconfig|   8 +
>>  drivers/media/platform/dw/Makefile   |   3 +
>>  drivers/media/platform/dw/dw-phy-e405.c  | 732 
>> +++
>>  drivers/media/platform/dw/dw-phy-e405.h  |  48 ++
>>  drivers/media/platform/dw/dw-phy-pdata.h |  47 ++
>>  7 files changed, 841 insertions(+)
>>  create mode 100644 drivers/media/platform/dw/Kconfig
>>  create mode 100644 drivers/media/platform/dw/Makefile
>>  create mode 100644 drivers/media/platform/dw/dw-phy-e405.c
>>  create mode 100644 drivers/media/platform/dw/dw-phy-e405.h
>>  create mode 100644 drivers/media/platform/dw/dw-phy-pdata.h
>>
>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>> index 754edbf1..9e8e67f 100644
>> --- a/drivers/media/platform/Kconfig
>> +++ b/drivers/media/platform/Kconfig
>> @@ -120,6 +120,7 @@ source "drivers/media/platform/am437x/Kconfig"
>>  source "drivers/media/platform/xilinx/Kconfig"
>>  source "drivers/media/platform/rcar-vin/Kconfig"
>>  source "drivers/media/platform/atmel/Kconfig"
>> +source "drivers/media/platform/dw/Kconfig"
>>  
>>  config VIDEO_TI_CAL
>>  tristate "TI CAL (Camera Adaptation Layer) driver"
>> diff --git a/drivers/media/platform/Makefile 
>> b/drivers/media/platform/Makefile
>> index f842933..fb2cf01 100644
>> --- a/drivers/media/platform/Makefile
>> +++ b/drivers/media/platform/Makefile
>> @@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
>>  obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec/
>>  
>>  obj-$(CONFIG_VIDEO_MEDIATEK_MDP)+= mtk-mdp/
>> +
>> +obj-y += dw/
>> diff --git a/drivers/media/platform/dw/Kconfig 
>> b/drivers/media/platform/dw/Kconfig
>> new file mode 100644
>> index 000..b3d7044
>> --- /dev/null
>> +++ b/drivers/media/platform/dw/Kconfig
>> @@ -0,0 +1,8 @@
>> +config VIDEO_DW_PHY_E405
>> +tristate "Synopsys Designware HDMI RX PHY e405 driver"
>> +depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>> +help
>> +   Support for 

Re: [PATCH v5] media: et8ek8: add device tree binding documentation

[Rob Herring]

On Mon, Nov 07, 2016 at 11:46:48AM +0100, Pavel Machek wrote:
> Add device tree binding documentation for toshiba et8ek8 sensor.
> 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt 
> b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
> new file mode 100644
> index 000..b03b21d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
> @@ -0,0 +1,53 @@
> +Toshiba et8ek8 5MP sensor
> +
> +Toshiba et8ek8 5MP sensor is an image sensor found in Nokia N900 device
> +
> +More detailed documentation can be found in
> +Documentation/devicetree/bindings/media/video-interfaces.txt .
> +
> +
> +Mandatory properties
> +
> +
> +- compatible: "toshiba,et8ek8"
> +- reg: I2C address (0x3e, or an alternative address)
> +- vana-supply: Analogue voltage supply (VANA), 2.8 volts
> +- clocks: External clock to the sensor
> +- clock-frequency: Frequency of the external clock to the sensor. Camera
> +  driver will set this frequency on the external clock. The clock frequency 
> is
> +  a pre-determined frequency known to be suitable to the board.
> +- reset-gpios: XSHUTDOWN GPIO. The XSHUTDOWN signal is active high. The 
> sensor
> +  is in hardware standby mode when the signal is in low state.

Sounds like active low to me. "Active" means when is the defined 
function of the pin enabled, not when is the chip active/enabled. So in 
this case reset or shutdown is active when low.

Rob
--
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/5] media: Add new SDR formats SC16, SC18 & SC20

[Ramesh Shanmugasundaram]

Hi Hans,

Thanks for the review comments.

> Subject: Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20
> 
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds support for the three new SDR formats. These formats
> > were prefixed with "sliced" indicating I data constitutes the top half
> > and Q data constitutes the bottom half of the received buffer.
> 
> The standard terminology for video formats is "planar". I am leaning
> towards using that here as well.
> 
> Any opinions on this?

Shall I rename the formats as "PC16", "PC18" & "PC20"?
For formats that do IQ IQ IQ... I shall use the regular formats "CUXX" when I 
introduce them.

Thanks,
Ramesh

> 
>   Hans
> 
> >
> > V4L2_SDR_FMT_SCU16BE - 14-bit complex (I & Q) unsigned big-endian
> > sample inside 16-bit. V4L2 FourCC: SC16
> >
> > V4L2_SDR_FMT_SCU18BE - 16-bit complex (I & Q) unsigned big-endian
> > sample inside 18-bit. V4L2 FourCC: SC18
> >
> > V4L2_SDR_FMT_SCU20BE - 18-bit complex (I & Q) unsigned big-endian
> > sample inside 20-bit. V4L2 FourCC: SC20
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
> >  include/uapi/linux/videodev2.h   | 3 +++
> >  2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 181381d..d36b386 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1207,6 +1207,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> *fmt)
> > case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
> > case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
> > case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
> > +   case V4L2_SDR_FMT_SCU16BE:  descr = "Sliced Complex U16BE"; break;
> > +   case V4L2_SDR_FMT_SCU18BE:  descr = "Sliced Complex U18BE"; break;
> > +   case V4L2_SDR_FMT_SCU20BE:  descr = "Sliced Complex U20BE"; break;
> > case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
> > case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
> > case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data";
> break;
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h index 4364ce6..34a9c30 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -666,6 +666,9 @@ struct v4l2_pix_format {
> >  #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /*
> complex s8 */
> >  #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /*
> complex s14le */
> >  #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /*
> real u12le */
> > +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
> sliced complex u16be */
> > +#define V4L2_SDR_FMT_SCU18BE v4l2_fourcc('S', 'C', '1', '8') /*
> sliced complex u18be */
> > +#define V4L2_SDR_FMT_SCU20BE v4l2_fourcc('S', 'C', '2', '0') /*
> sliced complex u20be */
> >
> >  /* Touch formats - used for Touch devices */
> >  #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 16-
> bit signed deltas */
> >
--
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 5/5] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

Hi Hans,

Thanks for the review comments.

> Subject: Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
> 
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and
> > the tuner device, which is registered as a sub-device, determines the
> > receive sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF
> > acts as a slave device and the tuner device acts as a master
> > transmitting the samples. The driver allows asynchronous binding of a
> > tuner device that is registered as a v4l2 sub-device. The driver can
> > learn about the tuner it is interfaced with based on port endpoint
> > properties of the device in device tree. The V4L2 SDR device inherits
> > the controls exposed by the tuner device.
> >
> > The device can also be configured to use either one or both of the
> > data pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> >  .../devicetree/bindings/media/renesas,drif.txt |  136 ++
> >  drivers/media/platform/Kconfig |   25 +
> >  drivers/media/platform/Makefile|1 +
> >  drivers/media/platform/rcar_drif.c | 1574
> 
> >  4 files changed, 1736 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/renesas,drif.txt
> >  create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > new file mode 100644
> > index 000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++-++-+
> > +| |-SCK--->|CLK  |
> > +|   Master|-SS>|SYNC  DRIFn (slave)  |
> > +| |-SD0--->|D0   |
> > +| |-SD1--->|D1   |
> > ++-++-+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 &
> drifn1).
> > +The sub-channels are like two individual channels in itself that
> > +share the common CLK & SYNC. Each sub-channel has it's own dedicated
> > +resources like irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's
> > +sub-channel as a separate node. The parent channel ties the
> > +sub-channels together with their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +-
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +-
> > +- port: child port node of a channel that defines the local and remote
> > +endpoints. The remote endpoint is assumed to be a tuner
> subdevice
> > +   endpoint.
> > +- renesas,syncmd   : sync mode
> > +0 (Frame start sync pulse mode. 1-bit width pulse
> > + 

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Rob Herring]

On Thu, Nov 10, 2016 at 4:02 AM, Andi Shyti  wrote:
> Hi Jacek,
>
>> > > > > Only DT bindings of LED class drivers should be placed in
>> > > > > Documentation/devicetree/bindings/leds. Please move it to the
>> > > > > media bindings.
>> > > >
>> > > > that's where I placed it first, but Rob asked me to put it in the
>> > > > LED directory and Cc the LED mailining list.
>> > > >
>> > > > That's the discussion of the version 2:
>> > > >
>> > > > https://lkml.org/lkml/2016/9/12/380
>> > > >
>> > > > Rob, Jacek, could you please agree where I can put the binding?
>> > >
>> > > I'm not sure if this is a good approach. I've noticed also that
>> > > backlight bindings have been moved to leds, whereas they don't look
>> > > similarly.
>> > >
>> > > We have common.txt LED bindings, that all LED class drivers' bindings
>> > > have to follow. Neither backlight bindings nor these ones do that,
>> > > which introduces some mess.
>> >
>> > And there are probably LED bindings that don't follow common.txt either.
>> >
>> > > Eventually adding a sub-directory, e.g. remote_control could make it
>> > > somehow logically justified, but still - shouldn't bindings be
>> > > placed in the documentation directory related to the subsystem of the
>> > > driver they are predestined to?
>> >
>> > No. While binding directories often mirror the driver directories, they
>> > are not the same. Bindings are grouped by types of h/w and IR LEDs are a
>> > type of LED.
>> >
>> > If you prefer a sub-dir, that is fine with me.
>>
>> Fine. So how about sub-dir "ir" ?
>
> would we put here all the remote control bindings that currently
> are under media?

No. Only if they are just an LED that happens to be IR.

Rob
--
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/5] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

Hi Hans,

Thank you for the review comments.

> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds driver support for MAX2175 chip. This is Maxim
> > Integrated's RF to Bits tuner front end chip designed for
> > software-defined radio solutions. This driver exposes the tuner as a
> > sub-device instance with standard and custom controls to configure the
> device.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> >  .../devicetree/bindings/media/i2c/max2175.txt  |   61 +
> >  drivers/media/i2c/Kconfig  |4 +
> >  drivers/media/i2c/Makefile |2 +
> >  drivers/media/i2c/max2175/Kconfig  |8 +
> >  drivers/media/i2c/max2175/Makefile |4 +
> >  drivers/media/i2c/max2175/max2175.c| 1558
> 
> >  drivers/media/i2c/max2175/max2175.h|  108 ++
> >  7 files changed, 1745 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/i2c/max2175.txt
> >  create mode 100644 drivers/media/i2c/max2175/Kconfig  create mode
> > 100644 drivers/media/i2c/max2175/Makefile
> >  create mode 100644 drivers/media/i2c/max2175/max2175.c
> >  create mode 100644 drivers/media/i2c/max2175/max2175.h
> >
> 
> 
> 
> > diff --git a/drivers/media/i2c/max2175/max2175.c
> > b/drivers/media/i2c/max2175/max2175.c
> > new file mode 100644
> > index 000..ec45b52
> > --- /dev/null
> > +++ b/drivers/media/i2c/max2175/max2175.c
> > @@ -0,0 +1,1558 @@
> 
> 
> 
> > +/* Read/Write bit(s) on top of regmap */ static int
> > +max2175_read(struct max2175 *ctx, u8 idx, u8 *val) {
> > +   u32 regval;
> > +   int ret = regmap_read(ctx->regmap, idx, );
> > +
> > +   if (ret)
> > +   v4l2_err(ctx->client, "read ret(%d): idx 0x%02x\n", ret, idx);
> > +
> > +   *val = regval;
> 
> Does regmap_read initialize regval even if it returns an error? If not,
> then I would initialize regval to 0 to prevent *val being uninitialized.

Agreed.

> 
> > +   return ret;
> > +}
> > +
> > +static int max2175_write(struct max2175 *ctx, u8 idx, u8 val) {
> > +   int ret = regmap_write(ctx->regmap, idx, val);
> > +
> > +   if (ret)
> > +   v4l2_err(ctx->client, "write ret(%d): idx 0x%02x val
> 0x%02x\n",
> > +ret, idx, val);
> > +   return ret;
> > +}
> > +
> > +static u8 max2175_read_bits(struct max2175 *ctx, u8 idx, u8 msb, u8
> > +lsb) {
> > +   u8 val;
> > +
> > +   if (max2175_read(ctx, idx, ))
> > +   return 0;
> > +
> > +   return max2175_get_bitval(val, msb, lsb); }
> > +
> > +static bool max2175_read_bit(struct max2175 *ctx, u8 idx, u8 bit) {
> > +   return !!max2175_read_bits(ctx, idx, bit, bit); }
> > +
> > +static int max2175_write_bits(struct max2175 *ctx, u8 idx,
> > +u8 msb, u8 lsb, u8 newval)
> > +{
> > +   int ret = regmap_update_bits(ctx->regmap, idx, GENMASK(msb, lsb),
> > +newval << lsb);
> > +
> > +   if (ret)
> > +   v4l2_err(ctx->client, "wbits ret(%d): idx 0x%02x\n", ret,
> idx);
> > +
> > +   return ret;
> > +}
> > +
> > +static int max2175_write_bit(struct max2175 *ctx, u8 idx, u8 bit, u8
> > +newval) {
> > +   return max2175_write_bits(ctx, idx, bit, bit, newval); }
> > +
> > +/* Checks expected pattern every msec until timeout */ static int
> > +max2175_poll_timeout(struct max2175 *ctx, u8 idx, u8 msb, u8 lsb,
> > +   u8 exp_bitval, u32 timeout_ms)
> > +{
> > +   unsigned int val;
> > +
> > +   return regmap_read_poll_timeout(ctx->regmap, idx, val,
> > +   (max2175_get_bitval(val, msb, lsb) == exp_bitval),
> > +   1000, timeout_ms * 1000);
> > +}
> > +
> > +static int max2175_poll_csm_ready(struct max2175 *ctx) {
> > +   int ret;
> > +
> > +   ret = max2175_poll_timeout(ctx, 69, 1, 1, 0, 50);
> > +   if (ret)
> > +   v4l2_err(ctx->client, "csm not ready\n");
> > +
> > +   return ret;
> > +}
> > +
> > +#define MAX2175_IS_BAND_AM(ctx)\
> > +   (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_AM)
> > +
> > +#define MAX2175_IS_BAND_VHF(ctx)   \
> > +   (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_VHF)
> > +
> > +#define MAX2175_IS_FM_MODE(ctx)\
> > +   (max2175_read_bits(ctx, 12, 5, 4) == 0)
> > +
> > +#define MAX2175_IS_FMHD_MODE(ctx)  \
> > +   (max2175_read_bits(ctx, 12, 5, 4) == 1)
> > +
> > +#define MAX2175_IS_DAB_MODE(ctx)   \
> > +   (max2175_read_bits(ctx, 12, 5, 4) == 2)
> > +
> > +static int max2175_band_from_freq(u32 freq) {
> > +   if (freq >= 144000 && freq <= 2610)
> > +   return MAX2175_BAND_AM;
> > +   else if (freq >= 6500 && freq <= 10800)
> > +   return MAX2175_BAND_FM;
> > +   else
> 
> No need for these 'else' keywords.

Agreed.

> 
> > +   return MAX2175_BAND_VHF;
> > +}
> > +
> > +static int max2175_update_i2s_mode(struct max2175 *ctx, u32 rx_mode,
> > +   

RE: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20

[Ramesh Shanmugasundaram]

Hello Laurent, Antti, Hans,

> Subject: Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
> 
> On 11/11/2016 02:57 PM, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Friday 11 Nov 2016 14:53:58 Hans Verkuil wrote:
> >> On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
> >>> Antti, Hans, ping ? Please see below.
> >>>
> >>> On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> > On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> >> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> > On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >> This patch adds documentation for the three new SDR formats
> >>
> >> V4L2_SDR_FMT_SCU16BE
> >> V4L2_SDR_FMT_SCU18BE
> >> V4L2_SDR_FMT_SCU20BE
> >>>
> >>> [snip]
> >>>
> >> +
> >> +   -  start + 0:
> >> +
> >> +   -  I'\ :sub:`0[D13:D6]`
> >> +
> >> +   -  I'\ :sub:`0[D5:D0]`
> >> +
> >> +-  .. row 2
> >> +
> >> +   -  start + buffer_size/2:
> >> +
> >> +   -  Q'\ :sub:`0[D13:D6]`
> >> +
> >> +   -  Q'\ :sub:`0[D5:D0]`
> >
> > The format looks planar, does it use one V4L2 plane (as does
> > NV12) or two V4L2 planes (as does NV12M) ? Same question for
> > the other formats.
> 
>  Thank you for bringing up this topic. This is one of the key
>  design dilemma.
> 
>  The I & Q data for these three SDR formats comes from two
>  different DMA channels and hence two separate pointers -> we
>  could say it is
>  v4l2 multi- planar. Right now, I am making it look like a
>  single plane by presenting the data in one single buffer ptr.
> 
>  For e.g. multi-planar SC16 format would look something like
>  this
> 
>  <32bits-->
>  <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
>  + 0
>  <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
>  + 4 ...
>  <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
>  + 0
>  <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
>  + 4
> 
>  My concerns are
> 
>  1) These formats are not a standard as the video "Image Formats".
>  These formats are possible when we use DRIF + MAX2175
> combination.
>  If we interface with a different tuner vendor, the above
>  format(s) MAY/MAY NOT be re-usable. We do not know at this
>  point. This is the main open item for discussion in the cover
> letter.
> >>
> >> If the formats are really device-specific then they should be
> >> documented accordingly and not made generic.
> >>
>  2) MPLANE support within V4L2 seems specific to video. Please
>  correct me if this is wrong interpretation.
> 
>  - struct v4l2_format contains v4l2_sdr_format and
>  v4l2_pix_format_mplane as members of union. Should I create a
>  new v4l2_sdr_format_mplane? If I have to use
>  v4l2_pix_format_mplane most of the video specific members would
>  be unused (it would be similar to using v4l2_pix_format itself
> instead of v4l2_sdr_format)?
> >>
> >> I have no answer to that question as I'm not familiar with SDR.
> >> Antti, you've added v4l2_sdr_format to the API, what's your
> >> opinion ? Hans, as you've acked the patch, your input would be
> appreciated as well.
> >
> > If I understood correctly this hardware provides I and Q samples
> > via different channels and driver now combines those channels as a
> > sequential IQ sample pairs.
> 
>  The driver combines the two buffer ptrs and present as one single
> buffer.
>  For a buffer of size 200
> 
>  ptr + 0   : I I I I ... I
>  ptr + 100 : Q Q Q Q ... Q
> 
> > I have never seen any other than hw which provides IQ IQ IQ IQ ...
> IQ.
> 
>  There are some modes where this h/w combo can also do IQ IQ IQ
> pattern.
>  Those modes are not added in the RFC patchset.
> 
> > This is
> > I I I I ... I
> > Q Q Q Q ... Q
> > I am not very familiar with planars, but it sounds like it is
> > correct approach. So I think should be added rather than emulate
> > packet sequential format.
> 
>  My understanding of V4L2 MPLANE constructs is limited to a quick
>  code read only. At this point MPLANE support seems specific to
>  video. SDR is defined as separate format like v4l2_pix_format.
>  Questions would be - should we define new SDR_MPLANE? or merge SDR
>  format with pix format & reuse existing MPLANE with some SDR
>  extensions (if possible)? These seem big design decisions. 

Re: [RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

[Hans Verkuil]

You're CC-ed for all, so if you don't receive it in the next 15 minutes
let me know and I'll forward it to you. But my guess is that the mails were
delayed for some reason and that they simply haven't arrived yet.

Hans

On 11/14/2016 04:39 PM, Russell King - ARM Linux wrote:
> I can't comment on these, you've not included me in patch 1 nor the
> covering message.
> 
> On Mon, Nov 14, 2016 at 04:22:45PM +0100, Hans Verkuil wrote:
>> From: Russell King 
>>
>> We don't need the CEC engine register definitions, so let's remove them.
>>
>> Signed-off-by: Russell King 
>> ---
>>  drivers/gpu/drm/bridge/dw-hdmi.h | 45 
>> 
>>  1 file changed, 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h 
>> b/drivers/gpu/drm/bridge/dw-hdmi.h
>> index fc9a560..26d6845 100644
>> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
>> @@ -478,51 +478,6 @@
>>  #define HDMI_A_PRESETUP 0x501A
>>  #define HDMI_A_SRM_BASE 0x5020
>>  
>> -/* CEC Engine Registers */
>> -#define HDMI_CEC_CTRL   0x7D00
>> -#define HDMI_CEC_STAT   0x7D01
>> -#define HDMI_CEC_MASK   0x7D02
>> -#define HDMI_CEC_POLARITY   0x7D03
>> -#define HDMI_CEC_INT0x7D04
>> -#define HDMI_CEC_ADDR_L 0x7D05
>> -#define HDMI_CEC_ADDR_H 0x7D06
>> -#define HDMI_CEC_TX_CNT 0x7D07
>> -#define HDMI_CEC_RX_CNT 0x7D08
>> -#define HDMI_CEC_TX_DATA0   0x7D10
>> -#define HDMI_CEC_TX_DATA1   0x7D11
>> -#define HDMI_CEC_TX_DATA2   0x7D12
>> -#define HDMI_CEC_TX_DATA3   0x7D13
>> -#define HDMI_CEC_TX_DATA4   0x7D14
>> -#define HDMI_CEC_TX_DATA5   0x7D15
>> -#define HDMI_CEC_TX_DATA6   0x7D16
>> -#define HDMI_CEC_TX_DATA7   0x7D17
>> -#define HDMI_CEC_TX_DATA8   0x7D18
>> -#define HDMI_CEC_TX_DATA9   0x7D19
>> -#define HDMI_CEC_TX_DATA10  0x7D1a
>> -#define HDMI_CEC_TX_DATA11  0x7D1b
>> -#define HDMI_CEC_TX_DATA12  0x7D1c
>> -#define HDMI_CEC_TX_DATA13  0x7D1d
>> -#define HDMI_CEC_TX_DATA14  0x7D1e
>> -#define HDMI_CEC_TX_DATA15  0x7D1f
>> -#define HDMI_CEC_RX_DATA0   0x7D20
>> -#define HDMI_CEC_RX_DATA1   0x7D21
>> -#define HDMI_CEC_RX_DATA2   0x7D22
>> -#define HDMI_CEC_RX_DATA3   0x7D23
>> -#define HDMI_CEC_RX_DATA4   0x7D24
>> -#define HDMI_CEC_RX_DATA5   0x7D25
>> -#define HDMI_CEC_RX_DATA6   0x7D26
>> -#define HDMI_CEC_RX_DATA7   0x7D27
>> -#define HDMI_CEC_RX_DATA8   0x7D28
>> -#define HDMI_CEC_RX_DATA9   0x7D29
>> -#define HDMI_CEC_RX_DATA10  0x7D2a
>> -#define HDMI_CEC_RX_DATA11  0x7D2b
>> -#define HDMI_CEC_RX_DATA12  0x7D2c
>> -#define HDMI_CEC_RX_DATA13  0x7D2d
>> -#define HDMI_CEC_RX_DATA14  0x7D2e
>> -#define HDMI_CEC_RX_DATA15  0x7D2f
>> -#define HDMI_CEC_LOCK   0x7D30
>> -#define HDMI_CEC_WKUPCTRL   0x7D31
>> -
>>  /* I2C Master Registers (E-DDC) */
>>  #define HDMI_I2CM_SLAVE 0x7E00
>>  #define HDMI_I2CM_ADDRESS   0x7E01
>> -- 
>> 2.8.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
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: [RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

[Russell King - ARM Linux]

I can't comment on these, you've not included me in patch 1 nor the
covering message.

On Mon, Nov 14, 2016 at 04:22:45PM +0100, Hans Verkuil wrote:
> From: Russell King 
> 
> We don't need the CEC engine register definitions, so let's remove them.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.h | 45 
> 
>  1 file changed, 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h 
> b/drivers/gpu/drm/bridge/dw-hdmi.h
> index fc9a560..26d6845 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> @@ -478,51 +478,6 @@
>  #define HDMI_A_PRESETUP 0x501A
>  #define HDMI_A_SRM_BASE 0x5020
>  
> -/* CEC Engine Registers */
> -#define HDMI_CEC_CTRL   0x7D00
> -#define HDMI_CEC_STAT   0x7D01
> -#define HDMI_CEC_MASK   0x7D02
> -#define HDMI_CEC_POLARITY   0x7D03
> -#define HDMI_CEC_INT0x7D04
> -#define HDMI_CEC_ADDR_L 0x7D05
> -#define HDMI_CEC_ADDR_H 0x7D06
> -#define HDMI_CEC_TX_CNT 0x7D07
> -#define HDMI_CEC_RX_CNT 0x7D08
> -#define HDMI_CEC_TX_DATA0   0x7D10
> -#define HDMI_CEC_TX_DATA1   0x7D11
> -#define HDMI_CEC_TX_DATA2   0x7D12
> -#define HDMI_CEC_TX_DATA3   0x7D13
> -#define HDMI_CEC_TX_DATA4   0x7D14
> -#define HDMI_CEC_TX_DATA5   0x7D15
> -#define HDMI_CEC_TX_DATA6   0x7D16
> -#define HDMI_CEC_TX_DATA7   0x7D17
> -#define HDMI_CEC_TX_DATA8   0x7D18
> -#define HDMI_CEC_TX_DATA9   0x7D19
> -#define HDMI_CEC_TX_DATA10  0x7D1a
> -#define HDMI_CEC_TX_DATA11  0x7D1b
> -#define HDMI_CEC_TX_DATA12  0x7D1c
> -#define HDMI_CEC_TX_DATA13  0x7D1d
> -#define HDMI_CEC_TX_DATA14  0x7D1e
> -#define HDMI_CEC_TX_DATA15  0x7D1f
> -#define HDMI_CEC_RX_DATA0   0x7D20
> -#define HDMI_CEC_RX_DATA1   0x7D21
> -#define HDMI_CEC_RX_DATA2   0x7D22
> -#define HDMI_CEC_RX_DATA3   0x7D23
> -#define HDMI_CEC_RX_DATA4   0x7D24
> -#define HDMI_CEC_RX_DATA5   0x7D25
> -#define HDMI_CEC_RX_DATA6   0x7D26
> -#define HDMI_CEC_RX_DATA7   0x7D27
> -#define HDMI_CEC_RX_DATA8   0x7D28
> -#define HDMI_CEC_RX_DATA9   0x7D29
> -#define HDMI_CEC_RX_DATA10  0x7D2a
> -#define HDMI_CEC_RX_DATA11  0x7D2b
> -#define HDMI_CEC_RX_DATA12  0x7D2c
> -#define HDMI_CEC_RX_DATA13  0x7D2d
> -#define HDMI_CEC_RX_DATA14  0x7D2e
> -#define HDMI_CEC_RX_DATA15  0x7D2f
> -#define HDMI_CEC_LOCK   0x7D30
> -#define HDMI_CEC_WKUPCTRL   0x7D31
> -
>  /* I2C Master Registers (E-DDC) */
>  #define HDMI_I2CM_SLAVE 0x7E00
>  #define HDMI_I2CM_ADDRESS   0x7E01
> -- 
> 2.8.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host

[Ramiro Oliveira]

Hi Laurent,

Thanks for the feedback.

On 11/14/2016 2:49 PM, Laurent Pinchart wrote:
> Hi Ramiro,
> 
> Thank you for the patch.
> 
> On Monday 14 Nov 2016 14:20:22 Ramiro Oliveira wrote:
>> Add documentation for Media and Video Device, as well as the DW MIPI CSI-2
>> Host.
>>
>> Signed-off-by: Ramiro Oliveira 
>> ---
>>  .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 27 +++
>>  .../devicetree/bindings/media/snps,plat-ipk.txt|  9 
>>  .../bindings/media/snps,video-device.txt   | 12 ++
>>  3 files changed, 48 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt create mode
>> 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt create
>> mode 100644 Documentation/devicetree/bindings/media/snps,video-device.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>> b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt new file
>> mode 100644
>> index 000..bec7441
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>> @@ -0,0 +1,27 @@
>> +Synopsys DesignWare CSI-2 Host controller
>> +
>> +Description
>> +---
>> +
>> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
>> +camera.
> 
> And what does it do after receiving the stream ? A more detailed description 
> would be useful. Is there any public documentation for this IP core ?
> 

I can add a more detailed description. Also, here is a link to the
documentation, but I'm afraid you might have to register yourself to access it.

CSI-2 Host
https://www.synopsys.com/dw/doc.php/ds/c/dwc_csi2_controller.pdf

CSI-2 Host IPK
https://www.synopsys.com/dw/doc.php/ds/o/ip_prototyping_kit_mipi_csi2_host_arc.pdf

>> +Required properties:
>> +- compatible: shall be "snps,dw-mipi-csi"
>> +- reg   : physical base address and size of the device memory 
> mapped
>> +  registers;
>> +- interrupts: CSI-2 Host interrupt
>> +- data-lanes: Number of lanes to be used
> 
> Is that fixed at synthesis time or configurable at runtime ?
> 

The max number is fixed at synthesis time, but you can configure it for lower
values. I added this option here because, although configurable, it's usually a
fixed value.

>> +- output-type   : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2)
> 
> What are IPI and IDI ?
> 

IPI is Image Pixel Interface and IDI Image Data Interface, these are the two
types of data output support by our CSI-2 Host controller

>> +- phys, phy-names: List of one PHY specifier and identifier string (as
>> defined
>> +  in Documentation/devicetree/bindings/phy/phy-bindings.txt).
> 
> A PHY for what ?
> 

Our controller needs a PHY, in this case a MIPI DPHY, to interact with a CSI-2
receiver (usually a sensor).

>> +Optional properties(if in IPI mode):
>> +- ipi-mode  : Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
>> +- ipi-color-mode: Color depth to be used in IPI (48 bits -> 0 or 16 bits ->
>> 1)
>> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No)
>> +- virtual-channel: Virtual channel where data is present when in IPI
> 
> We need more details than that, this is impossible to review, sorry.
> 

Sure, I'll add more details to the descripton

>> +The per-board settings:
>> + - port sub-node describing a single endpoint connected to the dw-mipi-csi
>> +   as described in video-interfaces.txt[1].
> 
> An example would be nice.
> 

I'll add an example of how we're using it.

>> diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>> b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt new file mode
>> 100644
>> index 000..2d51541
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>> @@ -0,0 +1,9 @@
>> +Synopsys DesignWare CSI-2 Host IPK Media Device
>> +
>> +This Media Device at the moment is not totally functional, however it is a
>> base
>> +for the future.
> 
> Then let's add it later :-) We don't want to design incomplete transient DT 
> bindings.
> 

I'm afraid I wasn't completely clear. This setup is fully functional. Actually
this sentence made sense in the past, but no longer does now.

>> +Required properties:
>> +
>> +- compatible: Must be "snps,plat-ipk".
>> +
>> diff --git a/Documentation/devicetree/bindings/media/snps,video-device.txt
>> b/Documentation/devicetree/bindings/media/snps,video-device.txt new file
>> mode 100644
>> index 000..d467092
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,video-device.txt
>> @@ -0,0 +1,12 @@
>> +Synopsys DesignWare CSI-2 Host video device
>> +
>> +This driver handles all the video handling part of this platform.
> 
> This is a DT binding documentation, drivers are irrelevant. You should 
> describe the hardware only.
> 
> More information is needed, based on this document I can't tell what the 
> "CSI-2 host video device" is.
> 

You're 

[RFCv2 PATCH 1/5] video: add HDMI state notifier support

[Hans Verkuil]

From: Hans Verkuil 

Add support for HDMI hotplug and EDID notifiers, which is used to convey
information from HDMI drivers to their CEC and audio counterparts.

Based on an earlier version from Russell King:

https://patchwork.kernel.org/patch/9277043/

The hdmi_notifier is a reference counted object containing the HDMI state
of an HDMI device.

When a new notifier is registered the current state will be reported to
that notifier at registration time.

Signed-off-by: Hans Verkuil 
---
 drivers/video/Kconfig |   3 +
 drivers/video/Makefile|   1 +
 drivers/video/hdmi-notifier.c | 136 ++
 include/linux/hdmi-notifier.h |  43 +
 4 files changed, 183 insertions(+)
 create mode 100644 drivers/video/hdmi-notifier.c
 create mode 100644 include/linux/hdmi-notifier.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..1ee7b9f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
 config HDMI
bool
 
+config HDMI_NOTIFIERS
+   bool
+
 if VT
source "drivers/video/console/Kconfig"
 endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17..65f5649 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_VGASTATE)+= vgastate.o
 obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HDMI_NOTIFIERS)  += hdmi-notifier.o
 
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
new file mode 100644
index 000..c2a4f1b
--- /dev/null
+++ b/drivers/video/hdmi-notifier.c
@@ -0,0 +1,136 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct hdmi_notifiers {
+   struct list_head head;
+   struct device *dev;
+   struct hdmi_notifier *n;
+};
+
+static LIST_HEAD(hdmi_notifiers);
+static DEFINE_MUTEX(hdmi_notifiers_lock);
+
+struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
+{
+   struct hdmi_notifier *n;
+
+   mutex_lock(_notifiers_lock);
+   list_for_each_entry(n, _notifiers, head) {
+   if (n->dev == dev) {
+   mutex_unlock(_notifiers_lock);
+   kref_get(>kref);
+   return n;
+   }
+   }
+   n = kzalloc(sizeof(*n), GFP_KERNEL);
+   if (!n)
+   goto unlock;
+   mutex_init(>lock);
+   BLOCKING_INIT_NOTIFIER_HEAD(>notifiers);
+   kref_init(>kref);
+   list_add_tail(>head, _notifiers);
+unlock:
+   mutex_unlock(_notifiers_lock);
+   return n;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_get);
+
+static void hdmi_notifier_release(struct kref *kref)
+{
+   struct hdmi_notifier *n =
+   container_of(kref, struct hdmi_notifier, kref);
+
+   kfree(n->edid);
+   kfree(n);
+}
+
+void hdmi_notifier_put(struct hdmi_notifier *n)
+{
+   kref_put(>kref, hdmi_notifier_release);
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_put);
+
+int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
+{
+   int ret = blocking_notifier_chain_register(>notifiers, nb);
+
+   if (ret)
+   return ret;
+   kref_get(>kref);
+   mutex_lock(>lock);
+   if (n->connected) {
+   blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
+   if (n->edid_size)
+   blocking_notifier_call_chain(>notifiers, 
HDMI_NEW_EDID, n);
+   if (n->has_eld)
+   blocking_notifier_call_chain(>notifiers, 
HDMI_NEW_ELD, n);
+   }
+   mutex_unlock(>lock);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_register);
+
+int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block 
*nb)
+{
+   int ret = blocking_notifier_chain_unregister(>notifiers, nb);
+
+   if (ret == 0)
+   hdmi_notifier_put(n);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
+
+void hdmi_event_connect(struct hdmi_notifier *n)
+{
+   mutex_lock(>lock);
+   n->connected = true;
+   blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_connect);
+
+void hdmi_event_disconnect(struct hdmi_notifier *n)
+{
+   mutex_lock(>lock);
+   n->connected = false;
+   n->has_eld = false;
+   n->edid_size = 0;
+   blocking_notifier_call_chain(>notifiers, HDMI_DISCONNECTED, n);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
+
+int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
+{
+   mutex_lock(>lock);
+   if (n->edid_allocated_size < size) {
+   void *p = kmalloc(size, GFP_KERNEL);
+
+   if (p == NULL) {
+   mutex_unlock(>lock);
+   return 

[RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

[Hans Verkuil]

From: Russell King 

We don't need the CEC engine register definitions, so let's remove them.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw-hdmi.h | 45 
 1 file changed, 45 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index fc9a560..26d6845 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -478,51 +478,6 @@
 #define HDMI_A_PRESETUP 0x501A
 #define HDMI_A_SRM_BASE 0x5020
 
-/* CEC Engine Registers */
-#define HDMI_CEC_CTRL   0x7D00
-#define HDMI_CEC_STAT   0x7D01
-#define HDMI_CEC_MASK   0x7D02
-#define HDMI_CEC_POLARITY   0x7D03
-#define HDMI_CEC_INT0x7D04
-#define HDMI_CEC_ADDR_L 0x7D05
-#define HDMI_CEC_ADDR_H 0x7D06
-#define HDMI_CEC_TX_CNT 0x7D07
-#define HDMI_CEC_RX_CNT 0x7D08
-#define HDMI_CEC_TX_DATA0   0x7D10
-#define HDMI_CEC_TX_DATA1   0x7D11
-#define HDMI_CEC_TX_DATA2   0x7D12
-#define HDMI_CEC_TX_DATA3   0x7D13
-#define HDMI_CEC_TX_DATA4   0x7D14
-#define HDMI_CEC_TX_DATA5   0x7D15
-#define HDMI_CEC_TX_DATA6   0x7D16
-#define HDMI_CEC_TX_DATA7   0x7D17
-#define HDMI_CEC_TX_DATA8   0x7D18
-#define HDMI_CEC_TX_DATA9   0x7D19
-#define HDMI_CEC_TX_DATA10  0x7D1a
-#define HDMI_CEC_TX_DATA11  0x7D1b
-#define HDMI_CEC_TX_DATA12  0x7D1c
-#define HDMI_CEC_TX_DATA13  0x7D1d
-#define HDMI_CEC_TX_DATA14  0x7D1e
-#define HDMI_CEC_TX_DATA15  0x7D1f
-#define HDMI_CEC_RX_DATA0   0x7D20
-#define HDMI_CEC_RX_DATA1   0x7D21
-#define HDMI_CEC_RX_DATA2   0x7D22
-#define HDMI_CEC_RX_DATA3   0x7D23
-#define HDMI_CEC_RX_DATA4   0x7D24
-#define HDMI_CEC_RX_DATA5   0x7D25
-#define HDMI_CEC_RX_DATA6   0x7D26
-#define HDMI_CEC_RX_DATA7   0x7D27
-#define HDMI_CEC_RX_DATA8   0x7D28
-#define HDMI_CEC_RX_DATA9   0x7D29
-#define HDMI_CEC_RX_DATA10  0x7D2a
-#define HDMI_CEC_RX_DATA11  0x7D2b
-#define HDMI_CEC_RX_DATA12  0x7D2c
-#define HDMI_CEC_RX_DATA13  0x7D2d
-#define HDMI_CEC_RX_DATA14  0x7D2e
-#define HDMI_CEC_RX_DATA15  0x7D2f
-#define HDMI_CEC_LOCK   0x7D30
-#define HDMI_CEC_WKUPCTRL   0x7D31
-
 /* I2C Master Registers (E-DDC) */
 #define HDMI_I2CM_SLAVE 0x7E00
 #define HDMI_I2CM_ADDRESS   0x7E01
-- 
2.8.1

--
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

[RFCv2 PATCH 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkuil's CEC code

[Hans Verkuil]

From: Russell King 

Add a CEC driver for the dw-hdmi hardware using Hans Verkuil's CEC
implementation.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/Kconfig|   7 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 346 ++
 drivers/gpu/drm/bridge/dw-hdmi.c  |  64 +-
 include/linux/platform_data/dw_hdmi-cec.h |  16 ++
 5 files changed, 423 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
 create mode 100644 include/linux/platform_data/dw_hdmi-cec.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 5f4ebe9..4ab137e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,6 +40,13 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.
 
+config DRM_DW_HDMI_CEC
+   tristate "Synopsis Designware CEC interface"
+   depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
+   help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cdf3a3c..6bdd8b9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-cec.c 
b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
new file mode 100644
index 000..e7e12b5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
@@ -0,0 +1,346 @@
+/* http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/
+ * tree/drivers/mxc/hdmi-cec/mxc_hdmi-cec.c?h=imx_3.0.35_4.1.0 */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#define DEV_NAME "mxc_hdmi_cec"
+
+enum {
+   HDMI_IH_CEC_STAT0   = 0x0106,
+   HDMI_IH_MUTE_CEC_STAT0  = 0x0186,
+
+   HDMI_CEC_CTRL   = 0x7d00,
+   CEC_CTRL_START  = BIT(0),
+   CEC_CTRL_NORMAL = 1 << 1,
+
+   HDMI_CEC_STAT   = 0x7d01,
+   CEC_STAT_DONE   = BIT(0),
+   CEC_STAT_EOM= BIT(1),
+   CEC_STAT_NACK   = BIT(2),
+   CEC_STAT_ARBLOST= BIT(3),
+   CEC_STAT_ERROR_INIT = BIT(4),
+   CEC_STAT_ERROR_FOLL = BIT(5),
+   CEC_STAT_WAKEUP = BIT(6),
+
+   HDMI_CEC_MASK   = 0x7d02,
+   HDMI_CEC_POLARITY   = 0x7d03,
+   HDMI_CEC_INT= 0x7d04,
+   HDMI_CEC_ADDR_L = 0x7d05,
+   HDMI_CEC_ADDR_H = 0x7d06,
+   HDMI_CEC_TX_CNT = 0x7d07,
+   HDMI_CEC_RX_CNT = 0x7d08,
+   HDMI_CEC_TX_DATA0   = 0x7d10,
+   HDMI_CEC_RX_DATA0   = 0x7d20,
+   HDMI_CEC_LOCK   = 0x7d30,
+   HDMI_CEC_WKUPCTRL   = 0x7d31,
+};
+
+struct dw_hdmi_cec {
+   void __iomem *base;
+   u32 addresses;
+   struct cec_adapter *adap;
+   struct cec_msg rx_msg;
+   unsigned int tx_status;
+   bool tx_done;
+   bool rx_done;
+   const struct dw_hdmi_cec_ops *ops;
+   void *ops_data;
+   int retries;
+   int irq;
+   struct hdmi_notifier *n;
+   struct notifier_block nb;
+};
+
+static int dw_hdmi_cec_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+   struct dw_hdmi_cec *cec = adap->priv;
+   u32 addresses;
+
+   if (logical_addr == CEC_LOG_ADDR_INVALID)
+   addresses = cec->addresses = BIT(15);
+   else
+   addresses = cec->addresses |= BIT(logical_addr);
+
+   writeb_relaxed(addresses & 255, cec->base + HDMI_CEC_ADDR_L);
+   writeb_relaxed(addresses >> 8, cec->base + HDMI_CEC_ADDR_H);
+
+   return 0;
+}
+
+static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
+   u32 signal_free_time, struct cec_msg *msg)
+{
+   struct dw_hdmi_cec *cec = adap->priv;
+   unsigned i;
+
+   cec->retries = attempts;
+
+   for (i = 0; i < msg->len; i++)
+   writeb_relaxed(msg->msg[i], cec->base + HDMI_CEC_TX_DATA0 + i);
+
+   writeb_relaxed(msg->len, cec->base + HDMI_CEC_TX_CNT);
+   writeb_relaxed(CEC_CTRL_NORMAL | CEC_CTRL_START, cec->base + 
HDMI_CEC_CTRL);
+
+   return 0;
+}
+
+static irqreturn_t dw_hdmi_cec_hardirq(int irq, void *data)
+{
+   struct cec_adapter *adap = 

[RFCv2 PATCH 3/5] drm/bridge: dw_hdmi: add HDMI notifier support

[Hans Verkuil]

From: Russell King 

Add HDMI notifiers to the HDMI bridge driver.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/Kconfig   |  1 +
 drivers/gpu/drm/bridge/dw-hdmi.c | 25 -
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 10e12e7..5f4ebe9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -27,6 +27,7 @@ config DRM_DUMB_VGA_DAC
 config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
+   select HDMI_NOTIFIERS
 
 config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsis Designware AHB Audio interface"
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ab7023e..bd02da5 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -114,6 +115,7 @@ struct dw_hdmi {
 
struct hdmi_data_info hdmi_data;
const struct dw_hdmi_plat_data *plat_data;
+   struct hdmi_notifier *n;
 
int vic;
 
@@ -1448,9 +1450,11 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
+   hdmi_event_new_edid(hdmi->n, edid, 0);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
+   hdmi_event_new_eld(hdmi->n, connector->eld);
kfree(edid);
} else {
dev_dbg(hdmi->dev, "failed to get edid\n");
@@ -1579,6 +1583,12 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
dw_hdmi_update_phy_mask(hdmi);
}
mutex_unlock(>mutex);
+
+   if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
+   hdmi_event_disconnect(hdmi->n);
+   else if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) ==
+(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_PHY_HPD))
+   hdmi_event_connect(hdmi->n);
}
 
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
@@ -1732,11 +1742,17 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
 
initialize_hdmi_ih_mutes(hdmi);
 
+   hdmi->n = hdmi_notifier_get(dev);
+   if (!hdmi->n) {
+   ret = -ENOMEM;
+   goto err_iahb;
+   }
+
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
dw_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
if (ret)
-   goto err_iahb;
+   goto err_hdmi_not;
 
/*
 * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
@@ -1788,6 +1804,8 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
 
return 0;
 
+err_hdmi_not:
+   hdmi_notifier_put(hdmi->n);
 err_iahb:
clk_disable_unprepare(hdmi->iahb_clk);
 err_isfr:
@@ -1804,6 +1822,11 @@ void dw_hdmi_unbind(struct device *dev, struct device 
*master, void *data)
if (hdmi->audio && !IS_ERR(hdmi->audio))
platform_device_unregister(hdmi->audio);
 
+   hdmi_notifier_put(hdmi->n);
+
+   if (!IS_ERR(hdmi->cec))
+   platform_device_unregister(hdmi->cec);
+
/* Disable all interrupts */
hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
 
-- 
2.8.1

--
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

[RFCv2 PATCH 0/5] CEC drivers for iMX6 and TDA9950

[Hans Verkuil]

From: Hans Verkuil 

This patch series is an update to this RFC series from Russell:

https://lists.freedesktop.org/archives/dri-devel/2016-August/115733.html

I have not seen any updates to this, so I hope that that series is still
the latest version.

The main problem with that original series was that the notifier didn't
store the state, so if a CEC driver registered with the notifier, then
it wouldn't be informed of the current state.

The hdmi-notifier code has been changed to a per-HDMI-device and refcounted
block_notifier that stores the state and will report the current state
upon registration.

The other four patches have been adapted to the new notifier code, but
no other changes were made.

It has *only* been compile-tested. I might be able to verify it next week
with an actual i.MX6 device, but it will take time to set that up.

If someone has a ready-to-test setup, then I would very much appreciate
it if this series can be tested.

The patches are also available in my branch:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=cec-notifiers

It is on top of my patch series that moves CEC out of staging. This
is planned for 4.10.

Regards,

Hans

Hans Verkuil (1):
  video: add HDMI state notifier support

Russell King (4):
  drm/bridge: dw_hdmi: remove CEC engine register definitions
  drm/bridge: dw_hdmi: add HDMI notifier support
  drm/bridge: add dw-hdmi cec driver using Hans Verkuil's CEC code
  drm/i2c: add tda998x/tda9950 CEC driver

 drivers/gpu/drm/bridge/Kconfig|   8 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 346 
 drivers/gpu/drm/bridge/dw-hdmi.c  |  89 +-
 drivers/gpu/drm/bridge/dw-hdmi.h  |  45 ---
 drivers/gpu/drm/i2c/Kconfig   |   5 +
 drivers/gpu/drm/i2c/Makefile  |   1 +
 drivers/gpu/drm/i2c/tda9950.c | 516 ++
 drivers/video/Kconfig |   3 +
 drivers/video/Makefile|   1 +
 drivers/video/hdmi-notifier.c | 136 
 include/linux/hdmi-notifier.h |  43 +++
 include/linux/platform_data/dw_hdmi-cec.h |  16 +
 include/linux/platform_data/tda9950.h |  15 +
 14 files changed, 1168 insertions(+), 57 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
 create mode 100644 drivers/gpu/drm/i2c/tda9950.c
 create mode 100644 drivers/video/hdmi-notifier.c
 create mode 100644 include/linux/hdmi-notifier.h
 create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
 create mode 100644 include/linux/platform_data/tda9950.h

-- 
2.8.1

--
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

[RFCv2 PATCH 5/5] drm/i2c: add tda998x/tda9950 CEC driver

[Hans Verkuil]

From: Russell King 

Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol.  The driver just has to read and write
the messages, and handle error conditions.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/Kconfig   |   5 +
 drivers/gpu/drm/i2c/Makefile  |   1 +
 drivers/gpu/drm/i2c/tda9950.c | 516 ++
 include/linux/platform_data/tda9950.h |  15 +
 4 files changed, 537 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/tda9950.c
 create mode 100644 include/linux/platform_data/tda9950.h

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index a6c92be..b30ea3b 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
help
  Support for NXP Semiconductors TDA998X HDMI encoders.
 
+config DRM_I2C_NXP_TDA9950
+   tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
+   depends on MEDIA_CEC_SUPPORT
+   select HDMI_NOTIFIERS
+
 endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..8a6e13e 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
 
 tda998x-y := tda998x_drv.o
 obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
new file mode 100644
index 000..601da7c
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -0,0 +1,516 @@
+/*
+ *  TDA9950 Consumer Electronics Control driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * The NXP TDA9950 implements the HDMI Consumer Electronics Control
+ * interface.  The host interface is similar to a mailbox: the data
+ * registers starting at REG_CDR0 are written to send a command to the
+ * internal CPU, and replies are read from these registers.
+ *
+ * As the data registers represent a mailbox, they must be accessed
+ * as a single I2C transaction.  See the TDA9950 data sheet for details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   REG_CSR = 0x00,
+   CSR_BUSY = BIT(7),
+   CSR_INT  = BIT(6),
+   CSR_ERR  = BIT(5),
+
+   REG_CER = 0x01,
+
+   REG_CVR = 0x02,
+
+   REG_CCR = 0x03,
+   CCR_RESET = BIT(7),
+   CCR_ON= BIT(6),
+
+   REG_ACKH = 0x04,
+   REG_ACKL = 0x05,
+
+   REG_CCONR = 0x06,
+   CCONR_ENABLE_ERROR = BIT(4),
+
+   REG_CDR0 = 0x07,
+
+   CDR1_REQ = 0x00,
+   CDR1_CNF = 0x01,
+   CDR1_IND = 0x81,
+   CDR1_ERR = 0x82,
+   CDR1_IER = 0x83,
+
+   CDR2_CNF_SUCCESS= 0x00,
+   CDR2_CNF_OFF_STATE  = 0x80,
+   CDR2_CNF_BAD_REQ= 0x81,
+   CDR2_CNF_CEC_ACCESS = 0x82,
+   CDR2_CNF_ARB_ERROR  = 0x83,
+   CDR2_CNF_BAD_TIMING = 0x84,
+   CDR2_CNF_NACK_ADDR  = 0x85,
+   CDR2_CNF_NACK_DATA  = 0x86,
+};
+
+struct tda9950_priv {
+   struct i2c_client *client;
+   struct device *hdmi;
+   struct cec_adapter *adap;
+   struct tda9950_glue *glue;
+   u16 addresses;
+   struct cec_msg rx_msg;
+   struct hdmi_notifier *n;
+   struct notifier_block nb;
+   bool open;
+};
+
+static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg;
+   u8 buf[cnt + 1];
+   int ret;
+
+   buf[0] = addr;
+   memcpy(buf + 1, p, cnt);
+
+   msg.addr = client->addr;
+   msg.flags = 0;
+   msg.len = cnt + 1;
+   msg.buf = buf;
+
+   dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
+
+   ret = i2c_transfer(client->adapter, , 1);
+   if (ret < 0)
+   dev_err(>dev, "Error %d writing to cec:0x%x\n", ret, 
addr);
+   return ret < 0 ? ret : 0;
+}
+
+static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
+{
+   tda9950_write_range(client, addr, , 1);
+}
+
+static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg[2];
+   int ret;
+
+   msg[0].addr = client->addr;
+   msg[0].flags = 0;
+   msg[0].len = 1;
+   msg[0].buf = 
+   msg[1].addr = client->addr;
+   msg[1].flags = I2C_M_RD;
+   msg[1].len = cnt;
+   msg[1].buf = p;
+
+   ret = i2c_transfer(client->adapter, msg, 2);
+   if (ret < 0)
+   dev_err(>dev, "Error %d reading from cec:0x%x\n", ret, 
addr);
+
+   dev_dbg(>dev, "rd 0x%02x: %*ph\n", addr, cnt, p);
+
+   return ret;
+}
+
+static u8 tda9950_read(struct i2c_client *client, 

Re: [PATCH v3 0/9] Qualcomm video decoder/encoder driver

[Hans Verkuil]

On 11/14/2016 03:59 PM, Stanimir Varbanov wrote:
> Hi,
> 
> On 11/11/2016 02:11 PM, Javier Martinez Canillas wrote:
>> Hello Hans,
>>
>> On Fri, Nov 11, 2016 at 8:49 AM, Hans Verkuil  wrote:
>>> Hi Stanimir,
>>>
>>> Overall it looks good. As you saw, I do have some comments but nothing 
>>> major.
>>>
>>> One question: you use qcom as the directory name. How about using qualcomm?
>>>
>>> It's really not that much longer and a bit more obvious.
>>>
>>> Up to you, though.
>>>
>>
>> It seems qcom is more consistent to the name used in most subsystems
>> for Qualcomm:
>>
>> $ find -name *qcom
>> ./arch/arm/mach-qcom
>> ./arch/arm64/boot/dts/qcom
>> ./Documentation/devicetree/bindings/soc/qcom
>> ./sound/soc/qcom
>> ./drivers/pinctrl/qcom
>> ./drivers/soc/qcom
>> ./drivers/clk/qcom
>>
>> $ find -name *qualcomm
>> ./drivers/net/ethernet/qualcomm
> 
> Also qcom is the vendor prefix used in [1]
> 
> [1] Documentation/devicetree/bindings/vendor-prefixes.txt
> 

qcom it is, then :-)

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 v3 0/9] Qualcomm video decoder/encoder driver

[Stanimir Varbanov]

Hi,

On 11/11/2016 02:11 PM, Javier Martinez Canillas wrote:
> Hello Hans,
> 
> On Fri, Nov 11, 2016 at 8:49 AM, Hans Verkuil  wrote:
>> Hi Stanimir,
>>
>> Overall it looks good. As you saw, I do have some comments but nothing major.
>>
>> One question: you use qcom as the directory name. How about using qualcomm?
>>
>> It's really not that much longer and a bit more obvious.
>>
>> Up to you, though.
>>
> 
> It seems qcom is more consistent to the name used in most subsystems
> for Qualcomm:
> 
> $ find -name *qcom
> ./arch/arm/mach-qcom
> ./arch/arm64/boot/dts/qcom
> ./Documentation/devicetree/bindings/soc/qcom
> ./sound/soc/qcom
> ./drivers/pinctrl/qcom
> ./drivers/soc/qcom
> ./drivers/clk/qcom
> 
> $ find -name *qualcomm
> ./drivers/net/ethernet/qualcomm

Also qcom is the vendor prefix used in [1]

[1] Documentation/devicetree/bindings/vendor-prefixes.txt

-- 
regards,
Stan
--
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/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host

[Laurent Pinchart]

Hi Ramiro,

Thank you for the patch.

On Monday 14 Nov 2016 14:20:22 Ramiro Oliveira wrote:
> Add documentation for Media and Video Device, as well as the DW MIPI CSI-2
> Host.
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 27 +++
>  .../devicetree/bindings/media/snps,plat-ipk.txt|  9 
>  .../bindings/media/snps,video-device.txt   | 12 ++
>  3 files changed, 48 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt create mode
> 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt create
> mode 100644 Documentation/devicetree/bindings/media/snps,video-device.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt new file
> mode 100644
> index 000..bec7441
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> @@ -0,0 +1,27 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +---
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.

And what does it do after receiving the stream ? A more detailed description 
would be useful. Is there any public documentation for this IP core ?

> +Required properties:
> +- compatible: shall be "snps,dw-mipi-csi"
> +- reg: physical base address and size of the device memory 
mapped
> +   registers;
> +- interrupts : CSI-2 Host interrupt
> +- data-lanes: Number of lanes to be used

Is that fixed at synthesis time or configurable at runtime ?

> +- output-type   : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2)

What are IPI and IDI ?

> +- phys, phy-names: List of one PHY specifier and identifier string (as
> defined
> +  in Documentation/devicetree/bindings/phy/phy-bindings.txt).

A PHY for what ?

> +Optional properties(if in IPI mode):
> +- ipi-mode   : Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
> +- ipi-color-mode: Color depth to be used in IPI (48 bits -> 0 or 16 bits ->
> 1)
> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No)
> +- virtual-channel: Virtual channel where data is present when in IPI

We need more details than that, this is impossible to review, sorry.

> +The per-board settings:
> + - port sub-node describing a single endpoint connected to the dw-mipi-csi
> +   as described in video-interfaces.txt[1].

An example would be nice.

> diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt new file mode
> 100644
> index 000..2d51541
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> @@ -0,0 +1,9 @@
> +Synopsys DesignWare CSI-2 Host IPK Media Device
> +
> +This Media Device at the moment is not totally functional, however it is a
> base
> +for the future.

Then let's add it later :-) We don't want to design incomplete transient DT 
bindings.

> +Required properties:
> +
> +- compatible: Must be "snps,plat-ipk".
> +
> diff --git a/Documentation/devicetree/bindings/media/snps,video-device.txt
> b/Documentation/devicetree/bindings/media/snps,video-device.txt new file
> mode 100644
> index 000..d467092
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,video-device.txt
> @@ -0,0 +1,12 @@
> +Synopsys DesignWare CSI-2 Host video device
> +
> +This driver handles all the video handling part of this platform.

This is a DT binding documentation, drivers are irrelevant. You should 
describe the hardware only.

More information is needed, based on this document I can't tell what the 
"CSI-2 host video device" is.

> +Required properties:
> +
> +- compatible: Must be "snps,video-device".
> +
> +- dmas, dma-names: List of one DMA specifier and identifier string (as
> defined
> +  in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
> +  requires a DMA channel with the identifier string set to "port" followed
> by
> +  the port index.

-- 
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 0/2] Add support for the DW IP Prototyping Kits for MIPI CSI-2 Host

[Ramiro Oliveira]

This patchset adds basic support for the DW CSI-2 Host IPK. There are 
some parts of the kit that aren't currently supported by this media 
platform driver but will be in the future.

Ramiro Oliveira (2):
  Add Documentation for Media Device, Video Device, and Synopsys DW MIPI
CSI-2 Host
  Add basic support for DW CSI-2 Host IPK

 .../devicetree/bindings/media/snps,dw-mipi-csi.txt |  27 +
 .../devicetree/bindings/media/snps,plat-ipk.txt|   9 +
 .../bindings/media/snps,video-device.txt   |  12 +
 MAINTAINERS|   7 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/dwc/Kconfig |  36 +
 drivers/media/platform/dwc/Makefile|   3 +
 drivers/media/platform/dwc/dw_mipi_csi.c   | 687 +
 drivers/media/platform/dwc/dw_mipi_csi.h   | 179 +
 drivers/media/platform/dwc/plat_ipk.c  | 835 +
 drivers/media/platform/dwc/plat_ipk.h  |  97 +++
 drivers/media/platform/dwc/plat_ipk_video.h|  97 +++
 drivers/media/platform/dwc/video_device.c  | 741 ++
 drivers/media/platform/dwc/video_device.h  | 101 +++
 15 files changed, 2834 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
 create mode 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt
 create mode 100644 
Documentation/devicetree/bindings/media/snps,video-device.txt
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.c
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk.c
 create mode 100644 drivers/media/platform/dwc/plat_ipk.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk_video.h
 create mode 100644 drivers/media/platform/dwc/video_device.c
 create mode 100644 drivers/media/platform/dwc/video_device.h

-- 
2.10.2


--
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 2/2] Add basic support for DW CSI-2 Host IPK

[Ramiro Oliveira]

Add support for basic configuration of the DW CSI-2 Host IPK

Signed-off-by: Ramiro Oliveira 
---
 MAINTAINERS |   7 +
 drivers/media/platform/Kconfig  |   1 +
 drivers/media/platform/Makefile |   2 +
 drivers/media/platform/dwc/Kconfig  |  36 ++
 drivers/media/platform/dwc/Makefile |   3 +
 drivers/media/platform/dwc/dw_mipi_csi.c| 687 +++
 drivers/media/platform/dwc/dw_mipi_csi.h| 179 ++
 drivers/media/platform/dwc/plat_ipk.c   | 835 
 drivers/media/platform/dwc/plat_ipk.h   |  97 
 drivers/media/platform/dwc/plat_ipk_video.h |  97 
 drivers/media/platform/dwc/video_device.c   | 741 
 drivers/media/platform/dwc/video_device.h   | 101 
 12 files changed, 2786 insertions(+)
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.c
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk.c
 create mode 100644 drivers/media/platform/dwc/plat_ipk.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk_video.h
 create mode 100644 drivers/media/platform/dwc/video_device.c
 create mode 100644 drivers/media/platform/dwc/video_device.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 6a71422..f54dfd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10618,6 +10618,13 @@ S: Maintained
 F: drivers/staging/media/st-cec/
 F: Documentation/devicetree/bindings/media/stih-cec.txt
 
+SYNOPSYS DESIGNWARE CSI-2 HOST IPK DRIVER
+M: Ramiro Oliveira 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/dwc/
+
 SYNOPSYS DESIGNWARE DMAC DRIVER
 M: Viresh Kumar 
 M: Andy Shevchenko 
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..6fef760f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/dwc/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..623f5d2 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -61,6 +61,8 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)  += rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)  += atmel/
 
+obj-$(CONFIG_VIDEO_DWC)+= dwc/
+
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
diff --git a/drivers/media/platform/dwc/Kconfig 
b/drivers/media/platform/dwc/Kconfig
new file mode 100644
index 000..fb8533b
--- /dev/null
+++ b/drivers/media/platform/dwc/Kconfig
@@ -0,0 +1,36 @@
+config VIDEO_DWC
+   bool "Designware Cores CSI-2 IPK (EXPERIMENTAL)"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
+   help
+ Say Y here to enable support for the DesignWare Cores CSI-2 Host IP
+ Prototyping Kit.
+
+if VIDEO_DWC
+config DWC_PLATFORM
+   tristate "SNPS DWC MIPI CSI2 Host"
+   depends on VIDEO_DWC
+   help
+ This is the V4L2 plaftorm driver driver for the DWC CSI-2 HOST IPK
+
+ To compile this driver as a module, choose M here
+
+
+config DWC_MIPI_CSI2_HOST
+   tristate "SNPS DWC MIPI CSI2 Host"
+   select GENERIC_PHY
+   depends on VIDEO_DWC
+   help
+ This is a V4L2 driver for SNPS DWC MIPI-CSI2
+
+ To compile this driver as a module, choose M here
+
+config DWC_VIDEO_DEVICE
+   tristate "DWC VIDEO DEVICE"
+   select VIDEOBUF2_VMALLOC
+   select VIDEOBUF2_DMA_CONTIG
+   depends on VIDEO_DWC
+   help
+ This is a V4L2 driver for SNPS Video device
+ To compile this driver as a module, choose M here
+
+endif # VIDEO_DWC
diff --git a/drivers/media/platform/dwc/Makefile 
b/drivers/media/platform/dwc/Makefile
new file mode 100644
index 000..75c74b7
--- /dev/null
+++ b/drivers/media/platform/dwc/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DWC_PLATFORM) += plat_ipk.o
+obj-$(CONFIG_DWC_MIPI_CSI2_HOST)   += dw_mipi_csi.o
+obj-$(CONFIG_DWC_VIDEO_DEVICE) += video_device.o
diff --git a/drivers/media/platform/dwc/dw_mipi_csi.c 
b/drivers/media/platform/dwc/dw_mipi_csi.c
new file mode 100644
index 000..1337a5e
--- /dev/null
+++ b/drivers/media/platform/dwc/dw_mipi_csi.c
@@ -0,0 +1,687 @@
+/*
+ * DWC MIPI CSI-2 Host device driver
+ *
+ * Copyright (C) 2016 Synopsys, Inc. All 

[PATCH 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host

[Ramiro Oliveira]

Add documentation for Media and Video Device, as well as the DW MIPI CSI-2 
Host.

Signed-off-by: Ramiro Oliveira 
---
 .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 27 ++
 .../devicetree/bindings/media/snps,plat-ipk.txt|  9 
 .../bindings/media/snps,video-device.txt   | 12 ++
 3 files changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
 create mode 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt
 create mode 100644 
Documentation/devicetree/bindings/media/snps,video-device.txt

diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt 
b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
new file mode 100644
index 000..bec7441
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
@@ -0,0 +1,27 @@
+Synopsys DesignWare CSI-2 Host controller
+
+Description
+---
+
+This HW block is used to receive image coming from an MIPI CSI-2 compatible
+camera.
+
+Required properties:
+- compatible: shall be "snps,dw-mipi-csi"
+- reg  : physical base address and size of the device memory mapped
+ registers;
+- interrupts   : CSI-2 Host interrupt
+- data-lanes: Number of lanes to be used
+- output-type   : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2)
+- phys, phy-names: List of one PHY specifier and identifier string (as defined
+  in Documentation/devicetree/bindings/phy/phy-bindings.txt).
+
+Optional properties(if in IPI mode):
+- ipi-mode : Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
+- ipi-color-mode: Color depth to be used in IPI (48 bits -> 0 or 16 bits -> 1)
+- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No)
+- virtual-channel: Virtual channel where data is present when in IPI
+
+The per-board settings:
+ - port sub-node describing a single endpoint connected to the dw-mipi-csi
+   as described in video-interfaces.txt[1].
diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt 
b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
new file mode 100644
index 000..2d51541
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
@@ -0,0 +1,9 @@
+Synopsys DesignWare CSI-2 Host IPK Media Device
+
+This Media Device at the moment is not totally functional, however it is a base
+for the future.
+
+Required properties:
+
+- compatible: Must be "snps,plat-ipk".
+
diff --git a/Documentation/devicetree/bindings/media/snps,video-device.txt 
b/Documentation/devicetree/bindings/media/snps,video-device.txt
new file mode 100644
index 000..d467092
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,video-device.txt
@@ -0,0 +1,12 @@
+Synopsys DesignWare CSI-2 Host video device
+
+This driver handles all the video handling part of this platform.
+
+Required properties:
+
+- compatible: Must be "snps,video-device".
+
+- dmas, dma-names: List of one DMA specifier and identifier string (as defined
+  in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
+  requires a DMA channel with the identifier string set to "port" followed by
+  the port index.
-- 
2.10.2


--
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: Including images on Sphinx documents

[Mauro Carvalho Chehab]

Em Sun, 13 Nov 2016 14:00:27 -0700
Jonathan Corbet  escreveu:

> On Mon, 7 Nov 2016 09:46:48 -0200
> Mauro Carvalho Chehab  wrote:
> 
> > When running LaTeX in interactive mode, building just the media
> > PDF file with:
> > 
> > $ cls;make cleandocs; make SPHINXOPTS="-j5" DOCBOOKS="" 
> > SPHINXDIRS=media latexdocs 
> > $ PDFLATEX=xelatex LATEXOPTS="-interaction=interactive" -C 
> > Documentation/output/media/latex
> > 
> > I get this:
> > 
> > LaTeX Warning: Hyper reference `uapi/v4l/subdev-formats:bayer-patterns' 
> > on page
> >  153 undefined on input line 21373.
> > 
> >  [153]
> > ! Extra alignment tab has been changed to \cr.
> >  \endtemplate 
> > 
> > l.21429 \unskip}\relax \unskip}
> >\relax \\
> > ? 
> > 
> > This patch fixes the issue:
> > 
> > https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dirty-pdf=b709de415f34d77cc121cad95bece9c7ef4d12fd
> > 
> > That means that Sphinx is not generating the right LaTeX output even for
> > (some?) PNG images.  
> 
> So I'm seriously confused.
> 
> I can get that particular message - TeX is complaining about too many
> columns in the table.  But applying your patch (with a suitable bayer.pdf
> provided) does not fix the problem.  Indeed, I can remove the figure with
> the image entirely and still not fix the problem.  Are you sure that the
> patch linked here actually fixed it for you?

There are two patches on the series fixing the column issues for the Bayer
formats table on the /6 patch series.

I guess I got confused with that, because of this warning:

LaTeX Warning: Hyper reference `uapi/v4l/subdev-formats:bayer-patterns' 
on page
 153 undefined on input line 21373.

Anyway, you're right: PNG is indeed working fine[1], and the
cross-reference is OK. The issue is just with SVG.

I'll fold it with patch 6/6 and submit a new series.

Sorry for the mess.

[1] I tested now on sphinx 1.4.8 - I was using an older version
before (1.4.5, I guess).

Thanks,
Mauro

[PATCH] docs-rst: Let Sphinx do PNG image conversion

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index 0f08bd8b87ba..297b85c37ab9 100644
--- a/Documentation/media/Makefile
+++ b/Documentation/media/Makefile
@@ -12,17 +12,6 @@ TARGETS := $(addprefix $(BUILDDIR)/, $(FILES))
 
 IMAGES = \
typical_media_device.svg \
-   uapi/v4l/fieldseq_tb.png \
-   uapi/v4l/selection.png \
-   uapi/v4l/vbi_hsync.png \
-   uapi/v4l/fieldseq_bt.png \
-   uapi/v4l/crop.png \
-   uapi/v4l/nv12mt.png \
-   uapi/v4l/vbi_525.png \
-   uapi/v4l/nv12mt_example.png \
-   uapi/v4l/vbi_625.png \
-   uapi/v4l/pipeline.png \
-   uapi/v4l/bayer.png \
uapi/dvb/dvbstb.svg \
uapi/v4l/constraints.svg \
uapi/v4l/subdev-image-processing-full.svg \
@@ -37,8 +26,6 @@ cmd = $(echo-cmd) $(cmd_$(1))
 quiet_cmd_genpdf = GENPDF  $2
   cmd_genpdf = convert $2 $3
 
-%.pdf: %.png
-   @$(call cmd,genpdf,$<,$@)
 %.pdf: %.svg
@$(call cmd,genpdf,$<,$@)
 
diff --git a/Documentation/media/uapi/v4l/crop.rst 
b/Documentation/media/uapi/v4l/crop.rst
index 31c5ba5ebd04..578c6f3d20f3 100644
--- a/Documentation/media/uapi/v4l/crop.rst
+++ b/Documentation/media/uapi/v4l/crop.rst
@@ -53,8 +53,8 @@ Cropping Structures
 
 .. _crop-scale:
 
-.. figure::  crop.*
-:alt:crop.pdf / crop.png
+.. figure::  crop.png
+:alt:crop.png
 :align:  center
 
 Image Cropping, Insertion and Scaling
diff --git a/Documentation/media/uapi/v4l/dev-raw-vbi.rst 
b/Documentation/media/uapi/v4l/dev-raw-vbi.rst
index fb4d9c4098a0..f81d906137ee 100644
--- a/Documentation/media/uapi/v4l/dev-raw-vbi.rst
+++ b/Documentation/media/uapi/v4l/dev-raw-vbi.rst
@@ -221,8 +221,8 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT 
` does
 
 .. _vbi-hsync:
 
-.. figure::  vbi_hsync.*
-:alt:vbi_hsync.pdf / vbi_hsync.png
+.. figure::  vbi_hsync.png
+:alt:vbi_hsync.png
 :align:  center
 
 **Figure 4.1. Line synchronization**
@@ -230,8 +230,8 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT 
` does
 
 .. _vbi-525:
 
-.. figure::  vbi_525.*
-:alt:vbi_525.pdf / vbi_525.png
+.. figure::  vbi_525.png
+:alt:vbi_525.png
 :align:  center
 
 **Figure 4.2. ITU-R 525 line numbering (M/NTSC and M/PAL)**
@@ -240,8 +240,8 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT 
` does
 
 .. _vbi-625:
 
-.. figure::  vbi_625.*
-:alt:vbi_625.pdf / vbi_625.png
+.. figure::  vbi_625.png
+:alt:vbi_625.png
 :align:  center
 
 **Figure 4.3. ITU-R 625 line numbering**
diff --git a/Documentation/media/uapi/v4l/dev-subdev.rst 
b/Documentation/media/uapi/v4l/dev-subdev.rst
index b515424b3949..c18e9c5427ee 100644
--- 

Re: [PATCH v4 7/8] v4l: Add signal lock status to source change events

[Devin Heitmueller]

> OK, but what can the application do with that event? If the glitch didn't
> affect the video, then it is pointless.
>
> If the lock is lost, then normally you loose video as well. If not, then
> applications are not interested in the event.

What about free running mode (where some decoders delivers blue or
black video with no signal present)?  In that case it might still be
useful to inform the application so it can show a message that says
something like "No Signal".

Devin


-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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] uvcvideo: Add bayer 16-bit format patterns

[Sakari Ailus]

Hi Edgar,

On Mon, Nov 14, 2016 at 02:26:56PM +0100, Edgar Thier wrote:
> From aec97c931cb4b91f91dd0ed38f74d866d4f13347 Mon Sep 17 00:00:00 2001
> From: Edgar Thier 
> Date: Mon, 14 Nov 2016 14:17:57 +0100
> Subject: [PATCH] uvcvideo: Add bayer 16-bit format patterns
> 
> Add bayer 16-bit GUIDs to uvcvideo and associated them with the
> corresponding V4L2 pixel formats.
> 
> Signed-off-by: Edgar Thier 
> ---

...

> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4364ce6..6bdf592 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -605,6 +605,9 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12  GRGR.. 
> BGBG.. */
> #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
> GBGB.. */
> #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
> GRGR.. */
> +#define V4L2_PIX_FMT_SGBRG16 v4l2_fourcc('G', 'B', '1', '6') /* 16  GBGB.. 
> RGRG.. */
> +#define V4L2_PIX_FMT_SRGGB16 v4l2_fourcc('R', 'G', '1', '6') /* 16  RGRG.. 
> GBGB.. */
> +#define V4L2_PIX_FMT_SGRBG16 v4l2_fourcc('G', 'R', '1', '6') /* 16  GRGR.. 
> BGBG.. */

Thanks for the patch!

Could you rebase your uvcvideo changes on this patch, dropping the framework
changes from yours?

Cc Laurent. Laurent, could you take both of the patches to your tree after
the rebase?

The patch is also available here:




>From c5b60538b33f993109248a642c8e9b74f7d1abd1 Mon Sep 17 00:00:00 2001
From: Sakari Ailus 
Date: Mon, 27 Jun 2016 16:46:16 +0300
Subject: [PATCH 1/1] v4l: Add 16-bit raw bayer pixel formats

The formats added by this patch are:

V4L2_PIX_FMT_SBGGR16
V4L2_PIX_FMT_SGBRG16
V4L2_PIX_FMT_SGRBG16

V4L2_PIX_FMT_SRGGB16 already existed before the patch. Rework the
documentation to match that of the other sample depths.

Also align the description of V4L2_PIX_FMT_SRGGB16 to match with other
similar formats.

Signed-off-by: Sakari Ailus 
Acked-by: Lad, Prabhakar 
---
 Documentation/media/uapi/v4l/pixfmt-rgb.rst |  2 +-
 Documentation/media/uapi/v4l/pixfmt-sbggr16.rst | 62 --
 Documentation/media/uapi/v4l/pixfmt-srggb16.rst | 69 +
 drivers/media/v4l2-core/v4l2-ioctl.c|  5 +-
 include/uapi/linux/videodev2.h  |  3 ++
 5 files changed, 77 insertions(+), 64 deletions(-)
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb16.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst 
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 9cc9808..b0f3513 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -12,9 +12,9 @@ RGB Formats
 
 pixfmt-packed-rgb
 pixfmt-srggb8
-pixfmt-sbggr16
 pixfmt-srggb10
 pixfmt-srggb10p
 pixfmt-srggb10alaw8
 pixfmt-srggb10dpcm8
 pixfmt-srggb12
+pixfmt-srggb16
diff --git a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst 
b/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
deleted file mode 100644
index 6f7f327..000
--- a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
+++ /dev/null
@@ -1,62 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SBGGR16:
-
-*
-V4L2_PIX_FMT_SBGGR16 ('BYR2')
-*
-
-Bayer RGB format
-
-
-Description
-===
-
-This format is similar to
-:ref:`V4L2_PIX_FMT_SBGGR8 `, except each pixel
-has a depth of 16 bits. The least significant byte is stored at lower
-memory addresses (little-endian).
-
-**Byte Order.**
-Each cell is one byte.
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-* - start + 0:
-  - B\ :sub:`00low`
-  - B\ :sub:`00high`
-  - G\ :sub:`01low`
-  - G\ :sub:`01high`
-  - B\ :sub:`02low`
-  - B\ :sub:`02high`
-  - G\ :sub:`03low`
-  - G\ :sub:`03high`
-* - start + 8:
-  - G\ :sub:`10low`
-  - G\ :sub:`10high`
-  - R\ :sub:`11low`
-  - R\ :sub:`11high`
-  - G\ :sub:`12low`
-  - G\ :sub:`12high`
-  - R\ :sub:`13low`
-  - R\ :sub:`13high`
-* - start + 16:
-  - B\ :sub:`20low`
-  - B\ :sub:`20high`
-  - G\ :sub:`21low`
-  - G\ :sub:`21high`
-  - B\ :sub:`22low`
-  - B\ :sub:`22high`
-  - G\ :sub:`23low`
-  - G\ :sub:`23high`
-* - start + 24:
-  - G\ :sub:`30low`
-  - G\ :sub:`30high`
-  - R\ :sub:`31low`
-  - R\ :sub:`31high`
-  - G\ :sub:`32low`
-  - G\ :sub:`32high`
-  - R\ :sub:`33low`
-  - R\ :sub:`33high`
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb16.rst 

[PATCH] s5p-mfc: Fix clock management in s5p_mfc_release function

[Marek Szyprowski]

Clock control indirectly requires access to MFC device, so call it only
if we are sure that the device exists in s5p_mfc_release function.
s5p_mfc_remove() calls s5p_mfc_final_pm(), which releases all PM related
resources, including clocks, so any call to clocks related functions
is not valid after s5p_mfc_final_pm().

Fixes: d695c12 ("[media] media: s5p-mfc fix invalid memory access from
s5p_mfc_release()")

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 0c8a4616e827..a0a29194ccd1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -940,10 +940,11 @@ static int s5p_mfc_release(struct file *file)
mfc_debug_enter();
if (dev)
mutex_lock(>mfc_mutex);
-   s5p_mfc_clock_on();
vb2_queue_release(>vq_src);
vb2_queue_release(>vq_dst);
if (dev) {
+   s5p_mfc_clock_on();
+
/* Mark context as idle */
clear_work_bit_irqsave(ctx);
/*
@@ -965,9 +966,9 @@ static int s5p_mfc_release(struct file *file)
if (s5p_mfc_power_off() < 0)
mfc_err("Power off failed\n");
}
+   mfc_debug(2, "Shutting down clock\n");
+   s5p_mfc_clock_off();
}
-   mfc_debug(2, "Shutting down clock\n");
-   s5p_mfc_clock_off();
if (dev)
dev->ctx[ctx->num] = NULL;
s5p_mfc_dec_ctrls_delete(ctx);
-- 
1.9.1

--
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/2] Add support for OV5647 sensor

[Ramiro Oliveira]

Add support for OV5647 sensor.

Modes supported:
 - 640x480 RAW 8

Signed-off-by: Ramiro Oliveira 
---
 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  12 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov5647.c | 861 +
 4 files changed, 881 insertions(+)
 create mode 100644 drivers/media/i2c/ov5647.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 93e9f42..6a71422 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8895,6 +8895,13 @@ M:   Harald Welte 
 S: Maintained
 F: drivers/char/pcmcia/cm4040_cs.*
 
+OMNIVISION OV5647 SENSOR DRIVER
+M: Ramiro Oliveira 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov5647.c
+
 OMNIVISION OV7670 SENSOR DRIVER
 M: Jonathan Corbet 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4b..4237165 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -531,6 +531,18 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV5647
+   tristate "OmniVision OV5647 sensor support"
+   depends on OF
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5647 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5647.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2..0d9014c 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -82,3 +82,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
new file mode 100644
index 000..0b3b4f2
--- /dev/null
+++ b/drivers/media/i2c/ov5647.c
@@ -0,0 +1,861 @@
+/*
+ * A V4L2 driver for OmniVision OV5647 cameras.
+ *
+ * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
+ * Copyright (C) 2011 Sylwester Nawrocki 
+ *
+ * Based on Omnivision OV7670 Camera Driver
+ * Copyright (C) 2006-7 Jonathan Corbet 
+ *
+ * Copyright (C) 2016, Synopsys, Inc.
+ *
+ * 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 version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SENSOR_NAME "ov5647"
+
+#define OV5647_SW_RESET0x1003
+#define OV5647_REG_CHIPID_H0x300A
+#define OV5647_REG_CHIPID_L0x300B
+
+#define REG_TERM 0xfffe
+#define VAL_TERM 0xfe
+#define REG_DLY  0x
+
+#define OV5647_ROW_START   0x01
+#define OV5647_ROW_START_MIN   0
+#define OV5647_ROW_START_MAX   2004
+#define OV5647_ROW_START_DEF   54
+
+#define OV5647_COLUMN_START0x02
+#define OV5647_COLUMN_START_MIN0
+#define OV5647_COLUMN_START_MAX2750
+#define OV5647_COLUMN_START_DEF16
+
+#define OV5647_WINDOW_HEIGHT   0x03
+#define OV5647_WINDOW_HEIGHT_MIN   2
+#define OV5647_WINDOW_HEIGHT_MAX   2006
+#define OV5647_WINDOW_HEIGHT_DEF   1944
+
+#define OV5647_WINDOW_WIDTH0x04
+#define OV5647_WINDOW_WIDTH_MIN2
+#define OV5647_WINDOW_WIDTH_MAX2752
+#define OV5647_WINDOW_WIDTH_DEF2592
+
+struct regval_list {
+   u16 addr;
+   u8 data;
+};
+
+struct cfg_array {
+   struct regval_list *regs;
+   int size;
+};
+
+struct sensor_win_size {
+   int width;
+   int height;
+   unsigned int hoffset;
+   unsigned int voffset;
+   unsigned int hts;
+   unsigned int vts;
+   unsigned int pclk;
+   unsigned int mipi_bps;
+   unsigned int fps_fixed;
+   unsigned int bin_factor;
+   unsigned int intg_min;
+   unsigned int intg_max;
+   void *regs;
+   int regs_size;
+   int (*set_size)(struct v4l2_subdev *sd);
+};
+
+
+struct ov5647 {
+   struct device   *dev;
+   

[PATCH v4 0/2] Add support for Omnivision OV5647

[Ramiro Oliveira]

Hello,

This patch adds support for the Omnivision OV5647 sensor.

At the moment it only supports 640x480 in Raw 8.

This is the fourth version of the OV5647 camera driver patchset.

v4: 
 - Add correct license
 - Revert debugging info to generic infrastructure
 - Turn defines into enums
 - Correct code style issues
 - Remove unused defines
 - Make sure all errors where being handled
 - Rename some functions to make code more readable
 - Add some debugging info

v3: 
 - No changes. Re-submitted due to lack of responses

v2: 
 - Corrections in DT documentation

Ramiro Oliveira (2):
  Add OV5647 device tree documentation
  Add support for OV5647 sensor

 .../devicetree/bindings/media/i2c/ov5647.txt   |  19 +
 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  12 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov5647.c | 861 +
 5 files changed, 900 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
 create mode 100644 drivers/media/i2c/ov5647.c

-- 
2.10.2


--
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 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Add device tree documentation.

Signed-off-by: Ramiro Oliveira 
---
 .../devicetree/bindings/media/i2c/ov5647.txt  | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
new file mode 100644
index 000..4c91b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
@@ -0,0 +1,19 @@
+Omnivision OV5647 raw image sensor
+-
+
+OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
+and CCI (I2C compatible) control bus.
+
+Required properties:
+
+- compatible   : "ovti,ov5647";
+- reg  : I2C slave address of the sensor;
+
+The common video interfaces bindings (see video-interfaces.txt) should be
+used to specify link to the image data receiver. The OV5647 device
+node should contain one 'port' child node with an 'endpoint' subnode.
+
+Following properties are valid for the endpoint node:
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+  video-interfaces.txt.  The sensor supports only two data lanes.
-- 
2.10.2


--
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 2/2] media: Add a driver for the ov5645 camera sensor.

[Mark Brown]

On Mon, Nov 14, 2016 at 02:18:49PM +0200, Laurent Pinchart wrote:
> On Wednesday 26 Oct 2016 12:51:49 Mark Brown wrote:

> > Why would this be guaranteed by the API given that it's not documented
> > and why would many drivers break?  It's fairly rare for devices other
> > than SoCs to have strict power on sequencing requirements as it is hard
> > to achieve in practical systems.

> Is there a reason why the API shouldn't guarantee that regulators are powered 
> on in the order listed, and powered off in the reverse order ? Looking at the 

If it ever even did that through implementation it's not been true for a
very long time - it does the regulator enables in parallel in order to
reduce the overall time to power things up.  I keep wanting to come up
with code to figure out if we're using multiple enable bits in a single
register and hit them all at once though it's likely to be more trouble
than it's worth.

> implementation that's already the case for regulator_bulk_disable(), but 
> regulator_bulk_enable() uses async scheduling so doesn't guarantee ordering. 
> I 
> wonder whether a synchronous version of regulator_bulk_enable() would be 
> useful.

*Possibly* but I'd be surprised to learn that there's a substantial
amount of hardware out there that cares given that a power on reset
circuit isn't exactly complex to implement.  You do sometimes see a
global rail that should come up first (especially if there is an
integrated regulator) but I've not seen many cases where the hardware
cared outside of SoCs.


signature.asc
Description: PGP signature

Re: [RFC v4 08/21] media: Enable allocating the media device dynamically

[Sakari Ailus]

Hi Shuah,

On Tue, Nov 08, 2016 at 12:20:29PM -0700, Shuah Khan wrote:
> On Tue, Nov 8, 2016 at 6:55 AM, Sakari Ailus
>  wrote:
> > From: Sakari Ailus 
> >
> > Allow allocating the media device dynamically. As the struct media_device
> > embeds struct media_devnode, the lifetime of that object is that same than
> > that of the media_device.
> >
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/media-device.c | 15 +++
> >  include/media/media-device.h | 13 +
> >  2 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > index a31329d..496195e 100644
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -684,6 +684,21 @@ void media_device_init(struct media_device *mdev)
> >  }
> >  EXPORT_SYMBOL_GPL(media_device_init);
> >
> > +struct media_device *media_device_alloc(struct device *dev)
> > +{
> > +   struct media_device *mdev;
> > +
> > +   mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
> > +   if (!mdev)
> > +   return NULL;
> > +
> > +   mdev->dev = dev;
> > +   media_device_init(mdev);
> > +
> > +   return mdev;
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_alloc);
> > +
> 
> One problem with this allocation is, this media device can't be shared across
> drivers. For au0828 and snd-usb-audio should be able to share the
> media_device. That is what the Media Allocator API patch series does.
> This a quick review and I will review the patch series and get back to
> you.

The assumption has always been there that a media device has a single struct
device related to it. It hasn't been visible in the function call API
though, just in the data structures.

I have to admit I may have forgotten something that was discussed back then,
but do you need to share the same media device over multiple devices in the
system? I don't see that at least in the allocator patch itself. It's
"[PATCH v3] media: Media Device Allocator API", isn't it?

-- 
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

Re: Including images on Sphinx documents

[Mauro Carvalho Chehab]

Em Sun, 13 Nov 2016 12:52:50 -0700
Jonathan Corbet  escreveu:

> On Mon, 7 Nov 2016 07:55:24 -0200
> Mauro Carvalho Chehab  wrote:
> 
> > So, we have a few alternatives:
> > 
> > 1) copy (or symlink) all rst files to Documentation/output (or to the
> >build dir specified via O= directive) and generate the *.pdf there,
> >and produce those converted images via Makefile.;
> > 
> > 2) add an Sphinx extension that would internally call ImageMagick and/or
> >inkscape to convert the bitmap;
> > 
> > 3) if possible, add an extension to trick Sphinx for it to consider the 
> >output dir as a source dir too.  
> 
> So, obviously, I've been letting this go by while dealing with other
> stuff...
> 
> I really think that 2) is the one we want.  Copying all the stuff and
> operating on the copies, beyond being a bit of a hack, just seems like a
> recipe for weird build problems in the future.

Yes, (2) sounds to be the best option.

> We should figure out why PNG files don't work.  Maybe I'll give that a
> try at some point soon, if I can find a moment.  Working around tools
> bugs seems like the wrong approach.

I appreciate any efforts on that.

> Working from .svg seems optimial, but I don't like the --shell-escape
> thing at all.
> 
> [Along those lines, we've picked up a lot of lines like this:
> 
>restricted \write18 enabled.
> 
> That, too, is shell execution stuff.  I've not been able to figure out
> where it came from, but I would sure like to get rid of it...]

Didn't know that! I'm new to LaTeX. Frankly, the log output sounds
very scary to me, as there are lots of warnings there, and debugging
each of them takes time. I don't see any \write18 inside the generated
.tex files or inside the sphinx.sty file. Perhaps it comes from some
Tex extension, like adjustbox?

> 
> jon



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: [bug report] [media] dib0700_core: don't use stack on I2C reads

[Dan Carpenter]

Same for the legacy functions as well.

drivers/media/usb/dvb-usb/dib0700_core.c:338 dib0700_i2c_xfer_legacy() warn: 
inconsistent returns 'mutex:>i2c_mutex'.
  Locked on:   line 301
   line 322
  Unlocked on: line 287
   line 291
   line 338
drivers/media/usb/dvb-usb/dib0700_core.c:338 dib0700_i2c_xfer_legacy() warn: 
inconsistent returns 'mutex:>usb_mutex'.
  Locked on:   line 301
   line 322
  Unlocked on: line 287
   line 291
   line 338

regards,
dan carpenter

--
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: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Sakari Ailus]

Hi Mauro,

I'm replying below but let me first summarise the remaining problem area
that this patchset addresses.

The problems you and Shuah have seen and partially addressed are related to
a larger picture which is the lifetime of (mostly) memory resources related
to various objects used by as well both the Media controller and V4L2
frameworks (including videobuf2) as the drivers which make use of these
frameworks.

The Media controller and V4L2 interfaces exposed by drivers consist of
multiple devices nodes, data structures with interdependencies within the
frameworks themselves and dependencies from the driver's own data structures
towards the framework data structures. The Media device and the media graph
objects are central to the problem area as well.

So what are the issues then? Until now, we've attempted to regulate the
users' ability to access the devices at the time they're being unregistered
(and the associated memory released), but that approach does not really
scale: you have to make sure that the unregistering also will not take place
_during_ the system call --- not just in the beginning of it.

The media graph contains media graph objects, some of which are media
entities (contained in struct video_device or struct v4l2_subdev, for
instance). Media entities as graph nodes have links to other entities. In
order to implement the system calls, the drivers do parse this graph in
order to obtain information they need to obtain from it. For instance, it's
not uncommon for an implementation for video node format enumeration to
figure out which sub-device the link from that video nodes leads to. Drivers
may also have similar paths they follow.

Interrupt handling may also be taking place during the device removal during
which a number of data structures are now freed. This really does call for a
solution based on reference counting.

This leads to the conclusion that all the memory resources that could be
accessed by the drivers or the kernel frameworks must stay intact until the
last file handle to the said devices is closed. Otherwise, there is a
possibility of accessing released memory.

Right now in a lot of the cases, such as for video device and sub-device
nodes, we do release the memory when a device (as in struct device) is being
unregistered. There simply is in the current mainline kernel a way to do
this in a safe way. Drivers do use devm_() family of functions to allocate
the memory of the media graph object and their internal data structures.

With this patchset:

- The media_device which again contains the media_devnode is allocated
  dynamically. The lifetime of the media device --- and the media graph
  objects it contains --- is bound to device nodes that are bound to the
  media device (video and sub-device nodes) as well as open file handles.

- Care is taken that the unregistration process and releasing memory happens
  in the right order. This was not always the case previously.

- The driver remains responsible for the memory of the video and sub-device
  nodes. However, now the Media controller provides a convenient callback to
  the driver to release any memory resources when the time has come to do
  so. This takes place just before the media device memory is released.

- Drivers that do not strictly need to be removable require no changes. The
  benefits of this set become tangible for any driver by changing how the
  driver allocates memory for the data structures. Ideally at least
  drivers for hot-removable devices should be converted.

In order to make the current drivers to behave well it is necessary to make
changes to how memory is allocated in the drivers. If you look at the sample
patches that are part of the set for the omap3isp driver, you'll find that
around 95% of the changes are related to removing the user of devm_() family
of functions instead of Media controller API changes. In this regard, the
approach taken here requires very little if any additional overhead.

On Wed, Nov 09, 2016 at 03:46:08PM -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 9 Nov 2016 10:00:58 -0700
> Shuah Khan  escreveu:
> 
> > > Maybe we can get the Media Device Allocator API work in and then we can
> > > get your RFC series in after that. Here is what I propose:
> > > 
> > > - Keep the fixes in 4.9
> 
> Fixes should always be kept. Reverting a fix is not an option.
> Instead, do incremental patches on the top of it.
> 
> > > - Get Media Device Allocator API patches into 4.9.  
> > 
> > I meant 4.10 not 4.9
> > 
> > > - snd-usb-auido work go into 4.10
> 
> Sounds like a plan.
> 
> > > Then your RFC series could go in. I am looking at the RFC series and that
> > > the drivers need to change as well, so this RFC work could take longer.
> > > Since we have to make media_device sharable, it is necessary to have a
> > > global list approach Media Device Allocator API takes. So it is possible
> > > for your RFC series to go on top of the Media Device Allocator 

[PATCH] uvcvideo: Add bayer 16-bit format patterns

[Edgar Thier]

>From aec97c931cb4b91f91dd0ed38f74d866d4f13347 Mon Sep 17 00:00:00 2001
From: Edgar Thier 
Date: Mon, 14 Nov 2016 14:17:57 +0100
Subject: [PATCH] uvcvideo: Add bayer 16-bit format patterns

Add bayer 16-bit GUIDs to uvcvideo and associated them with the
corresponding V4L2 pixel formats.

Signed-off-by: Edgar Thier 
---
drivers/media/usb/uvc/uvc_driver.c   | 20 
drivers/media/usb/uvc/uvcvideo.h | 12 
drivers/media/v4l2-core/v4l2-ioctl.c |  4 
include/uapi/linux/videodev2.h   |  3 +++
4 files changed, 39 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 87b2fc3b..9d1fc33 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -168,6 +168,26 @@ static struct uvc_format_desc uvc_fmts[] = {
.guid   = UVC_GUID_FORMAT_RW10,
.fcc= V4L2_PIX_FMT_SRGGB10P,
},
+   {
+   .name   = "Bayer 16-bit (SBGGR16)",
+   .guid   = UVC_GUID_FORMAT_BG16,
+   .fcc= V4L2_PIX_FMT_SBGGR16,
+   },
+   {
+   .name   = "Bayer 16-bit (SGBRG16)",
+   .guid   = UVC_GUID_FORMAT_GB16,
+   .fcc= V4L2_PIX_FMT_SGBRG16,
+   },
+   {
+   .name   = "Bayer 16-bit (SRGGB16)",
+   .guid   = UVC_GUID_FORMAT_RG16,
+   .fcc= V4L2_PIX_FMT_SRGGB16,
+   },
+   {
+   .name   = "Bayer 16-bit (SGRBG16)",
+   .guid   = UVC_GUID_FORMAT_GR16,
+   .fcc= V4L2_PIX_FMT_SGRBG16,
+   },
};

/* 
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 7e4d3ee..3d6cc62 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -106,6 +106,18 @@
#define UVC_GUID_FORMAT_RGGB \
{ 'R',  'G',  'G',  'B', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_BG16 \
+   { 'B',  'G',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_GB16 \
+   { 'G',  'B',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_RG16 \
+   { 'R',  'G',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_GR16 \
+   { 'G',  'R',  '1',  '6', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
#define UVC_GUID_FORMAT_RGBP \
{ 'R',  'G',  'B',  'P', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 181381d..abbb6d5 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1179,6 +1179,10 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SGBRG12:  descr = "12-bit Bayer GBGB/RGRG"; break;
case V4L2_PIX_FMT_SGRBG12:  descr = "12-bit Bayer GRGR/BGBG"; break;
case V4L2_PIX_FMT_SRGGB12:  descr = "12-bit Bayer RGRG/GBGB"; break;
+   case V4L2_PIX_FMT_SGBRG16:  descr = "16-bit Bayer GBGB/RGRG"; break;
+   case V4L2_PIX_FMT_SGRBG16:  descr = "16-bit Bayer GRGR/BGBG"; break;
+   case V4L2_PIX_FMT_SRGGB16:  descr = "16-bit Bayer RGRG/GBGB"; break;
+   case V4L2_PIX_FMT_SBGGR16:  descr = "16-bit Bayer BGBG/GRGR"; break;
case V4L2_PIX_FMT_SBGGR10P: descr = "10-bit Bayer BGBG/GRGR Packed"; break;
case V4L2_PIX_FMT_SGBRG10P: descr = "10-bit Bayer GBGB/RGRG Packed"; break;
case V4L2_PIX_FMT_SGRBG10P: descr = "10-bit Bayer GRGR/BGBG Packed"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 4364ce6..6bdf592 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -605,6 +605,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12  GRGR.. 
BGBG.. */
#define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
GBGB.. */
#define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
GRGR.. */
+#define V4L2_PIX_FMT_SGBRG16 v4l2_fourcc('G', 'B', '1', '6') /* 16  GBGB.. 
RGRG.. */
+#define V4L2_PIX_FMT_SRGGB16 v4l2_fourcc('R', 'G', '1', '6') /* 16  RGRG.. 
GBGB.. */
+#define V4L2_PIX_FMT_SGRBG16 v4l2_fourcc('G', 'R', '1', '6') /* 16  GRGR.. 
BGBG.. */

/* HSV formats */
#define V4L2_PIX_FMT_HSV24 v4l2_fourcc('H', 'S', 'V', '3')
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org

[bug report] [media] dib0700_core: don't use stack on I2C reads

[Dan Carpenter]

Hello Mauro Carvalho Chehab,

The patch fa1ecd8dc454: "[media] dib0700_core: don't use stack on I2C
reads" from Oct 7, 2016, leads to the following static checker
warning:

drivers/media/usb/dvb-usb/dib0700_core.c:273 dib0700_i2c_xfer_new() warn: 
inconsistent returns 'mutex:>i2c_mutex'.
  Locked on:   line 224
   line 250
  Unlocked on: line 178
   line 237
   line 273
drivers/media/usb/dvb-usb/dib0700_core.c:273 dib0700_i2c_xfer_new() warn: 
inconsistent returns 'mutex:>usb_mutex'.
  Locked on:   line 250
  Unlocked on: line 178
   line 224
   line 237
   line 273

drivers/media/usb/dvb-usb/dib0700_core.c
   164  static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, struct 
i2c_msg *msg,
   165  int num)
   166  {
   167  /* The new i2c firmware messages are more reliable and in 
particular
   168 properly support i2c read calls not preceded by a write */
   169  
   170  struct dvb_usb_device *d = i2c_get_adapdata(adap);
   171  struct dib0700_state *st = d->priv;
   172  uint8_t bus_mode = 1;  /* 0=eeprom bus, 1=frontend bus */
   173  uint8_t gen_mode = 0; /* 0=master i2c, 1=gpio i2c */
   174  uint8_t en_start = 0;
   175  uint8_t en_stop = 0;
   176  int result, i;
   177  
   178  /* Ensure nobody else hits the i2c bus while we're sending our
   179 sequence of messages, (such as the remote control thread) */
   180  if (mutex_lock_interruptible(>i2c_mutex) < 0)
   181  return -EINTR;
   182  
   183  for (i = 0; i < num; i++) {
   184  if (i == 0) {
   185  /* First message in the transaction */
   186  en_start = 1;
   187  } else if (!(msg[i].flags & I2C_M_NOSTART)) {
   188  /* Device supports repeated-start */
   189  en_start = 1;
   190  } else {
   191  /* Not the first packet and device doesn't 
support
   192 repeated start */
   193  en_start = 0;
   194  }
   195  if (i == (num - 1)) {
   196  /* Last message in the transaction */
   197  en_stop = 1;
   198  }
   199  
   200  if (msg[i].flags & I2C_M_RD) {
   201  /* Read request */
   202  u16 index, value;
   203  uint8_t i2c_dest;
   204  
   205  i2c_dest = (msg[i].addr << 1);
   206  value = ((en_start << 7) | (en_stop << 6) |
   207   (msg[i].len & 0x3F)) << 8 | i2c_dest;
   208  /* I2C ctrl + FE bus; */
   209  index = ((gen_mode << 6) & 0xC0) |
   210  ((bus_mode << 4) & 0x30);
   211  
   212  result = usb_control_msg(d->udev,
   213   
usb_rcvctrlpipe(d->udev, 0),
   214   REQUEST_NEW_I2C_READ,
   215   USB_TYPE_VENDOR | 
USB_DIR_IN,
   216   value, index, st->buf,
   217   msg[i].len,
   218   USB_CTRL_GET_TIMEOUT);
   219  if (result < 0) {
   220  deb_info("i2c read error (status = 
%d)\n", result);
   221  break;
   222  }
   223  
   224  if (msg[i].len > sizeof(st->buf)) {
   225  deb_info("buffer too small to fit %d 
bytes\n",
   226   msg[i].len);
   227  return -EIO;

Unlock.  I would just fix this myself, but shouldn't we be returning
"i - 1" here anyway, to show mark that part transfered?

   228  }
   229  
   230  memcpy(msg[i].buf, st->buf, msg[i].len);
   231  
   232  deb_data("<<< ");
   233  debug_dump(msg[i].buf, msg[i].len, deb_data);
   234  
   235  } else {
   236  /* Write request */
   237  if (mutex_lock_interruptible(>usb_mutex) < 
0) {
   238  err("could not acquire lock");
   239  mutex_unlock(>i2c_mutex);
   240  return -EINTR;
   241  }
   242  st->buf[0] = 

Re: [PATCH 1/3] [media] dvb-usb: move data_mutex to struct dvb_usb_device

[Michael Ira Krufky]

On Sat, Nov 12, 2016 at 9:46 AM, Mauro Carvalho Chehab
 wrote:
> From: Mauro Carvalho Chehab 
>
> The data_mutex is initialized too late, as it is needed for
> each device driver's power control, causing an OOPS:
>
> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in 
> warm state.
> BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> IP: [] __mutex_lock_slowpath+0x6f/0x100 PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: dvb_usb_cinergyT2(+) dvb_usb
> CPU: 0 PID: 2029 Comm: modprobe Not tainted 4.9.0-rc4-dvbmod #24
> Hardware name: FUJITSU LIFEBOOK A544/FJNBB35 , BIOS Version 1.17 
> 05/09/2014
> task: 88020e943840 task.stack: 8801f36ec000
> RIP: 0010:[]  [] 
> __mutex_lock_slowpath+0x6f/0x100
> RSP: 0018:8801f36efb10  EFLAGS: 00010282
> RAX:  RBX: 88021509bdc8 RCX: c100
> RDX: 0001 RSI:  RDI: 88021509bdcc
> RBP: 8801f36efb58 R08: 88021f216320 R09: 0010
> R10: 88021f216320 R11: 0023fee6c5a1 R12: 88020e943840
> R13: 88021509bdcc R14:  R15: 88021509bdd0
> FS:  7f21adb86740() GS:88021f20() 
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 000215bce000 CR4: 001406f0
> Stack:
>  88021509bdd0   c0137c80
>  88021509bdc8 8801f5944000 0001 c0136b00
>  880213e52000 88021509bdc8 84661856 88021509bd80
> Call Trace:
>  [] ? mutex_lock+0x16/0x25
>  [] ? cinergyt2_power_ctrl+0x1f/0x60 
> [dvb_usb_cinergyT2]
>  [] ? dvb_usb_device_init+0x21e/0x5d0 [dvb_usb]
>  [] ? cinergyt2_usb_probe+0x21/0x50 
> [dvb_usb_cinergyT2]
>  [] ? usb_probe_interface+0xf3/0x2a0
>  [] ? driver_probe_device+0x208/0x2b0
>  [] ? __driver_attach+0x87/0x90
>  [] ? driver_probe_device+0x2b0/0x2b0
>  [] ? bus_for_each_dev+0x52/0x80
>  [] ? bus_add_driver+0x1a3/0x220
>  [] ? driver_register+0x56/0xd0
>  [] ? usb_register_driver+0x77/0x130
>  [] ? 0xc013a000
>  [] ? do_one_initcall+0x46/0x180
>  [] ? free_vmap_area_noflush+0x38/0x70
>  [] ? kmem_cache_alloc+0x84/0xc0
>  [] ? do_init_module+0x50/0x1be
>  [] ? load_module+0x1d8b/0x2100
>  [] ? find_symbol_in_section+0xa0/0xa0
>  [] ? SyS_finit_module+0x89/0x90
>  [] ? entry_SYSCALL_64_fastpath+0x13/0x94
> Code: e8 a7 1d 00 00 8b 03 83 f8 01 0f 84 97 00 00 00 48 8b 43 10 4c 
> 8d 7b 08 48 89 63 10 4c 89 3c 24 41 be ff ff ff ff 48 89 44 24 08 <48> 89 20 
> 4c 89 64 24 10 eb 1a 49 c7 44 24 08 02 00 00 00 c6 43 RIP  
> [] __mutex_lock_slowpath+0x6f/0x100 RSP 
> CR2: 
>
> So, move it to the struct dvb_usb_device and initialize it
> before calling the driver's callbacks.
>
> Reported-by: Jörg Otte 
> Tested-by: Jörg Otte 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/usb/dvb-usb/af9005.c | 33 
>  drivers/media/usb/dvb-usb/cinergyT2-core.c | 33 
>  drivers/media/usb/dvb-usb/cxusb.c  | 39 -
>  drivers/media/usb/dvb-usb/cxusb.h  |  1 -
>  drivers/media/usb/dvb-usb/dtt200u.c| 40 
> +-
>  drivers/media/usb/dvb-usb/dvb-usb-init.c   |  1 +
>  drivers/media/usb/dvb-usb/dvb-usb.h|  9 +--
>  7 files changed, 61 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb/af9005.c 
> b/drivers/media/usb/dvb-usb/af9005.c
> index b257780fb380..7853261906b1 100644
> --- a/drivers/media/usb/dvb-usb/af9005.c
> +++ b/drivers/media/usb/dvb-usb/af9005.c
> @@ -53,7 +53,6 @@ struct af9005_device_state {
> u8 sequence;
> int led_state;
> unsigned char data[256];
> -   struct mutex data_mutex;
>  };
>
>  static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
> @@ -72,7 +71,7 @@ static int af9005_generic_read_write(struct dvb_usb_device 
> *d, u16 reg,
> return -EINVAL;
> }
>
> -   mutex_lock(>data_mutex);
> +   mutex_lock(>data_mutex);
> st->data[0] = 14;   /* rest of buffer length low */
> st->data[1] = 0;/* rest of buffer length high */
>
> @@ -140,7 +139,7 @@ static int af9005_generic_read_write(struct 
> dvb_usb_device *d, u16 reg,
> values[i] = st->data[8 + i];
>
>  ret:
> -   mutex_unlock(>data_mutex);

Re: [PATCH v7 2/2] media: Add a driver for the ov5645 camera sensor.

[Todor Tomov]

Hi Laurent,

Thank you once again for the review.

On 11/14/2016 02:38 PM, Laurent Pinchart wrote:
> Hi Todor,
> 
> Thank you for the patch.
> 
> On Monday 14 Nov 2016 12:24:36 Todor Tomov wrote:
>> The ov5645 sensor from Omnivision supports up to 2592x1944
>> and CSI2 interface.
>>
>> The driver adds support for the following modes:
>> - 1280x960
>> - 1920x1080
>> - 2592x1944
>>
>> Output format is packed 8bit UYVY.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  drivers/media/i2c/Kconfig  |   12 +
>>  drivers/media/i2c/Makefile |1 +
>>  drivers/media/i2c/ov5645.c | 1352 +
>>  3 files changed, 1365 insertions(+)
>>  create mode 100644 drivers/media/i2c/ov5645.c
> 
> [snip]
> 
>> diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
>> new file mode 100644
>> index 000..2b33bc6
>> --- /dev/null
>> +++ b/drivers/media/i2c/ov5645.c
> 
> [snip]
> 
>> +static const struct ov5645_mode_info *
>> +ov5645_find_nearest_mode(unsigned int width, unsigned int height)
>> +{
>> +   unsigned int i;
>> +
>> +   for (i = ARRAY_SIZE(ov5645_mode_info_data) - 1; i >= 0; i--) {
>> +   if (ov5645_mode_info_data[i].width <= width &&
>> +   ov5645_mode_info_data[i].height <= height)
>> +   break;
>> +   }
>> +
>> +   if (i < 0)
> 
> i needs to be int for this condition to be true.

Oops, I'll fix this for the next version. Let's wait for other feedback too 
until then.

> 
> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
>> +   i = 0;
>> +
>> +   return _mode_info_data[i];
>> +}
> 

-- 
Best regards,
Todor Tomov
--
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 v7 2/2] media: Add a driver for the ov5645 camera sensor.

[Laurent Pinchart]

Hi Todor,

Thank you for the patch.

On Monday 14 Nov 2016 12:24:36 Todor Tomov wrote:
> The ov5645 sensor from Omnivision supports up to 2592x1944
> and CSI2 interface.
> 
> The driver adds support for the following modes:
> - 1280x960
> - 1920x1080
> - 2592x1944
> 
> Output format is packed 8bit UYVY.
> 
> Signed-off-by: Todor Tomov 
> ---
>  drivers/media/i2c/Kconfig  |   12 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov5645.c | 1352 +
>  3 files changed, 1365 insertions(+)
>  create mode 100644 drivers/media/i2c/ov5645.c

[snip]

> diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
> new file mode 100644
> index 000..2b33bc6
> --- /dev/null
> +++ b/drivers/media/i2c/ov5645.c

[snip]

> +static const struct ov5645_mode_info *
> +ov5645_find_nearest_mode(unsigned int width, unsigned int height)
> +{
> +   unsigned int i;
> +
> +   for (i = ARRAY_SIZE(ov5645_mode_info_data) - 1; i >= 0; i--) {
> +   if (ov5645_mode_info_data[i].width <= width &&
> +   ov5645_mode_info_data[i].height <= height)
> +   break;
> +   }
> +
> +   if (i < 0)

i needs to be int for this condition to be true.

Apart from that,

Reviewed-by: Laurent Pinchart 

> +   i = 0;
> +
> +   return _mode_info_data[i];
> +}

-- 
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 v7 1/2] media: i2c/ov5645: add the device tree binding document

[Laurent Pinchart]

Hi Todor,

Thank you for the patch.

On Monday 14 Nov 2016 12:24:35 Todor Tomov wrote:
> Add the document for ov5645 device tree binding.
> 
> Signed-off-by: Todor Tomov 

Reviewed-by: Laurent Pinchart 

> ---
>  .../devicetree/bindings/media/i2c/ov5645.txt   | 54 +++
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt
> b/Documentation/devicetree/bindings/media/i2c/ov5645.txt new file mode
> 100644
> index 000..fd7aec9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
> @@ -0,0 +1,54 @@
> +* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
> +
> +The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor
> with
> +an active array size of 2592H x 1944V. It is programmable through a serial
> I2C
> +interface.
> +
> +Required Properties:
> +- compatible: Value should be "ovti,ov5645".
> +- clocks: Reference to the xclk clock.
> +- clock-names: Should be "xclk".
> +- clock-frequency: Frequency of the xclk clock.
> +- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This
> corresponds
> +  to the hardware pin PWDNB which is physically active low.
> +- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW. This
> corresponds to
> +  the hardware pin RESETB.
> +- vdddo-supply: Chip digital IO regulator.
> +- vdda-supply: Chip analog regulator.
> +- vddd-supply: Chip digital core regulator.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> +  {
> + ...
> +
> + ov5645: ov5645@78 {
> + compatible = "ovti,ov5645";
> + reg = <0x78>;
> +
> + enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 20 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_rear_default>;
> +
> + clocks = < 200>;
> + clock-names = "xclk";
> + clock-frequency = <2388>;
> +
> + vdddo-supply = <_dovdd_1v8>;
> + vdda-supply = <_avdd_2v8>;
> + vddd-supply = <_dvdd_1v2>;
> +
> + port {
> + ov5645_ep: endpoint {
> + clock-lanes = <1>;
> + data-lanes = <0 2>;
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> + };

-- 
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 v6 2/2] media: Add a driver for the ov5645 camera sensor.

[Laurent Pinchart]

Hi Mark,

On Wednesday 26 Oct 2016 12:51:49 Mark Brown wrote:
> On Wed, Oct 26, 2016 at 02:27:23PM +0300, Todor Tomov wrote:
> > And using Mark Brown's correct address...
> 
> This is an *enormous* e-mail quoted to multiple levels with top posting
> and very little editing which makes it incredibly hard to find any
> relevant content.
> 
> > >> I believe it should be an API guarantee, otherwise many drivers using
> > >> the bulk API would break. Mark, could you please comment on that ?
> > > 
> > > Ok, let's wait for a response from Mark.
> 
> Why would this be guaranteed by the API given that it's not documented
> and why would many drivers break?  It's fairly rare for devices other
> than SoCs to have strict power on sequencing requirements as it is hard
> to achieve in practical systems.

I'm surprised, I've always considered the bulk regulator API as guaranteeing 
sequencing, and have written quite a few drivers with that assumption. If 
that's not correct then I'll have to switch them back to manual regulator 
handling.

Is there a reason why the API shouldn't guarantee that regulators are powered 
on in the order listed, and powered off in the reverse order ? Looking at the 
implementation that's already the case for regulator_bulk_disable(), but 
regulator_bulk_enable() uses async scheduling so doesn't guarantee ordering. I 
wonder whether a synchronous version of regulator_bulk_enable() would be 
useful.

-- 
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

[RFCv2 PATCH] tc358840: add Toshiba HDMI-to-CSI bridge driver

[Hans Verkuil]

Second RFC version.

This driver was created by Armin Weiss and cleaned up, rebased and 4k
and CEC support finalized by Hans Verkuil.

It's almost ready for mainlining. The main TODO is to clean up and document
the device tree bindings.

Signed-off-by: Armin Weiss 
Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/i2c/tc358840.txt |   50 +
 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   18 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/tc358840.c   | 2851 
 drivers/media/i2c/tc358840_regs.h  |  805 ++
 include/media/i2c/tc358840.h   |   91 +
 7 files changed, 3823 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tc358840.txt
 create mode 100644 drivers/media/i2c/tc358840.c
 create mode 100644 drivers/media/i2c/tc358840_regs.h
 create mode 100644 include/media/i2c/tc358840.h

diff --git a/Documentation/devicetree/bindings/media/i2c/tc358840.txt 
b/Documentation/devicetree/bindings/media/i2c/tc358840.txt
new file mode 100644
index 000..b2a2544
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tc358840.txt
@@ -0,0 +1,50 @@
+* Toshiba TC358840 HDMI-RX to MIPI CSI2-TX Bridge
+
+The Toshiba TC358840 HDMI-RX to MIPI CSI2-TX (H2C) is a bridge that converts
+a HDMI stream to MIPI CSI-2 TX. It is programmable through I2C.
+
+Required Properties:
+
+- compatible: value should be "toshiba,tc358840"
+- clocks, clock-names: should contain a phandle link to the reference clock
+  source, the clock input is named "refclk".
+
+Optional Properties:
+
+- reset-gpios: gpio phandle GPIO connected to the reset pin
+- interrupts, interrupt-parent: GPIO connected to the interrupt pin
+- data-lanes: should be <1 2 3 4> for four-lane operation,
+ or <1 2> for two-lane operation
+- clock-lanes: should be <0>
+- clock-noncontinuous: Presence of this boolean property decides whether the
+  MIPI CSI-2 clock is continuous or non-continuous.
+- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
+   expressed as a 64-bit big-endian integer. The frequency
+   is half of the bps per lane due to DDR transmission.
+- csi_port: which CSI ports can be used: 1 = TX0, 2 = TX1, 3 = TX0 + TX1.
+
+For further information on the MIPI CSI-2 endpoint node properties, see
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+   tc358840@0f {
+   compatible = "toshiba,tc358840";
+   reg = <0x0f>;
+   clocks = <_osc>;
+   clock-names = "refclk";
+   reset-gpios = < 9 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+   csi_port = <3>;
+
+   port {
+   tc358840_out: endpoint {
+   remote-endpoint = <_csi2_in>;
+   data-lanes = <1 2 3 4>;
+   clock-lanes = <0>;
+   clock-noncontinuous;
+   link-frequencies = /bits/ 64 <29700>;
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 93e9f42..40c54ef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12145,6 +12145,13 @@ S: Maintained
 F: drivers/media/i2c/tc358743*
 F: include/media/i2c/tc358743.h

+TOSHIBA TC358840 DRIVER
+M: Hans Verkuil 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/tc358840*
+F: include/media/i2c/tc358840.h
+
 TMIO/SDHI MMC DRIVER
 M: Wolfram Sang 
 L: linux-...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4b..404240d 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -330,6 +330,24 @@ config VIDEO_TC358743
  To compile this driver as a module, choose M here: the
  module will be called tc358743.

+config VIDEO_TC358840
+   tristate "Toshiba TC358840 decoder"
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   select HDMI
+   select MEDIA_CEC_EDID
+   ---help---
+ Support for the Toshiba TC358840 HDMI to MIPI CSI-2 bridge.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tc358840.
+
+config VIDEO_TC358840_CEC
+   bool "Enable Toshiba TC358840 CEC support"
+   depends on VIDEO_TC358840 && MEDIA_CEC
+   ---help---
+ When selected the tc358840 will support the optional
+ HDMI CEC feature.
+
 config VIDEO_TVP514X
tristate "Texas Instruments TVP514x video decoder"
depends on VIDEO_V4L2 && I2C

Re: [PATCH v4 7/8] v4l: Add signal lock status to source change events

[Hans Verkuil]

On 08/03/2016 08:03 PM, Steve Longerbeam wrote:
> Add a signal lock status change to the source changes bitmask.
> This indicates there was a signal lock or unlock event detected
> at the input of a video decoder.
> 
> Signed-off-by: Steve Longerbeam 
> Cc: Mauro Carvalho Chehab 
> 
> ---
> 
> v4:
> - converted to rst from DocBook
> 
> v3: no changes
> v2: no changes
> ---
>  Documentation/media/uapi/v4l/vidioc-dqevent.rst | 9 +
>  Documentation/media/videodev2.h.rst.exceptions  | 1 +
>  include/uapi/linux/videodev2.h  | 1 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
> b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> index 73c0d5b..7d8a053 100644
> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> @@ -564,6 +564,15 @@ call.
> an input. This can come from an input connector or from a video
> decoder.
>  
> +-  .. row 2
> +
> +   -  ``V4L2_EVENT_SRC_CH_LOCK_STATUS``
> +
> +   -  0x0002
> +
> +   -  This event gets triggered when there is a signal lock or
> +   unlock detected at the input of a video decoder.
> +
>  
>  Return Value
>  
> diff --git a/Documentation/media/videodev2.h.rst.exceptions 
> b/Documentation/media/videodev2.h.rst.exceptions
> index 9bb9a6c..f412cc8 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -453,6 +453,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS ctrl-changes-flags
>  replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
>  
>  replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
> +replace define V4L2_EVENT_SRC_CH_LOCK_STATUS src-changes-flags
>  
>  replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ v4l2-event-motion-det
>  
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 724f43e..08a153f 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2078,6 +2078,7 @@ struct v4l2_event_frame_sync {
>  };
>  
>  #define V4L2_EVENT_SRC_CH_RESOLUTION (1 << 0)
> +#define V4L2_EVENT_SRC_CH_LOCK_STATUS(1 << 1)
>  
>  struct v4l2_event_src_change {
>   __u32 changes;
> 

Quoting from an old (July) conversation about this:

>> > I'm not entirely sure I like this. Typically losing lock means that this 
>> > event
>> > is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and userspace 
>> > has
>> > to check the new timings etc., which will fail if there is no lock anymore.
>> >
>> > This information is also available through ENUMINPUT.
>> >
>> > I would need to know more about why you think this is needed, because I 
>> > don't
>> > see what this adds.
> 
> Hi Hans,
> 
> At least on the ADV718x, a source resolution change (from an 
> autodetected video
> standard change) and a signal lock status change are distinct events. 
> For example
> there can be a temporary loss of input signal lock without a change in 
> detected
> input video standard/resolution.

OK, but what can the application do with that event? If the glitch didn't
affect the video, then it is pointless.

If the lock is lost, then normally you loose video as well. If not, then
applications are not interested in the event.

So I am not convinced...

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 v4 3/8] media: adv7180: add support for NEWAVMODE

[Hans Verkuil]

On 08/03/2016 08:03 PM, Steve Longerbeam wrote:
> Parse the optional v4l2 endpoint DT node. If the bus type is
> V4L2_MBUS_BT656 and the endpoint node specifies "newavmode",
> configure the BT.656 bus in NEWAVMODE.
> 
> Signed-off-by: Steve Longerbeam 
> 
> ---
> 
> v4: no changes
> v3:
> - the newavmode endpoint property is now private to adv7180.
> ---
>  .../devicetree/bindings/media/i2c/adv7180.txt  |  4 ++
>  drivers/media/i2c/adv7180.c| 46 
> --
>  2 files changed, 47 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt 
> b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
> index 0d50115..6c175d2 100644
> --- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
> @@ -15,6 +15,10 @@ Required Properties :
>   "adi,adv7282"
>   "adi,adv7282-m"
>  
> +Optional Endpoint Properties :
> +- newavmode: a boolean property to indicate the BT.656 bus is operating
> +  in Analog Device's NEWAVMODE. Valid for BT.656 busses only.

This is too vague.

Based on the ADV7280/ADV7281/ADV7282/ADV7283 Hardware Reference Manual I
would say something like this:

- newavmode: a boolean property to indicate the BT.656 bus is operating
  in Analog Device's NEWAVMODE. Valid for BT.656 busses only. When enabled
  the generated EAV/SAV codes are suitable for Analog Devices encoders.
  Otherwise these codes are setup according to 
  See bit 4 of user sub map register 0x31 in the Hardware Reference Manual.

I may have asked this before, but do you actually have hardware that needs
this? If so, it may be useful to give it as an example and explain why it
is needed.

If not, then I wonder if this cannot be dropped until we DO see hardware
that needs it.

Regards,

Hans


> +
>  Example:
>  
>   i2c0@1c22000 {
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 6e093c22..467953e 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -106,6 +107,7 @@
>  #define ADV7180_REG_SHAP_FILTER_CTL_10x0017
>  #define ADV7180_REG_CTRL_2   0x001d
>  #define ADV7180_REG_VSYNC_FIELD_CTL_10x0031
> +#define ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE 0x02
>  #define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
>  #define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
>  #define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
> @@ -214,6 +216,7 @@ struct adv7180_state {
>   struct mutexmutex; /* mutual excl. when accessing chip */
>   int irq;
>   v4l2_std_id curr_norm;
> + boolnewavmode;
>   boolpowered;
>   boolstreaming;
>   u8  input;
> @@ -864,9 +867,15 @@ static int adv7180_init(struct adv7180_state *state)
>   if (ret < 0)
>   return ret;
>  
> - /* Manually set V bit end position in NTSC mode */
> - return adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
> - ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
> + if (!state->newavmode) {
> + /* Manually set V bit end position in NTSC mode */
> + ret = adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
> + ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
>  }
>  
>  static int adv7180_set_std(struct adv7180_state *state, unsigned int std)
> @@ -1217,6 +1226,13 @@ static int init_device(struct adv7180_state *state)
>   if (ret)
>   goto out_unlock;
>  
> + if (state->newavmode) {
> + ret = adv7180_write(state, ADV7180_REG_VSYNC_FIELD_CTL_1,
> + ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE);
> + if (ret < 0)
> + goto out_unlock;
> + }
> +
>   ret = adv7180_program_std(state);
>   if (ret)
>   goto out_unlock;
> @@ -1257,6 +1273,28 @@ out_unlock:
>   return ret;
>  }
>  
> +static void adv7180_of_parse(struct adv7180_state *state)
> +{
> + struct i2c_client *client = state->client;
> + struct device_node *np = client->dev.of_node;
> + struct device_node *endpoint;
> + struct v4l2_of_endpoint ep;
> +
> + endpoint = of_graph_get_next_endpoint(np, NULL);
> + if (!endpoint) {
> + v4l_warn(client, "endpoint node not found\n");
> + return;
> + }
> +
> + v4l2_of_parse_endpoint(endpoint, );
> + if (ep.bus_type == V4L2_MBUS_BT656) {
> + if (of_property_read_bool(endpoint, "newavmode"))
> + state->newavmode = true;
> + }
> +
> + of_node_put(endpoint);
> +}
> +
>  static int 

Re: [PATCH v4 1/8] media: adv7180: fix field type

[Hans Verkuil]

On 08/03/2016 08:03 PM, Steve Longerbeam wrote:
> From: Steve Longerbeam 
> 
> The ADV7180 and ADV7182 transmit whole fields, bottom field followed
> by top (or vice-versa, depending on detected video standard). So
> for chips that do not have support for explicitly setting the field
> mode via I2P, set the field mode to V4L2_FIELD_ALTERNATE.
> 
> Signed-off-by: Steve Longerbeam 
> Signed-off-by: Niklas Söderlund 
> 
> ---
> 
> v4:
> - switch V4L2_FIELD_SEQ_TB/V4L2_FIELD_SEQ_BT to V4L2_FIELD_ALTERNATE.
>   This is from Niklas Söderlund.
> - remove checks for ADV7180_FLAG_I2P when setting field mode, since I2P
>   support is planned to be removed.
> - move init of state->curr_norm back to its original location, since
>   state->field init is no longer dependent on state->curr_norm.
> 
> v3: no changes
> 
> v2:
> - the init of state->curr_norm in probe needs to be moved up, ahead
>   of the init of state->field.
> ---
>  drivers/media/i2c/adv7180.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 95cbc85..192eeae 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -679,10 +679,10 @@ static int adv7180_set_pad_format(struct v4l2_subdev 
> *sd,
>   switch (format->format.field) {
>   case V4L2_FIELD_NONE:
>   if (!(state->chip_info->flags & ADV7180_FLAG_I2P))
> - format->format.field = V4L2_FIELD_INTERLACED;
> + format->format.field = V4L2_FIELD_ALTERNATE;
>   break;

I'd change this to:

if (state->chip_info->flags & ADV7180_FLAG_I2P)
break;
/* fall through */

>   default:
> - format->format.field = V4L2_FIELD_INTERLACED;
> + format->format.field = V4L2_FIELD_ALTERNATE;
>   break;
>   }
>  
> @@ -1251,7 +1251,7 @@ static int adv7180_probe(struct i2c_client *client,
>   return -ENOMEM;
>  
>   state->client = client;
> - state->field = V4L2_FIELD_INTERLACED;
> + state->field = V4L2_FIELD_ALTERNATE;
>   state->chip_info = (struct adv7180_chip_info *)id->driver_data;
>  
>   if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
> 

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 v4 5/8] media: adv7180: implement g_parm

[Hans Verkuil]

On 08/03/2016 08:03 PM, Steve Longerbeam wrote:
> Implement g_parm to return the current standard's frame period.
> 
> Signed-off-by: Steve Longerbeam 
> Tested-by: Tim Harvey 
> Acked-by: Tim Harvey 
> 
> ---
> v4: no changes
> v3: no changes
> v2: no changes
> ---
>  drivers/media/i2c/adv7180.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index b2df181..9705e24 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -764,6 +764,27 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
>   return 0;
>  }
>  
> +static int adv7180_g_parm(struct v4l2_subdev *sd, struct v4l2_streamparm *a)
> +{
> + struct adv7180_state *state = to_state(sd);
> + struct v4l2_captureparm *cparm = >parm.capture;
> +
> + if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + return -EINVAL;
> +
> + memset(a, 0, sizeof(*a));
> + a->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;

Don't memset this, it is the responsibility of the caller to do that,
not of the subdev.

The caller may have set other fields in the struct that the memset would
wipe out.

Regards,

Hans

> + if (state->curr_norm & V4L2_STD_525_60) {
> + cparm->timeperframe.numerator = 1001;
> + cparm->timeperframe.denominator = 3;
> + } else {
> + cparm->timeperframe.numerator = 1;
> + cparm->timeperframe.denominator = 25;
> + }
> +
> + return 0;
> +}
> +
>  static int adv7180_cropcap(struct v4l2_subdev *sd, struct v4l2_cropcap 
> *cropcap)
>  {
>   struct adv7180_state *state = to_state(sd);
> @@ -822,6 +843,7 @@ static int adv7180_subscribe_event(struct v4l2_subdev *sd,
>  static const struct v4l2_subdev_video_ops adv7180_video_ops = {
>   .s_std = adv7180_s_std,
>   .g_std = adv7180_g_std,
> + .g_parm = adv7180_g_parm,
>   .querystd = adv7180_querystd,
>   .g_input_status = adv7180_g_input_status,
>   .s_routing = adv7180_s_routing,
> 
--
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 v7 1/2] media: i2c/ov5645: add the device tree binding document

[Todor Tomov]

Add the document for ov5645 device tree binding.

Signed-off-by: Todor Tomov 
---
 .../devicetree/bindings/media/i2c/ov5645.txt   | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
new file mode 100644
index 000..fd7aec9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
@@ -0,0 +1,54 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1944V. It is programmable through a serial I2C
+interface.
+
+Required Properties:
+- compatible: Value should be "ovti,ov5645".
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- clock-frequency: Frequency of the xclk clock.
+- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This 
corresponds
+  to the hardware pin PWDNB which is physically active low.
+- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW. This corresponds 
to
+  the hardware pin RESETB.
+- vdddo-supply: Chip digital IO regulator.
+- vdda-supply: Chip analog regulator.
+- vddd-supply: Chip digital core regulator.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+   ...
+
+   ov5645: ov5645@78 {
+   compatible = "ovti,ov5645";
+   reg = <0x78>;
+
+   enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rear_default>;
+
+   clocks = < 200>;
+   clock-names = "xclk";
+   clock-frequency = <2388>;
+
+   vdddo-supply = <_dovdd_1v8>;
+   vdda-supply = <_avdd_2v8>;
+   vddd-supply = <_dvdd_1v2>;
+
+   port {
+   ov5645_ep: endpoint {
+   clock-lanes = <1>;
+   data-lanes = <0 2>;
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+   };
-- 
1.9.1

--
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 v3 5/9] media: venus: venc: add video encoder files

[Stanimir Varbanov]

Hi Hans,

Thanks for the comments!

On 11/11/2016 01:43 PM, Hans Verkuil wrote:
> The comments I made before about start_streaming and the use of struct 
> venus_ctrl
> apply here as well and I won't repeat them.
> 
> On 11/07/2016 06:33 PM, Stanimir Varbanov wrote:
>> This adds encoder part of the driver plus encoder controls.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/media/platform/qcom/venus/venc.c   | 1212 
>> 
>>  drivers/media/platform/qcom/venus/venc.h   |   32 +
>>  drivers/media/platform/qcom/venus/venc_ctrls.c |  396 
>>  3 files changed, 1640 insertions(+)
>>  create mode 100644 drivers/media/platform/qcom/venus/venc.c
>>  create mode 100644 drivers/media/platform/qcom/venus/venc.h
>>  create mode 100644 drivers/media/platform/qcom/venus/venc_ctrls.c
>>
>> diff --git a/drivers/media/platform/qcom/venus/venc.c 
>> b/drivers/media/platform/qcom/venus/venc.c
>> new file mode 100644
>> index ..35572eaffb9e
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/venus/venc.c
> 
> 
> 
>> +static int
>> +venc_s_selection(struct file *file, void *fh, struct v4l2_selection *s)
>> +{
>> +struct venus_inst *inst = to_inst(file);
>> +
>> +if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
>> +return -EINVAL;
>> +
>> +switch (s->target) {
>> +case V4L2_SEL_TGT_CROP:
>> +if (s->r.width != inst->out_width ||
>> +s->r.height != inst->out_height ||
>> +s->r.top != 0 || s->r.left != 0)
>> +return -EINVAL;
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
> 
> Why implement s_selection if I can't change the selection?

without s_selection the v4l2-compliance test starts failing with:

fail: v4l2-test-formats.cpp(1319): doioctl(node, VIDIOC_S_SELECTION,
_crop) != EINVAL

fail: v4l2-test-formats.cpp(1407): testBasicCrop(node,
V4L2_BUF_TYPE_VIDEO_OUTPUT)

> 
>> +
>> +static int
>> +venc_reqbufs(struct file *file, void *fh, struct v4l2_requestbuffers *b)
>> +{
>> +struct vb2_queue *queue = to_vb2q(file, b->type);
>> +
>> +if (!queue)
>> +return -EINVAL;
>> +
>> +return vb2_reqbufs(queue, b);
>> +}
> 
> Use the m2m helpers if at all possible.

I've answered already to that in 4/9.

-- 
regards,
Stan
--
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 04/12 v2] exynos-gsc: Make PM callbacks available conditionally

[Marek Szyprowski]

From: Ulf Hansson 

There are no need to set up the PM callbacks (runtime and system) unless
they are being used. It also causes compiler warnings about unused
functions.

Silence the warnings by making them available for CONFIG_PM (runtime
callbacks) and CONFIG_PM_SLEEP (system sleep callbacks).

Signed-off-by: Ulf Hansson 
[mszyprow: squashed two patches into one to avoid potential build break,
changed patch subject and updated commit message]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 84 ++--
 1 file changed, 43 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index b5a99af6d049..e75474f3f7f2 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -988,43 +988,6 @@ static void *gsc_get_drv_data(struct platform_device *pdev)
return driver_data;
 }
 
-static int gsc_m2m_suspend(struct gsc_dev *gsc)
-{
-   unsigned long flags;
-   int timeout;
-
-   spin_lock_irqsave(>slock, flags);
-   if (!gsc_m2m_pending(gsc)) {
-   spin_unlock_irqrestore(>slock, flags);
-   return 0;
-   }
-   clear_bit(ST_M2M_SUSPENDED, >state);
-   set_bit(ST_M2M_SUSPENDING, >state);
-   spin_unlock_irqrestore(>slock, flags);
-
-   timeout = wait_event_timeout(gsc->irq_queue,
-test_bit(ST_M2M_SUSPENDED, >state),
-GSC_SHUTDOWN_TIMEOUT);
-
-   clear_bit(ST_M2M_SUSPENDING, >state);
-   return timeout == 0 ? -EAGAIN : 0;
-}
-
-static void gsc_m2m_resume(struct gsc_dev *gsc)
-{
-   struct gsc_ctx *ctx;
-   unsigned long flags;
-
-   spin_lock_irqsave(>slock, flags);
-   /* Clear for full H/W setup in first run after resume */
-   ctx = gsc->m2m.ctx;
-   gsc->m2m.ctx = NULL;
-   spin_unlock_irqrestore(>slock, flags);
-
-   if (test_and_clear_bit(ST_M2M_SUSPENDED, >state))
-   gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
-}
-
 static int gsc_probe(struct platform_device *pdev)
 {
struct gsc_dev *gsc;
@@ -1130,6 +1093,44 @@ static int gsc_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int gsc_m2m_suspend(struct gsc_dev *gsc)
+{
+   unsigned long flags;
+   int timeout;
+
+   spin_lock_irqsave(>slock, flags);
+   if (!gsc_m2m_pending(gsc)) {
+   spin_unlock_irqrestore(>slock, flags);
+   return 0;
+   }
+   clear_bit(ST_M2M_SUSPENDED, >state);
+   set_bit(ST_M2M_SUSPENDING, >state);
+   spin_unlock_irqrestore(>slock, flags);
+
+   timeout = wait_event_timeout(gsc->irq_queue,
+test_bit(ST_M2M_SUSPENDED, >state),
+GSC_SHUTDOWN_TIMEOUT);
+
+   clear_bit(ST_M2M_SUSPENDING, >state);
+   return timeout == 0 ? -EAGAIN : 0;
+}
+
+static void gsc_m2m_resume(struct gsc_dev *gsc)
+{
+   struct gsc_ctx *ctx;
+   unsigned long flags;
+
+   spin_lock_irqsave(>slock, flags);
+   /* Clear for full H/W setup in first run after resume */
+   ctx = gsc->m2m.ctx;
+   gsc->m2m.ctx = NULL;
+   spin_unlock_irqrestore(>slock, flags);
+
+   if (test_and_clear_bit(ST_M2M_SUSPENDED, >state))
+   gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
 static int gsc_runtime_resume(struct device *dev)
 {
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1160,7 +1161,9 @@ static int gsc_runtime_suspend(struct device *dev)
pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
return ret;
 }
+#endif
 
+#ifdef CONFIG_PM_SLEEP
 static int gsc_resume(struct device *dev)
 {
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1197,12 +1200,11 @@ static int gsc_suspend(struct device *dev)
 
return 0;
 }
+#endif
 
 static const struct dev_pm_ops gsc_pm_ops = {
-   .suspend= gsc_suspend,
-   .resume = gsc_resume,
-   .runtime_suspend= gsc_runtime_suspend,
-   .runtime_resume = gsc_runtime_resume,
+   SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
+   SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
 };
 
 static struct platform_driver gsc_driver = {
-- 
1.9.1

--
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: [RFC 07/10] sunxi-cedrus: Add a MPEG 2 codec

[Hans Verkuil]

On 11/14/2016 11:18 AM, Hans Verkuil wrote:
> On 08/25/2016 11:39 AM, Florent Revest wrote:
>> This patch introduces the support of MPEG2 video decoding to the
>> sunxi-cedrus video decoder driver.
>>
>> Signed-off-by: Florent Revest 
>> ---
>>  drivers/media/platform/sunxi-cedrus/Makefile   |   2 +-
>>  drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c |  26 +++-
>>  .../platform/sunxi-cedrus/sunxi_cedrus_common.h|   2 +
>>  .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.c |  15 +-
>>  .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.c  |  17 ++-
>>  .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.h  |   4 +
>>  .../platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c | 152 
>> +
>>  7 files changed, 211 insertions(+), 7 deletions(-)
>>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c
>>
>> diff --git a/drivers/media/platform/sunxi-cedrus/Makefile 
>> b/drivers/media/platform/sunxi-cedrus/Makefile
>> index 14c2f7a..2d495a2 100644
>> --- a/drivers/media/platform/sunxi-cedrus/Makefile
>> +++ b/drivers/media/platform/sunxi-cedrus/Makefile
>> @@ -1,2 +1,2 @@
>>  obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi_cedrus.o sunxi_cedrus_hw.o \
>> -sunxi_cedrus_dec.o
>> +sunxi_cedrus_dec.o sunxi_cedrus_mpeg2.o
>> diff --git a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c 
>> b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
>> index 17af34c..d1c957a 100644
>> --- a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
>> +++ b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
>> @@ -46,14 +46,31 @@ static int sunxi_cedrus_s_ctrl(struct v4l2_ctrl *ctrl)
>>  struct sunxi_cedrus_ctx *ctx =
>>  container_of(ctrl->handler, struct sunxi_cedrus_ctx, hdl);
>>  
>> -v4l2_err(>dev->v4l2_dev, "Invalid control\n");
>> -return -EINVAL;
>> +switch (ctrl->id) {
>> +case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
>> +/* This is kept in memory and used directly. */
>> +break;
>> +default:
>> +v4l2_err(>dev->v4l2_dev, "Invalid control\n");
> 
> Drop this, it's pointless since this cannot happen, and even if it could, 
> there
> is nothing wrong about userspace passing an unknown control, that should just 
> result in
> -EINVAL.
> 

Just to be clear: 'this' == the v4l2_err call.

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

[PATCH v7 2/2] media: Add a driver for the ov5645 camera sensor.

[Todor Tomov]

The ov5645 sensor from Omnivision supports up to 2592x1944
and CSI2 interface.

The driver adds support for the following modes:
- 1280x960
- 1920x1080
- 2592x1944

Output format is packed 8bit UYVY.

Signed-off-by: Todor Tomov 
---
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5645.c | 1352 
 3 files changed, 1365 insertions(+)
 create mode 100644 drivers/media/i2c/ov5645.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4b..1d7df6e 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -531,6 +531,18 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV5645
+   tristate "OmniVision OV5645 sensor support"
+   depends on OF
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5645 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5645.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2..09a5d24 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
 obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
new file mode 100644
index 000..2b33bc6
--- /dev/null
+++ b/drivers/media/i2c/ov5645.c
@@ -0,0 +1,1352 @@
+/*
+ * Driver for the OV5645 camera sensor.
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015 By Tech Design S.L. All Rights Reserved.
+ * Copyright (C) 2012-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Based on:
+ * - the OV5645 driver from QC msm-3.10 kernel on codeaurora.org:
+ *   https://us.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/
+ *   media/platform/msm/camera_v2/sensor/ov5645.c?h=LA.BR.1.2.4_rb1.41
+ * - the OV5640 driver posted on linux-media:
+ *   https://www.mail-archive.com/linux-media%40vger.kernel.org/msg92671.html
+ */
+
+/*
+ * 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.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV5645_VOLTAGE_ANALOG   280
+#define OV5645_VOLTAGE_DIGITAL_CORE 150
+#define OV5645_VOLTAGE_DIGITAL_IO   180
+
+#define OV5645_SYSTEM_CTRL00x3008
+#defineOV5645_SYSTEM_CTRL0_START   0x02
+#defineOV5645_SYSTEM_CTRL0_STOP0x42
+#define OV5645_CHIP_ID_HIGH0x300a
+#defineOV5645_CHIP_ID_HIGH_BYTE0x56
+#define OV5645_CHIP_ID_LOW 0x300b
+#defineOV5645_CHIP_ID_LOW_BYTE 0x45
+#define OV5645_AWB_MANUAL_CONTROL  0x3406
+#defineOV5645_AWB_MANUAL_ENABLEBIT(0)
+#define OV5645_AEC_PK_MANUAL   0x3503
+#defineOV5645_AEC_MANUAL_ENABLEBIT(0)
+#defineOV5645_AGC_MANUAL_ENABLEBIT(1)
+#define OV5645_TIMING_TC_REG20 0x3820
+#defineOV5645_SENSOR_VFLIP BIT(1)
+#defineOV5645_ISP_VFLIPBIT(2)
+#define OV5645_TIMING_TC_REG21 0x3821
+#defineOV5645_SENSOR_MIRRORBIT(1)
+#define OV5645_PRE_ISP_TEST_SETTING_1  0x503d
+#defineOV5645_TEST_PATTERN_MASK0x3
+#defineOV5645_SET_TEST_PATTERN(x)  ((x) & 
OV5645_TEST_PATTERN_MASK)
+#defineOV5645_TEST_PATTERN_ENABLE  BIT(7)
+#define OV5645_SDE_SAT_U   0x5583
+#define OV5645_SDE_SAT_V   0x5584
+
+struct reg_value {
+   u16 reg;
+   u8 val;
+};
+
+struct ov5645_mode_info {
+   u32 width;
+   u32 height;
+   const struct reg_value 

[PATCH v7 0/2] OV5645 camera sensor driver

[Todor Tomov]

This is the seventh version of the OV5645 camera sensor driver patchset.

Changes since version 6 include:
- keep a pointer to the current sensor mode and remove enum ov5645_mode;
- do not keep v4l2 control values and xclk frequency in the main data struct;
- add caching variables in then main data struct for some of the register values
  to avoid i2c read commands;
- use reference counting for power state;
- enable xclk only after regulators are enabled;
- add check for xclk rate that it is supported;
- register v4l2 subdev only at the end of probe when the rest is succeeded;
- add hardware pin names in gpio descriptions in the dt binding document;
- other minor changes: uppercase to lowercase, add const modifier, remove
  unnecessary local variables, fix return values.

Changes since version 5 include:
- external clock frequency set in DT;
- added v4l2_subdev_pad_ops.init_cfg function to initialize formats;
- current sensor mode not updated if set_fmt is TRY (not ACTIVE);
- other small changes - debug messages removed, register addresses defines
  renamed, redundant safety checks removed, unnecessary labels removed,
  mutex_destroy added.

Two one-line changes since version 4:
- return current format on set_format;
- return all frame sizes when enumerating them.

Only one change since version 3:
- build failure on kernel v4.7-rc1 fixed:
  s/media_entity_init/media_entity_pads_init/

Changes from version 2 include:
- external camera clock configuration is moved from DT to driver;
- pwdn-gpios renamed to enable-gpios;
- switched polarity of reset-gpios to the more intuitive active low;
- added Kconfig dependency to OF;
- return values checks;
- regulators and gpios are now required (not optional);
- regulators names renamed;
- power counter variable changed to a bool power state;
- ov5645_registered() is removed and sensor id reading moved to probe().

Changes from version 1 include:
- patch split to dt binding doc patch and driver patch;
- changes in power on/off logic - s_power is now not called on
  open/close;
- using assigned-clock-rates in dt for setting camera external
  clock rate;
- correct api for gpio handling;
- return values checks;
- style fixes.

Todor Tomov (2):
  media: i2c/ov5645: add the device tree binding document
  media: Add a driver for the ov5645 camera sensor.

 .../devicetree/bindings/media/i2c/ov5645.txt   |   54 +
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5645.c | 1354 
 4 files changed, 1421 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt
 create mode 100644 drivers/media/i2c/ov5645.c

-- 
1.9.1

--
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 v3 3/9] media: venus: adding core part and helper functions

[Hans Verkuil]

On 11/14/2016 11:11 AM, Stanimir Varbanov wrote:
> Hi Hans,
> 
> 
> 

> +void vidc_vb2_stop_streaming(struct vb2_queue *q)
> +{
> + struct venus_inst *inst = vb2_get_drv_priv(q);
> + struct venus_core *core = inst->core;
> + struct device *dev = core->dev;
> + struct vb2_queue *other_queue;
> + struct vidc_buffer *buf, *n;
> + enum vb2_buffer_state state;
> + int ret;
> +
> + if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> + other_queue = >bufq_cap;
> + else
> + other_queue = >bufq_out;
> +
> + if (!vb2_is_streaming(other_queue))
> + return;

 This seems wrong to me: this return means that the buffers of queue q are 
 never
 released. Either drop this 'if' or release both queues when the last queue
 stops streaming. I think dropping the 'if' is best.
>>>
>>> I have done this way because hfi_session_stop must be called only once,
>>> and buffers will be released on first streamoff for both queues.
>>
>> Are you sure the buffers are released for both queues? I may have missed 
>> that when
>> reviewing.
> 
> yes, hfi_session_stop will instruct the firmware to stop using provided
> buffers and return ownership to the host driver by fill_buf_done and
> empty_buf_done callbacks.
> 
>>
>> I would recommend to call hfi_session_stop when the first stop_streaming is 
>> called,
>> not when it is called for both queues. I say this because stopping streaming 
>> without
>> releasing the buffers is likely to cause problems.
> 
> this is what I tried to implement with above
> !vb2_is_streaming(other_queue) thing.

That doesn't work: if the application calls STREAMON(CAPTURE) followed by 
STREAMOFF(CAPTURE)
without ever starting the OUTPUT queue, this will not clean up the capture 
queue.

Regards,

Hans

> 
>>
>> Did you turn on CONFIG_VIDEO_ADV_DEBUG? If it is on, and you don't release 
>> buffers
>> then I think you will see warnings in the kernel log.
> 
> OK I will enable it to be sure that warnings are missing.
> 
--
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: [RFC 07/10] sunxi-cedrus: Add a MPEG 2 codec

[Hans Verkuil]

On 08/25/2016 11:39 AM, Florent Revest wrote:
> This patch introduces the support of MPEG2 video decoding to the
> sunxi-cedrus video decoder driver.
> 
> Signed-off-by: Florent Revest 
> ---
>  drivers/media/platform/sunxi-cedrus/Makefile   |   2 +-
>  drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c |  26 +++-
>  .../platform/sunxi-cedrus/sunxi_cedrus_common.h|   2 +
>  .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.c |  15 +-
>  .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.c  |  17 ++-
>  .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.h  |   4 +
>  .../platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c | 152 
> +
>  7 files changed, 211 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c
> 
> diff --git a/drivers/media/platform/sunxi-cedrus/Makefile 
> b/drivers/media/platform/sunxi-cedrus/Makefile
> index 14c2f7a..2d495a2 100644
> --- a/drivers/media/platform/sunxi-cedrus/Makefile
> +++ b/drivers/media/platform/sunxi-cedrus/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi_cedrus.o sunxi_cedrus_hw.o \
> - sunxi_cedrus_dec.o
> + sunxi_cedrus_dec.o sunxi_cedrus_mpeg2.o
> diff --git a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c 
> b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> index 17af34c..d1c957a 100644
> --- a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> +++ b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> @@ -46,14 +46,31 @@ static int sunxi_cedrus_s_ctrl(struct v4l2_ctrl *ctrl)
>   struct sunxi_cedrus_ctx *ctx =
>   container_of(ctrl->handler, struct sunxi_cedrus_ctx, hdl);
>  
> - v4l2_err(>dev->v4l2_dev, "Invalid control\n");
> - return -EINVAL;
> + switch (ctrl->id) {
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> + /* This is kept in memory and used directly. */
> + break;
> + default:
> + v4l2_err(>dev->v4l2_dev, "Invalid control\n");

Drop this, it's pointless since this cannot happen, and even if it could, there
is nothing wrong about userspace passing an unknown control, that should just 
result in
-EINVAL.

> + return -EINVAL;
> + }
> +
> + return 0;
>  }
>  
>  static const struct v4l2_ctrl_ops sunxi_cedrus_ctrl_ops = {
>   .s_ctrl = sunxi_cedrus_s_ctrl,
>  };
>  
> +static const struct v4l2_ctrl_config sunxi_cedrus_ctrl_mpeg2_frame_hdr = {
> + .ops = _cedrus_ctrl_ops,
> + .id = V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR,
> + .type = V4L2_CTRL_TYPE_PRIVATE,
> + .name = "MPEG2 Frame Header Parameters",
> + .max_reqs = VIDEO_MAX_FRAME,
> + .elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr),
> +};
> +

I understand that this is not yet finalized. In any case, what should happen is
that we have standard compound controls for the MPEG2 and MPEG4 headers that are
based on the MPEG-2 and MPEG-4 standards. Any HW specific information should be
done through driver-specific controls.

I am not sure if V4L2_CTRL_TYPE_PRIVATE is the way to go for private compound
controls, but it may not be needed at all once these MPEG controls are 
standardized.

>  /*
>   * File operations
>   */
> @@ -78,6 +95,10 @@ static int sunxi_cedrus_open(struct file *file)
>   hdl = >hdl;
>   v4l2_ctrl_handler_init(hdl, 1);
>  
> + ctx->mpeg2_frame_hdr_ctrl = v4l2_ctrl_new_custom(hdl,
> + _cedrus_ctrl_mpeg2_frame_hdr, NULL);
> + ctx->mpeg2_frame_hdr_ctrl->flags |= V4L2_CTRL_FLAG_REQ_KEEP;
> +
>   if (hdl->error) {
>   rc = hdl->error;
>   v4l2_ctrl_handler_free(hdl);
> @@ -117,6 +138,7 @@ static int sunxi_cedrus_release(struct file *file)
>   v4l2_fh_del(>fh);
>   v4l2_fh_exit(>fh);
>   v4l2_ctrl_handler_free(>hdl);
> + ctx->mpeg2_frame_hdr_ctrl = NULL;
>   mutex_lock(>dev_mutex);
>   v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
>   mutex_unlock(>dev_mutex);
> diff --git a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_common.h 
> b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_common.h
> index 6b8d87a..e715184 100644
> --- a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_common.h
> +++ b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_common.h
> @@ -70,6 +70,8 @@ struct sunxi_cedrus_ctx {
>   struct v4l2_ctrl_handler hdl;
>  
>   struct vb2_buffer *dst_bufs[VIDEO_MAX_FRAME];
> +
> + struct v4l2_ctrl *mpeg2_frame_hdr_ctrl;
>  };
>  
>  static inline void sunxi_cedrus_write(struct sunxi_cedrus_dev *vpu,
> diff --git a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.c 
> b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.c
> index 71ef34b..38e8a3a 100644
> --- a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.c
> +++ b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.c
> @@ -48,6 +48,11 @@ static struct sunxi_cedrus_fmt formats[] = {
>   

Re: [RFC 06/10] media: platform: Add Sunxi Cedrus decoder driver

[Hans Verkuil]

On 08/25/2016 11:39 AM, Florent Revest wrote:
> This patch adds a "sunxi-cedrus" v4l2 m2m decoder driver for
> Allwinner's Video Processing Unit. This VPU has a low-level interface
> which requires manual registers writing for frame headers. Hence, it
> depends on the Request API to synchronize buffers with controls.
> 
> Most of the reverse engineering on which I based my work comes from the
> "Cedrus" project: http://linux-sunxi.org/Cedrus
> 
> The driver currently only runs on the A13 and this patch doesn't
> include any codec.
> 
> Signed-off-by: Florent Revest 
> ---
>  drivers/media/platform/Kconfig |  13 +
>  drivers/media/platform/Makefile|   1 +
>  drivers/media/platform/sunxi-cedrus/Makefile   |   2 +
>  drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c | 248 ++
>  .../platform/sunxi-cedrus/sunxi_cedrus_common.h|  86 
>  .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.c | 544 
> +
>  .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.h |  33 ++
>  .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.c  | 153 ++
>  .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.h  |  32 ++
>  .../platform/sunxi-cedrus/sunxi_cedrus_regs.h  | 170 +++
>  10 files changed, 1282 insertions(+)
>  create mode 100644 drivers/media/platform/sunxi-cedrus/Makefile
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_common.h
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.c
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.h
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_hw.c
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_hw.h
>  create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_regs.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index f25344b..92c92d3 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -315,6 +315,19 @@ config VIDEO_TI_VPE
> Support for the TI VPE(Video Processing Engine) block
> found on DRA7XX SoC.
>  
> +config VIDEO_SUNXI_CEDRUS
> + tristate "Sunxi CEDRUS VPU driver"
> + depends on VIDEO_DEV && VIDEO_V4L2
> + depends on ARCH_SUNXI
> + depends on HAS_DMA
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + ---help---
> +   Support for the VPU video codec found on Sunxi SoC.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called sunxi-cedrus.
> +
>  config VIDEO_TI_VPE_DEBUG
>   bool "VPE debug messages"
>   depends on VIDEO_TI_VPE
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 21771c1..1419749 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_VIDEO_RENESAS_VSP1)+= vsp1/
>  obj-y+= omap/
>  
>  obj-$(CONFIG_VIDEO_AM437X_VPFE)  += am437x/
> +obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus/
>  
>  obj-$(CONFIG_VIDEO_XILINX)   += xilinx/
>  
> diff --git a/drivers/media/platform/sunxi-cedrus/Makefile 
> b/drivers/media/platform/sunxi-cedrus/Makefile
> new file mode 100644
> index 000..14c2f7a
> --- /dev/null
> +++ b/drivers/media/platform/sunxi-cedrus/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi_cedrus.o sunxi_cedrus_hw.o \
> + sunxi_cedrus_dec.o
> diff --git a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c 
> b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> new file mode 100644
> index 000..17af34c
> --- /dev/null
> +++ b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> @@ -0,0 +1,248 @@
> +/*
> + * Sunxi Cedrus codec driver
> + *
> + * Copyright (C) 2016 Florent Revest
> + * Florent Revest 
> + *
> + * Based on vim2m
> + *
> + * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
> + * Pawel Osciak, 
> + * Marek Szyprowski, 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "sunxi_cedrus_common.h"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sunxi_cedrus_dec.h"
> +#include 

Re: [PATCH v3 3/9] media: venus: adding core part and helper functions

[Stanimir Varbanov]

Hi Hans,



>>>
 +void vidc_vb2_stop_streaming(struct vb2_queue *q)
 +{
 +  struct venus_inst *inst = vb2_get_drv_priv(q);
 +  struct venus_core *core = inst->core;
 +  struct device *dev = core->dev;
 +  struct vb2_queue *other_queue;
 +  struct vidc_buffer *buf, *n;
 +  enum vb2_buffer_state state;
 +  int ret;
 +
 +  if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
 +  other_queue = >bufq_cap;
 +  else
 +  other_queue = >bufq_out;
 +
 +  if (!vb2_is_streaming(other_queue))
 +  return;
>>>
>>> This seems wrong to me: this return means that the buffers of queue q are 
>>> never
>>> released. Either drop this 'if' or release both queues when the last queue
>>> stops streaming. I think dropping the 'if' is best.
>>
>> I have done this way because hfi_session_stop must be called only once,
>> and buffers will be released on first streamoff for both queues.
> 
> Are you sure the buffers are released for both queues? I may have missed that 
> when
> reviewing.

yes, hfi_session_stop will instruct the firmware to stop using provided
buffers and return ownership to the host driver by fill_buf_done and
empty_buf_done callbacks.

> 
> I would recommend to call hfi_session_stop when the first stop_streaming is 
> called,
> not when it is called for both queues. I say this because stopping streaming 
> without
> releasing the buffers is likely to cause problems.

this is what I tried to implement with above
!vb2_is_streaming(other_queue) thing.

> 
> Did you turn on CONFIG_VIDEO_ADV_DEBUG? If it is on, and you don't release 
> buffers
> then I think you will see warnings in the kernel log.

OK I will enable it to be sure that warnings are missing.

-- 
regards,
Stan
--
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 v3 4/9] media: venus: vdec: add video decoder files

[Stanimir Varbanov]

Hi Hans,

Thanks for the comments!

On 11/11/2016 01:39 PM, Hans Verkuil wrote:
> I made some comments about start_streaming in my review of patch 3/9, so
> I am not going to repeat that here.

Sure.

> 
> On 11/07/2016 06:33 PM, Stanimir Varbanov wrote:
>> This consists of video decoder implementation plus decoder
>> controls.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/media/platform/qcom/venus/vdec.c   | 1108 
>> 
>>  drivers/media/platform/qcom/venus/vdec.h   |   32 +
>>  drivers/media/platform/qcom/venus/vdec_ctrls.c |  197 +
>>  3 files changed, 1337 insertions(+)
>>  create mode 100644 drivers/media/platform/qcom/venus/vdec.c
>>  create mode 100644 drivers/media/platform/qcom/venus/vdec.h
>>  create mode 100644 drivers/media/platform/qcom/venus/vdec_ctrls.c
>>
>> diff --git a/drivers/media/platform/qcom/venus/vdec.c 
>> b/drivers/media/platform/qcom/venus/vdec.c
>> new file mode 100644
>> index ..3f0eba7e31dc
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/venus/vdec.c
> 
> 
> 
>> +static int
>> +vdec_s_selection(struct file *file, void *fh, struct v4l2_selection *s)
>> +{
>> +struct venus_inst *inst = to_inst(file);
>> +
>> +if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE &&
>> +s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
>> +return -EINVAL;
>> +
>> +switch (s->target) {
>> +case V4L2_SEL_TGT_CROP_BOUNDS:
>> +case V4L2_SEL_TGT_CROP_DEFAULT:
>> +case V4L2_SEL_TGT_CROP:
>> +return -EINVAL;
>> +case V4L2_SEL_TGT_COMPOSE_BOUNDS:
>> +case V4L2_SEL_TGT_COMPOSE_DEFAULT:
>> +case V4L2_SEL_TGT_COMPOSE_PADDED:
>> +return -EINVAL;
>> +case V4L2_SEL_TGT_COMPOSE:
>> +if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>> +return -EINVAL;
>> +s->r.width = inst->out_width;
>> +s->r.height = inst->out_height;
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>> +
>> +s->r.top = 0;
>> +s->r.left = 0;
>> +
>> +return 0;
>> +}
> 
> This can be simplified to just:
> 
>   if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
>   s->target != V4L2_SEL_TGT_COMPOSE)
>   return -EINVAL;
> 
>   // handle the remaining capture compose case

OK I will rewrite it.

> 
>> +
>> +static int
>> +vdec_reqbufs(struct file *file, void *fh, struct v4l2_requestbuffers *b)
>> +{
>> +struct vb2_queue *queue = to_vb2q(file, b->type);
>> +
>> +if (!queue)
>> +return -EINVAL;
>> +
>> +return vb2_reqbufs(queue, b);
>> +}
> 
> Is there any reason why the v4l2_m2m_ioctl_reqbufs et al helper functions
> can't be used? I strongly recommend that, unless there is a specific reason
> why that won't work.

So that means I need to completely rewrite the v4l2 part and adopt it
for mem2mem device APIs.

If that is what you meant I can invest some time to make a estimation
what would be the changes and time needed. After that we can decide what
to do - take the driver as is and port it to mem2mem device APIs later
on or wait for the this transition to happen before merging.

-- 
regards,
Stan
--
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: [RFC 03/10] v4l: Add sunxi Video Engine pixel format

[Hans Verkuil]

On 08/25/2016 11:39 AM, Florent Revest wrote:
> Add support for the allwinner's proprietary pixel format described in
> details here: http://linux-sunxi.org/File:Ve_tile_format_v1.pdf
> 
> This format is similar to V4L2_PIX_FMT_NV12M but the planes are divided
> in tiles of 32x32px.
> 
> Signed-off-by: Florent Revest 
> ---
>  include/uapi/linux/videodev2.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 904c44c..96e034d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -627,6 +627,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_Y8I  v4l2_fourcc('Y', '8', 'I', ' ') /* Greyscale 
> 8-bit L/R interleaved */
>  #define V4L2_PIX_FMT_Y12I v4l2_fourcc('Y', '1', '2', 'I') /* Greyscale 
> 12-bit L/R interleaved */
>  #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 
> 16-bit */
> +#define V4L2_PIX_FMT_SUNXIv4l2_fourcc('S', 'X', 'I', 'Y') /* Sunxi VE's 
> 32x32 tiled NV12 */

This is very similar to V4L2_PIX_FMT_NV12MT_16X16. I think it can be added as
V4L2_PIX_FMT_NV12MT_32X32.

This needs to be documented in the V4L2 spec as well, of course.

Regards,

Hans

>  
>  /* SDR formats - used only for Software Defined Radio devices */
>  #define V4L2_SDR_FMT_CU8  v4l2_fourcc('C', 'U', '0', '8') /* IQ u8 */
> 
--
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: [Intel-gfx] [PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

[Chris Wilson]

On Fri, Nov 11, 2016 at 08:50:17AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Scatterlist entries have an unsigned int for the offset so
> correct the sg_alloc_table_from_pages function accordingly.
> 
> Since these are offsets withing a page, unsigned int is
> wide enough.
> 
> Also converts callers which were using unsigned long locally
> with the lower_32_bits annotation to make it explicitly
> clear what is happening.
> 
> v2: Use offset_in_page. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Masahiro Yamada 
> Cc: Pawel Osciak 
> Cc: Marek Szyprowski 
> Cc: Kyungmin Park 
> Cc: Tomasz Stanislawski 
> Cc: Matt Porter 
> Cc: Alexandre Bounine 
> Cc: linux-media@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Acked-by: Marek Szyprowski  (v1)

If there were kerneldoc, it would nicely explain that having an offset
larger then a page is silly when passing in array of pages.

Changes elsewhere look ok (personally I'd be happy with just
offset_in_page(), 4GiB superpages are somebody else's problem :)

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
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: [RFC] V4L2 unified low-level decoder API

[Hans Verkuil]

On 10/27/2016 09:42 AM, Hugues FRUCHET wrote:
> Hi,
> 
> This RFC aims to start discussions in order to define the codec specific 
> controls structures to fulfill the low-level decoder API needed by non 
> "Stream API" based decoders ("stateless" or "Frame API" based decoders).

Let's refer to this as 'stateful' decoders and 'stateless' decoders. This
is the preferred terminology (and much more descriptive than 'Stream' vs
'Frame'). It's also not really a new API, although it does rely on the
Request API.

> Several implementation exists now which runs on several SoC and various 
> software frameworks.
> The idea is to find the communalities between all those implementations 
> and SoC to define a single unified interface in V4L2 includes.
> Even if "Request API" is needed to pass those codec specific controls 
> from userspace down to kernel on a per-buffer basis, we can start 
> discussions and define the controls in parallel of its development.
> We can even propose some implementations based on existing V4L2 control 
> framework (which doesn't support "per-frame" basis) by ensuring 
> atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]). Constraint 
> can then be relaxed when "Request API" is merged.
> 
> I would like to propose to work on a "per-codec" basis, having at least 
> 2 different SoC and 2 different frameworks to test and validate controls.
> To do so, I have tried to identify some people that have worked on this 
> subject and have proposed some implementations, feel free to correct me 
> and enhance the list if needed:
> * MPEG2/MPEG4
> - Florent Revest for Allwinner A13 CedarX support [1] tested with 
> VLC -> libVA + sunxi-cedrus-drv-video -> V4L2
> - Myself for STMicroelectronics Delta support [2] tested with 
> GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2
> 
> * VP8
> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested with 
> Chromium -> V4L2
> - Jung Zhao for Rockchip RK3288 VPU support [4]  framework used>
> 
> * H264
> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested with 
> Chromium -> V4L2
> - Randy Li for Rockchip RK3288  VPU support [6] tested with VLC? -> 
> libVA + rockchip-va-driver -> V4L2
> VLC? -> libVDPAU + rockchip-va-driver -> V4L2
> 
> I can work to define MPEG2/MPEG4 controls and propose functional 
> implementations for those codecs, and will be glad to co-work with you 
> Florent.
> I can help on H264 on a code review basis based on the functional H264 
> setup I have in-house and codec knowledge, but I cannot provide 
> implementation in a reasonable timeframe, same for VP8.
> 
> Apart of very details of each codec, we have also to state about generic 
> concerns such as:
> - new pixel format introduction (VP8 => VP8F, H264 => S264, MPG2 => 
> MG2F, MPG4 => MG4F)
> - new device caps to indicate that driver requires extra headers ? maybe 
> not needed because redundant with new pixel format

That's indeed typically signaled through the pixelformat.

> - continue to modify v4l2-controls.h ? or do we add some new specific 
> header files (H264 is huge!) ?
> - how to manage sequence header & picture header, optional/extended 
> controls (MPEG2 sequence/picture extensions, H264 SEI, ...). Personally 
> I have added flags inside a single control structure, H264 is done in a 
> different way using several controls (SPS/PPS/SLICE/DECODE/...)
> 
> Thanks you to all of you for your attention and feel free to react on 
> this topic if you are interested to work on this subject.

As long as the V4L2 driver underpins the various solutions I am happy :-)

I do think that having a libv4l plugin will be useful since it will make
it easy for applications that support the stateful decoder to use the
same code for a stateless decoder by seamlessly using the plugin.

This does not prevent other approaches at the same time, of course.

Regards,

Hans

> 
> Best regards,
> Hugues.
> 
> [0] [ANN] Codec & Request API Brainstorm meeting Oct 10 & 
> 11https://www.spinics.net/lists/linux-media/msg106699.html
> [1] MPEG2 A13 CedarXhttp://www.spinics.net/lists/linux-media/msg104823.html
> [1] MPEG4 A13 CedarXhttp://www.spinics.net/lists/linux-media/msg104817.html
> [2] MPEG2 STi4xx 
> Deltahttp://www.spinics.net/lists/linux-media/msg106240.html
> [2] MPEG4 STi4xx Delta is also supported but not yet pushed
> [3] VP8 Rockchip RK3288, RK3399? 
> VPUhttps://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-kernel/linux-headers/files/0002-CHROMIUM-v4l-Add-VP8-low-level-decoder-API-controls.patch
>  
> [4] VP8 Rockchip RK3288 
> VPUhttp://www.spinics.net/lists/linux-media/msg97997.html
> [5] H264 Rockchip RK3288, RK3399? 
> VPUhttps://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-kernel/linux-headers/files/0001-CHROMIUM-media-headers-Import-V4L2-headers-from-Chro.patch
> [6] H264 Rockchip RK3288 
> 

Re: [PATCH v3 3/9] media: venus: adding core part and helper functions

[Hans Verkuil]

On 11/14/2016 10:42 AM, Stanimir Varbanov wrote:
> Hi Hans,
> 
> Thanks for the comments!
> 
> On 11/11/2016 01:32 PM, Hans Verkuil wrote:
>> Hi Stanimir,
>>
>> Some comments:
>>
>> On 11/07/2016 06:33 PM, Stanimir Varbanov wrote:
>>>  * core.c has implemented the platform dirver methods, file
>>> operations and v4l2 registration.
>>>
>>>  * helpers.c has implemented common helper functions for:
>>>- buffer management
>>>
>>>- vb2_ops and functions for format propagation,
>>>
>>>- functions for allocating and freeing buffers for
>>>internal usage. The buffer parameters describing internal
>>>buffers depends on current format, resolution and codec.
>>>
>>>- functions for calculation of current load of the
>>>hardware. Depending on the count of instances and
>>>resolutions it selects the best clock rate for the video
>>>core.
>>>
>>> Signed-off-by: Stanimir Varbanov 
>>> ---
>>>  drivers/media/platform/qcom/venus/core.c| 557 +
>>>  drivers/media/platform/qcom/venus/core.h| 261 
>>>  drivers/media/platform/qcom/venus/helpers.c | 612 
>>> 
>>>  drivers/media/platform/qcom/venus/helpers.h |  43 ++
>>>  4 files changed, 1473 insertions(+)
>>>  create mode 100644 drivers/media/platform/qcom/venus/core.c
>>>  create mode 100644 drivers/media/platform/qcom/venus/core.h
>>>  create mode 100644 drivers/media/platform/qcom/venus/helpers.c
>>>  create mode 100644 drivers/media/platform/qcom/venus/helpers.h
>>>
>>
>> 
>>
>>> diff --git a/drivers/media/platform/qcom/venus/core.h 
>>> b/drivers/media/platform/qcom/venus/core.h
>>> new file mode 100644
>>> index ..21ed053aeb17
>>> --- /dev/null
>>> +++ b/drivers/media/platform/qcom/venus/core.h
>>
>> 
>>
>>> +struct venus_ctrl {
>>> +   u32 id;
>>> +   enum v4l2_ctrl_type type;
>>> +   s32 min;
>>> +   s32 max;
>>> +   s32 def;
>>> +   u32 step;
>>> +   u64 menu_skip_mask;
>>> +   u32 flags;
>>> +   const char * const *qmenu;
>>> +};
>>
>> Why duplicate struct v4l2_ctrl_config? Just use that struct to define custom 
>> controls
>> together with v4l2_ctrl_new_custom().
> 
> OK, I will rework the controls to avoid struct v4l2_ctrl_config duplication.
> 
>>
>>> +
>>> +/*
>>> + * Offset base for buffers on the destination queue - used to distinguish
>>> + * between source and destination buffers when mmapping - they receive the 
>>> same
>>> + * offsets but for different queues
>>> + */
>>> +#define DST_QUEUE_OFF_BASE (1 << 30)
>>> +
>>> +static inline struct venus_inst *to_inst(struct file *filp)
>>> +{
>>> +   return container_of(filp->private_data, struct venus_inst, fh);
>>> +}
>>> +
>>> +static inline void *to_hfi_priv(struct venus_core *core)
>>> +{
>>> +   return core->priv;
>>> +}
>>> +
>>> +static inline struct vb2_queue *
>>> +to_vb2q(struct file *file, enum v4l2_buf_type type)
>>> +{
>>> +   struct venus_inst *inst = to_inst(file);
>>> +
>>> +   if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
>>> +   return >bufq_cap;
>>> +   else if (type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
>>> +   return >bufq_out;
>>> +
>>> +   return NULL;
>>> +}
>>> +
>>> +#endif
>>> diff --git a/drivers/media/platform/qcom/venus/helpers.c 
>>> b/drivers/media/platform/qcom/venus/helpers.c
>>> new file mode 100644
>>> index ..c2d1446ad254
>>> --- /dev/null
>>> +++ b/drivers/media/platform/qcom/venus/helpers.c
>>
>> 
>>
>>> +void vidc_vb2_stop_streaming(struct vb2_queue *q)
>>> +{
>>> +   struct venus_inst *inst = vb2_get_drv_priv(q);
>>> +   struct venus_core *core = inst->core;
>>> +   struct device *dev = core->dev;
>>> +   struct vb2_queue *other_queue;
>>> +   struct vidc_buffer *buf, *n;
>>> +   enum vb2_buffer_state state;
>>> +   int ret;
>>> +
>>> +   if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
>>> +   other_queue = >bufq_cap;
>>> +   else
>>> +   other_queue = >bufq_out;
>>> +
>>> +   if (!vb2_is_streaming(other_queue))
>>> +   return;
>>
>> This seems wrong to me: this return means that the buffers of queue q are 
>> never
>> released. Either drop this 'if' or release both queues when the last queue
>> stops streaming. I think dropping the 'if' is best.
> 
> I have done this way because hfi_session_stop must be called only once,
> and buffers will be released on first streamoff for both queues.

Are you sure the buffers are released for both queues? I may have missed that 
when
reviewing.

I would recommend to call hfi_session_stop when the first stop_streaming is 
called,
not when it is called for both queues. I say this because stopping streaming 
without
releasing the buffers is likely to cause problems.

Did you turn on CONFIG_VIDEO_ADV_DEBUG? If it is on, and you don't release 
buffers
then I think you will see warnings in the kernel log.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to 

Re: [PATCH v3 3/9] media: venus: adding core part and helper functions

[Stanimir Varbanov]

Hi Hans,

Thanks for the comments!

On 11/11/2016 01:32 PM, Hans Verkuil wrote:
> Hi Stanimir,
> 
> Some comments:
> 
> On 11/07/2016 06:33 PM, Stanimir Varbanov wrote:
>>  * core.c has implemented the platform dirver methods, file
>> operations and v4l2 registration.
>>
>>  * helpers.c has implemented common helper functions for:
>>- buffer management
>>
>>- vb2_ops and functions for format propagation,
>>
>>- functions for allocating and freeing buffers for
>>internal usage. The buffer parameters describing internal
>>buffers depends on current format, resolution and codec.
>>
>>- functions for calculation of current load of the
>>hardware. Depending on the count of instances and
>>resolutions it selects the best clock rate for the video
>>core.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/media/platform/qcom/venus/core.c| 557 +
>>  drivers/media/platform/qcom/venus/core.h| 261 
>>  drivers/media/platform/qcom/venus/helpers.c | 612 
>> 
>>  drivers/media/platform/qcom/venus/helpers.h |  43 ++
>>  4 files changed, 1473 insertions(+)
>>  create mode 100644 drivers/media/platform/qcom/venus/core.c
>>  create mode 100644 drivers/media/platform/qcom/venus/core.h
>>  create mode 100644 drivers/media/platform/qcom/venus/helpers.c
>>  create mode 100644 drivers/media/platform/qcom/venus/helpers.h
>>
> 
> 
> 
>> diff --git a/drivers/media/platform/qcom/venus/core.h 
>> b/drivers/media/platform/qcom/venus/core.h
>> new file mode 100644
>> index ..21ed053aeb17
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/venus/core.h
> 
> 
> 
>> +struct venus_ctrl {
>> +u32 id;
>> +enum v4l2_ctrl_type type;
>> +s32 min;
>> +s32 max;
>> +s32 def;
>> +u32 step;
>> +u64 menu_skip_mask;
>> +u32 flags;
>> +const char * const *qmenu;
>> +};
> 
> Why duplicate struct v4l2_ctrl_config? Just use that struct to define custom 
> controls
> together with v4l2_ctrl_new_custom().

OK, I will rework the controls to avoid struct v4l2_ctrl_config duplication.

> 
>> +
>> +/*
>> + * Offset base for buffers on the destination queue - used to distinguish
>> + * between source and destination buffers when mmapping - they receive the 
>> same
>> + * offsets but for different queues
>> + */
>> +#define DST_QUEUE_OFF_BASE  (1 << 30)
>> +
>> +static inline struct venus_inst *to_inst(struct file *filp)
>> +{
>> +return container_of(filp->private_data, struct venus_inst, fh);
>> +}
>> +
>> +static inline void *to_hfi_priv(struct venus_core *core)
>> +{
>> +return core->priv;
>> +}
>> +
>> +static inline struct vb2_queue *
>> +to_vb2q(struct file *file, enum v4l2_buf_type type)
>> +{
>> +struct venus_inst *inst = to_inst(file);
>> +
>> +if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
>> +return >bufq_cap;
>> +else if (type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
>> +return >bufq_out;
>> +
>> +return NULL;
>> +}
>> +
>> +#endif
>> diff --git a/drivers/media/platform/qcom/venus/helpers.c 
>> b/drivers/media/platform/qcom/venus/helpers.c
>> new file mode 100644
>> index ..c2d1446ad254
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/venus/helpers.c
> 
> 
> 
>> +void vidc_vb2_stop_streaming(struct vb2_queue *q)
>> +{
>> +struct venus_inst *inst = vb2_get_drv_priv(q);
>> +struct venus_core *core = inst->core;
>> +struct device *dev = core->dev;
>> +struct vb2_queue *other_queue;
>> +struct vidc_buffer *buf, *n;
>> +enum vb2_buffer_state state;
>> +int ret;
>> +
>> +if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
>> +other_queue = >bufq_cap;
>> +else
>> +other_queue = >bufq_out;
>> +
>> +if (!vb2_is_streaming(other_queue))
>> +return;
> 
> This seems wrong to me: this return means that the buffers of queue q are 
> never
> released. Either drop this 'if' or release both queues when the last queue
> stops streaming. I think dropping the 'if' is best.

I have done this way because hfi_session_stop must be called only once,
and buffers will be released on first streamoff for both queues.

> 
>> +
>> +ret = hfi_session_stop(inst);
>> +if (ret) {
>> +dev_err(dev, "session: stop failed (%d)\n", ret);
>> +goto abort;
>> +}
>> +
>> +ret = hfi_session_unload_res(inst);
>> +if (ret) {
>> +dev_err(dev, "session: release resources failed (%d)\n", ret);
>> +goto abort;
>> +}
>> +
>> +ret = session_unregister_bufs(inst);
>> +if (ret) {
>> +dev_err(dev, "failed to release capture buffers: %d\n", ret);
>> +goto abort;
>> +}
>> +
>> +ret = intbufs_free(inst);
>> +
>> +if (inst->state == INST_INVALID || core->state == CORE_INVALID)
>> +ret = -EINVAL;
>> +
>> +abort:
>> +if (ret)
>> +

Re: [PATCH] usb: core: urb make use of usb_endpoint_maxp_mult

[Felipe Balbi]

Hi,

Greg KH  writes:
> On Sun, Nov 13, 2016 at 01:31:16PM +0300, Mike Krinkin wrote:
>> Since usb_endpoint_maxp now returns only lower 11 bits mult
>> calculation here isn't correct anymore and that breaks webcam
>> for me. Patch make use of usb_endpoint_maxp_mult instead of
>> direct calculation.
>> 
>> Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return
>>only packet size")
>> 
>> Signed-off-by: Mike Krinkin 
>> ---
>>  drivers/usb/core/urb.c | 7 ++-
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
>> index 0be49a1..d75cb8c 100644
>> --- a/drivers/usb/core/urb.c
>> +++ b/drivers/usb/core/urb.c
>> @@ -412,11 +412,8 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>>  }
>>  
>>  /* "high bandwidth" mode, 1-3 packets/uframe? */
>> -if (dev->speed == USB_SPEED_HIGH) {
>> -int mult = 1 + ((max >> 11) & 0x03);
>> -max &= 0x07ff;
>> -max *= mult;
>> -}
>> +if (dev->speed == USB_SPEED_HIGH)
>> +max *= usb_endpoint_maxp_mult(>desc);
>>  
>>  if (urb->number_of_packets <= 0)
>>  return -EINVAL;
>
> Felipe, this looks like it belongs in your tree...

Right, I've queued it up :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: core: urb make use of usb_endpoint_maxp_mult

[Greg KH]

On Sun, Nov 13, 2016 at 01:31:16PM +0300, Mike Krinkin wrote:
> Since usb_endpoint_maxp now returns only lower 11 bits mult
> calculation here isn't correct anymore and that breaks webcam
> for me. Patch make use of usb_endpoint_maxp_mult instead of
> direct calculation.
> 
> Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return
>only packet size")
> 
> Signed-off-by: Mike Krinkin 
> ---
>  drivers/usb/core/urb.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> index 0be49a1..d75cb8c 100644
> --- a/drivers/usb/core/urb.c
> +++ b/drivers/usb/core/urb.c
> @@ -412,11 +412,8 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>   }
>  
>   /* "high bandwidth" mode, 1-3 packets/uframe? */
> - if (dev->speed == USB_SPEED_HIGH) {
> - int mult = 1 + ((max >> 11) & 0x03);
> - max &= 0x07ff;
> - max *= mult;
> - }
> + if (dev->speed == USB_SPEED_HIGH)
> + max *= usb_endpoint_maxp_mult(>desc);
>  
>   if (urb->number_of_packets <= 0)
>   return -EINVAL;

Felipe, this looks like it belongs in your tree...
--
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: [PATCHv4] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 driver

[Geert Uytterhoeven]

On Sat, Nov 12, 2016 at 1:29 PM, Niklas Söderlund
 wrote:
> +Example:
> +
> +/* SoC properties */
> +
> +csi20: csi2@fea8 {
> +compatible = "renesas,r8a7795-csi2";

7795

> +reg = <0 0xfea8 0 0x1>;
> +interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> +clocks = < CPG_MOD 714>;
> +power-domains = < R8A7796_PD_ALWAYS_ON>;

7796

You'd better match the SoC part numbers ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [RFC PATCH 6/7] atmel-isi: remove dependency of the soc-camera framework

[Wu, Songjun]

On 11/14/2016 16:19, Hans Verkuil wrote:

Hi Songjun,

On 10/19/2016 09:48 AM, Wu, Songjun wrote:



On 10/19/2016 15:46, Hans Verkuil wrote:

On 10/19/2016 09:36 AM, Wu, Songjun wrote:



On 10/18/2016 18:58, Hans Verkuil wrote:

On 10/18/16 11:21, Wu, Songjun wrote:

Hi Hans,

Do you have any issue on this patch?


ENOTIME :-(


Could I give you some help? :)


I would certainly help if you can make the requested change to this patch.

Let me know if you want to do that, because in that case I'll rebase my
tree
to the latest media_tree master.


Yes, I would like to make the requested change to this patch. :)
It seems the patch is not based on the latest media_tree master.
Will you rebase this patch to the latest media_tree, or let me move it
and make the requested change based on the media_tree?


I've rebased my branch:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=sama5d3-2


Thank you very much.
I will make the requested change based on your branch.


Did you make any progress on this? I plan on finalizing the atmel-isi driver
next week.

I checked the code, you have already modified the code according the 
comments, and I also validate the ISI driver, no errors.

You can finalize the atmel-isi driver.
Thank you very much.


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: [RFC PATCH 6/7] atmel-isi: remove dependency of the soc-camera framework

[Hans Verkuil]

Hi Songjun,

On 10/19/2016 09:48 AM, Wu, Songjun wrote:
> 
> 
> On 10/19/2016 15:46, Hans Verkuil wrote:
>> On 10/19/2016 09:36 AM, Wu, Songjun wrote:
>>>
>>>
>>> On 10/18/2016 18:58, Hans Verkuil wrote:
 On 10/18/16 11:21, Wu, Songjun wrote:
> Hi Hans,
>
> Do you have any issue on this patch?

 ENOTIME :-(

> Could I give you some help? :)

 I would certainly help if you can make the requested change to this patch.

 Let me know if you want to do that, because in that case I'll rebase my
 tree
 to the latest media_tree master.

>>> Yes, I would like to make the requested change to this patch. :)
>>> It seems the patch is not based on the latest media_tree master.
>>> Will you rebase this patch to the latest media_tree, or let me move it
>>> and make the requested change based on the media_tree?
>>
>> I've rebased my branch:
>>
>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=sama5d3-2
>>
> Thank you very much.
> I will make the requested change based on your branch.

Did you make any progress on this? I plan on finalizing the atmel-isi driver
next week.

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