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:   Thu Jul 21 04:00:16 CEST 2016
git branch: test
git hash:   009a620848218d521f008141c62f56bf19294dd9
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.23-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0-i686: WARNINGS
linux-4.1.1-i686: WARNINGS
linux-4.2-i686: WARNINGS
linux-4.3-i686: WARNINGS
linux-4.4-i686: WARNINGS
linux-4.5-i686: WARNINGS
linux-4.6-i686: WARNINGS
linux-4.7-rc1-i686: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.23-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0-x86_64: WARNINGS
linux-4.1.1-x86_64: WARNINGS
linux-4.2-x86_64: WARNINGS
linux-4.3-x86_64: WARNINGS
linux-4.4-x86_64: WARNINGS
linux-4.5-x86_64: WARNINGS
linux-4.6-x86_64: WARNINGS
linux-4.7-rc1-x86_64: WARNINGS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [RFC 7/7] [media] rc: add support for IR LEDs driven through SPI

[Andi Shyti]

Hi Sean,

> > +   int ret;
> > +   struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv;
> 
> No cast needed.

yes, thanks.

> > +   ret = regulator_enable(idata->regulator);
> > +   if (ret)
> > +   return ret;
> > +
> > +   mutex_lock(>mutex);
> > +   idata->xfer.len = n;
> > +   idata->xfer.tx_buf = buffer;
> > +   mutex_unlock(>mutex);
> 
> I'm not convinced the locking works here. You want to guard against 
> someone modifying xfer while you are sending (so in spi_sync_transfer), 
> which this locking is not doing. You could declare a 
> local "struct spi_transfer xfer" and avoid the mutex altogether.

I cannot declare xfer locally because the spi framework needs
a statically allocated xfer, so that either I dynamically
allocate it in the function or I declare it global in idata.

With the mutex I would like to prevent different tasks to change
the value at the same time, it's an easy case, it shouldn't make
much difference.

There are checkpatch issues, in the next patchset I will fix
them.

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

Re: [RFC 5/7] [media] ir-lirc-codec: do not handle any buffer for raw transmitters

[Andi Shyti]

Hi Sean,

> > Raw transmitters receive the data which need to be sent to
> > receivers from userspace as stream of bits, they don't require
> > any handling from the lirc framework.
> 
> No drivers of type RC_DRIVER_IR_RAW_TX should handle tx just like any
> other device, so data should be provided as an array of u32 alternating
> pulse-space. If your device does not handle input like that then convert
> it into that format in the driver. Every other driver has to do some
> sort of conversion of that kind.

I don't see anything wrong here, that's how it works for example
in Tizen or in Android for the boards I'm on: userspace sends a
stream of bits that are then submitted to the IR as they are.

If I change it to only pulse-space domain, then I wouldn't
provide support for those platforms. Eventually I can add a new
protocol.

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

Re: [RFC 3/7] [media] rc-core: add support for IR raw transmitters

[Andi Shyti]

Hi Sean,

> > +   if (dev->driver_type == RC_DRIVER_IR_RAW ||
> > +   dev->driver_type == RC_DRIVER_IR_RAW_TX) {
> 
> Here the if is wrong. It should be 
> "if (dev->driver_type != RC_DRIVER_IR_RAW_TX)". Note that as result
> the decoder thread is not started, so patch 4 won't be needed either.

but I need the ir-lirc-codec as it handles the interface with
userspace and it calls the tx_ir and s_tx_carrier.

if I do "if (dev->driver_type != RC_DRIVER_IR_RAW_TX)" the
lirc-codec is not called and I would need to handle it on my
driver, but then we fall in the first version of the driver.

Thanks,
Andi

> > if (!raw_init) {
> > request_module_nowait("ir-lirc-codec");
> > raw_init = true;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/7] [media] rc-main: assign driver type during allocation

[Andi Shyti]

Hi Sean,

> > The driver type can be assigned immediately when an RC device
> > requests to the framework to allocate the device.
> > 
> > This is an 'enum rc_driver_type' data type and specifies whether
> > the device is a raw receiver or scancode receiver. The type will
> > be given as parameter to the rc_allocate_device device.
> 
> This patch is good, but it does unfortunately break all the other
> rc-core drivers, as now rc_allocate_device() needs argument. All
> drivers will need a simple change in this patch.

Yes, but for being an RFC I didn't took care of fixing
everything.

> Also note that there lots of issues that checkpatch.pl would pick
> in these series.

Some of the issues are coming from the code as it was and I
preferred to not change it. The last patch has some that need to
be fixed in the patchset.

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

Re: [PATCH 00/18] Complete moving media documentation to ReST format

[Jonathan Corbet]

On Wed, 20 Jul 2016 08:07:54 +0200
Markus Heiser  wrote:

> Jon, what do you think ... could we serve this 1.2 doc 
> on https://www.kernel.org/doc/ as reference?

Seems like a good idea.  I don't really know who controls that directory,
though; I can ping Konstantin and see what can be done there.  Failing
that, I'd be more than happy to put it up on lwn, of course.

> And whats about those who have 1.3 (or any version >1.2) as default 
> in the linux distro? Should they install a virtualenv?  ... it is
> a dilemma.

I would hope that most people wouldn't have to worry about it, and would
be able to just use what their distribution provides - that's the reason
for the 1.2 compatibility requirement in the first place.  I'll make a
point of having a 1.2 installation around that I can test things with;
that should suffice to catch any problems that sneak in.

Thanks,

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

Re: [PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

[Javier Martinez Canillas]

Hello Sakari,

On 07/20/2016 07:08 PM, Sakari Ailus wrote:
> Hi Javier,
> 
> On Wed, Jul 20, 2016 at 06:56:52PM -0400, Javier Martinez Canillas wrote:
>> Hello Sakari,
>>
>> On 07/20/2016 03:52 PM, Sakari Ailus wrote:
>>> On Wed, Jul 20, 2016 at 12:07:55PM -0400, Javier Martinez Canillas wrote:
 If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's
 useful to get the invalid and minimum lengths as a debug info.

 Before this patch:

 vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1

 After this patch:

 vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1, minimum 
 length 410880

 Signed-off-by: Javier Martinez Canillas 

 ---

 Changes in v2:
 - Use %u instead of %d (Sakari Ailus)
 - Include min_length (Sakari Ailus)

  drivers/media/v4l2-core/videobuf2-core.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
 b/drivers/media/v4l2-core/videobuf2-core.c
 index b6fbc04f9699..bbba50d6e1ad 100644
 --- a/drivers/media/v4l2-core/videobuf2-core.c
 +++ b/drivers/media/v4l2-core/videobuf2-core.c
 @@ -1227,8 +1227,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, 
 const void *pb)
planes[plane].length = dbuf->size;
  
if (planes[plane].length < vb->planes[plane].min_length) {
 -  dprintk(1, "invalid dmabuf length for plane %d\n",
 -  plane);
 +  dprintk(1, "invalid dmabuf length %u for plane %d, "
 +  "minimum length %u\n",
>>>
>>> You shouldn't split strings. It breaks grep.
>>>
>>
>> Yes I know but if I didn't split the line, it would had been longer than
>> the max 80 character per line convention. On those situations I follow
>> what's already done in the file for consistency and most strings in the
>> videobuf2-core file, whose lines are over 80 characters, are being split.
>>
>> But if having a longer line is preferred, I'll happily re-spin the patch.
> 
> I guess in videobuf2's case it's that the strings contain lots of format
> specifiers --- it's not that useful to be able to grep those. I think this
> case is a borderline one.
>

Yes, lots of format specifiers as you said. Which also makes harder to grep
the messages verbatim and someone would had to grep a sub-string anyways or
figure the specifier for each variable to be able to grep the complete line.

So I would prefer to kept the line split as is if you don't mind.
 
> Up to you. You've got my ack.
>

Thanks a lot.
 
>>> With that changed,
>>>
>>> Acked-by: Sakari Ailus 
>>>
 +  planes[plane].length, plane,
 +  vb->planes[plane].min_length);
dma_buf_put(dbuf);
ret = -EINVAL;
goto err;
>>>
>>
>> Best regards,
>> -- 
>> Javier Martinez Canillas
>> Open Source Group
>> Samsung Research America
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

[Sakari Ailus]

Hi Javier,

On Wed, Jul 20, 2016 at 06:56:52PM -0400, Javier Martinez Canillas wrote:
> Hello Sakari,
> 
> On 07/20/2016 03:52 PM, Sakari Ailus wrote:
> > On Wed, Jul 20, 2016 at 12:07:55PM -0400, Javier Martinez Canillas wrote:
> >> If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's
> >> useful to get the invalid and minimum lengths as a debug info.
> >>
> >> Before this patch:
> >>
> >> vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1
> >>
> >> After this patch:
> >>
> >> vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1, minimum 
> >> length 410880
> >>
> >> Signed-off-by: Javier Martinez Canillas 
> >>
> >> ---
> >>
> >> Changes in v2:
> >> - Use %u instead of %d (Sakari Ailus)
> >> - Include min_length (Sakari Ailus)
> >>
> >>  drivers/media/v4l2-core/videobuf2-core.c | 6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> >> b/drivers/media/v4l2-core/videobuf2-core.c
> >> index b6fbc04f9699..bbba50d6e1ad 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-core.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> >> @@ -1227,8 +1227,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, 
> >> const void *pb)
> >>planes[plane].length = dbuf->size;
> >>  
> >>if (planes[plane].length < vb->planes[plane].min_length) {
> >> -  dprintk(1, "invalid dmabuf length for plane %d\n",
> >> -  plane);
> >> +  dprintk(1, "invalid dmabuf length %u for plane %d, "
> >> +  "minimum length %u\n",
> > 
> > You shouldn't split strings. It breaks grep.
> > 
> 
> Yes I know but if I didn't split the line, it would had been longer than
> the max 80 character per line convention. On those situations I follow
> what's already done in the file for consistency and most strings in the
> videobuf2-core file, whose lines are over 80 characters, are being split.
> 
> But if having a longer line is preferred, I'll happily re-spin the patch.

I guess in videobuf2's case it's that the strings contain lots of format
specifiers --- it's not that useful to be able to grep those. I think this
case is a borderline one.

Up to you. You've got my ack.

> > With that changed,
> > 
> > Acked-by: Sakari Ailus 
> > 
> >> +  planes[plane].length, plane,
> >> +  vb->planes[plane].min_length);
> >>dma_buf_put(dbuf);
> >>ret = -EINVAL;
> >>goto err;
> > 
> 
> Best regards,
> -- 
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America

-- 
Kind regards,

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

v4l-utils-1.10.1; dvbv5-scan errors on Astra 19E2 12363kHz transponder

[asbase]

Hi folks,

What we are talking about?
--

1. Hardware:
1.1 Notebook: Lenovo ThinkPad 11e, Intel Celeron N2940
1.2 Frontend: TurboView TBS-5520 Multi-standard TV Tuner USB Box
  (http://www.tbs-technology.de, http://tbsdtv.com)

2. Software:
2.1 Package: v4l-utils-2.10.1:
(compiled on my non-standart Slax/Slackware GNU/Linux 3.19.8)
2.1.1 Utility: dvbv5-scan
  Errors on Astra 19E2 12363000Hz transponder (details below)
2.1.2 Utility: dvbv5-scan
  Produces duplicate entries in connection with 'channel'
  output format (deteils below)


Short pretext:
--

Firstly, thanks for all your work and time you have spent to create and maintain
this open-source software! The reason I am writing this bug report is that I use
this software package (due to new hardware) a lot and I want to help improve it.

Due to the (in my opinion bad) decision to switch from DVB-T to DVB-T2
transmissions for terrestrial TV here in Germany I invested in some new hardware
and played around. For DVB television and radio decoding I am using MPlayer
(without skin or other graphical toolkit). As you most probably know, MPlayer
has a internal tuning facility (done via mplayer dvb://...) but - so far - this
works only vor DVB-T and DVB-S/S2 (concerning DVB-C/C2 I can not make any
statement, because there is no functioning cable input available). So I decided
to do the tuning part with 'dvbv5-zap' utility and playback the stream via the
'dvr0' device with MPlayer. The result: DVB-T/T2 and DVB-S/S2 are working fine
(with the one restriction, that this German variant "DVB-T2 HD", which is
DVB-T2+HEVC/h.265, needs a lot/far too much resources).

Thanks to the improved 'channels.conf'-format, it is possible to use only one
channels file for the different standards and switch the TBS-5520 directly
with the 'dvbv5-zap' utility between DVB-T/T2 and DVB-S/S2 (very nice!).


Wrong service/audio-pid output on Astra 19.2° East,transponder 12363000 Hz:
---

On this transponder are some satellite radio stations I am listening from time
to time (BBC Word Service, Radio Nova - during night the "Le Grande Mix"). Now
solely tuning via 'dvbv5-zap' I soon noticed, that the station (service) names
and the AUDIO_PIDs generated with 'dvbv5-scan' are not correct. I repeated the
scan process with this utility, converted it to the older (more compact)
zap-channels.conf-format and compared it with the output of the 'scan' utility
of the 'dvb-apps-1.1.2' package and with 'w_scan' (version 2014-11-22).

In most cases 'dvbv5-scan' does a better job than the other tools, but on this
special transponder (no tv, only radio and some data) only 'scan' does correctly
separate the multiplex, 'w_scan' only produces one service with serveral audio
streams. Comparing serveral scans done with 'dvbv5-scan' on this transponder
shows that the software does find the service names but cannot assign correctly
the appropriate audio-pid (seems to be exchanged randomly)!


Duplicates output in connection with 'channel'-format:
--

Using 'dvbv5-scan -I channel ' or 'dvbv5-scan --input-format=channel' produces
duplicate entries when it finds a service on the same transponder. I think this
is not "a big thing", I only report this, because I have observed it and do not
believe that this behaviour was intended.


I have taken a short look into the source code, but - so far -, sorry,
I am not able to deliver the perfect patch instantly :-(

Enclosed are 4 files:
[1] Astra-19.2E-12363000: Scan input file in v5-format for this transponder
(data retrieved from: http://www.astra.de).
[2] Astra_S19E2_12363kHz_scanned-channels.conf: 'dvbv5-scan' output for this
transponder (wiht errors).
[3] Astra_S19E2_12363kHz_correct-channels.conf: Manual corrected channel file
(essentially using audio pids as produced by 'scan')
[4] channels.conf.sat: For comparison output of 'dvbv5-scan', 'scan' and
'w_scan' in v3/zap/mplayer-format.

I hope my descriptions and these files can help to improve this fine software
package. For the case, that someone finds the time and has the knowledge to fix
the code but is not able to scan Astra 19E2, you can mail me [asbase at gmx dot
de] patches or updated source code for compilation and testing.

Best regards

Armin Schneider


P.S.: Some additional observations ...

Channels file field PILOT (DVB-S/S2) blocks MPlayer from playback:
--

As described above I use 'mplayer /dev/dvb/adapter0/dvr0' for playback of the
dvb streams. Commenting-out the PILOT entry does "solve" the problem.


Additional available PIDs under DVB-T2 may block MPlayer from playback:
---

In the case of DVB-T2 zapping only works when PID filter is turned off (i.e.:
dvbv5-zap -P 

Re: [PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Jonathan Corbet]

On Wed, 20 Jul 2016 11:41:11 -0300
Mauro Carvalho Chehab  wrote:

> > The thing with that is that a lot of literal blocks *do* have C code, even
> > in kernel-documentation.rst.  Setting that in conf.py would turn off all C
> > highlighting.  I think that might actually be a desirable outcome, but it
> > would be good to make that decision explicitly.  
> 
> Agreed. Assuming "C" as default seems a good idea to me.

"Agreed," but there was an implied question there that, I think, deserves
consideration.  Do we want to have a default highlighting language for
literal blocks at all?  Those blocks will contain ascii art diagrams,
device-tree fragments, error message examples, and who knows what else.
Even if the majority of them are C code, having Sphinx treat all of them
as C is going to lead to a steady stream of warnings and a lot of extra
markup in the text.

Plus I'm not convinced that more color eye candy in code fragments is
actually helpful.

So I think I might actually argue in favor of Markus's suggestion and set
the language to "none" by default.  But others may feel strongly about
having their bikeshed in full syntax-highlighted color.  Opinions on the
matter?

Thanks,

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

Re: [PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

[Javier Martinez Canillas]

Hello Sakari,

On 07/20/2016 03:52 PM, Sakari Ailus wrote:
> On Wed, Jul 20, 2016 at 12:07:55PM -0400, Javier Martinez Canillas wrote:
>> If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's
>> useful to get the invalid and minimum lengths as a debug info.
>>
>> Before this patch:
>>
>> vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1
>>
>> After this patch:
>>
>> vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1, minimum 
>> length 410880
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> Changes in v2:
>> - Use %u instead of %d (Sakari Ailus)
>> - Include min_length (Sakari Ailus)
>>
>>  drivers/media/v4l2-core/videobuf2-core.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index b6fbc04f9699..bbba50d6e1ad 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -1227,8 +1227,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
>> void *pb)
>>  planes[plane].length = dbuf->size;
>>  
>>  if (planes[plane].length < vb->planes[plane].min_length) {
>> -dprintk(1, "invalid dmabuf length for plane %d\n",
>> -plane);
>> +dprintk(1, "invalid dmabuf length %u for plane %d, "
>> +"minimum length %u\n",
> 
> You shouldn't split strings. It breaks grep.
> 

Yes I know but if I didn't split the line, it would had been longer than
the max 80 character per line convention. On those situations I follow
what's already done in the file for consistency and most strings in the
videobuf2-core file, whose lines are over 80 characters, are being split.

But if having a longer line is preferred, I'll happily re-spin the patch.

> With that changed,
> 
> Acked-by: Sakari Ailus 
> 
>> +planes[plane].length, plane,
>> +vb->planes[plane].min_length);
>>  dma_buf_put(dbuf);
>>  ret = -EINVAL;
>>  goto err;
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documentation issues with some MBUS flags

[Mauro Carvalho Chehab]

Em Wed, 20 Jul 2016 23:45:45 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> Mauro Carvalho Chehab wrote:
> > Hi Sylwester/Sakari,
> >
> > While checking the docs for the V4L2 framework, I noticed something weird
> > Related to those two flags:
> >
> > #define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX(1U << 0)
> > #define V4L2_MBUS_FRAME_DESC_FL_BLOB   (1U << 1)
> >
> > They were originally introduced by this changeset:
> >
> > commit 291031192426bfc6ad4ab2eb9fa986025a926598
> > Author: Sylwester Nawrocki 
> > Date:   Thu May 17 14:33:30 2012 -0300
> >
> >  [media] V4L: Add [get/set]_frame_desc subdev callbacks
> >
> >  Add subdev callbacks for setting up parameters of the frame on media 
> > bus
> >  that are not exposed to user space directly. This is just an initial,
> >  mostly stub implementation. struct v4l2_mbus_frame_desc is intended
> >  to be extended with sub-structures specific to a particular hardware 
> > media
> >  bus. For now these new callbacks are used only to query or specify 
> > maximum
> >  size of a compressed or hybrid (container) media bus frame in octets.
> >
> >  Signed-off-by: Sylwester Nawrocki 
> >  Signed-off-by: Kyungmin Park 
> >  Signed-off-by: Mauro Carvalho Chehab 
> >
> > And the comments were modified by this one:
> >
> > commit 174d6a39b07f51212c23a8e30a0440598d18392c
> > Author: Sakari Ailus 
> > Date:   Wed Dec 18 08:40:28 2013 -0300
> >
> >  [media] v4l: V4L2_MBUS_FRAME_DESC_FL_BLOB is about 1D DMA
> >
> >  V4L2_MBUS_FRAME_DESC_FL_BLOB intends to say the receiver must use 1D 
> > DMA to
> >  receive the image, as the format does not have line offsets. This 
> > typically
> >  includes all compressed formats.
> >
> >  Signed-off-by: Sakari Ailus 
> >  Cc: Sylwester Nawrocki 
> >  Signed-off-by: Mauro Carvalho Chehab 
> >
> > The problem is that the description of V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
> > says that:
> > Indicates the @length field specifies maximum data length.
> >
> > But the description of the @length field says otherwise:
> > * @length: number of octets per frame, valid if 
> > V4L2_MBUS_FRAME_DESC_FL_BLOB
> >
> > So, I decided to take a look on what the heck is that:
> >
> > $ git grep V4L2_MBUS_FRAME_DESC_FL_BLOB
> > include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_BLOB
> > (1U << 1)
> > include/media/v4l2-subdev.h: *
> > %V4L2_MBUS_FRAME_DESC_FL_BLOB.
> > include/media/v4l2-subdev.h: * @length: number of octets per frame, 
> > valid if V4L2_MBUS_FRAME_DESC_FL_BLOB
> >
> > (nobody is using it)
> >
> > And:
> >
> > $ git grep V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
> > drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = 
> > V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
> > drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = 
> > V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
> > include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX 
> > (1U << 0)
> >
> > Only one driver is using it.
> >
> > So, I'm thinking if are there any reason why to keep the
> > V4L2_MBUS_FRAME_DESC_FL_BLOB, and what's the expected behavior
> > when V4L2_MBUS_FRAME_DESC_FL_LEN_MAX is found.
> >
> > Could you shed some light?  
> 
> There isn't really a problem that I could see here, except that the 
> m5mols driver should perhaps set the BLOB flag to indicate it's using 
> 1-dimensional DMA.

Hmm... why both flags should be on? I mean, if they both have the
same meaning, we can get rid of one of them.

> 
> What comes to the flags, the LEN_MAX flag indicates that the length 
> specified in the frame descriptor is the maximum length whereas the real 
> amount of data could be less than that.

Not sure if I understood. Are you saying that, instead of:

 * @length: number of octets per frame, valid if V4L2_MBUS_FRAME_DESC_FL_BLOB
 *  is set


It should be:

 * @length: number of octets per frame, valid if V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
 *  is set

as the description of V4L2_MBUS_FRAME_DESC_FL_LEN_MAX suggests?

> The BLOB flag indicates 
> 1-dimensional DMA, but no driver (yet) uses two-dimensional DMA with 
> frame descriptors. The patch adding two-dimensional support is here:
> 
> 
> 
> AFAIR I posted it to linux-media long time ago but the set currently is 
> still unfinished. It will be needed to add support for sensor embedded 
> data, for instance. Certain newer sensors also provide more distinct 
> types of data than the usual (embedded data and image data).

Well, if the feature using it was not merged, then we can just wipe it
out, re-adding when 

Re: Documentation issues with some MBUS flags

[Sakari Ailus]

Hi Mauro,

Mauro Carvalho Chehab wrote:

Hi Sylwester/Sakari,

While checking the docs for the V4L2 framework, I noticed something weird
Related to those two flags:

#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX(1U << 0)
#define V4L2_MBUS_FRAME_DESC_FL_BLOB   (1U << 1)

They were originally introduced by this changeset:

commit 291031192426bfc6ad4ab2eb9fa986025a926598
Author: Sylwester Nawrocki 
Date:   Thu May 17 14:33:30 2012 -0300

 [media] V4L: Add [get/set]_frame_desc subdev callbacks

 Add subdev callbacks for setting up parameters of the frame on media bus
 that are not exposed to user space directly. This is just an initial,
 mostly stub implementation. struct v4l2_mbus_frame_desc is intended
 to be extended with sub-structures specific to a particular hardware media
 bus. For now these new callbacks are used only to query or specify maximum
 size of a compressed or hybrid (container) media bus frame in octets.

 Signed-off-by: Sylwester Nawrocki 
 Signed-off-by: Kyungmin Park 
 Signed-off-by: Mauro Carvalho Chehab 

And the comments were modified by this one:

commit 174d6a39b07f51212c23a8e30a0440598d18392c
Author: Sakari Ailus 
Date:   Wed Dec 18 08:40:28 2013 -0300

 [media] v4l: V4L2_MBUS_FRAME_DESC_FL_BLOB is about 1D DMA

 V4L2_MBUS_FRAME_DESC_FL_BLOB intends to say the receiver must use 1D DMA to
 receive the image, as the format does not have line offsets. This typically
 includes all compressed formats.

 Signed-off-by: Sakari Ailus 
 Cc: Sylwester Nawrocki 
 Signed-off-by: Mauro Carvalho Chehab 

The problem is that the description of V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
says that:
Indicates the @length field specifies maximum data length.

But the description of the @length field says otherwise:
* @length: number of octets per frame, valid if 
V4L2_MBUS_FRAME_DESC_FL_BLOB

So, I decided to take a look on what the heck is that:

$ git grep V4L2_MBUS_FRAME_DESC_FL_BLOB
include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_BLOB  
  (1U << 1)
include/media/v4l2-subdev.h: *
%V4L2_MBUS_FRAME_DESC_FL_BLOB.
include/media/v4l2-subdev.h: * @length: number of octets per frame, 
valid if V4L2_MBUS_FRAME_DESC_FL_BLOB

(nobody is using it)

And:

$ git grep V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = 
V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = 
V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX   
  (1U << 0)

Only one driver is using it.

So, I'm thinking if are there any reason why to keep the
V4L2_MBUS_FRAME_DESC_FL_BLOB, and what's the expected behavior
when V4L2_MBUS_FRAME_DESC_FL_LEN_MAX is found.

Could you shed some light?


There isn't really a problem that I could see here, except that the 
m5mols driver should perhaps set the BLOB flag to indicate it's using 
1-dimensional DMA.


What comes to the flags, the LEN_MAX flag indicates that the length 
specified in the frame descriptor is the maximum length whereas the real 
amount of data could be less than that. The BLOB flag indicates 
1-dimensional DMA, but no driver (yet) uses two-dimensional DMA with 
frame descriptors. The patch adding two-dimensional support is here:




AFAIR I posted it to linux-media long time ago but the set currently is 
still unfinished. It will be needed to add support for sensor embedded 
data, for instance. Certain newer sensors also provide more distinct 
types of data than the usual (embedded data and image data).


--
Kind regards,

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

Re: [PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

[Sakari Ailus]

On Wed, Jul 20, 2016 at 12:07:55PM -0400, Javier Martinez Canillas wrote:
> If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's
> useful to get the invalid and minimum lengths as a debug info.
> 
> Before this patch:
> 
> vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1
> 
> After this patch:
> 
> vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1, minimum 
> length 410880
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Changes in v2:
> - Use %u instead of %d (Sakari Ailus)
> - Include min_length (Sakari Ailus)
> 
>  drivers/media/v4l2-core/videobuf2-core.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index b6fbc04f9699..bbba50d6e1ad 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1227,8 +1227,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
> void *pb)
>   planes[plane].length = dbuf->size;
>  
>   if (planes[plane].length < vb->planes[plane].min_length) {
> - dprintk(1, "invalid dmabuf length for plane %d\n",
> - plane);
> + dprintk(1, "invalid dmabuf length %u for plane %d, "
> + "minimum length %u\n",

You shouldn't split strings. It breaks grep.

With that changed,

Acked-by: Sakari Ailus 

> + planes[plane].length, plane,
> + vb->planes[plane].min_length);
>   dma_buf_put(dbuf);
>   ret = -EINVAL;
>   goto err;

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

Documentation issues with some MBUS flags

[Mauro Carvalho Chehab]

Hi Sylwester/Sakari,

While checking the docs for the V4L2 framework, I noticed something weird
Related to those two flags:

#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX(1U << 0)
#define V4L2_MBUS_FRAME_DESC_FL_BLOB   (1U << 1)

They were originally introduced by this changeset:

commit 291031192426bfc6ad4ab2eb9fa986025a926598
Author: Sylwester Nawrocki 
Date:   Thu May 17 14:33:30 2012 -0300

[media] V4L: Add [get/set]_frame_desc subdev callbacks

Add subdev callbacks for setting up parameters of the frame on media bus
that are not exposed to user space directly. This is just an initial,
mostly stub implementation. struct v4l2_mbus_frame_desc is intended
to be extended with sub-structures specific to a particular hardware media
bus. For now these new callbacks are used only to query or specify maximum
size of a compressed or hybrid (container) media bus frame in octets.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Signed-off-by: Mauro Carvalho Chehab 

And the comments were modified by this one:

commit 174d6a39b07f51212c23a8e30a0440598d18392c
Author: Sakari Ailus 
Date:   Wed Dec 18 08:40:28 2013 -0300

[media] v4l: V4L2_MBUS_FRAME_DESC_FL_BLOB is about 1D DMA

V4L2_MBUS_FRAME_DESC_FL_BLOB intends to say the receiver must use 1D DMA to
receive the image, as the format does not have line offsets. This typically
includes all compressed formats.

Signed-off-by: Sakari Ailus 
Cc: Sylwester Nawrocki 
Signed-off-by: Mauro Carvalho Chehab 

The problem is that the description of V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
says that:
Indicates the @length field specifies maximum data length.

But the description of the @length field says otherwise:
* @length: number of octets per frame, valid if 
V4L2_MBUS_FRAME_DESC_FL_BLOB

So, I decided to take a look on what the heck is that:

$ git grep V4L2_MBUS_FRAME_DESC_FL_BLOB
include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_BLOB
(1U << 1)
include/media/v4l2-subdev.h: *
%V4L2_MBUS_FRAME_DESC_FL_BLOB.
include/media/v4l2-subdev.h: * @length: number of octets per frame, 
valid if V4L2_MBUS_FRAME_DESC_FL_BLOB

(nobody is using it)

And:

$ git grep V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = 
V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = 
V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX 
(1U << 0)

Only one driver is using it.

So, I'm thinking if are there any reason why to keep the
V4L2_MBUS_FRAME_DESC_FL_BLOB, and what's the expected behavior
when V4L2_MBUS_FRAME_DESC_FL_LEN_MAX is found.

Could you shed some light?

Thanks!
Mauro

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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 18:06 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 17:13 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> >> > Hi,
>> >> >
>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> >> >> Hello,
>> >> >> >>
>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x 
>> >> >> >> based BeagleBoneBlack SBC.
>> >> >> >> I am sure that both of them are fine and work properly.
>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at 
>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
>> >> >> >> issue with frame transfer when high resolution formats are used.
>> >> >> >>
>> >> >> >> The issue is the following. I use simple v4l2 example tool (taken 
>> >> >> >> from API docs), which source code is available at 
>> >> >> >> http://pastebin.com/grcNXxfe
>> >> >> >>
>> >> >> >> When I use (see line 488) 640x480 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width   = 640;
>> >> >> >> fmt.fmt.pix.height  = 480;
>> >> >> >>
>> >> >> >> then I get "select timeout" and don't get any frames.
>> >> >> >>
>> >> >> >> When I use 320x240 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width   = 320;
>> >> >> >> fmt.fmt.pix.height  = 240;
>> >> >> >>
>> >> >> >> then about 60% frames are missed. An example outpout of ./a.out -f 
>> >> >> >> is available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> >> >> It looks like there are pauses between bulks of frames (frame 
>> >> >> >> counter and timestamp as returned from v4l2 API):
>> >> >> >>
>> >> >> >> 3 3705.142553
>> >> >> >> 8 3705.342533
>> >> >> >> 13 3705.542517
>> >> >> >> 110 3708.776208
>> >> >> >> 115 3708.976190
>> >> >> >> 120 3709.176169
>> >> >> >> 125 3709.376152
>> >> >> >> 130 3709.576144
>> >> >> >> 226 3712.807848
>> >> >> >>
>> >> >> >> When I use tiny 160x120 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width   = 160;
>> >> >> >> fmt.fmt.pix.height  = 120;
>> >> >> >>
>> >> >> >> then more frames are received. See output example at 
>> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> >> >> That is why I thought that everything was fine in May when used 
>> >> >> >> tiny xawtv window to check kernel OOPS presence (see 
>> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >> >> >>
>> >> >> >> Even more. When I introduce USB hub between the host and the 
>> >> >> >> webcam, I can not receive even any 320x240 frames.
>> >> >> >>
>> >> >> >> I've managed to use ftrace to see what is going on when no frames 
>> >> >> >> are received.
>> >> >> >> I've found that pwc_isoc_handler is called frequently as the 
>> >> >> >> following:
>> >> >> >>
>> >> >> >>  0)   |  pwc_isoc_handler [pwc]() {
>> >> >> >>  0)   |usb_submit_urb [usbcore]() {
>> >> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>> >> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>> >> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>> >> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>> >> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >> >> >>  0)   5.750 us|  }
>> >> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>> >> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>> >> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>> >> >> >>  0)   0.792 us|  _raw_spin_lock();
>> >> >> >>  0)   0.791 us|  _raw_spin_unlock();
>> >> >> >>  0) + 10.500 us   |}
>> >> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>> >> >> >>  0) + 25.375 us   |  }
>> >> >> >>  0) + 45.208 us   |}
>> >> >> >>  0) + 51.042 us   |  }
>> >> >> >>  0) + 56.084 us   |}
>> >> >> >>  0) + 61.292 us   |  }
>> >> >> >>
>> >> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why 
>> >> >> >> I get "select timeout" in userspace.
>> >> >> >> Unfortunately, my kernel is not compiled with 
>> >> >> >> CONFIG_USB_PWC_DEBUG=y but I can recompile it, if you think that it 
>> >> >> >> could provide more information. I am also ready to perform 
>> >> >> >> additional tests (use usbmon maybe?).
>> >> >> >>
>> >> >> >> How could this issue be resolved?
>> >> >> >>
>> >> >> >> Thank you.
>> >> >> >
>> >> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>> >> >> > issue in CPPI Isoch transfer, in which the MUSB controller only 

[PATCH] Staging: media: timblogiw: File cleanup.

[Jeremiah Goerdt]

Cleaned up checkpatch.pl warnings and checks.

Signed-off-by: Jeremiah Goerdt 
---
 drivers/staging/media/timb/timblogiw.c | 134 -
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/drivers/staging/media/timb/timblogiw.c 
b/drivers/staging/media/timb/timblogiw.c
index 113c9f3..66d2898 100644
--- a/drivers/staging/media/timb/timblogiw.c
+++ b/drivers/staging/media/timb/timblogiw.c
@@ -10,10 +10,6 @@
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
 /* Supports:
@@ -43,7 +39,6 @@
 
 #define TIMBLOGIW_HAS_DECODER(lw)  (lw->pdata.encoder.module_name)
 
-
 struct timblogiw {
struct video_device video_dev;
struct v4l2_device  v4l2_dev; /* mutual exclusion */
@@ -98,7 +93,6 @@ static int timblogiw_bytes_per_line(const struct 
timblogiw_tvnorm *norm)
return norm->width * 2;
 }
 
-
 static int timblogiw_frame_size(const struct timblogiw_tvnorm *norm)
 {
return norm->height * timblogiw_bytes_per_line(norm);
@@ -107,6 +101,7 @@ static int timblogiw_frame_size(const struct 
timblogiw_tvnorm *norm)
 static const struct timblogiw_tvnorm *timblogiw_get_norm(const v4l2_std_id std)
 {
int i;
+
for (i = 0; i < ARRAY_SIZE(timblogiw_tvnorms); i++)
if (timblogiw_tvnorms[i].std & std)
return timblogiw_tvnorms + i;
@@ -138,8 +133,8 @@ static void timblogiw_dma_cb(void *data)
}
 
if (!list_empty(>capture)) {
-   vb = list_entry(fh->capture.next, struct videobuf_buffer,
-   queue);
+   vb = list_entry(
+   fh->capture.next, struct videobuf_buffer, queue);
vb->state = VIDEOBUF_ACTIVE;
}
 
@@ -153,8 +148,8 @@ static bool timblogiw_dma_filter_fn(struct dma_chan *chan, 
void *filter_param)
 
 /* IOCTL functions */
 
-static int timblogiw_g_fmt(struct file *file, void  *priv,
-   struct v4l2_format *format)
+static int timblogiw_g_fmt(
+   struct file *file, void *priv, struct v4l2_format *format)
 {
struct video_device *vdev = video_devdata(file);
struct timblogiw *lw = video_get_drvdata(vdev);
@@ -179,8 +174,8 @@ static int timblogiw_g_fmt(struct file *file, void  *priv,
return 0;
 }
 
-static int timblogiw_try_fmt(struct file *file, void  *priv,
-   struct v4l2_format *format)
+static int timblogiw_try_fmt(
+   struct file *file, void *priv, struct v4l2_format *format)
 {
struct video_device *vdev = video_devdata(file);
struct v4l2_pix_format *pix = >fmt.pix;
@@ -204,8 +199,8 @@ static int timblogiw_try_fmt(struct file *file, void  *priv,
return 0;
 }
 
-static int timblogiw_s_fmt(struct file *file, void  *priv,
-   struct v4l2_format *format)
+static int timblogiw_s_fmt(
+   struct file *file, void *priv, struct v4l2_format *format)
 {
struct video_device *vdev = video_devdata(file);
struct timblogiw *lw = video_get_drvdata(vdev);
@@ -233,15 +228,17 @@ out:
return err;
 }
 
-static int timblogiw_querycap(struct file *file, void  *priv,
-   struct v4l2_capability *cap)
+static int timblogiw_querycap(
+   struct file *file, void *priv, struct v4l2_capability *cap)
 {
struct video_device *vdev = video_devdata(file);
 
dev_dbg(>dev, "%s: Entry\n",  __func__);
-   strncpy(cap->card, TIMBLOGIWIN_NAME, sizeof(cap->card)-1);
+   strncpy(cap->card, TIMBLOGIWIN_NAME, sizeof(cap->card) - 1);
strncpy(cap->driver, DRIVER_NAME, sizeof(cap->driver) - 1);
-   snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s", 
vdev->name);
+   snprintf(
+   cap->bus_info, sizeof(cap->bus_info),
+   "platform:%s", vdev->name);
cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
@@ -249,8 +246,8 @@ static int timblogiw_querycap(struct file *file, void  
*priv,
return 0;
 }
 
-static int timblogiw_enum_fmt(struct file *file, void  *priv,
-   struct v4l2_fmtdesc *fmt)
+static int timblogiw_enum_fmt(
+   struct file *file, void *priv, struct v4l2_fmtdesc *fmt)
 {
struct video_device *vdev = video_devdata(file);
 
@@ -261,15 +258,16 @@ static int timblogiw_enum_fmt(struct file *file, void  
*priv,
memset(fmt, 0, sizeof(*fmt));
fmt->index = 0;
fmt->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
-   strncpy(fmt->description, "4:2:2, packed, YUYV",
-   sizeof(fmt->description)-1);
+   strncpy(
+  

[PATCH] [media] vb2: move dma-buf unmap from __vb2_dqbuf() to vb2_buffer_done()

[Javier Martinez Canillas]

Currently the dma-buf is unmapped when the buffer is dequeued by userspace
but it's not used anymore after the driver finished processing the buffer.

So instead of doing the dma-buf unmapping in __vb2_dqbuf(), it can be made
in vb2_buffer_done() after the driver notified that buf processing is done.

Decoupling the buffer dequeue from the dma-buf unmapping has also the side
effect of making possible to add dma-buf fence support in the future since
the buffer could be dequeued even before the driver has finished using it.

Signed-off-by: Javier Martinez Canillas 

---
Hello,

I've tested this patch doing DMA buffer sharing between a
vivid input and output device with both v4l2-ctl and gst:

$ v4l2-ctl -d0 -e1 --stream-dmabuf --stream-out-mmap
$ v4l2-ctl -d0 -e1 --stream-mmap --stream-out-dmabuf
$ gst-launch-1.0 v4l2src device=/dev/video0 io-mode=dmabuf ! v4l2sink 
device=/dev/video1 io-mode=dmabuf-import

And I didn't find any issues but more testing will be appreciated.

Best regards,
Javier

 drivers/media/v4l2-core/videobuf2-core.c | 34 +---
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 7128b09810be..973331efaf79 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -958,6 +958,22 @@ void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned int 
plane_no)
 EXPORT_SYMBOL_GPL(vb2_plane_cookie);
 
 /**
+ * __vb2_unmap_dmabuf() - unmap dma-buf attached to buffer planes
+ */
+static void __vb2_unmap_dmabuf(struct vb2_buffer *vb)
+{
+   int i;
+
+   for (i = 0; i < vb->num_planes; ++i) {
+   if (!vb->planes[i].dbuf_mapped)
+   continue;
+   call_void_memop(vb, unmap_dmabuf,
+   vb->planes[i].mem_priv);
+   vb->planes[i].dbuf_mapped = 0;
+   }
+}
+
+/**
  * vb2_buffer_done() - inform videobuf that an operation on a buffer is 
finished
  * @vb:vb2_buffer returned from the driver
  * @state: either VB2_BUF_STATE_DONE if the operation finished 
successfully,
@@ -1028,6 +1044,9 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
__enqueue_in_driver(vb);
return;
default:
+   if (q->memory == VB2_MEMORY_DMABUF)
+   __vb2_unmap_dmabuf(vb);
+
/* Inform any processes that may be waiting for buffers */
wake_up(>done_wq);
break;
@@ -1708,23 +1727,11 @@ EXPORT_SYMBOL_GPL(vb2_wait_for_all_buffers);
  */
 static void __vb2_dqbuf(struct vb2_buffer *vb)
 {
-   struct vb2_queue *q = vb->vb2_queue;
-   unsigned int i;
-
/* nothing to do if the buffer is already dequeued */
if (vb->state == VB2_BUF_STATE_DEQUEUED)
return;
 
vb->state = VB2_BUF_STATE_DEQUEUED;
-
-   /* unmap DMABUF buffer */
-   if (q->memory == VB2_MEMORY_DMABUF)
-   for (i = 0; i < vb->num_planes; ++i) {
-   if (!vb->planes[i].dbuf_mapped)
-   continue;
-   call_void_memop(vb, unmap_dmabuf, 
vb->planes[i].mem_priv);
-   vb->planes[i].dbuf_mapped = 0;
-   }
 }
 
 /**
@@ -1861,6 +1868,9 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
call_void_vb_qop(vb, buf_finish, vb);
}
__vb2_dqbuf(vb);
+
+   if (q->memory == VB2_MEMORY_DMABUF)
+   __vb2_unmap_dmabuf(vb);
}
 }
 
-- 
2.5.5

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

Re: [PATCH] af9035: fix dual tuner detection with PCTV 79e

[basic . master]

Am 17.07.2016 um 10:59 schrieb Antti Palosaari:
> On 07/16/2016 11:05 PM, Stefan Pöschel wrote:
>> Am 15.07.2016 um 08:21 schrieb Antti Palosaari:
>>> Applied and PULL requested for 4.7.
>>
>> Great, thanks!
>>
>>> Anyhow, it does not apply for 4.6. You must backport that patch to 4.6
>>> stable also!
>>
>> I have never done backporting before, so I need some advice I think:
>> Am I right that I have to create the patch, now just based on tag "v4.6"
>> of the media_tree repo?
> 
> Just make patch that compiles and works against kernel tag v4.6. No need to 
> backport it to media_tree or media_build. It should go 4.6 kernel stable tree.

Please find the backport patch below. Is sending to this ML here enough or are 
there any further steps needed to do by me?

Regards,
Stefan
-




The value 5 of the EEPROM_TS_MODE register (meaning dual tuner presence) is
only valid for AF9035 devices. For IT9135 devices it is invalid and led to a
false positive dual tuner mode detection with PCTV 79e.
Therefore on non-AF9035 devices and with value 5 the driver now defaults to
single tuner mode and outputs a regarding info message to log.

This fixes Bugzilla bug #118561.

(backport of 4.7)

Reported-by: Marc Duponcheel 
Signed-off-by: Stefan Pöschel 
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 53 +++
 drivers/media/usb/dvb-usb-v2/af9035.h |  2 +-
 2 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 2638e32..14dbfeb 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -475,7 +475,8 @@ static struct i2c_algorithm af9035_i2c_algo = {
 static int af9035_identify_state(struct dvb_usb_device *d, const char **name)
 {
struct state *state = d_to_priv(d);
-   int ret;
+   int ret, ts_mode_invalid;
+   u8 tmp;
u8 wbuf[1] = { 1 };
u8 rbuf[4];
struct usb_req req = { CMD_FW_QUERYINFO, 0, sizeof(wbuf), wbuf,
@@ -511,6 +512,38 @@ static int af9035_identify_state(struct dvb_usb_device *d, 
const char **name)
state->eeprom_addr = EEPROM_BASE_AF9035;
}

+
+   /* check for dual tuner mode */
+   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
+   if (ret < 0)
+   goto err;
+
+   ts_mode_invalid = 0;
+   switch (tmp) {
+   case 0:
+   break;
+   case 1:
+   case 3:
+   state->dual_mode = true;
+   break;
+   case 5:
+   if (state->chip_type != 0x9135 && state->chip_type != 0x9306)
+   state->dual_mode = true;/* AF9035 */
+   else
+   ts_mode_invalid = 1;
+   break;
+   default:
+   ts_mode_invalid = 1;
+   }
+
+   dev_dbg(>udev->dev, "%s: ts mode=%d dual mode=%d\n",
+   __func__, tmp, state->dual_mode);
+
+   if (ts_mode_invalid)
+   dev_info(>udev->dev, "%s: ts mode=%d not supported, 
defaulting to single tuner mode!",
+   __func__, tmp);
+
+
ret = af9035_ctrl_msg(d, );
if (ret < 0)
goto err;
@@ -680,11 +713,7 @@ static int af9035_download_firmware(struct dvb_usb_device 
*d,
 * which is done by master demod.
 * Master feeds also clock and controls power via GPIO.
 */
-   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
-   if (ret < 0)
-   goto err;
-
-   if (tmp == 1 || tmp == 3 || tmp == 5) {
+   if (state->dual_mode) {
/* configure gpioh1, reset & power slave demod */
ret = af9035_wr_reg_mask(d, 0x00d8b0, 0x01, 0x01);
if (ret < 0)
@@ -817,18 +846,6 @@ static int af9035_read_config(struct dvb_usb_device *d)
}


-
-   /* check if there is dual tuners */
-   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
-   if (ret < 0)
-   goto err;
-
-   if (tmp == 1 || tmp == 3 || tmp == 5)
-   state->dual_mode = true;
-
-   dev_dbg(>udev->dev, "%s: ts mode=%d dual mode=%d\n", __func__,
-   tmp, state->dual_mode);
-
if (state->dual_mode) {
/* read 2nd demodulator I2C address */
ret = af9035_rd_reg(d,
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h 
b/drivers/media/usb/dvb-usb-v2/af9035.h
index df22001..d50ff15 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.h
+++ b/drivers/media/usb/dvb-usb-v2/af9035.h
@@ -112,7 +112,7 @@ static const u32 clock_lut_it9135[] = {
  * 0  TS
  * 1  DCA + PIP
  * 3  PIP
- * 5  DCA + PIP
+ * 5  DCA + PIP (AF9035 only)
  * n  DCA
  *
  * Values 0, 3 and 5 are seen to this day. 0 for single TS and 3/5 for dual TS.
-- 
2.9.1
--
To unsubscribe from this list: send the 

Re: [PATCH v2 01/10] v4l: of: add "newavmode" property for Analog Devices codecs

[Steve Longerbeam]

On 07/20/2016 12:37 AM, Hans Verkuil wrote:
> On 07/20/2016 02:03 AM, Steve Longerbeam wrote:
>> This patch adds a "newavmode" boolean property as part of the v4l2 endpoint
>> properties. This indicates an Analog Devices decoder is generating EAV/SAV
>> codes to suit Analog Devices encoders.
>>
>> Signed-off-by: Steve Longerbeam 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Javier Martinez Canillas 
>> Cc: Laurent Pinchart 
>> Cc: Sakari Ailus 
>> ---
>>  Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
>>  drivers/media/v4l2-core/v4l2-of.c| 4 
>>  include/media/v4l2-mediabus.h| 5 +
>>  3 files changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
>> b/Documentation/devicetree/bindings/media/video-interfaces.txt
>> index 9cd2a36..6f2df51 100644
>> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
>> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
>> @@ -88,6 +88,8 @@ Optional endpoint properties
>>  - field-even-active: field signal level during the even field data 
>> transmission.
>>  - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel 
>> clock
>>signal.
>> +- newavmode: a boolean property to indicate an Analog Devices decoder is
>> +  operating in NEWAVMODE. Valid for BT.656 busses only.
> This property is adv7180 specific and does not belong here.

Hi Hans, yes that was my initial reaction to this idea as well, but
you didn't respond to my first request for comment.

>
> Add this to Documentation/devicetree/bindings/media/i2c/adv7180.txt instead.

Yes, I'll move this property into adv7180.

Steve


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

Re: em288xx and lna - how to enable?

[Martin]

> Hi,
>
> I see that my card 292e has LNA support:
> https://patchwork.linuxtv.org/patch/23763/
>
> but searching I can't find how to enable this the force option
> force_lna_activation=1 that the t500 uses isn't recognised
>
> Please could someone tell me if this is configurable an if so how to
> configure it?

Turns out I was looking in the wrong place.

I found it after more searching - it's part of the API and can be enabled
with the dvbv5-zap --lna=1


Regards,
M


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

[PATCH 1/2] [media] redrat3: remove hw_timeout member

[Sean Young]

This is a duplicate of the timeout in rc_dev.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 399f44d..4739bce 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -188,9 +188,6 @@ struct redrat3_dev {
/* usb dma */
dma_addr_t dma_in;
 
-   /* rx signal timeout */
-   u32 hw_timeout;
-
/* Is the device currently transmitting?*/
bool transmitting;
 
@@ -372,7 +369,7 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
/* add a trailing space */
rawir.pulse = false;
rawir.timeout = true;
-   rawir.duration = US_TO_NS(rr3->hw_timeout);
+   rawir.duration = rr3->rc->timeout;
dev_dbg(dev, "storing trailing timeout with duration %d\n",
rawir.duration);
ir_raw_event_store_with_filter(rr3->rc, );
@@ -495,10 +492,9 @@ static int redrat3_set_timeout(struct rc_dev *rc_dev, 
unsigned int timeoutns)
dev_dbg(dev, "set ir parm timeout %d ret 0x%02x\n",
be32_to_cpu(*timeout), ret);
 
-   if (ret == sizeof(*timeout)) {
-   rr3->hw_timeout = timeoutns / 1000;
+   if (ret == sizeof(*timeout))
ret = 0;
-   } else if (ret >= 0)
+   else if (ret >= 0)
ret = -EIO;
 
kfree(timeout);
@@ -889,7 +885,7 @@ static struct rc_dev *redrat3_init_rc_dev(struct 
redrat3_dev *rr3)
rc->allowed_protocols = RC_BIT_ALL;
rc->min_timeout = MS_TO_NS(RR3_RX_MIN_TIMEOUT);
rc->max_timeout = MS_TO_NS(RR3_RX_MAX_TIMEOUT);
-   rc->timeout = US_TO_NS(rr3->hw_timeout);
+   rc->timeout = US_TO_NS(redrat3_get_timeout(rr3));
rc->s_timeout = redrat3_set_timeout;
rc->tx_ir = redrat3_transmit_ir;
rc->s_tx_carrier = redrat3_set_tx_carrier;
@@ -1000,9 +996,6 @@ static int redrat3_dev_probe(struct usb_interface *intf,
if (retval < 0)
goto error;
 
-   /* store current hardware timeout, in µs */
-   rr3->hw_timeout = redrat3_get_timeout(rr3);
-
/* default.. will get overridden by any sends with a freq defined */
rr3->carrier = 38000;
 
-- 
2.7.4

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

[PATCH 2/2] [media] redrat3: hardware-specific parameters

[Sean Young]

Add these options as module parameters for now; should other drivers
need similar options we could add it to the LIRC api.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 4739bce..68df9d7 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -124,6 +124,41 @@
 #define USB_RR3USB_PRODUCT_ID  0x0001
 #define USB_RR3IIUSB_PRODUCT_ID0x0005
 
+
+/*
+ * The redrat3 encodes an IR signal as set of different lengths and a set
+ * of indices into those lengths. This sets how much two lengths must
+ * differ before they are considered distinct, the value is specified
+ * in microseconds.
+ * Default 5, value 0 to 127.
+ */
+static int length_fuzz = 5;
+module_param(length_fuzz, uint, 0644);
+MODULE_PARM_DESC(length_fuzz, "Length Fuzz (0-127)");
+
+/*
+ * When receiving a continuous ir stream (for example when a user is
+ * holding a button down on a remote), this specifies the minimum size
+ * of a space when the redrat3 sends a irdata packet to the host. Specified
+ * in miliseconds. Default value 18ms.
+ * The value can be between 2 and 30 inclusive.
+ */
+static int minimum_pause = 18;
+module_param(minimum_pause, uint, 0644);
+MODULE_PARM_DESC(minimum_pause, "Minimum Pause in ms (2-30)");
+
+/*
+ * The carrier frequency is measured during the first pulse of the IR
+ * signal. The larger the number of periods used To measure, the more
+ * accurate the result is likely to be, however some signals have short
+ * initial pulses, so in some case it may be necessary to reduce this value.
+ * Default 8, value 1 to 255.
+ */
+static int periods_measure_carrier = 8;
+module_param(periods_measure_carrier, uint, 0644);
+MODULE_PARM_DESC(periods_measure_carrier, "Number of Periods to Measure 
Carrier (1-255)");
+
+
 struct redrat3_header {
__be16 length;
__be16 transfer_type;
@@ -525,12 +560,25 @@ static void redrat3_reset(struct redrat3_dev *rr3)
 RR3_CPUCS_REG_ADDR, 0, val, len, HZ * 25);
dev_dbg(dev, "reset returned 0x%02x\n", rc);
 
-   *val = 5;
+   *val = length_fuzz;
rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
 USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
 RR3_IR_IO_LENGTH_FUZZ, 0, val, len, HZ * 25);
dev_dbg(dev, "set ir parm len fuzz %d rc 0x%02x\n", *val, rc);
 
+   *val = (65536 - (minimum_pause * 2000)) / 256;
+   rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+RR3_IR_IO_MIN_PAUSE, 0, val, len, HZ * 25);
+   dev_dbg(dev, "set ir parm min pause %d rc 0x%02x\n", *val, rc);
+
+   *val = periods_measure_carrier;
+   rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+RR3_IR_IO_PERIODS_MF, 0, val, len, HZ * 25);
+   dev_dbg(dev, "set ir parm periods measure carrier %d rc 0x%02x", *val,
+   rc);
+
*val = RR3_DRIVER_MAXLENS;
rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
 USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
-- 
2.7.4

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

[PATCH] [media] vb2: remove TODO comment for dma-buf in QBUF

[Javier Martinez Canillas]

There is a TODO comment about the dma-buf being mapped in VIDIOC_QBUF
instead of doing it closer to when the actual DMA is going to happen
when the buffers are queued in the driver (i.e: __enqueue_in_driver).

But there is a reason to do it earlier in QBUF, and is that userspace
has no way to know if a exported dma-buf can be imported successfully
and so relies on QBUF succeeding as indication that the dma-buf mapped.

If QBUF fails, the application can fallback to another streaming I/O
method. But moving the dma-buf mapping later when queueing the buffers
can be too late for userspace to recover, since it may had dropped the
buffer(s) already when it knows that the dma-buf mapping failed.

So remove the TODO instead and change the comment to explain this.

Suggested-by: Hans Verkuil 
Signed-off-by: Javier Martinez Canillas 

---
Hello,

This patch was suggested by Hans as a feedback in a previous patch
that attempted to get rid of the TODO by moving the dma-buf mapping:

https://lkml.org/lkml/2016/7/20/338

Best regards,
Javier

 drivers/media/v4l2-core/videobuf2-core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index bbba50d6e1ad..7128b09810be 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1272,9 +1272,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
vb->planes[plane].mem_priv = mem_priv;
}
 
-   /* TODO: This pins the buffer(s) with  dma_buf_map_attachment()).. but
-* really we want to do this just before the DMA, not while queueing
-* the buffer(s)..
+   /*
+* This pins the buffer(s) with dma_buf_map_attachment()). It's done
+* here instead just before the DMA, while queueing the buffer(s) so
+* userspace knows sooner rather than later if the dma-buf map fails.
 */
for (plane = 0; plane < vb->num_planes; ++plane) {
ret = call_memop(vb, map_dmabuf, vb->planes[plane].mem_priv);
-- 
2.5.5

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

[PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

[Javier Martinez Canillas]

If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's
useful to get the invalid and minimum lengths as a debug info.

Before this patch:

vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1

After this patch:

vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1, minimum 
length 410880

Signed-off-by: Javier Martinez Canillas 

---

Changes in v2:
- Use %u instead of %d (Sakari Ailus)
- Include min_length (Sakari Ailus)

 drivers/media/v4l2-core/videobuf2-core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index b6fbc04f9699..bbba50d6e1ad 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1227,8 +1227,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
planes[plane].length = dbuf->size;
 
if (planes[plane].length < vb->planes[plane].min_length) {
-   dprintk(1, "invalid dmabuf length for plane %d\n",
-   plane);
+   dprintk(1, "invalid dmabuf length %u for plane %d, "
+   "minimum length %u\n",
+   planes[plane].length, plane,
+   vb->planes[plane].min_length);
dma_buf_put(dbuf);
ret = -EINVAL;
goto err;
-- 
2.5.5

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

Re: [PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Markus Heiser]

Am 20.07.2016 um 17:06 schrieb Mauro Carvalho Chehab :

> Em Wed, 20 Jul 2016 16:49:59 +0200
> Markus Heiser  escreveu:
> 
>> Am 20.07.2016 um 16:31 schrieb Jonathan Corbet :
>> 
>>> On Wed, 20 Jul 2016 16:23:28 +0200
>>> Markus Heiser  wrote:
>>> 
 Am 20.07.2016 um 16:11 schrieb Mauro Carvalho Chehab 
 :
 
> Sphinx 1.4.5 complains about some literal blocks at
> kernel-documentation.rst:
> 
>   Documentation/kernel-documentation.rst:373: WARNING: Could not lex 
> literal_block as "C". Highlighting skipped.
>   Documentation/kernel-documentation.rst:378: WARNING: Could not lex 
> literal_block as "C". Highlighting skipped.
>   Documentation/kernel-documentation.rst:576: WARNING: Could not lex 
> literal_block as "C". Highlighting skipped.
> 
> Fix it by telling Sphinx to consider them as "none" type.
 
 Hi Mauro,
 
 IMHO we should better fix this by unsetting the lexers default language 
 in the conf.py  [1] ... currently:
 
 highlight_language = 'C'  # set this to 'none'

 As far as I know the default highlight_language is also the default
 for literal blocks starting with "::"  
>>> 
>>> The thing with that is that a lot of literal blocks *do* have C code, even
>>> in kernel-documentation.rst.  Setting that in conf.py would turn off all C
>>> highlighting.  I think that might actually be a desirable outcome, but it
>>> would be good to make that decision explicitly.
>>> 
>>> As it happens, I'd already fixed these particular warnings in docs-next:
>>> 
>>> http://permalink.gmane.org/gmane.linux.documentation/39806
>>> 
>>> I took a different approach; using code-block might actually be better.  
>> 
>> In some kernel-doc comments we have constructs like this:
>> 
>> * host point of view, the graphic address space is partitioned by multiple
>> * vGPUs in different VMs.::
>> *
>> *vGPU1 view Host view
>> * 0 --> +---+ +---+
>> *   ^   |///| |   vGPU3   |
>> *   |   |///| +---+
>> *   |   |///| |   vGPU2   |
>> *   |   +---+ +---+
>> *mappable GM| available | ==> |   vGPU1   |
>> *   |   +---+ +---+
>> 
>> I mean, in kernel-doc comments it would be nice to have no lexer
>> active when starting a literal block with a double colon "::".
>> Introducing a none highlighted literal block with a directive
>> like ".. highlight::" or ".. code-block" is a bit verbose
>> for a C comment.  And on the opposite, if one place a C construct
>> in a literal block with a double colon "::", only the highlighting
>> is missed, but we get now warning.
>> 
>> At least a code-block should be a code block, not a diagram 
>> or anything other ...
>> 
>> I don't know whats the best ... but these are my 2cent :)
> 
> I actually think that the best would be if we could have a way to
> "draw" graphs inside the documentation.

please .. not yet ;-)  ... we have so many problem sites to 
close first ... graphiz & Co. bring additional dependencies
to fulfill in context with sphinx 1.2 ...

> We have a few cases of
> diagrams like the above at the media documentation too.
> 
> As Sphinx seems to like ASCIIart, IMHO, the more Sphinx-style
> way would be to have a:
> 
> .. code-block:: asciiart

> 
> markup to handle it.

why a special markup for a literal block?

-- M --

> Another possibility would be to have a graphviz extension.
> 
>> 
>> --Markus--
>> 
>> 
>>> 
>>> jon
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html  
>> 
> 
> 
> 
> Thanks,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Mauro Carvalho Chehab]

Em Wed, 20 Jul 2016 16:49:59 +0200
Markus Heiser  escreveu:

> Am 20.07.2016 um 16:31 schrieb Jonathan Corbet :
> 
> > On Wed, 20 Jul 2016 16:23:28 +0200
> > Markus Heiser  wrote:
> >   
> >> Am 20.07.2016 um 16:11 schrieb Mauro Carvalho Chehab 
> >> :
> >>   
> >>> Sphinx 1.4.5 complains about some literal blocks at
> >>> kernel-documentation.rst:
> >>> 
> >>>   Documentation/kernel-documentation.rst:373: WARNING: Could not lex 
> >>> literal_block as "C". Highlighting skipped.
> >>>   Documentation/kernel-documentation.rst:378: WARNING: Could not lex 
> >>> literal_block as "C". Highlighting skipped.
> >>>   Documentation/kernel-documentation.rst:576: WARNING: Could not lex 
> >>> literal_block as "C". Highlighting skipped.
> >>> 
> >>> Fix it by telling Sphinx to consider them as "none" type.
> >> 
> >> Hi Mauro,
> >> 
> >> IMHO we should better fix this by unsetting the lexers default language 
> >> in the conf.py  [1] ... currently:
> >> 
> >> highlight_language = 'C'  # set this to 'none'
> >>
> >> As far as I know the default highlight_language is also the default
> >> for literal blocks starting with "::"  
> > 
> > The thing with that is that a lot of literal blocks *do* have C code, even
> > in kernel-documentation.rst.  Setting that in conf.py would turn off all C
> > highlighting.  I think that might actually be a desirable outcome, but it
> > would be good to make that decision explicitly.
> > 
> > As it happens, I'd already fixed these particular warnings in docs-next:
> > 
> > http://permalink.gmane.org/gmane.linux.documentation/39806
> > 
> > I took a different approach; using code-block might actually be better.  
> 
> In some kernel-doc comments we have constructs like this:
> 
>  * host point of view, the graphic address space is partitioned by multiple
>  * vGPUs in different VMs.::
>  *
>  *vGPU1 view Host view
>  * 0 --> +---+ +---+
>  *   ^   |///| |   vGPU3   |
>  *   |   |///| +---+
>  *   |   |///| |   vGPU2   |
>  *   |   +---+ +---+
>  *mappable GM| available | ==> |   vGPU1   |
>  *   |   +---+ +---+
> 
> I mean, in kernel-doc comments it would be nice to have no lexer
> active when starting a literal block with a double colon "::".
> Introducing a none highlighted literal block with a directive
> like ".. highlight::" or ".. code-block" is a bit verbose
> for a C comment.  And on the opposite, if one place a C construct
> in a literal block with a double colon "::", only the highlighting
> is missed, but we get now warning.
> 
> At least a code-block should be a code block, not a diagram 
> or anything other ...
> 
> I don't know whats the best ... but these are my 2cent :)

I actually think that the best would be if we could have a way to
"draw" graphs inside the documentation. We have a few cases of
diagrams like the above at the media documentation too.

As Sphinx seems to like ASCIIart, IMHO, the more Sphinx-style
way would be to have a:

.. code-block:: asciiart

markup to handle it.

Another possibility would be to have a graphviz extension.

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



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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

Hi,

On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 17:13 GMT+03:00 Bin Liu :
> > Hi,
> >
> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
> >> > Hi,
> >> >
> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> >> >> >> Hello,
> >> >> >>
> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x 
> >> >> >> based BeagleBoneBlack SBC.
> >> >> >> I am sure that both of them are fine and work properly.
> >> >> >> I am running Linux 4.6.4 (my kernel config is available at 
> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
> >> >> >> issue with frame transfer when high resolution formats are used.
> >> >> >>
> >> >> >> The issue is the following. I use simple v4l2 example tool (taken 
> >> >> >> from API docs), which source code is available at 
> >> >> >> http://pastebin.com/grcNXxfe
> >> >> >>
> >> >> >> When I use (see line 488) 640x480 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width   = 640;
> >> >> >> fmt.fmt.pix.height  = 480;
> >> >> >>
> >> >> >> then I get "select timeout" and don't get any frames.
> >> >> >>
> >> >> >> When I use 320x240 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width   = 320;
> >> >> >> fmt.fmt.pix.height  = 240;
> >> >> >>
> >> >> >> then about 60% frames are missed. An example outpout of ./a.out -f 
> >> >> >> is available at https://yadi.sk/d/aRka8xWPtSc4y
> >> >> >> It looks like there are pauses between bulks of frames (frame 
> >> >> >> counter and timestamp as returned from v4l2 API):
> >> >> >>
> >> >> >> 3 3705.142553
> >> >> >> 8 3705.342533
> >> >> >> 13 3705.542517
> >> >> >> 110 3708.776208
> >> >> >> 115 3708.976190
> >> >> >> 120 3709.176169
> >> >> >> 125 3709.376152
> >> >> >> 130 3709.576144
> >> >> >> 226 3712.807848
> >> >> >>
> >> >> >> When I use tiny 160x120 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width   = 160;
> >> >> >> fmt.fmt.pix.height  = 120;
> >> >> >>
> >> >> >> then more frames are received. See output example at 
> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
> >> >> >> That is why I thought that everything was fine in May when used tiny 
> >> >> >> xawtv window to check kernel OOPS presence (see 
> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
> >> >> >>
> >> >> >> Even more. When I introduce USB hub between the host and the webcam, 
> >> >> >> I can not receive even any 320x240 frames.
> >> >> >>
> >> >> >> I've managed to use ftrace to see what is going on when no frames 
> >> >> >> are received.
> >> >> >> I've found that pwc_isoc_handler is called frequently as the 
> >> >> >> following:
> >> >> >>
> >> >> >>  0)   |  pwc_isoc_handler [pwc]() {
> >> >> >>  0)   |usb_submit_urb [usbcore]() {
> >> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
> >> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
> >> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
> >> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
> >> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
> >> >> >>  0)   5.750 us|  }
> >> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
> >> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
> >> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
> >> >> >>  0)   0.792 us|  _raw_spin_lock();
> >> >> >>  0)   0.791 us|  _raw_spin_unlock();
> >> >> >>  0) + 10.500 us   |}
> >> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
> >> >> >>  0) + 25.375 us   |  }
> >> >> >>  0) + 45.208 us   |}
> >> >> >>  0) + 51.042 us   |  }
> >> >> >>  0) + 56.084 us   |}
> >> >> >>  0) + 61.292 us   |  }
> >> >> >>
> >> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why 
> >> >> >> I get "select timeout" in userspace.
> >> >> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y 
> >> >> >> but I can recompile it, if you think that it could provide more 
> >> >> >> information. I am also ready to perform additional tests (use usbmon 
> >> >> >> maybe?).
> >> >> >>
> >> >> >> How could this issue be resolved?
> >> >> >>
> >> >> >> Thank you.
> >> >> >
> >> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
> >> >> > issue in CPPI Isoch transfer, in which the MUSB controller only sends 
> >> >> > IN
> >> >> > tokens in every other SOF, so only half of the bus bandwidth is
> >> >> > utilized, which causes video frame drops in higher 

Re: [PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Markus Heiser]

Am 20.07.2016 um 16:31 schrieb Jonathan Corbet :

> On Wed, 20 Jul 2016 16:23:28 +0200
> Markus Heiser  wrote:
> 
>> Am 20.07.2016 um 16:11 schrieb Mauro Carvalho Chehab 
>> :
>> 
>>> Sphinx 1.4.5 complains about some literal blocks at
>>> kernel-documentation.rst:
>>> 
>>> Documentation/kernel-documentation.rst:373: WARNING: Could not lex 
>>> literal_block as "C". Highlighting skipped.
>>> Documentation/kernel-documentation.rst:378: WARNING: Could not lex 
>>> literal_block as "C". Highlighting skipped.
>>> Documentation/kernel-documentation.rst:576: WARNING: Could not lex 
>>> literal_block as "C". Highlighting skipped.
>>> 
>>> Fix it by telling Sphinx to consider them as "none" type.  
>> 
>> Hi Mauro,
>> 
>> IMHO we should better fix this by unsetting the lexers default language 
>> in the conf.py  [1] ... currently:
>> 
>> highlight_language = 'C'  # set this to 'none'
>>  
>> As far as I know the default highlight_language is also the default
>> for literal blocks starting with "::"
> 
> The thing with that is that a lot of literal blocks *do* have C code, even
> in kernel-documentation.rst.  Setting that in conf.py would turn off all C
> highlighting.  I think that might actually be a desirable outcome, but it
> would be good to make that decision explicitly.
> 
> As it happens, I'd already fixed these particular warnings in docs-next:
> 
>   http://permalink.gmane.org/gmane.linux.documentation/39806
> 
> I took a different approach; using code-block might actually be better.

In some kernel-doc comments we have constructs like this:

 * host point of view, the graphic address space is partitioned by multiple
 * vGPUs in different VMs.::
 *
 *vGPU1 view Host view
 * 0 --> +---+ +---+
 *   ^   |///| |   vGPU3   |
 *   |   |///| +---+
 *   |   |///| |   vGPU2   |
 *   |   +---+ +---+
 *mappable GM| available | ==> |   vGPU1   |
 *   |   +---+ +---+

I mean, in kernel-doc comments it would be nice to have no lexer
active when starting a literal block with a double colon "::".
Introducing a none highlighted literal block with a directive
like ".. highlight::" or ".. code-block" is a bit verbose
for a C comment.  And on the opposite, if one place a C construct
in a literal block with a double colon "::", only the highlighting
is missed, but we get now warning.

At least a code-block should be a code block, not a diagram 
or anything other ...

I don't know whats the best ... but these are my 2cent :)

--Markus--


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

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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 17:13 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> >> > Hi,
>> >> >
>> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> >> Hello,
>> >> >>
>> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
>> >> >> BeagleBoneBlack SBC.
>> >> >> I am sure that both of them are fine and work properly.
>> >> >> I am running Linux 4.6.4 (my kernel config is available at 
>> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
>> >> >> issue with frame transfer when high resolution formats are used.
>> >> >>
>> >> >> The issue is the following. I use simple v4l2 example tool (taken from 
>> >> >> API docs), which source code is available at 
>> >> >> http://pastebin.com/grcNXxfe
>> >> >>
>> >> >> When I use (see line 488) 640x480 frames
>> >> >>
>> >> >> fmt.fmt.pix.width   = 640;
>> >> >> fmt.fmt.pix.height  = 480;
>> >> >>
>> >> >> then I get "select timeout" and don't get any frames.
>> >> >>
>> >> >> When I use 320x240 frames
>> >> >>
>> >> >> fmt.fmt.pix.width   = 320;
>> >> >> fmt.fmt.pix.height  = 240;
>> >> >>
>> >> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
>> >> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> >> It looks like there are pauses between bulks of frames (frame counter 
>> >> >> and timestamp as returned from v4l2 API):
>> >> >>
>> >> >> 3 3705.142553
>> >> >> 8 3705.342533
>> >> >> 13 3705.542517
>> >> >> 110 3708.776208
>> >> >> 115 3708.976190
>> >> >> 120 3709.176169
>> >> >> 125 3709.376152
>> >> >> 130 3709.576144
>> >> >> 226 3712.807848
>> >> >>
>> >> >> When I use tiny 160x120 frames
>> >> >>
>> >> >> fmt.fmt.pix.width   = 160;
>> >> >> fmt.fmt.pix.height  = 120;
>> >> >>
>> >> >> then more frames are received. See output example at 
>> >> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> >> That is why I thought that everything was fine in May when used tiny 
>> >> >> xawtv window to check kernel OOPS presence (see 
>> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >> >>
>> >> >> Even more. When I introduce USB hub between the host and the webcam, I 
>> >> >> can not receive even any 320x240 frames.
>> >> >>
>> >> >> I've managed to use ftrace to see what is going on when no frames are 
>> >> >> received.
>> >> >> I've found that pwc_isoc_handler is called frequently as the following:
>> >> >>
>> >> >>  0)   |  pwc_isoc_handler [pwc]() {
>> >> >>  0)   |usb_submit_urb [usbcore]() {
>> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >> >>  0)   5.750 us|  }
>> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>> >> >>  0)   0.792 us|  _raw_spin_lock();
>> >> >>  0)   0.791 us|  _raw_spin_unlock();
>> >> >>  0) + 10.500 us   |}
>> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>> >> >>  0) + 25.375 us   |  }
>> >> >>  0) + 45.208 us   |}
>> >> >>  0) + 51.042 us   |  }
>> >> >>  0) + 56.084 us   |}
>> >> >>  0) + 61.292 us   |  }
>> >> >>
>> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I 
>> >> >> get "select timeout" in userspace.
>> >> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y 
>> >> >> but I can recompile it, if you think that it could provide more 
>> >> >> information. I am also ready to perform additional tests (use usbmon 
>> >> >> maybe?).
>> >> >>
>> >> >> How could this issue be resolved?
>> >> >>
>> >> >> Thank you.
>> >> >
>> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>> >> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
>> >> > tokens in every other SOF, so only half of the bus bandwidth is
>> >> > utilized, which causes video frame drops in higher resolution.
>> >> >
>> >>
>> >> Yes, I do use DMA:
>> >>
>> >> CONFIG_USB_TI_CPPI41_DMA=y
>> >
>> > Okay.
>> >
>> >>
>> >> > To confirm this, use a bus analyzer to capture a bus trace, you would
>> >> > see no IN tokens in every other SOF while transfering Isoch packets.
>> >> >
>> >>
>> >> I am sorry, I am new to 

[PATCH 2/5] [media] doc-rst: Fix some Sphinx warnings

[Mauro Carvalho Chehab]

Fix all remaining media warnings with ReST that are fixable
without changing at the Sphinx code.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx88.rst| 1 +
 Documentation/media/v4l-drivers/tm6000-cardlist.rst | 2 +-
 drivers/media/dvb-core/dvb_math.h   | 7 +++
 include/media/media-entity.h| 6 --
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/media/v4l-drivers/cx88.rst 
b/Documentation/media/v4l-drivers/cx88.rst
index 97865007f51f..d8f3a014726a 100644
--- a/Documentation/media/v4l-drivers/cx88.rst
+++ b/Documentation/media/v4l-drivers/cx88.rst
@@ -119,6 +119,7 @@ GPIO 16(I believe) is tied to the IR port (if present).
 From the data sheet:
 
 - Register 24'h20004  PCI Interrupt Status
+
  - bit [18]  IR_SMP_INT Set when 32 input samples have been collected over
  - gpio[16] pin into GP_SAMPLE register.
 
diff --git a/Documentation/media/v4l-drivers/tm6000-cardlist.rst 
b/Documentation/media/v4l-drivers/tm6000-cardlist.rst
index ca08d4214b38..2fbd3886b5f0 100644
--- a/Documentation/media/v4l-drivers/tm6000-cardlist.rst
+++ b/Documentation/media/v4l-drivers/tm6000-cardlist.rst
@@ -1,5 +1,5 @@
 TM6000 cards list
-===
+=
 
 .. code-block:: none
 
diff --git a/drivers/media/dvb-core/dvb_math.h 
b/drivers/media/dvb-core/dvb_math.h
index 34dc1df03cab..2f0326674ca6 100644
--- a/drivers/media/dvb-core/dvb_math.h
+++ b/drivers/media/dvb-core/dvb_math.h
@@ -30,11 +30,15 @@
  * @value: The value (must be != 0)
  *
  * to use rational values you can use the following method:
+ *
  *   intlog2(value) = intlog2(value * 2^x) - x * 2^24
  *
  * Some usecase examples:
+ *
  * intlog2(8) will give 3 << 24 = 3 * 2^24
+ *
  * intlog2(9) will give 3 << 24 + ... = 3.16... * 2^24
+ *
  * intlog2(1.5) = intlog2(3) - 2^24 = 0.584... * 2^24
  *
  *
@@ -48,10 +52,13 @@ extern unsigned int intlog2(u32 value);
  * @value: The value (must be != 0)
  *
  * to use rational values you can use the following method:
+ *
  *   intlog10(value) = intlog10(value * 10^x) - x * 2^24
  *
  * An usecase example:
+ *
  * intlog10(1000) will give 3 << 24 = 3 * 2^24
+ *
  *   due to the implementation intlog10(1000) might be not exactly 3 * 2^24
  *
  * look at intlog2 for similar examples
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 83877719bef4..3d885d97d149 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -180,8 +180,10 @@ struct media_pad {
  * view. The media_entity_pipeline_start() function
  * validates all links by calling this operation. Optional.
  *
- * .. note:: Those these callbacks are called with struct 
media_device.@graph_mutex
- * mutex held.
+ * .. note::
+ *
+ *Those these callbacks are called with struct media_device.@graph_mutex
+ *mutex held.
  */
 struct media_entity_operations {
int (*link_setup)(struct media_entity *entity,
-- 
2.7.4

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

[PATCH 5/5] [media] doc-rst: Fix license for the media books

[Mauro Carvalho Chehab]

The kAPI, v4l-drivers and dvb-drivers never used the
GNU FDL license. The addition of such license header were
just due to copy-and-paste. So, let's fix it.

As the media_kapi were part of device-drivers.tmp, it is
under GPL v2+.

The other two books is an agregation of files without any
license explicitly specified. So, they're all bound to the
Kernel's COPYING license. So, they're GPL v2 only.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/dvb-drivers/index.rst | 15 ++-
 Documentation/media/media_kapi.rst| 16 +++-
 Documentation/media/v4l-drivers/index.rst | 15 ++-
 3 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/Documentation/media/dvb-drivers/index.rst 
b/Documentation/media/dvb-drivers/index.rst
index e4c2e74db9dc..ea0da6d63299 100644
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -8,11 +8,16 @@ Linux Digital TV driver-specific documentation
 
 **Copyright** |copy| 2001-2016 : LinuxTV Developers
 
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1 or
-any later version published by the Free Software Foundation. A copy of
-the license is included in the chapter entitled "GNU Free Documentation
-License".
+This documentation is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the Free
+Software Foundation version 2 of the License.
+
+This program is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+more details.
+
+For more details see the file COPYING in the source distribution of Linux.
 
 .. class:: toc-title
 
diff --git a/Documentation/media/media_kapi.rst 
b/Documentation/media/media_kapi.rst
index 5414d2a7dfb8..431fc3e43d6a 100644
--- a/Documentation/media/media_kapi.rst
+++ b/Documentation/media/media_kapi.rst
@@ -8,11 +8,17 @@ Media subsystem kernel internal API
 
 **Copyright** |copy| 2009-2016 : LinuxTV Developers
 
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1 or
-any later version published by the Free Software Foundation. A copy of
-the license is included in the chapter entitled "GNU Free Documentation
-License".
+This documentation is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2 of the License, or (at your option) any
+later version.
+
+This program is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+more details.
+
+For more details see the file COPYING in the source distribution of Linux.
 
 .. class:: toc-title
 
diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 2aab653905ce..aac566f88833 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -8,11 +8,16 @@ Video4Linux (V4L)  driver-specific documentation
 
 **Copyright** |copy| 1999-2016 : LinuxTV Developers
 
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1 or
-any later version published by the Free Software Foundation. A copy of
-the license is included in the chapter entitled "GNU Free Documentation
-License".
+This documentation is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the Free
+Software Foundation version 2 of the License.
+
+This program is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+more details.
+
+For more details see the file COPYING in the source distribution of Linux.
 
 .. class:: toc-title
 
-- 
2.7.4

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

[PATCH 1/5] [media] doc-rst: backward compatibility with older Sphinx versions

[Mauro Carvalho Chehab]

Sphinx is really evil when an older version finds an extra
attribute for the :toctree: tag: it simply ignores everything
and produce documents without any chapter inside!

As we're now using tags available only on Sphinx 1.4.x, we
need to use some creative ways to add a title before the
table of contents. Do that by using a css class.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/dvb-drivers/index.rst   | 5 +++--
 Documentation/media/media_kapi.rst  | 6 --
 Documentation/media/media_uapi.rst  | 5 +++--
 Documentation/media/v4l-drivers/index.rst   | 5 +++--
 Documentation/sphinx-static/theme_overrides.css | 5 +
 5 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/Documentation/media/dvb-drivers/index.rst 
b/Documentation/media/dvb-drivers/index.rst
index e1d4d87f2a47..e4c2e74db9dc 100644
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -14,12 +14,13 @@ any later version published by the Free Software 
Foundation. A copy of
 the license is included in the chapter entitled "GNU Free Documentation
 License".
 
+.. class:: toc-title
+
+   Table of Contents
 
 .. toctree::
:maxdepth: 5
:numbered:
-   :caption: Table of Contents
-   :name: dvb_mastertoc
 
intro
avermedia
diff --git a/Documentation/media/media_kapi.rst 
b/Documentation/media/media_kapi.rst
index 0af80e90b7b5..5414d2a7dfb8 100644
--- a/Documentation/media/media_kapi.rst
+++ b/Documentation/media/media_kapi.rst
@@ -14,11 +14,13 @@ any later version published by the Free Software 
Foundation. A copy of
 the license is included in the chapter entitled "GNU Free Documentation
 License".
 
+.. class:: toc-title
+
+Table of Contents
+
 .. toctree::
 :maxdepth: 5
 :numbered:
-:caption: Table of Contents
-:name: kapi_mastertoc
 
 kapi/v4l2-framework
 kapi/v4l2-controls
diff --git a/Documentation/media/media_uapi.rst 
b/Documentation/media/media_uapi.rst
index debe4531040b..aaa9a0e387c4 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -14,11 +14,12 @@ any later version published by the Free Software 
Foundation. A copy of
 the license is included in the chapter entitled "GNU Free Documentation
 License".
 
+.. class:: toc-title
+
+Table of Contents
 
 .. toctree::
 :maxdepth: 5
-:caption: Table of Contents
-:name: uapi_mastertoc
 
 intro
 uapi/v4l/v4l2
diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 8d1710234e5a..2aab653905ce 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -14,12 +14,13 @@ any later version published by the Free Software 
Foundation. A copy of
 the license is included in the chapter entitled "GNU Free Documentation
 License".
 
+.. class:: toc-title
+
+Table of Contents
 
 .. toctree::
:maxdepth: 5
:numbered:
-   :caption: Table of Contents
-   :name: v4l_mastertoc
 
fourcc
v4l-with-ir
diff --git a/Documentation/sphinx-static/theme_overrides.css 
b/Documentation/sphinx-static/theme_overrides.css
index c97d8428302d..3a2ac4bcfd78 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -31,6 +31,11 @@
  *   - hide the permalink symbol as long as link is not hovered
  */
 
+.toc-title {
+font-size: 150%;
+   font-weight: bold;
+}
+
 caption, .wy-table caption, .rst-content table.field-list caption {
 font-size: 100%;
 }
-- 
2.7.4

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

[PATCH 4/5] [media] media-entry.h: Fix a note markup

[Mauro Carvalho Chehab]

The Sphinx note markup for media_remove_intf_links() is wrong:
there's a missing space.

While here, let's auto-numerate the two notes.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/media-entity.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 3d885d97d149..17390cc7b538 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -968,12 +968,12 @@ void __media_remove_intf_links(struct media_interface 
*intf);
  *
  * @intf:  pointer to _interface
  *
- * ..note::
+ * .. note::
  *
- *   - This is called automatically when an entity is unregistered via
- * media_device_register_entity() and by media_devnode_remove().
+ *   #) This is called automatically when an entity is unregistered via
+ *  media_device_register_entity() and by media_devnode_remove().
  *
- *   - Prefer to use this one, instead of __media_remove_intf_links().
+ *   #) Prefer to use this one, instead of __media_remove_intf_links().
  */
 void media_remove_intf_links(struct media_interface *intf);
 
-- 
2.7.4

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

[PATCH 3/5] [media] doc-rst: better organize the media books

[Mauro Carvalho Chehab]

The uAPI book has 5 parts, but they lost numeration after
conversion to rst. Manually number those parts, and make
the main index with 1 depth, to only show the parts and
the annexes.

At each part, use :maxwidth: 5, in order to show a more
complete index.

While here, fix the cross-references between different
books.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/kapi/mc-core.rst   |  2 +-
 Documentation/media/media_uapi.rst |  2 +-
 Documentation/media/uapi/cec/cec-api.rst   | 14 --
 Documentation/media/uapi/dvb/dvbapi.rst| 12 
 Documentation/media/uapi/mediactl/media-controller.rst | 17 +++--
 Documentation/media/uapi/rc/remote_controllers.rst | 17 +++--
 Documentation/media/uapi/v4l/v4l2.rst  | 12 
 Documentation/media/v4l-drivers/fimc.rst   | 10 --
 8 files changed, 44 insertions(+), 42 deletions(-)

diff --git a/Documentation/media/kapi/mc-core.rst 
b/Documentation/media/kapi/mc-core.rst
index c1fe0d69207d..4c47f5e3611d 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -5,7 +5,7 @@ Media Controller
 
 
 The media controller userspace API is documented in
-:ref:`the Media Controller uAPI book `. This document focus
+:ref:`the Media Controller uAPI book `. This document focus
 on the kernel-side implementation of the media framework.
 
 Abstract media device model
diff --git a/Documentation/media/media_uapi.rst 
b/Documentation/media/media_uapi.rst
index aaa9a0e387c4..fd8ebe002cd2 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -19,7 +19,7 @@ License".
 Table of Contents
 
 .. toctree::
-:maxdepth: 5
+:maxdepth: 1
 
 intro
 uapi/v4l/v4l2
diff --git a/Documentation/media/uapi/cec/cec-api.rst 
b/Documentation/media/uapi/cec/cec-api.rst
index 246fbae2e079..bb018709970c 100644
--- a/Documentation/media/uapi/cec/cec-api.rst
+++ b/Documentation/media/uapi/cec/cec-api.rst
@@ -4,16 +4,18 @@
 
 .. _cec:
 
-###
-CEC API
-###
-
-.. _cec-api:
+#
+Part V - Consumer Electronics Control API
+#
 
 This part describes the CEC: Consumer Electronics Control
 
+.. class:: toc-title
+
+Table of Contents
+
 .. toctree::
-:maxdepth: 1
+:maxdepth: 5
 :numbered:
 
 cec-intro
diff --git a/Documentation/media/uapi/dvb/dvbapi.rst 
b/Documentation/media/uapi/dvb/dvbapi.rst
index 6c06147f167c..48e61aba741e 100644
--- a/Documentation/media/uapi/dvb/dvbapi.rst
+++ b/Documentation/media/uapi/dvb/dvbapi.rst
@@ -4,17 +4,21 @@
 
 .. _dvbapi:
 
-##
-Digital TV API
-##
+
+Part II - Digital TV API
+
 
 .. note:: This API is also known as **DVB API**, although it is generic
enough to support all digital TV standards.
 
 **Version 5.10**
 
+.. class:: toc-title
+
+Table of Contents
+
 .. toctree::
-:maxdepth: 1
+:maxdepth: 5
 :numbered:
 
 intro
diff --git a/Documentation/media/uapi/mediactl/media-controller.rst 
b/Documentation/media/uapi/mediactl/media-controller.rst
index 7e08c93a15ab..7ae38d48969e 100644
--- a/Documentation/media/uapi/mediactl/media-controller.rst
+++ b/Documentation/media/uapi/mediactl/media-controller.rst
@@ -2,21 +2,18 @@
 
 .. include:: 
 
-.. _media_common:
-
-
-Media Controller API
-
-
 .. _media_controller:
 
-
-Media Controller
-
+##
+Part IV - Media Controller API
+##
 
+.. class:: toc-title
+
+Table of Contents
 
 .. toctree::
-:maxdepth: 1
+:maxdepth: 5
 :numbered:
 
 media-controller-intro
diff --git a/Documentation/media/uapi/rc/remote_controllers.rst 
b/Documentation/media/uapi/rc/remote_controllers.rst
index 169286501ebb..3e25cc9f65e0 100644
--- a/Documentation/media/uapi/rc/remote_controllers.rst
+++ b/Documentation/media/uapi/rc/remote_controllers.rst
@@ -2,21 +2,18 @@
 
 .. include:: 
 
-.. _remotes:
-
-#
-Remote Controller API
-#
-
 .. _remote_controllers:
 
-**
-Remote Controllers
-**
+
+Part III - Remote Controller API
+
 
+.. class:: toc-title
+
+Table of Contents
 
 .. toctree::
-:maxdepth: 1
+:maxdepth: 5
 :numbered:
 
 rc-intro
diff --git a/Documentation/media/uapi/v4l/v4l2.rst 
b/Documentation/media/uapi/v4l/v4l2.rst
index c0859ebc88ee..5e41a8505301 100644
--- a/Documentation/media/uapi/v4l/v4l2.rst
+++ b/Documentation/media/uapi/v4l/v4l2.rst
@@ -3,17 +3,21 @@
 .. include:: 
 .. _v4l2spec:
 
-###
-Video for Linux API

Re: [PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Mauro Carvalho Chehab]

Em Wed, 20 Jul 2016 08:31:49 -0600
Jonathan Corbet  escreveu:

> On Wed, 20 Jul 2016 16:23:28 +0200
> Markus Heiser  wrote:
> 
> > Am 20.07.2016 um 16:11 schrieb Mauro Carvalho Chehab 
> > :
> >   
> > > Sphinx 1.4.5 complains about some literal blocks at
> > > kernel-documentation.rst:
> > > 
> > >   Documentation/kernel-documentation.rst:373: WARNING: Could not lex 
> > > literal_block as "C". Highlighting skipped.
> > >   Documentation/kernel-documentation.rst:378: WARNING: Could not lex 
> > > literal_block as "C". Highlighting skipped.
> > >   Documentation/kernel-documentation.rst:576: WARNING: Could not lex 
> > > literal_block as "C". Highlighting skipped.
> > > 
> > > Fix it by telling Sphinx to consider them as "none" type.
> > 
> > Hi Mauro,
> > 
> > IMHO we should better fix this by unsetting the lexers default language 
> > in the conf.py  [1] ... currently:
> > 
> > highlight_language = 'C'  # set this to 'none'
> > 
> > As far as I know the default highlight_language is also the default
> > for literal blocks starting with "::"  
> 
> The thing with that is that a lot of literal blocks *do* have C code, even
> in kernel-documentation.rst.  Setting that in conf.py would turn off all C
> highlighting.  I think that might actually be a desirable outcome, but it
> would be good to make that decision explicitly.

Agreed. Assuming "C" as default seems a good idea to me.

> 
> As it happens, I'd already fixed these particular warnings in docs-next:
> 
>   http://permalink.gmane.org/gmane.linux.documentation/39806
> 
> I took a different approach; using code-block might actually be better.

Particularly, I prefer to explicitly tell when a block has a different
highlight than to switch the default along the document with "highlight"
tag, as this can be trickier to maintain as the document suffers
review along the time.

Anyway, your call ;)

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

Re: [PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Jonathan Corbet]

On Wed, 20 Jul 2016 16:23:28 +0200
Markus Heiser  wrote:

> Am 20.07.2016 um 16:11 schrieb Mauro Carvalho Chehab 
> :
> 
> > Sphinx 1.4.5 complains about some literal blocks at
> > kernel-documentation.rst:
> > 
> > Documentation/kernel-documentation.rst:373: WARNING: Could not lex 
> > literal_block as "C". Highlighting skipped.
> > Documentation/kernel-documentation.rst:378: WARNING: Could not lex 
> > literal_block as "C". Highlighting skipped.
> > Documentation/kernel-documentation.rst:576: WARNING: Could not lex 
> > literal_block as "C". Highlighting skipped.
> > 
> > Fix it by telling Sphinx to consider them as "none" type.  
> 
> Hi Mauro,
> 
> IMHO we should better fix this by unsetting the lexers default language 
> in the conf.py  [1] ... currently:
> 
> highlight_language = 'C'  # set this to 'none'
>   
> As far as I know the default highlight_language is also the default
> for literal blocks starting with "::"

The thing with that is that a lot of literal blocks *do* have C code, even
in kernel-documentation.rst.  Setting that in conf.py would turn off all C
highlighting.  I think that might actually be a desirable outcome, but it
would be good to make that decision explicitly.

As it happens, I'd already fixed these particular warnings in docs-next:

http://permalink.gmane.org/gmane.linux.documentation/39806

I took a different approach; using code-block might actually be better.

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

Re: [PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Markus Heiser]

Am 20.07.2016 um 16:11 schrieb Mauro Carvalho Chehab :

> Sphinx 1.4.5 complains about some literal blocks at
> kernel-documentation.rst:
> 
>   Documentation/kernel-documentation.rst:373: WARNING: Could not lex 
> literal_block as "C". Highlighting skipped.
>   Documentation/kernel-documentation.rst:378: WARNING: Could not lex 
> literal_block as "C". Highlighting skipped.
>   Documentation/kernel-documentation.rst:576: WARNING: Could not lex 
> literal_block as "C". Highlighting skipped.
> 
> Fix it by telling Sphinx to consider them as "none" type.

Hi Mauro,

IMHO we should better fix this by unsetting the lexers default language 
in the conf.py  [1] ... currently:

highlight_language = 'C'  # set this to 'none'

As far as I know the default highlight_language is also the default
for literal blocks starting with "::"

---
references. For example::

 See function :c:func:`foo` and struct/union/enum/typedef :c:type:`bar`.
---

[1] http://www.sphinx-doc.org/en/stable/config.html#confval-highlight_language

-- Markus --

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> Documentation/kernel-documentation.rst | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/kernel-documentation.rst 
> b/Documentation/kernel-documentation.rst
> index 391decc66a18..1dd97478743e 100644
> --- a/Documentation/kernel-documentation.rst
> +++ b/Documentation/kernel-documentation.rst
> @@ -370,11 +370,15 @@ To cross-reference the functions and types defined in 
> the kernel-doc comments
> from reStructuredText documents, please use the `Sphinx C Domain`_
> references. For example::
> 
> +.. code-block:: none
> +
>  See function :c:func:`foo` and struct/union/enum/typedef :c:type:`bar`.
> 
> While the type reference works with just the type name, without the
> struct/union/enum/typedef part in front, you may want to use::
> 
> +.. code-block:: none
> +
>  See :c:type:`struct foo `.
>  See :c:type:`union bar `.
>  See :c:type:`enum baz `.
> @@ -573,6 +577,8 @@ converted to Sphinx and reStructuredText. For most 
> DocBook XML documents, a good
> enough solution is to use the simple ``Documentation/sphinx/tmplcvt`` script,
> which uses ``pandoc`` under the hood. For example::
> 
> +.. code-block:: none
> +
>  $ cd Documentation/sphinx
>  $ ./tmplcvt ../DocBook/in.tmpl ../out.rst
> 
> -- 
> 2.7.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Javier Martinez Canillas]

Hello Hans,

On 07/20/2016 10:12 AM, Hans Verkuil wrote:
> On 07/20/2016 04:06 PM, Javier Martinez Canillas wrote:
>> Hello Sakari,
>>
>> On 07/20/2016 09:20 AM, Sakari Ailus wrote:
>>> Hi Javier,
>>>
>>> On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas wrote:
 The buffer planes' dma-buf are currently mapped when buffers are queued
 from userspace but it's more appropriate to do the mapping when buffers
 are queued in the driver since that's when the actual DMA operation are
 going to happen.

 Suggested-by: Nicolas Dufresne 
 Signed-off-by: Javier Martinez Canillas 

 ---

 Hello,

 A side effect of this change is that if the dmabuf map fails for some
 reasons (i.e: a driver using the DMA contig memory allocator but CMA
 not being enabled), the fail will no longer happen on VIDIOC_QBUF but
 later (i.e: in VIDIOC_STREAMON).

 I don't know if that's an issue though but I think is worth mentioning.
>>>
>>> I have the same question has Hans --- why?
>>>
>>
>> Yes, sorry for missing this information. Nicolas already explained a little
>> bit but the context is that I want to add dma-buf fence support to videobuf2,
>> and currently the dma-buf is unmapped in VIDIOC_DQBUF.
>>
>> But with dma-buf fence, the idea is to be able to dequeue a buffer even when
>> the driver has not yet finished processing the buffer. So the dma-buf needs 
>> to
>> be mapped until vb2_buffer_done() when the driver is done processing the vb2,
>> and is able to signal the pending fence.
>>
>> Since the unmapping was going to be delayed to vb2_buffer_done(), I thought
>> it would make sense to also move the mapping closer to when is really going
>> to be used and that's why I moved it to __enqueue_in_driver() in this patch.
>>
>> But I didn't know that user-space was using the dma-buf map as a way to know
>> if the dma-buf will be compatible and fallback to a different streaming I/O
>> method if that's not the case. So $SUBJECT is wrong if it prevents user-space
>> to recover gracefully from a dma-buf mapping failure.
>>
>> In any case, only delaying the unmapping is needed to support fence and doing
>> the map early in VIDIOC_QBUF is not an issue.
> 
> OK. I've rejected this patch. I understand the DQBUF part and I happily accept

Ok, thanks.

> a patch for that. But the other side should be left as-is. The TODO comment
> should probably be dropped, now that I think about it.
>

I can post such a patch, do you want me to also add a comment about why is done
in QBUF instead of when the buffer is queued in the driver (e.g: that user-space
is able to recover in QBUF but no in STREAMON) or just removing it and mention
that in the commit message is enough?
 
> Regards,
> 
>   Hans
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

Hi,

On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 0:34 GMT+03:00 Bin Liu :
> > Hi,
> >
> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
> >> > Hi,
> >> >
> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> >> >> Hello,
> >> >>
> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
> >> >> BeagleBoneBlack SBC.
> >> >> I am sure that both of them are fine and work properly.
> >> >> I am running Linux 4.6.4 (my kernel config is available at 
> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
> >> >> issue with frame transfer when high resolution formats are used.
> >> >>
> >> >> The issue is the following. I use simple v4l2 example tool (taken from 
> >> >> API docs), which source code is available at 
> >> >> http://pastebin.com/grcNXxfe
> >> >>
> >> >> When I use (see line 488) 640x480 frames
> >> >>
> >> >> fmt.fmt.pix.width   = 640;
> >> >> fmt.fmt.pix.height  = 480;
> >> >>
> >> >> then I get "select timeout" and don't get any frames.
> >> >>
> >> >> When I use 320x240 frames
> >> >>
> >> >> fmt.fmt.pix.width   = 320;
> >> >> fmt.fmt.pix.height  = 240;
> >> >>
> >> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
> >> >> available at https://yadi.sk/d/aRka8xWPtSc4y
> >> >> It looks like there are pauses between bulks of frames (frame counter 
> >> >> and timestamp as returned from v4l2 API):
> >> >>
> >> >> 3 3705.142553
> >> >> 8 3705.342533
> >> >> 13 3705.542517
> >> >> 110 3708.776208
> >> >> 115 3708.976190
> >> >> 120 3709.176169
> >> >> 125 3709.376152
> >> >> 130 3709.576144
> >> >> 226 3712.807848
> >> >>
> >> >> When I use tiny 160x120 frames
> >> >>
> >> >> fmt.fmt.pix.width   = 160;
> >> >> fmt.fmt.pix.height  = 120;
> >> >>
> >> >> then more frames are received. See output example at 
> >> >> https://yadi.sk/d/DedBmH6ftSc9t
> >> >> That is why I thought that everything was fine in May when used tiny 
> >> >> xawtv window to check kernel OOPS presence (see 
> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
> >> >>
> >> >> Even more. When I introduce USB hub between the host and the webcam, I 
> >> >> can not receive even any 320x240 frames.
> >> >>
> >> >> I've managed to use ftrace to see what is going on when no frames are 
> >> >> received.
> >> >> I've found that pwc_isoc_handler is called frequently as the following:
> >> >>
> >> >>  0)   |  pwc_isoc_handler [pwc]() {
> >> >>  0)   |usb_submit_urb [usbcore]() {
> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
> >> >>  0)   5.750 us|  }
> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
> >> >>  0)   0.792 us|  _raw_spin_lock();
> >> >>  0)   0.791 us|  _raw_spin_unlock();
> >> >>  0) + 10.500 us   |}
> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
> >> >>  0) + 25.375 us   |  }
> >> >>  0) + 45.208 us   |}
> >> >>  0) + 51.042 us   |  }
> >> >>  0) + 56.084 us   |}
> >> >>  0) + 61.292 us   |  }
> >> >>
> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I 
> >> >> get "select timeout" in userspace.
> >> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y 
> >> >> but I can recompile it, if you think that it could provide more 
> >> >> information. I am also ready to perform additional tests (use usbmon 
> >> >> maybe?).
> >> >>
> >> >> How could this issue be resolved?
> >> >>
> >> >> Thank you.
> >> >
> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
> >> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
> >> > tokens in every other SOF, so only half of the bus bandwidth is
> >> > utilized, which causes video frame drops in higher resolution.
> >> >
> >>
> >> Yes, I do use DMA:
> >>
> >> CONFIG_USB_TI_CPPI41_DMA=y
> >
> > Okay.
> >
> >>
> >> > To confirm this, use a bus analyzer to capture a bus trace, you would
> >> > see no IN tokens in every other SOF while transfering Isoch packets.
> >> >
> >>
> >> I am sorry, I am new to USB debugging. Do you mean I need to use
> >> usbmon or some external hardware device?
> >
> > I barely use usbmon, and not sure if it gives the information I am
> > 

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Hans Verkuil]

On 07/20/2016 04:06 PM, Javier Martinez Canillas wrote:
> Hello Sakari,
> 
> On 07/20/2016 09:20 AM, Sakari Ailus wrote:
>> Hi Javier,
>>
>> On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas wrote:
>>> The buffer planes' dma-buf are currently mapped when buffers are queued
>>> from userspace but it's more appropriate to do the mapping when buffers
>>> are queued in the driver since that's when the actual DMA operation are
>>> going to happen.
>>>
>>> Suggested-by: Nicolas Dufresne 
>>> Signed-off-by: Javier Martinez Canillas 
>>>
>>> ---
>>>
>>> Hello,
>>>
>>> A side effect of this change is that if the dmabuf map fails for some
>>> reasons (i.e: a driver using the DMA contig memory allocator but CMA
>>> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
>>> later (i.e: in VIDIOC_STREAMON).
>>>
>>> I don't know if that's an issue though but I think is worth mentioning.
>>
>> I have the same question has Hans --- why?
>>
> 
> Yes, sorry for missing this information. Nicolas already explained a little
> bit but the context is that I want to add dma-buf fence support to videobuf2,
> and currently the dma-buf is unmapped in VIDIOC_DQBUF.
> 
> But with dma-buf fence, the idea is to be able to dequeue a buffer even when
> the driver has not yet finished processing the buffer. So the dma-buf needs to
> be mapped until vb2_buffer_done() when the driver is done processing the vb2,
> and is able to signal the pending fence.
> 
> Since the unmapping was going to be delayed to vb2_buffer_done(), I thought
> it would make sense to also move the mapping closer to when is really going
> to be used and that's why I moved it to __enqueue_in_driver() in this patch.
> 
> But I didn't know that user-space was using the dma-buf map as a way to know
> if the dma-buf will be compatible and fallback to a different streaming I/O
> method if that's not the case. So $SUBJECT is wrong if it prevents user-space
> to recover gracefully from a dma-buf mapping failure.
> 
> In any case, only delaying the unmapping is needed to support fence and doing
> the map early in VIDIOC_QBUF is not an issue.

OK. I've rejected this patch. I understand the DQBUF part and I happily accept
a patch for that. But the other side should be left as-is. The TODO comment
should probably be dropped, now that I think about it.

Regards,

Hans

>> I rather think we should keep the buffers mapped all the time. That'd
>> require a bit of extra from the DMA-BUF framework I suppose, to support
>> streaming mappings.
>>
> 
> Interesting, I can take a look to this possibility after adding the dma-buf
> fence support.
> 
> Best regards,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] doc-rst: get rid of warnings at kernel-documentation.rst

[Mauro Carvalho Chehab]

Sphinx 1.4.5 complains about some literal blocks at
kernel-documentation.rst:

Documentation/kernel-documentation.rst:373: WARNING: Could not lex 
literal_block as "C". Highlighting skipped.
Documentation/kernel-documentation.rst:378: WARNING: Could not lex 
literal_block as "C". Highlighting skipped.
Documentation/kernel-documentation.rst:576: WARNING: Could not lex 
literal_block as "C". Highlighting skipped.

Fix it by telling Sphinx to consider them as "none" type.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/kernel-documentation.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/kernel-documentation.rst 
b/Documentation/kernel-documentation.rst
index 391decc66a18..1dd97478743e 100644
--- a/Documentation/kernel-documentation.rst
+++ b/Documentation/kernel-documentation.rst
@@ -370,11 +370,15 @@ To cross-reference the functions and types defined in the 
kernel-doc comments
 from reStructuredText documents, please use the `Sphinx C Domain`_
 references. For example::
 
+.. code-block:: none
+
   See function :c:func:`foo` and struct/union/enum/typedef :c:type:`bar`.
 
 While the type reference works with just the type name, without the
 struct/union/enum/typedef part in front, you may want to use::
 
+.. code-block:: none
+
   See :c:type:`struct foo `.
   See :c:type:`union bar `.
   See :c:type:`enum baz `.
@@ -573,6 +577,8 @@ converted to Sphinx and reStructuredText. For most DocBook 
XML documents, a good
 enough solution is to use the simple ``Documentation/sphinx/tmplcvt`` script,
 which uses ``pandoc`` under the hood. For example::
 
+.. code-block:: none
+
   $ cd Documentation/sphinx
   $ ./tmplcvt ../DocBook/in.tmpl ../out.rst
 
-- 
2.7.4


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

[PATCH] ir-ctl: give proper error message if transmitter does not exist

[Sean Young]

If a transmitter does not exist when setting using -e, you get the error:

warning: /dev/lirc0: failed to set send transmitters: Success

Signed-off-by: Sean Young 
---
 utils/ir-ctl/ir-ctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index 05b46a3..229330e 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -516,7 +516,9 @@ static int lirc_options(struct arguments *args, int fd, 
unsigned features)
if (args->emitters) {
if (features & LIRC_CAN_SET_TRANSMITTER_MASK) {
rc = ioctl(fd, LIRC_SET_TRANSMITTER_MASK, 
>emitters);
-   if (rc)
+   if (rc > 0)
+   fprintf(stderr, _("warning: %s: failed to set 
send transmitters: only %d available\n"), dev, rc);
+   else if (rc < 0)
fprintf(stderr, _("warning: %s: failed to set 
send transmitters: %m\n"), dev);
} else
fprintf(stderr, _("warning: %s: does not support 
setting send transmitters\n"), dev);
-- 
2.7.4

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

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Javier Martinez Canillas]

Hello Sakari,

On 07/20/2016 09:20 AM, Sakari Ailus wrote:
> Hi Javier,
> 
> On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas wrote:
>> The buffer planes' dma-buf are currently mapped when buffers are queued
>> from userspace but it's more appropriate to do the mapping when buffers
>> are queued in the driver since that's when the actual DMA operation are
>> going to happen.
>>
>> Suggested-by: Nicolas Dufresne 
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> Hello,
>>
>> A side effect of this change is that if the dmabuf map fails for some
>> reasons (i.e: a driver using the DMA contig memory allocator but CMA
>> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
>> later (i.e: in VIDIOC_STREAMON).
>>
>> I don't know if that's an issue though but I think is worth mentioning.
> 
> I have the same question has Hans --- why?
>

Yes, sorry for missing this information. Nicolas already explained a little
bit but the context is that I want to add dma-buf fence support to videobuf2,
and currently the dma-buf is unmapped in VIDIOC_DQBUF.

But with dma-buf fence, the idea is to be able to dequeue a buffer even when
the driver has not yet finished processing the buffer. So the dma-buf needs to
be mapped until vb2_buffer_done() when the driver is done processing the vb2,
and is able to signal the pending fence.

Since the unmapping was going to be delayed to vb2_buffer_done(), I thought
it would make sense to also move the mapping closer to when is really going
to be used and that's why I moved it to __enqueue_in_driver() in this patch.

But I didn't know that user-space was using the dma-buf map as a way to know
if the dma-buf will be compatible and fallback to a different streaming I/O
method if that's not the case. So $SUBJECT is wrong if it prevents user-space
to recover gracefully from a dma-buf mapping failure.

In any case, only delaying the unmapping is needed to support fence and doing
the map early in VIDIOC_QBUF is not an issue.
 
> I rather think we should keep the buffers mapped all the time. That'd
> require a bit of extra from the DMA-BUF framework I suppose, to support
> streaming mappings.
> 

Interesting, I can take a look to this possibility after adding the dma-buf
fence support.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] doc-rst: Fix some Sphinx warnings

[Mauro Carvalho Chehab]

Em Wed, 20 Jul 2016 15:14:27 +0200
Markus Heiser  escreveu:

> Am 20.07.2016 um 15:00 schrieb Mauro Carvalho Chehab 
> :
> 
> > Em Wed, 20 Jul 2016 09:32:15 -0300
> > Mauro Carvalho Chehab  escreveu:
> >   
> >> Fix all remaining media warnings with ReST that are fixable
> >> without changing at the Sphinx code.
> >>   
> >   
> >> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> >> index 83877719bef4..3d885d97d149 100644
> >> --- a/include/media/media-entity.h
> >> +++ b/include/media/media-entity.h
> >> @@ -180,8 +180,10 @@ struct media_pad {
> >> *  view. The media_entity_pipeline_start() function
> >> *  validates all links by calling this operation. Optional.
> >> *
> >> - * .. note:: Those these callbacks are called with struct 
> >> media_device.@graph_mutex
> >> - * mutex held.
> >> + * .. note::
> >> + *
> >> + *Those these callbacks are called with struct 
> >> media_device.@graph_mutex
> >> + *mutex held.
> >> */  
> > 
> > The kernel-doc script did something wrong here... something bad
> > happened with "@graph_mutex". While it is showing the note box
> > properly, the message inside is:
> > 
> > "Note
> > 
> >  Those these callbacks are called with struct 
> > media_device.**graph_mutex** mutex held."
> > 
> > 
> > E. g. it converted @ to "**graph_mutex**" and some code seemed to
> > change it to: "\*\*graph_mutex\*\*", as this message is not showing
> > with a bold font, but, instead, with the double asterisks.
> > 
> > No idea how to fix it.  
> 
> Thanks for reporting ..
> I guess it is the kernel-doc parser, currently I'am trying to eliminate
> some base fails of the kernel-doc parser (e.g. you mailed handling of 
> c functions) .. for this I test with your media_tree/doc-next ..
> if you commit this to your doc-next I have an example (or where could I get 
> it)

It is on my development tree:
https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next

I'll push it to the media_tree later today.

Btw, I'm also getting this warning:

/devel/v4l/patchwork/Documentation/media/kapi/mc-core.rst:1252: WARNING: Could 
not lex literal_block as "C". Highlighting skipped. 
  

With invalid line numbers. I was unable to discover why, and your
patch didn't help solving it.

---

A completely unrelated question: it seems that Sphinx is using just
one CPU to do its builds:

%Cpu0  :  3,0 us,  7,6 sy,  0,0 ni, 89,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu1  :100,0 us,  0,0 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu2  :  1,3 us,  2,7 sy,  0,0 ni, 95,7 id,  0,3 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu3  :  1,0 us,  3,3 sy,  0,0 ni, 95,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem : 15861876 total,  5809820 free,  1750528 used,  8301528 buff/cache
KiB Swap:  8200188 total,  8200188 free,0 used. 13382964 avail Mem 

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND 
 5660 mchehab   20   0  325256  89776   8300 R  99,7  0,6   0:22.25 sphinx-bui+ 

Are there any way to speed it up and make it use all available CPUs?


> I will take a look about this also .. .. give me some time ;-)
> 
> -- Markus --
> 
> > 
> > Thanks,
> > Mauro
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> 



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

Re: [PATCH] [media] vb2: include length in dmabuf qbuf debug message

[Javier Martinez Canillas]

Hello Sakari,

On 07/20/2016 09:03 AM, Sakari Ailus wrote:
> Hi Javier,
> 
> Thanks for the patch!
>

Thanks for your feedback.
 
> On Thu, Jul 14, 2016 at 11:09:34AM -0400, Javier Martinez Canillas wrote:
>> If the the VIDIOC_QBUF ioctl fails due a wrong dmabuf length,
>> it's useful to get the invalid length as a debug information.
>>
>> Before this patch:
>>
>> vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1
>>
>> After this patch:
>>
>> vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>>  drivers/media/v4l2-core/videobuf2-core.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index ca8ffeb56d72..97d1483e0f7a 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -1228,8 +1228,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
>> void *pb)
>>  planes[plane].length = dbuf->size;
>>  
>>  if (planes[plane].length < vb->planes[plane].min_length) {
>> -dprintk(1, "invalid dmabuf length for plane %d\n",
>> -plane);
>> +dprintk(1, "invalid dmabuf length %d for plane %d\n",
> 
> %u, please. You might want to print the minimum length as well.
>

Right, it should be %u indeed. Ok, I'll add the min_length as well in v2.
 
>> +planes[plane].length, plane);
>>  dma_buf_put(dbuf);
>>  ret = -EINVAL;
>>  goto err;
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Sakari Ailus]

Hi Javier,

On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas wrote:
> The buffer planes' dma-buf are currently mapped when buffers are queued
> from userspace but it's more appropriate to do the mapping when buffers
> are queued in the driver since that's when the actual DMA operation are
> going to happen.
> 
> Suggested-by: Nicolas Dufresne 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Hello,
> 
> A side effect of this change is that if the dmabuf map fails for some
> reasons (i.e: a driver using the DMA contig memory allocator but CMA
> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
> later (i.e: in VIDIOC_STREAMON).
> 
> I don't know if that's an issue though but I think is worth mentioning.

I have the same question has Hans --- why?

I rather think we should keep the buffers mapped all the time. That'd
require a bit of extra from the DMA-BUF framework I suppose, to support
streaming mappings.

The reason for that is performance. If you're passing the buffer between a
couple of hardware devices, there's no need to map and unmap it every time
the buffer is accessed by the said devices. That'd avoid an unnecessary
cache flush as well, something that tends to be quite expensive. On a PC
with resolutions typically used on webcams that might not really matter. But
if you have an embedded system with a relatively modest 10 MP camera sensor,
it's one of the first things you'll notice if you check where the CPU time
is being spent.

-- 
Kind regards,

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

Re: [PATCH v7] [media] pci: Add tw5864 driver

[Hans Verkuil]

On 07/20/2016 03:07 PM, Andrey Utkin wrote:
> Changes since v6:
>  - Change tw5864_input_std_get() behaviour as suggested by Hans, and also 
> simplify
>  - tw5864_from_v4l2_std(): drop WARN_ON_ONCE on returning STD_INVALID
>  - tw5864_prepare_frame_headers(): not only WARN_ON_ONCE, but also return if 
> buffer space is too small
>  - tw5864_frameinterval_get(): return -EINVAL instead of "1" on failure
> 
> Granular git log: 
> https://github.com/bluecherrydvr/linux/commits/release/tw5864/pre_1.26/drivers/media/pci/tw5864
> 
> ---8<---
> Support for boards based on Techwell TW5864 chip which provides
> multichannel video & audio grabbing and encoding (H.264, MJPEG,
> ADPCM G.726).
> 
> This submission implements only H.264 encoding of all channels at D1
> resolution.
> 
> Thanks to Mark Thompson  for help, and for contribution of
> H.264 startcode emulation prevention code.
> 
> Signed-off-by: Andrey Utkin 
> Tested-by: Andrey Utkin 

Looks good. Once we moved to v4.8-rc1 in 3 weeks time or so I'll make a pull 
request for this.

Regards,

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

Re: [PATCH] [media] doc-rst: Fix some Sphinx warnings

[Markus Heiser]

Am 20.07.2016 um 15:00 schrieb Mauro Carvalho Chehab :

> Em Wed, 20 Jul 2016 09:32:15 -0300
> Mauro Carvalho Chehab  escreveu:
> 
>> Fix all remaining media warnings with ReST that are fixable
>> without changing at the Sphinx code.
>> 
> 
>> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
>> index 83877719bef4..3d885d97d149 100644
>> --- a/include/media/media-entity.h
>> +++ b/include/media/media-entity.h
>> @@ -180,8 +180,10 @@ struct media_pad {
>> *view. The media_entity_pipeline_start() function
>> *validates all links by calling this operation. Optional.
>> *
>> - * .. note:: Those these callbacks are called with struct 
>> media_device.@graph_mutex
>> - * mutex held.
>> + * .. note::
>> + *
>> + *Those these callbacks are called with struct media_device.@graph_mutex
>> + *mutex held.
>> */
> 
> The kernel-doc script did something wrong here... something bad
> happened with "@graph_mutex". While it is showing the note box
> properly, the message inside is:
> 
>   "Note
> 
>Those these callbacks are called with struct 
> media_device.**graph_mutex** mutex held."
> 
> 
> E. g. it converted @ to "**graph_mutex**" and some code seemed to
> change it to: "\*\*graph_mutex\*\*", as this message is not showing
> with a bold font, but, instead, with the double asterisks.
> 
> No idea how to fix it.

Thanks for reporting ..
I guess it is the kernel-doc parser, currently I'am trying to eliminate
some base fails of the kernel-doc parser (e.g. you mailed handling of 
c functions) .. for this I test with your media_tree/doc-next ..
if you commit this to your doc-next I have an example (or where could I get it)
I will take a look about this also .. .. give me some time ;-)

-- Markus --

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

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

Re: [PATCH] [media] vb2: include length in dmabuf qbuf debug message

[Sakari Ailus]

Hi Javier,

Thanks for the patch!

On Thu, Jul 14, 2016 at 11:09:34AM -0400, Javier Martinez Canillas wrote:
> If the the VIDIOC_QBUF ioctl fails due a wrong dmabuf length,
> it's useful to get the invalid length as a debug information.
> 
> Before this patch:
> 
> vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1
> 
> After this patch:
> 
> vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/media/v4l2-core/videobuf2-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index ca8ffeb56d72..97d1483e0f7a 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1228,8 +1228,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
> void *pb)
>   planes[plane].length = dbuf->size;
>  
>   if (planes[plane].length < vb->planes[plane].min_length) {
> - dprintk(1, "invalid dmabuf length for plane %d\n",
> - plane);
> + dprintk(1, "invalid dmabuf length %d for plane %d\n",

%u, please. You might want to print the minimum length as well.

> + planes[plane].length, plane);
>   dma_buf_put(dbuf);
>   ret = -EINVAL;
>   goto err;

-- 
Kind regards,

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

Re: [PATCH] [media] doc-rst: Fix some Sphinx warnings

[Mauro Carvalho Chehab]

Em Wed, 20 Jul 2016 09:32:15 -0300
Mauro Carvalho Chehab  escreveu:

> Fix all remaining media warnings with ReST that are fixable
> without changing at the Sphinx code.
> 

> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 83877719bef4..3d885d97d149 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -180,8 +180,10 @@ struct media_pad {
>   *   view. The media_entity_pipeline_start() function
>   *   validates all links by calling this operation. Optional.
>   *
> - * .. note:: Those these callbacks are called with struct 
> media_device.@graph_mutex
> - * mutex held.
> + * .. note::
> + *
> + *Those these callbacks are called with struct media_device.@graph_mutex
> + *mutex held.
>   */

The kernel-doc script did something wrong here... something bad
happened with "@graph_mutex". While it is showing the note box
properly, the message inside is:

"Note

 Those these callbacks are called with struct 
media_device.**graph_mutex** mutex held."


E. g. it converted @ to "**graph_mutex**" and some code seemed to
change it to: "\*\*graph_mutex\*\*", as this message is not showing
with a bold font, but, instead, with the double asterisks.

No idea how to fix it.

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

Re: [PATCH 0/6] radio: Utilize the module_isa_driver macro

[William Breathitt Gray]

On Wed, Jul 20, 2016 at 12:37:31PM +0200, Hans Verkuil wrote:
>On 07/18/2016 04:45 PM, William Breathitt Gray wrote:
>> The module_isa_driver macro is a helper macro for ISA drivers which do
>> not do anything special in module init/exit. This patchset eliminates a
>> lot of ISA driver registration boilerplate code by utilizing
>> module_isa_driver, which replaces module_init and module_exit.
>> 
>> William Breathitt Gray (6):
>>   radio: terratec: Utilize the module_isa_driver macro
>>   radio: rtrack2: Utilize the module_isa_driver macro
>>   radio: trust: Utilize the module_isa_driver macro
>>   radio: zoltrix: Utilize the module_isa_driver macro
>>   radio: aztech: Utilize the module_isa_driver macro
>>   radio: aimslab: Utilize the module_isa_driver macro
>
>Good idea, but it doesn't compile:
>
>module_isa_driver(terratec_driver.driver, 1);
>
>expands to:
>
>static int __init terratec_driver.driver_init(void)
>{
>return isa_register_driver(&(terratec_driver.driver), 1);
>}
>
>So now the function name contains a '.' and it won't compile.
>
>Regards,
>
>   Hans

Oops, looks like I was a bit on autopilot there. I'll have to rethink
this patchset at a later point to overcome the symbol naming issue.

Thank you,

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

[PATCH] media: doc-rst: document ENODATA for cropping ioctls

[Hans Verkuil]

Document that the cropping ioctls can return ENODATA if the operation isn't 
supported
for the current input or output.

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/uapi/v4l/vidioc-cropcap.rst 
b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
index 8dcbe6d..54382cd 100644
--- a/Documentation/media/uapi/v4l/vidioc-cropcap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
@@ -165,3 +165,6 @@ appropriately. The generic error codes are described at the
 EINVAL
 The struct :ref:`v4l2_cropcap ` ``type`` is
 invalid.
+
+ENODATA
+Cropping is not supported for this input or output.
diff --git a/Documentation/media/uapi/v4l/vidioc-g-crop.rst 
b/Documentation/media/uapi/v4l/vidioc-g-crop.rst
index 6cf7649..075e87a 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-crop.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-crop.rst
@@ -111,3 +111,6 @@ Return Value
 On success 0 is returned, on error -1 and the ``errno`` variable is set
 appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes ` chapter.
+
+ENODATA
+Cropping is not supported for this input or output.
diff --git a/Documentation/media/uapi/v4l/vidioc-g-selection.rst 
b/Documentation/media/uapi/v4l/vidioc-g-selection.rst
index 953931f..3f38a83 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-selection.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-selection.rst
@@ -204,6 +204,9 @@ ERANGE
 ``r`` rectangle to satisfy all constraints given in the ``flags``
 argument.

+ENODATA
+Selection is not supported for this input or output.
+
 EBUSY
 It is not possible to apply change of the selection rectangle at the
 moment. Usually because streaming is in progress.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] rcar-vin: add legacy mode for wrong media bus formats

[Hans Verkuil]

On 07/20/2016 02:29 PM, Niklas Söderlund wrote:

Hi Hans,

Thanks for your feedback.

On 2016-07-20 11:48:40 +0200, Hans Verkuil wrote:

On 07/08/2016 12:43 PM, Niklas Söderlund wrote:

A recent bugfix to adv7180 brought to light that the rcar-vin driver are
looking for the wrong media bus format. It was looking for a YUVU format
but then expecting UYVY data. The bugfix for adv7180 will break the
usage of rcar-vin together with a adv7180 as found on Renesas R-Car2
Koelsch boards for example.

This patch fix the rcar-vin driver to look for the correct UYVU formats
and adds a legacy mode. The legacy mode is needed since I don't know if
other devices provide a incorrect media bus format and I don't want to
break any working configurations. Hopefully the legacy mode can be
removed sometime in the future.


I'd rather have a version without the legacy code. You have to assume that
subdevs return correct values otherwise what's the point of the mediabus
formats?

So this is simply an adv7180 bug fix + this r-car fix to stay consistent
with the adv7180.


On principal I agree with you. My goal with this patch is just to make
sure there is no case where the rcar-vin driver won't work with the
adv7180. The plan was to drop the legacy mode in a separate patch after
both the adv7182 and rcar-vin patches where picked up.

I'm happy to drop the 'legacy support' for the wrong formats from this
patch as long as I can be sure that there is no breaking. Should I
rewrite this patch to drop the wrong formats and submit it as a series
together with the adv7180 patch so they can be picked up together? Or do
you know of a better way?


Why not combine this patch and the adv7180 patch in a single patch? Just keep
Steve's Signed-off-by line together with yours. That way everything stays
in sync. The only other user of the adv7180 doesn't look at the mediabus
formats at all, so it isn't affected.

Regards,

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

[PATCH] [media] doc-rst: Fix some Sphinx warnings

[Mauro Carvalho Chehab]

Fix all remaining media warnings with ReST that are fixable
without changing at the Sphinx code.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx88.rst| 1 +
 Documentation/media/v4l-drivers/tm6000-cardlist.rst | 2 +-
 drivers/media/dvb-core/dvb_math.h   | 7 +++
 include/media/media-entity.h| 6 --
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/media/v4l-drivers/cx88.rst 
b/Documentation/media/v4l-drivers/cx88.rst
index 97865007f51f..d8f3a014726a 100644
--- a/Documentation/media/v4l-drivers/cx88.rst
+++ b/Documentation/media/v4l-drivers/cx88.rst
@@ -119,6 +119,7 @@ GPIO 16(I believe) is tied to the IR port (if present).
 From the data sheet:
 
 - Register 24'h20004  PCI Interrupt Status
+
  - bit [18]  IR_SMP_INT Set when 32 input samples have been collected over
  - gpio[16] pin into GP_SAMPLE register.
 
diff --git a/Documentation/media/v4l-drivers/tm6000-cardlist.rst 
b/Documentation/media/v4l-drivers/tm6000-cardlist.rst
index ca08d4214b38..2fbd3886b5f0 100644
--- a/Documentation/media/v4l-drivers/tm6000-cardlist.rst
+++ b/Documentation/media/v4l-drivers/tm6000-cardlist.rst
@@ -1,5 +1,5 @@
 TM6000 cards list
-===
+=
 
 .. code-block:: none
 
diff --git a/drivers/media/dvb-core/dvb_math.h 
b/drivers/media/dvb-core/dvb_math.h
index 34dc1df03cab..2f0326674ca6 100644
--- a/drivers/media/dvb-core/dvb_math.h
+++ b/drivers/media/dvb-core/dvb_math.h
@@ -30,11 +30,15 @@
  * @value: The value (must be != 0)
  *
  * to use rational values you can use the following method:
+ *
  *   intlog2(value) = intlog2(value * 2^x) - x * 2^24
  *
  * Some usecase examples:
+ *
  * intlog2(8) will give 3 << 24 = 3 * 2^24
+ *
  * intlog2(9) will give 3 << 24 + ... = 3.16... * 2^24
+ *
  * intlog2(1.5) = intlog2(3) - 2^24 = 0.584... * 2^24
  *
  *
@@ -48,10 +52,13 @@ extern unsigned int intlog2(u32 value);
  * @value: The value (must be != 0)
  *
  * to use rational values you can use the following method:
+ *
  *   intlog10(value) = intlog10(value * 10^x) - x * 2^24
  *
  * An usecase example:
+ *
  * intlog10(1000) will give 3 << 24 = 3 * 2^24
+ *
  *   due to the implementation intlog10(1000) might be not exactly 3 * 2^24
  *
  * look at intlog2 for similar examples
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 83877719bef4..3d885d97d149 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -180,8 +180,10 @@ struct media_pad {
  * view. The media_entity_pipeline_start() function
  * validates all links by calling this operation. Optional.
  *
- * .. note:: Those these callbacks are called with struct 
media_device.@graph_mutex
- * mutex held.
+ * .. note::
+ *
+ *Those these callbacks are called with struct media_device.@graph_mutex
+ *mutex held.
  */
 struct media_entity_operations {
int (*link_setup)(struct media_entity *entity,
-- 
2.7.4

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

[PATCH] vivid: return -ENODATA if the current input doesn't support g/s_selection

[Hans Verkuil]

Returning -EINVAL indicates wrong arguments, but that's not the case here.

Returning -ENOTTY is also no option, since the ioctl is implemented, but it 
just is not valid for
this input.

So use -ENODATA instead. This is also used elsewhere when an ioctl isn't valid 
for a specific
input.

In this case G/S_SELECTION returned -EINVAL for the webcam input. That input 
doesn't support
cropping, instead it uses ENUM_FRAMESIZES to enumerate a list of discrete frame 
sizes.

Signed-off-by: Hans Verkuil 
---
A patch for docs-next will follow.
---
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c 
b/drivers/media/platform/vivid/vivid-vid-cap.c
index d404a7c..d5c84ec 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -823,7 +823,7 @@ int vivid_vid_cap_g_selection(struct file *file, void *priv,
if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
if (vivid_is_webcam(dev))
-   return -EINVAL;
+   return -ENODATA;

sel->r.left = sel->r.top = 0;
switch (sel->target) {
@@ -872,7 +872,7 @@ int vivid_vid_cap_s_selection(struct file *file, void *fh, 
struct v4l2_selection
if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
if (vivid_is_webcam(dev))
-   return -EINVAL;
+   return -ENODATA;

switch (s->target) {
case V4L2_SEL_TGT_CROP:
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] rcar-vin: add legacy mode for wrong media bus formats

[Niklas Söderlund]

Hi Hans,

Thanks for your feedback.

On 2016-07-20 11:48:40 +0200, Hans Verkuil wrote:
> On 07/08/2016 12:43 PM, Niklas Söderlund wrote:
> > A recent bugfix to adv7180 brought to light that the rcar-vin driver are
> > looking for the wrong media bus format. It was looking for a YUVU format
> > but then expecting UYVY data. The bugfix for adv7180 will break the
> > usage of rcar-vin together with a adv7180 as found on Renesas R-Car2
> > Koelsch boards for example.
> > 
> > This patch fix the rcar-vin driver to look for the correct UYVU formats
> > and adds a legacy mode. The legacy mode is needed since I don't know if
> > other devices provide a incorrect media bus format and I don't want to
> > break any working configurations. Hopefully the legacy mode can be
> > removed sometime in the future.
> 
> I'd rather have a version without the legacy code. You have to assume that
> subdevs return correct values otherwise what's the point of the mediabus
> formats?
> 
> So this is simply an adv7180 bug fix + this r-car fix to stay consistent
> with the adv7180.

On principal I agree with you. My goal with this patch is just to make 
sure there is no case where the rcar-vin driver won't work with the 
adv7180. The plan was to drop the legacy mode in a separate patch after 
both the adv7182 and rcar-vin patches where picked up.

I'm happy to drop the 'legacy support' for the wrong formats from this 
patch as long as I can be sure that there is no breaking. Should I 
rewrite this patch to drop the wrong formats and submit it as a series 
together with the adv7180 patch so they can be picked up together? Or do 
you know of a better way?

> 
> Regards,
> 
>   Hans
> 
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-core.c | 39 
> > +++--
> >  drivers/media/platform/rcar-vin/rcar-dma.c  |  4 +--
> >  2 files changed, 39 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > b/drivers/media/platform/rcar-vin/rcar-core.c
> > index 4b2007b..481d82a 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -37,6 +37,7 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
> > struct v4l2_subdev_mbus_code_enum code = {
> > .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> > };
> > +   bool found;
> >  
> > sd = vin_to_source(vin);
> >  
> > @@ -45,8 +46,8 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
> > code.index++;
> > switch (code.code) {
> > case MEDIA_BUS_FMT_YUYV8_1X16:
> > -   case MEDIA_BUS_FMT_YUYV8_2X8:
> > -   case MEDIA_BUS_FMT_YUYV10_2X10:
> > +   case MEDIA_BUS_FMT_UYVY8_2X8:
> > +   case MEDIA_BUS_FMT_UYVY10_2X10:
> > case MEDIA_BUS_FMT_RGB888_1X24:
> > vin->source.code = code.code;
> > vin_dbg(vin, "Found supported media bus format: %d\n",
> > @@ -57,6 +58,40 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
> > }
> > }
> >  
> > +   /*
> > +* Older versions where looking for the wrong media bus format.
> > +* It where looking for a YUVY format but then treated it as a
> > +* UYVY format. This was not noticed since atlest one subdevice
> > +* used for testing (adv7180) reported a YUVY media bus format
> > +* but provided UYVY data. There might be other unknown subdevices
> > +* which also do this, to not break compatibility try to use them
> > +* in legacy mode.
> > +*/
> > +   found = false;
> > +   code.index = 0;
> > +   while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
> > +   code.index++;
> > +   switch (code.code) {
> > +   case MEDIA_BUS_FMT_YUYV8_2X8:
> > +   vin->source.code = MEDIA_BUS_FMT_UYVY8_2X8;
> > +   found = true;
> > +   break;
> > +   case MEDIA_BUS_FMT_YUYV10_2X10:
> > +   vin->source.code = MEDIA_BUS_FMT_UYVY10_2X10;
> > +   found = true;
> > +   break;
> > +   default:
> > +   break;
> > +   }
> > +
> > +   if (found) {
> > +   vin_err(vin,
> > +   "media bus %d not supported, trying legacy mode 
> > %d\n",
> > +   code.code, vin->source.code);
> > +   return true;
> > +   }
> > +   }
> > +
> > return false;
> >  }
> >  
> > diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> > b/drivers/media/platform/rcar-vin/rcar-dma.c
> > index dad3b03..0836b15 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> > @@ -169,7 +169,7 @@ static int rvin_setup(struct rvin_dev *vin)
> > vnmc |= VNMC_INF_YUV16;
> > input_is_yuv = true;

Re: [PATCH 2/4] dt-bindings: Add a binding for Mediatek MDP

[Minghsiu Tsai]

On Sat, 2016-07-16 at 18:01 -0500, Rob Herring wrote:
> On Thu, Jul 14, 2016 at 08:17:59PM +0800, Minghsiu Tsai wrote:
> > Add a DT binding documentation of MDP for the MT8173 SoC
> > from Mediatek
> > 
> > Signed-off-by: Minghsiu Tsai 
> > ---
> >  .../devicetree/bindings/media/mediatek-mdp.txt |   92 
> > 
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> > b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > new file mode 100644
> > index 000..ef570c3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -0,0 +1,92 @@
> > +* Mediatek Media Data Path
> > +
> > +Media Data Path is used for scaling and color space conversion.
> > +
> > +Required properties:
> > +  - compatible : should contain them as below:
> > +"mediatek,mt8173-mdp"
> > +"mediatek,mt8173-mdp-rdma"
> > +"mediatek,mt8173-mdp-rsz"
> > +"mediatek,mt8173-mdp-wdma"
> > +"mediatek,mt8173-mdp-wrot"
> > +  - clocks : device clocks
> > +  - power-domains : a phandle to the power domain.
> > +  - mediatek,larb : should contain the larbes of current platform
> > +  - iommus : Mediatek IOMMU H/W has designed the fixed associations with
> > +the multimedia H/W. and there is only one multimedia iommu domain.
> > +"iommus = < portid>" the "portid" is from
> > +dt-bindings\iommu\mt8173-iommu-port.h, it means that this portid 
> > will
> > +enable iommu. The portid default is disable iommu if "< 
> > portid>"
> > +don't be added.
> > +  - mediatek,vpu : the node of video processor unit
> 
> These properties don't apply to all the nodes. I think you need a 
> section for each IP block.


I will add description for those IP block, thanks.


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

[GIT PULL FOR v4.8] (v2) Various fixes/cleanups

[Hans Verkuil]

Hi Mauro,

Another bunch of bug fixes and small cleanups for 4.8.

The vb2 fix is particularly nasty, the others are all pretty trivial.

Regards,

Hans

New for v2: added patch "staging: add MEDIA_SUPPORT dependency"


The following changes since commit 009a620848218d521f008141c62f56bf19294dd9:

  [media] cec: always check all_device_types and features (2016-07-19 13:27:46 
-0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.8a

for you to fetch changes up to 7d03aba486d80fcd289ac44f92b95269fd2f:

  staging: add MEDIA_SUPPORT dependency (2016-07-20 13:09:39 +0200)


Arnd Bergmann (1):
  staging: add MEDIA_SUPPORT dependency

Bhaktipriya Shridhar (6):
  pvrusb2: Remove deprecated create_singlethread_workqueue
  gspca: sonixj: Remove deprecated create_singlethread_workqueue
  gspca: vicam: Remove deprecated create_singlethread_workqueue
  gspca: jl2005bcd: Remove deprecated create_singlethread_workqueue
  gspca: finepix: Remove deprecated create_singlethread_workqueue
  ad9389b: Remove deprecated create_singlethread_workqueue

Hans Verkuil (5):
  adv7511: fix VIC autodetect
  cobalt: support reduced fps
  vim2m: copy the other colorspace-related fields as well
  vivid: don't handle CEC_MSG_SET_STREAM_PATH
  airspy: fix compiler warning

Markus Elfring (4):
  tw686x-kh: Delete an unnecessary check before the function call 
"video_unregister_device"
  cec: Delete an unnecessary check before the function call "rc_free_device"
  v4l2-common: Delete an unnecessary check before the function call 
"spi_unregister_device"
  tw686x: Delete an unnecessary check before the function call 
"video_unregister_device"

Steve Longerbeam (3):
  media: adv7180: Fix broken interrupt register access
  media: adv7180: define more registers
  media: adv7180: add power pin control

Vincent Stehlé (1):
  vb2: Fix allocation size of dma_parms

 Documentation/devicetree/bindings/media/i2c/adv7180.txt |   5 ++
 drivers/media/i2c/Kconfig   |   2 +-
 drivers/media/i2c/ad9389b.c |  22 ++---
 drivers/media/i2c/adv7180.c | 118 
+++-
 drivers/media/i2c/adv7511.c |  24 +++--
 drivers/media/pci/cobalt/cobalt-v4l2.c  |   7 ++-
 drivers/media/pci/tw686x/tw686x-video.c |   3 +-
 drivers/media/platform/vim2m.c  |  15 +-
 drivers/media/platform/vivid/vivid-cec.c|  10 
 drivers/media/usb/airspy/airspy.c   |   1 -
 drivers/media/usb/gspca/finepix.c   |   8 +--
 drivers/media/usb/gspca/jl2005bcd.c |   8 +--
 drivers/media/usb/gspca/sonixj.c|  13 ++---
 drivers/media/usb/gspca/vicam.c |   8 +--
 drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h|   1 -
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c |  23 +++--
 drivers/media/v4l2-core/v4l2-common.c   |   2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c  |   2 +-
 drivers/staging/media/Kconfig   |   2 +-
 drivers/staging/media/cec/cec-core.c|   3 +-
 drivers/staging/media/tw686x-kh/tw686x-kh-video.c   |   3 +-
 21 files changed, 157 insertions(+), 123 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.8] Various fixes/cleanups

[Hans Verkuil]

Hi Mauro,

Another bunch of bug fixes and small cleanups for 4.8.

The vb2 fix is particularly nasty, the others are all pretty trivial.

Regards,

Hans

The following changes since commit 009a620848218d521f008141c62f56bf19294dd9:

  [media] cec: always check all_device_types and features (2016-07-19 13:27:46 
-0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.8a

for you to fetch changes up to 50200862a0c4757fa72cf4f188ce37add25673cd:

  airspy: fix compiler warning (2016-07-20 12:45:51 +0200)


Bhaktipriya Shridhar (6):
  pvrusb2: Remove deprecated create_singlethread_workqueue
  gspca: sonixj: Remove deprecated create_singlethread_workqueue
  gspca: vicam: Remove deprecated create_singlethread_workqueue
  gspca: jl2005bcd: Remove deprecated create_singlethread_workqueue
  gspca: finepix: Remove deprecated create_singlethread_workqueue
  ad9389b: Remove deprecated create_singlethread_workqueue

Hans Verkuil (5):
  adv7511: fix VIC autodetect
  cobalt: support reduced fps
  vim2m: copy the other colorspace-related fields as well
  vivid: don't handle CEC_MSG_SET_STREAM_PATH
  airspy: fix compiler warning

Markus Elfring (4):
  tw686x-kh: Delete an unnecessary check before the function call 
"video_unregister_device"
  cec: Delete an unnecessary check before the function call "rc_free_device"
  v4l2-common: Delete an unnecessary check before the function call 
"spi_unregister_device"
  tw686x: Delete an unnecessary check before the function call 
"video_unregister_device"

Steve Longerbeam (3):
  media: adv7180: Fix broken interrupt register access
  media: adv7180: define more registers
  media: adv7180: add power pin control

Vincent Stehlé (1):
  vb2: Fix allocation size of dma_parms

 Documentation/devicetree/bindings/media/i2c/adv7180.txt |   5 ++
 drivers/media/i2c/Kconfig   |   2 +-
 drivers/media/i2c/ad9389b.c |  22 ++---
 drivers/media/i2c/adv7180.c | 118 
+++-
 drivers/media/i2c/adv7511.c |  24 +++--
 drivers/media/pci/cobalt/cobalt-v4l2.c  |   7 ++-
 drivers/media/pci/tw686x/tw686x-video.c |   3 +-
 drivers/media/platform/vim2m.c  |  15 +-
 drivers/media/platform/vivid/vivid-cec.c|  10 
 drivers/media/usb/airspy/airspy.c   |   1 -
 drivers/media/usb/gspca/finepix.c   |   8 +--
 drivers/media/usb/gspca/jl2005bcd.c |   8 +--
 drivers/media/usb/gspca/sonixj.c|  13 ++---
 drivers/media/usb/gspca/vicam.c |   8 +--
 drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h|   1 -
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c |  23 +++--
 drivers/media/v4l2-core/v4l2-common.c   |   2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c  |   2 +-
 drivers/staging/media/cec/cec-core.c|   3 +-
 drivers/staging/media/tw686x-kh/tw686x-kh-video.c   |   3 +-
 20 files changed, 156 insertions(+), 122 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] airspy: fix compiler warning

[Hans Verkuil]

drivers/media/usb/airspy/airspy.c: In function 'airspy_probe':
drivers/media/usb/airspy/airspy.c:1084:1: warning: label 
'err_unregister_v4l2_dev' defined but not used [-Wunused-label]

Signed-off-by: Hans Verkuil 
---
 drivers/media/usb/airspy/airspy.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/usb/airspy/airspy.c 
b/drivers/media/usb/airspy/airspy.c
index 19cd64c..fe031b0 100644
--- a/drivers/media/usb/airspy/airspy.c
+++ b/drivers/media/usb/airspy/airspy.c
@@ -1081,7 +1081,6 @@ static int airspy_probe(struct usb_interface *intf,

 err_free_controls:
v4l2_ctrl_handler_free(>hdl);
-err_unregister_v4l2_dev:
v4l2_device_unregister(>v4l2_dev);
 err_free_mem:
kfree(s);
-- 
2.8.1

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

Re: [PATCH 0/6] radio: Utilize the module_isa_driver macro

[Hans Verkuil]

On 07/18/2016 04:45 PM, William Breathitt Gray wrote:
> The module_isa_driver macro is a helper macro for ISA drivers which do
> not do anything special in module init/exit. This patchset eliminates a
> lot of ISA driver registration boilerplate code by utilizing
> module_isa_driver, which replaces module_init and module_exit.
> 
> William Breathitt Gray (6):
>   radio: terratec: Utilize the module_isa_driver macro
>   radio: rtrack2: Utilize the module_isa_driver macro
>   radio: trust: Utilize the module_isa_driver macro
>   radio: zoltrix: Utilize the module_isa_driver macro
>   radio: aztech: Utilize the module_isa_driver macro
>   radio: aimslab: Utilize the module_isa_driver macro

Good idea, but it doesn't compile:

module_isa_driver(terratec_driver.driver, 1);

expands to:

static int __init terratec_driver.driver_init(void)
{
return isa_register_driver(&(terratec_driver.driver), 1);
}

So now the function name contains a '.' and it won't compile.

Regards,

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

Re: next build: 7 warnings 0 failures (next/next-20160720)

[Arnd Bergmann]

On Wednesday, July 20, 2016 3:01:14 AM CEST Olof's autobuilder wrote:
>Passed: 122
>Failed: 0
>Warnings:   7
>Section mismatches: 0

Looking pretty good, almost no warnings left. The first one in this
list is the only one that already exists in v4.7 (and a long time
before that), all other preexisting warnings are fixed in -next.

The kernelci autobuilder finds a couple of other warnings on top
of these, because they build more unusual configurations and use
some slightly older compilers that produce false positives.

> Warnings:
>   1 drivers/infiniband/core/cma.c:1242:12: warning: 
> 'src_addr_storage.sin_addr.s_addr' may be used uninitialized in this function 
> [-Wmaybe-uninitialized]

I sent a patch on July 4 to the infiniband list but got no reply.
It only shows up on powerpc, presumably with an older compiler, so I
don't consider this as urgent, the only reason to fix it up would be
to get to zero warnings for the common architectures.

Doug, any chance you can still pick up "infiniband: shut up a
maybe-uninitialized warning" for 4.8?

>   1 drivers/tty/serial/8250/8250_fintek.c:34:0: warning: "IRQ_MODE" 
> redefined

I sent a patch on June 26 to Greg, but he hasn't applied any serial
driver patches since June 25, so I assume it's in his queue and will
make it into v4.8 without further action on my side.

>   2 drivers/media/dvb-frontends/cxd2841er.c:3408:40: warning: 
> 'carrier_offset' may be used uninitialized in this function 
> [-Wmaybe-uninitialized]

It's in patchwork, so I assume Mauro will get to it in time:
https://patchwork.linuxtv.org/patch/35398/

The warning was introduced by a patch outside of drivers/media
in linux-mm ("dynamic_debug: add jump label support").

>   3 drivers/net/wireless/ti/wlcore/spi.c:457:6: warning: unused variable 
> 'ret' [-Wunused-variable]

This came up today, and the author of the patch that broke it already
sent a fix "wlcore: spi: fix build warning caused by redundant variable".

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

Re: [PATCH 00/18] Complete moving media documentation to ReST format

[Mauro Carvalho Chehab]

Em Wed, 20 Jul 2016 08:07:54 +0200
Markus Heiser  escreveu:

> Am 20.07.2016 um 02:00 schrieb Mauro Carvalho Chehab 
> :
> 
> > Em Tue, 19 Jul 2016 16:49:16 -0600
> > Jonathan Corbet  escreveu:
> >   
> >> On Tue, 19 Jul 2016 11:53:19 -0300
> >> Mauro Carvalho Chehab  wrote:
> >>   
> >>> So, I guess we should set the minimal requirement to 1.2.x.
> >> 
> >> *sigh*.
> >> 
> >> I hate to do that; things are happening quickly enough with Sphinx that
> >> it would be nice to be able to count on a newer version.  That said, one
> >> of my goals in this whole thing was to make it *easier* for developers to
> >> generate the docs; the DocBook toolchain has always been notoriously
> >> difficult in that regard.  Forcing people to install a newer sphinx by
> >> hand is not the way to get there.
> >> 
> >> So I guess we need to make sure things work with 1.2 for now.  I'd hope
> >> we could push that to at least 1.3 before too long, though, once the
> >> community distributions are there.  I think we can be a *bit* more
> >> aggressive with the docs than with the kernel as a whole.  
> > 
> > Yeah, that seems to be the right strategy, IMHO. With the patch I sent,
> > the media books will again build fine with 1.2.  
> 
> 
> It is a difficult situation, whatever we do, we will get in trouble. To
> handle this, (IMHO) at first we need a reference documentation.
> 
> > What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
> > site only has documentation for the very latest version, making harder
> > to ensure that we're using only the tags supported by a certain version.  
> 
> We could build the documentation of the (e.g.) 1.2 tag
> 
> https://github.com/sphinx-doc/sphinx/tree/1.2
> 
> by checkout the tag, cd to "./doc" and run "make html".
> I haven't tested yet, but it should work this way.
> 
> Jon, what do you think ... could we serve this 1.2 doc 
> on https://www.kernel.org/doc/ as reference?

Yeah, building the documentation for 1.2.3 worked. I added the
documentation at linuxtv.org:
https://linuxtv.org/downloads/sphinx-1.2.3/

Yet, I agree that the best would be to host it at kernel.org,
and add a link for it at kernel-documentation.rst.

> And whats about those who have 1.3 (or any version >1.2) as default 
> in the linux distro? Should they install a virtualenv?  ... it is
> a dilemma.

Well, they won't notice if a newer tag is used. IMHO, the best would
be if we had some tag at the configuration file or at the book itself
that would specify the sphinx version, and produce an ERROR if a
tag for newer versions would be used.

Not having that means more work for maintainers, as we'll need to
check it when merging patches for documentation.

> 
> Sorry that I have not identified this earlier ... I'am using python
> a long time and for me it is common to set up build processes
> with a version decoupled from the OS version, mostly the up to date
> version .. thats why I have neglected any version problems :(
> 
> -- Markus --
> 
> 
> 
> > 
> > Thanks,
> > Mauro  
> 



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

em288xx and lna - how to enable?

[Martin]

Hi,

I see that my card 292e has LNA support:
https://patchwork.linuxtv.org/patch/23763/

but searching I can't find how to enable this the force option
force_lna_activation=1 that the t500 uses isn't recognised

Please could someone tell me if this is configurable an if so how to
configure it?

Thanks,
M

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

Re: [PATCH] [media] rcar-vin: add legacy mode for wrong media bus formats

[Hans Verkuil]

On 07/08/2016 12:43 PM, Niklas Söderlund wrote:
> A recent bugfix to adv7180 brought to light that the rcar-vin driver are
> looking for the wrong media bus format. It was looking for a YUVU format
> but then expecting UYVY data. The bugfix for adv7180 will break the
> usage of rcar-vin together with a adv7180 as found on Renesas R-Car2
> Koelsch boards for example.
> 
> This patch fix the rcar-vin driver to look for the correct UYVU formats
> and adds a legacy mode. The legacy mode is needed since I don't know if
> other devices provide a incorrect media bus format and I don't want to
> break any working configurations. Hopefully the legacy mode can be
> removed sometime in the future.

I'd rather have a version without the legacy code. You have to assume that
subdevs return correct values otherwise what's the point of the mediabus
formats?

So this is simply an adv7180 bug fix + this r-car fix to stay consistent
with the adv7180.

Regards,

Hans

> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 39 
> +++--
>  drivers/media/platform/rcar-vin/rcar-dma.c  |  4 +--
>  2 files changed, 39 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 4b2007b..481d82a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -37,6 +37,7 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
>   struct v4l2_subdev_mbus_code_enum code = {
>   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
>   };
> + bool found;
>  
>   sd = vin_to_source(vin);
>  
> @@ -45,8 +46,8 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
>   code.index++;
>   switch (code.code) {
>   case MEDIA_BUS_FMT_YUYV8_1X16:
> - case MEDIA_BUS_FMT_YUYV8_2X8:
> - case MEDIA_BUS_FMT_YUYV10_2X10:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
>   case MEDIA_BUS_FMT_RGB888_1X24:
>   vin->source.code = code.code;
>   vin_dbg(vin, "Found supported media bus format: %d\n",
> @@ -57,6 +58,40 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
>   }
>   }
>  
> + /*
> +  * Older versions where looking for the wrong media bus format.
> +  * It where looking for a YUVY format but then treated it as a
> +  * UYVY format. This was not noticed since atlest one subdevice
> +  * used for testing (adv7180) reported a YUVY media bus format
> +  * but provided UYVY data. There might be other unknown subdevices
> +  * which also do this, to not break compatibility try to use them
> +  * in legacy mode.
> +  */
> + found = false;
> + code.index = 0;
> + while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
> + code.index++;
> + switch (code.code) {
> + case MEDIA_BUS_FMT_YUYV8_2X8:
> + vin->source.code = MEDIA_BUS_FMT_UYVY8_2X8;
> + found = true;
> + break;
> + case MEDIA_BUS_FMT_YUYV10_2X10:
> + vin->source.code = MEDIA_BUS_FMT_UYVY10_2X10;
> + found = true;
> + break;
> + default:
> + break;
> + }
> +
> + if (found) {
> + vin_err(vin,
> + "media bus %d not supported, trying legacy mode 
> %d\n",
> + code.code, vin->source.code);
> + return true;
> + }
> + }
> +
>   return false;
>  }
>  
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index dad3b03..0836b15 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -169,7 +169,7 @@ static int rvin_setup(struct rvin_dev *vin)
>   vnmc |= VNMC_INF_YUV16;
>   input_is_yuv = true;
>   break;
> - case MEDIA_BUS_FMT_YUYV8_2X8:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
>   /* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
>   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
>   VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
> @@ -178,7 +178,7 @@ static int rvin_setup(struct rvin_dev *vin)
>   case MEDIA_BUS_FMT_RGB888_1X24:
>   vnmc |= VNMC_INF_RGB888;
>   break;
> - case MEDIA_BUS_FMT_YUYV10_2X10:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
>   /* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
>   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
>   VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
> 
--
To unsubscribe from 

[PATCH] vivid: don't handle CEC_MSG_SET_STREAM_PATH

[Hans Verkuil]

vivid shouldn't process the CEC_MSG_SET_STREAM_PATH message: this will confuse
userspace follower code because it isn't aware of the state change of becoming
an active source.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/platform/vivid/vivid-cec.c 
b/drivers/media/platform/vivid/vivid-cec.c
index 66aa729..f9f878b 100644
--- a/drivers/media/platform/vivid/vivid-cec.c
+++ b/drivers/media/platform/vivid/vivid-cec.c
@@ -169,7 +169,6 @@ static int vivid_received(struct cec_adapter *adap, struct 
cec_msg *msg)
struct vivid_dev *dev = adap->priv;
struct cec_msg reply;
u8 dest = cec_msg_destination(msg);
-   u16 pa;
u8 disp_ctl;
char osd[14];

@@ -178,15 +177,6 @@ static int vivid_received(struct cec_adapter *adap, struct 
cec_msg *msg)
cec_msg_init(, dest, cec_msg_initiator(msg));

switch (cec_msg_opcode(msg)) {
-   case CEC_MSG_SET_STREAM_PATH:
-   if (cec_is_sink(adap))
-   return -ENOMSG;
-   cec_ops_set_stream_path(msg, );
-   if (pa != adap->phys_addr)
-   return -ENOMSG;
-   cec_msg_active_source(, adap->phys_addr);
-   cec_transmit_msg(adap, , false);
-   break;
case CEC_MSG_SET_OSD_STRING:
if (!cec_is_sink(adap))
return -ENOMSG;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/10] media: adv7180: define more registers

[Lars-Peter Clausen]

On 07/20/2016 02:03 AM, Steve Longerbeam wrote:
> Replace hard-coded addresses with new register macro defines. No
> functional changes.
> 
> Signed-off-by: Steve Longerbeam 

Acked-by: Lars-Peter Clausen 

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

Re: [PATCH v2 05/10] media: adv7180: add power pin control

[Lars-Peter Clausen]

On 07/20/2016 02:03 AM, Steve Longerbeam wrote:
> Some targets control the ADV7180 power pin via a gpio, so add
> optional support for "powerdown" pin control.
> 
> Signed-off-by: Steve Longerbeam 
> Tested-by: Tim Harvey 
> Acked-by: Tim Harvey 
> Cc: Lars-Peter Clausen 

Looks good, thanks.

Acked-by: Lars-Peter Clausen 

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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 9:09 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>>> >> Hello,
>>> >>
>>> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
>>> >> BeagleBoneBlack SBC.
>>> >> I am sure that both of them are fine and work properly.
>>> >> I am running Linux 4.6.4 (my kernel config is available at 
>>> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue 
>>> >> with frame transfer when high resolution formats are used.
>>> >>
>>> >> The issue is the following. I use simple v4l2 example tool (taken from 
>>> >> API docs), which source code is available at http://pastebin.com/grcNXxfe
>>> >>
>>> >> When I use (see line 488) 640x480 frames
>>> >>
>>> >> fmt.fmt.pix.width   = 640;
>>> >> fmt.fmt.pix.height  = 480;
>>> >>
>>> >> then I get "select timeout" and don't get any frames.
>>> >>
>>> >> When I use 320x240 frames
>>> >>
>>> >> fmt.fmt.pix.width   = 320;
>>> >> fmt.fmt.pix.height  = 240;
>>> >>
>>> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
>>> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>>> >> It looks like there are pauses between bulks of frames (frame counter 
>>> >> and timestamp as returned from v4l2 API):
>>> >>
>>> >> 3 3705.142553
>>> >> 8 3705.342533
>>> >> 13 3705.542517
>>> >> 110 3708.776208
>>> >> 115 3708.976190
>>> >> 120 3709.176169
>>> >> 125 3709.376152
>>> >> 130 3709.576144
>>> >> 226 3712.807848
>>> >>
>>> >> When I use tiny 160x120 frames
>>> >>
>>> >> fmt.fmt.pix.width   = 160;
>>> >> fmt.fmt.pix.height  = 120;
>>> >>
>>> >> then more frames are received. See output example at 
>>> >> https://yadi.sk/d/DedBmH6ftSc9t
>>> >> That is why I thought that everything was fine in May when used tiny 
>>> >> xawtv window to check kernel OOPS presence (see 
>>> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>>> >>
>>> >> Even more. When I introduce USB hub between the host and the webcam, I 
>>> >> can not receive even any 320x240 frames.
>>> >>
>>> >> I've managed to use ftrace to see what is going on when no frames are 
>>> >> received.
>>> >> I've found that pwc_isoc_handler is called frequently as the following:
>>> >>
>>> >>  0)   |  pwc_isoc_handler [pwc]() {
>>> >>  0)   |usb_submit_urb [usbcore]() {
>>> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>>> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>>> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>>> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>>> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>>> >>  0)   5.750 us|  }
>>> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>>> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>>> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>>> >>  0)   0.792 us|  _raw_spin_lock();
>>> >>  0)   0.791 us|  _raw_spin_unlock();
>>> >>  0) + 10.500 us   |}
>>> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>>> >>  0) + 25.375 us   |  }
>>> >>  0) + 45.208 us   |}
>>> >>  0) + 51.042 us   |  }
>>> >>  0) + 56.084 us   |}
>>> >>  0) + 61.292 us   |  }
>>> >>
>>> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I 
>>> >> get "select timeout" in userspace.
>>> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but 
>>> >> I can recompile it, if you think that it could provide more information. 
>>> >> I am also ready to perform additional tests (use usbmon maybe?).
>>> >>
>>> >> How could this issue be resolved?
>>> >>
>>> >> Thank you.
>>> >
>>> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>>> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
>>> > tokens in every other SOF, so only half of the bus bandwidth is
>>> > utilized, which causes video frame drops in higher resolution.
>>> >
>>>
>>> Yes, I do use DMA:
>>>
>>> CONFIG_USB_TI_CPPI41_DMA=y
>>
>> Okay.
>>
>>>
>>> > To confirm this, use a bus analyzer to capture a bus trace, you would
>>> > see no IN tokens in every other SOF while transfering Isoch packets.
>>> >
>>>
>>> I am sorry, I am new to USB debugging. Do you mean I need to use
>>> usbmon or some external hardware device?
>>
>> I barely use usbmon, and not sure if it gives the information I am
>> looking for. But I meant the external test equipment - USB bus protocol
>> analyzer - a bus packet sniffer.
>>
>
> Now I see. I've googled it, they 

Re: [PATCH v8 0/10] Output raw touch data via V4L2

[Hans Verkuil]

Hi Nick,

This series looks good. I plan on taking it for 4.9. I have to wait until
4.8-rc1 is out and merged in our media_tree repo before I can make the pull
request, probably in about 3 weeks from now.

One request: can you post the 'v4l2-compliance -a -f' output, using the latest
v4l2-compliance code with your patch on top.

I'd like to make sure all input and format combinations are working as they 
should.

Regards,

Hans

On 07/18/2016 11:10 PM, Nick Dyer wrote:
> This is a series of patches to add output of raw touch diagnostic data via 
> V4L2
> to the Atmel maXTouch and Synaptics RMI4 drivers.
> 
> It's a rewrite of the previous implementation which output via debugfs: it now
> uses a V4L2 device in a similar way to the sur40 driver.
> 
> We have a utility which can read the data and display it in a useful format:
> https://github.com/ndyer/heatmap/commits/heatmap-v4l
> 
> Changes in v8:
> - Split out docs changes, rework in RST/Sphinx, and rebase against docs-next
> - Update for changes to vb2_queue alloc_ctxs
> - Rebase against git://linuxtv.org/media_tree.git and re-test
> 
> Changes in v7:
> - Tested by Andrew Duggan and Chris Healy.
> - Update bus_info to add "rmi4:" bus.
> - Fix code style issues in sur40 changes.
> 
> Changes in v6:
> - Remove BUF_TYPE_TOUCH_CAPTURE, as discussed with Hans V touch devices will
>   use BUF_TYPE_VIDEO_CAPTURE.
> - Touch devices should now register CAP_VIDEO_CAPTURE: CAP_TOUCH just says 
> that
>   this is a touch device, not a video device, but otherwise it acts the same.
> - Add some code to v4l_s_fmt() to set sensible default values for fields not
>   used by touch.
> - Improve naming/doc of RMI4 F54 report types.
> - Various minor DocBook fixes, and split to separate patch.
> - Update my email address.
> - Rework sur40 changes so that PIX_FMT_GREY is supported for backward
>   compatibility. Florian is it possible for you to test?
> 
> Changes in v5 (Hans Verkuil review):
> - Update v4l2-core:
>   - Add VFL_TYPE_TOUCH, V4L2_BUF_TYPE_TOUCH_CAPTURE and V4L2_CAP_TOUCH
>   - Change V4L2_INPUT_TYPE_TOUCH_SENSOR to V4L2_INPUT_TYPE_TOUCH
>   - Improve DocBook documentation
>   - Add FMT definitions for touch data
>   - Note this will need the latest version of the heatmap util
> - Synaptics RMI4 driver:
>   - Remove some less important non full frame report types
>   - Switch report type names to const char * array
>   - Move a static array to inside context struct
> - Split sur40 changes to a separate commit
> 
> Changes in v4:
> - Address nits from the input side in atmel_mxt_ts patches (Dmitry Torokhov)
> - Add Synaptics RMI4 F54 support patch
> 
> Changes in v3:
> - Address V4L2 review comments from Hans Verkuil
> - Run v4l-compliance and fix all issues - needs minor patch here:
>   https://github.com/ndyer/v4l-utils/commit/cf50469773f
> 
> Changes in v2:
> - Split pixfmt changes into separate commit and add DocBook
> - Introduce VFL_TYPE_TOUCH_SENSOR and /dev/v4l-touch
> - Remove "single node" support for now, it may be better to treat it as
>   metadata later
> - Explicitly set VFL_DIR_RX
> - Fix Kconfig
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/10] v4l: of: add "newavmode" property for Analog Devices codecs

[Hans Verkuil]

On 07/20/2016 02:03 AM, Steve Longerbeam wrote:
> This patch adds a "newavmode" boolean property as part of the v4l2 endpoint
> properties. This indicates an Analog Devices decoder is generating EAV/SAV
> codes to suit Analog Devices encoders.
> 
> Signed-off-by: Steve Longerbeam 
> Cc: Mauro Carvalho Chehab 
> Cc: Javier Martinez Canillas 
> Cc: Laurent Pinchart 
> Cc: Sakari Ailus 
> ---
>  Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
>  drivers/media/v4l2-core/v4l2-of.c| 4 
>  include/media/v4l2-mediabus.h| 5 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
> b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 9cd2a36..6f2df51 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -88,6 +88,8 @@ Optional endpoint properties
>  - field-even-active: field signal level during the even field data 
> transmission.
>  - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel 
> clock
>signal.
> +- newavmode: a boolean property to indicate an Analog Devices decoder is
> +  operating in NEWAVMODE. Valid for BT.656 busses only.

This property is adv7180 specific and does not belong here.

Add this to Documentation/devicetree/bindings/media/i2c/adv7180.txt instead.

Nacked-by: Hans Verkuil 

Regards,

Hans

>  - sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for
>LOW/HIGH respectively.
>  - data-lanes: an array of physical data lane indexes. Position of an entry
> diff --git a/drivers/media/v4l2-core/v4l2-of.c 
> b/drivers/media/v4l2-core/v4l2-of.c
> index 93b3368..719a7d1 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -109,6 +109,10 @@ static void v4l2_of_parse_parallel_bus(const struct 
> device_node *node,
>   flags |= v ? V4L2_MBUS_DATA_ACTIVE_HIGH :
>   V4L2_MBUS_DATA_ACTIVE_LOW;
>  
> + if (endpoint->bus_type == V4L2_MBUS_BT656 &&
> + of_get_property(node, "newavmode", ))
> + flags |= V4L2_MBUS_NEWAVMODE;
> +
>   if (of_get_property(node, "slave-mode", ))
>   flags |= V4L2_MBUS_SLAVE;
>   else
> diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
> index 34cc99e..0bd5f0e 100644
> --- a/include/media/v4l2-mediabus.h
> +++ b/include/media/v4l2-mediabus.h
> @@ -43,6 +43,11 @@
>  /* Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH 
> respectively. */
>  #define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH  (1 << 12)
>  #define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW   (1 << 13)
> +/*
> + * BT.656 specific flags
> + */
> +/* Analog Device's NEWAVMODE */
> +#define V4L2_MBUS_NEWAVMODE  (1 << 14)
>  
>  /* Serial flags */
>  /* How many lanes the client can use */
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] [media] pci: Add tw5864 driver

[Hans Verkuil]

On 07/20/2016 03:42 AM, Andrey Utkin wrote:
> Changes since v5:
>  - Rework known issues notice as suggested by Hans Verkuil (and previously 
> Joe Perches)
> 
> I am leaving for a vacation in a day and won't respond before 3rd of August.
> I wish to all of you to enjoy your time, too.
> 
> Thanks to all the reviewers for their efforts.
> 



> +static int tw5864_input_std_get(struct tw5864_input *input,
> + enum tw5864_vid_std *std_arg)
> +{
> + struct tw5864_dev *dev = input->root;
> + enum tw5864_vid_std std;
> + u8 std_reg = tw_indir_readb(TW5864_INDIR_VIN_E(input->nr));
> +
> + std = (std_reg & 0x70) >> 4;
> +
> + if (std_reg & 0x80) {
> + dev_err(>pci->dev,
> + "Video format detection is in progress, please wait\n");

Use dev_dbg instead of dev_err.

> + return -EAGAIN;
> + }
> +
> + if (std == STD_INVALID) {
> + dev_err(>pci->dev, "No valid video format detected\n");
> + return -EPERM;

This is still wrong. From my v5 review:

"In this case set *std_arg to V4L2_STD_UNKNOWN and just return 0. As per the 
QUERYSTD spec."

Also, don't use dev_err here. There is nothing wrong with not being able to 
detect
a valid format. I'd just drop the message.

> + }
> +
> + *std_arg = std;
> + return 0;
> +}

Regards,

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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 0:34 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> Hello,
>> >>
>> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
>> >> BeagleBoneBlack SBC.
>> >> I am sure that both of them are fine and work properly.
>> >> I am running Linux 4.6.4 (my kernel config is available at 
>> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue 
>> >> with frame transfer when high resolution formats are used.
>> >>
>> >> The issue is the following. I use simple v4l2 example tool (taken from 
>> >> API docs), which source code is available at http://pastebin.com/grcNXxfe
>> >>
>> >> When I use (see line 488) 640x480 frames
>> >>
>> >> fmt.fmt.pix.width   = 640;
>> >> fmt.fmt.pix.height  = 480;
>> >>
>> >> then I get "select timeout" and don't get any frames.
>> >>
>> >> When I use 320x240 frames
>> >>
>> >> fmt.fmt.pix.width   = 320;
>> >> fmt.fmt.pix.height  = 240;
>> >>
>> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
>> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> It looks like there are pauses between bulks of frames (frame counter and 
>> >> timestamp as returned from v4l2 API):
>> >>
>> >> 3 3705.142553
>> >> 8 3705.342533
>> >> 13 3705.542517
>> >> 110 3708.776208
>> >> 115 3708.976190
>> >> 120 3709.176169
>> >> 125 3709.376152
>> >> 130 3709.576144
>> >> 226 3712.807848
>> >>
>> >> When I use tiny 160x120 frames
>> >>
>> >> fmt.fmt.pix.width   = 160;
>> >> fmt.fmt.pix.height  = 120;
>> >>
>> >> then more frames are received. See output example at 
>> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> That is why I thought that everything was fine in May when used tiny 
>> >> xawtv window to check kernel OOPS presence (see 
>> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >>
>> >> Even more. When I introduce USB hub between the host and the webcam, I 
>> >> can not receive even any 320x240 frames.
>> >>
>> >> I've managed to use ftrace to see what is going on when no frames are 
>> >> received.
>> >> I've found that pwc_isoc_handler is called frequently as the following:
>> >>
>> >>  0)   |  pwc_isoc_handler [pwc]() {
>> >>  0)   |usb_submit_urb [usbcore]() {
>> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >>  0)   5.750 us|  }
>> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>> >>  0)   0.792 us|  _raw_spin_lock();
>> >>  0)   0.791 us|  _raw_spin_unlock();
>> >>  0) + 10.500 us   |}
>> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>> >>  0) + 25.375 us   |  }
>> >>  0) + 45.208 us   |}
>> >>  0) + 51.042 us   |  }
>> >>  0) + 56.084 us   |}
>> >>  0) + 61.292 us   |  }
>> >>
>> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get 
>> >> "select timeout" in userspace.
>> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but 
>> >> I can recompile it, if you think that it could provide more information. 
>> >> I am also ready to perform additional tests (use usbmon maybe?).
>> >>
>> >> How could this issue be resolved?
>> >>
>> >> Thank you.
>> >
>> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
>> > tokens in every other SOF, so only half of the bus bandwidth is
>> > utilized, which causes video frame drops in higher resolution.
>> >
>>
>> Yes, I do use DMA:
>>
>> CONFIG_USB_TI_CPPI41_DMA=y
>
> Okay.
>
>>
>> > To confirm this, use a bus analyzer to capture a bus trace, you would
>> > see no IN tokens in every other SOF while transfering Isoch packets.
>> >
>>
>> I am sorry, I am new to USB debugging. Do you mean I need to use
>> usbmon or some external hardware device?
>
> I barely use usbmon, and not sure if it gives the information I am
> looking for. But I meant the external test equipment - USB bus protocol
> analyzer - a bus packet sniffer.
>

Now I see. I've googled it, they start from $1000, I don't know
when/whether/where I can get one to try.
Until that, could I check something else? For instance, disable
CONFIG_USB_TI_CPPI41_DMA.

I've found that after 

Re: [PATCH 00/18] Complete moving media documentation to ReST format

[Markus Heiser]

Am 20.07.2016 um 02:00 schrieb Mauro Carvalho Chehab :

> Em Tue, 19 Jul 2016 16:49:16 -0600
> Jonathan Corbet  escreveu:
> 
>> On Tue, 19 Jul 2016 11:53:19 -0300
>> Mauro Carvalho Chehab  wrote:
>> 
>>> So, I guess we should set the minimal requirement to 1.2.x.  
>> 
>> *sigh*.
>> 
>> I hate to do that; things are happening quickly enough with Sphinx that
>> it would be nice to be able to count on a newer version.  That said, one
>> of my goals in this whole thing was to make it *easier* for developers to
>> generate the docs; the DocBook toolchain has always been notoriously
>> difficult in that regard.  Forcing people to install a newer sphinx by
>> hand is not the way to get there.
>> 
>> So I guess we need to make sure things work with 1.2 for now.  I'd hope
>> we could push that to at least 1.3 before too long, though, once the
>> community distributions are there.  I think we can be a *bit* more
>> aggressive with the docs than with the kernel as a whole.
> 
> Yeah, that seems to be the right strategy, IMHO. With the patch I sent,
> the media books will again build fine with 1.2.


It is a difficult situation, whatever we do, we will get in trouble. To
handle this, (IMHO) at first we need a reference documentation.

> What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
> site only has documentation for the very latest version, making harder
> to ensure that we're using only the tags supported by a certain version.

We could build the documentation of the (e.g.) 1.2 tag

https://github.com/sphinx-doc/sphinx/tree/1.2

by checkout the tag, cd to "./doc" and run "make html".
I haven't tested yet, but it should work this way.

Jon, what do you think ... could we serve this 1.2 doc 
on https://www.kernel.org/doc/ as reference?

And whats about those who have 1.3 (or any version >1.2) as default 
in the linux distro? Should they install a virtualenv?  ... it is
a dilemma.

Sorry that I have not identified this earlier ... I'am using python
a long time and for me it is common to set up build processes
with a version decoupled from the OS version, mostly the up to date
version .. thats why I have neglected any version problems :(

-- Markus --



> 
> Thanks,
> Mauro

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