Re: [PATCHv2 08/16] atmel-isi: document device tree bindings

[Sakari Ailus]

Hi Hans,

On Mon, Jan 30, 2017 at 03:06:20PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Document the device tree bindings for this driver.
> 
> Mostly copied from the atmel-isc bindings.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/atmel-isi.txt| 91 
> +-
>  1 file changed, 56 insertions(+), 35 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt 
> b/Documentation/devicetree/bindings/media/atmel-isi.txt
> index 251f008..d1934b4 100644
> --- a/Documentation/devicetree/bindings/media/atmel-isi.txt
> +++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
> @@ -1,51 +1,72 @@
> -Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
> ---
> +Atmel Image Sensor Interface (ISI)
> +--
>  
> -Required properties:
> -- compatible: must be "atmel,at91sam9g45-isi"
> -- reg: physical base address and length of the registers set for the device;
> -- interrupts: should contain IRQ line for the ISI;
> -- clocks: list of clock specifiers, corresponding to entries in
> -  the clock-names property;
> -- clock-names: must contain "isi_clk", which is the isi peripherial clock.
> +Required properties for ISI:
> +- compatible
> + Must be "atmel,at91sam9g45-isi".
> +- reg
> + Physical base address and length of the registers set for the device.
> +- interrupts
> + Should contain IRQ line for the ISI.
> +- clocks
> + List of clock specifiers, corresponding to entries in
> + the clock-names property;
> + Please refer to clock-bindings.txt.
> +- clock-names
> + Required elements: "isi_clk".
> +- #clock-cells
> + Should be 0.

#clock-cells can't be found in the example. Does the ISI block provide a
#clock?

> +- pinctrl-names, pinctrl-0
> + Please refer to pinctrl-bindings.txt.
>  
>  ISI supports a single port node with parallel bus. It should contain one
>  'port' child node with child 'endpoint' node. Please refer to the bindings
>  defined in Documentation/devicetree/bindings/media/video-interfaces.txt.

We haven't documented exactly which properties are relevant for parallel
interfaces. I think we should, but until that's done we should explicitly
document which endpoint properties are mandatory and which are optional.

Such as in Documentation/devicetree/bindings/media/i2c/nokia,smia.txt .

>  
>  Example:
> - isi: isi@f0034000 {
> - compatible = "atmel,at91sam9g45-isi";
> - reg = <0xf0034000 0x4000>;
> - interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
>  
> - clocks = <_clk>;
> - clock-names = "isi_clk";
> +isi: isi@f0034000 {
> + compatible = "atmel,at91sam9g45-isi";
> + reg = <0xf0034000 0x4000>;
> + interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_isi_data_0_7>;
> + clocks = <_clk>;
> + clock-names = "isi_clk";
> + status = "ok";
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + isi_0: endpoint {
> + reg = <0>;
> + remote-endpoint = <_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;
> + };
> + };
> +};
> +
> +i2c1: i2c@f0018000 {
> + status = "okay";
>  
> + ov2640: camera@0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
>   pinctrl-names = "default";
> - pinctrl-0 = <_isi>;
> + pinctrl-0 = <_pck0_as_isi_mck _sensor_power 
> _sensor_reset>;
> + resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
> + clocks = <>;
> + clock-names = "xvclk";
> + assigned-clocks = <>;
> + assigned-clock-rates = <2500>;
>  
>   port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - isi_0: endpoint {
> - remote-endpoint = <_0>;
> + ov2640_0: endpoint {
> + remote-endpoint = <_0>;
>   bus-width = <8>;
>   };
>   };
>   };
> -
> - i2c1: i2c@f0018000 {
> - ov2640: camera@0x30 {
> - compatible = "ovti,ov2640";
> - reg = <0x30>;
> -
> - port {
> - ov2640_0: endpoint {
> - remote-endpoint = <_0>;
> - bus-width = <8>;
> - };
> - };
> - };
> - };
> +};
> -- 
> 2.10.2
> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 

Re: [PATCHv2 05/16] ov7670: document device tree bindings

[Sakari Ailus]

Hi Hans,

On Mon, Jan 30, 2017 at 03:06:17PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add binding documentation and add that file to the MAINTAINERS entry.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/i2c/ov7670.txt   | 44 
> ++
>  MAINTAINERS|  1 +
>  2 files changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> new file mode 100644
> index 000..a014694
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> @@ -0,0 +1,44 @@
> +* Omnivision OV7670 CMOS sensor
> +
> +The Omnivision OV7670 sensor supports multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support the YUV422/420, RGB565/555 or raw RGB
> +output formats.
> +
> +Required Properties:
> +- compatible: should be "ovti,ov7670"
> +- clocks: reference to the xclk input clock.
> +- clock-names: should be "xclk".
> +
> +Optional Properties:
> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.

Please add when the signal is active. From the datasheet it seems to be that
these are both "active high".

> +
> +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:
> +
> + i2c1: i2c@f0018000 {
> + status = "okay";
> +
> + ov7670: camera@0x21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pck0_as_isi_mck 
> _sensor_power _sensor_reset>;
> + resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
> + clocks = <>;
> + clock-names = "xclk";
> + assigned-clocks = <>;
> + assigned-clock-rates = <2500>;
> +
> + port {
> + ov7670_0: endpoint {
> + remote-endpoint = <_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };

-- 
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: [PATCHv2 04/16] ov7670: add devicetree support

[Sakari Ailus]

Hi Hans,

On Mon, Jan 30, 2017 at 03:06:16PM +0100, Hans Verkuil wrote:
> @@ -1549,6 +1551,29 @@ static const struct ov7670_devtype ov7670_devdata[] = {
>   },
>  };
>  
> +static int ov7670_init_gpio(struct i2c_client *client, struct ov7670_info 
> *info)
> +{
> + /* Request the power down GPIO asserted */

You're setting both GPIOs to low state. How about just removing the
comments? I think they're just confusing.

> + info->pwdn_gpio = devm_gpiod_get_optional(>dev, "pwdn",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(info->pwdn_gpio)) {
> + dev_info(>dev, "can't get %s GPIO\n", "pwdn");
> + return PTR_ERR(info->pwdn_gpio);
> + }
> +
> + /* Request the reset GPIO deasserted */
> + info->resetb_gpio = devm_gpiod_get_optional(>dev, "resetb",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(info->resetb_gpio)) {
> + dev_info(>dev, "can't get %s GPIO\n", "resetb");
> + return PTR_ERR(info->resetb_gpio);
> + }
> +
> + usleep_range(3000, 5000);
> +
> + return 0;
> +}
> +
>  static int ov7670_probe(struct i2c_client *client,
>   const struct i2c_device_id *id)
>  {

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

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 Jan 31 05:00:24 CET 2017
media-tree git hash:a052af2a548decf1da5cccf9e777aa02321e3ffb
media_build git hash:   3c6ce4ff75f19adf45869e34b376c5b9dee4d50a
v4l-utils git hash: 9df320dd3d1a498fcd6cdeef7d783da609b526e0
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.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: ERRORS
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
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: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-4.10-rc3-i686: ERRORS
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: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
linux-4.10-rc3-x86_64: ERRORS
apps: WARNINGS
spec-git: OK
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 v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

[Steve Longerbeam]

On 01/30/2017 03:29 PM, Russell King - ARM Linux wrote:

On Fri, Jan 06, 2017 at 06:11:40PM -0800, Steve Longerbeam wrote:

+config IMX_OV5640_MIPI
+   tristate "OmniVision OV5640 MIPI CSI-2 camera support"
+   depends on GPIOLIB && VIDEO_IMX_CAMERA
+   select IMX_MIPI_CSI2
+   default y

Why is this defaulting to y?  New drivers should not default to enabled
unless they are replacing some already pre-existing functionality.
Ditto for the other camera driver.


The ov564x sensors are required for the SabreSD and SabreLite/Nitrogen
reference boards (if VIDEO_IMX_CAMERA is enabled that is). But they're not
required for other platforms, so you're right I shouldn't have defaulted 
these

to yes. Fixed.


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 v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Steve Longerbeam]

On 01/30/2017 04:31 PM, Russell King - ARM Linux wrote:

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:

+++ b/drivers/staging/media/imx/imx-mipi-csi2.c

...

+#define DEVICE_NAME "imx6-mipi-csi2"

Why is the device/driver named imx6-mipi-csi2, but the module named
imx-mipi-csi2 - could there be some consistency here please?


right, that was missed after renaming the device node. Fixed.

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 v3 00/24] i.MX Media Driver

[Steve Longerbeam]

On 01/30/2017 05:06 PM, Russell King - ARM Linux wrote:

On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote:

Trying this driver with an imx219 camera (which works with Philipp's
driver) results in not much happening... no /dev/media* node for it,
no subdevs, no nothing.  No clues as to what's missing either.  Only
messages from imx-media are from registering the various subdevs.

Another issue:

imx_csi 5491  4
imx_camif  11654  4
imx_ic 23961  8
imx_smfc6639  4
imx_media  23308  1 imx_csi
imx_mipi_csi2   5544  1
imx_media_common   12701  6 
imx_csi,imx_smfc,imx_media,imx_mipi_csi2,imx_camif,imx_ic
imx219 21205  2

So how does one remove any of these modules, say, while developing a
camera driver?  Having to reboot to test an update makes it painfully
slow for testing.


Unload is not working yet, it's on the TODO list.

But FWIW, here's how it currently looks in version 4
(on the SabreSD):

imx_media_csi   9663  4
imx_media_ic   12688  6
imx_media_capture  10201  2 imx_media_ic,imx_media_csi
imx_media_vdic  6909  2
imx_mipi_csi2   6293  1
ov5640_mipi25988  1
imx_media  15532  0
imx_media_common   16093  6 
imx_media_ic,imx_media,imx_media_csi,imx_mipi_cs

i2,imx_media_capture,imx_media_vdic


Steve




Philipp's driver can do this (once the unload bugs are fixed, which I
have patches for).



--
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 6/6] staging: bcm2835-v4l2: Apply spelling fixes from checkpatch.

[Joe Perches]

On Mon, 2017-01-30 at 12:05 -0800, Eric Anholt wrote:
> Joe Perches  writes:
> 
> > On Fri, 2017-01-27 at 13:55 -0800, Eric Anholt wrote:
> > > Generated with checkpatch.pl --fix-inplace and git add -p out of the
> > > results.
> > 
> > Maybe another.
> > 
> > > diff --git a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c 
> > > b/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
> > 
> > []
> > > @@ -239,7 +239,7 @@ static int bulk_receive(struct vchiq_mmal_instance 
> > > *instance,
> > >   pr_err("buffer list empty trying to submit bulk receive\n");
> > >  
> > >   /* todo: this is a serious error, we should never have
> > > -  * commited a buffer_to_host operation to the mmal
> > > +  * committed a buffer_to_host operation to the mmal
> > >* port without the buffer to back it up (underflow
> > >* handling) and there is no obvious way to deal with
> > >* this - how is the mmal servie going to react when
> > 
> > Perhaps s/servie/service/ ?
> 
> I was trying to restrict this patch to just the fixes from checkpatch.

That's the wrong thing to do if you're fixing
spelling defects.  checkpatch is just one mechanism
to identify some, and definitely not all, typos and
spelling defects.

If you fixing, fix.  Don't just rely on the brainless
tools, use your decidedly non-mechanical brain.
--
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 00/24] i.MX Media Driver

[Steve Longerbeam]

On 01/30/2017 04:45 PM, Russell King - ARM Linux wrote:


Hi,

Trying this driver with an imx219 camera (which works with Philipp's
driver) results in not much happening... no /dev/media* node for it,
no subdevs, no nothing.  No clues as to what's missing either.  Only
messages from imx-media are from registering the various subdevs.

[   37.444877] imx-media: Registered subdev imx6-mipi-csi2
[   37.444973] imx-media: Registered subdev imx219 0-0010
[   38.868740] imx-media: Registered subdev ipu1_ic_prpenc
[   38.869265] imx-media: Registered subdev ipu1_ic_prpvf
[   38.869425] imx-media: Registered subdev ipu1_ic_pp0
[   38.870086] imx-media: Registered subdev ipu1_ic_pp1
[   38.871510] imx-media: Registered subdev ipu2_ic_prpenc
[   38.871743] imx-media: Registered subdev ipu1_smfc0
[   38.873043] imx-media: Registered subdev ipu1_smfc1
[   38.873225] imx-media: Registered subdev ipu2_ic_prpvf
[   38.875027] imx-media: Registered subdev ipu2_smfc0
[   38.875320] imx-media: Registered subdev ipu2_ic_pp0
[   38.877148] imx-media: Registered subdev ipu2_smfc1
[   38.877436] imx-media: Registered subdev ipu2_ic_pp1
[   38.932089] imx-media: Registered subdev camif0
[   38.956538] imx-media: Registered subdev camif1
[   38.959148] imx-media: Registered subdev camif2
[   38.964353] imx-media: Registered subdev camif3
[  206.502077] imx-media: Registered subdev ipu1_csi0
[  206.503304] imx-media: Registered subdev ipu1_csi1
[  206.503814] imx-media: Registered subdev ipu2_csi0
[  206.504281] imx-media: Registered subdev ipu2_csi1

I also get:

[   37.200072] imx6-mipi-csi2: data lanes: 2
[   37.200077] imx6-mipi-csi2: flags: 0x0200

and from what I can see, all modules from drivers/staging/media/imx/ are
loaded (had to load imx-csi by hand because of the brokenness in the
drivers/gpu/ipu code attaching an device_node pointer after registering
the platform device, which changes what userspace sees in the modalias
file.)

Any clues at what to look at?


Hi Russell,

I'm not familiar with IMX219, can you send me the source for the
imx219 subdev? I don't see it in 4.10-rc1.

I'm also having trouble finding a datasheet for it, but from what
I've read, it has a MIPI CSI-2 interface. It should work fine as long
as it presents a single source pad, registers asynchronously, and
sets its entity function to MEDIA_ENT_F_CAM_SENSOR.

Since I see it was registered asynchronously from the above, it
must have been added to the device tree. But given that there
is no /dev/media? node, the media driver is probably waiting for
another subdev to register, I don't know what that would be.

Can you send me the full patch on top of the v3 driver and I'll
try to find what's missing.

Edit: I see a subdev that is missing: the video mux. Did you enable
CONFIG_VIDEO_MULTIPLEXER?

Finally, what platform does this IMX219 sensor module plug into?


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 v3 00/24] i.MX Media Driver

[Russell King - ARM Linux]

On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote:
> Trying this driver with an imx219 camera (which works with Philipp's
> driver) results in not much happening... no /dev/media* node for it,
> no subdevs, no nothing.  No clues as to what's missing either.  Only
> messages from imx-media are from registering the various subdevs.

Another issue:

imx_csi 5491  4
imx_camif  11654  4
imx_ic 23961  8
imx_smfc6639  4
imx_media  23308  1 imx_csi
imx_mipi_csi2   5544  1
imx_media_common   12701  6 
imx_csi,imx_smfc,imx_media,imx_mipi_csi2,imx_camif,imx_ic
imx219 21205  2

So how does one remove any of these modules, say, while developing a
camera driver?  Having to reboot to test an update makes it painfully
slow for testing.

Philipp's driver can do this (once the unload bugs are fixed, which I
have patches for).

-- 
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 v3 00/24] i.MX Media Driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:18PM -0800, Steve Longerbeam wrote:
> Philipp Zabel (3):
>   ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
> connections
>   add mux and video interface bridge entity functions
>   platform: add video-multiplexer subdevice driver
> 
> Steve Longerbeam (21):
>   [media] dt-bindings: Add bindings for i.MX media driver
>   ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
>   ARM: dts: imx6qdl: add media device
>   ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround
>   ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
>   ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
>   ARM: dts: imx6-sabreauto: create i2cmux for i2c3
>   ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
>   ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
>   ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
>   UAPI: Add media UAPI Kbuild file
>   media: Add userspace header file for i.MX
>   media: Add i.MX media core driver
>   media: imx: Add CSI subdev driver
>   media: imx: Add SMFC subdev driver
>   media: imx: Add IC subdev drivers
>   media: imx: Add Camera Interface subdev driver
>   media: imx: Add MIPI CSI-2 Receiver subdev driver
>   media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver
>   media: imx: Add Parallel OV5642 sensor subdev driver
>   ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers

Hi,

Trying this driver with an imx219 camera (which works with Philipp's
driver) results in not much happening... no /dev/media* node for it,
no subdevs, no nothing.  No clues as to what's missing either.  Only
messages from imx-media are from registering the various subdevs.

[   37.444877] imx-media: Registered subdev imx6-mipi-csi2
[   37.444973] imx-media: Registered subdev imx219 0-0010
[   38.868740] imx-media: Registered subdev ipu1_ic_prpenc
[   38.869265] imx-media: Registered subdev ipu1_ic_prpvf
[   38.869425] imx-media: Registered subdev ipu1_ic_pp0
[   38.870086] imx-media: Registered subdev ipu1_ic_pp1
[   38.871510] imx-media: Registered subdev ipu2_ic_prpenc
[   38.871743] imx-media: Registered subdev ipu1_smfc0
[   38.873043] imx-media: Registered subdev ipu1_smfc1
[   38.873225] imx-media: Registered subdev ipu2_ic_prpvf
[   38.875027] imx-media: Registered subdev ipu2_smfc0
[   38.875320] imx-media: Registered subdev ipu2_ic_pp0
[   38.877148] imx-media: Registered subdev ipu2_smfc1
[   38.877436] imx-media: Registered subdev ipu2_ic_pp1
[   38.932089] imx-media: Registered subdev camif0
[   38.956538] imx-media: Registered subdev camif1
[   38.959148] imx-media: Registered subdev camif2
[   38.964353] imx-media: Registered subdev camif3
[  206.502077] imx-media: Registered subdev ipu1_csi0
[  206.503304] imx-media: Registered subdev ipu1_csi1
[  206.503814] imx-media: Registered subdev ipu2_csi0
[  206.504281] imx-media: Registered subdev ipu2_csi1

I also get:

[   37.200072] imx6-mipi-csi2: data lanes: 2
[   37.200077] imx6-mipi-csi2: flags: 0x0200

and from what I can see, all modules from drivers/staging/media/imx/ are
loaded (had to load imx-csi by hand because of the brokenness in the
drivers/gpu/ipu code attaching an device_node pointer after registering
the platform device, which changes what userspace sees in the modalias
file.)

Any clues at what to look at?

-- 
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 v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
...
> +#define DEVICE_NAME "imx6-mipi-csi2"

Why is the device/driver named imx6-mipi-csi2, but the module named
imx-mipi-csi2 - could there be some consistency here please?

Thanks.

-- 
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 v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +static void imxcsi2_enable(struct imxcsi2_dev *csi2, bool enable)
> +{
> + if (enable) {
> + imxcsi2_write(csi2, 0x, CSI2_PHY_SHUTDOWNZ);
> + imxcsi2_write(csi2, 0x, CSI2_DPHY_RSTZ);
> + imxcsi2_write(csi2, 0x, CSI2_RESETN);
> + } else {
> + imxcsi2_write(csi2, 0x0, CSI2_PHY_SHUTDOWNZ);
> + imxcsi2_write(csi2, 0x0, CSI2_DPHY_RSTZ);
> + imxcsi2_write(csi2, 0x0, CSI2_RESETN);
> + }
> +}
> +
> +static void imxcsi2_reset(struct imxcsi2_dev *csi2)
> +{
> + imxcsi2_enable(csi2, false);
> +
> + imxcsi2_write(csi2, 0x0001, CSI2_PHY_TST_CTRL0);
> + imxcsi2_write(csi2, 0x, CSI2_PHY_TST_CTRL1);
> + imxcsi2_write(csi2, 0x, CSI2_PHY_TST_CTRL0);
> + imxcsi2_write(csi2, 0x0002, CSI2_PHY_TST_CTRL0);
> + imxcsi2_write(csi2, 0x00010044, CSI2_PHY_TST_CTRL1);
> + imxcsi2_write(csi2, 0x, CSI2_PHY_TST_CTRL0);
> + imxcsi2_write(csi2, 0x0014, CSI2_PHY_TST_CTRL1);
> + imxcsi2_write(csi2, 0x0002, CSI2_PHY_TST_CTRL0);
> + imxcsi2_write(csi2, 0x, CSI2_PHY_TST_CTRL0);
> +
> + imxcsi2_enable(csi2, true);
> +}
> +
> +static int imxcsi2_dphy_wait(struct imxcsi2_dev *csi2)
> +{
> + u32 reg;
> + int i;
> +
> + /* wait for mipi sensor ready */
> + for (i = 0; i < 50; i++) {
> + reg = imxcsi2_read(csi2, CSI2_PHY_STATE);
> + if (reg != 0x200)
> + break;
> + usleep_range(1, 2);
> + }
> +
> + if (i >= 50) {
> + v4l2_err(>sd,
> +  "wait for clock lane timeout, phy_state = 0x%08x\n",
> +  reg);
> + return -ETIME;
> + }
> +
> + /* wait for mipi stable */
> + for (i = 0; i < 50; i++) {
> + reg = imxcsi2_read(csi2, CSI2_ERR1);
> + if (reg == 0x0)
> + break;
> + usleep_range(1, 2);
> + }
> +
> + if (i >= 50) {
> + v4l2_err(>sd,
> +  "wait for controller timeout, err1 = 0x%08x\n",
> +  reg);
> + return -ETIME;
> + }
> +
> + /* finally let's wait for active clock on the clock lane */
> + for (i = 0; i < 50; i++) {
> + reg = imxcsi2_read(csi2, CSI2_PHY_STATE);
> + if (reg & (1 << 8))
> + break;
> + usleep_range(1, 2);
> + }
> +
> + if (i >= 50) {
> + v4l2_err(>sd,
> +  "wait for active clock timeout, phy_state = 0x%08x\n",
> +  reg);
> + return -ETIME;
> + }
> +
> + v4l2_info(>sd, "ready, dphy version 0x%x\n",
> +   imxcsi2_read(csi2, CSI2_VERSION));
> +
> + return 0;
> +}
...
> +static int imxcsi2_s_power(struct v4l2_subdev *sd, int on)
> +{
> + struct imxcsi2_dev *csi2 = sd_to_dev(sd);
> +
> + if (on && !csi2->on) {
> + v4l2_info(>sd, "power ON\n");
> + clk_prepare_enable(csi2->cfg_clk);
> + clk_prepare_enable(csi2->dphy_clk);
> + imxcsi2_set_lanes(csi2);
> + imxcsi2_reset(csi2);

The iMX6 manuals call for a very specific seven sequence of initialisation
for CSI2, which begins with:

1. reset the D-PHY.
2. place MIPI sensor in LP-11 state
3. perform D-PHY initialisation
4. configure CSI2 lanes and de-assert resets and shutdown signals

Since you reset the CSI2 at power up and then release it, how do you
guarantee that the published sequence is followed?

With Philipp's driver, this is easy, because there is a prepare_stream
callback which gives the sensor an opportunity to get everything
correctly configured according to the negotiated parameters, and place
the sensor in LP-11 state.

Some sensors do not power up in LP-11 state, but need to be programmed
fully before being asked to momentarily stream.  Only at that point is
the sensor guaranteed to be in the required LP-11 state.

-- 
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 v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:40PM -0800, Steve Longerbeam wrote:
> +config IMX_OV5640_MIPI
> +   tristate "OmniVision OV5640 MIPI CSI-2 camera support"
> +   depends on GPIOLIB && VIDEO_IMX_CAMERA
> +   select IMX_MIPI_CSI2
> +   default y

Why is this defaulting to y?  New drivers should not default to enabled
unless they are replacing some already pre-existing functionality.
Ditto for the other camera driver.

-- 
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 v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> + ov5640: camera@40 {
> + compatible = "ovti,ov5640";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ov5640>;
> + clocks = <_xclk>;
> + clock-names = "xclk";
> + reg = <0x40>;
> + xclk = <2200>;
> + reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
> + pwdn-gpios = < 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov5640_to_mipi_csi: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_csi_from_mipi_sensor>;
> + data-lanes = <0 1>;
> + clock-lanes = <2>;

How do you envision a four-lane sensor being described?

data-lanes = <0 1 3 4>;
clock-lanes = <2>;

?

The binding document for video-interfaces.txt says:

- clock-lanes: an array of physical clock lane indexes. Position of an entry
  determines the logical lane number, while the value of an entry indicates
  physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
  which places the clock lane on hardware lane 0. This property is valid for
  serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
  array contains only one entry.

So I think you need to have a good reason to make the clock lane non-zero.

-- 
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 v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: imx: Add MIPI CSI-2 Receiver subdev driver
.git/rebase-apply/patch:522: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

-- 
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 v3 17/24] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
> 
> Signed-off-by: Steve Longerbeam 

warning: 3 lines add whitespace errors.
Applying: media: imx: Add CSI subdev driver
.git/rebase-apply/patch:38: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

-- 
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 v3 19/24] media: imx: Add IC subdev drivers

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:37PM -0800, Steve Longerbeam wrote:
> This is a set of three media entity subdevice drivers for the i.MX
> Image Converter. The i.MX IC module contains three independent
> "tasks":
> 
> - Pre-processing Encode task: video frames are routed directly from
>   the CSI and can be scaled, color-space converted, and rotated.
>   Scaled output is limited to 1024x1024 resolution. Output frames
>   are routed to the camera interface entities (camif).
> 
> - Pre-processing Viewfinder task: this task can perform the same
>   conversions as the pre-process encode task, but in addition can
>   be used for hardware motion compensated deinterlacing. Frames can
>   come either directly from the CSI or from the SMFC entities (memory
>   buffers via IDMAC channels). Scaled output is limited to 1024x1024
>   resolution. Output frames can be routed to various sinks including
>   the post-processing task entities.
> 
> - Post-processing task: same conversions as pre-process encode. However
>   this entity sends frames to the i.MX IPU image converter which supports
>   image tiling, which allows scaled output up to 4096x4096 resolution.
>   Output frames can be routed to the camera interfaces.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: imx: Add IC subdev drivers
.git/rebase-apply/patch:3054: new blank line at EOF.
+
warning: 1 line adds whitespace errors.


-- 
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 v3 16/24] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:516: new blank line at EOF.
+
.git/rebase-apply/patch:528: new blank line at EOF.
+
.git/rebase-apply/patch:556: new blank line at EOF.
+
warning: 3 lines add whitespace errors.

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

[GIT PULL FOR v4.11] More RC updates

[Sean Young]

Hi Mauro,

This includes a fix for my embarrassing ir-rx51 build failure, the mediatek
IR driver, a keymap and some important fixes for tx-only drivers.

Thanks,

Sean


The following changes since commit a052af2a548decf1da5cccf9e777aa02321e3ffb:

  [media] staging/media/s5p-cec/exynos_hdmi_cecctrl.c Fixed blank line before 
closing brace '}' (2017-01-30 15:48:54 -0200)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.11b

for you to fetch changes up to 7813bce59dca0eb7f9af1626fc9cd6ef1ddea9a5:

  [media] rx51: broken build (2017-01-30 21:38:30 +)


Martin Blumenstingl (1):
  [media] rc/keymaps: add a keytable for the GeekBox remote control

Sean Wang (3):
  [media] rc: add driver for IR remote receiver on MT7623 SoC
  [media] Documentation: devicetree: move shared property used by rc into a 
common place
  [media] Documentation: devicetree: Add document bindings for mtk-cir

Sean Young (5):
  [media] lirc: fix transmit-only read features
  [media] rc: remove excessive spaces from error message
  [media] lirc: LIRC_GET_MIN_TIMEOUT should be in range
  [media] lirc: fix null dereference for tx-only devices
  [media] rx51: broken build

 .../devicetree/bindings/media/gpio-ir-receiver.txt |   3 +-
 .../devicetree/bindings/media/hix5hd2-ir.txt   |   2 +-
 .../devicetree/bindings/media/mtk-cir.txt  |  24 ++
 Documentation/devicetree/bindings/media/rc.txt | 116 +++
 .../devicetree/bindings/media/sunxi-ir.txt |   2 +-
 arch/arm/mach-omap2/pdata-quirks.c |   2 +-
 drivers/media/rc/Kconfig   |  11 +
 drivers/media/rc/Makefile  |   1 +
 drivers/media/rc/ir-lirc-codec.c   |   7 +-
 drivers/media/rc/keymaps/Makefile  |   1 +
 drivers/media/rc/keymaps/rc-geekbox.c  |  55 
 drivers/media/rc/lirc_dev.c|   2 +-
 drivers/media/rc/mtk-cir.c | 335 +
 drivers/media/rc/rc-main.c |   3 +-
 include/media/rc-map.h |   1 +
 15 files changed, 555 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
 create mode 100644 Documentation/devicetree/bindings/media/rc.txt
 create mode 100644 drivers/media/rc/keymaps/rc-geekbox.c
 create mode 100644 drivers/media/rc/mtk-cir.c
--
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: [linuxtv-media:master 1071/1091] arch/arm/mach-omap2/pdata-quirks.c:536:49: error: 'rx51_lirc_data' undeclared here (not in a function)

[Sean Young]

On Tue, Jan 31, 2017 at 03:53:54AM +0800, kbuild test robot wrote:
> tree:   git://linuxtv.org/media_tree.git master
> head:   a052af2a548decf1da5cccf9e777aa02321e3ffb
> commit: a92def1becf33e91fc460c7ae575aa9210ba8f40 [1071/1091] [media] ir-rx51: 
> port to rc-core
> config: arm-multi_v7_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> 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
> git checkout a92def1becf33e91fc460c7ae575aa9210ba8f40
> # save the attached .config to linux build tree
> make.cross ARCH=arm 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from arch/arm/mach-omap2/pdata-quirks.c:15:0:
> >> arch/arm/mach-omap2/pdata-quirks.c:536:49: error: 'rx51_lirc_data' 
> >> undeclared here (not in a function)
>  OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _lirc_data),
> ^
>include/linux/of_platform.h:52:21: note: in definition of macro 
> 'OF_DEV_AUXDATA'
>.platform_data = _pdata }

Oh dear, that should have been rx51_ir_data. The patch below fixes it.


Sean

>From 7813bce59dca0eb7f9af1626fc9cd6ef1ddea9a5 Mon Sep 17 00:00:00 2001
From: Sean Young 
Date: Mon, 30 Jan 2017 19:58:19 +
Subject: [PATCH] [media] rx51: broken build

Since "a92def1 [media] ir-rx51: port to rc-core" the build fails on
some arm configurations.

Signed-off-by: Sean Young 
---
 arch/arm/mach-omap2/pdata-quirks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 9f06074..dc3b6c8 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -533,7 +533,7 @@ static struct of_dev_auxdata omap_auxdata_lookup[] 
__initdata = {
   _iommu_pdata),
OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x4809c000, "4809c000.mmc", 
_pdata[0]),
OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x480b4000, "480b4000.mmc", 
_pdata[1]),
-   OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _lirc_data),
+   OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),
/* Only on am3517 */
OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", NULL),
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",
-- 
2.9.3

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

Re: [PATCH 6/6] staging: bcm2835-v4l2: Apply spelling fixes from checkpatch.

[Eric Anholt]

Joe Perches  writes:

> On Fri, 2017-01-27 at 13:55 -0800, Eric Anholt wrote:
>> Generated with checkpatch.pl --fix-inplace and git add -p out of the
>> results.
>
> Maybe another.
>
>> diff --git a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c 
>> b/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
> []
>> @@ -239,7 +239,7 @@ static int bulk_receive(struct vchiq_mmal_instance 
>> *instance,
>>  pr_err("buffer list empty trying to submit bulk receive\n");
>>  
>>  /* todo: this is a serious error, we should never have
>> - * commited a buffer_to_host operation to the mmal
>> + * committed a buffer_to_host operation to the mmal
>>   * port without the buffer to back it up (underflow
>>   * handling) and there is no obvious way to deal with
>>   * this - how is the mmal servie going to react when
>
> Perhaps s/servie/service/ ?

I was trying to restrict this patch to just the fixes from checkpatch.


signature.asc
Description: PGP signature

[linuxtv-media:master 1071/1091] arch/arm/mach-omap2/pdata-quirks.c:536:49: error: 'rx51_lirc_data' undeclared here (not in a function)

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git master
head:   a052af2a548decf1da5cccf9e777aa02321e3ffb
commit: a92def1becf33e91fc460c7ae575aa9210ba8f40 [1071/1091] [media] ir-rx51: 
port to rc-core
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
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
git checkout a92def1becf33e91fc460c7ae575aa9210ba8f40
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from arch/arm/mach-omap2/pdata-quirks.c:15:0:
>> arch/arm/mach-omap2/pdata-quirks.c:536:49: error: 'rx51_lirc_data' 
>> undeclared here (not in a function)
 OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _lirc_data),
^
   include/linux/of_platform.h:52:21: note: in definition of macro 
'OF_DEV_AUXDATA'
   .platform_data = _pdata }
^~

vim +/rx51_lirc_data +536 arch/arm/mach-omap2/pdata-quirks.c

036582f76 Tony Lindgren   2013-11-25  530  #endif
30a69ef78 Tony Lindgren   2013-10-10  531  #ifdef CONFIG_ARCH_OMAP3
910f1678b Suman Anna  2014-03-05  532   
OF_DEV_AUXDATA("ti,omap2-iommu", 0x5d00, "5d00.mmu",
910f1678b Suman Anna  2014-03-05  533  
_iommu_pdata),
10c1f7d32 Tony Lindgren   2016-04-28  534   
OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x4809c000, "4809c000.mmc", _pdata[0]),
10c1f7d32 Tony Lindgren   2016-04-28  535   
OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x480b4000, "480b4000.mmc", _pdata[1]),
b54061769 Ivaylo Dimitrov 2016-06-22 @536   OF_DEV_AUXDATA("nokia,n900-ir", 
0, "n900-ir", _lirc_data),
719003144 Tony Lindgren   2013-12-06  537   /* Only on am3517 */
719003144 Tony Lindgren   2013-12-06  538   
OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", NULL),
719003144 Tony Lindgren   2013-12-06  539   
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",

:: The code at line 536 was first introduced by commit
:: b5406176989da601736db862643d3d7ee8335815 ir-rx51: add DT support to 
driver

:: TO: Ivaylo Dimitrov 
:: CC: Tony Lindgren 

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


.config.gz
Description: application/gzip

Re: [GIT PULL FOR v4.11] New st-delta driver

[Mauro Carvalho Chehab]

Em Mon, 30 Jan 2017 17:15:36 -0200
Mauro Carvalho Chehab  escreveu:

> Em Mon, 9 Jan 2017 14:23:33 +0100
> Hans Verkuil  escreveu:
> 
> > See the v4 series for details:
> > 
> > https://www.spinics.net/lists/linux-media/msg108737.html
> > 
> > Regards,
> > 
> > Hans
> > 
> > The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:
> > 
> >   [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)
> > 
> > are available in the git repository at:
> > 
> >   git://linuxtv.org/hverkuil/media_tree.git delta
> > 
> > for you to fetch changes up to e6f199d01e7b8bc4436738b6c666fda31b9f3340:
> > 
> >   st-delta: debug: trace stream/frame information & summary (2017-01-09 
> > 14:16:45 +0100)
> > 
> > 
> > Hugues Fruchet (10):
> >   Documentation: DT: add bindings for ST DELTA
> >   ARM: dts: STiH410: add DELTA dt node
> >   ARM: multi_v7_defconfig: enable STMicroelectronics DELTA Support
> >   MAINTAINERS: add st-delta driver
> >   st-delta: STiH4xx multi-format video decoder v4l2 driver
> >   st-delta: add memory allocator helper functions
> >   st-delta: rpmsg ipc support
> >   st-delta: EOS (End Of Stream) support
> >   st-delta: add mjpeg support
> >   st-delta: debug: trace stream/frame information & summary
> 
> There is something wrong on this driver... even after applying all
> patches, it complains that there's a for there that does nothing:
> 
> drivers/media/platform/sti/delta/delta-v4l2.c:322 register_decoders() warn: 
> we never enter this loop
> drivers/media/platform/sti/delta/delta-v4l2.c: In function 
> 'register_decoders':
> drivers/media/platform/sti/delta/delta-v4l2.c:322:16: warning: comparison of 
> unsigned expression < 0 is always false [-Wtype-limits]
>   for (i = 0; i < ARRAY_SIZE(delta_decoders); i++) {
> ^
> 
> On a first glance, it seems that the register_decoders() function is
> reponsible to register the format decoders that the hardware
> recognizes. If so, I suspect that this driver is deadly broken.
> 
> Please be sure that the upstream driver works properly before
> submitting it upstream.
> 
> Also, please fix the comments to match the Kernel standard. E. g.
> instead of:
> 
> /* guard output frame count:
>  * - at least 1 frame needed for display
>  * - at worst 21
>  *   ( max h264 dpb (16) +
>  * decoding peak smoothing (2) +
>  * user display pipeline (3) )
>  */
> 
> It should be:
> 
> /*
>  * guard output frame count:
>  * - at least 1 frame needed for display
>  * - at worst 21
>  *   ( max h264 dpb (16) +
>  * decoding peak smoothing (2) +
>  * user display pipeline (3) )
>  */
> 
> There are several similar occurrences among this patch series.

Ah, forgot to comment, but it mentions a firmware. Does such firmware
reside on some RAM memory? If so, how such firmware is loaded? 

> 
> Thanks,
> Mauro
> 
> Thanks,
> Mauro



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: [GIT PULL FOR v4.11] New st-delta driver

[Mauro Carvalho Chehab]

Em Mon, 9 Jan 2017 14:23:33 +0100
Hans Verkuil  escreveu:

> See the v4 series for details:
> 
> https://www.spinics.net/lists/linux-media/msg108737.html
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:
> 
>   [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git delta
> 
> for you to fetch changes up to e6f199d01e7b8bc4436738b6c666fda31b9f3340:
> 
>   st-delta: debug: trace stream/frame information & summary (2017-01-09 
> 14:16:45 +0100)
> 
> 
> Hugues Fruchet (10):
>   Documentation: DT: add bindings for ST DELTA
>   ARM: dts: STiH410: add DELTA dt node
>   ARM: multi_v7_defconfig: enable STMicroelectronics DELTA Support
>   MAINTAINERS: add st-delta driver
>   st-delta: STiH4xx multi-format video decoder v4l2 driver
>   st-delta: add memory allocator helper functions
>   st-delta: rpmsg ipc support
>   st-delta: EOS (End Of Stream) support
>   st-delta: add mjpeg support
>   st-delta: debug: trace stream/frame information & summary

There is something wrong on this driver... even after applying all
patches, it complains that there's a for there that does nothing:

drivers/media/platform/sti/delta/delta-v4l2.c:322 register_decoders() warn: we 
never enter this loop
drivers/media/platform/sti/delta/delta-v4l2.c: In function 'register_decoders':
drivers/media/platform/sti/delta/delta-v4l2.c:322:16: warning: comparison of 
unsigned expression < 0 is always false [-Wtype-limits]
  for (i = 0; i < ARRAY_SIZE(delta_decoders); i++) {
^

On a first glance, it seems that the register_decoders() function is
reponsible to register the format decoders that the hardware
recognizes. If so, I suspect that this driver is deadly broken.

Please be sure that the upstream driver works properly before
submitting it upstream.

Also, please fix the comments to match the Kernel standard. E. g.
instead of:

/* guard output frame count:
 * - at least 1 frame needed for display
 * - at worst 21
 *   ( max h264 dpb (16) +
 * decoding peak smoothing (2) +
 * user display pipeline (3) )
 */

It should be:

/*
 * guard output frame count:
 * - at least 1 frame needed for display
 * - at worst 21
 *   ( max h264 dpb (16) +
 * decoding peak smoothing (2) +
 * user display pipeline (3) )
 */

There are several similar occurrences among this patch series.

Thanks,
Mauro

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

[PATCH 04/14] m5mols: use atomic_dec_not_zero()

[Fabian Frederick]

instead of atomic_add_unless(value, -1, 0)

Signed-off-by: Fabian Frederick 
---
 drivers/media/i2c/m5mols/m5mols_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/m5mols/m5mols_core.c 
b/drivers/media/i2c/m5mols/m5mols_core.c
index acb804b..3aab2ca 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -337,7 +337,7 @@ int m5mols_wait_interrupt(struct v4l2_subdev *sd, u8 
irq_mask, u32 timeout)
struct m5mols_info *info = to_m5mols(sd);
 
int ret = wait_event_interruptible_timeout(info->irq_waitq,
-   atomic_add_unless(>irq_done, -1, 0),
+   atomic_dec_not_zero(>irq_done),
msecs_to_jiffies(timeout));
if (ret <= 0)
return ret ? ret : -ETIMEDOUT;
-- 
2.9.3

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

[PATCH 05/14] omap3isp: use atomic_dec_not_zero()

[Fabian Frederick]

instead of atomic_add_unless(value, -1, 0)

Signed-off-by: Fabian Frederick 
---
 drivers/media/platform/omap3isp/ispstat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap3isp/ispstat.c 
b/drivers/media/platform/omap3isp/ispstat.c
index 47cbc7e..462b1d1 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -620,7 +620,7 @@ static int isp_stat_buf_process(struct ispstat *stat, int 
buf_state)
 {
int ret = STAT_NO_BUF;
 
-   if (!atomic_add_unless(>buf_err, -1, 0) &&
+   if (!atomic_dec_not_zero(>buf_err) &&
buf_state == STAT_BUF_DONE && stat->state == ISPSTAT_ENABLED) {
ret = isp_stat_buf_queue(stat);
isp_stat_buf_next(stat);
-- 
2.9.3

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

[PATCH 00/14] use atomic_dec_not_zero()

[Fabian Frederick]

complementary definition to atomic_inc_not_zero() featured in
lib/fault-inject.c. This small patchset moves it to
include/linux/atomic.h using it instead of
atomic_add_unless(value, -1, 0)

s390 patches were not compile-tested.

Fabian Frederick (14):
  locking/atomic: import atomic_dec_not_zero()
  drm/exynos: use atomic_dec_not_zero()
  drm/omap: use atomic_dec_not_zero()
  m5mols: use atomic_dec_not_zero()
  omap3isp: use atomic_dec_not_zero()
  s390/qeth: use atomic_dec_not_zero()
  PM / RUNTIME: use atomic_dec_not_zero()
  ipmi: use atomic_dec_not_zero()
  kdb: use atomic_dec_not_zero()
  PM / Hibernate: use atomic_dec_not_zero()
  PM: use atomic_dec_not_zero()
  s390/topology: use atomic_dec_not_zero()
  ext4: use atomic_dec_not_zero()
  xfs: use atomic_dec_not_zero()

 arch/s390/kernel/topology.c   | 2 +-
 drivers/base/power/runtime.c  | 4 ++--
 drivers/char/ipmi/ipmi_msghandler.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 2 +-
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c  | 2 +-
 drivers/media/i2c/m5mols/m5mols_core.c| 2 +-
 drivers/media/platform/omap3isp/ispstat.c | 2 +-
 drivers/s390/net/qeth_core_main.c | 2 +-
 fs/ext4/ext4.h| 2 +-
 fs/xfs/xfs_buf.c  | 2 +-
 include/linux/atomic.h| 2 ++
 kernel/debug/kdb/kdb_main.c   | 2 +-
 kernel/power/hibernate.c  | 4 ++--
 kernel/power/user.c   | 2 +-
 lib/fault-inject.c| 2 --
 15 files changed, 17 insertions(+), 17 deletions(-)

-- 
2.9.3

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

Re: [GIT PULL FOR v4.11] Various fixes & enhancements

[Mauro Carvalho Chehab]

Em Mon, 9 Jan 2017 12:22:23 +0100
Hans Verkuil  escreveu:

> The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:
> 
>   [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git for-v4.11a
> 
> for you to fetch changes up to f77fb0d794484029f83605f05bfcd3ef25dab98f:
> 
>   staging/media/s5p-cec/exynos_hdmi_cecctrl.c Fixed blank line before closing 
> brace '}' (2017-01-09 12:07:39 +0100)
> 
> 
> Baruch Siach (2):
>   ov2659: remove NOP assignment
>   adv7170: drop redundant ret local
> 
> Colin Ian King (4):
>   dvb-frontends: fix spelling mistake on cx24123_pll_calcutate
>   cobalt: fix spelling mistake: "Celcius" -> "Celsius"
>   b2c2: fix spelling mistake: "Contunuity" -> "Continuity"
>   gp8psk: fix spelling mistake: "firmare" -> "firmware"
> 
> Corentin Labbe (2):
>   media: s5p-cec: Remove unneeded linux/miscdevice.h include
>   media: s5p-cec: Remove references to non-existent PLAT_S5P symbol
> 
> Hans Verkuil (1):
>   gen-errors.rst: document EIO
> 
> Jean-Christophe Trotin (2):
>   st-hva: encoding summary at instance release
>   st-hva: add debug file system

I didn't merge those; the first one adds an unconditional debug printk
without a good reason. The second one sounds ok, but it depends on
the first patch.

> 
> Lars-Peter Clausen (1):
>   adv7604: Initialize drive strength to default when using DT
> 
> Nicolas Iooss (1):
>   am437x-vpfe: always assign bpp variable
> 
> Scott Matheina (2):
>   staging:media:s5p-cec:exynos_hdmi_cecctrl.c Fixed Alignment should 
> match open parenthesis
>   staging/media/s5p-cec/exynos_hdmi_cecctrl.c Fixed blank line before 
> closing brace '}'
> 
> Soren Brinkmann (1):
>   vivid: Enable 4k resolution for webcam capture device

Merged the remained patches.

Thanks!
Mauro

> 
>  Documentation/media/uapi/gen-errors.rst |  10 +-
>  drivers/media/dvb-frontends/cx24123.c   |   2 +-
>  drivers/media/i2c/adv7170.c |   5 +-
>  drivers/media/i2c/adv7604.c |   3 +
>  drivers/media/i2c/ov2659.c  |   1 -
>  drivers/media/pci/b2c2/flexcop-pci.c|   2 +-
>  drivers/media/pci/cobalt/cobalt-cpld.c  |   4 +-
>  drivers/media/platform/Kconfig  |  11 ++
>  drivers/media/platform/am437x/am437x-vpfe.c |   2 +-
>  drivers/media/platform/sti/hva/Makefile |   1 +
>  drivers/media/platform/sti/hva/hva-debugfs.c| 422 
> 
>  drivers/media/platform/sti/hva/hva-h264.c   |   6 +
>  drivers/media/platform/sti/hva/hva-hw.c |  48 ++
>  drivers/media/platform/sti/hva/hva-hw.h |   3 +
>  drivers/media/platform/sti/hva/hva-mem.c|   5 +-
>  drivers/media/platform/sti/hva/hva-v4l2.c   |  78 +++--
>  drivers/media/platform/sti/hva/hva.h|  96 ++-
>  drivers/media/platform/vivid/vivid-vid-cap.c|   5 +-
>  drivers/media/usb/dvb-usb/gp8psk.c  |   2 +-
>  drivers/staging/media/s5p-cec/Kconfig   |   2 +-
>  drivers/staging/media/s5p-cec/exynos_hdmi_cec.h |   1 -
>  drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c |   5 +-
>  22 files changed, 683 insertions(+), 31 deletions(-)
>  create mode 100644 drivers/media/platform/sti/hva/hva-debugfs.c
> --
> 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



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

Re: [PATCH] Staging: omap4iss: fix coding style issues

[Laurent Pinchart]

Hello Avraham,

Thank you for the patch.

On Saturday 28 Jan 2017 20:00:08 Avraham Shukron wrote:
> This is a patch that fixes checkpatch.pl issues in omap4iss/iss_video.c
> Specifically, it fixes "line over 80 characters" issues
> 
> Signed-off-by: Avraham Shukron 

This looks OK to me. I've applied the patch to my tree and will push it to 
v4.11.

Acked-by: Laurent Pinchart 

> ---
>  drivers/staging/media/omap4iss/iss_video.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index c16927a..cdab053 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -298,7 +298,8 @@ iss_video_check_format(struct iss_video *video, struct
> iss_video_fh *vfh)
> 
>  static int iss_video_queue_setup(struct vb2_queue *vq,
>unsigned int *count, unsigned int 
*num_planes,
> -  unsigned int sizes[], struct device 
*alloc_devs[])
> +  unsigned int sizes[],
> +  struct device *alloc_devs[])
>  {
>   struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
>   struct iss_video *video = vfh->video;
> @@ -678,8 +679,8 @@ iss_video_get_selection(struct file *file, void *fh,
> struct v4l2_selection *sel) if (subdev == NULL)
>   return -EINVAL;
> 
> - /* Try the get selection operation first and fallback to get format if 
not
> -  * implemented.
> + /* Try the get selection operation first and fallback to get format if
> +  * not implemented.
>*/
>   sdsel.pad = pad;
>   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );

-- 
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 RESEND] staging: media: lirc: use new parport device model

[Sean Young]

On Sat, Jan 21, 2017 at 12:55:54AM +, Sudip Mukherjee wrote:
> From: Sudip Mukherjee 
> 
> Modify lirc_parallel driver to use the new parallel port device model.
> 
> Signed-off-by: Sudip Mukherjee 
> ---
> 
> Resending after more than one year.
> Prevoius patch is at https://patchwork.kernel.org/patch/7883591/

Since noone ported lirc_parallel to rc-core, the lirc_parallel staging
driver has been droppped from the current media tree.

I have ported a few other lirc drivers to rc-core but I never found
anyone using lirc_parallel or the hardware itself.


Sean
--
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/3] st-hva: encoding summary at instance release

[Mauro Carvalho Chehab]

Em Mon, 28 Nov 2016 11:30:52 +0100
Jean-Christophe Trotin  escreveu:

> This patch prints unconditionnaly a short summary 

Why? Is this driver so broken that everyone would need an
unconditional "short summary" about what happened there?

If not, then please use dev_dbg() or debugfs instead. If yes, then
we should move this driver to staging.

> about the encoding
> operation at each instance closing, for debug purpose:
> - information about the frame (format, resolution)
> - information about the stream (format, profile, level, resolution)
> - number of encoded frames
> - potential (system, encoding...) errors
> 
> Signed-off-by: Yannick Fertre 
> Signed-off-by: Jean-Christophe Trotin 
> ---
>  drivers/media/platform/sti/hva/hva-h264.c |  6 
>  drivers/media/platform/sti/hva/hva-hw.c   |  5 
>  drivers/media/platform/sti/hva/hva-mem.c  |  5 +++-
>  drivers/media/platform/sti/hva/hva-v4l2.c | 49 
> ---
>  drivers/media/platform/sti/hva/hva.h  |  8 +
>  5 files changed, 62 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/sti/hva/hva-h264.c 
> b/drivers/media/platform/sti/hva/hva-h264.c
> index 8cc8467..e6f247a 100644
> --- a/drivers/media/platform/sti/hva/hva-h264.c
> +++ b/drivers/media/platform/sti/hva/hva-h264.c
> @@ -607,6 +607,7 @@ static int hva_h264_prepare_task(struct hva_ctx *pctx,
>   "%s   width(%d) or height(%d) exceeds limits (%dx%d)\n",
>   pctx->name, frame_width, frame_height,
>   H264_MAX_SIZE_W, H264_MAX_SIZE_H);
> + pctx->frame_errors++;
>   return -EINVAL;
>   }
>  
> @@ -717,6 +718,7 @@ static int hva_h264_prepare_task(struct hva_ctx *pctx,
>   default:
>   dev_err(dev, "%s   invalid source pixel format\n",
>   pctx->name);
> + pctx->frame_errors++;
>   return -EINVAL;
>   }
>  
> @@ -741,6 +743,7 @@ static int hva_h264_prepare_task(struct hva_ctx *pctx,
>  
>   if (td->framerate_den == 0) {
>   dev_err(dev, "%s   invalid framerate\n", pctx->name);
> + pctx->frame_errors++;
>   return -EINVAL;
>   }
>  
> @@ -831,6 +834,7 @@ static int hva_h264_prepare_task(struct hva_ctx *pctx,
>   (payload > MAX_SPS_PPS_SIZE)) {
>   dev_err(dev, "%s   invalid sps/pps size %d\n", pctx->name,
>   payload);
> + pctx->frame_errors++;
>   return -EINVAL;
>   }
>  
> @@ -842,6 +846,7 @@ static int hva_h264_prepare_task(struct hva_ctx *pctx,
>  (u8 *)stream->vaddr,
>  )) {
>   dev_err(dev, "%s   fail to get SEI nal\n", pctx->name);
> + pctx->frame_errors++;
>   return -EINVAL;
>   }
>  
> @@ -963,6 +968,7 @@ static int hva_h264_open(struct hva_ctx *pctx)
>  err_ctx:
>   devm_kfree(dev, ctx);
>  err:
> + pctx->sys_errors++;
>   return ret;
>  }
>  
> diff --git a/drivers/media/platform/sti/hva/hva-hw.c 
> b/drivers/media/platform/sti/hva/hva-hw.c
> index 68d625b..5104068 100644
> --- a/drivers/media/platform/sti/hva/hva-hw.c
> +++ b/drivers/media/platform/sti/hva/hva-hw.c
> @@ -470,6 +470,7 @@ int hva_hw_execute_task(struct hva_ctx *ctx, enum 
> hva_hw_cmd_type cmd,
>  
>   if (pm_runtime_get_sync(dev) < 0) {
>   dev_err(dev, "%s failed to get pm_runtime\n", ctx->name);
> + ctx->sys_errors++;
>   ret = -EFAULT;
>   goto out;
>   }
> @@ -481,6 +482,7 @@ int hva_hw_execute_task(struct hva_ctx *ctx, enum 
> hva_hw_cmd_type cmd,
>   break;
>   default:
>   dev_dbg(dev, "%s unknown command 0x%x\n", ctx->name, cmd);
> + ctx->encode_errors++;
>   ret = -EFAULT;
>   goto out;
>   }
> @@ -511,6 +513,7 @@ int hva_hw_execute_task(struct hva_ctx *ctx, enum 
> hva_hw_cmd_type cmd,
>msecs_to_jiffies(2000))) {
>   dev_err(dev, "%s %s: time out on completion\n", ctx->name,
>   __func__);
> + ctx->encode_errors++;
>   ret = -EFAULT;
>   goto out;
>   }
> @@ -518,6 +521,8 @@ int hva_hw_execute_task(struct hva_ctx *ctx, enum 
> hva_hw_cmd_type cmd,
>   /* get encoding status */
>   ret = ctx->hw_err ? -EFAULT : 0;
>  
> + ctx->encode_errors += ctx->hw_err ? 1 : 0;
> +
>  out:
>   disable_irq(hva->irq_its);
>   disable_irq(hva->irq_err);
> diff --git a/drivers/media/platform/sti/hva/hva-mem.c 
> b/drivers/media/platform/sti/hva/hva-mem.c
> index 649f660..821c78e 100644
> --- a/drivers/media/platform/sti/hva/hva-mem.c
> +++ b/drivers/media/platform/sti/hva/hva-mem.c
> @@ -17,14 +17,17 @@ int hva_mem_alloc(struct 

Re: metadata node

[Stanimir Varbanov]

Hi Guennadi,

On 01/11/2017 11:42 AM, Guennadi Liakhovetski wrote:
> Hi Laurent,
> 
> As you know, I'm working on a project, that involves streaming metadata, 
> obtained from UVC payload headers to the userspace. Luckily, you have 
> created "metadata node" patces a while ago. The core patch has also been 
> acked by Hans, so, I decided it would be a safe enough bet to base my work 
> on top of that.
> 
> Your patch makes creating /dev/video* metadata device nodes possible, but 
> it doesn't provide any means to associate metadata nodes to respective 
> video (image) nodes. Another important aspect of using per-frame metadata 
> is synchronisation between metadata and image buffers.  The user is 
> supposed to use buffer sequence numbers for that. That should be possible, 
> but might be difficult if buffers lose synchronisation at some point. As a 
> solution to the latter problem the use of requests with buffers for both 
> nodes has been proposed, which should be possible once the request API is 
> available.
> 
> An alternative approach to metadata support, e.g. heterogeneous 
> multi-plain buffers with one plain carrying image data and another plain 
> carrying metadata would be possible. It could also have other uses. E.g. 
> we have come across cameras, streaming buffers, containing multiple images 
> (e.g. A and B). Possibly both images have supported fourcc format, but 
> they cannot be re-used, because A+B now are transferred in a single 
> buffer. Instead a new fourcc code has to be invented for such cases to 
> describe A+B.
> 
> As an important argument in favour of having a separate video node for 
> metadata you named cases, when metadata has to be obtained before a 
> complete image is available. Do you remember specifically what those cases 
> are? Or have you got a link to that discussion?
> 
> In any case, _if_ we do keep the current approach of separate /dev/video* 
> nodes, we need a way to associate video and metadata nodes. Earlier I 
> proposed using media controller links for that. In your implementation of 

I don't think that media controller links is a good idea. This metadata
api could be used by mem2mem drivers which don't have media controller
links so we will need a generic v4l2 way to bound image buffer and its
metadata buffer.


-- 
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] Staging: media: lirc: style fix, using octal file permissions

[Sean Young]

On Sat, Jan 07, 2017 at 04:02:55PM +1300, Derek Robson wrote:
> Change file permissions to octal style.
> Found using checkpatch
> 
> Signed-off-by: Derek Robson 
> ---
>  drivers/staging/media/lirc/lirc_imon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/lirc/lirc_imon.c 
> b/drivers/staging/media/lirc/lirc_imon.c
> index 1e650fba4a92..6c8a4a15278e 100644
> --- a/drivers/staging/media/lirc/lirc_imon.c
> +++ b/drivers/staging/media/lirc/lirc_imon.c
> @@ -182,7 +182,7 @@ MODULE_DESCRIPTION(MOD_DESC);
>  MODULE_VERSION(MOD_VERSION);
>  MODULE_LICENSE("GPL");
>  MODULE_DEVICE_TABLE(usb, imon_usb_id_table);
> -module_param(debug, int, S_IRUGO | S_IWUSR);
> +module_param(debug, int, 0644);
>  MODULE_PARM_DESC(debug, "Debug messages: 0=no, 1=yes(default: no)");
>  
>  static void free_imon_context(struct imon_context *context)

In the current media tree, drivers/staging/media/lirc/lirc_imon.c has
been merged with drivers/media/rc/imon.c already, I'm afraid. This
patch no longer applies.


Sean
--
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: [GIT PULL FOR 4.11] RC updates

[Mauro Carvalho Chehab]

Em Tue, 27 Dec 2016 20:45:48 +
Sean Young  escreveu:

> Hi Mauro,
> 
> This pull request is for the ir-spi driver, wakeup changes along
> with the required IR encoders, staging updates.

Patches merged.

>  delete mode 100644 drivers/staging/media/lirc/lirc_bt829.c
>  delete mode 100644 drivers/staging/media/lirc/lirc_imon.c
>  delete mode 100644 drivers/staging/media/lirc/lirc_parallel.c
>  delete mode 100644 drivers/staging/media/lirc/lirc_parallel.h

Thanks for that! Yeah, we should get rid of the stuff under staging and
that nobody cares enough to fix ;)

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

Re: [GIT PULL FOR v4l-utils] ir updates

[Mauro Carvalho Chehab]

Em Tue, 27 Dec 2016 20:49:57 +
Sean Young  escreveu:

> Hi Mauro,
> 
> Some minor fixes for ir-ctl and one for ir-keytable.

Hi Sean,

I suspect that Gregor already merged those patches. If are there any
left-over, just submit what's missing.

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

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Mauro Carvalho Chehab]

Em Mon, 16 Jan 2017 21:13:58 +0100
Pavel Machek  escreveu:

> Hi!
> 
> > On 16.01.2017 12:10, Sean Young wrote:  
> > >
> > >Have you had a chance to test the ir-rx51 changes?
> > >
> > >Thanks
> > >Sean
> > >  
> > 
> > Still no, and afaik there are issues booting n900 with current kernel. Will
> > try to find time over the weekend.  
> 
> v4.10-rc3 (?) works for me on n900. Do you want a working .config?

I'm merging this patch at the media tree. Please report if you
find any issues for us to fix in time for 4.11.

Thanks,
Mauro

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

Re: [PATCH v3 16/24] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Mon, Jan 23, 2017 at 12:13:26PM +0100, Philipp Zabel wrote:
> Hi Steve,
> 
> On Sun, 2017-01-22 at 18:31 -0800, Steve Longerbeam wrote:
> > Second, ignoring the above locking issue for a moment, 
> > v4l2_pipeline_pm_use()
> > will call s_power on the sensor _first_, then the mipi csi-2 s_power, 
> > when executing
> > media-ctl -l '"ov5640 1-003c":0 -> "imx6-mipi-csi2":0[1]'. Which is the 
> > wrong order.
> > In my version which enforces the correct power on order, the mipi csi-2 
> > s_power
> > is called first in that link setup, followed by the sensor.
> 
> I don't understand why you want to power up subdevs as soon as the links
> are established. Shouldn't that rather be done for all subdevices in the
> pipeline when the corresponding capture device is opened?
> It seems to me that powering up the pipeline should be the last step
> before userspace actually starts the capture.

I agree with Philipp here - configuration of the software pipeline
shouldn't result in hardware being forced to be powered up.  That's
more of a decision for the individual sub-driver than for core.

Executing media-ctl to enable a link between two sub-device endpoints
should really be a matter of setting the software state, and when the
video device is opened for streaming, surely that's when the hardware
in the chain between the source and the capture device should be
powered up and programmed.

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

[PATCHv2 15/16] sama5d3 dts: enable atmel-isi

[Hans Verkuil]

From: Hans Verkuil 

This illustrates the changes needed to the dts in order to hook up the
ov7670. I don't plan on merging this.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/at91-sama5d3_xplained.dts | 61 ++---
 arch/arm/boot/dts/sama5d3.dtsi  |  4 +-
 2 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index c51fc65..2af24f7 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -65,18 +65,53 @@
status = "okay";
};
 
+   isi0: isi@f0034000 {
+   status = "okay";
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   isi_0: endpoint {
+   reg = <0>;
+   remote-endpoint = <_0>;
+   bus-width = <8>;
+   vsync-active = <1>;
+   hsync-active = <1>;
+   };
+   };
+   };
+
i2c0: i2c@f0014000 {
pinctrl-0 = <_i2c0_pu>;
-   status = "okay";
+   status = "disabled";
};
 
i2c1: i2c@f0018000 {
status = "okay";
 
+   ov7670: camera@0x21 {
+   compatible = "ovti,ov7670";
+   reg = <0x21>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pck0_as_isi_mck 
_sensor_power _sensor_reset>;
+   resetb-gpios = < 11 
GPIO_ACTIVE_LOW>;
+   pwdn-gpios = < 13 
GPIO_ACTIVE_HIGH>;
+   clocks = <>;
+   clock-names = "xclk";
+   assigned-clocks = <>;
+   assigned-clock-rates = <2500>;
+
+   port {
+   ov7670_0: endpoint {
+   remote-endpoint = 
<_0>;
+   bus-width = <8>;
+   };
+   };
+   };
+
pmic: act8865@5b {
compatible = "active-semi,act8865";
reg = <0x5b>;
-   status = "disabled";
+   status = "okay";
 
regulators {
vcc_1v8_reg: DCDC_REG1 {
@@ -130,7 +165,7 @@
pwm0: pwm@f002c000 {
pinctrl-names = "default";
pinctrl-0 = <_pwm0_pwmh0_0 
_pwm0_pwmh1_0>;
-   status = "okay";
+   status = "disabled";
};
 
usart0: serial@f001c000 {
@@ -143,7 +178,7 @@
};
 
uart0: serial@f0024000 {
-   status = "okay";
+   status = "disabled";
};
 
mmc1: mmc@f800 {
@@ -181,7 +216,7 @@
i2c2: i2c@f801c000 {
dmas = <0>, <0>;/* Do not use DMA for 
i2c2 */
pinctrl-0 = <_i2c2_pu>;
-   status = "okay";
+   status = "disabled";
};
 
macb1: ethernet@f802c000 {
@@ -200,6 +235,22 @@
};
 
pinctrl@f200 {
+   camera_sensor {
+   pinctrl_pck0_as_isi_mck: 
pck0_as_isi_mck-0 {
+   atmel,pins =
+   ; /* ISI_MCK */
+   };
+
+   pinctrl_sensor_power: sensor_power-0 {
+   atmel,pins =
+ 

[PATCHv2 14/16] em28xx: drop last soc_camera link

[Hans Verkuil]

From: Hans Verkuil 

The em28xx driver still used the soc_camera.h header for the ov2640
driver. Since this driver no longer uses soc_camera, that include can
be removed.

Signed-off-by: Hans Verkuil 
---
 drivers/media/usb/em28xx/em28xx-camera.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 89c890b..63aaa57 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -23,7 +23,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -43,13 +42,6 @@ static unsigned short omnivision_sensor_addrs[] = {
I2C_CLIENT_END
 };
 
-static struct soc_camera_link camlink = {
-   .bus_id = 0,
-   .flags = 0,
-   .module_name = "em28xx",
-   .unbalanced_power = true,
-};
-
 /* FIXME: Should be replaced by a proper mt9m111 driver */
 static int em28xx_initialize_mt9m111(struct em28xx *dev)
 {
@@ -421,7 +413,6 @@ int em28xx_init_camera(struct em28xx *dev)
.type = "ov2640",
.flags = I2C_CLIENT_SCCB,
.addr = client->addr,
-   .platform_data = ,
};
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
-- 
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

[PATCHv2 13/16] ov2640: update bindings

[Hans Verkuil]

From: Hans Verkuil 

Update the bindings for this device based on a working DT example.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/i2c/ov2640.txt   | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
index c429b5b..5e6c445 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
@@ -1,8 +1,8 @@
 * Omnivision OV2640 CMOS sensor
 
-The Omnivision OV2640 sensor support multiple resolutions output, such as
-CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
-output format.
+The Omnivision OV2640 sensor supports multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support the YUV422/420, RGB565/555 or raw RGB
+output formats.
 
 Required Properties:
 - compatible: should be "ovti,ov2640"
@@ -20,20 +20,18 @@ 
Documentation/devicetree/bindings/media/video-interfaces.txt.
 Example:
 
i2c1: i2c@f0018000 {
+   status = "okay";
+
ov2640: camera@0x30 {
compatible = "ovti,ov2640";
reg = <0x30>;
-
pinctrl-names = "default";
-   pinctrl-0 = <_pck1 _ov2640_pwdn 
_ov2640_resetb>;
-
-   resetb-gpios = < 24 GPIO_ACTIVE_LOW>;
-   pwdn-gpios = < 29 GPIO_ACTIVE_HIGH>;
-
-   clocks = <>;
+   pinctrl-0 = <_pck0_as_isi_mck 
_sensor_power _sensor_reset>;
+   resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
+   pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   clocks = <>;
clock-names = "xvclk";
-
-   assigned-clocks = <>;
+   assigned-clocks = <>;
assigned-clock-rates = <2500>;
 
port {
-- 
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

[PATCHv2 16/16] at91-sama5d3_xplained.dts: select ov2640

[Hans Verkuil]

From: Hans Verkuil 

This patch replaces the ov7670 with the ov2640. This patch is not
meant to be merged but is for demonstration purposes only.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/at91-sama5d3_xplained.dts | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 2af24f7..d5f7e82 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -72,7 +72,7 @@
#size-cells = <0>;
isi_0: endpoint {
reg = <0>;
-   remote-endpoint = <_0>;
+   remote-endpoint = <_0>;
bus-width = <8>;
vsync-active = <1>;
hsync-active = <1>;
@@ -88,20 +88,20 @@
i2c1: i2c@f0018000 {
status = "okay";
 
-   ov7670: camera@0x21 {
-   compatible = "ovti,ov7670";
-   reg = <0x21>;
+   ov2640: camera@0x30 {
+   compatible = "ovti,ov2640";
+   reg = <0x30>;
pinctrl-names = "default";
pinctrl-0 = <_pck0_as_isi_mck 
_sensor_power _sensor_reset>;
resetb-gpios = < 11 
GPIO_ACTIVE_LOW>;
pwdn-gpios = < 13 
GPIO_ACTIVE_HIGH>;
clocks = <>;
-   clock-names = "xclk";
+   clock-names = "xvclk";
assigned-clocks = <>;
assigned-clock-rates = <2500>;
 
port {
-   ov7670_0: endpoint {
+   ov2640_0: endpoint {
remote-endpoint = 
<_0>;
bus-width = <8>;
};
-- 
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

[PATCHv2 09/16] ov2640: convert from soc-camera to a standard subdev sensor driver.

[Hans Verkuil]

From: Hans Verkuil 

Convert ov2640 to a standard subdev driver. The soc-camera driver no longer
uses this driver, so it can safely be converted.

Note: the s_power op has been dropped: this never worked. When the last open()
is closed, then the power is turned off, and when it is opened again the power
is turned on again, but the old state isn't restored.

Someone else can figure out in the future how to get this working correctly,
but I don't want to spend more time on this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/Kconfig   | 11 
 drivers/media/i2c/Makefile  |  1 +
 drivers/media/i2c/{soc_camera => }/ov2640.c | 89 +
 drivers/media/i2c/soc_camera/Kconfig|  6 --
 drivers/media/i2c/soc_camera/Makefile   |  1 -
 5 files changed, 27 insertions(+), 81 deletions(-)
 rename drivers/media/i2c/{soc_camera => }/ov2640.c (94%)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b979ea1..159ef64 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -520,6 +520,17 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_OV2640
+   tristate "OmniVision OV2640 sensor support"
+   depends on VIDEO_V4L2 && I2C
+   depends on MEDIA_CAMERA_SUPPORT
+   help
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2640 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2640.
+
 config VIDEO_OV2659
tristate "OmniVision OV2659 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2..6388ec9a9 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_OV2640) += ov2640.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/soc_camera/ov2640.c b/drivers/media/i2c/ov2640.c
similarity index 94%
rename from drivers/media/i2c/soc_camera/ov2640.c
rename to drivers/media/i2c/ov2640.c
index b9a0069..83f88ef 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -24,8 +24,8 @@
 #include 
 #include 
 
-#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -287,7 +287,6 @@ struct ov2640_priv {
struct v4l2_clk *clk;
const struct ov2640_win_size*win;
 
-   struct soc_camera_subdev_desc   ssdd_dt;
struct gpio_desc *resetb_gpio;
struct gpio_desc *pwdn_gpio;
 };
@@ -677,13 +676,8 @@ static int ov2640_reset(struct i2c_client *client)
 }
 
 /*
- * soc_camera_ops functions
+ * functions
  */
-static int ov2640_s_stream(struct v4l2_subdev *sd, int enable)
-{
-   return 0;
-}
-
 static int ov2640_s_ctrl(struct v4l2_ctrl *ctrl)
 {
struct v4l2_subdev *sd =
@@ -744,10 +738,16 @@ static int ov2640_s_register(struct v4l2_subdev *sd,
 static int ov2640_s_power(struct v4l2_subdev *sd, int on)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
 
-   return soc_camera_set_power(>dev, ssdd, priv->clk, on);
+   gpiod_direction_output(priv->pwdn_gpio, !on);
+   if (on && priv->resetb_gpio) {
+   /* Active the resetb pin to perform a reset pulse */
+   gpiod_direction_output(priv->resetb_gpio, 1);
+   usleep_range(3000, 5000);
+   gpiod_direction_output(priv->resetb_gpio, 0);
+   }
+   return 0;
 }
 
 /* Select the nearest higher resolution for capture */
@@ -994,26 +994,6 @@ static struct v4l2_subdev_core_ops ov2640_subdev_core_ops 
= {
.s_power= ov2640_s_power,
 };
 
-static int ov2640_g_mbus_config(struct v4l2_subdev *sd,
-   struct v4l2_mbus_config *cfg)
-{
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
-   cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
-   V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
-   V4L2_MBUS_DATA_ACTIVE_HIGH;
-   cfg->type = V4L2_MBUS_PARALLEL;
-   cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
-
-   return 0;
-}
-
-static struct v4l2_subdev_video_ops ov2640_subdev_video_ops = {
-   .s_stream   = ov2640_s_stream,
-   .g_mbus_config  = ov2640_g_mbus_config,
-};
-
 static const struct v4l2_subdev_pad_ops ov2640_subdev_pad_ops = {
.enum_mbus_code = 

[PATCHv2 12/16] ov2640: add MC support

[Hans Verkuil]

From: Hans Verkuil 

The MC support is needed by the em28xx driver.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ov2640.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index bd96889..29d4217 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -281,6 +281,9 @@ struct ov2640_win_size {
 
 struct ov2640_priv {
struct v4l2_subdev  subdev;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   struct media_pad pad;
+#endif
struct v4l2_ctrl_handlerhdl;
u32 cfmt_code;
struct clk  *clk;
@@ -1053,19 +1056,30 @@ static int ov2640_probe(struct i2c_client *client,
ret = priv->hdl.error;
goto err_hdl;
}
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   priv->pad.flags = MEDIA_PAD_FL_SOURCE;
+   priv->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+   ret = media_entity_pads_init(>subdev.entity, 1, >pad);
+   if (ret < 0)
+   goto err_hdl;
+#endif
 
ret = ov2640_video_probe(client);
if (ret < 0)
-   goto err_hdl;
+   goto err_videoprobe;
 
ret = v4l2_async_register_subdev(>subdev);
if (ret < 0)
-   goto err_hdl;
+   goto err_videoprobe;
 
dev_info(>dev, "OV2640 Probed\n");
 
return 0;
 
+err_videoprobe:
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   media_entity_cleanup(>subdev.entity);
+#endif
 err_hdl:
v4l2_ctrl_handler_free(>hdl);
return ret;
@@ -1077,6 +1091,9 @@ static int ov2640_remove(struct i2c_client *client)
 
v4l2_async_unregister_subdev(>subdev);
v4l2_ctrl_handler_free(>hdl);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   media_entity_cleanup(>subdev.entity);
+#endif
v4l2_device_unregister_subdev(>subdev);
return 0;
 }
-- 
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

[PATCHv2 11/16] ov2640: allow use inside em28xx

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/Kconfig  |  2 +-
 drivers/media/i2c/ov2640.c | 14 +-
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 159ef64..1859783 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -522,7 +522,7 @@ config VIDEO_SMIAPP_PLL
 
 config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
-   depends on VIDEO_V4L2 && I2C
+   depends on GPIOLIB && VIDEO_V4L2 && I2C
depends on MEDIA_CAMERA_SUPPORT
help
  This is a Video4Linux2 sensor-level driver for the OmniVision
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 565742b..bd96889 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -1031,15 +1031,11 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
 
-   priv->clk = clk_get(>dev, "xvclk");
-   if (IS_ERR(priv->clk))
-   return -EPROBE_DEFER;
-   clk_prepare_enable(priv->clk);
-
-   if (!client->dev.of_node) {
-   dev_err(>dev, "Missing platform_data for driver\n");
-   ret = -EINVAL;
-   goto err_clk;
+   if (client->dev.of_node) {
+   priv->clk = clk_get(>dev, "xvclk");
+   if (IS_ERR(priv->clk))
+   return -EPROBE_DEFER;
+   clk_prepare_enable(priv->clk);
}
 
ret = ov2640_init_gpio(client, priv);
-- 
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

[PATCHv2 08/16] atmel-isi: document device tree bindings

[Hans Verkuil]

From: Hans Verkuil 

Document the device tree bindings for this driver.

Mostly copied from the atmel-isc bindings.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/atmel-isi.txt| 91 +-
 1 file changed, 56 insertions(+), 35 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt 
b/Documentation/devicetree/bindings/media/atmel-isi.txt
index 251f008..d1934b4 100644
--- a/Documentation/devicetree/bindings/media/atmel-isi.txt
+++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
@@ -1,51 +1,72 @@
-Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
---
+Atmel Image Sensor Interface (ISI)
+--
 
-Required properties:
-- compatible: must be "atmel,at91sam9g45-isi"
-- reg: physical base address and length of the registers set for the device;
-- interrupts: should contain IRQ line for the ISI;
-- clocks: list of clock specifiers, corresponding to entries in
-  the clock-names property;
-- clock-names: must contain "isi_clk", which is the isi peripherial clock.
+Required properties for ISI:
+- compatible
+   Must be "atmel,at91sam9g45-isi".
+- reg
+   Physical base address and length of the registers set for the device.
+- interrupts
+   Should contain IRQ line for the ISI.
+- clocks
+   List of clock specifiers, corresponding to entries in
+   the clock-names property;
+   Please refer to clock-bindings.txt.
+- clock-names
+   Required elements: "isi_clk".
+- #clock-cells
+   Should be 0.
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
 
 ISI supports a single port node with parallel bus. It should contain one
 'port' child node with child 'endpoint' node. Please refer to the bindings
 defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
 
 Example:
-   isi: isi@f0034000 {
-   compatible = "atmel,at91sam9g45-isi";
-   reg = <0xf0034000 0x4000>;
-   interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
 
-   clocks = <_clk>;
-   clock-names = "isi_clk";
+isi: isi@f0034000 {
+   compatible = "atmel,at91sam9g45-isi";
+   reg = <0xf0034000 0x4000>;
+   interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_isi_data_0_7>;
+   clocks = <_clk>;
+   clock-names = "isi_clk";
+   status = "ok";
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   isi_0: endpoint {
+   reg = <0>;
+   remote-endpoint = <_0>;
+   bus-width = <8>;
+   vsync-active = <1>;
+   hsync-active = <1>;
+   };
+   };
+};
+
+i2c1: i2c@f0018000 {
+   status = "okay";
 
+   ov2640: camera@0x30 {
+   compatible = "ovti,ov2640";
+   reg = <0x30>;
pinctrl-names = "default";
-   pinctrl-0 = <_isi>;
+   pinctrl-0 = <_pck0_as_isi_mck _sensor_power 
_sensor_reset>;
+   resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
+   pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   clocks = <>;
+   clock-names = "xvclk";
+   assigned-clocks = <>;
+   assigned-clock-rates = <2500>;
 
port {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   isi_0: endpoint {
-   remote-endpoint = <_0>;
+   ov2640_0: endpoint {
+   remote-endpoint = <_0>;
bus-width = <8>;
};
};
};
-
-   i2c1: i2c@f0018000 {
-   ov2640: camera@0x30 {
-   compatible = "ovti,ov2640";
-   reg = <0x30>;
-
-   port {
-   ov2640_0: endpoint {
-   remote-endpoint = <_0>;
-   bus-width = <8>;
-   };
-   };
-   };
-   };
+};
-- 
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

[PATCHv2 10/16] ov2640: enable clock and fix power/reset

[Hans Verkuil]

From: Hans Verkuil 

Convert v4l2_clk to normal clk, enable the clock and fix the power/reset
handling.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ov2640.c | 80 +-
 1 file changed, 29 insertions(+), 51 deletions(-)

diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 83f88ef..565742b 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -16,15 +16,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -284,7 +283,7 @@ struct ov2640_priv {
struct v4l2_subdev  subdev;
struct v4l2_ctrl_handlerhdl;
u32 cfmt_code;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
const struct ov2640_win_size*win;
 
struct gpio_desc *resetb_gpio;
@@ -656,8 +655,9 @@ static int ov2640_mask_set(struct i2c_client *client,
return i2c_smbus_write_byte_data(client, reg, val);
 }
 
-static int ov2640_reset(struct i2c_client *client)
+static int ov2640_reset(struct v4l2_subdev *sd, u32 val)
 {
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret;
const struct regval_list reset_seq[] = {
{BANK_SEL, BANK_SEL_SENS},
@@ -735,21 +735,6 @@ static int ov2640_s_register(struct v4l2_subdev *sd,
 }
 #endif
 
-static int ov2640_s_power(struct v4l2_subdev *sd, int on)
-{
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct ov2640_priv *priv = to_ov2640(client);
-
-   gpiod_direction_output(priv->pwdn_gpio, !on);
-   if (on && priv->resetb_gpio) {
-   /* Active the resetb pin to perform a reset pulse */
-   gpiod_direction_output(priv->resetb_gpio, 1);
-   usleep_range(3000, 5000);
-   gpiod_direction_output(priv->resetb_gpio, 0);
-   }
-   return 0;
-}
-
 /* Select the nearest higher resolution for capture */
 static const struct ov2640_win_size *ov2640_select_win(u32 *width, u32 *height)
 {
@@ -769,9 +754,10 @@ static const struct ov2640_win_size *ov2640_select_win(u32 
*width, u32 *height)
return _supported_win_sizes[default_size];
 }
 
-static int ov2640_set_params(struct i2c_client *client, u32 *width, u32 
*height,
+static int ov2640_set_params(struct v4l2_subdev *sd, u32 *width, u32 *height,
 u32 code)
 {
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov2640_priv   *priv = to_ov2640(client);
const struct regval_list *selected_cfmt_regs;
int ret;
@@ -802,7 +788,7 @@ static int ov2640_set_params(struct i2c_client *client, u32 
*width, u32 *height,
}
 
/* reset hardware */
-   ov2640_reset(client);
+   ov2640_reset(sd, 0);
 
/* initialize the sensor with default data */
dev_dbg(>dev, "%s: Init default", __func__);
@@ -840,7 +826,7 @@ static int ov2640_set_params(struct i2c_client *client, u32 
*width, u32 *height,
 
 err:
dev_err(>dev, "%s: Error %d", __func__, ret);
-   ov2640_reset(client);
+   ov2640_reset(sd, 0);
priv->win = NULL;
 
return ret;
@@ -877,7 +863,6 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_format *format)
 {
struct v4l2_mbus_framefmt *mf = >format;
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
 
if (format->pad)
return -EINVAL;
@@ -902,7 +887,7 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
}
 
if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE)
-   return ov2640_set_params(client, >width,
+   return ov2640_set_params(sd, >width,
 >height, mf->code);
cfg->try_fmt = *mf;
return 0;
@@ -947,10 +932,6 @@ static int ov2640_video_probe(struct i2c_client *client)
const char *devname;
int ret;
 
-   ret = ov2640_s_power(>subdev, 1);
-   if (ret < 0)
-   return ret;
-
/*
 * check and show product ID and manufacturer ID
 */
@@ -978,7 +959,6 @@ static int ov2640_video_probe(struct i2c_client *client)
ret = v4l2_ctrl_handler_setup(>hdl);
 
 done:
-   ov2640_s_power(>subdev, 0);
return ret;
 }
 
@@ -991,7 +971,7 @@ static struct v4l2_subdev_core_ops ov2640_subdev_core_ops = 
{
.g_register = ov2640_g_register,
.s_register = ov2640_s_register,
 #endif
-   .s_power= ov2640_s_power,
+   .reset  = ov2640_reset,
 };
 
 static const struct v4l2_subdev_pad_ops ov2640_subdev_pad_ops = {
@@ -1006,9 +986,17 @@ static struct v4l2_subdev_ops ov2640_subdev_ops = {
.pad= _subdev_pad_ops,
 };
 
-static int ov2640_probe_dt(struct i2c_client *client,
-   

[PATCHv2 06/16] atmel-isi: remove dependency of the soc-camera framework

[Hans Verkuil]

From: Hans Verkuil 

This patch converts the atmel-isi driver from a soc-camera driver to a driver
that is stand-alone.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/soc_camera/ov2640.c |   23 +-
 drivers/media/platform/soc_camera/Kconfig |3 +-
 drivers/media/platform/soc_camera/atmel-isi.c | 1223 +++--
 3 files changed, 735 insertions(+), 514 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
b/drivers/media/i2c/soc_camera/ov2640.c
index 56de182..b9a0069 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -794,10 +794,11 @@ static int ov2640_set_params(struct i2c_client *client, 
u32 *width, u32 *height,
dev_dbg(>dev, "%s: Selected cfmt YUYV (YUV422)", 
__func__);
selected_cfmt_regs = ov2640_yuyv_regs;
break;
-   default:
case MEDIA_BUS_FMT_UYVY8_2X8:
+   default:
dev_dbg(>dev, "%s: Selected cfmt UYVY", __func__);
selected_cfmt_regs = ov2640_uyvy_regs;
+   break;
}
 
/* reset hardware */
@@ -865,17 +866,7 @@ static int ov2640_get_fmt(struct v4l2_subdev *sd,
mf->width   = priv->win->width;
mf->height  = priv->win->height;
mf->code= priv->cfmt_code;
-
-   switch (mf->code) {
-   case MEDIA_BUS_FMT_RGB565_2X8_BE:
-   case MEDIA_BUS_FMT_RGB565_2X8_LE:
-   mf->colorspace = V4L2_COLORSPACE_SRGB;
-   break;
-   default:
-   case MEDIA_BUS_FMT_YUYV8_2X8:
-   case MEDIA_BUS_FMT_UYVY8_2X8:
-   mf->colorspace = V4L2_COLORSPACE_JPEG;
-   }
+   mf->colorspace  = V4L2_COLORSPACE_SRGB;
mf->field   = V4L2_FIELD_NONE;
 
return 0;
@@ -897,17 +888,17 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
ov2640_select_win(>width, >height);
 
mf->field   = V4L2_FIELD_NONE;
+   mf->colorspace  = V4L2_COLORSPACE_SRGB;
 
switch (mf->code) {
case MEDIA_BUS_FMT_RGB565_2X8_BE:
case MEDIA_BUS_FMT_RGB565_2X8_LE:
-   mf->colorspace = V4L2_COLORSPACE_SRGB;
+   case MEDIA_BUS_FMT_YUYV8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
break;
default:
mf->code = MEDIA_BUS_FMT_UYVY8_2X8;
-   case MEDIA_BUS_FMT_YUYV8_2X8:
-   case MEDIA_BUS_FMT_UYVY8_2X8:
-   mf->colorspace = V4L2_COLORSPACE_JPEG;
+   break;
}
 
if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE)
diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 86d7478..a37ec91 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -29,9 +29,8 @@ config VIDEO_SH_MOBILE_CEU
 
 config VIDEO_ATMEL_ISI
tristate "ATMEL Image Sensor Interface (ISI) support"
-   depends on VIDEO_DEV && SOC_CAMERA
+   depends on VIDEO_V4L2 && OF && HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
---help---
  This module makes the ATMEL Image Sensor Interface available
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index 46de657..a837b942 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -22,18 +22,22 @@
 #include 
 #include 
 #include 
-
-#include 
-#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include "atmel-isi.h"
 
-#define MAX_BUFFER_NUM 32
 #define MAX_SUPPORT_WIDTH  2048
 #define MAX_SUPPORT_HEIGHT 2048
-#define VID_LIMIT_BYTES(16 * 1024 * 1024)
 #define MIN_FRAME_RATE 15
 #define FRAME_INTERVAL_MILLI_SEC   (1000 / MIN_FRAME_RATE)
 
@@ -65,9 +69,37 @@ struct frame_buffer {
struct list_head list;
 };
 
+struct isi_graph_entity {
+   struct device_node *node;
+
+   struct v4l2_async_subdev asd;
+   struct v4l2_subdev *subdev;
+};
+
+/*
+ * struct isi_format - ISI media bus format information
+ * @fourcc:Fourcc code for this format
+ * @mbus_code: V4L2 media bus format code.
+ * @bpp:   Bytes per pixel (when stored in memory)
+ * @swap:  Byte swap configuration value
+ * @support:   Indicates format supported by subdev
+ * @skip:  Skip duplicate format supported by subdev
+ */
+struct isi_format {
+   u32 fourcc;
+   u32 mbus_code;
+   u8  bpp;
+   u32 swap;
+
+   boolsupport;
+   boolskip;
+};
+
+
 struct atmel_isi {
/* Protects the access of variables shared with the ISR */
-   spinlock_t  lock;
+   spinlock_t  

[PATCHv2 02/16] ov7670: fix g/s_parm

[Hans Verkuil]

From: Hans Verkuil 

Drop unnecesary memset. Drop the unnecessary extendedmode check and
set the V4L2_CAP_TIMEPERFRAME capability.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ov7670.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9af8d3b..50e4466 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1046,7 +1046,6 @@ static int ov7670_g_parm(struct v4l2_subdev *sd, struct 
v4l2_streamparm *parms)
if (parms->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
 
-   memset(cp, 0, sizeof(struct v4l2_captureparm));
cp->capability = V4L2_CAP_TIMEPERFRAME;
info->devtype->get_framerate(sd, >timeperframe);
 
@@ -1061,9 +1060,8 @@ static int ov7670_s_parm(struct v4l2_subdev *sd, struct 
v4l2_streamparm *parms)
 
if (parms->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
-   if (cp->extendedmode != 0)
-   return -EINVAL;
 
+   cp->capability = V4L2_CAP_TIMEPERFRAME;
return info->devtype->set_framerate(sd, tpf);
 }
 
-- 
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

[PATCHv2 05/16] ov7670: document device tree bindings

[Hans Verkuil]

From: Hans Verkuil 

Add binding documentation and add that file to the MAINTAINERS entry.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/i2c/ov7670.txt   | 44 ++
 MAINTAINERS|  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
new file mode 100644
index 000..a014694
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
@@ -0,0 +1,44 @@
+* Omnivision OV7670 CMOS sensor
+
+The Omnivision OV7670 sensor supports multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support the YUV422/420, RGB565/555 or raw RGB
+output formats.
+
+Required Properties:
+- compatible: should be "ovti,ov7670"
+- clocks: reference to the xclk input clock.
+- clock-names: should be "xclk".
+
+Optional Properties:
+- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
+- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
+
+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:
+
+   i2c1: i2c@f0018000 {
+   status = "okay";
+
+   ov7670: camera@0x21 {
+   compatible = "ovti,ov7670";
+   reg = <0x21>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pck0_as_isi_mck 
_sensor_power _sensor_reset>;
+   resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
+   pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   clocks = <>;
+   clock-names = "xclk";
+   assigned-clocks = <>;
+   assigned-clock-rates = <2500>;
+
+   port {
+   ov7670_0: endpoint {
+   remote-endpoint = <_0>;
+   bus-width = <8>;
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9..67df205 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9101,6 +9101,7 @@ L:linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov7670.c
+F: Documentation/devicetree/bindings/media/i2c/ov7670.txt
 
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
-- 
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

[PATCHv2 07/16] atmel-isi: move out of soc_camera to atmel

[Hans Verkuil]

From: Hans Verkuil 

Move this out of the soc_camera directory into the atmel directory
where it belongs.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Makefile  |  1 +
 drivers/media/platform/atmel/Kconfig | 11 ++-
 drivers/media/platform/atmel/Makefile|  1 +
 drivers/media/platform/{soc_camera => atmel}/atmel-isi.c |  0
 drivers/media/platform/{soc_camera => atmel}/atmel-isi.h |  0
 drivers/media/platform/soc_camera/Kconfig| 10 --
 drivers/media/platform/soc_camera/Makefile   |  1 -
 7 files changed, 12 insertions(+), 12 deletions(-)
 rename drivers/media/platform/{soc_camera => atmel}/atmel-isi.c (100%)
 rename drivers/media/platform/{soc_camera => atmel}/atmel-isi.h (100%)

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb27..15f4f69 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/
 obj-$(CONFIG_VIDEO_RCAR_VIN)   += rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)  += atmel/
+obj-$(CONFIG_VIDEO_ATMEL_ISI)  += atmel/
 
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
diff --git a/drivers/media/platform/atmel/Kconfig 
b/drivers/media/platform/atmel/Kconfig
index 867dca2..9bd0f19 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -6,4 +6,13 @@ config VIDEO_ATMEL_ISC
select REGMAP_MMIO
help
   This module makes the ATMEL Image Sensor Controller available
-  as a v4l2 device.
\ No newline at end of file
+  as a v4l2 device.
+
+config VIDEO_ATMEL_ISI
+   tristate "ATMEL Image Sensor Interface (ISI) support"
+   depends on VIDEO_V4L2 && OF && HAS_DMA
+   depends on ARCH_AT91 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This module makes the ATMEL Image Sensor Interface available
+ as a v4l2 device.
diff --git a/drivers/media/platform/atmel/Makefile 
b/drivers/media/platform/atmel/Makefile
index 9d7c999..27000d0 100644
--- a/drivers/media/platform/atmel/Makefile
+++ b/drivers/media/platform/atmel/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o
+obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/atmel/atmel-isi.c
similarity index 100%
rename from drivers/media/platform/soc_camera/atmel-isi.c
rename to drivers/media/platform/atmel/atmel-isi.c
diff --git a/drivers/media/platform/soc_camera/atmel-isi.h 
b/drivers/media/platform/atmel/atmel-isi.h
similarity index 100%
rename from drivers/media/platform/soc_camera/atmel-isi.h
rename to drivers/media/platform/atmel/atmel-isi.h
diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index a37ec91..0c581aa 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -26,13 +26,3 @@ config VIDEO_SH_MOBILE_CEU
select SOC_CAMERA_SCALE_CROP
---help---
  This is a v4l2 driver for the SuperH Mobile CEU Interface
-
-config VIDEO_ATMEL_ISI
-   tristate "ATMEL Image Sensor Interface (ISI) support"
-   depends on VIDEO_V4L2 && OF && HAS_DMA
-   depends on ARCH_AT91 || COMPILE_TEST
-   select VIDEOBUF2_DMA_CONTIG
-   ---help---
- This module makes the ATMEL Image Sensor Interface available
- as a v4l2 device.
-
diff --git a/drivers/media/platform/soc_camera/Makefile 
b/drivers/media/platform/soc_camera/Makefile
index 7633a0f..07a451e 100644
--- a/drivers/media/platform/soc_camera/Makefile
+++ b/drivers/media/platform/soc_camera/Makefile
@@ -6,5 +6,4 @@ obj-$(CONFIG_SOC_CAMERA_SCALE_CROP) += soc_scale_crop.o
 obj-$(CONFIG_SOC_CAMERA_PLATFORM)  += soc_camera_platform.o
 
 # soc-camera host drivers have to be linked after camera drivers
-obj-$(CONFIG_VIDEO_ATMEL_ISI)  += atmel-isi.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
-- 
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

[PATCHv2 01/16] ov7670: call v4l2_async_register_subdev

[Hans Verkuil]

From: Hans Verkuil 

Add v4l2-async support for this driver.

Signed-off-by: Hans Verkuil 
Acked-by: Sakari Ailus 
---
 drivers/media/i2c/ov7670.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 56cfb5c..9af8d3b 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1636,10 +1636,9 @@ static int ov7670_probe(struct i2c_client *client,
V4L2_EXPOSURE_AUTO);
sd->ctrl_handler = >hdl;
if (info->hdl.error) {
-   int err = info->hdl.error;
+   ret = info->hdl.error;
 
-   v4l2_ctrl_handler_free(>hdl);
-   return err;
+   goto hdl_free;
}
/*
 * We have checked empirically that hw allows to read back the gain
@@ -1651,7 +1650,15 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_cluster(2, >saturation);
v4l2_ctrl_handler_setup(>hdl);
 
+   ret = v4l2_async_register_subdev(>sd);
+   if (ret < 0)
+   goto hdl_free;
+
return 0;
+
+hdl_free:
+   v4l2_ctrl_handler_free(>hdl);
+   return ret;
 }
 
 
-- 
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

[PATCHv2 03/16] ov7670: get xclk

[Hans Verkuil]

From: Hans Verkuil 

Get the clock for this sensor.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ov7670.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 50e4466..da08436 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -10,6 +10,7 @@
  * This file may be distributed under the terms of the GNU General
  * Public License, version 2.
  */
+#include 
 #include 
 #include 
 #include 
@@ -227,6 +228,7 @@ struct ov7670_info {
struct v4l2_ctrl *hue;
};
struct ov7670_format_struct *fmt;  /* Current format */
+   struct clk *clk;
int min_width;  /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -1587,6 +1589,15 @@ static int ov7670_probe(struct i2c_client *client,
info->pclk_hb_disable = true;
}
 
+   info->clk = devm_clk_get(>dev, "xclk");
+   if (IS_ERR(info->clk))
+   return -EPROBE_DEFER;
+   clk_prepare_enable(info->clk);
+
+   info->clock_speed = clk_get_rate(info->clk) / 100;
+   if (info->clock_speed < 10 || info->clock_speed > 48)
+   return -EINVAL;
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
@@ -1667,6 +1678,7 @@ static int ov7670_remove(struct i2c_client *client)
 
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
+   clk_disable_unprepare(info->clk);
return 0;
 }
 
-- 
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

[PATCHv2 04/16] ov7670: add devicetree support

[Hans Verkuil]

From: Hans Verkuil 

Add DT support. Use it to get the reset and pwdn pins (if there are any).
Tested with one sensor requiring reset/pwdn and one sensor that doesn't
have reset/pwdn pins.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ov7670.c | 42 --
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index da08436..24f388e 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -229,6 +231,8 @@ struct ov7670_info {
};
struct ov7670_format_struct *fmt;  /* Current format */
struct clk *clk;
+   struct gpio_desc *resetb_gpio;
+   struct gpio_desc *pwdn_gpio;
int min_width;  /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -591,8 +595,6 @@ static int ov7670_init(struct v4l2_subdev *sd, u32 val)
return ov7670_write_array(sd, ov7670_default_regs);
 }
 
-
-
 static int ov7670_detect(struct v4l2_subdev *sd)
 {
unsigned char v;
@@ -1549,6 +1551,29 @@ static const struct ov7670_devtype ov7670_devdata[] = {
},
 };
 
+static int ov7670_init_gpio(struct i2c_client *client, struct ov7670_info 
*info)
+{
+   /* Request the power down GPIO asserted */
+   info->pwdn_gpio = devm_gpiod_get_optional(>dev, "pwdn",
+   GPIOD_OUT_LOW);
+   if (IS_ERR(info->pwdn_gpio)) {
+   dev_info(>dev, "can't get %s GPIO\n", "pwdn");
+   return PTR_ERR(info->pwdn_gpio);
+   }
+
+   /* Request the reset GPIO deasserted */
+   info->resetb_gpio = devm_gpiod_get_optional(>dev, "resetb",
+   GPIOD_OUT_LOW);
+   if (IS_ERR(info->resetb_gpio)) {
+   dev_info(>dev, "can't get %s GPIO\n", "resetb");
+   return PTR_ERR(info->resetb_gpio);
+   }
+
+   usleep_range(3000, 5000);
+
+   return 0;
+}
+
 static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
@@ -1594,6 +1619,10 @@ static int ov7670_probe(struct i2c_client *client,
return -EPROBE_DEFER;
clk_prepare_enable(info->clk);
 
+   ret = ov7670_init_gpio(client, info);
+   if (ret)
+   return ret;
+
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48)
return -EINVAL;
@@ -1689,9 +1718,18 @@ static const struct i2c_device_id ov7670_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ov7670_id);
 
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id ov7670_of_match[] = {
+   { .compatible = "ovti,ov7670", },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ov7670_of_match);
+#endif
+
 static struct i2c_driver ov7670_driver = {
.driver = {
.name   = "ov7670",
+   .of_match_table = of_match_ptr(ov7670_of_match),
},
.probe  = ov7670_probe,
.remove = ov7670_remove,
-- 
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

[PATCHv2 00/16] atmel-isi/ov7670/ov2640: convert to standalone drivers

[Hans Verkuil]

From: Hans Verkuil 

This patch series converts the soc-camera atmel-isi to a standalone V4L2
driver.

The same is done for the ov7670 and ov2640 sensor drivers: the ov7670 was
used to test the atmel-isi driver. The ov2640 is needed because the em28xx
driver has a soc_camera include dependency. Both ov7670 and ov2640 sensors
have been tested with the atmel-isi driver.

The first 5 patches improve the ov7670 sensor driver, mostly adding modern
features such as DT support.

The next three convert the atmel-isi and move it out of soc_camera.

The following 6 patches convert ov2640 and drop the soc_camera dependency
in em28xx. I have tested that this works with my 'SpeedLink Vicious And
Divine Laplace webcam', but the picture is all wrong, but it was like that
without my patches as well so I am bug-compatible.

I've asked Frank Schaefer who authored this if he can test this em28xx code
and see if something regressed.

The last two patches add isi support to the DT: the first for the ov7670
sensor, the second modifies it for the ov2640 sensor.

These two final patches are for demonstration purposes only, I do not plan
on merging them.

Tested with my sama5d3-Xplained board, the ov2640 sensor and two ov7670
sensors: one with and one without reset/pwdn pins. Also tested with my
em28xx-based webcam.

I believe I have addressed all comments made by Sakari regarding the v1
patch series.

Regards,

Hans

Changes since v1:

- Dropped MC support from atmel-isi and ov7670: not needed to make this
  work. Only for the ov2640 was it kept since the em28xx driver requires it.
- Use devm_clk_get instead of clk_get.
- The ov7670 lower limit of the clock speed is 10 MHz instead of 12. Adjust
  accordingly.


Hans Verkuil (16):
  ov7670: call v4l2_async_register_subdev
  ov7670: fix g/s_parm
  ov7670: get xclk
  ov7670: add devicetree support
  ov7670: document device tree bindings
  atmel-isi: remove dependency of the soc-camera framework
  atmel-isi: move out of soc_camera to atmel
  atmel-isi: document device tree bindings
  ov2640: convert from soc-camera to a standard subdev sensor driver.
  ov2640: enable clock and fix power/reset
  ov2640: allow use inside em28xx
  ov2640: add MC support
  ov2640: update bindings
  em28xx: drop last soc_camera link
  sama5d3 dts: enable atmel-isi
  at91-sama5d3_xplained.dts: select ov2640

 .../devicetree/bindings/media/atmel-isi.txt|   91 +-
 .../devicetree/bindings/media/i2c/ov2640.txt   |   22 +-
 .../devicetree/bindings/media/i2c/ov7670.txt   |   44 +
 MAINTAINERS|1 +
 arch/arm/boot/dts/at91-sama5d3_xplained.dts|   61 +-
 arch/arm/boot/dts/sama5d3.dtsi |4 +-
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/{soc_camera => }/ov2640.c|  189 +--
 drivers/media/i2c/ov7670.c |   71 +-
 drivers/media/i2c/soc_camera/Kconfig   |6 -
 drivers/media/i2c/soc_camera/Makefile  |1 -
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/atmel/Kconfig   |   11 +-
 drivers/media/platform/atmel/Makefile  |1 +
 drivers/media/platform/atmel/atmel-isi.c   | 1398 
 .../platform/{soc_camera => atmel}/atmel-isi.h |0
 drivers/media/platform/soc_camera/Kconfig  |   11 -
 drivers/media/platform/soc_camera/Makefile |1 -
 drivers/media/platform/soc_camera/atmel-isi.c  | 1167 
 drivers/media/usb/em28xx/em28xx-camera.c   |9 -
 21 files changed, 1710 insertions(+), 1391 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt
 rename drivers/media/i2c/{soc_camera => }/ov2640.c (90%)
 create mode 100644 drivers/media/platform/atmel/atmel-isi.c
 rename drivers/media/platform/{soc_camera => atmel}/atmel-isi.h (100%)
 delete mode 100644 drivers/media/platform/soc_camera/atmel-isi.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

Re: DRM Atomic property for color-space conversion

[Ville Syrjälä]

On Fri, Jan 27, 2017 at 05:23:24PM +, Brian Starkey wrote:
> Hi,
> 
> We're looking to enable the per-plane color management hardware in
> Mali-DP with atomic properties, which has sparked some conversation
> around how to handle YCbCr formats.
> 
> As it stands today, it's assumed that a driver will implicitly "do the
> right thing" to display a YCbCr buffer.
> 
> YCbCr data often uses different gamma curves and signal ranges (e.g.
> BT.609, BT.701, BT.2020, studio range, full-range), so its desirable
> to be able to explicitly control the YCbCr to RGB conversion process
> from userspace.
> 
> We're proposing adding a "CSC" (color-space conversion) property to
> control this - primarily per-plane for framebuffer->pipeline CSC, but
> perhaps one per CRTC too for devices which have an RGB pipeline and
> want to output in YUV to the display:
> 
> Name: "CSC"
> Type: ENUM | ATOMIC;
> Enum values (representative):
> "default":
>   Same behaviour as now. "Some kind" of YCbCr->RGB conversion
>   for YCbCr buffers, bypass for RGB buffers
> "disable":
>   Explicitly disable all colorspace conversion (i.e. use an
>   identity matrix).
> "YCbCr to RGB: BT.709":
>   Only valid for YCbCr formats. CSC in accordance with BT.709
>   using [16..235] for (8-bit) luma values, and [16..240] for
>   8-bit chroma values. For 10-bit formats, the range limits are
>   multiplied by 4.
> "YCbCr to RGB: BT.709 full-swing":
>   Only valid for YCbCr formats. CSC in accordance with BT.709,
>   but using the full range of each channel.
> "YCbCr to RGB: Use CTM":*
>   Only valid for YCbCr formats. Use the matrix applied via the
>   plane's CTM property
> "RGB to RGB: Use CTM":*
>   Only valid for RGB formats. Use the matrix applied via the
>   plane's CTM property
> "Use CTM":*
>   Valid for any format. Use the matrix applied via the plane's
>   CTM property
> ... any other values for BT.601, BT.2020, RGB to YCbCr etc. etc. as
> they are required.

Having some RGB2RGB and YCBCR2RGB things in the same property seems
weird. I would just go with something very simple like:

YCBCR_TO_RGB_CSC:
* BT.601
* BT.709
* custom matrix

And trying to use the same thing for the crtc stuff is probably not
going to end well. Like Daniel said we already have the
'Broadcast RGB' property muddying the waters there, and that stuff
also ties in with what colorspace we signal to the sink via
infoframes/whatever the DP thing was called. So my gut feeling is
that trying to use the same property everywhere will just end up
messy.

-- 
Ville Syrjälä
Intel OTC
--
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 00/24] i.MX Media Driver

[Russell King - ARM Linux]

> The central issue seems to be that I think media pad links / media bus
> formats should describe physical links, such as parallel or serial
> buses, and the formats of pixels flowing through them, whereas Steve
> would like to extend them to describe software transports and in-memory
> formats.

This probably isn't the right place to attach this comment in this
thread, but... the issue of media bus formats matching physical buses
is an argument that I think is already lost.

For example, take the 10-bit bayer formats:

#define MEDIA_BUS_FMT_SBGGR10_1X10  0x3007
#define MEDIA_BUS_FMT_SGBRG10_1X10  0x300e
#define MEDIA_BUS_FMT_SGRBG10_1X10  0x300a
#define MEDIA_BUS_FMT_SRGGB10_1X10  0x300f

These are commonly used on CSI serial buses (see the smiapp driver for
example).  From the description at the top of the file, it says the
1X10 means that one pixel is transferred as one 10-bit sample.

However, the format on wire is somewhat different - four pixels are
transmitted over five bytes:

P0  P1  P2  P3  P0  P1  P2  P3
8-bit   8-bit   8-bit   8-bit   2-bit   2-bit   2-bit   2-bit

This gives two problems:
1) it doesn't fit in any sensible kind of "one pixel transferred as
   N M-bit samples" description because the pixel/sample values
   (depending how you look at them) are broken up.

2) changing this will probably be a user visible change, as things
   like smiapp are already in use.

So, I think what we actually have is the media bus formats describing
the _logical_ bus format.  Yes, one pixel is transferred as one 10-bit
sample in this case.

To help illustrate my point, consider the difference between
MEDIA_BUS_FMT_RGB565_1X16 and MEDIA_BUS_FMT_RGB565_2X8_BE or
MEDIA_BUS_FMT_RGB565_2X8_LE.  RGB565_1X16 means 1 pixel over an effective
16-bit wide bus (if it's not 16-bit, then it has to be broken up into
separate "samples".)  RGB565_2X8 means 1 pixel as two 8-bit samples.

So, the 10-bit bayer is 1 pixel as 1.25 bytes.  Or is it, over a serial
bus.  Using the RGB565 case, 10-bit bayer over a 4 lane CSI bus becomes
interesting:

first byte  2nd 3rd
lane 1  P0 9:2  S0  P7 9:2
lane 2  P1 9:2  P4 9:2  S1
lane 3  P2 9:2  P5 9:2  P8 9:2
lane 4  P3 9:2  P6 9:2  P9 9:2

S0 = P0/P1/P2/P3 least significant two bits
S1 = P4/P5/P6/P7 least significant two bits

or 2 lane CSI:
first byte  2nd 3rd 4th 5th
lane 1  P0 9:2  P2  S0  P5  P7
lane 2  P1 9:2  P3  P4  P6  S1

or 1 lane CSI:
lane 1  P0 P1 P2 P3 S0 P4 P5 P6 P7 S1 P8 P9 ...

etc.

-- 
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: [ANN] Media object lifetime management meeting report from Oslo

[Mauro Carvalho Chehab]

Em Mon, 30 Jan 2017 09:39:21 +0100
Hans Verkuil  escreveu:

> On 28/01/17 16:35, Laurent Pinchart wrote:
> > Hi Sakari,
> >
> > On Saturday 28 Jan 2017 00:02:53 Sakari Ailus wrote:  
> >> On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:  
> >>> Hi Sakari/Hans/Laurent,
> >>>
> >>> First of all, thanks for looking into those issues. Unfortunately, I was
> >>> in vacations, and were not able to be with you there for such discussions.
> >>>
> >>> While I have a somewhat different view on some of the introductory points
> >>> of this RFC, what really matters is the "proposal" part of it. So, based
> >>> on the experiments I did when I addressed the hotplug issues with the
> >>> media controller on USB drivers, I'm adding a few comments below.
> >>>
> >>> Em Fri, 27 Jan 2017 12:08:22 +0200 Sakari Ailus escreveu:  
>  Allocating struct media_devnode separately from struct media_device
>  ---
> 
>  The current codebase allocates struct media_devnode dynamically. This
>  was done in order to reduce the time window during which unallocated
>  kernel memory could be accessed. However, there is no specific need for
>  such a separation as the entire data structure, including the media
>  device which used to contain struct media_devnode, will have the same
>  lifetime. Thus the struct media_devnode should be allocated as part of
>  struct media_device. Later on, struct media_devnode may be merged with
>  struct media_device if so decided.  
> >>>
> >>> There is one issue merging struct media_devnode at struct media_device.
> >>> The problem is that, if the same struct device is used for two different
> >>> APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
> >>> to the same struct device, you may end by having a double free when the
> >>> device is unregistered on the second core. That's basically why
> >>> currently struct cdev is at struct media_devnode: this way, it has its own
> >>> struct device.  
> >>
> >> One of the conclusions of the memorandum I wrote is that the data 
> >> structures
> >> that are involved in executing a system call (including IOCTLs) must stay
> >> intact during that system call. (Well, the alternative I can think of is
> >> using an rw_semaphore but I certainly do not advocate that solution.)
> >>
> >> Otherwise, we will continue to have serialisation issues: kernel memory 
> >> that
> >> may be released at any point of time independently of a system call in
> >> progress:
> >>
> >>  >>   
> >>>  
> >>
> >> That one is a NULL pointer dereference but released kernel memory can be
> >> accessed as well.
> >>  

There's an alternative approach: to have a flag to indicate that the
device got disconnected and denying access to the device-specific data
if the device was already hot-unplugged. The V4L USB drivers do that
already. See, for example, the em28xx driver:

int em28xx_read_reg_req_len(struct em28xx *dev, u8 req, u16 reg,
char *buf, int len)
{
...
if (dev->disconnected)
return -ENODEV;
...
}

/* Processes and copies the URB data content (video and VBI data) */
static inline int em28xx_urb_data_copy(struct em28xx *dev, struct urb *urb)
{
...
if (dev->disconnected)
return 0;

The same logic exists on multiple places along the driver. Some of
such checks could be moved to the core, but, if I remember well when
such code was written, several such checks should be inside the driver,
as the USB core doesn't allow any calls to their functions after the
disconnect callback is called. That's why it was opted to not move
it to the core.

In the case of DVB, the core has a similar logic to handle disconnected
devices, with prevents it to call driver-specific code when a device is
removed. That's why there are just 2 checks if dev->disconnected at
drivers/media/usb/em28xx/em28xx-dvb.c: one at the IRQ logic, and the
second one to avoid a race issue with the suspend code.

Due to that, on real hot-plug devices (USB drivers) that don't have
hot-unplug issues with the V4L2 API, it should be safe to free some of
their data structs at the .disconnect callback. Of course, the struct
that embeds the struct device used as the cdev's parent can't be freed
there.

> >>> IMHO, it also makes sense to embeed struct cdev at the V4L2 side, as I
> >>> detected some race issues at the V4L2 side when I ran the bind/unbind
> >>> race tests, when we tried to merge the snd-usb-audio MC support patch.
> >>> I remember Shuah reported something similar on that time.
> >>>  
>  Allocating struct media_device dynamically
>  --
> 
>  Traditionally the media device has been allocated as part of drivers'
>  own structures. This is certainly fine as 

[PATCH v1 2/3] [media] st-delta: add parsing metadata controls support

[Hugues Fruchet]

Install all metadata controls required by registered decoders.
Update the decoding context with the set of metadata received
from user through extended control.
Set the received metadata in access unit prior to call the
decoder decoding ops.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/delta-v4l2.c | 125 +-
 drivers/media/platform/sti/delta/delta.h  |  34 +++
 2 files changed, 158 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c 
b/drivers/media/platform/sti/delta/delta-v4l2.c
index 8ad6a45..f61ff1e 100644
--- a/drivers/media/platform/sti/delta/delta-v4l2.c
+++ b/drivers/media/platform/sti/delta/delta-v4l2.c
@@ -335,6 +335,30 @@ static void register_decoders(struct delta_dev *delta)
}
 }
 
+static void register_ctrls(struct delta_dev *delta)
+{
+   const struct delta_dec *dec;
+   unsigned int i, j;
+   u32 meta_cid;
+
+   /* decoders optional meta controls */
+   for (i = 0; i < delta->nb_of_decoders; i++) {
+   dec = delta->decoders[i];
+   if (!dec->meta_cids)
+   continue;
+
+   for (j = 0; j < dec->nb_of_metas; j++) {
+   meta_cid = dec->meta_cids[j];
+   if (!meta_cid)
+   continue;
+
+   delta->cids[delta->nb_of_ctrls++] = meta_cid;
+   }
+   }
+
+   /* add here additional controls if needed */
+}
+
 static void delta_lock(void *priv)
 {
struct delta_ctx *ctx = priv;
@@ -351,6 +375,79 @@ static void delta_unlock(void *priv)
mutex_unlock(>lock);
 }
 
+static int delta_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct delta_ctx *ctx =
+   container_of(ctrl->handler, struct delta_ctx, ctrl_handler);
+   struct delta_dev *delta = ctx->dev;
+
+   if (ctx->nb_of_metas >= DELTA_MAX_METAS) {
+   dev_err(delta->dev, "%s not enough room to set meta control\n",
+   ctx->name);
+   return -EINVAL;
+   }
+
+   dev_dbg(delta->dev, "%s set metas[%d] from control id=%d (%s)\n",
+   ctx->name, ctx->nb_of_metas, ctrl->id, ctrl->name);
+
+   ctx->metas[ctx->nb_of_metas].cid = ctrl->id;
+   ctx->metas[ctx->nb_of_metas].p = ctrl->p_new.p;
+   ctx->nb_of_metas++;
+
+   return 0;
+}
+
+static const struct v4l2_ctrl_ops delta_ctrl_ops = {
+   .s_ctrl = delta_s_ctrl,
+};
+
+static int delta_ctrls_setup(struct delta_ctx *ctx)
+{
+   struct delta_dev *delta = ctx->dev;
+   struct v4l2_ctrl_handler *hdl = >ctrl_handler;
+   unsigned int i;
+
+   v4l2_ctrl_handler_init(hdl, delta->nb_of_ctrls);
+
+   for (i = 0; i < delta->nb_of_ctrls; i++) {
+   struct v4l2_ctrl *ctrl;
+   u32 cid = delta->cids[i];
+   struct v4l2_ctrl_config cfg;
+
+   /* override static config to set delta_ctrl_ops */
+   memset(, 0, sizeof(cfg));
+   cfg.id = cid;
+   cfg.ops = _ctrl_ops;
+
+   ctrl = v4l2_ctrl_new_custom(hdl, , NULL);
+   if (hdl->error) {
+   int err = hdl->error;
+
+   dev_err(delta->dev, "%s failed to setup control '%s' 
(id=%d, size=%d, err=%d)\n",
+   ctx->name, cfg.name, cfg.id,
+   cfg.elem_size, err);
+   v4l2_ctrl_handler_free(hdl);
+   return err;
+   }
+
+   /* force unconditional execution of s_ctrl() by
+* disabling control value evaluation in case of
+* meta control (passed by pointer)
+*/
+   if (ctrl->is_ptr)
+   ctrl->flags |= V4L2_CTRL_FLAG_EXECUTE_ON_WRITE;
+   }
+
+   v4l2_ctrl_handler_setup(hdl);
+   ctx->fh.ctrl_handler = hdl;
+
+   ctx->nb_of_metas = 0;
+   memset(ctx->metas, 0, sizeof(ctx->metas));
+
+   dev_dbg(delta->dev, "%s controls setup done\n", ctx->name);
+   return 0;
+}
+
 static int delta_open_decoder(struct delta_ctx *ctx, u32 streamformat,
  u32 pixelformat, const struct delta_dec **pdec)
 {
@@ -957,6 +1054,12 @@ static void delta_run_work(struct work_struct *work)
au->size = vb2_get_plane_payload(>vb2_buf, 0);
au->dts = vbuf->vb2_buf.timestamp;
 
+   /* set access unit meta data in case of decoder requires it */
+   memcpy(au->metas, ctx->metas, ctx->nb_of_metas * sizeof(au->metas[0]));
+   au->nb_of_metas = ctx->nb_of_metas;
+   /* reset context metas for next decoding */
+   ctx->nb_of_metas = 0;
+
/* dump access unit */
dump_au(ctx, au);
 
@@ -1353,6 +1456,12 @@ static int delta_vb2_au_start_streaming(struct vb2_queue 
*q,
au->size = vb2_get_plane_payload(>vb2_buf, 0);
au->dts = 

[PATCH v1 1/3] [media] v4l: add parsed MPEG-2 support

[Hugues Fruchet]

Add "parsed MPEG-2" pixel format & related controls
needed by stateless video decoders.
In order to decode the video bitstream chunk provided
by user on output queue, stateless decoders require
also some extra data resulting from this video bitstream
chunk parsing.
Those parsed extra data have to be set by user through
control framework using the dedicated mpeg video extended
controls introduced in this patchset.

Signed-off-by: Hugues Fruchet 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 363 +
 Documentation/media/uapi/v4l/pixfmt-013.rst|  10 +
 drivers/media/v4l2-core/v4l2-ctrls.c   |  53 +++
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/uapi/linux/v4l2-controls.h |  86 +
 include/uapi/linux/videodev2.h |   8 +
 6 files changed, 522 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index abb1057..cd1a8d6 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1827,6 +1827,369 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type -
 not insert, 1 = insert packets.
 
 
+MPEG-2 Parsed Control Reference
+-
+
+The MPEG-2 parsed decoding controls are needed by stateless video decoders.
+Those decoders expose :ref:`Compressed formats ` 
:ref:`V4L2_PIX_FMT_MPEG1_PARSED` or 
:ref:`V4L2_PIX_FMT_MPEG2_PARSED`.
+In order to decode the video bitstream chunk provided by user on output queue,
+stateless decoders require also some extra data resulting from this video
+bitstream chunk parsing. Those parsed extra data have to be set by user
+through control framework using the mpeg video extended controls defined
+in this section. Those controls have been defined based on MPEG-2 standard
+ISO/IEC 13818-2, and so derive directly from the MPEG-2 video bitstream syntax
+including how it is coded inside bitstream (enumeration values for ex.).
+
+MPEG-2 Parsed Control IDs
+^^^
+
+.. _mpeg2-parsed-control-id:
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR``
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_hdr
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_hdr
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u16
+  - ``width``
+  - Video width in pixels.
+* - __u16
+  - ``height``
+  - Video height in pixels.
+* - __u8
+  - ``aspect_ratio_info``
+  - Aspect ratio code as in the bitstream (1: 1:1 square pixels,
+2: 4:3 display, 3: 16:9 display, 4: 2.21:1 display)
+* - __u8
+  - ``framerate code``
+  - Framerate code as in the bitstream
+(1: 24000/1001.0 '23.976 fps, 2: 24.0, 3: 25.0,
+4: 3/1001.0 '29.97, 5: 30.0, 6: 50.0, 7: 6/1001.0,
+8: 60.0)
+* - __u32
+  - ``bitrate_value``
+  - Bitrate value as in the bitstream, expressed in 400bps unit
+* - __u16
+  - ``vbv_buffer_size``
+  -  Video Buffering Verifier size, expressed in 16KBytes unit.
+* - __u8
+  - ``constrained_parameters_flag``
+  - Set to 1 if this bitstream uses constrained parameters.
+* - __u8
+  - ``load_intra_quantiser_matrix``
+  - If set to 1, ``intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``load_non_intra_quantiser_matrix``
+  - If set to 1, ``non_intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``intra_quantiser_matrix[64]``
+  - Intra quantization table, in zig-zag scan order.
+* - __u8
+  - ``non_intra_quantiser_matrix[64]``
+  - Non-intra quantization table, in zig-zag scan order.
+* - __u32
+  - ``par_w``
+  - Pixel aspect ratio width in pixels.
+* - __u32
+  - ``par_h``
+  - Pixel aspect ratio height in pixels.
+* - __u32
+  - ``fps_n``
+  - Framerate nominator.
+* - __u32
+  - ``fps_d``
+  - Framerate denominator.
+* - __u32
+  - ``bitrate``
+  - Bitrate in bps if constant bitrate, 0 otherwise.
+* - :cspan:`2`
+
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_EXT``
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_ext
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_ext
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``profile``
+  - Encoding profile used to encode this bitstream.
+(1: High Profile, 2: Spatially Scalable Profile,
+3: SNR Scalable Profile, 4: Main Profile, 5: Simple Profile).
+* - __u8
+  - ``level``
+  - Encoding level used to encode this bitstream
+(4: High Level, 6: High 1440 Level, 8: Main Level, 10: Low Level).
+* - __u8

[PATCH v1 0/3] Add support for MPEG-2 in DELTA video decoder

[Hugues Fruchet]

The patchset implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0] needed by stateless video decoders, ie decoders which requires
specific parsing metadata in addition to video bitstream chunk in order
to complete decoding.
A reference implementation using STMicroelectronics DELTA video decoder
is provided as initial support in this patchset.
In addition to this patchset, a libv4l plugin is also provided which convert
MPEG-2 video bitstream to "parsed MPEG-2" by parsing the user video bitstream
and filling accordingly the dedicated controls, doing so user code remains
unchanged whatever decoder is: stateless or not.

The first patch implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0]. A dedicated "parsed MPEG-2" pixel format has been introduced with
its related extended controls in order that user provides both video bitstream
chunk and the associated extra data resulting from this video bitstream chunk
parsing.

The second patch adds the support of "parsed" pixel format inside DELTA video
decoder including handling of the dedicated controls and setting of parsing
metadata required by decoder layer.
Please note that the current implementation has a restriction regarding
the atomicity of S_EXT_CTRL/QBUF that must be guaranteed by user.
This restriction will be removed when V4L2 request API will be implemented [1].
Please also note the failure in v4l2-compliance in controls section, related
to complex compound controls handling, to be discussed to find the right way
to fix it in v4l2-compliance.

The third patch adds the support of DELTA MPEG-2 stateless video decoder 
back-end.


This driver depends on:
  [PATCH v4 00/10] Add support for DELTA video decoder of STMicroelectronics 
STiH4xx SoC series https://patchwork.linuxtv.org/patch/38967/

References:
  [0] [RFC] V4L2 unified low-level decoder API 
https://www.spinics.net/lists/linux-media/msg107150.html
  [1] [ANN] Report of the V4L2 Request API brainstorm meeting 
https://www.spinics.net/lists/linux-media/msg106699.html

===
= history =
===
version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report, v4l2-compliance has been build from SHA1:
003f31e59f353b4aecc82e8fb1c7555964da7efa (v4l2-compliance: allow S_SELECTION to 
return ENOTTY)

root@sti-4:~# v4l2-compliance -d /dev/video3
v4l2-compliance SHA   : 003f31e59f353b4aecc82e8fb1c7555964da7efa


root@sti-lts:~# v4l2-compliance -d /dev/video3 
v4l2-compliance SHA   : not available

Driver Info:
Driver name   : st-delta
Card type : st-delta-21.1-3
Bus info  : platform:soc:delta0
Driver version: 4.9.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
fail: 
../../../../../../../../../sources/v4l-utils/utils/v4l2-compliance/v4l2-test-controls.cpp(585):
 g_ext_ctrls worked even when no controls are present
test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

   

[GIT PULL FOR v4.11] Sensors changes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git sensors/next

for you to fetch changes up to ab21fe9d7e3748e42445a43d24c67e8b42abff01:

  ov9650: use msleep() for uncritical long delay (2017-01-30 12:57:14 +0200)


Laurent Pinchart (1):
  v4l: mt9v032: Remove unneeded gpiod NULL check

Nicholas Mc Guire (1):
  ov9650: use msleep() for uncritical long delay

 drivers/media/i2c/mt9v032.c | 3 +--
 drivers/media/i2c/ov9650.c  | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

-- 
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 v1 3/3] [media] st-delta: add mpeg2 support

[Hugues Fruchet]

Adds support of DELTA MPEG-2 video decoder back-end,
implemented by calling MPEG2_TRANSFORMER0 firmware
using RPMSG IPC communication layer.
MPEG-2 decoder back-end is a stateless decoder which
require specific parsing metadata in access unit
in order to complete decoding.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig |6 +
 drivers/media/platform/sti/delta/Makefile  |3 +
 drivers/media/platform/sti/delta/delta-cfg.h   |5 +
 drivers/media/platform/sti/delta/delta-mpeg2-dec.c | 1392 
 drivers/media/platform/sti/delta/delta-mpeg2-fw.h  |  415 ++
 drivers/media/platform/sti/delta/delta-v4l2.c  |4 +
 6 files changed, 1825 insertions(+)
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-dec.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-fw.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 9e71a7b..0472939 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -323,6 +323,12 @@ config VIDEO_STI_DELTA_MJPEG
help
Enables DELTA MJPEG hardware support.
 
+config VIDEO_STI_DELTA_MPEG2
+   bool "STMicroelectronics DELTA MPEG2/MPEG1 support"
+   default y
+   help
+   Enables DELTA MPEG2 hardware support.
+
 endif # VIDEO_STI_DELTA
 
 config VIDEO_SH_VEU
diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index f95580e..e509bcb 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -4,3 +4,6 @@ st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o delta-debug.o
 # MJPEG support
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-dec.o
+
+# MPEG2 support
+st-delta-$(CONFIG_VIDEO_STI_DELTA_MPEG2) += delta-mpeg2-dec.o
diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
b/drivers/media/platform/sti/delta/delta-cfg.h
index fa89064..a7d718c 100644
--- a/drivers/media/platform/sti/delta/delta-cfg.h
+++ b/drivers/media/platform/sti/delta/delta-cfg.h
@@ -60,4 +60,9 @@
 extern const struct delta_dec mjpegdec;
 #endif
 
+#ifdef CONFIG_VIDEO_STI_DELTA_MPEG2
+extern const struct delta_dec mpeg2dec;
+extern const struct delta_dec mpeg1dec;
+#endif
+
 #endif /* DELTA_CFG_H */
diff --git a/drivers/media/platform/sti/delta/delta-mpeg2-dec.c 
b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
new file mode 100644
index 000..6ccfdc9
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
@@ -0,0 +1,1392 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Hugues Fruchet 
+ *  Chetan Nanda 
+ *  Jean-Christophe Trotin 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "delta.h"
+#include "delta-ipc.h"
+#include "delta-mem.h"
+#include "delta-mpeg2-fw.h"
+
+#define DELTA_MPEG2_MAX_RESO DELTA_MAX_RESO
+
+/* minimal number of frames for decoding = 1 dec + 2 refs frames */
+#define DELTA_MPEG2_DPB_FRAMES_NEEDED 3
+
+struct delta_mpeg2_ctx {
+   /* ipc */
+   void *ipc_hdl;
+   struct delta_buf *ipc_buf;
+
+   /* stream information */
+   struct delta_streaminfo streaminfo;
+
+   bool header_parsed;
+
+   /* reference frames mgt */
+   struct delta_mpeg2_frame *prev_ref;
+   struct delta_mpeg2_frame *next_ref;
+
+   /* output frames reordering management */
+   struct delta_frame *out_frame;
+   struct delta_frame *delayed_frame;
+
+   /* interlaced frame management */
+   struct delta_frame *last_frame;
+   enum mpeg2_picture_structure_t accumulated_picture_structure;
+
+   unsigned char str[3000];
+};
+
+/* codec specific frame struct */
+struct delta_mpeg2_frame {
+   struct delta_frame frame;
+   struct timeval dts;
+   struct delta_buf omega_buf; /* 420mb buffer for decoding */
+};
+
+#define to_ctx(ctx) ((struct delta_mpeg2_ctx *)ctx->priv)
+#define to_mpeg2_frame(frame) ((struct delta_mpeg2_frame *)frame)
+#define to_frame(mpeg2_frame) ((struct delta_frame *)mpeg2_frame)
+
+/* default intra, zig-zag order */
+static u8 default_intra_matrix[] = {
+   8,
+   16, 16,
+   19, 16, 19,
+   22, 22, 22, 22,
+   22, 22, 26, 24, 26,
+   27, 27, 27, 26, 26, 26,
+   26, 27, 27, 27, 29, 29, 29,
+   34, 34, 34, 29, 29, 29, 27, 27,
+   29, 29, 32, 32, 34, 34, 37,
+   38, 37, 35, 35, 34, 35,
+   38, 38, 40, 40, 40,
+   48, 48, 46, 46,
+   56, 56, 58,
+   69, 69,
+   83
+};
+
+static u8 default_non_intra_matrix[] = {
+   16, 16, 16, 16, 16, 16, 16, 16,
+   16, 16, 16, 16, 16, 16, 16, 16,
+   16, 16, 16, 16, 16, 16, 16, 16,
+   16, 16, 16, 16, 16, 16, 16, 16,
+  

Re: [PATCH] v4l: mt9v032: Remove unneeded gpiod NULL check

[Sakari Ailus]

On Thu, Jan 19, 2017 at 01:32:20AM +0200, Laurent Pinchart wrote:
> The gpiod API checks for NULL descriptors, there's no need to duplicate
> the check in the driver.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Sakari Ailus 

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

[GIT PULL FOR v4.11] OMAP3 ISP and OMAP4 ISS changes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git omap3isp/next

for you to fetch changes up to 2ea65cbd5684934bcda4fc140a34cb2746c2c80b:

  v4l: omap4iss: Clean up file handle in open() and release() (2017-01-30 
12:45:46 +0200)


Shailendra Verma (2):
  v4l: omap3isp: Clean up file handle in open() and release()
  v4l: omap4iss: Clean up file handle in open() and release()

 drivers/media/platform/omap3isp/ispvideo.c | 2 ++
 drivers/staging/media/omap4iss/iss_video.c | 2 ++
 2 files changed, 4 insertions(+)

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

[GIT PULL FOR v4.11] uvcvideo changes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git uvc/next

for you to fetch changes up to eeb7ba86db3cf031b659bae245ca56d38dc44741:

  uvcvideo: Change result code of debugfs_init to void (2017-01-19 02:07:10 
+0200)


Guennadi Liakhovetski (3):
  uvcvideo: (cosmetic) Add and use an inline function
  uvcvideo: (cosmetic) Remove a superfluous assignment
  uvcvideo: Fix a wrong macro

Jaejoong Kim (1):
  uvcvideo: Change result code of debugfs_init to void

 drivers/media/usb/uvc/uvc_debugfs.c | 15 ++-
 drivers/media/usb/uvc/uvc_queue.c   | 13 +
 drivers/media/usb/uvc/uvc_video.c   |  3 +--
 drivers/media/usb/uvc/uvcvideo.h|  4 ++--
 4 files changed, 18 insertions(+), 17 deletions(-)

-- 
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: [Intel-gfx] [PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

[Daniel Vetter]

Hi all,

Ok if we merge the entire series through drm-intel (likely for 4.12, 4.11
is getting a bit late)? We'd like to use this there, and Mauro already
reviewed the v4l side ...

Thanks, Daniel

On Mon, Jan 16, 2017 at 02:12:07PM +, 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)
> Reviewed-by: Chris Wilson 
> Reviewed-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
>  drivers/rapidio/devices/rio_mport_cdev.c   | 4 ++--
>  include/linux/scatterlist.h| 2 +-
>  lib/scatterlist.c  | 2 +-
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index fb6a177be461..51e8765bc3c6 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -478,7 +478,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
> unsigned long vaddr,
>  {
>   struct vb2_dc_buf *buf;
>   struct frame_vector *vec;
> - unsigned long offset;
> + unsigned int offset;
>   int n_pages, i;
>   int ret = 0;
>   struct sg_table *sgt;
> @@ -506,7 +506,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
> unsigned long vaddr,
>   buf->dev = dev;
>   buf->dma_dir = dma_dir;
>  
> - offset = vaddr & ~PAGE_MASK;
> + offset = lower_32_bits(offset_in_page(vaddr));
>   vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
>   if (IS_ERR(vec)) {
>   ret = PTR_ERR(vec);
> diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
> b/drivers/rapidio/devices/rio_mport_cdev.c
> index 9013a585507e..0fae29ff47ba 100644
> --- a/drivers/rapidio/devices/rio_mport_cdev.c
> +++ b/drivers/rapidio/devices/rio_mport_cdev.c
> @@ -876,10 +876,10 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
>* offset within the internal buffer specified by handle parameter.
>*/
>   if (xfer->loc_addr) {
> - unsigned long offset;
> + unsigned int offset;
>   long pinned;
>  
> - offset = (unsigned long)(uintptr_t)xfer->loc_addr & ~PAGE_MASK;
> + offset = lower_32_bits(offset_in_page(xfer->loc_addr));
>   nr_pages = PAGE_ALIGN(xfer->length + offset) >> PAGE_SHIFT;
>  
>   page_list = kmalloc_array(nr_pages,
> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> index cb3c8fe6acd7..c981bee1a3ae 100644
> --- a/include/linux/scatterlist.h
> +++ b/include/linux/scatterlist.h
> @@ -263,7 +263,7 @@ int __sg_alloc_table(struct sg_table *, unsigned int, 
> unsigned int,
>  int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
>  int sg_alloc_table_from_pages(struct sg_table *sgt,
>   struct page **pages, unsigned int n_pages,
> - unsigned long offset, unsigned long size,
> + unsigned int offset, unsigned long size,
>   gfp_t gfp_mask);
>  
>  size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
> diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> index 004fc70fc56a..e05e7fc98892 100644
> --- a/lib/scatterlist.c
> +++ b/lib/scatterlist.c
> @@ -391,7 +391,7 @@ EXPORT_SYMBOL(sg_alloc_table);
>   */
>  int sg_alloc_table_from_pages(struct sg_table *sgt,
>   struct page **pages, unsigned int n_pages,
> - unsigned long offset, unsigned long size,
> + unsigned int offset, unsigned long size,
>   gfp_t gfp_mask)
>  {
>   unsigned int chunks;
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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  

Re: [PATCH v6 0/5] davinci: VPIF: add DT support

[Hans Verkuil]

On 27/01/17 18:22, Kevin Hilman wrote:

On Fri, Dec 16, 2016 at 4:49 PM, Kevin Hilman  wrote:

Hans Verkuil  writes:


On 07/12/16 19:30, Kevin Hilman wrote:

Prepare the groundwork for adding DT support for davinci VPIF drivers.
This series does some fixups/cleanups and then adds the DT binding and
DT compatible string matching for DT probing.

The controversial part from previous versions around async subdev
parsing, and specifically hard-coding the input/output routing of
subdevs, has been left out of this series.  That part can be done as a
follow-on step after agreement has been reached on the path forward.
With this version, platforms can still use the VPIF capture/display
drivers, but must provide platform_data for the subdevs and subdev
routing.

Tested video capture to memory on da850-lcdk board using composite
input.


Other than the comment for the first patch this series looks good.

So once that's addressed I'll queue it up for 4.11.


I've fixed that issue, and sent an update for just that patch in reply
to the original.

Thanks for the review,


Gentle ping on this series.

I'm still not seeing this series yet in linux-next, so am worried it
might not make it for v4.11.

Kevin



Mauro was on vacation, so pull requests were delayed. I understood from
him that he's going to process pending pull requests this week, which
should include your series.

Regards,

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

Re: [PATCH] [media] v4l2-async: failing functions shouldn't have side effects

[Sakari Ailus]

Heippa!

On Fri, Jan 27, 2017 at 12:32:56PM +0200, Tuukka Toivonen wrote:
> v4l2-async had several functions doing some operations and then
> not undoing the operations in a failure situation. For example,
> v4l2_async_test_notify() moved a subdev into notifier's done list
> even if registering the subdev (v4l2_device_register_subdev) failed.
> If the subdev was allocated and v4l2_async_register_subdev() called
> from the driver's probe() function, as usually, the probe()
> function freed the allocated subdev and returned a failure.
> Nevertheless, the subdev was still left into the notifier's done
> list, causing an access to already freed memory when the notifier
> was later unregistered.
> 
> A hand-edited call trace leaving freed subdevs into the notifier:
> 
> v4l2_async_register_notifier(notifier, asd)
> cameradrv_probe
>  sd = devm_kzalloc()
>  v4l2_async_register_subdev(sd)
>   v4l2_async_test_notify(notifier, sd, asd)
>list_move(sd, >done)
>v4l2_device_register_subdev(notifier->v4l2_dev, sd)
> cameradrv_registered(sd) -> fails
> ->v4l2_async_register_subdev returns failure
> ->cameradrv_probe returns failure
> ->devres frees the allocated sd
> ->sd was freed but it still remains in the notifier's list.
> 
> This patch fixes this and several other cases where a failing
> function could leave nodes into a linked list while the caller
> might free the node due to a failure.
> 
> Signed-off-by: Tuukka Toivonen 

Acked-by: Sakari Ailus 

-- 
Terveisin,

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: [ANN] Media object lifetime management meeting report from Oslo

[Hans Verkuil]

On 28/01/17 16:35, Laurent Pinchart wrote:

Hi Sakari,

On Saturday 28 Jan 2017 00:02:53 Sakari Ailus wrote:

On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:

Hi Sakari/Hans/Laurent,

First of all, thanks for looking into those issues. Unfortunately, I was
in vacations, and were not able to be with you there for such discussions.

While I have a somewhat different view on some of the introductory points
of this RFC, what really matters is the "proposal" part of it. So, based
on the experiments I did when I addressed the hotplug issues with the
media controller on USB drivers, I'm adding a few comments below.

Em Fri, 27 Jan 2017 12:08:22 +0200 Sakari Ailus escreveu:

Allocating struct media_devnode separately from struct media_device
---

The current codebase allocates struct media_devnode dynamically. This
was done in order to reduce the time window during which unallocated
kernel memory could be accessed. However, there is no specific need for
such a separation as the entire data structure, including the media
device which used to contain struct media_devnode, will have the same
lifetime. Thus the struct media_devnode should be allocated as part of
struct media_device. Later on, struct media_devnode may be merged with
struct media_device if so decided.


There is one issue merging struct media_devnode at struct media_device.
The problem is that, if the same struct device is used for two different
APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
to the same struct device, you may end by having a double free when the
device is unregistered on the second core. That's basically why
currently struct cdev is at struct media_devnode: this way, it has its own
struct device.


One of the conclusions of the memorandum I wrote is that the data structures
that are involved in executing a system call (including IOCTLs) must stay
intact during that system call. (Well, the alternative I can think of is
using an rw_semaphore but I certainly do not advocate that solution.)

Otherwise, we will continue to have serialisation issues: kernel memory that
may be released at any point of time independently of a system call in
progress:

Re: DRM Atomic property for color-space conversion

[Daniel Vetter]

On Fri, Jan 27, 2017 at 05:23:24PM +, Brian Starkey wrote:
> Hi,
> 
> We're looking to enable the per-plane color management hardware in
> Mali-DP with atomic properties, which has sparked some conversation
> around how to handle YCbCr formats.
> 
> As it stands today, it's assumed that a driver will implicitly "do the
> right thing" to display a YCbCr buffer.
> 
> YCbCr data often uses different gamma curves and signal ranges (e.g.
> BT.609, BT.701, BT.2020, studio range, full-range), so its desirable
> to be able to explicitly control the YCbCr to RGB conversion process
> from userspace.
> 
> We're proposing adding a "CSC" (color-space conversion) property to
> control this - primarily per-plane for framebuffer->pipeline CSC, but
> perhaps one per CRTC too for devices which have an RGB pipeline and
> want to output in YUV to the display:
> 
> Name: "CSC"
> Type: ENUM | ATOMIC;
> Enum values (representative):
> "default":
>   Same behaviour as now. "Some kind" of YCbCr->RGB conversion
>   for YCbCr buffers, bypass for RGB buffers
> "disable":
>   Explicitly disable all colorspace conversion (i.e. use an
>   identity matrix).
> "YCbCr to RGB: BT.709":
>   Only valid for YCbCr formats. CSC in accordance with BT.709
>   using [16..235] for (8-bit) luma values, and [16..240] for
>   8-bit chroma values. For 10-bit formats, the range limits are
>   multiplied by 4.
> "YCbCr to RGB: BT.709 full-swing":
>   Only valid for YCbCr formats. CSC in accordance with BT.709,
>   but using the full range of each channel.

We already have a standardized property for broadcast vs. full range. So
needs to be taken out of this one here to avoid silly interactions. It's
not yet atomic-ified though (i.e. not tracked in drm_connector_state).
It's a bit annoying since it's on the connector, but with sufficient glue
we can fix this.

Your helper should probably take that into account too.

> "YCbCr to RGB: Use CTM":*
>   Only valid for YCbCr formats. Use the matrix applied via the
>   plane's CTM property
> "RGB to RGB: Use CTM":*
>   Only valid for RGB formats. Use the matrix applied via the
>   plane's CTM property
> "Use CTM":*
>   Valid for any format. Use the matrix applied via the plane's
>   CTM property
> ... any other values for BT.601, BT.2020, RGB to YCbCr etc. etc. as
> they are required.
> 
> *This assumes color-management is enabled per-plane. We're currently
> working on patches to add this mostly to be able to use per-plane
> degamma, but it would be analogous to the CRTC color-management code
> and so also be able to expose a per-plane CTM property.
> 
> Our hardware implements the color-space conversion as a 3x3 matrix, so
> we can implement a helper to convert a CSC enum value to a CTM matrix
> for use by any hardware which has a programmable CSC matrix. For any
> other hardware, the driver simply needs to map the enum value to
> whatever selector bits are available.
> 
> It's expected that the "Use CTM" value(s) are *not* the common case,
> and most of the time userspace will use one of the provided "standard"
> enum values. The three different flavours of "Use CTM" allow us to
> support hardware whose CSC hardware can only be used on e.g. YCbCr
> data.
> 
> Drivers can of course filter the enum list to expose whichever subset
> the hardware can support.
> 
> Having thrashed this out a bit on IRC with Ville, I think the above
> approach is flexible enough to support at least Mali-DP and i915,
> without burdening userspace any more than necessary. It also provides
> the "default" behaviour which is backwards compatible, and allows for
> fully custom CSC matrices where that is supported.
> 
> We can obviously implement this as a Mali-DP driver private property,
> but it would be good to come up with something to go into the core if
> possible.

It needs userspace either way :-) And I think the tricky bit here is
interaction with the CTM stuff we already have, i.e. what happens when
userspace sets both this and the CTM? Would our helper need to be able to
merge the explicit CTM with the implicit one here with some matrix
multiplication? If we go with "kernel multiplies them" then we could
simplify things a lot I think, since all we'd need is just "none, BT.709,
BT.601, ..." and none of the special values that define interactions with
the CTM.

Or we just chicken out for now and say you can't have a per-plane CTM if
you expose this :-) Since there's no per-plane CTM userspace yet, this is
probably the simplest option ...
-Daniel

> 
> I'd be happy to hear any feedback,
> 
> Thanks,
> Brian
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to