cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sat Feb 24 05:00:16 CET 2018
media-tree git hash:a7bc5773cd166032e35e343dfb6067a93d8402d1
media_build git hash:   a9ea3d056e5ce50d37dd6129126f776c3a8ec2d7
v4l-utils git hash: ef45319c1686088a46325db4dbfaffcdbcacf862
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.0-3994-g45eb2282
smatch version: v0.5.0-3994-g45eb2282
host hardware:  x86_64
host os:4.14.0-3-amd64

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-arm64: 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: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.98-i686: WARNINGS
linux-3.2.98-x86_64: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.53-i686: WARNINGS
linux-3.16.53-x86_64: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.93-i686: WARNINGS
linux-3.18.93-x86_64: WARNINGS
linux-3.19-i686: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.49-i686: WARNINGS
linux-4.1.49-x86_64: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.115-i686: OK
linux-4.4.115-x86_64: OK
linux-4.5.7-i686: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-i686: OK
linux-4.7.5-x86_64: WARNINGS
linux-4.8-i686: OK
linux-4.8-x86_64: WARNINGS
linux-4.9.80-i686: OK
linux-4.9.80-x86_64: OK
linux-4.10.14-i686: OK
linux-4.10.14-x86_64: WARNINGS
linux-4.11-i686: OK
linux-4.11-x86_64: WARNINGS
linux-4.12.1-i686: OK
linux-4.12.1-x86_64: WARNINGS
linux-4.13-i686: OK
linux-4.13-x86_64: OK
linux-4.14.17-i686: OK
linux-4.14.17-x86_64: OK
linux-4.15.2-i686: OK
linux-4.15.2-x86_64: OK
linux-4.16-rc1-i686: OK
linux-4.16-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: pinnacle 300i driver crashed after first device access

[Devin Heitmueller]

On Fri, Feb 23, 2018 at 2:37 PM, Devin Heitmueller
 wrote:
> On Fri, Feb 23, 2018 at 2:30 PM, Federico Allegretti
>  wrote:
>> i noticed that my pinnacle 300i could accept full resolution settings:
>> v4l2-ctl --set-fmt-video=width=720,height=576
>>
>> only the first time the command is fired.
>>
>> after that, evey time i try to set that resolution with the same
>> command, i get instead only the half vertical resolution:
>> v4l2-ctl --get-fmt-video
>> Format Video Capture:
>> Width/Height  : 720/288
>> Pixel Format  : 'YU12'
>> Field : Bottom
>> Bytes per Line: 720
>> Size Image: 311040
>> Colorspace: SMPTE 170M
>> Transfer Function : Default
>> YCbCr/HSV Encoding: Default
>> Quantization  : Default
>> Flags :

Also, looks like the field format is set to bottom, which would
explain why you're only getting half the lines.  You probably need to
set the field type to interlaced in your --set-fmt-video arguments
(although I don't have the exact syntax right in front of me).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: pinnacle 300i driver crashed after first device access

[Devin Heitmueller]

On Fri, Feb 23, 2018 at 2:30 PM, Federico Allegretti
 wrote:
> i noticed that my pinnacle 300i could accept full resolution settings:
> v4l2-ctl --set-fmt-video=width=720,height=576
>
> only the first time the command is fired.
>
> after that, evey time i try to set that resolution with the same
> command, i get instead only the half vertical resolution:
> v4l2-ctl --get-fmt-video
> Format Video Capture:
> Width/Height  : 720/288
> Pixel Format  : 'YU12'
> Field : Bottom
> Bytes per Line: 720
> Size Image: 311040
> Colorspace: SMPTE 170M
> Transfer Function : Default
> YCbCr/HSV Encoding: Default
> Quantization  : Default
> Flags :

Did you set the video standard?  All sorts of bad things could happen
if you set the format to 720x576 but the standard is still set to
NTSC.

To get the standards supported, you can run:

v4l2-ctl --list-standards

And then set the standard with "v4l2-ctl -s".  Do this before setting
the format.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

pinnacle 300i driver crashed after first device access

[Federico Allegretti]

i noticed that my pinnacle 300i could accept full resolution settings:
v4l2-ctl --set-fmt-video=width=720,height=576

only the first time the command is fired.

after that, evey time i try to set that resolution with the same
command, i get instead only the half vertical resolution:
v4l2-ctl --get-fmt-video
Format Video Capture:
Width/Height  : 720/288
Pixel Format  : 'YU12'
Field : Bottom
Bytes per Line: 720
Size Image: 311040
Colorspace: SMPTE 170M
Transfer Function : Default
YCbCr/HSV Encoding: Default
Quantization  : Default
Flags :

I noticed that behaviour when streaming with ffmpeg:

ffmpeg -re -f video4linux2 -i /dev/video0 -f pulse -ar 44100  -strict
experimental -acodec aac -ab 56k -vcodec libx264 -vb 452k -profile:v
high -level 40 -g 100 -f flv
"rtmp://vps222134.ovh.net:8081/publish/first?passsegretapervideostreaming"

first time i get audio and video full frame and no problems.
second time instead ffmpeg drops a lot of frames and fires warnings:

" ... Thread message queue blocking; consider raising the
thread_queue_size option (current value: 8) ..."
-- 
Open TV Architecture project: http://sourceforge.net/projects/otva/

Messagenet VOIP: 5338759

YouTube Channel: v1p3r's lab

VIMEO HD videos: http://www.vimeo.com/user1912745/videos

Re: [PATCH] media: ttpci/ttusb: add extra parameter to filter callbacks

[Mauro Carvalho Chehab]

Em Fri, 23 Feb 2018 19:52:48 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Friday, 23 February 2018 18:43:48 EET Mauro Carvalho Chehab wrote:
> > The filter callbaks now have an optional extra argument,
> > meant to allow reporting statistics to userspace via mmap.
> > 
> > Set those to NULL, in order to avoid those build errors:
> >   + drivers/media/pci/ttpci/av7110.c: error: too few arguments to function
> > 'dvbdmxfilter->feed->cb.sec':  => 325:10 +
> > drivers/media/pci/ttpci/av7110.c: error: too few arguments to function
> > 'dvbdmxfilter->feed->cb.ts':  => 332:11 +
> > drivers/media/pci/ttpci/av7110_av.c: error: too few arguments to function
> > 'feed->cb.ts':  => 817:3
> >   
> 
> I think this misses a Fixes: line. Apart from that it looks good to me.
> 
> With the Fixes: line,
> 
> Acked-by: Laurent Pinchart 

Thanks for review.

While not too late, I actually decided in favor of merging it with the
original patch, in order to avoid git bisect issues, as the other patch
was applied today on my fixes branch.

Regards,
Mauro

Re: [PATCH 01/13] media: v4l2-fwnode: Let parse_endpoint callback decide if no remote is error

[Steve Longerbeam]

Hi all,


On 02/23/2018 03:16 AM, Philipp Zabel wrote:

Hi Laurent,

On Fri, 2018-02-23 at 12:05 +0200, Laurent Pinchart wrote:

Hi Philipp,

On Friday, 23 February 2018 11:56:52 EET Philipp Zabel wrote:

On Fri, 2018-02-23 at 11:29 +0200, Laurent Pinchart wrote:

On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:

For some subdevices, a fwnode endpoint that has no connection to a
remote endpoint may not be an error. Let the parse_endpoint callback

make that decision in v4l2_async_notifier_fwnode_parse_endpoint(). If

the callback indicates that is not an error, skip adding the asd to the
notifier and return 0.

For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
(omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
unavailable remote fwnodes to maintain the previous behavior.

I'm not sure this should be a per-driver decision.

Generally speaking, if an endpoint node has no remote-endpoint property,
the endpoint node is not needed. I've always considered such an endpoint
node as invalid. The OF graphs DT bindings are however not clear on this
subject.

Documentation/devicetree/bindings/graph.txt says:

   Each endpoint should contain a 'remote-endpoint' phandle property
   that points to the corresponding endpoint in the port of the remote
   device.

("should", not "must").

The DT bindings documentation has historically used "should" to mean "must" in
many places :-( That was a big mistake.

Maybe I could have worded that better? The intention was to let "should"
be read as a strong suggestion, like "it is recommended", but not as a
requirement.


Later, the remote-node property explicitly lists the remote-endpoint
property as optional.

I've seen that too, and that's why I mentioned that the documentation isn't
clear on the subject.

Do you have a suggestion how to improve the documentation? I thought
listing the remote-endpoint property under a header called "Optional
endpoint properties" was pretty clear.


This could also be achieved by adding the endpoints in the board DT files. See
for instance the hdmi@fead node in arch/arm64/boot/dts/renesas/
r8a7795.dtsi and how it gets extended in arch/arm64/boot/dts/renesas/r8a7795-
salvator-x.dts. On the other hand, I also have empty endpoints in the
display@feb0 node of arch/arm64/boot/dts/renesas/r8a7795.dtsi.

Right, that would be possible.


Yes, I think this is doable in the specific case of the video mux device.

For example on the i.MX6 SabreAuto reference boards, only the parallel
bus mux input is connected to a device (to adv7180). The MIPI CSI-2 mux
input is left unconnected.

So probably the right approach is to not define any endpoint nodes under the
unused mux input ports.

The video-mux driver will need to be modified to enumerate ports, instead of
endpoints, to determine its number of mux inputs.

I will start looking into this change for v2.

The trick would be to do this while still remaining compatible with old
DTB's in the wild with unconnected endpoints. Unfortunately that might
not be possible, unless we were to let v4l2-core ignore empty endpoints.





I think we should first decide what we want to do going forward (allowing for
empty endpoints or not), clarify the documentation, and then update the code.
In any case I don't think it should be a per-device decision.

There are device trees in the wild that have those empty endpoints, so I
don't think retroactively declaring the remote-endpoint property
required is a good idea.

Is there any driver that currently benefits from throwing an error on
empty endpoints in any way? I'd prefer to just let the core ignore empty
endpoints for all drivers.


I tend to agree that, given the fuzziness of the DT binding docs regarding
unconnected endpoints, v4l2-core should ignore them.

In v2 I can modify this patch to ignore empty endpoints without error and
continue with endpoint parsing rather than pass the empty endpoint to the
caller's parse_endpoint callback.

Or this patch can be dropped altogether. It won't be needed for i.MX6 after
making the change described above, but again if this patch is dropped it 
will

break b/w compatibility with old i.MX6 DTB's.


Steve

Re: [PATCH] media: ttpci/ttusb: add extra parameter to filter callbacks

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Friday, 23 February 2018 18:43:48 EET Mauro Carvalho Chehab wrote:
> The filter callbaks now have an optional extra argument,
> meant to allow reporting statistics to userspace via mmap.
> 
> Set those to NULL, in order to avoid those build errors:
>   + drivers/media/pci/ttpci/av7110.c: error: too few arguments to function
> 'dvbdmxfilter->feed->cb.sec':  => 325:10 +
> drivers/media/pci/ttpci/av7110.c: error: too few arguments to function
> 'dvbdmxfilter->feed->cb.ts':  => 332:11 +
> drivers/media/pci/ttpci/av7110_av.c: error: too few arguments to function
> 'feed->cb.ts':  => 817:3
> 

I think this misses a Fixes: line. Apart from that it looks good to me.

With the Fixes: line,

Acked-by: Laurent Pinchart 

> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/pci/ttpci/av7110.c|  5 +++--
>  drivers/media/pci/ttpci/av7110_av.c |  6 +++---
>  drivers/media/usb/ttusb-dec/ttusb_dec.c | 10 +-
>  3 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/media/pci/ttpci/av7110.c
> b/drivers/media/pci/ttpci/av7110.c index dc8e577b2f74..d6816effb878 100644
> --- a/drivers/media/pci/ttpci/av7110.c
> +++ b/drivers/media/pci/ttpci/av7110.c
> @@ -324,14 +324,15 @@ static int DvbDmxFilterCallback(u8 *buffer1, size_t
> buffer1_len, }
>   return dvbdmxfilter->feed->cb.sec(buffer1, buffer1_len,
> buffer2, buffer2_len,
> -   >filter);
> +   >filter, NULL);
>   case DMX_TYPE_TS:
>   if (!(dvbdmxfilter->feed->ts_type & TS_PACKET))
>   return 0;
>   if (dvbdmxfilter->feed->ts_type & TS_PAYLOAD_ONLY)
>   return dvbdmxfilter->feed->cb.ts(buffer1, buffer1_len,
>buffer2, buffer2_len,
> -  
> >feed->feed.ts);
> +  
> >feed->feed.ts,
> +  NULL);
>   else
>   av7110_p2t_write(buffer1, buffer1_len,
>dvbdmxfilter->feed->pid,
> diff --git a/drivers/media/pci/ttpci/av7110_av.c
> b/drivers/media/pci/ttpci/av7110_av.c index 4daba76ec240..ef1bc17cdc4d
> 100644
> --- a/drivers/media/pci/ttpci/av7110_av.c
> +++ b/drivers/media/pci/ttpci/av7110_av.c
> @@ -99,7 +99,7 @@ int av7110_record_cb(struct dvb_filter_pes2ts *p2t, u8
> *buf, size_t len) buf[4] = buf[5] = 0;
>   if (dvbdmxfeed->ts_type & TS_PAYLOAD_ONLY)
>   return dvbdmxfeed->cb.ts(buf, len, NULL, 0,
> -  >feed.ts);
> +  >feed.ts, NULL);
>   else
>   return dvb_filter_pes2ts(p2t, buf, len, 1);
>  }
> @@ -109,7 +109,7 @@ static int dvb_filter_pes2ts_cb(void *priv, unsigned
> char *data) struct dvb_demux_feed *dvbdmxfeed = (struct dvb_demux_feed *)
> priv;
> 
>   dvbdmxfeed->cb.ts(data, 188, NULL, 0,
> -   >feed.ts);
> +   >feed.ts, NULL);
>   return 0;
>  }
> 
> @@ -814,7 +814,7 @@ static void p_to_t(u8 const *buf, long int length, u16
> pid, u8 *counter, memcpy(obuf + l, buf + c, TS_SIZE - l);
>   c = length;
>   }
> - feed->cb.ts(obuf, 188, NULL, 0, >feed.ts);
> + feed->cb.ts(obuf, 188, NULL, 0, >feed.ts, NULL);
>   pes_start = 0;
>   }
>  }
> diff --git a/drivers/media/usb/ttusb-dec/ttusb_dec.c
> b/drivers/media/usb/ttusb-dec/ttusb_dec.c index a8900f5571f7..44ca66cb9b8f
> 100644
> --- a/drivers/media/usb/ttusb-dec/ttusb_dec.c
> +++ b/drivers/media/usb/ttusb-dec/ttusb_dec.c
> @@ -428,7 +428,7 @@ static int ttusb_dec_audio_pes2ts_cb(void *priv,
> unsigned char *data) struct ttusb_dec *dec = priv;
> 
>   dec->audio_filter->feed->cb.ts(data, 188, NULL, 0,
> ->audio_filter->feed->feed.ts);
> +>audio_filter->feed->feed.ts, NULL);
> 
>   return 0;
>  }
> @@ -438,7 +438,7 @@ static int ttusb_dec_video_pes2ts_cb(void *priv,
> unsigned char *data) struct ttusb_dec *dec = priv;
> 
>   dec->video_filter->feed->cb.ts(data, 188, NULL, 0,
> ->video_filter->feed->feed.ts);
> +>video_filter->feed->feed.ts, NULL);
> 
>   return 0;
>  }
> @@ -490,7 +490,7 @@ static void ttusb_dec_process_pva(struct ttusb_dec *dec,
> u8 *pva, int length)
> 
>   if (output_pva) {
>   dec->video_filter->feed->cb.ts(pva, length, NULL, 0,
> - >video_filter->feed->feed.ts);
> + >video_filter->feed->feed.ts, NULL);
>

[PATCH] media: ttpci/ttusb: add extra parameter to filter callbacks

[Mauro Carvalho Chehab]

The filter callbaks now have an optional extra argument,
meant to allow reporting statistics to userspace via mmap.

Set those to NULL, in order to avoid those build errors:
  + drivers/media/pci/ttpci/av7110.c: error: too few arguments to function 
'dvbdmxfilter->feed->cb.sec':  => 325:10
  + drivers/media/pci/ttpci/av7110.c: error: too few arguments to function 
'dvbdmxfilter->feed->cb.ts':  => 332:11
  + drivers/media/pci/ttpci/av7110_av.c: error: too few arguments to function 
'feed->cb.ts':  => 817:3

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/ttpci/av7110.c|  5 +++--
 drivers/media/pci/ttpci/av7110_av.c |  6 +++---
 drivers/media/usb/ttusb-dec/ttusb_dec.c | 10 +-
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/media/pci/ttpci/av7110.c b/drivers/media/pci/ttpci/av7110.c
index dc8e577b2f74..d6816effb878 100644
--- a/drivers/media/pci/ttpci/av7110.c
+++ b/drivers/media/pci/ttpci/av7110.c
@@ -324,14 +324,15 @@ static int DvbDmxFilterCallback(u8 *buffer1, size_t 
buffer1_len,
}
return dvbdmxfilter->feed->cb.sec(buffer1, buffer1_len,
  buffer2, buffer2_len,
- >filter);
+ >filter, NULL);
case DMX_TYPE_TS:
if (!(dvbdmxfilter->feed->ts_type & TS_PACKET))
return 0;
if (dvbdmxfilter->feed->ts_type & TS_PAYLOAD_ONLY)
return dvbdmxfilter->feed->cb.ts(buffer1, buffer1_len,
 buffer2, buffer2_len,
-
>feed->feed.ts);
+
>feed->feed.ts,
+NULL);
else
av7110_p2t_write(buffer1, buffer1_len,
 dvbdmxfilter->feed->pid,
diff --git a/drivers/media/pci/ttpci/av7110_av.c 
b/drivers/media/pci/ttpci/av7110_av.c
index 4daba76ec240..ef1bc17cdc4d 100644
--- a/drivers/media/pci/ttpci/av7110_av.c
+++ b/drivers/media/pci/ttpci/av7110_av.c
@@ -99,7 +99,7 @@ int av7110_record_cb(struct dvb_filter_pes2ts *p2t, u8 *buf, 
size_t len)
buf[4] = buf[5] = 0;
if (dvbdmxfeed->ts_type & TS_PAYLOAD_ONLY)
return dvbdmxfeed->cb.ts(buf, len, NULL, 0,
->feed.ts);
+>feed.ts, NULL);
else
return dvb_filter_pes2ts(p2t, buf, len, 1);
 }
@@ -109,7 +109,7 @@ static int dvb_filter_pes2ts_cb(void *priv, unsigned char 
*data)
struct dvb_demux_feed *dvbdmxfeed = (struct dvb_demux_feed *) priv;
 
dvbdmxfeed->cb.ts(data, 188, NULL, 0,
- >feed.ts);
+ >feed.ts, NULL);
return 0;
 }
 
@@ -814,7 +814,7 @@ static void p_to_t(u8 const *buf, long int length, u16 pid, 
u8 *counter,
memcpy(obuf + l, buf + c, TS_SIZE - l);
c = length;
}
-   feed->cb.ts(obuf, 188, NULL, 0, >feed.ts);
+   feed->cb.ts(obuf, 188, NULL, 0, >feed.ts, NULL);
pes_start = 0;
}
 }
diff --git a/drivers/media/usb/ttusb-dec/ttusb_dec.c 
b/drivers/media/usb/ttusb-dec/ttusb_dec.c
index a8900f5571f7..44ca66cb9b8f 100644
--- a/drivers/media/usb/ttusb-dec/ttusb_dec.c
+++ b/drivers/media/usb/ttusb-dec/ttusb_dec.c
@@ -428,7 +428,7 @@ static int ttusb_dec_audio_pes2ts_cb(void *priv, unsigned 
char *data)
struct ttusb_dec *dec = priv;
 
dec->audio_filter->feed->cb.ts(data, 188, NULL, 0,
-  >audio_filter->feed->feed.ts);
+  >audio_filter->feed->feed.ts, NULL);
 
return 0;
 }
@@ -438,7 +438,7 @@ static int ttusb_dec_video_pes2ts_cb(void *priv, unsigned 
char *data)
struct ttusb_dec *dec = priv;
 
dec->video_filter->feed->cb.ts(data, 188, NULL, 0,
-  >video_filter->feed->feed.ts);
+  >video_filter->feed->feed.ts, NULL);
 
return 0;
 }
@@ -490,7 +490,7 @@ static void ttusb_dec_process_pva(struct ttusb_dec *dec, u8 
*pva, int length)
 
if (output_pva) {
dec->video_filter->feed->cb.ts(pva, length, NULL, 0,
-   >video_filter->feed->feed.ts);
+   >video_filter->feed->feed.ts, NULL);
return;
}
 
@@ -551,7 +551,7 @@ static void ttusb_dec_process_pva(struct ttusb_dec *dec, u8 
*pva, int length)
case 0x02:  /* MainAudioStream */
if (output_pva) {

[v5 1/2] media: dw9807: Add dw9807 vcm driver

[Andy Yeh]

From: Alan Chiang 

DW9807 is a 10 bit DAC from Dongwoon, designed for linear
control of voice coil motor.

This driver creates a V4L2 subdevice and
provides control to set the desired focus.

Signed-off-by: Andy Yeh 
---
since v1:
- changed author.
since v2:
- addressed outstanding comments.
- enabled sequential write to update 2 registers in a single transaction.
since v3:
- addressed comments for v3.
- Remove redundant codes and declare some variables as constant variable.
- separate DT binding to another patch
sicne v4:
- sent patchset included DT binding with cover page

 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 320 +
 4 files changed, 338 insertions(+)
 create mode 100644 drivers/media/i2c/dw9807.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..a339bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4385,6 +4385,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/dw9714.c
 
+DONGWOON DW9807 LENS VOICE COIL DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/dw9807.c
+
 DOUBLETALK DRIVER
 M: "James R. Van Zandt" 
 L: blinux-l...@redhat.com
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..fd01842 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -325,6 +325,16 @@ config VIDEO_DW9714
  capability. This is designed for linear control of
  voice coil motors, controlled via I2C serial interface.
 
+config VIDEO_DW9807
+   tristate "DW9807 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9807 camera lens voice coil.
+ DW9807 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
 config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..1b62639 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
 obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
 obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
 obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
+obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
 obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
 obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
 obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c
new file mode 100644
index 000..95626e9
--- /dev/null
+++ b/drivers/media/i2c/dw9807.c
@@ -0,0 +1,320 @@
+// Copyright (C) 2018 Intel Corporation
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9807_NAME"dw9807"
+#define DW9807_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 DW9807_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
+ * number of control steps.
+ */
+#define DW9807_CTRL_STEPS  16
+#define DW9807_CTRL_DELAY_US   1000
+
+#define DW9807_CTL_ADDR0x02
+/*
+ * DW9807 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9807_MSB_ADDR0x03
+#define DW9807_LSB_ADDR0x04
+#define DW9807_STATUS_ADDR 0x05
+#define DW9807_MODE_ADDR   0x06
+#define DW9807_RESONANCE_ADDR  0x07
+
+#define MAX_RETRY  10
+
+struct dw9807_device {
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+static inline struct dw9807_device *sd_to_dw9807_vcm(struct v4l2_subdev 
*subdev)
+{
+   return container_of(subdev, struct dw9807_device, sd);
+}
+
+static int dw9807_i2c_check(struct i2c_client *client)
+{
+   const char status_addr = DW9807_STATUS_ADDR;
+   char status_result = 0x1;
+   int ret;
+
+   ret = i2c_master_send(client, (const char *)_addr, 
sizeof(status_addr));
+   if (ret != sizeof(status_addr)) {
+   dev_err(>dev, "I2C write STATUS address fail ret = 
%d\n",
+   ret);
+   return -EIO;
+   }
+
+   ret = i2c_master_recv(client, (char *)_result, 
sizeof(status_result));
+   if (ret != sizeof(status_result)) {
+  

[v5 2/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Andy Yeh]

From: Alan Chiang 

Dongwoon DW9807 is a voice coil lens driver.

Also add a vendor prefix for Dongwoon for one did not exist previously.

Signed-off-by: Andy Yeh 
---
 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
new file mode 100644
index 000..0a1a860
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
@@ -0,0 +1,9 @@
+Dongwoon Anatech DW9807 voice coil lens driver
+
+DW9807 is a 10-bit DAC with current sink capability. It is intended for
+controlling voice coil lenses.
+
+Mandatory properties:
+
+- compatible: "dongwoon,dw9807"
+- reg: I2C slave address
-- 
2.7.4

[v5 0/2] DW9807 DT binding and driver patches

[Andy Yeh]

Hi Sakari and Tomasz,

The two patches are the DT binding and driver for DW9807 VCM controller.

Alan Chiang (2):
  media: dw9807: Add dw9807 vcm driver
  media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

 .../bindings/media/i2c/dongwoon,dw9807.txt |   9 +
 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 320 +
 5 files changed, 347 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
 create mode 100644 drivers/media/i2c/dw9807.c

-- 
2.7.4

Re: [PATCH 1/2] media: ov2680: dt: Add bindings for OV2680

[Rui Miguel Silva]

Hi Sakari,
Thanks for the review.

On Thu 22 Feb 2018 at 10:59, Sakari Ailus wrote:

Hi Rui,

Thanks for the patchset.

Could you use "dt: bindings: " prefix in the subject?


Sure, no problem.



On Thu, Feb 22, 2018 at 10:23:37AM +, Rui Miguel Silva 
wrote:
Add device tree binding documentation for the OV5640 camera 
sensor.


CC: devicet...@vger.kernel.org
Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/i2c/ov2680.txt   | 34 
 ++

 1 file changed, 34 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/media/i2c/ov2680.txt


diff --git 
a/Documentation/devicetree/bindings/media/i2c/ov2680.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2680.txt

new file mode 100644
index ..f9dc63ce5044
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
@@ -0,0 +1,34 @@
+* Omnivision OV2680 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: should be "ovti,ov2680"
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+
+Optional Properties:
+- powerdown-gpios: reference to the GPIO connected to the 
powerdown pin,
+		 if any. This is an active high signal to the 
OV2680.

+
+The device node must contain one 'port' child node for its 
digital output


Please add that the port contains a single endpoint as well.


Ack.



+video port, in accordance with the video interface bindings 
defined in

+Documentation/devicetree/bindings/media/video-interfaces.txt.


Please list required and optional endpoint properties as well.


OK.

---
Cheers,
Rui




+
+Example:
+
+ {
+   ov2680: camera-sensor@36 {
+   compatible = "ovti,ov2680";
+   reg = <0x36>;
+   clocks = <>;
+   clock-names = "xvclk";
+   powerdown-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov2680_mipi_ep: endpoint {
+remote-endpoint = 
<_sensor_ep>;

+   clock-lanes = <0>;
+   data-lanes = <1>;
+   };
+   };
+   };
+};

Re: [PATCH 1/2] media: ov2680: dt: Add bindings for OV2680

[Rui Miguel Silva]

Hi Fabio,
On Thu 22 Feb 2018 at 11:31, Fabio Estevam wrote:
On Thu, Feb 22, 2018 at 7:23 AM, Rui Miguel Silva 
 wrote:
Add device tree binding documentation for the OV5640 camera 
sensor.


s/OV5640/OV2680


Thanks for notice this ;).

---
Cheers,
Rui

Re: [PATCH 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

[Rui Miguel Silva]

Hi Sakari,
Thanks for your review.

On Fri 23 Feb 2018 at 07:50, Sakari Ailus wrote:

Hi Rui,

On Thu, Feb 22, 2018 at 10:23:38AM +, Rui Miguel Silva 
wrote:

This patch adds V4L2 sub-device driver for OV2680 image sensor.
The OV2680 is a 1/5" CMOS color sensor from Omnivision.
Supports output format: 10-bit Raw RGB.
The OV2680 has a single lane MIPI interface.

The driver exposes following V4L2 controls:
- auto/manual exposure,
- exposure,
- auto/manual gain,
- gain,
- horizontal/vertical flip,
- test pattern menu.
Supported resolution are only: QUXGA, 720P, UXGA.

Signed-off-by: Rui Miguel Silva 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov2680.c | 1189 
 

 3 files changed, 1203 insertions(+)
 create mode 100644 drivers/media/i2c/ov2680.c

diff --git a/drivers/media/i2c/Kconfig 
b/drivers/media/i2c/Kconfig

index 9f18cd296841..089103d29171 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -586,6 +586,19 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV2680

+   tristate "OmniVision OV2680 sensor support"
+   depends on OF


I think you can drop OF dependency here.


Agree.



+	depends on GPIOLIB && VIDEO_V4L2 && I2C && 
VIDEO_V4L2_SUBDEV_API

+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   ---help---
+	  This is a Video4Linux2 sensor-level driver for the 
OmniVision

+ OV2680 camera sensor with a MIPI CSI-2 interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2680.
+
 config VIDEO_OV5640
tristate "OmniVision OV5640 sensor support"
depends on OF
diff --git a/drivers/media/i2c/Makefile 
b/drivers/media/i2c/Makefile

index c0f94cd8d56d..d0aba4d37b8d 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += 
sony-btf-mpx.o

 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
+obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
diff --git a/drivers/media/i2c/ov2680.c 
b/drivers/media/i2c/ov2680.c

new file mode 100644
index ..64c1c2b03f97
--- /dev/null
+++ b/drivers/media/i2c/ov2680.c
@@ -0,0 +1,1189 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Omnivision OV2680 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ *
+ * Based on OV5640 Sensor Driver
+ * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All 
Rights Reserved.

+ * Copyright (C) 2014-2017 Mentor Graphics Inc.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Do you need of_gpio.h?


Yeah, I need only to include the gpio/consumer.h for the
devm_gpiod_get_optional call.




+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Do you need all of these? At least v4l2-event.h and 
v4l2-image-sizes.h seem

redundant.


Agree, will clean up this includes.




+
+#define OV2680_XVCLK_MIN   600
+#define OV2680_XVCLK_MAX   2400
+
+#define OV2680_CHIP_ID_HIGH0x26
+#define OV2680_CHIP_ID_LOW 0x80
+
+#define OV2680_REG_STREAM_CTRL 0x0100
+#define OV2680_REG_SOFT_RESET  0x0103
+
+#define OV2680_REG_CHIP_ID_HIGH0x300a
+#define OV2680_REG_CHIP_ID_LOW 0x300b
+
+#define OV2680_REG_R_MANUAL0x3503
+#define OV2680_REG_GAIN_PK 0x350a
+#define OV2680_REG_EXPOSURE_PK_HIGH0x3500
+#define OV2680_REG_EXPOSURE_PK_MED 0x3501
+#define OV2680_REG_EXPOSURE_PK_LOW 0x3502
+#define OV2680_REG_TIMING_HTS  0x380c
+#define OV2680_REG_TIMING_VTS  0x380e
+#define OV2680_REG_FORMAT1 0x3820
+#define OV2680_REG_FORMAT2 0x3821
+
+#define OV2680_REG_ISP_CTRL00  0x5080
+
+enum ov2680_frame_rate {
+   OV2680_30_FPS,
+   OV2680_FRAMERATES_MAX,
+};
+
+static const int ov2680_framerates[] = {
+   [OV2680_30_FPS] = 30,
+};
+
+enum ov2680_mode_id {
+   OV2680_MODE_QUXGA_800_600,
+   OV2680_MODE_720P_1280_720,
+   OV2680_MODE_UXGA_1600_1200,
+   OV2680_MODE_MAX,
+};
+
+struct reg_value {
+   u16 reg_addr;
+   u8 val;
+};
+
+struct ov2680_mode_info {
+   const char *name;
+   enum ov2680_mode_id id;
+   u32 width;
+   u32 height;
+   const struct reg_value *reg_data;
+   u32 reg_data_size;
+};
+
+struct ov2680_ctrls {
+   struct v4l2_ctrl_handler handler;
+   struct {
+   struct v4l2_ctrl *auto_exp;
+   struct v4l2_ctrl *exposure;
+   };
+   struct {
+   struct v4l2_ctrl *auto_gain;
+   struct v4l2_ctrl 

Re: [PATCH v2 1/1] videobuf2: Add VIDEOBUF2_V4L2 Kconfig option for videobuf2 V4L2 part

[Hans Verkuil]

On 02/23/2018 09:29 AM, Sakari Ailus wrote:
> Videobuf2 is now separate from V4L2 and can be now built without it, at
> least in principle --- enabling videobuf2 in kernel configuration attempts
> to compile videobuf2-v4l2.c but that will fail if CONFIG_VIDEO_V4L2 isn't
> enabled.
> 
> Solve this by adding a separate Kconfig option for videobuf2-v4l2 and make
> it a separate module as well. This means that drivers now need to choose
> both the appropriate videobuf2 memory type
> (VIDEOBUF2_{VMALLOC,DMA_CONTIG,DMA_SG}) and VIDEOBUF2_V4L2 if they need
> both.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
> Hi Mauro,
> 
> I'm proposing to merge this as it fixes build errors. We can later in
> rework the Kconfig options; the rework isn't related to fixing the build
> errors in general but rather is a change in the approach used to manage
> dependencies. Let's discuss that on #v4l.
> 
> since v1:
> 
> - Select VIDEOBUF2_V4L2 if both VIDEO_V4L2 and VIDEOBUF2_CORE are
>   selected. This way the patch no longer requires changing Kconfig entries
>   for effectively all drivers. In certain rare configurations (V4L2 and
>   VIDEOBUF2 are enabled but no V4L2 driver uses VIDEOBUF2) VIDEOBUF2_V4L2
>   could be enabled without it being needed. This is not really an issue
>   though.
> 
>  drivers/media/common/videobuf2/Kconfig  | 3 +++
>  drivers/media/common/videobuf2/Makefile | 3 ++-
>  drivers/media/v4l2-core/Kconfig | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/common/videobuf2/Kconfig 
> b/drivers/media/common/videobuf2/Kconfig
> index 5df05250de94..17c32ea58395 100644
> --- a/drivers/media/common/videobuf2/Kconfig
> +++ b/drivers/media/common/videobuf2/Kconfig
> @@ -3,6 +3,9 @@ config VIDEOBUF2_CORE
>   select DMA_SHARED_BUFFER
>   tristate
>  
> +config VIDEOBUF2_V4L2
> + tristate
> +
>  config VIDEOBUF2_MEMOPS
>   tristate
>   select FRAME_VECTOR
> diff --git a/drivers/media/common/videobuf2/Makefile 
> b/drivers/media/common/videobuf2/Makefile
> index 19de5ccda20b..7e27bdd44dcc 100644
> --- a/drivers/media/common/videobuf2/Makefile
> +++ b/drivers/media/common/videobuf2/Makefile
> @@ -1,5 +1,6 @@
>  
> -obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o videobuf2-v4l2.o
> +obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
> +obj-$(CONFIG_VIDEOBUF2_V4L2) += videobuf2-v4l2.o
>  obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
>  obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
>  obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
> diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
> index bf52fbd07aed..8e37e7c5e0f7 100644
> --- a/drivers/media/v4l2-core/Kconfig
> +++ b/drivers/media/v4l2-core/Kconfig
> @@ -7,6 +7,7 @@ config VIDEO_V4L2
>   tristate
>   depends on (I2C || I2C=n) && VIDEO_DEV
>   select RATIONAL
> + select VIDEOBUF2_V4L2 if VIDEOBUF2_CORE
>   default (I2C || I2C=n) && VIDEO_DEV
>  
>  config VIDEO_ADV_DEBUG
> 

[linuxtv-media:fixes 10/11] drivers/media/pci/ttpci/av7110_av.c:817:28: sparse: not enough arguments for function ts

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git fixes
head:   0e0751a4b9ee82ff086472ab4e81ee693fbe091a
commit: a3938f1b749cbedf47c4cb6af08f1c29e9418007 [10/11] media: dvb: update 
buffer mmaped flags and frame counter
reproduce:
# apt-get install sparse
git checkout a3938f1b749cbedf47c4cb6af08f1c29e9418007
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/media/pci/ttpci/av7110_av.c:817:28: sparse: not enough arguments for 
>> function ts
   drivers/media/pci/ttpci/av7110_av.c:101:41: sparse: not enough arguments for 
function ts
   drivers/media/pci/ttpci/av7110_av.c:111:26: sparse: not enough arguments for 
function ts
   drivers/media/pci/ttpci/av7110_av.c: In function 'av7110_record_cb':
   drivers/media/pci/ttpci/av7110_av.c:101:10: error: too few arguments to 
function 'dvbdmxfeed->cb.ts'
return dvbdmxfeed->cb.ts(buf, len, NULL, 0,
^~
   drivers/media/pci/ttpci/av7110_av.c: In function 'dvb_filter_pes2ts_cb':
   drivers/media/pci/ttpci/av7110_av.c:111:2: error: too few arguments to 
function 'dvbdmxfeed->cb.ts'
dvbdmxfeed->cb.ts(data, 188, NULL, 0,
^~
   drivers/media/pci/ttpci/av7110_av.c: In function 'p_to_t':
   drivers/media/pci/ttpci/av7110_av.c:817:3: error: too few arguments to 
function 'feed->cb.ts'
feed->cb.ts(obuf, 188, NULL, 0, >feed.ts);
^~~~
   drivers/media/pci/ttpci/av7110_av.c: In function 'av7110_record_cb':
   drivers/media/pci/ttpci/av7110_av.c:105:1: warning: control reaches end of 
non-void function
}
^
--
>> drivers/media/pci/ttpci/av7110.c:325:50: sparse: not enough arguments for 
>> function sec
>> drivers/media/pci/ttpci/av7110.c:332:57: sparse: not enough arguments for 
>> function ts
   drivers/media/pci/ttpci/av7110.c: In function 'DvbDmxFilterCallback':
   drivers/media/pci/ttpci/av7110.c:325:10: error: too few arguments to 
function 'dvbdmxfilter->feed->cb.sec'
return dvbdmxfilter->feed->cb.sec(buffer1, buffer1_len,
^~~~
   drivers/media/pci/ttpci/av7110.c:332:11: error: too few arguments to 
function 'dvbdmxfilter->feed->cb.ts'
return dvbdmxfilter->feed->cb.ts(buffer1, buffer1_len,
^~~~

vim +817 drivers/media/pci/ttpci/av7110_av.c

^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
773  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
774  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
775  static void p_to_t(u8 const *buf, long int length, u16 pid, u8 *counter,
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
776 struct dvb_demux_feed *feed)
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
777  {
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
778  int l, pes_start;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
779  u8 obuf[TS_SIZE];
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
780  long c = 0;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
781  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
782  pes_start = 0;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
783  if (length > 3 &&
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
784   buf[0] == 0x00 && buf[1] == 0x00 && buf[2] == 0x01)
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
785  switch (buf[3]) {
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
786  case PROG_STREAM_MAP:
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
787  case PRIVATE_STREAM2:
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
788  case PROG_STREAM_DIR:
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
789  case ECM_STREAM :
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
790  case EMM_STREAM :
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
791  case PADDING_STREAM :
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
792  case DSM_CC_STREAM  :
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
793  case ISO13522_STREAM:
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
794  case PRIVATE_STREAM1:
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
795  case AUDIO_STREAM_S ... AUDIO_STREAM_E:
^1da177e 

[PATCH] media: i2c: TDA1997x: add CONFIG_SND dependency

[Arnd Bergmann]

Without CONFIG_SND, we get a link error:

ERROR: "snd_soc_register_codec" [drivers/media/i2c/tda1997x.ko] undefined!
ERROR: "snd_soc_unregister_codec" [drivers/media/i2c/tda1997x.ko] undefined!
ERROR: "snd_pcm_hw_constraint_minmax" [drivers/media/i2c/tda1997x.ko] undefined!

This adds the same Kconfig dependency that we have in other
media drivers, using 'select SND_PCM' to ensure that we have
can call snd_pcm_hw_constraint_minmax, while depending on
CONFIG_SND_SOC for registering the codec.

Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 94e32d75d632..a44e8c36f13c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -59,6 +59,8 @@ config VIDEO_TDA9840
 config VIDEO_TDA1997X
tristate "NXP TDA1997x HDMI receiver"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   depends on SND_SOC
+   select SND_PCM
---help---
  V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
 
-- 
2.9.0

Re: [PATCH 01/13] media: v4l2-fwnode: Let parse_endpoint callback decide if no remote is error

[Sakari Ailus]

Hi Philipp,

On Fri, Feb 23, 2018 at 12:16:17PM +0100, Philipp Zabel wrote:
> Hi Laurent,
> 
> On Fri, 2018-02-23 at 12:05 +0200, Laurent Pinchart wrote:
> > Hi Philipp,
> > 
> > On Friday, 23 February 2018 11:56:52 EET Philipp Zabel wrote:
> > > On Fri, 2018-02-23 at 11:29 +0200, Laurent Pinchart wrote:
> > > > On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:
> > > > > For some subdevices, a fwnode endpoint that has no connection to a
> > > > > remote endpoint may not be an error. Let the parse_endpoint callback
> > > > 
> > > > make that decision in v4l2_async_notifier_fwnode_parse_endpoint(). If
> > > > > the callback indicates that is not an error, skip adding the asd to 
> > > > > the
> > > > > notifier and return 0.
> > > > > 
> > > > > For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
> > > > > (omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
> > > > > unavailable remote fwnodes to maintain the previous behavior.
> > > > 
> > > > I'm not sure this should be a per-driver decision.
> > > > 
> > > > Generally speaking, if an endpoint node has no remote-endpoint property,
> > > > the endpoint node is not needed. I've always considered such an endpoint
> > > > node as invalid. The OF graphs DT bindings are however not clear on this
> > > > subject.
> > > 
> > > Documentation/devicetree/bindings/graph.txt says:
> > > 
> > >   Each endpoint should contain a 'remote-endpoint' phandle property
> > >   that points to the corresponding endpoint in the port of the remote
> > >   device.
> > > 
> > > ("should", not "must").
> > 
> > The DT bindings documentation has historically used "should" to mean "must" 
> > in 
> > many places :-( That was a big mistake.
> 
> Maybe I could have worded that better? The intention was to let "should"
> be read as a strong suggestion, like "it is recommended", but not as a
> requirement.

Is there a reason for have an endpoint without a remote-endpoint property?

The problem with should (in general when it is used when the intention is
"shall") is that it lets the developer to write broken DT source that is
still conforming to the spec.

I don't have a strong preference to change should to shall in this
particular case now but I would have used "shall" to begin with.

> 
> > > Later, the remote-node property explicitly lists the remote-endpoint
> > > property as optional.
> > 
> > I've seen that too, and that's why I mentioned that the documentation isn't 
> > clear on the subject.
> 
> Do you have a suggestion how to improve the documentation? I thought
> listing the remote-endpoint property under a header called "Optional
> endpoint properties" was pretty clear.
> 
> > This could also be achieved by adding the endpoints in the board DT files. 
> > See 
> > for instance the hdmi@fead node in arch/arm64/boot/dts/renesas/
> > r8a7795.dtsi and how it gets extended in 
> > arch/arm64/boot/dts/renesas/r8a7795-
> > salvator-x.dts. On the other hand, I also have empty endpoints in the 
> > display@feb0 node of arch/arm64/boot/dts/renesas/r8a7795.dtsi.
> 
> Right, that would be possible.
> 
> > I think we should first decide what we want to do going forward (allowing 
> > for 
> > empty endpoints or not), clarify the documentation, and then update the 
> > code. 
> > In any case I don't think it should be a per-device decision.
> 
> There are device trees in the wild that have those empty endpoints, so I
> don't think retroactively declaring the remote-endpoint property
> required is a good idea.

You could IMO, but the kernel (and existing drivers) would still need to
work with DT binaries without those bits. And leave comments in the code
why it's there.

> 
> Is there any driver that currently benefits from throwing an error on
> empty endpoints in any way? I'd prefer to just let the core ignore empty
> endpoints for all drivers.

Not necessarily, but it's overhead in parsing the DT as well as in the
DT source and in the DT binary.

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH] media: fix build issues with vb2-trace

[Sakari Ailus]

On Fri, Feb 23, 2018 at 05:10:38AM -0500, Mauro Carvalho Chehab wrote:
> There was a trouble with vb2-trace: instead of being part of
> VB2 core, it was stored at V4L2 videodev. That was wrong,
> as it doesn't actually belong to V4L2 core.
> 
> Now that vb2 is not part of v4l2-core, its trace functions
> should be moved altogether. So, move it to its rightful
> place: at videobuf2-core.
> 
> That fixes those errors:
>   drivers/media/common/videobuf2/videobuf2-core.o: In function 
> `__read_once_size':
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_buf_queue'
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_buf_queue'
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_buf_done'
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_buf_done'
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_qbuf'
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_qbuf'
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_dqbuf'
>   ./include/linux/compiler.h:183: undefined reference to 
> `__tracepoint_vb2_dqbuf'
>   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): 
> undefined reference to `__tracepoint_vb2_buf_queue'
>   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x28): 
> undefined reference to `__tracepoint_vb2_buf_done'
>   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x40): 
> undefined reference to `__tracepoint_vb2_qbuf'
>   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x58): 
> undefined reference to `__tracepoint_vb2_dqbuf'
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Mauro Carvalho Chehab 

Thanks!

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 00/13] Remove metag architecture

[Arnd Bergmann]

On Fri, Feb 23, 2018 at 12:02 PM, James Hogan  wrote:
> On Fri, Feb 23, 2018 at 11:26:58AM +0100, Arnd Bergmann wrote:
>> On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
>> > So lets call it a day and drop the Meta architecture port from the
>> > kernel. RIP Meta.
>>
>> Since I brought up the architecture removal independently, I could
>> pick this up into a git tree that also has the removal of some of the
>> other architectures.
>>
>> I see your tree is part of linux-next, so you could also just put it
>> in there and send a pull request at the merge window if you prefer.
>>
>> The only real reason I see for a shared git tree would be to avoid
>> conflicts when we touch the same Kconfig files or #ifdefs in driver,
>> but Meta only appears in
>>
>> config FRAME_POINTER
>> bool "Compile the kernel with frame pointers"
>> depends on DEBUG_KERNEL && \
>> (CRIS || M68K || FRV || UML || \
>>  SUPERH || BLACKFIN || MN10300 || METAG) || \
>> ARCH_WANT_FRAME_POINTERS
>>
>> and
>>
>> include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
>> defined(CONFIG_METAG) || defined(CONFIG_IA64)
>>
>> so there is little risk.
>
> I'm happy to put v2 in linux-next now (only patch 4 has changed, I just
> sent an updated version), and send you a pull request early next week so
> you can take it from there. The patches can't be directly applied with
> git-am anyway thanks to the -D option to make them more concise.
>
> Sound okay?

Yes, sounds good, thanks!

   Arnd

Re: [PATCH v2] v4l: vsp1: Print the correct blending unit name in debug messages

[Kieran Bingham]

Hi Laurent,

Thankyou for the patch (update).

On 22/02/18 20:52, Laurent Pinchart wrote:
> The DRM pipelines can use either the BRU or the BRS for blending. Make
> sure the right name is used in debugging messages to avoid confusion.
> 
> Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 

> ---
> Changes since v1:
> 
> - Create a macro to get the right entity name instead of duplicating the
>   same code all over the driver
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index ac85942162c1..b8fee1834253 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -27,6 +27,7 @@
>  #include "vsp1_pipe.h"
>  #include "vsp1_rwpf.h"
>  
> +#define BRU_NAME(e)  (e)->type == VSP1_ENTITY_BRU ? "BRU" : "BRS"
>  
>  /* 
> -
>   * Interrupt Handling
> @@ -88,7 +89,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
>   struct v4l2_subdev_format format;
> - const char *bru_name;
>   unsigned long flags;
>   unsigned int i;
>   int ret;
> @@ -99,7 +99,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   drm_pipe = >drm->pipe[pipe_index];
>   pipe = _pipe->pipe;
>   bru = to_bru(>bru->subdev);
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
>  
>   if (!cfg) {
>   /*
> @@ -165,7 +164,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>   }
>  
>   format.pad = pipe->bru->source_pad;
> @@ -181,7 +180,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>  
>   format.pad = RWPF_PAD_SINK;
>   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
> @@ -473,9 +472,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, format.pad);
> + format.format.code, BRU_NAME(pipe->bru), format.pad);
>  
>   sel.pad = bru_input;
>   sel.target = V4L2_SEL_TGT_COMPOSE;
> @@ -486,10 +485,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev,
> - "%s: set selection (%u,%u)/%ux%u on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
>   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> - sel.pad);
> + BRU_NAME(pipe->bru), sel.pad);
>  
>   return 0;
>  }
> @@ -514,12 +512,9 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   struct vsp1_entity *entity;
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
> - const char *bru_name;
>   unsigned int i;
>   int ret;
>  
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
> -
>   /* Prepare the display list. */
>   dl = vsp1_dl_list_get(pipe->output->dlm);
>  
> @@ -570,7 +565,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   rpf->entity.sink_pad = i;
>  
>   dev_dbg(vsp1->dev, "%s: connecting RPF.%u to %s:%u\n",
> - __func__, rpf->entity.index, bru_name, i);
> + __func__, rpf->entity.index, BRU_NAME(pipe->bru), i);
>  
>   ret = vsp1_du_setup_rpf_pipe(vsp1, pipe, rpf, i);
>   if (ret < 0)
> 

[linuxtv-media:fixes 10/11] drivers/media/usb/ttusb-dec/ttusb_dec.c:430:2: error: too few arguments to function 'dec->audio_filter->feed->cb.ts'

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git fixes
head:   0e0751a4b9ee82ff086472ab4e81ee693fbe091a
commit: a3938f1b749cbedf47c4cb6af08f1c29e9418007 [10/11] media: dvb: update 
buffer mmaped flags and frame counter
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout a3938f1b749cbedf47c4cb6af08f1c29e9418007
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/usb/ttusb-dec/ttusb_dec.c: In function 
'ttusb_dec_audio_pes2ts_cb':
>> drivers/media/usb/ttusb-dec/ttusb_dec.c:430:2: error: too few arguments to 
>> function 'dec->audio_filter->feed->cb.ts'
 dec->audio_filter->feed->cb.ts(data, 188, NULL, 0,
 ^~~
   drivers/media/usb/ttusb-dec/ttusb_dec.c: In function 
'ttusb_dec_video_pes2ts_cb':
>> drivers/media/usb/ttusb-dec/ttusb_dec.c:440:2: error: too few arguments to 
>> function 'dec->video_filter->feed->cb.ts'
 dec->video_filter->feed->cb.ts(data, 188, NULL, 0,
 ^~~
   drivers/media/usb/ttusb-dec/ttusb_dec.c: In function 'ttusb_dec_process_pva':
   drivers/media/usb/ttusb-dec/ttusb_dec.c:492:4: error: too few arguments to 
function 'dec->video_filter->feed->cb.ts'
   dec->video_filter->feed->cb.ts(pva, length, NULL, 0,
   ^~~
   drivers/media/usb/ttusb-dec/ttusb_dec.c:553:4: error: too few arguments to 
function 'dec->audio_filter->feed->cb.ts'
   dec->audio_filter->feed->cb.ts(pva, length, NULL, 0,
   ^~~
   drivers/media/usb/ttusb-dec/ttusb_dec.c: In function 
'ttusb_dec_process_filter':
>> drivers/media/usb/ttusb-dec/ttusb_dec.c:591:3: error: too few arguments to 
>> function 'filter->feed->cb.sec'
  filter->feed->cb.sec([2], length - 2, NULL, 0,
  ^~

vim +430 drivers/media/usb/ttusb-dec/ttusb_dec.c

^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  425  
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  426  static int ttusb_dec_audio_pes2ts_cb(void *priv, unsigned char 
*data)
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  427  {
f961e71a0 drivers/media/dvb/ttusb-dec/ttusb_dec.c Alex Woods
2006-01-09  428 struct ttusb_dec *dec = priv;
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  429  
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16 @430 dec->audio_filter->feed->cb.ts(data, 188, NULL, 0,
2f684b239 drivers/media/usb/ttusb-dec/ttusb_dec.c Mauro Carvalho Chehab 
2015-10-06  431
>audio_filter->feed->feed.ts);
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  432  
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  433 return 0;
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  434  }
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  435  
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  436  static int ttusb_dec_video_pes2ts_cb(void *priv, unsigned char 
*data)
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  437  {
f961e71a0 drivers/media/dvb/ttusb-dec/ttusb_dec.c Alex Woods
2006-01-09  438 struct ttusb_dec *dec = priv;
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  439  
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16 @440 dec->video_filter->feed->cb.ts(data, 188, NULL, 0,
2f684b239 drivers/media/usb/ttusb-dec/ttusb_dec.c Mauro Carvalho Chehab 
2015-10-06  441
>video_filter->feed->feed.ts);
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  442  
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  443 return 0;
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  444  }
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  445  
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  446  static void ttusb_dec_set_pids(struct ttusb_dec *dec)
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  447  {
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  448 u8 b[] = { 0x00, 0x00, 0x00, 0x00,
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  4490x00, 0x00, 0xff, 0xff,
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  4500xff, 0xff, 0xff, 0xff };
^1da177e4 drivers/media/dvb/ttusb-dec/ttusb_dec.c Linus Torvalds
2005-04-16  451  
d4f979a9e 

[linuxtv-media:fixes 10/11] drivers/media/pci/ttpci/av7110_av.c:101:10: error: too few arguments to function 'dvbdmxfeed->cb.ts'

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git fixes
head:   0e0751a4b9ee82ff086472ab4e81ee693fbe091a
commit: a3938f1b749cbedf47c4cb6af08f1c29e9418007 [10/11] media: dvb: update 
buffer mmaped flags and frame counter
config: i386-randconfig-s0-201807 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout a3938f1b749cbedf47c4cb6af08f1c29e9418007
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/media/pci/ttpci/av7110_av.c: In function 'av7110_record_cb':
>> drivers/media/pci/ttpci/av7110_av.c:101:10: error: too few arguments to 
>> function 'dvbdmxfeed->cb.ts'
  return dvbdmxfeed->cb.ts(buf, len, NULL, 0,
 ^~
   drivers/media/pci/ttpci/av7110_av.c: In function 'dvb_filter_pes2ts_cb':
   drivers/media/pci/ttpci/av7110_av.c:111:2: error: too few arguments to 
function 'dvbdmxfeed->cb.ts'
 dvbdmxfeed->cb.ts(data, 188, NULL, 0,
 ^~
   drivers/media/pci/ttpci/av7110_av.c: In function 'p_to_t':
>> drivers/media/pci/ttpci/av7110_av.c:817:3: error: too few arguments to 
>> function 'feed->cb.ts'
  feed->cb.ts(obuf, 188, NULL, 0, >feed.ts);
  ^~~~
   drivers/media/pci/ttpci/av7110_av.c: In function 'av7110_record_cb':
>> drivers/media/pci/ttpci/av7110_av.c:105:1: warning: control reaches end of 
>> non-void function [-Wreturn-type]
}
^
--
   drivers/media/pci/ttpci/av7110.c: In function 'DvbDmxFilterCallback':
>> drivers/media/pci/ttpci/av7110.c:325:10: error: too few arguments to 
>> function 'dvbdmxfilter->feed->cb.sec'
  return dvbdmxfilter->feed->cb.sec(buffer1, buffer1_len,
 ^~~~
>> drivers/media/pci/ttpci/av7110.c:332:11: error: too few arguments to 
>> function 'dvbdmxfilter->feed->cb.ts'
   return dvbdmxfilter->feed->cb.ts(buffer1, buffer1_len,
  ^~~~

vim +101 drivers/media/pci/ttpci/av7110_av.c

^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
90  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
91  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
92  int av7110_record_cb(struct dvb_filter_pes2ts *p2t, u8 *buf, size_t len)
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
93  {
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
94  struct dvb_demux_feed *dvbdmxfeed = (struct dvb_demux_feed *) p2t->priv;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
95  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
96  if (!(dvbdmxfeed->ts_type & TS_PACKET))
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
97  return 0;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
98  if (buf[3] == 0xe0)  // video PES do not have a length in TS
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16   
99  buf[4] = buf[5] = 0;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
100  if (dvbdmxfeed->ts_type & TS_PAYLOAD_ONLY)
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16 
@101  return dvbdmxfeed->cb.ts(buf, len, NULL, 0,
2f684b23 drivers/media/pci/ttpci/av7110_av.c Mauro Carvalho Chehab 2015-10-06  
102   >feed.ts);
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
103  else
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
104  return dvb_filter_pes2ts(p2t, buf, len, 1);
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16 
@105  }
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
106  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
107  static int dvb_filter_pes2ts_cb(void *priv, unsigned char *data)
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
108  {
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
109  struct dvb_demux_feed *dvbdmxfeed = (struct dvb_demux_feed *) priv;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
110  
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16 
@111  dvbdmxfeed->cb.ts(data, 188, NULL, 0,
2f684b23 drivers/media/pci/ttpci/av7110_av.c Mauro Carvalho Chehab 2015-10-06  
112>feed.ts);
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
113  return 0;
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
114  }
^1da177e drivers/media/dvb/ttpci/av7110_av.c Linus Torvalds2005-04-16  
115  

:: The code at line 101 was first introduced by 

Re: [PATCH 01/13] media: v4l2-fwnode: Let parse_endpoint callback decide if no remote is error

[Philipp Zabel]

Hi Laurent,

On Fri, 2018-02-23 at 12:05 +0200, Laurent Pinchart wrote:
> Hi Philipp,
> 
> On Friday, 23 February 2018 11:56:52 EET Philipp Zabel wrote:
> > On Fri, 2018-02-23 at 11:29 +0200, Laurent Pinchart wrote:
> > > On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:
> > > > For some subdevices, a fwnode endpoint that has no connection to a
> > > > remote endpoint may not be an error. Let the parse_endpoint callback
> > > 
> > > make that decision in v4l2_async_notifier_fwnode_parse_endpoint(). If
> > > > the callback indicates that is not an error, skip adding the asd to the
> > > > notifier and return 0.
> > > > 
> > > > For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
> > > > (omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
> > > > unavailable remote fwnodes to maintain the previous behavior.
> > > 
> > > I'm not sure this should be a per-driver decision.
> > > 
> > > Generally speaking, if an endpoint node has no remote-endpoint property,
> > > the endpoint node is not needed. I've always considered such an endpoint
> > > node as invalid. The OF graphs DT bindings are however not clear on this
> > > subject.
> > 
> > Documentation/devicetree/bindings/graph.txt says:
> > 
> >   Each endpoint should contain a 'remote-endpoint' phandle property
> >   that points to the corresponding endpoint in the port of the remote
> >   device.
> > 
> > ("should", not "must").
> 
> The DT bindings documentation has historically used "should" to mean "must" 
> in 
> many places :-( That was a big mistake.

Maybe I could have worded that better? The intention was to let "should"
be read as a strong suggestion, like "it is recommended", but not as a
requirement.

> > Later, the remote-node property explicitly lists the remote-endpoint
> > property as optional.
> 
> I've seen that too, and that's why I mentioned that the documentation isn't 
> clear on the subject.

Do you have a suggestion how to improve the documentation? I thought
listing the remote-endpoint property under a header called "Optional
endpoint properties" was pretty clear.

> This could also be achieved by adding the endpoints in the board DT files. 
> See 
> for instance the hdmi@fead node in arch/arm64/boot/dts/renesas/
> r8a7795.dtsi and how it gets extended in arch/arm64/boot/dts/renesas/r8a7795-
> salvator-x.dts. On the other hand, I also have empty endpoints in the 
> display@feb0 node of arch/arm64/boot/dts/renesas/r8a7795.dtsi.

Right, that would be possible.

> I think we should first decide what we want to do going forward (allowing for 
> empty endpoints or not), clarify the documentation, and then update the code. 
> In any case I don't think it should be a per-device decision.

There are device trees in the wild that have those empty endpoints, so I
don't think retroactively declaring the remote-endpoint property
required is a good idea.

Is there any driver that currently benefits from throwing an error on
empty endpoints in any way? I'd prefer to just let the core ignore empty
endpoints for all drivers.

regards
Philipp

Re: [PATCH 00/13] Remove metag architecture

[James Hogan]

On Fri, Feb 23, 2018 at 11:26:58AM +0100, Arnd Bergmann wrote:
> On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
> > So lets call it a day and drop the Meta architecture port from the
> > kernel. RIP Meta.
> 
> Since I brought up the architecture removal independently, I could
> pick this up into a git tree that also has the removal of some of the
> other architectures.
> 
> I see your tree is part of linux-next, so you could also just put it
> in there and send a pull request at the merge window if you prefer.
> 
> The only real reason I see for a shared git tree would be to avoid
> conflicts when we touch the same Kconfig files or #ifdefs in driver,
> but Meta only appears in
> 
> config FRAME_POINTER
> bool "Compile the kernel with frame pointers"
> depends on DEBUG_KERNEL && \
> (CRIS || M68K || FRV || UML || \
>  SUPERH || BLACKFIN || MN10300 || METAG) || \
> ARCH_WANT_FRAME_POINTERS
> 
> and
> 
> include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
> defined(CONFIG_METAG) || defined(CONFIG_IA64)
> 
> so there is little risk.

I'm happy to put v2 in linux-next now (only patch 4 has changed, I just
sent an updated version), and send you a pull request early next week so
you can take it from there. The patches can't be directly applied with
git-am anyway thanks to the -D option to make them more concise.

Sound okay?

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH 00/13] Remove metag architecture

[Arnd Bergmann]

On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
> These patches remove the metag architecture and tightly dependent
> drivers from the kernel. With the 4.16 kernel the ancient gcc 4.2.4
> based metag toolchain we have been using is hitting compiler bugs, so
> now seems a good time to drop it altogether.
>
> Quoting from patch 1:
>
> The earliest Meta architecture port of Linux I have a record of was an
> import of a Meta port of Linux v2.4.1 in February 2004, which was worked
> on significantly over the next few years by Graham Whaley, Will Newton,
> Matt Fleming, myself and others.
>
> Eventually the port was merged into mainline in v3.9 in March 2013, not
> long after Imagination Technologies bought MIPS Technologies and shifted
> its CPU focus over to the MIPS architecture.
>
> As a result, though the port was maintained for a while, kept on life
> support for a while longer, and useful for testing a few specific
> drivers for which I don't have ready access to the equivalent MIPS
> hardware, it is now essentially dead with no users.
>
> It is also stuck using an out-of-tree toolchain based on GCC 4.2.4 which
> is no longer maintained, now struggles to build modern kernels due to
> toolchain bugs, and doesn't itself build with a modern GCC. The latest
> buildroot port is still using an old uClibc snapshot which is no longer
> served, and the latest uClibc doesn't build with GCC 4.2.4.
>
> So lets call it a day and drop the Meta architecture port from the
> kernel. RIP Meta.

Since I brought up the architecture removal independently, I could
pick this up into a git tree that also has the removal of some of the
other architectures.

I see your tree is part of linux-next, so you could also just put it
in there and send a pull request at the merge window if you prefer.

The only real reason I see for a shared git tree would be to avoid
conflicts when we touch the same Kconfig files or #ifdefs in driver,
but Meta only appears in

config FRAME_POINTER
bool "Compile the kernel with frame pointers"
depends on DEBUG_KERNEL && \
(CRIS || M68K || FRV || UML || \
 SUPERH || BLACKFIN || MN10300 || METAG) || \
ARCH_WANT_FRAME_POINTERS

and

include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
defined(CONFIG_METAG) || defined(CONFIG_IA64)

so there is little risk.

  Arnd

Re: [PATCH 01/13] media: v4l2-fwnode: Let parse_endpoint callback decide if no remote is error

[Sakari Ailus]

Hi guys,

On Fri, Feb 23, 2018 at 12:05:38PM +0200, Laurent Pinchart wrote:
> Hi Philipp,
> 
> On Friday, 23 February 2018 11:56:52 EET Philipp Zabel wrote:
> > On Fri, 2018-02-23 at 11:29 +0200, Laurent Pinchart wrote:
> > > On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:
> > >> For some subdevices, a fwnode endpoint that has no connection to a
> > >> remote endpoint may not be an error. Let the parse_endpoint callback
> > > make that decision in v4l2_async_notifier_fwnode_parse_endpoint(). If
> > >> the callback indicates that is not an error, skip adding the asd to the
> > >> notifier and return 0.
> > >> 
> > >> For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
> > >> (omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
> > >> unavailable remote fwnodes to maintain the previous behavior.
> > > 
> > > I'm not sure this should be a per-driver decision.
> > > 
> > > Generally speaking, if an endpoint node has no remote-endpoint property,
> > > the endpoint node is not needed. I've always considered such an endpoint
> > > node as invalid. The OF graphs DT bindings are however not clear on this
> > > subject.
> > 
> > Documentation/devicetree/bindings/graph.txt says:
> > 
> >   Each endpoint should contain a 'remote-endpoint' phandle property
> >   that points to the corresponding endpoint in the port of the remote
> >   device.
> > 
> > ("should", not "must").
> 
> The DT bindings documentation has historically used "should" to mean "must" 
> in 
> many places :-( That was a big mistake.

"Shall", not "must".

Indeed, there's hardly use for an endpoint without the remote-endpoint
property. My understanding is that such nodes might be best ignored, that's
been at least the practice in a lot of DT parsing code. There are arguments
both ways I guess.

What comes to this patch is that I'd rather not burden individual drivers
with such checks.

> 
> > Later, the remote-node property explicitly lists the remote-endpoint
> > property as optional.
> 
> I've seen that too, and that's why I mentioned that the documentation isn't 
> clear on the subject.
> 
> > > I have either failed to notice when they got merged, or they slowly
> > > evolved over time to contain contradictory information. In any case, I
> > > think we should decide on whether such a situation is valid or not from
> > > an OF graph point of view, and then always reject or always accept and
> > > ignore those endpoints.
> > 
> > We are currently using this on i.MX6 to provide empty labeled endpoints
> > in the dtsi files for board DT writers to link to, both for the display
> > output and video capture ports.
> > See for example the endpoints with the labels ipu1_di0_disp0 and
> > ipu1_csi0_mux_from_parallel_sensor in arch/arm/boot/dts/imx6q.dtsi.
> 
> This could also be achieved by adding the endpoints in the board DT files. 
> See 
> for instance the hdmi@fead node in arch/arm64/boot/dts/renesas/
> r8a7795.dtsi and how it gets extended in arch/arm64/boot/dts/renesas/r8a7795-
> salvator-x.dts. On the other hand, I also have empty endpoints in the 
> display@feb0 node of arch/arm64/boot/dts/renesas/r8a7795.dtsi.
> 
> I think we should first decide what we want to do going forward (allowing for 
> empty endpoints or not), clarify the documentation, and then update the code. 
> In any case I don't think it should be a per-device decision.

I don't think they should be allowed in the documentation. The
implementation could still simply ignore them.

Cc the devicetree list.

-- 
Regards,

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

[PATCH] media: fix build issues with vb2-trace

[Mauro Carvalho Chehab]

There was a trouble with vb2-trace: instead of being part of
VB2 core, it was stored at V4L2 videodev. That was wrong,
as it doesn't actually belong to V4L2 core.

Now that vb2 is not part of v4l2-core, its trace functions
should be moved altogether. So, move it to its rightful
place: at videobuf2-core.

That fixes those errors:
drivers/media/common/videobuf2/videobuf2-core.o: In function 
`__read_once_size':
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_queue'
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_queue'
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_done'
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_done'
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_qbuf'
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_qbuf'
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_dqbuf'
./include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_dqbuf'
drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): 
undefined reference to `__tracepoint_vb2_buf_queue'
drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x28): 
undefined reference to `__tracepoint_vb2_buf_done'
drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x40): 
undefined reference to `__tracepoint_vb2_qbuf'
drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x58): 
undefined reference to `__tracepoint_vb2_dqbuf'

Reported-by: kbuild test robot 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/common/videobuf2/Makefile   | 3 +++
 drivers/media/{v4l2-core => common/videobuf2}/vb2-trace.c | 0
 drivers/media/v4l2-core/Makefile  | 3 +--
 3 files changed, 4 insertions(+), 2 deletions(-)
 rename drivers/media/{v4l2-core => common/videobuf2}/vb2-trace.c (100%)

diff --git a/drivers/media/common/videobuf2/Makefile 
b/drivers/media/common/videobuf2/Makefile
index 7e27bdd44dcc..067badb1aaa7 100644
--- a/drivers/media/common/videobuf2/Makefile
+++ b/drivers/media/common/videobuf2/Makefile
@@ -6,3 +6,6 @@ obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
 obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
 obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
 obj-$(CONFIG_VIDEOBUF2_DVB) += videobuf2-dvb.o
+ifeq ($(CONFIG_TRACEPOINTS),y)
+  obj-$(CONFIG_VIDEOBUF2_CORE) += vb2-trace.o
+endif
diff --git a/drivers/media/v4l2-core/vb2-trace.c 
b/drivers/media/common/videobuf2/vb2-trace.c
similarity index 100%
rename from drivers/media/v4l2-core/vb2-trace.c
rename to drivers/media/common/videobuf2/vb2-trace.c
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 80de2cb9c476..7df54582e956 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -13,7 +13,7 @@ ifeq ($(CONFIG_COMPAT),y)
 endif
 obj-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o
 ifeq ($(CONFIG_TRACEPOINTS),y)
-  videodev-objs += vb2-trace.o v4l2-trace.o
+  videodev-objs += v4l2-trace.o
 endif
 videodev-$(CONFIG_MEDIA_CONTROLLER) += v4l2-mc.o
 
@@ -35,4 +35,3 @@ obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
 
 ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
 ccflags-y += -I$(srctree)/drivers/media/tuners
-
-- 
2.14.3

Re: [PATCH 01/13] media: v4l2-fwnode: Let parse_endpoint callback decide if no remote is error

[Laurent Pinchart]

Hi Philipp,

On Friday, 23 February 2018 11:56:52 EET Philipp Zabel wrote:
> On Fri, 2018-02-23 at 11:29 +0200, Laurent Pinchart wrote:
> > On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:
> >> For some subdevices, a fwnode endpoint that has no connection to a
> >> remote endpoint may not be an error. Let the parse_endpoint callback
> > make that decision in v4l2_async_notifier_fwnode_parse_endpoint(). If
> >> the callback indicates that is not an error, skip adding the asd to the
> >> notifier and return 0.
> >> 
> >> For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
> >> (omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
> >> unavailable remote fwnodes to maintain the previous behavior.
> > 
> > I'm not sure this should be a per-driver decision.
> > 
> > Generally speaking, if an endpoint node has no remote-endpoint property,
> > the endpoint node is not needed. I've always considered such an endpoint
> > node as invalid. The OF graphs DT bindings are however not clear on this
> > subject.
> 
> Documentation/devicetree/bindings/graph.txt says:
> 
>   Each endpoint should contain a 'remote-endpoint' phandle property
>   that points to the corresponding endpoint in the port of the remote
>   device.
> 
> ("should", not "must").

The DT bindings documentation has historically used "should" to mean "must" in 
many places :-( That was a big mistake.

> Later, the remote-node property explicitly lists the remote-endpoint
> property as optional.

I've seen that too, and that's why I mentioned that the documentation isn't 
clear on the subject.

> > I have either failed to notice when they got merged, or they slowly
> > evolved over time to contain contradictory information. In any case, I
> > think we should decide on whether such a situation is valid or not from
> > an OF graph point of view, and then always reject or always accept and
> > ignore those endpoints.
> 
> We are currently using this on i.MX6 to provide empty labeled endpoints
> in the dtsi files for board DT writers to link to, both for the display
> output and video capture ports.
> See for example the endpoints with the labels ipu1_di0_disp0 and
> ipu1_csi0_mux_from_parallel_sensor in arch/arm/boot/dts/imx6q.dtsi.

This could also be achieved by adding the endpoints in the board DT files. See 
for instance the hdmi@fead node in arch/arm64/boot/dts/renesas/
r8a7795.dtsi and how it gets extended in arch/arm64/boot/dts/renesas/r8a7795-
salvator-x.dts. On the other hand, I also have empty endpoints in the 
display@feb0 node of arch/arm64/boot/dts/renesas/r8a7795.dtsi.

I think we should first decide what we want to do going forward (allowing for 
empty endpoints or not), clarify the documentation, and then update the code. 
In any case I don't think it should be a per-device decision.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/13] media: v4l2-fwnode: Let parse_endpoint callback decide if no remote is error

[Philipp Zabel]

Hi Laurent,

On Fri, 2018-02-23 at 11:29 +0200, Laurent Pinchart wrote:
> Hi Steve,
> 
> Thank you for the patch.
> 
> On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:
> > For some subdevices, a fwnode endpoint that has no connection to a remote
> > endpoint may not be an error. Let the parse_endpoint callback make that
> > decision in v4l2_async_notifier_fwnode_parse_endpoint(). If the callback
> > indicates that is not an error, skip adding the asd to the notifier and
> > return 0.
> > 
> > For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
> > (omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
> > unavailable remote fwnodes to maintain the previous behavior.
> 
> I'm not sure this should be a per-driver decision.
> 
> Generally speaking, if an endpoint node has no remote-endpoint property, the 
> endpoint node is not needed. I've always considered such an endpoint node as 
> invalid. The OF graphs DT bindings are however not clear on this subject.

Documentation/devicetree/bindings/graph.txt says:

  Each endpoint should contain a 'remote-endpoint' phandle property
  that points to the corresponding endpoint in the port of the remote
  device.

("should", not "must"). Later, the remote-node property explicitly lists
the remote-endpoint property as optional.

> I have either failed to notice when they got merged, or they slowly evolved 
> over 
> time to contain contradictory information. In any case, I think we should 
> decide on whether such a situation is valid or not from an OF graph point of 
> view, and then always reject or always accept and ignore those endpoints.

We are currently using this on i.MX6 to provide empty labeled endpoints
in the dtsi files for board DT writers to link to, both for the display
output and video capture ports.
See for example the endpoints with the labels ipu1_di0_disp0 and
ipu1_csi0_mux_from_parallel_sensor in arch/arm/boot/dts/imx6q.dtsi.

regards
Philipp

[PATCH v1.2 1/5] v4l: common: Add a function to obtain best size from a list

[Sakari Ailus]

Add a function (as well as a helper macro) to obtain the best size in a
list of device specific sizes. This helps writing drivers as well as
aligns interface behaviour across drivers.

The struct in which this information is contained in is typically specific
to the driver, therefore the existing function v4l2_find_nearest_format()
does not address the need.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
since v1.1:

- Align argument order in __v4l2_find_nearest_size() function and its
  prototype. Align argument names across the function and the macro.

 drivers/media/v4l2-core/v4l2-common.c | 30 ++
 include/media/v4l2-common.h   | 34 ++
 2 files changed, 64 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-common.c 
b/drivers/media/v4l2-core/v4l2-common.c
index 96c1b31..9b65529 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -383,6 +383,36 @@ v4l2_find_nearest_format(const struct 
v4l2_frmsize_discrete *sizes,
 }
 EXPORT_SYMBOL_GPL(v4l2_find_nearest_format);
 
+const void *
+__v4l2_find_nearest_size(const void *array, size_t array_size,
+size_t entry_size, size_t width_offset,
+size_t height_offset, s32 width, s32 height)
+{
+   u32 error, min_error = U32_MAX;
+   const void *best = NULL;
+   unsigned int i;
+
+   if (!array)
+   return NULL;
+
+   for (i = 0; i < array_size; i++, array += entry_size) {
+   const u32 *entry_width = array + width_offset;
+   const u32 *entry_height = array + height_offset;
+
+   error = abs(*entry_width - width) + abs(*entry_height - height);
+   if (error > min_error)
+   continue;
+
+   min_error = error;
+   best = array;
+   if (!error)
+   break;
+   }
+
+   return best;
+}
+EXPORT_SYMBOL_GPL(__v4l2_find_nearest_size);
+
 void v4l2_get_timestamp(struct timeval *tv)
 {
struct timespec ts;
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index f3aa1d7..38947dc 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -333,6 +333,40 @@ v4l2_find_nearest_format(const struct 
v4l2_frmsize_discrete *sizes,
  s32 width, s32 height);
 
 /**
+ * v4l2_find_nearest_size - Find the nearest size among a discrete
+ * set of resolutions contained in an array of a driver specific struct.
+ *
+ * @array: a driver specific array of image sizes
+ * @array_size: the length of the driver specific array of image sizes
+ * @width_field: the name of the width field in the driver specific struct
+ * @height_field: the name of the height field in the driver specific struct
+ * @width: desired width.
+ * @height: desired height.
+ *
+ * Finds the closest resolution to minimize the width and height differences
+ * between what requested and the supported resolutions. The size of the width
+ * and height fields in the driver specific must equal to that of u32, i.e. 
four
+ * bytes.
+ *
+ * Returns the best match or NULL if the length of the array is zero.
+ */
+#define v4l2_find_nearest_size(array, array_size, width_field, height_field, \
+  width, height)   \
+   ({  \
+   BUILD_BUG_ON(sizeof((array)->width_field) != sizeof(u32) || \
+sizeof((array)->height_field) != sizeof(u32)); \
+   (typeof(&(*(array__v4l2_find_nearest_size(  \
+   (array), array_size, sizeof(*(array)),  \
+   offsetof(typeof(*(array)), width_field),\
+   offsetof(typeof(*(array)), height_field),   \
+   width, height); \
+   })
+const void *
+__v4l2_find_nearest_size(const void *array, size_t array_size,
+size_t entry_size, size_t width_offset,
+size_t height_offset, s32 width, s32 height);
+
+/**
  * v4l2_get_timestamp - helper routine to get a timestamp to be used when
  * filling streaming metadata. Internally, it uses ktime_get_ts(),
  * which is the recommended way to get it.
-- 
2.7.4

Re: [PATCH 01/13] media: v4l2-fwnode: Let parse_endpoint callback decide if no remote is error

[Laurent Pinchart]

Hi Steve,

Thank you for the patch.

On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:
> For some subdevices, a fwnode endpoint that has no connection to a remote
> endpoint may not be an error. Let the parse_endpoint callback make that
> decision in v4l2_async_notifier_fwnode_parse_endpoint(). If the callback
> indicates that is not an error, skip adding the asd to the notifier and
> return 0.
> 
> For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
> (omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
> unavailable remote fwnodes to maintain the previous behavior.

I'm not sure this should be a per-driver decision.

Generally speaking, if an endpoint node has no remote-endpoint property, the 
endpoint node is not needed. I've always considered such an endpoint node as 
invalid. The OF graphs DT bindings are however not clear on this subject. I 
have either failed to notice when they got merged, or they slowly evolved over 
time to contain contradictory information. In any case, I think we should 
decide on whether such a situation is valid or not from an OF graph point of 
view, and then always reject or always accept and ignore those endpoints.

> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-cio2.c| 3 +++
>  drivers/media/platform/omap3isp/isp.c   | 3 +++
>  drivers/media/platform/rcar-vin/rcar-core.c | 3 +++
>  drivers/media/v4l2-core/v4l2-fwnode.c   | 4 ++--
>  4 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c index 6cb..2323151 100644
> --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> @@ -1477,6 +1477,9 @@ static int cio2_fwnode_parse(struct device *dev,
>   struct sensor_async_subdev *s_asd =
>   container_of(asd, struct sensor_async_subdev, asd);
> 
> + if (!fwnode_device_is_available(asd->match.fwnode))
> + return -EINVAL;
> +
>   if (vep->bus_type != V4L2_MBUS_CSI2) {
>   dev_err(dev, "Only CSI2 bus type is currently supported\n");
>   return -EINVAL;
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 8eb000e..4a302f2 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2025,6 +2025,9 @@ static int isp_fwnode_parse(struct device *dev,
>   dev_dbg(dev, "parsing endpoint %pOF, interface %u\n",
>   to_of_node(vep->base.local_fwnode), vep->base.port);
> 
> + if (!fwnode_device_is_available(asd->match.fwnode))
> + return -EINVAL;
> +
>   switch (vep->base.port) {
>   case ISP_OF_PHY_PARALLEL:
>   buscfg->interface = ISP_INTERFACE_PARALLEL;
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index f1fc797..51bb8f1 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -149,6 +149,9 @@ static int rvin_digital_parse_v4l2(struct device *dev,
>   struct rvin_graph_entity *rvge =
>   container_of(asd, struct rvin_graph_entity, asd);
> 
> + if (!fwnode_device_is_available(asd->match.fwnode))
> + return -EINVAL;
> +
>   if (vep->base.port || vep->base.id)
>   return -ENOTCONN;
> 
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
> b/drivers/media/v4l2-core/v4l2-fwnode.c index d630640..446646b 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -361,7 +361,7 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
>   asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
>   asd->match.fwnode =
>   fwnode_graph_get_remote_port_parent(endpoint);
> - if (!asd->match.fwnode) {
> + if (!asd->match.fwnode && !parse_endpoint) {
>   dev_warn(dev, "bad remote port parent\n");
>   ret = -EINVAL;
>   goto out_err;
> @@ -384,7 +384,7 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
>"driver could not parse port@%u/endpoint@%u (%d)\n",
>vep->base.port, vep->base.id, ret);
>   v4l2_fwnode_endpoint_free(vep);
> - if (ret < 0)
> + if (ret < 0 || !asd->match.fwnode)
>   goto out_err;
> 
>   notifier->subdevs[notifier->num_subdevs] = asd;


-- 
Regards,

Laurent Pinchart

drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): undefined reference to `__tracepoint_vb2_buf_queue'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0f9da844d87796ac31b04e81ee95e155e9043132
commit: 7952be9b6ece3d3c4d61f9811d7e5a984580064a media: 
drivers/media/common/videobuf2: rename from videobuf
date:   4 weeks ago
config: x86_64-randconfig-s1-02231552 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 7952be9b6ece3d3c4d61f9811d7e5a984580064a
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/common/videobuf2/videobuf2-core.o: In function 
`__read_once_size':
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_queue'
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_queue'
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_done'
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_done'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_qbuf'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_qbuf'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_dqbuf'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_dqbuf'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): 
>> undefined reference to `__tracepoint_vb2_buf_queue'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x28): 
>> undefined reference to `__tracepoint_vb2_buf_done'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x40): 
>> undefined reference to `__tracepoint_vb2_qbuf'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x58): 
>> undefined reference to `__tracepoint_vb2_dqbuf'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_poll':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:678: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.c:685: undefined reference to 
`v4l2_event_pending'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_reqbufs':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:714: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_create_bufs':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:733: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_prepare_buf':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:759: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_querybuf':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:769: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_qbuf':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:778: undefined reference to 
`video_devdata'
   
drivers/media/common/videobuf2/videobuf2-v4l2.o:drivers/media/common/videobuf2/videobuf2-v4l2.c:788:
 more undefined references to `video_devdata' follow
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`_vb2_fop_release':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:848: undefined reference to 
`v4l2_fh_release'

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


.config.gz
Description: application/gzip

[PATCH] media: imx274: fix typo in error message

[Luca Ceresoli]

Signed-off-by: Luca Ceresoli 
---
 drivers/media/i2c/imx274.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index 664e8acdf2a0..daec33f4196a 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -1426,7 +1426,7 @@ static int imx274_set_vflip(struct stimx274 *priv, int 
val)
 
err = imx274_write_reg(priv, IMX274_VFLIP_REG, val);
if (err) {
-   dev_err(>client->dev, "VFILP control error\n");
+   dev_err(>client->dev, "VFLIP control error\n");
return err;
}
 
-- 
2.7.4

Re: [PATCH v2 1/1] videobuf2: Add VIDEOBUF2_V4L2 Kconfig option for videobuf2 V4L2 part

[Laurent Pinchart]

Hi Sakari,

Thank you for the patch.

On Friday, 23 February 2018 10:29:46 EET Sakari Ailus wrote:
> Videobuf2 is now separate from V4L2 and can be now built without it, at
> least in principle --- enabling videobuf2 in kernel configuration attempts
> to compile videobuf2-v4l2.c but that will fail if CONFIG_VIDEO_V4L2 isn't
> enabled.
> 
> Solve this by adding a separate Kconfig option for videobuf2-v4l2 and make
> it a separate module as well. This means that drivers now need to choose
> both the appropriate videobuf2 memory type
> (VIDEOBUF2_{VMALLOC,DMA_CONTIG,DMA_SG}) and VIDEOBUF2_V4L2 if they need
> both.
> 
> Signed-off-by: Sakari Ailus 
> ---
> Hi Mauro,
> 
> I'm proposing to merge this as it fixes build errors. We can later in
> rework the Kconfig options; the rework isn't related to fixing the build
> errors in general but rather is a change in the approach used to manage
> dependencies. Let's discuss that on #v4l.
> 
> since v1:
> 
> - Select VIDEOBUF2_V4L2 if both VIDEO_V4L2 and VIDEOBUF2_CORE are
>   selected. This way the patch no longer requires changing Kconfig entries
>   for effectively all drivers. In certain rare configurations (V4L2 and
>   VIDEOBUF2 are enabled but no V4L2 driver uses VIDEOBUF2) VIDEOBUF2_V4L2
>   could be enabled without it being needed. This is not really an issue
>   though.
> 
>  drivers/media/common/videobuf2/Kconfig  | 3 +++
>  drivers/media/common/videobuf2/Makefile | 3 ++-
>  drivers/media/v4l2-core/Kconfig | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/common/videobuf2/Kconfig
> b/drivers/media/common/videobuf2/Kconfig index 5df05250de94..17c32ea58395
> 100644
> --- a/drivers/media/common/videobuf2/Kconfig
> +++ b/drivers/media/common/videobuf2/Kconfig
> @@ -3,6 +3,9 @@ config VIDEOBUF2_CORE
>   select DMA_SHARED_BUFFER
>   tristate
> 
> +config VIDEOBUF2_V4L2
> + tristate
> +
>  config VIDEOBUF2_MEMOPS
>   tristate
>   select FRAME_VECTOR
> diff --git a/drivers/media/common/videobuf2/Makefile
> b/drivers/media/common/videobuf2/Makefile index 19de5ccda20b..7e27bdd44dcc
> 100644
> --- a/drivers/media/common/videobuf2/Makefile
> +++ b/drivers/media/common/videobuf2/Makefile
> @@ -1,5 +1,6 @@
> 
> -obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o videobuf2-v4l2.o
> +obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
> +obj-$(CONFIG_VIDEOBUF2_V4L2) += videobuf2-v4l2.o
>  obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
>  obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
>  obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
> diff --git a/drivers/media/v4l2-core/Kconfig
> b/drivers/media/v4l2-core/Kconfig index bf52fbd07aed..8e37e7c5e0f7 100644
> --- a/drivers/media/v4l2-core/Kconfig
> +++ b/drivers/media/v4l2-core/Kconfig
> @@ -7,6 +7,7 @@ config VIDEO_V4L2
>   tristate
>   depends on (I2C || I2C=n) && VIDEO_DEV
>   select RATIONAL
> + select VIDEOBUF2_V4L2 if VIDEOBUF2_CORE
>   default (I2C || I2C=n) && VIDEO_DEV

I thought that if VIDEO_V4L2=y and VIDEOBUF2_CORE=m, this would set 
VIDEOBUF2_V4L2=y, but testing the patch proved me wrong.

Tested-by: Laurent Pinchart 
Reviewed-by: Laurent Pinchart 

> 
>  config VIDEO_ADV_DEBUG

-- 
Regards,

Laurent Pinchart

[PATCH v1.1 1/5] v4l: common: Add a function to obtain best size from a list

[Sakari Ailus]

Add a function (as well as a helper macro) to obtain the best size in a
list of device specific sizes. This helps writing drivers as well as
aligns interface behaviour across drivers.

The struct in which this information is contained in is typically specific
to the driver, therefore the existing function v4l2_find_nearest_format()
does not address the need.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
since v1:

- Fix KernelDoc for v4l2_find_nearest_size():

  * v4l2_find_nearest_size - Find the nearest size among a discrete
  * set of resolutions contained in an array of a driver specific struct.
  *
- * @sizes: a driver specific array of image sizes
+ * @array: a driver specific array of image sizes
+ * @array_size: the length of the driver specific array of image sizes
  * @width_field: the name of the width field in the driver specific struct
  * @height_field: the name of the height field in the driver specific struct
  * @width: desired width.


 drivers/media/v4l2-core/v4l2-common.c | 30 ++
 include/media/v4l2-common.h   | 34 ++
 2 files changed, 64 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-common.c 
b/drivers/media/v4l2-core/v4l2-common.c
index 96c1b31..7b892c9 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -383,6 +383,36 @@ v4l2_find_nearest_format(const struct 
v4l2_frmsize_discrete *sizes,
 }
 EXPORT_SYMBOL_GPL(v4l2_find_nearest_format);
 
+const void *
+__v4l2_find_nearest_size(const void *arr, size_t num_entries, size_t 
entry_size,
+size_t width_offset, size_t height_offset,
+s32 width, s32 height)
+{
+   u32 error, min_error = U32_MAX;
+   const void *best = NULL;
+   unsigned int i;
+
+   if (!arr)
+   return NULL;
+
+   for (i = 0; i < num_entries; i++, arr += entry_size) {
+   const u32 *entry_width = arr + width_offset;
+   const u32 *entry_height = arr + height_offset;
+
+   error = abs(*entry_width - width) + abs(*entry_height - height);
+   if (error > min_error)
+   continue;
+
+   min_error = error;
+   best = arr;
+   if (!error)
+   break;
+   }
+
+   return best;
+}
+EXPORT_SYMBOL_GPL(__v4l2_find_nearest_size);
+
 void v4l2_get_timestamp(struct timeval *tv)
 {
struct timespec ts;
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index f3aa1d7..4a8eaa6 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -333,6 +333,40 @@ v4l2_find_nearest_format(const struct 
v4l2_frmsize_discrete *sizes,
  s32 width, s32 height);
 
 /**
+ * v4l2_find_nearest_size - Find the nearest size among a discrete
+ * set of resolutions contained in an array of a driver specific struct.
+ *
+ * @array: a driver specific array of image sizes
+ * @array_size: the length of the driver specific array of image sizes
+ * @width_field: the name of the width field in the driver specific struct
+ * @height_field: the name of the height field in the driver specific struct
+ * @width: desired width.
+ * @height: desired height.
+ *
+ * Finds the closest resolution to minimize the width and height differences
+ * between what requested and the supported resolutions. The size of the width
+ * and height fields in the driver specific must equal to that of u32, i.e. 
four
+ * bytes.
+ *
+ * Returns the best match or NULL if the length of the array is zero.
+ */
+#define v4l2_find_nearest_size(array, array_size, width_field, height_field, \
+  width, height)   \
+   ({  \
+   BUILD_BUG_ON(sizeof((array)->width_field) != sizeof(u32) || \
+sizeof((array)->height_field) != sizeof(u32)); \
+   (typeof(&(*(array__v4l2_find_nearest_size(  \
+   (array), array_size, sizeof(*(array)),  \
+   offsetof(typeof(*(array)), width_field),\
+   offsetof(typeof(*(array)), height_field),   \
+   width, height); \
+   })
+const void *
+__v4l2_find_nearest_size(const void *arr, size_t entry_size,
+size_t width_offset, size_t height_offset,
+size_t num_entries, s32 width, s32 height);
+
+/**
  * v4l2_get_timestamp - helper routine to get a timestamp to be used when
  * filling streaming metadata. Internally, it uses ktime_get_ts(),
  * which is the recommended way to get it.
-- 
2.7.4

[PATCH v2 1/1] videobuf2: Add VIDEOBUF2_V4L2 Kconfig option for videobuf2 V4L2 part

[Sakari Ailus]

Videobuf2 is now separate from V4L2 and can be now built without it, at
least in principle --- enabling videobuf2 in kernel configuration attempts
to compile videobuf2-v4l2.c but that will fail if CONFIG_VIDEO_V4L2 isn't
enabled.

Solve this by adding a separate Kconfig option for videobuf2-v4l2 and make
it a separate module as well. This means that drivers now need to choose
both the appropriate videobuf2 memory type
(VIDEOBUF2_{VMALLOC,DMA_CONTIG,DMA_SG}) and VIDEOBUF2_V4L2 if they need
both.

Signed-off-by: Sakari Ailus 
---
Hi Mauro,

I'm proposing to merge this as it fixes build errors. We can later in
rework the Kconfig options; the rework isn't related to fixing the build
errors in general but rather is a change in the approach used to manage
dependencies. Let's discuss that on #v4l.

since v1:

- Select VIDEOBUF2_V4L2 if both VIDEO_V4L2 and VIDEOBUF2_CORE are
  selected. This way the patch no longer requires changing Kconfig entries
  for effectively all drivers. In certain rare configurations (V4L2 and
  VIDEOBUF2 are enabled but no V4L2 driver uses VIDEOBUF2) VIDEOBUF2_V4L2
  could be enabled without it being needed. This is not really an issue
  though.

 drivers/media/common/videobuf2/Kconfig  | 3 +++
 drivers/media/common/videobuf2/Makefile | 3 ++-
 drivers/media/v4l2-core/Kconfig | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 5df05250de94..17c32ea58395 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -3,6 +3,9 @@ config VIDEOBUF2_CORE
select DMA_SHARED_BUFFER
tristate
 
+config VIDEOBUF2_V4L2
+   tristate
+
 config VIDEOBUF2_MEMOPS
tristate
select FRAME_VECTOR
diff --git a/drivers/media/common/videobuf2/Makefile 
b/drivers/media/common/videobuf2/Makefile
index 19de5ccda20b..7e27bdd44dcc 100644
--- a/drivers/media/common/videobuf2/Makefile
+++ b/drivers/media/common/videobuf2/Makefile
@@ -1,5 +1,6 @@
 
-obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o videobuf2-v4l2.o
+obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
+obj-$(CONFIG_VIDEOBUF2_V4L2) += videobuf2-v4l2.o
 obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
 obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
 obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index bf52fbd07aed..8e37e7c5e0f7 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -7,6 +7,7 @@ config VIDEO_V4L2
tristate
depends on (I2C || I2C=n) && VIDEO_DEV
select RATIONAL
+   select VIDEOBUF2_V4L2 if VIDEOBUF2_CORE
default (I2C || I2C=n) && VIDEO_DEV
 
 config VIDEO_ADV_DEBUG
-- 
2.11.0

Re: [PATCH v2] v4l: vsp1: Print the correct blending unit name in debug messages

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2018-02-22 22:52:26 +0200, Laurent Pinchart wrote:
> The DRM pipelines can use either the BRU or the BRS for blending. Make
> sure the right name is used in debugging messages to avoid confusion.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Niklas Söderlund 

> ---
> Changes since v1:
> 
> - Create a macro to get the right entity name instead of duplicating the
>   same code all over the driver
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index ac85942162c1..b8fee1834253 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -27,6 +27,7 @@
>  #include "vsp1_pipe.h"
>  #include "vsp1_rwpf.h"
>  
> +#define BRU_NAME(e)  (e)->type == VSP1_ENTITY_BRU ? "BRU" : "BRS"
>  
>  /* 
> -
>   * Interrupt Handling
> @@ -88,7 +89,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
>   struct v4l2_subdev_format format;
> - const char *bru_name;
>   unsigned long flags;
>   unsigned int i;
>   int ret;
> @@ -99,7 +99,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   drm_pipe = >drm->pipe[pipe_index];
>   pipe = _pipe->pipe;
>   bru = to_bru(>bru->subdev);
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
>  
>   if (!cfg) {
>   /*
> @@ -165,7 +164,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>   }
>  
>   format.pad = pipe->bru->source_pad;
> @@ -181,7 +180,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>  
>   format.pad = RWPF_PAD_SINK;
>   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
> @@ -473,9 +472,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, format.pad);
> + format.format.code, BRU_NAME(pipe->bru), format.pad);
>  
>   sel.pad = bru_input;
>   sel.target = V4L2_SEL_TGT_COMPOSE;
> @@ -486,10 +485,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev,
> - "%s: set selection (%u,%u)/%ux%u on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
>   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> - sel.pad);
> + BRU_NAME(pipe->bru), sel.pad);
>  
>   return 0;
>  }
> @@ -514,12 +512,9 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   struct vsp1_entity *entity;
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
> - const char *bru_name;
>   unsigned int i;
>   int ret;
>  
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
> -
>   /* Prepare the display list. */
>   dl = vsp1_dl_list_get(pipe->output->dlm);
>  
> @@ -570,7 +565,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   rpf->entity.sink_pad = i;
>  
>   dev_dbg(vsp1->dev, "%s: connecting RPF.%u to %s:%u\n",
> - __func__, rpf->entity.index, bru_name, i);
> + __func__, rpf->entity.index, BRU_NAME(pipe->bru), i);
>  
>   ret = vsp1_du_setup_rpf_pipe(vsp1, pipe, rpf, i);
>   if (ret < 0)
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

[PATCH] ov13858: fix endiannes warnings

[Mauro Carvalho Chehab]

3 warning regressions:
  + drivers/media/i2c/ov13858.c: warning: cast to restricted __be32:  => 1093:16
  + drivers/media/i2c/ov13858.c: warning: incorrect type in assignment 
(different base types):  => :13
  + drivers/media/i2c/ov13858.c: warning: incorrect type in initializer 
(different base types):  => 1071:27

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/ov13858.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
index 1f260d346a29..d4156eb62dab 100644
--- a/drivers/media/i2c/ov13858.c
+++ b/drivers/media/i2c/ov13858.c
@@ -1061,14 +1061,15 @@ struct ov13858 {
 #define to_ov13858(_sd)container_of(_sd, struct ov13858, sd)
 
 /* Read registers up to 4 at a time */
-static int ov13858_read_reg(struct ov13858 *ov13858, u16 reg, u32 len, u32 
*val)
+static int ov13858_read_reg(struct ov13858 *ov13858, u16 reg, u32 len,
+   u32 *val)
 {
struct i2c_client *client = v4l2_get_subdevdata(>sd);
struct i2c_msg msgs[2];
u8 *data_be_p;
int ret;
-   u32 data_be = 0;
-   u16 reg_addr_be = cpu_to_be16(reg);
+   __be32 data_be = 0;
+   __be16 reg_addr_be = cpu_to_be16(reg);
 
if (len > 4)
return -EINVAL;
@@ -1096,11 +1097,13 @@ static int ov13858_read_reg(struct ov13858 *ov13858, 
u16 reg, u32 len, u32 *val)
 }
 
 /* Write registers up to 4 at a time */
-static int ov13858_write_reg(struct ov13858 *ov13858, u16 reg, u32 len, u32 
val)
+static int ov13858_write_reg(struct ov13858 *ov13858, u16 reg, u32 len,
+u32 __val)
 {
struct i2c_client *client = v4l2_get_subdevdata(>sd);
int buf_i, val_i;
u8 buf[6], *val_p;
+   __be32 val;
 
if (len > 4)
return -EINVAL;
@@ -1108,7 +,7 @@ static int ov13858_write_reg(struct ov13858 *ov13858, u16 
reg, u32 len, u32 val)
buf[0] = reg >> 8;
buf[1] = reg & 0xff;
 
-   val = cpu_to_be32(val);
+   val = cpu_to_be32(__val);
val_p = (u8 *)
buf_i = 2;
val_i = 4 - len;
-- 
2.14.3

Re: [PATCH v11 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Simon Horman]

On Thu, Feb 22, 2018 at 11:37:20AM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Hans Verkuil 

I have marked this patch as deferred as it depends on the binding for
"renesas,r7s72100-ceu".  Please repost or otherwise ping me once that
dependency has been accepted.