Re: [Libva] something different ideas from chromium's decoder settings API

2016-10-16 Thread Xiang, Haihao 

Hi Randy, 

I saw a statement below at the end of your email:

==
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please
contact the sender by reply e-mail and destroy all copies of the
original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
==

Please do not send your email to li...@lists.freedesktop.org if you
don't want to discuss your question/idea publicly because libva@lists.f
reedesktop is only used for public discussion of libva, otherwise
please remove the above statement in your email.

Thanks
Haihao

cron job: media_tree daily build: ERRORS

2016-10-16 Thread 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:   Mon Oct 17 05:00:14 CEST 2016
media-tree git hash:11a1e0ed7908f04c896e69d0eb65e478c12f8519
media_build git hash:   ecfc9bfca3012b0c6e19967ce90f621f71a6da94
v4l-utils git hash: 79186f9d3d9d3b6bee4a611bd92435d11807
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.7.0-164

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

Detailed results are available here:

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

Full logs are available here:

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

something different ideas from chromium's decoder settings API

2016-10-16 Thread Randy Li 

Hello Hans and all media staff:
  Recently I have try to run the my VA-API driver in Rockchip RK3399, 
after ported the driver in chromium to request API, it works now.
Thanks to the chromium project effort, both the decoder settings API and 
structures are the same between rk3288 and rk3399.
  However the those v4l2 decoder structures are too different between 
the VA-API, I know those VA-API structures would not enough for our 
situation. If we could expend the VA-API structures, it sounds more easy 
to start up a standard.
  Also creating a new v4l2 fourcc for each format is not convenience, 
also the data format may be a little different, but it is still a part 
of the original data right?
  The slice API and request API are still not clearly, I just put my 
ideas here and hoping more ideas coming.
P.S Does somebody know where the chromium would switch to request API 
instead of the config store?

--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

--
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 04/22] [media] v4l2-subdev.h: add prepare_stream op

2016-10-16 Thread Sakari Ailus 
On Fri, Oct 14, 2016 at 05:48:43PM +0200, Philipp Zabel wrote:
> Am Samstag, den 08.10.2016, 02:16 +0300 schrieb Sakari Ailus:
> > Hi Philipp,
> > 
> > On Fri, Oct 07, 2016 at 06:00:49PM +0200, Philipp Zabel wrote:
> > > In some cases, for example MIPI CSI-2 input on i.MX6, the sending and
> > > receiving subdevice need to be prepared in lock-step before the actual
> > > streaming can start. In the i.MX6 MIPI CSI-2 case, the sender needs to
> > > put its MIPI CSI-2 transmitter lanes into stop state, and the receiver
> > > needs to configure its D-PHY and detect the stop state on all active
> > > lanes. Only then the sender can be enabled to stream data and the
> > > receiver can lock its PLL to the clock lane.
> > 
> > Is there a need to explicitly control this? Shouldn't this already be the
> > case when the transmitting device is powered on and is not streaming?
> 
> Even if the transmitter is expected to keep the lanes in this stop state
> all the time while the subdevice is powered but not streaming, I still
> have to wait for stop state detection before enabling the transmitter,
> and only then enable the reciever.
> I'll remove the prepare_streaming callback in the next version and
> instead let the subdevices propagate s_stream upstream instead in the
> next version.

Ack.

As discussed, I'll provide a patch to document this behaviour on CSI-2. I
believe the current drivers implicitly implement it but you're the first one
to ask the question. :-)

-- 
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: [PATCH] Potential fix for "[BUG] process stuck when closing saa7146 [dvb_ttpci]"

2016-10-16 Thread Philipp Matthias Hahn 
Hello Andrey,

On Mon, Sep 19, 2016 at 07:08:52AM +0200, Philipp Hahn wrote:
> Am 16.09.2016 um 12:00 schrieb Andrey Utkin:
> > Please try this patch. It is purely speculative as I don't have the 
> > hardware,
> > but I hope my approach is right.
> 
> Thanks you for the patch; I've built a new kernel but didn't have the
> time to test it yet; I'll mail you again as soon as I have tested it.

I tested your patch and during my limites testing I wan't able to
reproduce the previous problem. Seems you fixed it.

Tested-by: Philipp Matthias Hahn 

Thanks you again for looking into that issues.

Philipp
-- 
  / /  (_)__  __   __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ pmh...@pmhahn.de
--
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 18/22] [media] imx-ipuv3-csi: support downsizing

2016-10-16 Thread Marek Vasut 
On 10/14/2016 05:48 PM, Philipp Zabel wrote:
> Am Freitag, den 07.10.2016, 21:01 +0200 schrieb Marek Vasut:
>> On 10/07/2016 06:01 PM, Philipp Zabel wrote:
>>> Add support for the CSI internal horizontal and vertical downsizing.
>>>
>>> Signed-off-by: Philipp Zabel 
>>> ---
>>>  drivers/media/platform/imx/imx-ipuv3-csi.c | 20 ++--
>>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/imx/imx-ipuv3-csi.c 
>>> b/drivers/media/platform/imx/imx-ipuv3-csi.c
>>> index 699460e6..e8a6a7b 100644
>>> --- a/drivers/media/platform/imx/imx-ipuv3-csi.c
>>> +++ b/drivers/media/platform/imx/imx-ipuv3-csi.c
>>> @@ -167,8 +167,16 @@ static int ipucsi_subdev_set_format(struct v4l2_subdev 
>>> *sd,
>>> width = clamp_t(unsigned int, sdformat->format.width, 16, 8192);
>>> height = clamp_t(unsigned int, sdformat->format.height, 16, 
>>> 4096);
>>> } else {
>>> -   width = ipucsi->format_mbus[0].width;
>>> -   height = ipucsi->format_mbus[0].height;
>>> +   if (sdformat->format.width <
>>> +   (ipucsi->format_mbus[0].width * 3 / 4))
>>> +   width = ipucsi->format_mbus[0].width / 2;
>>> +   else
>>> +   width = ipucsi->format_mbus[0].width;
>>> +   if (sdformat->format.height <
>>> +   (ipucsi->format_mbus[0].height * 3 / 4))
>>> +   height = ipucsi->format_mbus[0].height / 2;
>>> +   else
>>> +   height = ipucsi->format_mbus[0].height;
>>> }
>>>  
>>> mbusformat = __ipucsi_get_pad_format(sd, cfg, sdformat->pad,
>>> @@ -212,14 +220,14 @@ static int ipucsi_subdev_s_stream(struct v4l2_subdev 
>>> *sd, int enable)
>>> window.width = fmt[0].width;
>>> window.height = fmt[0].height;
>>> ipu_csi_set_window(ipucsi->csi, );
>>> +   ipu_csi_set_downsize(ipucsi->csi,
>>> +fmt[0].width == 2 * fmt[1].width,
>>> +fmt[0].height == 2 * fmt[1].height);
>>>  
>>> /* Is CSI data source MCT (MIPI)? */
>>> mux_mct = (mbus_config.type == V4L2_MBUS_CSI2);
>>> -
>>> ipu_set_csi_src_mux(ipucsi->ipu, ipucsi->id, mux_mct);
>>> -   if (mux_mct)
>>> -   ipu_csi_set_mipi_datatype(ipucsi->csi, /*VC*/ 0,
>>> - [0]);
>>> +   ipu_csi_set_mipi_datatype(ipucsi->csi, /*VC*/ 0, [0]);
>>
>> This probably needs fixing , so that the correct VC is passed in ?
> 
> Absolutely, right now I don't know how though.
> We are still missing API to set the MIPI CSI-2 virtual channel.

Right. And since most cameras use VC0 anyway, it's unlikely anyone will
be severely affected by this, so this shouldn't be considered a blocker
for this patchset. Maybe add a comment, something along the lines of
"FIXME: We are still missing an API for setting VC != 0" .


-- 
Best regards,
Marek Vasut
--
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: omap4iss: fixed coding style issues

2016-10-16 Thread Greg KH 
On Sun, Oct 16, 2016 at 05:18:56PM +0200, Hector Roussille wrote:
> Fixed coding style issues


You need to be a lot more specific please.

thanks,

greg k-h
--
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: omap4iss: fixed coding style issues

2016-10-16 Thread Laurent Pinchart 
Hi Hector,

Thank you for the patch.

On Sunday 16 Oct 2016 17:18:56 Hector Roussille wrote:
> Fixed coding style issues

What coding style issues ?

> 
> Signed-off-by: Hector Roussille 
> ---
>  drivers/staging/media/omap4iss/iss_video.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index c16927a..8f2d374 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -297,8 +297,10 @@ 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,

This line doesn't exceed the 80 columns limit, no need to split it.

> -  unsigned int sizes[], struct device 
*alloc_devs[])
> +  unsigned int *count,
> +  unsigned int *num_planes,
> +  unsigned int sizes[],
> +  struct device *alloc_devs[])
>  {
>   struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
>   struct iss_video *video = vfh->video;
> @@ -678,9 +680,10 @@ 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

while do you split the line here and not right before the 80 columns limit ?

> +  * get format if not implemented.
>*/

This isn't the preferred comment style for the kernel, see 
http://lkml.iu.edu/hypermail/linux/kernel/1607.1/00627.html. The problem 
doesn't predate your patch, but while at it you might want to fix it through 
the driver.

> +

How does adding a blank line here fix a coding style issue ?

>   sdsel.pad = pad;
>   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
>   if (!ret)

-- 
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] Staging: media: omap4iss: fixed coding style issues

2016-10-16 Thread Hector Roussille 
Fixed coding style issues

Signed-off-by: Hector Roussille 
---
 drivers/staging/media/omap4iss/iss_video.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss_video.c 
b/drivers/staging/media/omap4iss/iss_video.c
index c16927a..8f2d374 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -297,8 +297,10 @@ 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 *count,
+unsigned int *num_planes,
+unsigned int sizes[],
+struct device *alloc_devs[])
 {
struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
struct iss_video *video = vfh->video;
@@ -678,9 +680,10 @@ 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, );
if (!ret)
-- 
2.10.0

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

Re: RFC - unclear change in "[media] DiBxxxx: Codingstype updates"

2016-10-16 Thread Nicholas Mc Guire 
On Mon, Oct 10, 2016 at 08:31:12AM +0200, Patrick Boettcher wrote:
> Hi, der Herr Hofrat ;-)
> 
> On Sat, 8 Oct 2016 13:57:14 +
> Nicholas Mc Guire  wrote:
> > - lo6 |= (1 << 2) | 2;
> > - else
> > - lo6 |= (1 << 2) | 1;
> > + lo6 |= (1 << 2) | 2;//SigmaDelta and Dither
> > + else {
> > + if (state->identity.in_soc)
> > + lo6 |= (1 << 2) | 2;//SigmaDelta and
> > Dither
> > + else
> > + lo6 |= (1 << 2) | 2;//SigmaDelta and
> > Dither
> > + }
> > 
> >  resulting in the current code-base of:
> > 
> >if (Rest > 0) {
> >if (state->config->analog_output)
> >lo6 |= (1 << 2) | 2;
> >else {
> >if (state->identity.in_soc)
> >lo6 |= (1 << 2) | 2;
> >else
> >lo6 |= (1 << 2) | 2;
> >}
> >Den = 255;
> >}
> > 
> >  The problem now is that the if and the else(if/else) are
> >  all the same and thus the conditions have no effect. Further
> >  the origninal code actually had different if/else - so I 
> >  wonder if this is a cut bug here ?
> 
> I may answer on behalf of Olivier (didn't his address bounce?).
> 
> I don't remember the details, this patch must date from 2011 or
> before, but at that time we generated the linux-driver from our/their
> internal sources.
> 
> Updates in this area were achieved by a lot of thinking + a mix of trial
> and error (after hours/days/weeks of RF hardware validation). 
> 
> This logic above has 3 possibilities: 
> 
>   - we use the analog-output, or 
>   - we are using the digital one, then there is whether we are being in
> a SoC or not (SIP or sinlge chip).
> 
> At some point in time all values have been different. In the end, they
> aren't anymore, but in case someone wants to try a different value,
> there are placeholders in the code to easily inject these values.
> 
> Now the device is stable, maybe even obsolete. We could remove all the
> branches resulting in the same value for lo6.
>
ok - so as the value for lo6 effectively is the same for all conditions

given (1 << 2) | 2 == 6

this might be simplified to and commented as:
 
if (Rest > 0) {
/* Based on trial and error */
lo6 |= 6;
Den = 255;
}

let me know if that sounds resonable - just plugging in a magic number
sounds like a bad idea - even if this comment might not be wildly enlightening
it atleast indicates that it is known "magic".

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

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

2016-10-16 Thread Laurent Pinchart 
Hi Steve,

Thank you for the patch.

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

This is a vendor-specific property, it should be prefixed with "adi,". Could 
you also explain how this mode works ? I'd like to make sure it qualifies for 
a DT property.

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

-- 
Regards,

[PATCH] [media] usbtv: add video controls

2016-10-16 Thread Lubomir Rintel 
Brightness, Contrast, Hue and Color Saturation are supported.

Signed-off-by: Lubomir Rintel 
---
 drivers/media/usb/usbtv/usbtv-video.c | 97 ++-
 drivers/media/usb/usbtv/usbtv.h   |  3 ++
 2 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/usbtv/usbtv-video.c 
b/drivers/media/usb/usbtv/usbtv-video.c
index 2a08975..dca4fcb 100644
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013 Lubomir Rintel
+ * Copyright (c) 2013,2016 Lubomir Rintel
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -259,6 +259,10 @@ static int usbtv_setup_capture(struct usbtv *usbtv)
if (ret)
return ret;
 
+   ret = v4l2_ctrl_handler_setup(>ctrl);
+   if (ret)
+   return ret;
+
return 0;
 }
 
@@ -696,11 +700,83 @@ static struct vb2_ops usbtv_vb2_ops = {
.stop_streaming = usbtv_stop_streaming,
 };
 
+static int usbtv_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct usbtv *usbtv = container_of(ctrl->handler, struct usbtv,
+   ctrl);
+   u8 data[3];
+   u16 index, size;
+   int ret;
+
+   /*
+* Read in the current brightness/contrast registers. We need them
+* both, because the values are for some reason interleaved.
+*/
+   if (ctrl->id == V4L2_CID_BRIGHTNESS || ctrl->id == V4L2_CID_CONTRAST) {
+   ret = usb_control_msg(usbtv->udev,
+   usb_sndctrlpipe(usbtv->udev, 0), USBTV_CONTROL_REG,
+   USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+   0, USBTV_BASE + 0x0244, (void *)data, 3, 0);
+   }
+
+   switch (ctrl->id) {
+   case V4L2_CID_BRIGHTNESS:
+   index = USBTV_BASE + 0x0244;
+   size = 3;
+   data[0] &= 0xf0;
+   data[0] |= (ctrl->val >> 8) & 0xf;
+   data[2] = ctrl->val & 0xff;
+   break;
+   case V4L2_CID_CONTRAST:
+   index = USBTV_BASE + 0x0244;
+   size = 3;
+   data[0] &= 0x0f;
+   data[0] |= (ctrl->val >> 4) & 0xf0;
+   data[1] = ctrl->val & 0xff;
+   break;
+   case V4L2_CID_SATURATION:
+   index = USBTV_BASE + 0x0242;
+   data[0] = ctrl->val >> 8;
+   data[1] = ctrl->val & 0xff;
+   size = 2;
+   break;
+   case V4L2_CID_HUE:
+   index = USBTV_BASE + 0x0240;
+   size = 2;
+   if (ctrl->val > 0) {
+   data[0] = 0x92 + (ctrl->val >> 8);
+   data[1] = ctrl->val & 0xff;
+   } else {
+   data[0] = 0x82 + (-ctrl->val >> 8);
+   data[1] = -ctrl->val & 0xff;
+   }
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = usb_control_msg(usbtv->udev, usb_sndctrlpipe(usbtv->udev, 0),
+   USBTV_CONTROL_REG,
+   USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+   0, index, (void *)data, size, 0);
+   if (ret < 0) {
+   dev_warn(usbtv->dev, "Failed to submit a control request.\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct v4l2_ctrl_ops usbtv_ctrl_ops = {
+   .s_ctrl = usbtv_s_ctrl,
+};
+
 static void usbtv_release(struct v4l2_device *v4l2_dev)
 {
struct usbtv *usbtv = container_of(v4l2_dev, struct usbtv, v4l2_dev);
 
v4l2_device_unregister(>v4l2_dev);
+   v4l2_ctrl_handler_free(>ctrl);
vb2_queue_release(>vb2q);
kfree(usbtv);
 }
@@ -731,7 +807,24 @@ int usbtv_video_init(struct usbtv *usbtv)
return ret;
}
 
+   /* controls */
+   v4l2_ctrl_handler_init(>ctrl, 4);
+   v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
+   V4L2_CID_CONTRAST, 0, 0x3ff, 1, 0x1d0);
+   v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
+   V4L2_CID_BRIGHTNESS, 0, 0x3ff, 1, 0x1c0);
+   v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
+   V4L2_CID_SATURATION, 0, 0x3ff, 1, 0x200);
+   v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
+   V4L2_CID_HUE, -0xdff, 0xdff, 1, 0x000);
+   ret = usbtv->ctrl.error;
+   if (ret < 0) {
+   dev_warn(usbtv->dev, "Could not initialize controls\n");
+   goto ctrl_fail;
+   }
+
/* v4l2 structure */
+   usbtv->v4l2_dev.ctrl_handler = >ctrl;
usbtv->v4l2_dev.release = usbtv_release;
ret = v4l2_device_register(usbtv->dev, >v4l2_dev);
if (ret < 0) {
@@ -760,6 +853,8 @@ int usbtv_video_init(struct usbtv *usbtv)
 vdev_fail:
v4l2_device_unregister(>v4l2_dev);
 v4l2_fail:
+ctrl_fail:
+