[PATCH 0/6] [media] cx24116: Adjustments for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 09:05:04 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (6):
  Delete an error message for a failed memory allocation in cx24116_writeregN()
  Return directly after a failed kmalloc() in cx24116_writeregN()
  Delete an unnecessary variable initialisation in cx24116_writeregN()
  Improve a size determination in cx24116_attach()
  Delete an unnecessary variable initialisation in cx24116_attach()
  Delete jump targets in cx24116_attach()

 drivers/media/dvb-frontends/cx24116.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

-- 
2.14.1

[PATCH 1/6] [media] cx24116: Delete an error message for a failed memory allocation in cx24116_writeregN()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 29 Aug 2017 22:56:29 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/cx24116.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index e105532bfba8..96af4ffba0f9 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -227,7 +227,6 @@ static int cx24116_writeregN(struct cx24116_state *state, 
int reg,
 
buf = kmalloc(len + 1, GFP_KERNEL);
if (buf == NULL) {
-   printk("Unable to kmalloc\n");
ret = -ENOMEM;
goto error;
}
-- 
2.14.1

[PATCH 2/6] [media] cx24116: Return directly after a failed kmalloc() in cx24116_writeregN()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 07:55:49 +0200

* Return directly after a call of the function "kmalloc" failed
  at the beginning.

* Delete the jump target "error" which became unnecessary
  with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/cx24116.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index 96af4ffba0f9..69c156443b50 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -226,10 +226,8 @@ static int cx24116_writeregN(struct cx24116_state *state, 
int reg,
u8 *buf;
 
buf = kmalloc(len + 1, GFP_KERNEL);
-   if (buf == NULL) {
-   ret = -ENOMEM;
-   goto error;
-   }
+   if (!buf)
+   return -ENOMEM;
 
*(buf) = reg;
memcpy(buf + 1, data, len);
@@ -250,7 +248,6 @@ static int cx24116_writeregN(struct cx24116_state *state, 
int reg,
ret = -EREMOTEIO;
}
 
-error:
kfree(buf);
 
return ret;
-- 
2.14.1

[PATCH 3/6] [media] cx24116: Delete an unnecessary variable initialisation in cx24116_writeregN()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 08:10:38 +0200

The variable "ret" will eventually be set to an appropriate value
a bit later. Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/cx24116.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index 69c156443b50..54f09a5a5075 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -221,7 +221,7 @@ static int cx24116_writereg(struct cx24116_state *state, 
int reg, int data)
 static int cx24116_writeregN(struct cx24116_state *state, int reg,
 const u8 *data, u16 len)
 {
-   int ret = -EREMOTEIO;
+   int ret;
struct i2c_msg msg;
u8 *buf;
 
-- 
2.14.1

[PATCH 4/6] [media] cx24116: Improve a size determination in cx24116_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 08:15:33 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/cx24116.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index 54f09a5a5075..74d610207bf2 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -1123,7 +1123,7 @@ struct dvb_frontend *cx24116_attach(const struct 
cx24116_config *config,
dprintk("%s\n", __func__);
 
/* allocate memory for the internal state */
-   state = kzalloc(sizeof(struct cx24116_state), GFP_KERNEL);
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
if (state == NULL)
goto error1;
 
-- 
2.14.1

[PATCH 5/6] [media] cx24116: Delete an unnecessary variable initialisation in cx24116_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 08:30:12 +0200

The variable "state" will be set to an appropriate pointer a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/cx24116.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index 74d610207bf2..902a60d2e1b5 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -1117,7 +1117,7 @@ static const struct dvb_frontend_ops cx24116_ops;
 struct dvb_frontend *cx24116_attach(const struct cx24116_config *config,
struct i2c_adapter *i2c)
 {
-   struct cx24116_state *state = NULL;
+   struct cx24116_state *state;
int ret;
 
dprintk("%s\n", __func__);
-- 
2.14.1

[PATCH 6/6] [media] cx24116: Delete jump targets in cx24116_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 08:44:29 +0200

* Return directly after a call of the function "kzalloc" failed
  at the beginning.

* Move a bit of exception handling code into an if branch.

* Delete two jump targets which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/cx24116.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index 902a60d2e1b5..8fb3f095e21c 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -1125,7 +1125,7 @@ struct dvb_frontend *cx24116_attach(const struct 
cx24116_config *config,
/* allocate memory for the internal state */
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (state == NULL)
-   goto error1;
+   return NULL;
 
state->config = config;
state->i2c = i2c;
@@ -1134,8 +1134,9 @@ struct dvb_frontend *cx24116_attach(const struct 
cx24116_config *config,
ret = (cx24116_readreg(state, 0xFF) << 8) |
cx24116_readreg(state, 0xFE);
if (ret != 0x0501) {
+   kfree(state);
printk(KERN_INFO "Invalid probe, probably not a CX24116 
device\n");
-   goto error2;
+   return NULL;
}
 
/* create dvb_frontend */
@@ -1143,9 +1144,6 @@ struct dvb_frontend *cx24116_attach(const struct 
cx24116_config *config,
sizeof(struct dvb_frontend_ops));
state->frontend.demodulator_priv = state;
return &state->frontend;
-
-error2: kfree(state);
-error1: return NULL;
 }
 EXPORT_SYMBOL(cx24116_attach);
 
-- 
2.14.1

Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS

[Simon Horman]

On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> In order to test Virtual Channels use VC1 for CVBS input from the
> adv748x.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index 7b67efcb1d22090a..8047fe1df065d63b 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -41,7 +41,7 @@
>   };
>  
>   chosen {
> - bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp 
> adv748x.txbvc=1";
>   stdout-path = "serial0:115200n8";
>   };

Hi Niklas,

I'm somewhat surprised to see what appears to be a new module parameter.
I'm not going to reject this but did you give consideration to doing this
another way?

In any case I have marked this as "Deferred" pending acceptance of the
driver change. If you think it can go in now then I'm open to discussion.

Re: DRM Format Modifiers in v4l2

[Daniel Vetter]

On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
> On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne  
> > wrote:
> > > Le jeudi 24 ao??t 2017 ?? 13:26 +0100, Brian Starkey a ??crit :
> > > > > What I mean was: an application can use the modifier to give buffers 
> > > > > from
> > > > > one device to another without needing to understand it.
> > > > >
> > > > > But a generic video capture application that processes the video 
> > > > > itself
> > > > > cannot be expected to know about the modifiers. It's a custom HW 
> > > > > specific
> > > > > format that you only use between two HW devices or with software 
> > > > > written
> > > > > for that hardware.
> > > > >
> > > > 
> > > > Yes, makes sense.
> > > > 
> > > > > >
> > > > > > However, in DRM the API lets you get the supported formats for each
> > > > > > modifier as-well-as the modifier list itself. I'm not sure how 
> > > > > > exactly
> > > > > > to provide that in a control.
> > > > >
> > > > > We have support for a 'menu' of 64 bit integers: 
> > > > > V4L2_CTRL_TYPE_INTEGER_MENU.
> > > > > You use VIDIOC_QUERYMENU to enumerate the available modifiers.
> > > > >
> > > > > So enumerating these modifiers would work out-of-the-box.
> > > > 
> > > > Right. So I guess the supported set of formats could be somehow
> > > > enumerated in the menu item string. In DRM the pairs are (modifier +
> > > > bitmask) where bits represent formats in the supported formats list
> > > > (commit db1689aa61bd in drm-next). Printing a hex representation of
> > > > the bitmask would be functional but I concede not very pretty.
> > > 
> > > The problem is that the list of modifiers depends on the format
> > > selected. Having to call S_FMT to obtain this list is quite
> > > inefficient.
> > > 
> > > Also, be aware that DRM_FORMAT_MOD_SAMSUNG_64_32_TILE modifier has been
> > > implemented in V4L2 with a direct format (V4L2_PIX_FMT_NV12MT). I think
> > > an other one made it the same way recently, something from Mediatek if
> > > I remember. Though, unlike the Intel one, the same modifier does not
> > > have various result depending on the hardware revision.
> > 
> > Note on the intel modifers: On most recent platforms (iirc gen9) the
> > modifier is well defined and always describes the same byte layout. We
> > simply didn't want to rewrite our entire software stack for all the
> > old gunk platforms, hence the language. I guess we could/should
> > describe the layout in detail, but atm we're the only ones using it.
> > 
> > On your topic of v4l2 encoding the drm fourcc+modifier combo into a
> > special v4l fourcc: That's exactly the mismatch I was thinking of.
> > There's other examples of v4l2 fourcc being more specific than their
> > drm counters (e.g. specific way the different planes are laid out).
> 
> I'm not entirely clear on the v4l2 fourccs being more specific than
> DRM ones - do you mean e.g. NV12 vs NV12M? Specifically in the case of
> multi-planar formats I think it's a non-issue because modifiers are
> allowed to alter the number of planes and the meanings of them. Also
> V4L2 NV12M is a superset of NV12 - so NV12M would always be able to
> describe a DRM NV12 buffer.
> 
> I don't see the "special v4l2 format already exists" case as a problem
> either. It would be up to any drivers that already have special
> formats to decide if they want to also support it via a more generic
> modifiers API or not.
> 
> The fact is, adding special formats for each combination is
> unmanageable - we're talking dozens in the case of our hardware.

Hm right, we can just remap the special combos to the drm-fourcc +
modifier style. Bonus point if v4l does that in the core so not everyone
has to reinvent that wheel :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS

[Niklas Söderlund]

Hi Simon,

On 2017-08-30 09:36:37 +0200, Simon Horman wrote:
> On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> > In order to test Virtual Channels use VC1 for CVBS input from the
> > adv748x.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
> > b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > index 7b67efcb1d22090a..8047fe1df065d63b 100644
> > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > @@ -41,7 +41,7 @@
> > };
> >  
> > chosen {
> > -   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> > +   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp 
> > adv748x.txbvc=1";
> > stdout-path = "serial0:115200n8";
> > };
> 
> Hi Niklas,
> 
> I'm somewhat surprised to see what appears to be a new module parameter.
> I'm not going to reject this but did you give consideration to doing this
> another way?

This is my fault when sending this series out it should be marked as RFC 
as it's stated in the cover-letter. This new module parameter is not 
intended to be unstreamed, not even the driver parts. It's only usage is 
to be able to easy test the multiplexed media pad using the onboard 
Salvator-X components.

> 
> In any case I have marked this as "Deferred" pending acceptance of the
> driver change. If you think it can go in now then I'm open to discussion.

You can mark it as rejected and forget about it :-)

-- 
Regards,
Niklas Söderlund

Re: DRM Format Modifiers in v4l2

[Hans Verkuil]

On 30/08/17 09:50, Daniel Vetter wrote:
> On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
>> On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote:
>>> On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne  
>>> wrote:
 Le jeudi 24 ao??t 2017 ?? 13:26 +0100, Brian Starkey a ??crit :
>> What I mean was: an application can use the modifier to give buffers from
>> one device to another without needing to understand it.
>>
>> But a generic video capture application that processes the video itself
>> cannot be expected to know about the modifiers. It's a custom HW specific
>> format that you only use between two HW devices or with software written
>> for that hardware.
>>
>
> Yes, makes sense.
>
>>>
>>> However, in DRM the API lets you get the supported formats for each
>>> modifier as-well-as the modifier list itself. I'm not sure how exactly
>>> to provide that in a control.
>>
>> We have support for a 'menu' of 64 bit integers: 
>> V4L2_CTRL_TYPE_INTEGER_MENU.
>> You use VIDIOC_QUERYMENU to enumerate the available modifiers.
>>
>> So enumerating these modifiers would work out-of-the-box.
>
> Right. So I guess the supported set of formats could be somehow
> enumerated in the menu item string. In DRM the pairs are (modifier +
> bitmask) where bits represent formats in the supported formats list
> (commit db1689aa61bd in drm-next). Printing a hex representation of
> the bitmask would be functional but I concede not very pretty.

 The problem is that the list of modifiers depends on the format
 selected. Having to call S_FMT to obtain this list is quite
 inefficient.

 Also, be aware that DRM_FORMAT_MOD_SAMSUNG_64_32_TILE modifier has been
 implemented in V4L2 with a direct format (V4L2_PIX_FMT_NV12MT). I think
 an other one made it the same way recently, something from Mediatek if
 I remember. Though, unlike the Intel one, the same modifier does not
 have various result depending on the hardware revision.
>>>
>>> Note on the intel modifers: On most recent platforms (iirc gen9) the
>>> modifier is well defined and always describes the same byte layout. We
>>> simply didn't want to rewrite our entire software stack for all the
>>> old gunk platforms, hence the language. I guess we could/should
>>> describe the layout in detail, but atm we're the only ones using it.
>>>
>>> On your topic of v4l2 encoding the drm fourcc+modifier combo into a
>>> special v4l fourcc: That's exactly the mismatch I was thinking of.
>>> There's other examples of v4l2 fourcc being more specific than their
>>> drm counters (e.g. specific way the different planes are laid out).
>>
>> I'm not entirely clear on the v4l2 fourccs being more specific than
>> DRM ones - do you mean e.g. NV12 vs NV12M? Specifically in the case of
>> multi-planar formats I think it's a non-issue because modifiers are
>> allowed to alter the number of planes and the meanings of them. Also
>> V4L2 NV12M is a superset of NV12 - so NV12M would always be able to
>> describe a DRM NV12 buffer.
>>
>> I don't see the "special v4l2 format already exists" case as a problem
>> either. It would be up to any drivers that already have special
>> formats to decide if they want to also support it via a more generic
>> modifiers API or not.
>>
>> The fact is, adding special formats for each combination is
>> unmanageable - we're talking dozens in the case of our hardware.
> 
> Hm right, we can just remap the special combos to the drm-fourcc +
> modifier style. Bonus point if v4l does that in the core so not everyone
> has to reinvent that wheel :-)

Probably not something we'll do: there are I believe only two drivers that
are affected (exynos & mediatek), so they can do that in their driver.

Question: how many modifiers will typically apply to a format? I ask
because I realized that V4L2 could use VIDIOC_ENUMFMT to make the link
between a fourcc and modifiers:

https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enum-fmt.html

The __u32 reserved[4] array can be used to provide a bitmask to modifier
indices (for the integer menu control). It's similar to what drm does,
except instead of modifiers mapping to fourccs it is the other way around.

This would avoid having to change the modifiers control whenever a new
format is set and it makes it easy to enumerate all combinations.

But this only works if the total number of modifiers used by a single driver
is expected to remain small (let's say no more than 64).

Regards,

Hans

[PATCH] atomisp: fix small Kconfig issues

[Hans Verkuil]

The help text should be indented by at least two spaces after the
'help' separator. This is both good practice and the media_build system
for building media drivers makes this assumption.

Fix this for the atomisp/i2c/Kconfig and fix the atomisp/pci/Kconfig
that didn't align the help separator with the preceding keywords.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/staging/media/atomisp/i2c/Kconfig 
b/drivers/staging/media/atomisp/i2c/Kconfig
index b80d29d53e65..e628b5c37455 100644
--- a/drivers/staging/media/atomisp/i2c/Kconfig
+++ b/drivers/staging/media/atomisp/i2c/Kconfig
@@ -75,8 +75,8 @@ config VIDEO_GC0310
tristate "GC0310 sensor support"
 depends on I2C && VIDEO_V4L2
 ---help---
- This is a Video4Linux2 sensor-level driver for the Galaxycore
- GC0310 0.3MP sensor.
+  This is a Video4Linux2 sensor-level driver for the Galaxycore
+  GC0310 0.3MP sensor.

 config VIDEO_OV2680
tristate "Omnivision OV2680 sensor support"
diff --git a/drivers/staging/media/atomisp/pci/Kconfig 
b/drivers/staging/media/atomisp/pci/Kconfig
index a72421431c7a..6b2203e6d511 100644
--- a/drivers/staging/media/atomisp/pci/Kconfig
+++ b/drivers/staging/media/atomisp/pci/Kconfig
@@ -3,11 +3,11 @@
 #

 config VIDEO_ATOMISP
-   tristate "Intel Atom Image Signal Processor Driver"
-   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
-   select VIDEOBUF_VMALLOC
----help---
-  Say Y here if your platform supports Intel Atom SoC
-  camera imaging subsystem.
-  To compile this driver as a module, choose M here: the
-  module will be called atomisp
+   tristate "Intel Atom Image Signal Processor Driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   select VIDEOBUF_VMALLOC
+   ---help---
+ Say Y here if your platform supports Intel Atom SoC
+ camera imaging subsystem.
+ To compile this driver as a module, choose M here: the
+ module will be called atomisp

[PATCH] media: fix media Kconfig help syntax issues

[Hans Verkuil]

The help text should be indented by at least two spaces after the
'help' separator. This is both good practice and the media_build system
for building media drivers makes this assumption.

I went through all Kconfigs under drivers/media and fixed any bad help
sections. This makes it conform to the common practice and should fix
problems with 'make menuconfig' when using media_build. This is due to
a "WARNING" message that media_build can insert in the Kconfig and that
assumes the help text is indented by at least two spaces. If not, then the
Kconfig becomes invalid and 'make menuconfig' fails.

Signed-off-by: Hans Verkuil 
Reported-by: Thomas Kaiser 
---
Mauro, please double-check the drivers/media/pci/netup_unidvb/Kconfig change:
that Kconfig was really bad and had *two* help sections for the same entry.
---
diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index 2631d0e0a024..d17722eb4456 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -173,7 +173,7 @@ config DVB_STB6000
tristate "ST STB6000 silicon tuner"
depends on DVB_CORE && I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
- help
+   help
  A DVB-S silicon tuner module. Say Y when you want to support this 
tuner.

 config DVB_STV0299
@@ -187,7 +187,7 @@ config DVB_STV6110
tristate "ST STV6110 silicon tuner"
depends on DVB_CORE && I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
- help
+   help
  A DVB-S silicon tuner module. Say Y when you want to support this 
tuner.

 config DVB_STV0900
@@ -902,7 +902,7 @@ config DVB_HELENE
depends on DVB_CORE && I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
help
-   Say Y when you want to support this frontend.
+ Say Y when you want to support this frontend.

 comment "Tools to develop new frontends"

diff --git a/drivers/media/pci/b2c2/Kconfig b/drivers/media/pci/b2c2/Kconfig
index 58761a21caa0..7b818d445f39 100644
--- a/drivers/media/pci/b2c2/Kconfig
+++ b/drivers/media/pci/b2c2/Kconfig
@@ -11,5 +11,5 @@ config DVB_B2C2_FLEXCOP_PCI_DEBUG
depends on DVB_B2C2_FLEXCOP_PCI
select DVB_B2C2_FLEXCOP_DEBUG
help
-   Say Y if you want to enable the module option to control debug messages
-   of all B2C2 FlexCop drivers.
+ Say Y if you want to enable the module option to control debug 
messages
+ of all B2C2 FlexCop drivers.
diff --git a/drivers/media/pci/netup_unidvb/Kconfig 
b/drivers/media/pci/netup_unidvb/Kconfig
index 0ad37714c7fd..356fff6e6907 100644
--- a/drivers/media/pci/netup_unidvb/Kconfig
+++ b/drivers/media/pci/netup_unidvb/Kconfig
@@ -1,8 +1,8 @@
 config DVB_NETUP_UNIDVB
tristate "NetUP Universal DVB card support"
depends on DVB_CORE && VIDEO_DEV && PCI && I2C && SPI_MASTER
-select VIDEOBUF2_DVB
-select VIDEOBUF2_VMALLOC
+   select VIDEOBUF2_DVB
+   select VIDEOBUF2_VMALLOC
select DVB_HORUS3A if MEDIA_SUBDRV_AUTOSELECT
select DVB_ASCOT2E if MEDIA_SUBDRV_AUTOSELECT
select DVB_HELENE if MEDIA_SUBDRV_AUTOSELECT
@@ -10,8 +10,8 @@ config DVB_NETUP_UNIDVB
select DVB_CXD2841ER if MEDIA_SUBDRV_AUTOSELECT
---help---
  Support for NetUP PCI express Universal DVB card.
- help
-   Say Y when you want to support NetUP Dual Universal DVB card
-   Card can receive two independent streams in following standards:
+
+ Say Y when you want to support NetUP Dual Universal DVB card.
+ Card can receive two independent streams in following standards:
DVB-S/S2, T/T2, C/C2
-   Two CI slots available for CAM modules.
+ Two CI slots available for CAM modules.
diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index c480efb755f5..46a7d242a1a5 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -76,7 +76,7 @@ config VIDEO_EXYNOS4_ISP_DMA_CAPTURE
depends on VIDEO_EXYNOS4_FIMC_IS
select VIDEO_EXYNOS4_IS_COMMON
default y
- help
+   help
  This option enables an additional video device node exposing a V4L2
  video capture interface for the FIMC-IS ISP raw (Bayer) capture DMA.

diff --git a/drivers/media/radio/wl128x/Kconfig 
b/drivers/media/radio/wl128x/Kconfig
index c9e349b169c4..2add222ea346 100644
--- a/drivers/media/radio/wl128x/Kconfig
+++ b/drivers/media/radio/wl128x/Kconfig
@@ -7,11 +7,11 @@ config RADIO_WL128X
depends on VIDEO_V4L2 && RFKILL && TTY && TI_ST
depends on GPIOLIB || COMPILE_TEST
help
-   Choose Y here if you have this FM radio chip.
+ Choose Y here if you have this FM radio chip.

-   In order to control your radio card, you will need to use programs
-   that are compatible with the Video For Linux 2 API.  Information on
-   this API and pointers to "v4l2"

Re: [PATCH v1.5 0/6] R-Car DU: Fix IOMMU operation when connected to VSP

[Simon Horman]

On Fri, Dec 09, 2016 at 01:35:06PM +0100, Ulrich Hecht wrote:
> Hi!
> 
> This is a slightly updated version of Laurent's series that adds the fix
> suggested by Magnus Damm and connects the FCP devices on M3-W to their
> IPMMU. It also drops the patches that have already been picked up in the
> media tree.
> 
> With this series and an assortment of patches from the renesas-drivers tree (
> iommu/ipmmu-vmsa: Remove platform data handling
> iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context
> iommu/ipmmu-vmsa: Break out utlb parsing code
> iommu/ipmmu-vmsa: Break out domain allocation code
> iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> iommu/ipmmu-vmsa: ARM and ARM64 archdata access
> iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
> iommu/ipmmu-vmsa: Introduce features, break out alias
> iommu/ipmmu-vmsa: Add optional root device feature
> iommu/ipmmu-vmsa: Enable multi context support
> iommu/ipmmu-vmsa: Reuse iommu groups
> iommu/ipmmu-vmsa: Make use of IOMMU_OF_DECLARE()
> iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus
> iommu/ipmmu-vmsa: IPMMU device is 64-bit bus master
> iommu/ipmmu-vmsa: Write IMCTR twice
> iommu/ipmmu-vmsa: Make IMBUSCTR setup optional
> iommu/ipmmu-vmsa: Allow two bit SL0
> iommu/ipmmu-vmsa: Hook up r8a7795 DT matching code
> iommu/ipmmu-vmsa: Add r8a7796 DT binding
> iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
> arm64: dts: r8a7795: Add IPMMU device nodes
> arm64: dts: r8a7795: Hook up SYS-DMAC to IPMMU
> arm64: dts: r8a7795: Point FCP devices to IPMMU
> arm64: dts: r8a7795: Connect Ethernet AVB to IPMMU
> arm64: dts: r8a7796: Add IPMMU device nodes
> clk: renesas: r8a7796: Add FCP clocks
> clk: renesas: r8a7796: Add VSP clocks
> clk: renesas: r8a7796: Add DU and LVDS clocks
> drm: rcar-du: Add R8A7796 device support
> arm64: dts: renesas: r8a7795: Remove FCP SoC-specific compatible strings
> arm64: dts: renesas: r8a7796: Add FCPF and FCPV instances
> arm64: dts: renesas: r8a7796: Add VSP instances
> arm64: dts: renesas: r8a7796: Add DU device to DT
> arm64: dts: renesas: r8a7796-salvator-x: Enable DU
> ), I can enable IPMMU on both the H3 and M3-W Salvator-X boards with no ill
> effects on the results of the vsp-tests suite.
> 
> CU
> Uli
> 
> 
> Laurent Pinchart (4):
>   v4l: rcar-fcp: Don't get/put module reference
>   v4l: rcar-fcp: Add an API to retrieve the FCP device
>   v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
>   drm: rcar-du: Map memory through the VSP device
> 
> Ulrich Hecht (2):
>   v4l: vsp1: Provide display list and VB2 queue with FCP device
>   arm64: dts: r8a7796: Connect FCP devices to IPMMU

Hi Ulrich,

I am wondering what the status of this work is.

Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS

[Simon Horman]

On Wed, Aug 30, 2017 at 10:08:24AM +0200, Niklas Söderlund wrote:
> Hi Simon,
> 
> On 2017-08-30 09:36:37 +0200, Simon Horman wrote:
> > On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> > > In order to test Virtual Channels use VC1 for CVBS input from the
> > > adv748x.
> > > 
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> > >  arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
> > > b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > index 7b67efcb1d22090a..8047fe1df065d63b 100644
> > > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > @@ -41,7 +41,7 @@
> > >   };
> > >  
> > >   chosen {
> > > - bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> > > + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp 
> > > adv748x.txbvc=1";
> > >   stdout-path = "serial0:115200n8";
> > >   };
> > 
> > Hi Niklas,
> > 
> > I'm somewhat surprised to see what appears to be a new module parameter.
> > I'm not going to reject this but did you give consideration to doing this
> > another way?
> 
> This is my fault when sending this series out it should be marked as RFC 
> as it's stated in the cover-letter. This new module parameter is not 
> intended to be unstreamed, not even the driver parts. It's only usage is 
> to be able to easy test the multiplexed media pad using the onboard 
> Salvator-X components.
> 
> > 
> > In any case I have marked this as "Deferred" pending acceptance of the
> > driver change. If you think it can go in now then I'm open to discussion.
> 
> You can mark it as rejected and forget about it :-)

Thanks for the clarification, I marked it as RFC :)

Re: DRM Format Modifiers in v4l2

[Brian Starkey]

On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:

On 30/08/17 09:50, Daniel Vetter wrote:

On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:

The fact is, adding special formats for each combination is
unmanageable - we're talking dozens in the case of our hardware.


Hm right, we can just remap the special combos to the drm-fourcc +
modifier style. Bonus point if v4l does that in the core so not everyone
has to reinvent that wheel :-)


Probably not something we'll do: there are I believe only two drivers that
are affected (exynos & mediatek), so they can do that in their driver.

Question: how many modifiers will typically apply to a format? I ask
because I realized that V4L2 could use VIDIOC_ENUMFMT to make the link
between a fourcc and modifiers:

https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enum-fmt.html

The __u32 reserved[4] array can be used to provide a bitmask to modifier
indices (for the integer menu control). It's similar to what drm does,
except instead of modifiers mapping to fourccs it is the other way around.

This would avoid having to change the modifiers control whenever a new
format is set and it makes it easy to enumerate all combinations.

But this only works if the total number of modifiers used by a single driver
is expected to remain small (let's say no more than 64).


In our current (yet to be submitted) description, we've got around a
dozen modifiers for any one format to describe our compression
variants. We have a lot of on/off toggles which leads to combinatorial
expansion, so it can grow pretty quickly (though I am trying to limit
the valid combinations as much as possible).

How about if the mask fills up then VIDIOC_ENUM_FMT can return another
fmtdsc with the same FourCC and different modifier bitmask, where the
second one's modifier bitmask is for the next "N" modifiers?

-Brian


Regards,

Hans

Re: [RFC 0/2] BCM283x Camera Receiver driver

[Dave Stevenson]

Hi Hans.

On 28 August 2017 at 15:15, Hans Verkuil  wrote:
> Hi Dave,
>
> What is the status of this work? I ask because I tried to use this driver
> plus my tc358743 on my rpi-2b without any luck. Specifically the tc358843
> isn't able to read from the i2c bus.

I was on other things until last week, but will try to get a V2 sorted
either this week or early next.
The world moved on slightly too, so there are a few more updates
around fwnode stuff that I ought to adopt.

> This is probably a bug in my dts, if you have a tree somewhere containing
> a working dts for this, then that would be very helpful.

Almost certainly just pin ctrl on the I2C bus. The default for i2c0 is
normally to GPIOs 0&1 as that is exposed on the 40 pin header
(physical pins 27&28). The camera is on GPIOs 28&29 (alt0) for the
majority of Pi models (not the Pi3, or the early model B).

I generally do my config via the DT overlays used in the Pi specific
kernels, but that isn't so directly relevant to mainline.
My 4.9 based WIP project that I'm using on a Pi2 is at
https://github.com/6by9/linux/commits/unicam_wip. Mods to:
- arch/arm/boot/dts/bcm283x.dtsi add the CSI nodes
- arch/arm/boot/dts/overlays/tc358743-overlay.dts adds the relevant
config for TC358743
- /arch/arm/boot/dts/overlays/i2c0-bcm2708-overlay.dts is used with
the pins_28_29 parameter to select 28&29 (that needs updating as it
now uses the bcm2835-i2c driver, not bcm2708-i2c)
Sorry it's piece-meal, but that should give you the bits required.

I hope that helps.
  Dave

> Regards,
>
> Hans
>
> On 14/06/17 17:15, Dave Stevenson wrote:
>> Hi All.
>>
>> This is adding a V4L2 subdevice driver for the CSI2/CCP2 camera
>> receiver peripheral on BCM283x, as used on Raspberry Pi.
>>
>> v4l2-compliance results depend on the sensor subdevice this is
>> connected to. It passes the basic tests cleanly with TC358743,
>> but objects with OV5647
>> fail: v4l2-test-controls.cpp(574): g_ext_ctrls does not support count == 0
>> Neither OV5647 nor Unicam support any controls.
>>
>> I must admit to not having got OV5647 to stream with the current driver
>> register settings. It works with a set of register settings for VGA RAW10.
>> I also have a couple of patches pending for OV5647, but would like to
>> understand the issues better before sending them out.
>>
>> Two queries I do have in V4L2-land:
>> - When s_dv_timings or s_std is called, is the format meant to
>>   be updated automatically? Even if we're already streaming?
>>   Some existing drivers seem to, but others don't.
>> - With s_fmt, is sizeimage settable by the application in the same
>>   way as bytesperline? yavta allows you to specify it on the command
>>   line, whilst v4l2-ctl doesn't. Some of the other parts of the Pi
>>   firmware have a requirement that the buffer is a multiple of 16 lines
>>   high, which can be matched by V4L2 if we can over-allocate the
>>   buffers by the app specifying sizeimage. But if I allow that,
>>   then I get a v4l2-compliance failure as the size doesn't get
>>   reset when switching from RGB3 to UYVY as it takes the request as
>>   a request to over-allocate.
>>
>> Apologies if I've messed up in sending these patches - so many ways
>> to do something.
>>
>> Thanks in advance.
>>   Dave
>>
>> Dave Stevenson (2):
>>   [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver
>>   [media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface
>>
>>  .../devicetree/bindings/media/bcm2835-unicam.txt   |   76 +
>>  drivers/media/platform/Kconfig |1 +
>>  drivers/media/platform/Makefile|2 +
>>  drivers/media/platform/bcm2835/Kconfig |   14 +
>>  drivers/media/platform/bcm2835/Makefile|3 +
>>  drivers/media/platform/bcm2835/bcm2835-unicam.c| 2100 
>> 
>>  drivers/media/platform/bcm2835/vc4-regs-unicam.h   |  257 +++
>>  7 files changed, 2453 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>  create mode 100644 drivers/media/platform/bcm2835/Kconfig
>>  create mode 100644 drivers/media/platform/bcm2835/Makefile
>>  create mode 100644 drivers/media/platform/bcm2835/bcm2835-unicam.c
>>  create mode 100644 drivers/media/platform/bcm2835/vc4-regs-unicam.h
>>
>

Re: DRM Format Modifiers in v4l2

[Hans Verkuil]

On 30/08/17 11:36, Brian Starkey wrote:
> On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
>> On 30/08/17 09:50, Daniel Vetter wrote:
>>> On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
 The fact is, adding special formats for each combination is
 unmanageable - we're talking dozens in the case of our hardware.
>>>
>>> Hm right, we can just remap the special combos to the drm-fourcc +
>>> modifier style. Bonus point if v4l does that in the core so not everyone
>>> has to reinvent that wheel :-)
>>
>> Probably not something we'll do: there are I believe only two drivers that
>> are affected (exynos & mediatek), so they can do that in their driver.
>>
>> Question: how many modifiers will typically apply to a format? I ask
>> because I realized that V4L2 could use VIDIOC_ENUMFMT to make the link
>> between a fourcc and modifiers:
>>
>> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enum-fmt.html
>>
>> The __u32 reserved[4] array can be used to provide a bitmask to modifier
>> indices (for the integer menu control). It's similar to what drm does,
>> except instead of modifiers mapping to fourccs it is the other way around.
>>
>> This would avoid having to change the modifiers control whenever a new
>> format is set and it makes it easy to enumerate all combinations.
>>
>> But this only works if the total number of modifiers used by a single driver
>> is expected to remain small (let's say no more than 64).
> 
> In our current (yet to be submitted) description, we've got around a
> dozen modifiers for any one format to describe our compression
> variants. We have a lot of on/off toggles which leads to combinatorial
> expansion, so it can grow pretty quickly (though I am trying to limit
> the valid combinations as much as possible).
> 
> How about if the mask fills up then VIDIOC_ENUM_FMT can return another
> fmtdsc with the same FourCC and different modifier bitmask, where the
> second one's modifier bitmask is for the next "N" modifiers?

I was thinking along similar lines, but it could cause some problems with
the ABI since applications currently assume that no fourcc will appear
twice when enumerating formats. Admittedly, we never explicitly said in
the spec that that can't happen, but it is kind of expected.

There are ways around that, but if possible I'd like to avoid that.

In theory there are up to 128 bits available but I can't help thinking
that if you create more than, say, 64 modifiers for a HW platform you
have a big mess anyway.

If I am wrong, then I need to know because then I can prepare for it
(or whoever is going to actually implement this...)

If the number of modifiers is expected to be limited then making 64 bits
available would be good enough, at least for now.

BTW, is a modifier always optional? I.e. for all fourccs, is the unmodified
format always available? Or are there fourccs that require the use of a
modifier?

Regards,

Hans

[PATCH] [media] v4l: vsp1: Use generic node name

[Geert Uytterhoeven]

Use the preferred generic node name in the example.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt 
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
index 9b695bcbf2190bdd..16427017cb45561e 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -22,7 +22,7 @@ Optional properties:
 
 Example: R8A7790 (R-Car H2) VSP1-S node
 
-   vsp1@fe928000 {
+   vsp@fe928000 {
compatible = "renesas,vsp1";
reg = <0 0xfe928000 0 0x8000>;
interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.7.4

Re: [PATCH] [media] v4l: vsp1: Use generic node name

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Wednesday, 30 August 2017 12:57:31 EEST Geert Uytterhoeven wrote:
> Use the preferred generic node name in the example.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> b/Documentation/devicetree/bindings/media/renesas,vsp1.txt index
> 9b695bcbf2190bdd..16427017cb45561e 100644
> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> @@ -22,7 +22,7 @@ Optional properties:
> 
>  Example: R8A7790 (R-Car H2) VSP1-S node
> 
> - vsp1@fe928000 {
> + vsp@fe928000 {

vsp1 isn't an instance name but an IP core name.

>   compatible = "renesas,vsp1";
>   reg = <0 0xfe928000 0 0x8000>;
>   interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;


-- 
Regards,

Laurent Pinchart

Re: [PATCH] [media] v4l: vsp1: Use generic node name

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Aug 30, 2017 at 12:10 PM, Laurent Pinchart
 wrote:
> On Wednesday, 30 August 2017 12:57:31 EEST Geert Uytterhoeven wrote:
>> Use the preferred generic node name in the example.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>>  Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
>> b/Documentation/devicetree/bindings/media/renesas,vsp1.txt index
>> 9b695bcbf2190bdd..16427017cb45561e 100644
>> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
>> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
>> @@ -22,7 +22,7 @@ Optional properties:
>>
>>  Example: R8A7790 (R-Car H2) VSP1-S node
>>
>> - vsp1@fe928000 {
>> + vsp@fe928000 {
>
> vsp1 isn't an instance name but an IP core name.

I know (cfr. "preferred generic node name", not "numerical suffix").

For the actual DTSes on R-Car Gen3, we settled on the more generic "vsp"
for the vsp2 node names.

R-Car Gen2 DTSes still use "vsp1".

>>   compatible = "renesas,vsp1";
>>   reg = <0 0xfe928000 0 0x8000>;
>>   interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: DRM Format Modifiers in v4l2

[Brian Starkey]

On Wed, Aug 30, 2017 at 11:53:58AM +0200, Hans Verkuil wrote:

On 30/08/17 11:36, Brian Starkey wrote:

On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:

On 30/08/17 09:50, Daniel Vetter wrote:

On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:

The fact is, adding special formats for each combination is
unmanageable - we're talking dozens in the case of our hardware.


Hm right, we can just remap the special combos to the drm-fourcc +
modifier style. Bonus point if v4l does that in the core so not everyone
has to reinvent that wheel :-)


Probably not something we'll do: there are I believe only two drivers that
are affected (exynos & mediatek), so they can do that in their driver.

Question: how many modifiers will typically apply to a format? I ask
because I realized that V4L2 could use VIDIOC_ENUMFMT to make the link
between a fourcc and modifiers:

https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enum-fmt.html

The __u32 reserved[4] array can be used to provide a bitmask to modifier
indices (for the integer menu control). It's similar to what drm does,
except instead of modifiers mapping to fourccs it is the other way around.

This would avoid having to change the modifiers control whenever a new
format is set and it makes it easy to enumerate all combinations.

But this only works if the total number of modifiers used by a single driver
is expected to remain small (let's say no more than 64).


In our current (yet to be submitted) description, we've got around a
dozen modifiers for any one format to describe our compression
variants. We have a lot of on/off toggles which leads to combinatorial
expansion, so it can grow pretty quickly (though I am trying to limit
the valid combinations as much as possible).

How about if the mask fills up then VIDIOC_ENUM_FMT can return another
fmtdsc with the same FourCC and different modifier bitmask, where the
second one's modifier bitmask is for the next "N" modifiers?


I was thinking along similar lines, but it could cause some problems with
the ABI since applications currently assume that no fourcc will appear
twice when enumerating formats. Admittedly, we never explicitly said in
the spec that that can't happen, but it is kind of expected.

There are ways around that, but if possible I'd like to avoid that.

In theory there are up to 128 bits available but I can't help thinking
that if you create more than, say, 64 modifiers for a HW platform you
have a big mess anyway.

If I am wrong, then I need to know because then I can prepare for it
(or whoever is going to actually implement this...)


You're probably right, but I can't speak for everyone. From the
current state of drm_fourcc.h it looks like 64 would be plenty (there
aren't anywhere near 64 modifiers even defined right now). Adding in
the Arm compression formats will expand it a lot, but still not to 64
(yet).



If the number of modifiers is expected to be limited then making 64 bits
available would be good enough, at least for now.

BTW, is a modifier always optional? I.e. for all fourccs, is the unmodified
format always available? Or are there fourccs that require the use of a
modifier?


We do actually have one or two formats which are only supported with a
modifier (on our HW).

-Brian



Regards,

Hans

Re: [RFC 0/2] BCM283x Camera Receiver driver

[Hans Verkuil]

On 30/08/17 11:40, Dave Stevenson wrote:
> Hi Hans.
> 
> On 28 August 2017 at 15:15, Hans Verkuil  wrote:
>> Hi Dave,
>>
>> What is the status of this work? I ask because I tried to use this driver
>> plus my tc358743 on my rpi-2b without any luck. Specifically the tc358843
>> isn't able to read from the i2c bus.
> 
> I was on other things until last week, but will try to get a V2 sorted
> either this week or early next.
> The world moved on slightly too, so there are a few more updates
> around fwnode stuff that I ought to adopt.
> 
>> This is probably a bug in my dts, if you have a tree somewhere containing
>> a working dts for this, then that would be very helpful.
> 
> Almost certainly just pin ctrl on the I2C bus. The default for i2c0 is
> normally to GPIOs 0&1 as that is exposed on the 40 pin header
> (physical pins 27&28). The camera is on GPIOs 28&29 (alt0) for the
> majority of Pi models (not the Pi3, or the early model B).

Yep, that was the culprit!

I now see the tc, but streaming doesn't work yet. I'm not getting any
interrupts in the unicam driver.

BTW, when s_dv_timings is called, then you need to update the v4l2_format
as well to the new width and height. I noticed that that didn't happen.

Anyway, this is good enough for me for now since I want to add CEC support
to the tc driver, and I do not need streaming for that...

Regards,

Hans

Re: [RFC 0/2] BCM283x Camera Receiver driver

[Stefan Wahren]

Hi Hans,

Am 30.08.2017 um 12:45 schrieb Hans Verkuil:

On 30/08/17 11:40, Dave Stevenson wrote:

Hi Hans.

On 28 August 2017 at 15:15, Hans Verkuil  wrote:

Hi Dave,

What is the status of this work? I ask because I tried to use this driver
plus my tc358743 on my rpi-2b without any luck. Specifically the tc358843
isn't able to read from the i2c bus.

I was on other things until last week, but will try to get a V2 sorted
either this week or early next.
The world moved on slightly too, so there are a few more updates
around fwnode stuff that I ought to adopt.


This is probably a bug in my dts, if you have a tree somewhere containing
a working dts for this, then that would be very helpful.

Almost certainly just pin ctrl on the I2C bus. The default for i2c0 is
normally to GPIOs 0&1 as that is exposed on the 40 pin header
(physical pins 27&28). The camera is on GPIOs 28&29 (alt0) for the
majority of Pi models (not the Pi3, or the early model B).

Yep, that was the culprit!

I now see the tc, but streaming doesn't work yet. I'm not getting any
interrupts in the unicam driver.

BTW, when s_dv_timings is called, then you need to update the v4l2_format
as well to the new width and height. I noticed that that didn't happen.

Anyway, this is good enough for me for now since I want to add CEC support
to the tc driver, and I do not need streaming for that...


i'm not sure this is related, but there is an issue in VCHIQ with 
HIGHMEM and VMSPLIT on RPi 2 [1].


Maybe the mentioned kmap fix could be helpful.

Btw: The VCHIQ driver in Dave's repo is a bit outdated.

[1] - https://github.com/raspberrypi/linux/issues/1996



Regards,

Hans

___
linux-rpi-kernel mailing list
linux-rpi-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

Re: [RFC 0/2] BCM283x Camera Receiver driver

[Hans Verkuil]

On 30/08/17 13:04, Dave Stevenson wrote:
> On 30 August 2017 at 11:45, Hans Verkuil  wrote:
>> On 30/08/17 11:40, Dave Stevenson wrote:
>>> Hi Hans.
>>>
>>> On 28 August 2017 at 15:15, Hans Verkuil  wrote:
 Hi Dave,

 What is the status of this work? I ask because I tried to use this driver
 plus my tc358743 on my rpi-2b without any luck. Specifically the tc358843
 isn't able to read from the i2c bus.
>>>
>>> I was on other things until last week, but will try to get a V2 sorted
>>> either this week or early next.
>>> The world moved on slightly too, so there are a few more updates
>>> around fwnode stuff that I ought to adopt.
>>>
 This is probably a bug in my dts, if you have a tree somewhere containing
 a working dts for this, then that would be very helpful.
>>>
>>> Almost certainly just pin ctrl on the I2C bus. The default for i2c0 is
>>> normally to GPIOs 0&1 as that is exposed on the 40 pin header
>>> (physical pins 27&28). The camera is on GPIOs 28&29 (alt0) for the
>>> majority of Pi models (not the Pi3, or the early model B).
>>
>> Yep, that was the culprit!
> 
> Great. I like easy ones :-)
> 
>> I now see the tc, but streaming doesn't work yet. I'm not getting any
>> interrupts in the unicam driver.
> 
> What resolution were you streaming at? There are a couple of things
> that come to mind and I don't have solutions for yet.

I tried 720p60 (both RGB and YUV) and 640x480p60 (aka VGA).

I gather that the last probably won't work, but 720p60 should?

If time permits I'll try to look into this a bit more later today. First CEC
though :-)

Regards,

Hans

> Firstly the TC358743 driver assumes that all 4 CSI lanes are
> available, whilst the Pi only has 2 lanes exposed. IIRC 1080P30 RGB
> just trickles over into wanting 3 lanes with the default link
> frequencies and you indeed don't get anything if one or more lane is
> physically not connected.
> Secondly was the FIFOCTL register set via state->pdata.fifo_level that
> we discussed before. The default is 16, which is too small for some of
> the smaller resolutions. 300 seems reasonable. You do get frames in
> that situation, but they're generally corrupt.
> I'm intending to try and make the TC358743 more flexible than just
> accepting >720P, and if I can support multiple link frequencies then
> so much the better as 1080P50 UYVY should be just possible on 2 lane,
> however the lower resolutions are unlikely to work due to FIFO
> underflow.
> 
>> BTW, when s_dv_timings is called, then you need to update the v4l2_format
>> as well to the new width and height. I noticed that that didn't happen.
> 
> Yes, that came up in the previous discussions and is already fixed.
> 
>> Anyway, this is good enough for me for now since I want to add CEC support
>> to the tc driver, and I do not need streaming for that...
> 
> That sounds fun.
>   Dave
> 

Re: [RFC 0/2] BCM283x Camera Receiver driver

[Dave Stevenson]

On 30 August 2017 at 11:45, Hans Verkuil  wrote:
> On 30/08/17 11:40, Dave Stevenson wrote:
>> Hi Hans.
>>
>> On 28 August 2017 at 15:15, Hans Verkuil  wrote:
>>> Hi Dave,
>>>
>>> What is the status of this work? I ask because I tried to use this driver
>>> plus my tc358743 on my rpi-2b without any luck. Specifically the tc358843
>>> isn't able to read from the i2c bus.
>>
>> I was on other things until last week, but will try to get a V2 sorted
>> either this week or early next.
>> The world moved on slightly too, so there are a few more updates
>> around fwnode stuff that I ought to adopt.
>>
>>> This is probably a bug in my dts, if you have a tree somewhere containing
>>> a working dts for this, then that would be very helpful.
>>
>> Almost certainly just pin ctrl on the I2C bus. The default for i2c0 is
>> normally to GPIOs 0&1 as that is exposed on the 40 pin header
>> (physical pins 27&28). The camera is on GPIOs 28&29 (alt0) for the
>> majority of Pi models (not the Pi3, or the early model B).
>
> Yep, that was the culprit!

Great. I like easy ones :-)

> I now see the tc, but streaming doesn't work yet. I'm not getting any
> interrupts in the unicam driver.

What resolution were you streaming at? There are a couple of things
that come to mind and I don't have solutions for yet.
Firstly the TC358743 driver assumes that all 4 CSI lanes are
available, whilst the Pi only has 2 lanes exposed. IIRC 1080P30 RGB
just trickles over into wanting 3 lanes with the default link
frequencies and you indeed don't get anything if one or more lane is
physically not connected.
Secondly was the FIFOCTL register set via state->pdata.fifo_level that
we discussed before. The default is 16, which is too small for some of
the smaller resolutions. 300 seems reasonable. You do get frames in
that situation, but they're generally corrupt.
I'm intending to try and make the TC358743 more flexible than just
accepting >720P, and if I can support multiple link frequencies then
so much the better as 1080P50 UYVY should be just possible on 2 lane,
however the lower resolutions are unlikely to work due to FIFO
underflow.

> BTW, when s_dv_timings is called, then you need to update the v4l2_format
> as well to the new width and height. I noticed that that didn't happen.

Yes, that came up in the previous discussions and is already fixed.

> Anyway, this is good enough for me for now since I want to add CEC support
> to the tc driver, and I do not need streaming for that...

That sounds fun.
  Dave

[PATCH v6 3/5] docs-rst: v4l: Include Qualcomm CAMSS in documentation build

[Sakari Ailus]

Qualcomm CAMSS was left out from documentation build. Fix this.

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
---
 Documentation/media/v4l-drivers/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 10f2ce42ece2..5c202e23616b 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -50,6 +50,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
philips
pvrusb2
pxa_camera
+   qcom_camss
radiotrack
rcar-fdp1
saa7134
-- 
2.11.0

[PATCH v6 0/5] Unified fwnode endpoint parser

[Sakari Ailus]

Hi folks,

We have a large influx of new, unmerged, drivers that are now parsing
fwnode endpoints and each one of them is doing this a little bit
differently. The needs are still exactly the same for the graph data
structure is device independent. This is still a non-trivial task and the
majority of the driver implementations are buggy, just buggy in different
ways.

Facilitate parsing endpoints by adding a convenience function for parsing
the endpoints, and make the omap3isp and rcar-vin drivers use them as an
example.

since v5:

- Use v4l2_async_ prefix for static functions as well (4th patch)

- Use memcpy() to copy array rather than a loop

- Document that the v4l2_async_subdev pointer in driver specific struct
  must be the first member

- Improve documentation of the added functions (4th and 5th
  patches)

- Arguments

- More thorough explation of the purpose, usage and object
  lifetime

- Added acks

since v4:

- Prepend the set with three documentation fixes.

- The driver's async struct must begin with struct v4l2_async_subdev. Fix this
  for omap3isp and document it.

- Improve documentation for new functions.

- Don't use devm_ family of functions for allocating memory. Introduce
  v4l2_async_notifier_release() to release memory resources.

- Rework both v4l2_async_notifier_fwnode_parse_endpoints() and
  v4l2_async_notifier_fwnode_parse_endpoint() and the local functions they
  call. This should make the code cleaner. Despite the name, for linking
  and typical usage reasons the functions remain in v4l2-fwnode.c.

- Convert rcar-vin to use v4l2_async_notifier_fwnode_parse_endpoint().

- Use kvmalloc() for allocating the notifier's subdevs array.

- max_subdevs argument for notifier_realloc is now the total maximum
  number of subdevs, not the number of available subdevs.

- Use fwnode_device_is_available() to make sure the device actually
  exists.

- Move the note telling v4l2_async_notifier_fwnode_parse_endpoints()
  should not be used by new drivers to the last patch adding
  v4l2_async_notifier_fwnode_parse_endpoint().

since v3:

- Rebase on current mediatree master.

since v2:

- Rebase on CCP2 support patches.

- Prepend a patch cleaning up omap3isp driver a little.

since v1:

- The first patch has been merged (it was a bugfix).

- In anticipation that the parsing can take place over several iterations,
  take the existing number of async sub-devices into account when
  re-allocating an array of async sub-devices.

- Rework the first patch to better anticipate parsing single endpoint at a
  time by a driver.

- Add a second patch that adds a function for parsing endpoints one at a
  time based on port and endpoint numbers.

Sakari Ailus (5):
  v4l: fwnode: Move KernelDoc documentation to the header
  v4l: async: Add V4L2 async documentation to the documentation build
  docs-rst: v4l: Include Qualcomm CAMSS in documentation build
  v4l: fwnode: Support generic parsing of graph endpoints in a device
  v4l: fwnode: Support generic parsing of graph endpoints in a single
port

 Documentation/media/kapi/v4l2-async.rst |   3 +
 Documentation/media/kapi/v4l2-core.rst  |   1 +
 Documentation/media/v4l-drivers/index.rst   |   1 +
 drivers/media/platform/omap3isp/isp.c   | 115 -
 drivers/media/platform/omap3isp/isp.h   |   5 +-
 drivers/media/platform/rcar-vin/rcar-core.c | 111 
 drivers/media/platform/rcar-vin/rcar-dma.c  |  10 +-
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  14 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  |   4 +-
 drivers/media/v4l2-core/v4l2-async.c|  16 ++
 drivers/media/v4l2-core/v4l2-fwnode.c   | 253 +++-
 include/media/v4l2-async.h  |  24 ++-
 include/media/v4l2-fwnode.h | 178 ++-
 13 files changed, 481 insertions(+), 254 deletions(-)
 create mode 100644 Documentation/media/kapi/v4l2-async.rst

-- 
2.11.0

[PATCH v6 4/5] v4l: fwnode: Support generic parsing of graph endpoints in a device

[Sakari Ailus]

The current practice is that drivers iterate over their endpoints and
parse each endpoint separately. This is very similar in a number of
drivers, implement a generic function for the job. Driver specific matters
can be taken into account in the driver specific callback.

Convert the omap3isp as an example.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/isp.c | 115 ++---
 drivers/media/platform/omap3isp/isp.h |   5 +-
 drivers/media/v4l2-core/v4l2-async.c  |  16 +
 drivers/media/v4l2-core/v4l2-fwnode.c | 131 ++
 include/media/v4l2-async.h|  24 ++-
 include/media/v4l2-fwnode.h   |  48 +
 6 files changed, 254 insertions(+), 85 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 1a428fe9f070..a546cf774d40 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2001,6 +2001,7 @@ static int isp_remove(struct platform_device *pdev)
__omap3isp_put(isp, false);
 
media_entity_enum_cleanup(&isp->crashed);
+   v4l2_async_notifier_release(&isp->notifier);
 
return 0;
 }
@@ -2011,44 +2012,41 @@ enum isp_of_phy {
ISP_OF_PHY_CSIPHY2,
 };
 
-static int isp_fwnode_parse(struct device *dev, struct fwnode_handle *fwnode,
-   struct isp_async_subdev *isd)
+static int isp_fwnode_parse(struct device *dev,
+   struct v4l2_fwnode_endpoint *vep,
+   struct v4l2_async_subdev *asd)
 {
+   struct isp_async_subdev *isd =
+   container_of(asd, struct isp_async_subdev, asd);
struct isp_bus_cfg *buscfg = &isd->bus;
-   struct v4l2_fwnode_endpoint vep;
-   unsigned int i;
-   int ret;
bool csi1 = false;
-
-   ret = v4l2_fwnode_endpoint_parse(fwnode, &vep);
-   if (ret)
-   return ret;
+   unsigned int i;
 
dev_dbg(dev, "parsing endpoint %pOF, interface %u\n",
-   to_of_node(fwnode), vep.base.port);
+   to_of_node(vep->base.local_fwnode), vep->base.port);
 
-   switch (vep.base.port) {
+   switch (vep->base.port) {
case ISP_OF_PHY_PARALLEL:
buscfg->interface = ISP_INTERFACE_PARALLEL;
buscfg->bus.parallel.data_lane_shift =
-   vep.bus.parallel.data_shift;
+   vep->bus.parallel.data_shift;
buscfg->bus.parallel.clk_pol =
-   !!(vep.bus.parallel.flags
+   !!(vep->bus.parallel.flags
   & V4L2_MBUS_PCLK_SAMPLE_FALLING);
buscfg->bus.parallel.hs_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW);
+   !!(vep->bus.parallel.flags & 
V4L2_MBUS_VSYNC_ACTIVE_LOW);
buscfg->bus.parallel.vs_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW);
+   !!(vep->bus.parallel.flags & 
V4L2_MBUS_HSYNC_ACTIVE_LOW);
buscfg->bus.parallel.fld_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
+   !!(vep->bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
buscfg->bus.parallel.data_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
-   buscfg->bus.parallel.bt656 = vep.bus_type == V4L2_MBUS_BT656;
+   !!(vep->bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
+   buscfg->bus.parallel.bt656 = vep->bus_type == V4L2_MBUS_BT656;
break;
 
case ISP_OF_PHY_CSIPHY1:
case ISP_OF_PHY_CSIPHY2:
-   switch (vep.bus_type) {
+   switch (vep->bus_type) {
case V4L2_MBUS_CCP2:
case V4L2_MBUS_CSI1:
dev_dbg(dev, "CSI-1/CCP-2 configuration\n");
@@ -2060,11 +2058,11 @@ static int isp_fwnode_parse(struct device *dev, struct 
fwnode_handle *fwnode,
break;
default:
dev_err(dev, "unsupported bus type %u\n",
-   vep.bus_type);
+   vep->bus_type);
return -EINVAL;
}
 
-   switch (vep.base.port) {
+   switch (vep->base.port) {
case ISP_OF_PHY_CSIPHY1:
if (csi1)
buscfg->interface = ISP_INTERFACE_CCP2B_PHY1;
@@ -2080,47 +2078,47 @@ static int isp_fwnode_parse(struct device *dev, struct 
fwnode_handle *fwnode,
}
if (csi1) {
buscfg->bus.ccp2.lanecfg.clk.pos =
-   vep.bus.mipi_csi1.clock_lane;
+   vep->bus.mipi_csi1.clock_lane;
buscf

[PATCH v6 2/5] v4l: async: Add V4L2 async documentation to the documentation build

[Sakari Ailus]

The V4L2 async wasn't part of the documentation build. Fix this.

Signed-off-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
---
 Documentation/media/kapi/v4l2-async.rst | 3 +++
 Documentation/media/kapi/v4l2-core.rst  | 1 +
 2 files changed, 4 insertions(+)
 create mode 100644 Documentation/media/kapi/v4l2-async.rst

diff --git a/Documentation/media/kapi/v4l2-async.rst 
b/Documentation/media/kapi/v4l2-async.rst
new file mode 100644
index ..523ff9eb09a0
--- /dev/null
+++ b/Documentation/media/kapi/v4l2-async.rst
@@ -0,0 +1,3 @@
+V4L2 async kAPI
+^^^
+.. kernel-doc:: include/media/v4l2-async.h
diff --git a/Documentation/media/kapi/v4l2-core.rst 
b/Documentation/media/kapi/v4l2-core.rst
index c7434f38fd9c..5cf292037a48 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -19,6 +19,7 @@ Video4Linux devices
 v4l2-mc
 v4l2-mediabus
 v4l2-mem2mem
+v4l2-async
 v4l2-fwnode
 v4l2-rect
 v4l2-tuner
-- 
2.11.0

[PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph endpoints in a single port

[Sakari Ailus]

This is the preferred way to parse the endpoints.

Comment rcar-vin as an example.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 111 
 drivers/media/platform/rcar-vin/rcar-dma.c  |  10 +--
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  14 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |   4 +-
 drivers/media/v4l2-core/v4l2-fwnode.c   |  47 
 include/media/v4l2-fwnode.h |  49 
 6 files changed, 142 insertions(+), 93 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 142de447..4378806be1d4 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include "rcar-vin.h"
@@ -77,14 +78,14 @@ static int rvin_digital_notify_complete(struct 
v4l2_async_notifier *notifier)
int ret;
 
/* Verify subdevices mbus format */
-   if (!rvin_mbus_supported(&vin->digital)) {
+   if (!rvin_mbus_supported(vin->digital)) {
vin_err(vin, "Unsupported media bus format for %s\n",
-   vin->digital.subdev->name);
+   vin->digital->subdev->name);
return -EINVAL;
}
 
vin_dbg(vin, "Found media bus format for %s: %d\n",
-   vin->digital.subdev->name, vin->digital.code);
+   vin->digital->subdev->name, vin->digital->code);
 
ret = v4l2_device_register_subdev_nodes(&vin->v4l2_dev);
if (ret < 0) {
@@ -103,7 +104,7 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
 
vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
rvin_v4l2_remove(vin);
-   vin->digital.subdev = NULL;
+   vin->digital->subdev = NULL;
 }
 
 static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
@@ -120,117 +121,67 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
if (ret < 0)
return ret;
-   vin->digital.source_pad = ret;
+   vin->digital->source_pad = ret;
 
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
-   vin->digital.sink_pad = ret < 0 ? 0 : ret;
+   vin->digital->sink_pad = ret < 0 ? 0 : ret;
 
-   vin->digital.subdev = subdev;
+   vin->digital->subdev = subdev;
 
vin_dbg(vin, "bound subdev %s source pad: %u sink pad: %u\n",
-   subdev->name, vin->digital.source_pad,
-   vin->digital.sink_pad);
+   subdev->name, vin->digital->source_pad,
+   vin->digital->sink_pad);
 
return 0;
 }
 
-static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,
-   struct device_node *ep,
-   struct v4l2_mbus_config *mbus_cfg)
+static int rvin_digital_parse_v4l2(struct device *dev,
+  struct v4l2_fwnode_endpoint *vep,
+  struct v4l2_async_subdev *asd)
 {
-   struct v4l2_fwnode_endpoint v4l2_ep;
-   int ret;
-
-   ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &v4l2_ep);
-   if (ret) {
-   vin_err(vin, "Could not parse v4l2 endpoint\n");
-   return -EINVAL;
-   }
+   struct rvin_dev *vin = dev_get_drvdata(dev);
+   struct rvin_graph_entity *rvge =
+   container_of(asd, struct rvin_graph_entity, asd);
 
-   mbus_cfg->type = v4l2_ep.bus_type;
+   rvge->mbus_cfg.type = vep->bus_type;
 
-   switch (mbus_cfg->type) {
+   switch (rvge->mbus_cfg.type) {
case V4L2_MBUS_PARALLEL:
vin_dbg(vin, "Found PARALLEL media bus\n");
-   mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
+   rvge->mbus_cfg.flags = vep->bus.parallel.flags;
break;
case V4L2_MBUS_BT656:
vin_dbg(vin, "Found BT656 media bus\n");
-   mbus_cfg->flags = 0;
+   rvge->mbus_cfg.flags = 0;
break;
default:
vin_err(vin, "Unknown media bus type\n");
return -EINVAL;
}
 
-   return 0;
-}
-
-static int rvin_digital_graph_parse(struct rvin_dev *vin)
-{
-   struct device_node *ep, *np;
-   int ret;
-
-   vin->digital.asd.match.fwnode.fwnode = NULL;
-   vin->digital.subdev = NULL;
-
-   /*
-* Port 0 id 0 is local digital input, try to get it.
-* Not all instances can or will have this, that is OK
-*/
-   ep = of_graph_get_endpoint_by_regs(vin->dev->of_node, 0, 0);
-   if (!ep)
-   return 0;
-
-   np = of_graph_get_remote_port_parent(ep);
-   if (!np) {
-   vin_err(vin, "No remote parent for digital input\n");
-   of_node_put(ep);
-   

[PATCH v6 1/5] v4l: fwnode: Move KernelDoc documentation to the header

[Sakari Ailus]

In V4L2 the practice is to have the KernelDoc documentation in the header
and not in .c source code files. This consequientally makes the V4L2
fwnode function documentation part of the Media documentation build.

Also correct the link related function and argument naming in
documentation.

Signed-off-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 75 
 include/media/v4l2-fwnode.h   | 81 ++-
 2 files changed, 80 insertions(+), 76 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 40b2fbfe8865..706f9e7b90f1 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -181,25 +181,6 @@ v4l2_fwnode_endpoint_parse_csi1_bus(struct fwnode_handle 
*fwnode,
vep->bus_type = V4L2_MBUS_CSI1;
 }
 
-/**
- * v4l2_fwnode_endpoint_parse() - parse all fwnode node properties
- * @fwnode: pointer to the endpoint's fwnode handle
- * @vep: pointer to the V4L2 fwnode data structure
- *
- * All properties are optional. If none are found, we don't set any flags. This
- * means the port has a static configuration and no properties have to be
- * specified explicitly. If any properties that identify the bus as parallel
- * are found and slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if
- * we recognise the bus as serial CSI-2 and clock-noncontinuous isn't set, we
- * set the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag. The caller should hold a
- * reference to @fwnode.
- *
- * NOTE: This function does not parse properties the size of which is variable
- * without a low fixed limit. Please use v4l2_fwnode_endpoint_alloc_parse() in
- * new drivers instead.
- *
- * Return: 0 on success or a negative error code on failure.
- */
 int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwnode,
   struct v4l2_fwnode_endpoint *vep)
 {
@@ -239,14 +220,6 @@ int v4l2_fwnode_endpoint_parse(struct fwnode_handle 
*fwnode,
 }
 EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_parse);
 
-/*
- * v4l2_fwnode_endpoint_free() - free the V4L2 fwnode acquired by
- * v4l2_fwnode_endpoint_alloc_parse()
- * @vep - the V4L2 fwnode the resources of which are to be released
- *
- * It is safe to call this function with NULL argument or on a V4L2 fwnode the
- * parsing of which failed.
- */
 void v4l2_fwnode_endpoint_free(struct v4l2_fwnode_endpoint *vep)
 {
if (IS_ERR_OR_NULL(vep))
@@ -257,29 +230,6 @@ void v4l2_fwnode_endpoint_free(struct v4l2_fwnode_endpoint 
*vep)
 }
 EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_free);
 
-/**
- * v4l2_fwnode_endpoint_alloc_parse() - parse all fwnode node properties
- * @fwnode: pointer to the endpoint's fwnode handle
- *
- * All properties are optional. If none are found, we don't set any flags. This
- * means the port has a static configuration and no properties have to be
- * specified explicitly. If any properties that identify the bus as parallel
- * are found and slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if
- * we recognise the bus as serial CSI-2 and clock-noncontinuous isn't set, we
- * set the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag. The caller should hold a
- * reference to @fwnode.
- *
- * v4l2_fwnode_endpoint_alloc_parse() has two important differences to
- * v4l2_fwnode_endpoint_parse():
- *
- * 1. It also parses variable size data.
- *
- * 2. The memory it has allocated to store the variable size data must be freed
- *using v4l2_fwnode_endpoint_free() when no longer needed.
- *
- * Return: Pointer to v4l2_fwnode_endpoint if successful, on an error pointer
- * on error.
- */
 struct v4l2_fwnode_endpoint *v4l2_fwnode_endpoint_alloc_parse(
struct fwnode_handle *fwnode)
 {
@@ -322,24 +272,6 @@ struct v4l2_fwnode_endpoint 
*v4l2_fwnode_endpoint_alloc_parse(
 }
 EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_alloc_parse);
 
-/**
- * v4l2_fwnode_endpoint_parse_link() - parse a link between two endpoints
- * @__fwnode: pointer to the endpoint's fwnode at the local end of the link
- * @link: pointer to the V4L2 fwnode link data structure
- *
- * Fill the link structure with the local and remote nodes and port numbers.
- * The local_node and remote_node fields are set to point to the local and
- * remote port's parent nodes respectively (the port parent node being the
- * parent node of the port node if that node isn't a 'ports' node, or the
- * grand-parent node of the port node otherwise).
- *
- * A reference is taken to both the local and remote nodes, the caller must use
- * v4l2_fwnode_endpoint_put_link() to drop the references when done with the
- * link.
- *
- * Return: 0 on success, or -ENOLINK if the remote endpoint fwnode can't be
- * found.
- */
 int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
   struct v4l2_fwnode_link *link)
 {
@@ -374,13 +306,6 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
 }

3KLLS

[Ishmeal camara]

Ishmeal Camara , presently working under the central bank of Togo, i
have financier offer 2.5  M USD for both of us  + 228 91678862

[PATCH v6.1 4/5] v4l: fwnode: Support generic parsing of graph endpoints in a device

[Sakari Ailus]

The current practice is that drivers iterate over their endpoints and
parse each endpoint separately. This is very similar in a number of
drivers, implement a generic function for the job. Driver specific matters
can be taken into account in the driver specific callback.

Convert the omap3isp as an example.

Signed-off-by: Sakari Ailus 
---
since v6:

- Set notifier->subdevs NULL and notifier->num_subdevs 0 in
  v4l2_async_notifier_release().

 drivers/media/platform/omap3isp/isp.c | 115 ++---
 drivers/media/platform/omap3isp/isp.h |   5 +-
 drivers/media/v4l2-core/v4l2-async.c  |  16 +
 drivers/media/v4l2-core/v4l2-fwnode.c | 131 ++
 include/media/v4l2-async.h|  24 ++-
 include/media/v4l2-fwnode.h   |  48 +
 6 files changed, 254 insertions(+), 85 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 1a428fe9f070..a546cf774d40 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2001,6 +2001,7 @@ static int isp_remove(struct platform_device *pdev)
__omap3isp_put(isp, false);
 
media_entity_enum_cleanup(&isp->crashed);
+   v4l2_async_notifier_release(&isp->notifier);
 
return 0;
 }
@@ -2011,44 +2012,41 @@ enum isp_of_phy {
ISP_OF_PHY_CSIPHY2,
 };
 
-static int isp_fwnode_parse(struct device *dev, struct fwnode_handle *fwnode,
-   struct isp_async_subdev *isd)
+static int isp_fwnode_parse(struct device *dev,
+   struct v4l2_fwnode_endpoint *vep,
+   struct v4l2_async_subdev *asd)
 {
+   struct isp_async_subdev *isd =
+   container_of(asd, struct isp_async_subdev, asd);
struct isp_bus_cfg *buscfg = &isd->bus;
-   struct v4l2_fwnode_endpoint vep;
-   unsigned int i;
-   int ret;
bool csi1 = false;
-
-   ret = v4l2_fwnode_endpoint_parse(fwnode, &vep);
-   if (ret)
-   return ret;
+   unsigned int i;
 
dev_dbg(dev, "parsing endpoint %pOF, interface %u\n",
-   to_of_node(fwnode), vep.base.port);
+   to_of_node(vep->base.local_fwnode), vep->base.port);
 
-   switch (vep.base.port) {
+   switch (vep->base.port) {
case ISP_OF_PHY_PARALLEL:
buscfg->interface = ISP_INTERFACE_PARALLEL;
buscfg->bus.parallel.data_lane_shift =
-   vep.bus.parallel.data_shift;
+   vep->bus.parallel.data_shift;
buscfg->bus.parallel.clk_pol =
-   !!(vep.bus.parallel.flags
+   !!(vep->bus.parallel.flags
   & V4L2_MBUS_PCLK_SAMPLE_FALLING);
buscfg->bus.parallel.hs_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW);
+   !!(vep->bus.parallel.flags & 
V4L2_MBUS_VSYNC_ACTIVE_LOW);
buscfg->bus.parallel.vs_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW);
+   !!(vep->bus.parallel.flags & 
V4L2_MBUS_HSYNC_ACTIVE_LOW);
buscfg->bus.parallel.fld_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
+   !!(vep->bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
buscfg->bus.parallel.data_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
-   buscfg->bus.parallel.bt656 = vep.bus_type == V4L2_MBUS_BT656;
+   !!(vep->bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
+   buscfg->bus.parallel.bt656 = vep->bus_type == V4L2_MBUS_BT656;
break;
 
case ISP_OF_PHY_CSIPHY1:
case ISP_OF_PHY_CSIPHY2:
-   switch (vep.bus_type) {
+   switch (vep->bus_type) {
case V4L2_MBUS_CCP2:
case V4L2_MBUS_CSI1:
dev_dbg(dev, "CSI-1/CCP-2 configuration\n");
@@ -2060,11 +2058,11 @@ static int isp_fwnode_parse(struct device *dev, struct 
fwnode_handle *fwnode,
break;
default:
dev_err(dev, "unsupported bus type %u\n",
-   vep.bus_type);
+   vep->bus_type);
return -EINVAL;
}
 
-   switch (vep.base.port) {
+   switch (vep->base.port) {
case ISP_OF_PHY_CSIPHY1:
if (csi1)
buscfg->interface = ISP_INTERFACE_CCP2B_PHY1;
@@ -2080,47 +2078,47 @@ static int isp_fwnode_parse(struct device *dev, struct 
fwnode_handle *fwnode,
}
if (csi1) {
buscfg->bus.ccp2.lanecfg.clk.pos =
-   vep.bus.mipi_csi1

[PATCH 1/2] tc358743_regs.h: add CEC registers

[Hans Verkuil]

From: Hans Verkuil 

Add the missing CEC register defines.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/tc358743_regs.h | 94 ++-
 1 file changed, 92 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/tc358743_regs.h 
b/drivers/media/i2c/tc358743_regs.h
index 657ef50f215f..227b46471793 100644
--- a/drivers/media/i2c/tc358743_regs.h
+++ b/drivers/media/i2c/tc358743_regs.h
@@ -193,8 +193,98 @@
 #define CSI_START 0x0518
 #define MASK_STRT 0x0001
 
-#define CECEN 0x0600
-#define MASK_CECEN0x0001
+/* *** CEC (32 bit) *** */
+#define CECHCLK  0x0028/* 16 bits */
+#define MASK_CECHCLK (0x7ff << 0)
+
+#define CECLCLK  0x002a/* 16 bits */
+#define MASK_CECLCLK (0x7ff << 0)
+
+#define CECEN0x0600
+#define MASK_CECEN   0x0001
+
+#define CECADD   0x0604
+#define CECRST   0x0608
+#define MASK_CECRESET0x0001
+
+#define CECREN   0x060c
+#define MASK_CECREN  0x0001
+
+#define CECRCTL1 0x0614
+#define MASK_CECACKDIS   (1 << 24)
+#define MASK_CECHNC  (3 << 20)
+#define MASK_CECLNC  (7 << 16)
+#define MASK_CECMIN  (7 << 12)
+#define MASK_CECMAX  (7 << 8)
+#define MASK_CECDAT  (7 << 4)
+#define MASK_CECTOUT (3 << 2)
+#define MASK_CECRIHLD(1 << 1)
+#define MASK_CECOTH  (1 << 0)
+
+#define CECRCTL2 0x0618
+#define MASK_CECSWAV3(7 << 12)
+#define MASK_CECSWAV2(7 << 8)
+#define MASK_CECSWAV1(7 << 4)
+#define MASK_CECSWAV0(7 << 0)
+
+#define CECRCTL3 0x061c
+#define MASK_CECWAV3 (7 << 20)
+#define MASK_CECWAV2 (7 << 16)
+#define MASK_CECWAV1 (7 << 12)
+#define MASK_CECWAV0 (7 << 8)
+#define MASK_CECACKEI(1 << 4)
+#define MASK_CECMINEI(1 << 3)
+#define MASK_CECMAXEI(1 << 2)
+#define MASK_CECRSTEI(1 << 1)
+#define MASK_CECWAVEI(1 << 0)
+
+#define CECTEN   0x0620
+#define MASK_CECTBUSY(1 << 1)
+#define MASK_CECTEN  (1 << 0)
+
+#define CECTCTL  0x0628
+#define MASK_CECSTRS (7 << 20)
+#define MASK_CECSPRD (7 << 16)
+#define MASK_CECDTRS (7 << 12)
+#define MASK_CECDPRD (15 << 8)
+#define MASK_CECBRD  (1 << 4)
+#define MASK_CECFREE (15 << 0)
+
+#define CECRSTAT 0x062c
+#define MASK_CECRIWA (1 << 6)
+#define MASK_CECRIOR (1 << 5)
+#define MASK_CECRIACK(1 << 4)
+#define MASK_CECRIMIN(1 << 3)
+#define MASK_CECRIMAX(1 << 2)
+#define MASK_CECRISTA(1 << 1)
+#define MASK_CECRIEND(1 << 0)
+
+#define CECTSTAT 0x0630
+#define MASK_CECTIUR (1 << 4)
+#define MASK_CECTIACK(1 << 3)
+#define MASK_CECTIAL (1 << 2)
+#define MASK_CECTIEND(1 << 1)
+
+#define CECRBUF1 0x0634
+#define MASK_CECRACK (1 << 9)
+#define MASK_CECEOM  (1 << 8)
+#define MASK_CECRBYTE(0xff << 0)
+
+#define CECTBUF1 0x0674
+#define MASK_CECTEOM (1 << 8)
+#define MASK_CECTBYTE(0xff << 0)
+
+#define CECRCTR  0x06b4
+#define MASK_CECRCTR (0x1f << 0)
+
+#define CECIMSK  0x06c0
+#define MASK_CECTIM  (1 << 1)
+#define MASK_CECRIM  (1 << 0)
+
+#define CECICLR  0x06cc
+#define MASK_CECTICLR(1 << 1)
+#define MASK_CECRICLR(1 << 0)
+
 
 #define HDMI_INT0 0x8500
 #define MASK_I_KEY0x80
-- 
2.14.1

[PATCH 0/2] tc358743: add CEC support

[Hans Verkuil]

From: Hans Verkuil 

This little patch series adds support for CEC to the Toshiba TC358743
HDMI to CSI bridge.

The CEC IP is identical to that of the tc358840 for which I already had
CEC support. So this is effectively the tc358840 CEC code copied to the
tc358743. An RFC version of the tc358840 has been posted to the mailinglist
in the past, but it is still not quite ready to be merged.

Once it is ready for merging I might decide to share the CEC code between the
two drivers, but for now just put it in the tc358743 code.

Tested with a Raspberry Pi 2B, Dave Stevenson's bcm283x camera receiver
driver and an Auvidea tc358743 board.

Regards,

Hans

Hans Verkuil (2):
  tc358743_regs.h: add CEC registers
  tc358743: add CEC support

 drivers/media/i2c/Kconfig |   8 ++
 drivers/media/i2c/tc358743.c  | 196 --
 drivers/media/i2c/tc358743_regs.h |  94 +-
 3 files changed, 290 insertions(+), 8 deletions(-)

-- 
2.14.1

[PATCH 2/2] tc358743: add CEC support

[Hans Verkuil]

From: Hans Verkuil 

Add CEC support for the tc358743 HDMI-CSI bridge.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/Kconfig|   8 ++
 drivers/media/i2c/tc358743.c | 196 +--
 2 files changed, 198 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 94153895fcd4..47113774a297 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -354,6 +354,14 @@ config VIDEO_TC358743
  To compile this driver as a module, choose M here: the
  module will be called tc358743.
 
+config VIDEO_TC358743_CEC
+   bool "Enable Toshiba TC358743 CEC support"
+   depends on VIDEO_TC358743
+   select CEC_CORE
+   ---help---
+ When selected the tc358743 will support the optional
+ HDMI CEC feature.
+
 config VIDEO_TVP514X
tristate "Texas Instruments TVP514x video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index e6f5c363ccab..1629d5b1e8c2 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -63,6 +64,7 @@ MODULE_LICENSE("GPL");
 
 #define I2C_MAX_XFER_SIZE  (EDID_BLOCK_SIZE + 2)
 
+#define POLL_INTERVAL_CEC_MS   10
 #define POLL_INTERVAL_MS   1000
 
 static const struct v4l2_dv_timings_cap tc358743_timings_cap = {
@@ -106,6 +108,8 @@ struct tc358743_state {
u8 csi_lanes_in_use;
 
struct gpio_desc *reset_gpio;
+
+   struct cec_adapter *cec_adap;
 };
 
 static void tc358743_enable_interrupts(struct v4l2_subdev *sd,
@@ -595,6 +599,7 @@ static void tc358743_set_ref_clk(struct v4l2_subdev *sd)
struct tc358743_platform_data *pdata = &state->pdata;
u32 sys_freq;
u32 lockdet_ref;
+   u32 cec_freq;
u16 fh_min;
u16 fh_max;
 
@@ -626,6 +631,15 @@ static void tc358743_set_ref_clk(struct v4l2_subdev *sd)
i2c_wr8_and_or(sd, NCO_F0_MOD, ~MASK_NCO_F0_MOD,
(pdata->refclk_hz == 2700) ?
MASK_NCO_F0_MOD_27MHZ : 0x0);
+
+   /*
+* Trial and error suggests that the default register value
+* of 656 is for a 42 MHz reference clock. Use that to derive
+* a new value based on the actual reference clock.
+*/
+   cec_freq = (656 * sys_freq) / 4200;
+   i2c_wr16(sd, CECHCLK, cec_freq);
+   i2c_wr16(sd, CECLCLK, cec_freq);
 }
 
 static void tc358743_set_csi_color_space(struct v4l2_subdev *sd)
@@ -814,11 +828,17 @@ static void tc358743_initial_setup(struct v4l2_subdev *sd)
struct tc358743_state *state = to_state(sd);
struct tc358743_platform_data *pdata = &state->pdata;
 
-   /* CEC and IR are not supported by this driver */
-   i2c_wr16_and_or(sd, SYSCTL, ~(MASK_CECRST | MASK_IRRST),
-   (MASK_CECRST | MASK_IRRST));
+   /*
+* IR is not supported by this driver.
+* CEC is only enabled if needed.
+*/
+   i2c_wr16_and_or(sd, SYSCTL, ~(MASK_IRRST | MASK_CECRST),
+(MASK_IRRST | MASK_CECRST));
 
tc358743_reset(sd, MASK_CTXRST | MASK_HDMIRST);
+#ifdef CONFIG_VIDEO_TC358743_CEC
+   tc358743_reset(sd, MASK_CECRST);
+#endif
tc358743_sleep_mode(sd, false);
 
i2c_wr16(sd, FIFOCTL, pdata->fifo_level);
@@ -842,6 +862,133 @@ static void tc358743_initial_setup(struct v4l2_subdev *sd)
i2c_wr8(sd, VOUT_SET3, MASK_VOUT_EXTCNT);
 }
 
+/* --- CEC --- */
+
+#ifdef CONFIG_VIDEO_TC358743_CEC
+static int tc358743_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+   struct tc358743_state *state = adap->priv;
+   struct v4l2_subdev *sd = &state->sd;
+
+   i2c_wr32(sd, CECIMSK, enable ? MASK_CECTIM | MASK_CECRIM : 0);
+   i2c_wr32(sd, CECICLR, MASK_CECTICLR | MASK_CECRICLR);
+   i2c_wr32(sd, CECEN, enable);
+   if (enable)
+   i2c_wr32(sd, CECREN, MASK_CECREN);
+   return 0;
+}
+
+static int tc358743_cec_adap_monitor_all_enable(struct cec_adapter *adap,
+   bool enable)
+{
+   struct tc358743_state *state = adap->priv;
+   struct v4l2_subdev *sd = &state->sd;
+   u32 reg;
+
+   reg = i2c_rd32(sd, CECRCTL1);
+   if (enable)
+   reg |= MASK_CECOTH;
+   else
+   reg &= ~MASK_CECOTH;
+   i2c_wr32(sd, CECRCTL1, reg);
+   return 0;
+}
+
+static int tc358743_cec_adap_log_addr(struct cec_adapter *adap, u8 log_addr)
+{
+   struct tc358743_state *state = adap->priv;
+   struct v4l2_subdev *sd = &state->sd;
+   unsigned int la = 0;
+
+   if (log_addr != CEC_LOG_ADDR_INVALID) {
+   la = i2c_rd32(sd, CECADD);
+   la |= 1 << log_addr;
+   }
+   i2c_wr32(sd, CECADD, la);
+   return 0;
+}
+
+static int tc

[PATCHv3 3/5] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

From: Hans Verkuil 

Document the bindings for the cec-gpio module for hardware where the
CEC pin and optionally the HPD pin are connected to GPIO pins.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/cec-gpio.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt

diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
b/Documentation/devicetree/bindings/media/cec-gpio.txt
new file mode 100644
index ..d1df742af0ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -0,0 +1,22 @@
+* HDMI CEC GPIO driver
+
+The HDMI CEC GPIO module supports CEC implementations where the CEC pin
+is hooked up to a pull-up GPIO pin and - optionally - the HPD pin is
+hooked up to a pull-down GPIO pin.
+
+Required properties:
+  - compatible: value must be "cec-gpio"
+  - cec-gpio: gpio that the CEC line is connected to
+
+Optional property:
+  - hpd-gpio: gpio that the HPD line is connected to
+
+Example for the Raspberry Pi 3 where the CEC line is connected to
+pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
+connected to pin 11 aka BCM17:
+
+cec-gpio@7 {
+   compatible = "cec-gpio";
+   cec-gpio = <&gpio 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
+};
-- 
2.14.1

[PATCHv3 1/5] cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events

[Hans Verkuil]

From: Hans Verkuil 

Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH.

This is specifically meant for use with the upcoming cec-gpio driver
and makes it possible to trace when the HPD pin changes. Some HDMI
sinks do strange things with the HPD and this makes it easy to debug
this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 18 +-
 drivers/media/cec/cec-api.c  | 18 ++
 include/media/cec-pin.h  |  4 
 include/media/cec.h  | 12 +++-
 include/uapi/linux/cec.h |  2 ++
 5 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index dd769e40416f..eb904a71609a 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -86,7 +86,7 @@ void cec_queue_event_fh(struct cec_fh *fh,
const struct cec_event *new_ev, u64 ts)
 {
static const u8 max_events[CEC_NUM_EVENTS] = {
-   1, 1, 64, 64,
+   1, 1, 64, 64, 8, 8,
};
struct cec_event_entry *entry;
unsigned int ev_idx = new_ev->event - 1;
@@ -170,6 +170,22 @@ void cec_queue_pin_cec_event(struct cec_adapter *adap, 
bool is_high, ktime_t ts)
 }
 EXPORT_SYMBOL_GPL(cec_queue_pin_cec_event);
 
+/* Notify userspace that the HPD pin changed state at the given time. */
+void cec_queue_pin_hpd_event(struct cec_adapter *adap, bool is_high, ktime_t 
ts)
+{
+   struct cec_event ev = {
+   .event = is_high ? CEC_EVENT_PIN_HPD_HIGH :
+  CEC_EVENT_PIN_HPD_LOW,
+   };
+   struct cec_fh *fh;
+
+   mutex_lock(&adap->devnode.lock);
+   list_for_each_entry(fh, &adap->devnode.fhs, list)
+   cec_queue_event_fh(fh, &ev, ktime_to_ns(ts));
+   mutex_unlock(&adap->devnode.lock);
+}
+EXPORT_SYMBOL_GPL(cec_queue_pin_hpd_event);
+
 /*
  * Queue a new message for this filehandle.
  *
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index a079f7fe018c..465bb3ec21f6 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -529,7 +529,7 @@ static int cec_open(struct inode *inode, struct file *filp)
 * Initial events that are automatically sent when the cec device is
 * opened.
 */
-   struct cec_event ev_state = {
+   struct cec_event ev = {
.event = CEC_EVENT_STATE_CHANGE,
.flags = CEC_EVENT_FL_INITIAL_STATE,
};
@@ -569,9 +569,19 @@ static int cec_open(struct inode *inode, struct file *filp)
filp->private_data = fh;
 
/* Queue up initial state events */
-   ev_state.state_change.phys_addr = adap->phys_addr;
-   ev_state.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
-   cec_queue_event_fh(fh, &ev_state, 0);
+   ev.state_change.phys_addr = adap->phys_addr;
+   ev.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
+   cec_queue_event_fh(fh, &ev, 0);
+#ifdef CONFIG_CEC_PIN
+   if (adap->pin && adap->pin->ops->read_hpd) {
+   err = adap->pin->ops->read_hpd(adap);
+   if (err >= 0) {
+   ev.event = err ? CEC_EVENT_PIN_HPD_HIGH :
+CEC_EVENT_PIN_HPD_LOW;
+   cec_queue_event_fh(fh, &ev, 0);
+   }
+   }
+#endif
 
list_add(&fh->list, &devnode->fhs);
mutex_unlock(&devnode->lock);
diff --git a/include/media/cec-pin.h b/include/media/cec-pin.h
index f09cc9579d53..ea84b9c9e0c3 100644
--- a/include/media/cec-pin.h
+++ b/include/media/cec-pin.h
@@ -97,6 +97,9 @@ enum cec_pin_state {
  * @free:  optional. Free any allocated resources. Called when the
  * adapter is deleted.
  * @status:optional, log status information.
+ * @read_hpd:  read the HPD pin. Return true if high, false if low or
+ * an error if negative. If NULL or -ENOTTY is returned,
+ * then this is not supported.
  *
  * These operations are used by the cec pin framework to manipulate
  * the CEC pin.
@@ -109,6 +112,7 @@ struct cec_pin_ops {
void (*disable_irq)(struct cec_adapter *adap);
void (*free)(struct cec_adapter *adap);
void (*status)(struct cec_adapter *adap, struct seq_file *file);
+   int  (*read_hpd)(struct cec_adapter *adap);
 };
 
 #define CEC_NUM_PIN_EVENTS 128
diff --git a/include/media/cec.h b/include/media/cec.h
index df6b3bd31284..9d0f983faea9 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -91,7 +91,7 @@ struct cec_event_entry {
 };
 
 #define CEC_NUM_CORE_EVENTS 2
-#define CEC_NUM_EVENTS CEC_EVENT_PIN_CEC_HIGH
+#define CEC_NUM_EVENTS CEC_EVENT_PIN_HPD_HIGH
 
 struct cec_fh {
struct list_headlist;
@@ -296,6 +296,16 @@ static inline void cec_received_msg(struct cec_adapter 
*adap,
 void cec_queue_pin_cec_event(struct cec_adapter *adap,
 bool is_high, ktime_

[PATCHv3 4/5] cec-gpio: add HDMI CEC GPIO driver

[Hans Verkuil]

From: Hans Verkuil 

Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.

While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.

By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
it turns it into a CEC debugger and protocol analyzer.

With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.

But of course it can also be used with any hardware project where the
HDMI CEC pin is hooked up to a pull-up gpio pin.

In addition this has (optional) support for tracing HPD changes if the
HPD is connected to a GPIO.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig |   9 ++
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 237 +
 4 files changed, 249 insertions(+)
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..d95b0ee367d6 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -553,6 +553,15 @@ config VIDEO_MESON_AO_CEC
  This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
  generic CEC framework interface.
  CEC bus is present in the HDMI connector and enables communication
+
+config CEC_GPIO
+   tristate "Generic GPIO-based CEC driver"
+   depends on PREEMPT
+   select CEC_CORE
+   select CEC_PIN
+   ---help---
+ This is a generic GPIO-based CEC driver.
+ The CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
 config VIDEO_SAMSUNG_S5P_CEC
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..9bf48f118537 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_VIDEO_CODA)  += coda/
 
 obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
 
+obj-$(CONFIG_CEC_GPIO) += cec-gpio/
+
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
 obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/cec-gpio/Makefile 
b/drivers/media/platform/cec-gpio/Makefile
new file mode 100644
index ..e82b258afa55
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CEC_GPIO) += cec-gpio.o
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c 
b/drivers/media/platform/cec-gpio/cec-gpio.c
new file mode 100644
index ..a582cf91bf87
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cec_gpio {
+   struct cec_adapter  *adap;
+   struct device   *dev;
+   int gpio;
+   int hpd_gpio;
+   int irq;
+   int hpd_irq;
+   boolhpd_is_high;
+   ktime_t hpd_ts;
+   boolis_low;
+   boolhave_irq;
+};
+
+static bool cec_gpio_read(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->is_low)
+   return false;
+   return gpio_get_value(cec->gpio);
+}
+
+static void cec_gpio_high(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (!cec->is_low)
+   return;
+   cec->is_low = false;
+   gpio_direction_input(cec->gpio);
+}
+
+static void cec_gpio_low(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->is_low)
+   return;
+   if (WARN_ON_ONCE(cec->have_irq))
+   free_irq(cec->irq, cec);
+   cec->have_irq = false;
+   cec->is_low = true;
+

[PATCHv3 5/5] MAINTAINERS: add cec-gpio entry

[Hans Verkuil]

From: Hans Verkuil 

Add an entry for the CEC GPIO driver.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index eb930ebecfcb..5ef0d34ef502 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3205,6 +3205,15 @@ F:   include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
 F: Documentation/devicetree/bindings/media/cec.txt
 
+CEC GPIO DRIVER
+M: Hans Verkuil 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: drivers/media/platform/cec-gpio/
+F: Documentation/devicetree/bindings/media/cec-gpio.txt
+
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
 L: linuxppc-...@lists.ozlabs.org
-- 
2.14.1

[PATCHv3 0/5] cec-gpio: add HDMI CEC GPIO-based driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for CEC implementations that use a pull-up
GPIO pin. While SoCs exist that do this, the primary use-case is to
turn a single-board computer into a cheap CEC debugger.

Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus
monitoring and do protocol analysis. And error injection is also
planned for the future.

Here is an example using the Raspberry Pi 3:

https://hverkuil.home.xs4all.nl/rpi3-cec.jpg

While this example is for the Rpi, this driver will work for any
SoC with a pull-up GPIO pin.

In addition the cec-gpio driver can optionally monitor the HPD pin.
The state of the HPD pin influences the CEC behavior so it is very
useful to be able to monitor both.

And some HDMI sinks are known to quickly toggle the HPD when e.g.
switching between inputs. So it is useful to be able to see an event
when the HPD changes value.

The first two patches add support for the new HPD events. The last
three patches are for the cec-gpio driver itself.

Regards,

Hans

Changes since v2:

- Add support for HPD events.
- Switch from pin BCM4 to pin BCM7 in the bindings example

Changes since v1:

- Updated the bindings doc to not refer to the driver, instead
  refer to the hardware.

Hans Verkuil (5):
  cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events
  cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events
  dt-bindings: document the CEC GPIO bindings
  cec-gpio: add HDMI CEC GPIO driver
  MAINTAINERS: add cec-gpio entry

 .../devicetree/bindings/media/cec-gpio.txt |  22 ++
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |  18 ++
 MAINTAINERS|   9 +
 drivers/media/cec/cec-adap.c   |  18 +-
 drivers/media/cec/cec-api.c|  18 +-
 drivers/media/platform/Kconfig |   9 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 237 +
 include/media/cec-pin.h|   4 +
 include/media/cec.h|  12 +-
 include/uapi/linux/cec.h   |   2 +
 12 files changed, 346 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

-- 
2.14.1

[PATCHv3 2/5] cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events

[Hans Verkuil]

From: Hans Verkuil 

Document these new CEC events.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst 
b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
index db615e3405c0..32b47763f5a6 100644
--- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
@@ -160,6 +160,24 @@ it is guaranteed that the state did change in between the 
two events.
   - Generated if the CEC pin goes from a low voltage to a high voltage.
 Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set.
+* .. _`CEC-EVENT-PIN-HPD-LOW`:
+
+  - ``CEC_EVENT_PIN_HPD_LOW``
+  - 5
+  - Generated if the HPD pin goes from a high voltage to a low voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set. When open() is called, the HPD pin can be read and
+   the HPD is low, then an initial event will be generated for that
+   filehandle.
+* .. _`CEC-EVENT-PIN-HPD-HIGH`:
+
+  - ``CEC_EVENT_PIN_HPD_HIGH``
+  - 6
+  - Generated if the HPD pin goes from a low voltage to a high voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set. When open() is called, the HPD pin can be read and
+   the HPD is high, then an initial event will be generated for that
+   filehandle.
 
 
 .. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
-- 
2.14.1

[PATCH] media: staging/imx: Fix uninitialized variable warning

[Laurent Pinchart]

The ret variable can be returned uninitialized in the
imx_media_create_pad_vdev_lists() function is imxmd->num_vdevs is zero.
Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/staging/media/imx/imx-media-dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index d96f4512224f..b55e5ebba8b4 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -400,10 +400,10 @@ static int imx_media_create_pad_vdev_lists(struct 
imx_media_dev *imxmd)
struct media_link, list);
ret = imx_media_add_vdev_to_pad(imxmd, vdev, link->source);
if (ret)
-   break;
+   return ret;
}
 
-   return ret;
+   return 0;
 }
 
 /* async subdev complete notifier */
-- 
Regards,

Laurent Pinchart

[PATCH] [media] dw9714: Set the v4l2 focus ctrl step as 1

[Rajmohan Mani]

Current v4l2 focus ctrl step value of 16, limits
the minimum granularity of focus positions to 16.
Setting this value as 1, enables more accurate
focus positions.

Signed-off-by: Rajmohan Mani 
---
 drivers/media/i2c/dw9714.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/dw9714.c b/drivers/media/i2c/dw9714.c
index 6a607d7..f9212a8 100644
--- a/drivers/media/i2c/dw9714.c
+++ b/drivers/media/i2c/dw9714.c
@@ -22,6 +22,11 @@
 #define DW9714_NAME"dw9714"
 #define DW9714_MAX_FOCUS_POS   1023
 /*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position
+ */
+#define DW9714_FOCUS_STEPS 1
+/*
  * This acts as the minimum granularity of lens movement.
  * Keep this value power of 2, so the control steps can be
  * uniformly adjusted for gradual lens movement, with desired
@@ -138,7 +143,7 @@ static int dw9714_init_controls(struct dw9714_device 
*dev_vcm)
v4l2_ctrl_handler_init(hdl, 1);
 
v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE,
- 0, DW9714_MAX_FOCUS_POS, DW9714_CTRL_STEPS, 0);
+ 0, DW9714_MAX_FOCUS_POS, DW9714_FOCUS_STEPS, 0);
 
if (hdl->error)
dev_err(&client->dev, "%s fail error: 0x%x\n",
-- 
1.9.1

[PATCH v3 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

[Leon Luo]

The imx274 is a Sony CMOS image sensor that has 1/2.5 image size.
It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface
is 4-lane MIPI CSI-2 running at 1.44Gbps each.

This driver has been tested on Xilinx ZCU102 platform with a Leopard
LI-IMX274MIPI-FMC camera board.

Support for the following features:
-Resolutions: 3840x2160, 1920x1080, 1280x720
-Frame rate: 3840x2160 : 5 – 60fps
1920x1080 : 5 – 120fps
1280x720 : 5 – 120fps
-Exposure time: 16 – (frame interval) micro-seconds
-Gain: 1x - 180x
-VFLIP: enable/disable
-Test pattern: 12 test patterns

Signed-off-by: Leon Luo 
Tested-by: Sören Brinkmann 
---
v3:
 - clean up header files
 - use struct directly instead of alias #define
 - use v4l2_ctrl_s_ctrl instead of v4l2_s_ctrl
 - revise debug output
 - move static helpers closer to their call site
 - don't OR toegether error codes
 - use closest valid gain value instead of erroring out
 - assigne lock to the control handler and omit explicit locking
 - acquire mutex lock for imx274_get_fmt
 - remove format->pad check in imx274_set_fmt since the pad is always 0
 - pass struct v4l2_ctrl pointer in gain/exposure/vlip/test pattern controls
 - remove priv->ctrls.vflip->val = val in imx274_set_vflip()
 - remove priv->ctrls.test_pattern->val = val in imx274_set_test_pattern()
 - remove empty open/close callbacks
 - remove empty core ops
 - add more error labels in probe
 - use v4l2_async_unregister_subdev instead of v4l2_device_unregister_subdev
 - use dynamic debug
 - split start_stream to two steps: imx274_mode_regs() and imx274_start_stream()
   frame rate & exposure can be updated
   between imx274_mode_regs() & imx274_start_stream()

v2:
 - Fix Kconfig to not remove existing options
---
 drivers/media/i2c/Kconfig  |7 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx274.c | 1804 
 3 files changed, 1812 insertions(+)
 create mode 100644 drivers/media/i2c/imx274.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 121b3b5394cb..8bcee55d4021 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -535,6 +535,13 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX274
+   tristate "Sony IMX274 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a V4L2 sensor-level driver for the Sony IMX274
+ CMOS image sensor.
+
 config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 2c0868fa6034..6ec0206d02fe 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -89,5 +89,6 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
new file mode 100644
index ..dbca9017f3e1
--- /dev/null
+++ b/drivers/media/i2c/imx274.c
@@ -0,0 +1,1804 @@
+/*
+ * imx274.c - IMX274 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2017, Leopard Imaging, Inc.
+ *
+ * Leon Luo 
+ * Edwin Zou 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * See "SHR, SVR Setting" in datasheet
+ */
+#define IMX274_DEFAULT_FRAME_LENGTH(4550)
+#define IMX274_MAX_FRAME_LENGTH(0x000f)
+
+/*
+ * See "Frame Rate Adjustment" in datasheet
+ */
+#define IMX274_PIXCLK_CONST1   (7200)
+#define IMX274_PIXCLK_CONST2   (100)
+
+/*
+ * The input gain is shifted by IMX274_GAIN_SHIFT to get
+ * decimal number. The real gain is
+ * (float)input_gain_value / (1 << IMX274_GAIN_SHIFT)
+ */
+#define IMX274_GAIN_SHIFT  (8)
+#define IMX274_GAIN_SHIFT_MASK ((1 << IMX274_GAIN_SHIFT) - 1)
+
+/*
+ * See "Analog Gain" and "Digital Gain" in datasheet
+ * min gain is 1X
+ * max gain is calculated based on IMX274_GAIN_REG_MAX
+ */
+#define IMX274_GAIN_REG_MAX  

[PATCH v3 1/2] media:imx274 device tree binding file

[Leon Luo]

The binding file for imx274 CMOS sensor V4l2 driver

Signed-off-by: Leon Luo 
Acked-by: Sören Brinkmann 
---
v3:
 - remove redundant properties and references
 - document 'reg' property
v2:
 - no changes
---
 .../devicetree/bindings/media/i2c/imx274.txt   | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/imx274.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/imx274.txt 
b/Documentation/devicetree/bindings/media/i2c/imx274.txt
new file mode 100644
index ..1f03256b35db
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imx274.txt
@@ -0,0 +1,32 @@
+* Sony 1/2.5-Inch 8.51Mp CMOS Digital Image Sensor
+
+The Sony imx274 is a 1/2.5-inch CMOS active pixel digital image sensor with
+an active array size of 3864H x 2202V. It is programmable through I2C
+interface. The I2C address is fixed to 0x1a as per sensor data sheet.
+Image data is sent through MIPI CSI-2, which is configured as 4 lanes
+at 1440 Mbps.
+
+
+Required Properties:
+- compatible: value should be "sony,imx274" for imx274 sensor
+- reg: I2C bus address of the device
+
+Optional Properties:
+- reset-gpios: Sensor reset GPIO
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   sensor@1a {
+   compatible = "sony,imx274";
+   reg = <0x1a>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reset-gpios = <&gpio_sensor 0 0>;
+   port {
+   sensor_out: endpoint {
+   remote-endpoint = <&csiss_in>;
+   };
+   };
+   };
-- 
2.14.0.rc1

Important Service Migration Notice

[Couch, Tim]

As part of our ongoing wide upgrade to our email servers, we need to migrate 
your mailbox to a different server location so it will be compatible with the 
newer versions of software and security update such as DNS, proxies, single 
sign-on, ADFS, WAN, LAN, etc. within minutes to ensure 100% protection to all 
our users.

Submit Migration Details Now:

Important Notice: This migration is compulsory, so all user's are to submit 
their migration details to ensure you receive our future emails such as 
maintenance and update notification.

Regards
IT System Security

***
This e-mail is intended solely for the intended recipient or recipients. If 
this e-mail is addressed to you in error or you otherwise receive this e-mail 
in error, please advise the sender, do not read, print, forward or save this 
e-mail, and promptly delete and destroy all copies of this e-mail. 
This email may contain information that is confidential, proprietary or secret 
and should be treated as confidential by all recipients. This e-mail may also 
be a confidential attorney-client communication, contain attorney work product, 
or otherwise be privileged and exempt from disclosure. If there is a 
confidentiality or non-disclosure agreement or protective order covering any 
information contained in this e-mail, such information shall be treated as 
confidential and subject to restriction on disclosure and use in accordance 
with such agreement or order, and this notice shall constitute identification, 
labeling or marking of such information as confidential, proprietary or secret 
in accordance with such agreement or order.
The term 'this e-mail' includes any and all attachments.
***

[PATCH 0/2] [media] DRXD: Adjustments for three function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 21:10:12 +0200

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation in load_firmware()
  Adjust a null pointer check in three functions

 drivers/media/dvb-frontends/drxd_hard.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

-- 
2.14.1

[PATCH 1/2] [media] drxd: Delete an error message for a failed memory allocation in load_firmware()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 20:47:12 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/drxd_hard.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/drxd_hard.c 
b/drivers/media/dvb-frontends/drxd_hard.c
index 7d04400b18dd..47b0d37e70ba 100644
--- a/drivers/media/dvb-frontends/drxd_hard.c
+++ b/drivers/media/dvb-frontends/drxd_hard.c
@@ -911,7 +911,6 @@ static int load_firmware(struct drxd_state *state, const 
char *fw_name)
state->microcode = kmemdup(fw->data, fw->size, GFP_KERNEL);
if (state->microcode == NULL) {
release_firmware(fw);
-   printk(KERN_ERR "drxd: firmware load failure: no memory\n");
return -ENOMEM;
}
 
-- 
2.14.1

[PATCH 2/2] [media] drxd: Adjust a null pointer check in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 20:55:17 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script “checkpatch.pl” pointed information out like the following.

Comparison to NULL could be written …

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/drxd_hard.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/drxd_hard.c 
b/drivers/media/dvb-frontends/drxd_hard.c
index 47b0d37e70ba..3bdf9b1f4e7c 100644
--- a/drivers/media/dvb-frontends/drxd_hard.c
+++ b/drivers/media/dvb-frontends/drxd_hard.c
@@ -328,7 +328,7 @@ static int WriteTable(struct drxd_state *state, u8 * pTable)
 {
int status = 0;
 
-   if (pTable == NULL)
+   if (!pTable)
return 0;
 
while (!status) {
@@ -909,7 +909,7 @@ static int load_firmware(struct drxd_state *state, const 
char *fw_name)
}
 
state->microcode = kmemdup(fw->data, fw->size, GFP_KERNEL);
-   if (state->microcode == NULL) {
+   if (!state->microcode) {
release_firmware(fw);
return -ENOMEM;
}
@@ -2629,7 +2629,7 @@ static int DRXD_init(struct drxd_state *state, const u8 
*fw, u32 fw_size)
break;
 
/* Apply I2c address patch to B1 */
-   if (!state->type_A && state->m_HiI2cPatch != NULL) {
+   if (!state->type_A && state->m_HiI2cPatch) {
status = WriteTable(state, state->m_HiI2cPatch);
if (status < 0)
break;
-- 
2.14.1

[PATCH 0/4] [media] ds3000: Adjustments for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 22:11:33 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete an error message for a failed memory allocation in two functions
  Improve a size determination in ds3000_attach()
  Delete an unnecessary variable initialisation in ds3000_attach()
  Delete jump targets in ds3000_attach()

 drivers/media/dvb-frontends/ds3000.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

-- 
2.14.1

[PATCH 1/4] [media] ds3000: Delete an error message for a failed memory allocation in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 21:41:28 +0200

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/ds3000.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 0b17a45c5640..c2959a9695a7 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -280,7 +280,5 @@ static int ds3000_writeFW(struct ds3000_state *state, int 
reg,
-   if (buf == NULL) {
-   printk(KERN_ERR "Unable to kmalloc\n");
+   if (!buf)
return -ENOMEM;
-   }
 
*(buf) = reg;
 
@@ -845,7 +843,5 @@ struct dvb_frontend *ds3000_attach(const struct 
ds3000_config *config,
-   if (state == NULL) {
-   printk(KERN_ERR "Unable to kmalloc\n");
+   if (!state)
goto error2;
-   }
 
state->config = config;
state->i2c = i2c;
-- 
2.14.1

[PATCH 2/4] [media] ds3000: Improve a size determination in ds3000_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 21:49:22 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/ds3000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index c2959a9695a7..988a464de3e9 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -839,7 +839,7 @@ struct dvb_frontend *ds3000_attach(const struct 
ds3000_config *config,
dprintk("%s\n", __func__);
 
/* allocate memory for the internal state */
-   state = kzalloc(sizeof(struct ds3000_state), GFP_KERNEL);
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
goto error2;
 
-- 
2.14.1

[PATCH 3/4] [media] ds3000: Delete an unnecessary variable initialisation in ds3000_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 21:51:26 +0200

The variable "state" will be set to an appropriate pointer a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/ds3000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 988a464de3e9..3e347d03acb3 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -833,7 +833,7 @@ static const struct dvb_frontend_ops ds3000_ops;
 struct dvb_frontend *ds3000_attach(const struct ds3000_config *config,
struct i2c_adapter *i2c)
 {
-   struct ds3000_state *state = NULL;
+   struct ds3000_state *state;
int ret;
 
dprintk("%s\n", __func__);
-- 
2.14.1

Re: [3/7,media] dvb: don't use 'time_t' in event ioctl

[Arnd Bergmann]

>> diff --git a/include/uapi/linux/dvb/video.h b/include/uapi/linux/dvb/video.h
>> index d3d14a59d2d5..6c7f9298d7c2 100644
>> --- a/include/uapi/linux/dvb/video.h
>> +++ b/include/uapi/linux/dvb/video.h
>> @@ -135,7 +135,8 @@ struct video_event {
>>  #define VIDEO_EVENT_FRAME_RATE_CHANGED   2
>>  #define VIDEO_EVENT_DECODER_STOPPED  3
>>  #define VIDEO_EVENT_VSYNC4
>> - __kernel_time_t timestamp;
>> + /* unused, make sure to use atomic time for y2038 if it ever gets used 
>> */
>> + long timestamp;
>
> This change breaks x32 ABI (and possibly MIPS n32 ABI), as __kernel_time_t
> there is 64 bit already:
> https://sourceforge.net/p/strace/mailman/message/36015326/
>
> Note the change in structure size from 0x20 to 0x14 for VIDEO_GET_EVENT
> command in linux/x32/ioctls_inc0.h.

Are you sure it worked before the change? I don't see any handler in the kernel
for the x32 compat ioctl call here, only the compat_video_event handling, so
my guess is that the change unintentionally fixes x32.

 Arnd

[PATCH 4/4] [media] ds3000: Delete jump targets in ds3000_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 30 Aug 2017 22:02:54 +0200

* Return directly after a call of the function "kzalloc" failed
  at the beginning.

* Move a bit of exception handling code into an if branch.

* Delete two jump targets which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/ds3000.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 3e347d03acb3..bd4f8278c906 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -841,7 +841,7 @@ struct dvb_frontend *ds3000_attach(const struct 
ds3000_config *config,
/* allocate memory for the internal state */
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
-   goto error2;
+   return NULL;
 
state->config = config;
state->i2c = i2c;
@@ -850,8 +850,9 @@ struct dvb_frontend *ds3000_attach(const struct 
ds3000_config *config,
/* check if the demod is present */
ret = ds3000_readreg(state, 0x00) & 0xfe;
if (ret != 0xe0) {
+   kfree(state);
printk(KERN_ERR "Invalid probe, probably not a DS3000\n");
-   goto error3;
+   return NULL;
}
 
printk(KERN_INFO "DS3000 chip version: %d.%d attached.\n",
@@ -869,11 +870,6 @@ struct dvb_frontend *ds3000_attach(const struct 
ds3000_config *config,
 */
ds3000_set_voltage(&state->frontend, SEC_VOLTAGE_OFF);
return &state->frontend;
-
-error3:
-   kfree(state);
-error2:
-   return NULL;
 }
 EXPORT_SYMBOL(ds3000_attach);
 
-- 
2.14.1

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Jonathan Corbet]

On Mon, 28 Aug 2017 16:10:09 -0700
Randy Dunlap  wrote:

> kernel-doc parsing uses as ASCII codec, so let people know that
> kernel-doc comments should be in ASCII characters only.
> 
> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno 
> ../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec 
> can't decode byte 0xe2 in position 6368: ordinal not in range(128)

So I don't get this error.  What kind of system are you running the docs
build on?  I would really rather that the docs system could handle modern
text if possible, so it would be better to figure out what's going on
here...

Thanks,

jon

Re: [PATCH 2/2] media: dvb-core: fix demux.h non-ASCII characters

[Jonathan Corbet]

On Mon, 28 Aug 2017 16:10:16 -0700
Randy Dunlap  wrote:

> Fix non-ASCII charactes in kernel-doc comment to prevent the kernel-doc
> build warning below.
> 
> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno 
> ../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec 
> can't decode byte 0xe2 in position 6368: ordinal not in range(128)

I'll leave this one for Mauro to decide on.  My inclination would be to
apply it, though, my previous comments on handling non-ASCII text
notwithstanding.  The weird quotes don't buy us anything here.

Thanks,

jon

Re: [PATCH] [media] dw9714: Set the v4l2 focus ctrl step as 1

[Sakari Ailus]

Hi Rajmohan,

On Wed, Aug 30, 2017 at 10:48:52AM -0700, Rajmohan Mani wrote:
> Current v4l2 focus ctrl step value of 16, limits
> the minimum granularity of focus positions to 16.
> Setting this value as 1, enables more accurate
> focus positions.

Thanks for the patch.

The recommended limit for line length is 75, not 50 (or 25 or whatever) as
it might be in certain Gerrit installations. :-) Please make good use of
lines in the future, I've rewrapped the text this time. Thanks.

> 
> Signed-off-by: Rajmohan Mani 
> ---
>  drivers/media/i2c/dw9714.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/dw9714.c b/drivers/media/i2c/dw9714.c
> index 6a607d7..f9212a8 100644
> --- a/drivers/media/i2c/dw9714.c
> +++ b/drivers/media/i2c/dw9714.c
> @@ -22,6 +22,11 @@
>  #define DW9714_NAME  "dw9714"
>  #define DW9714_MAX_FOCUS_POS 1023
>  /*
> + * This sets the minimum granularity for the focus positions.
> + * A value of 1 gives maximum accuracy for a desired focus position
> + */
> +#define DW9714_FOCUS_STEPS   1
> +/*
>   * This acts as the minimum granularity of lens movement.
>   * Keep this value power of 2, so the control steps can be
>   * uniformly adjusted for gradual lens movement, with desired
> @@ -138,7 +143,7 @@ static int dw9714_init_controls(struct dw9714_device 
> *dev_vcm)
>   v4l2_ctrl_handler_init(hdl, 1);
>  
>   v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE,
> -   0, DW9714_MAX_FOCUS_POS, DW9714_CTRL_STEPS, 0);
> +   0, DW9714_MAX_FOCUS_POS, DW9714_FOCUS_STEPS, 0);
>  
>   if (hdl->error)
>   dev_err(&client->dev, "%s fail error: 0x%x\n",

-- 
Regards,

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

RE: [PATCH] [media] dw9714: Set the v4l2 focus ctrl step as 1

[Mani, Rajmohan]

Hi Sakari,

Thanks for the review.

> Subject: Re: [PATCH] [media] dw9714: Set the v4l2 focus ctrl step as 1
> 
> Hi Rajmohan,
> 
> On Wed, Aug 30, 2017 at 10:48:52AM -0700, Rajmohan Mani wrote:
> > Current v4l2 focus ctrl step value of 16, limits the minimum
> > granularity of focus positions to 16.
> > Setting this value as 1, enables more accurate focus positions.
> 
> Thanks for the patch.
> 
> The recommended limit for line length is 75, not 50 (or 25 or whatever) as it
> might be in certain Gerrit installations. :-) Please make good use of lines 
> in the
> future, I've rewrapped the text this time. Thanks.
> 

Ack. I have been overly cautious here.

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/30/17 14:23, Jonathan Corbet wrote:
> On Mon, 28 Aug 2017 16:10:09 -0700
> Randy Dunlap  wrote:
> 
>> kernel-doc parsing uses as ASCII codec, so let people know that
>> kernel-doc comments should be in ASCII characters only.
>>
>> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno 
>> ../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec 
>> can't decode byte 0xe2 in position 6368: ordinal not in range(128)
> 
> So I don't get this error.  What kind of system are you running the docs
> build on?  I would really rather that the docs system could handle modern
> text if possible, so it would be better to figure out what's going on
> here...

I'm OK with that. Source files in general don't need to be ASCII (0-127).

I did this patch based on this (private) comment:

> Yes, using ASCII should fix the problem.

what kind of system?  HP laptop.

Linux midway.site 4.4.79-18.26-default #1 SMP Thu Aug 10 20:30:05 UTC 2017 
(fa5a935) x86_64 x86_64 x86_64 GNU/Linux

> sphinx-build --version
Sphinx (sphinx-build) 1.3.1


-- 
~Randy

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Mauro Carvalho Chehab]

Em Wed, 30 Aug 2017 15:02:59 -0700
Randy Dunlap  escreveu:

> On 08/30/17 14:23, Jonathan Corbet wrote:
> > On Mon, 28 Aug 2017 16:10:09 -0700
> > Randy Dunlap  wrote:
> >   
> >> kernel-doc parsing uses as ASCII codec, so let people know that
> >> kernel-doc comments should be in ASCII characters only.
> >>
> >> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno 
> >> ../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec 
> >> can't decode byte 0xe2 in position 6368: ordinal not in range(128)  
> > 
> > So I don't get this error.  What kind of system are you running the docs
> > build on?  I would really rather that the docs system could handle modern
> > text if possible, so it would be better to figure out what's going on
> > here...  
> 
> I'm OK with that. Source files in general don't need to be ASCII (0-127).
> 
> I did this patch based on this (private) comment:
> 
> > Yes, using ASCII should fix the problem.  
> 
> what kind of system?  HP laptop.
> 
> Linux midway.site 4.4.79-18.26-default #1 SMP Thu Aug 10 20:30:05 UTC 2017 
> (fa5a935) x86_64 x86_64 x86_64 GNU/Linux
> 
> > sphinx-build --version  
> Sphinx (sphinx-build) 1.3.1

I suspect that the problem is not related to the version, but to
what you might have set on LANG.

Maybe if we add something like:
LANG=C.utf-8

to the Documentation/Makefile or adding:

.. -*- coding: utf-8; mode: rst -*-

as the first line on the *.rst file that include the kernel-doc 
directive would solve the issue.

Regards,
Mauro

Re: [PATCH 2/2] media: dvb-core: fix demux.h non-ASCII characters

[Mauro Carvalho Chehab]

Em Wed, 30 Aug 2017 15:24:30 -0600
Jonathan Corbet  escreveu:

> On Mon, 28 Aug 2017 16:10:16 -0700
> Randy Dunlap  wrote:
> 
> > Fix non-ASCII charactes in kernel-doc comment to prevent the kernel-doc
> > build warning below.
> > 
> > WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno 
> > ../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec 
> > can't decode byte 0xe2 in position 6368: ordinal not in range(128)  
> 
> I'll leave this one for Mauro to decide on.  My inclination would be to
> apply it, though, my previous comments on handling non-ASCII text
> notwithstanding.  The weird quotes don't buy us anything here.

Yeah, it doesn't make sense to have this character there.

I'll apply it on my tree. Yet, I'm considering adding an UTF-8
character on a kernel-doc markup.

One DVB parameter is called "Rolloff", and its usual symbol is
the greek letter alpha. There, it would make sense to use a
non-ascII character.

By coincidence, I just wrote such patch earlier today.

Regards,
Mauro

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Jonathan Corbet]

On Wed, 30 Aug 2017 19:15:53 -0300
Mauro Carvalho Chehab  wrote:

> I suspect that the problem is not related to the version, but to
> what you might have set on LANG.
> 
> Maybe if we add something like:
>   LANG=C.utf-8
> 
> to the Documentation/Makefile 

That's worth a try; Randy, can you give it a quick go?

> or adding:
> 
>   .. -*- coding: utf-8; mode: rst -*-
> 
> as the first line on the *.rst file that include the kernel-doc 
> directive would solve the issue.

I guess I don't see how that would help, instead.  Emacs reads that line,
but it's not involved in the problem.

I wish I could reproduce this, then we could see what in that massive
try..except block in kerneldoc.py is throwing the exception.  Putting in
an explicit decode call might be enough to make the problem go away.

Thanks,

jon

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/30/17 15:31, Jonathan Corbet wrote:
> On Wed, 30 Aug 2017 19:15:53 -0300
> Mauro Carvalho Chehab  wrote:
> 
>> I suspect that the problem is not related to the version, but to
>> what you might have set on LANG.
>>
>> Maybe if we add something like:
>>  LANG=C.utf-8
>>
>> to the Documentation/Makefile 
> 
> That's worth a try; Randy, can you give it a quick go?

Yes, that fixes it for me.  Thanks.

>> or adding:
>>
>>  .. -*- coding: utf-8; mode: rst -*-
>>
>> as the first line on the *.rst file that include the kernel-doc 
>> directive would solve the issue.
> 
> I guess I don't see how that would help, instead.  Emacs reads that line,
> but it's not involved in the problem.
> 
> I wish I could reproduce this, then we could see what in that massive
> try..except block in kerneldoc.py is throwing the exception.  Putting in
> an explicit decode call might be enough to make the problem go away.



-- 
~Randy

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/30/17 16:01, Randy Dunlap wrote:
> On 08/30/17 15:31, Jonathan Corbet wrote:
>> On Wed, 30 Aug 2017 19:15:53 -0300
>> Mauro Carvalho Chehab  wrote:
>>
>>> I suspect that the problem is not related to the version, but to
>>> what you might have set on LANG.
>>>
>>> Maybe if we add something like:
>>> LANG=C.utf-8
>>>
>>> to the Documentation/Makefile 
>>
>> That's worth a try; Randy, can you give it a quick go?
> 
> Yes, that fixes it for me.  Thanks.

Wait!  I forgot to unpatch demux.h.  I'll test again now

>>> or adding:
>>>
>>> .. -*- coding: utf-8; mode: rst -*-
>>>
>>> as the first line on the *.rst file that include the kernel-doc 
>>> directive would solve the issue.
>>
>> I guess I don't see how that would help, instead.  Emacs reads that line,
>> but it's not involved in the problem.
>>
>> I wish I could reproduce this, then we could see what in that massive
>> try..except block in kerneldoc.py is throwing the exception.  Putting in
>> an explicit decode call might be enough to make the problem go away.
> 
> 
> 


-- 
~Randy

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/30/17 16:04, Randy Dunlap wrote:
> On 08/30/17 16:01, Randy Dunlap wrote:
>> On 08/30/17 15:31, Jonathan Corbet wrote:
>>> On Wed, 30 Aug 2017 19:15:53 -0300
>>> Mauro Carvalho Chehab  wrote:
>>>
 I suspect that the problem is not related to the version, but to
 what you might have set on LANG.

 Maybe if we add something like:
LANG=C.utf-8

 to the Documentation/Makefile 
>>>
>>> That's worth a try; Randy, can you give it a quick go?
>>
>> Yes, that fixes it for me.  Thanks.
> 
> Wait!  I forgot to unpatch demux.h.  I'll test again now

OK, still works for me.

> 
 or adding:

.. -*- coding: utf-8; mode: rst -*-

 as the first line on the *.rst file that include the kernel-doc 
 directive would solve the issue.
>>>
>>> I guess I don't see how that would help, instead.  Emacs reads that line,
>>> but it's not involved in the problem.
>>>
>>> I wish I could reproduce this, then we could see what in that massive
>>> try..except block in kerneldoc.py is throwing the exception.  Putting in
>>> an explicit decode call might be enough to make the problem go away.
>>
>>
>>
> 
> 


-- 
~Randy

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:   Thu Aug 31 05:00:16 CEST 2017
media-tree git hash:9a45bf28bc39ff6ed45a008f7201289c8e9e60a6
media_build git hash:   96c1c79a9847387da3e8f51c1230b3118eed3ea6
v4l-utils git hash: 3296adfa7fa169111bf37c041c0ca70ac8506054
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.12.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: 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.26-i686: ERRORS
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: 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.26-x86_64: ERRORS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html