Re: [PATCH] Documentation:media:v4l2:Add vivid metadata doc

[Mauro Carvalho Chehab]

Em Fri, 4 Oct 2019 13:59:00 +0200
Hans Verkuil  escreveu:

> On 10/4/19 1:55 PM, Vandana BN wrote:
> > Adds new file for describing new metadata format V4L2_META_FMT_VIVID added 
> > in vivid driver.
> > 
> > Signed-off-by: Vandana BN 
> > ---
> >  Documentation/media/uapi/v4l/meta-formats.rst |  1 +
> >  .../media/uapi/v4l/pixfmt-meta-vivid.rst  | 43 +++
> >  2 files changed, 44 insertions(+)
> >  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vivid.rst
> > 
> > diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
> > b/Documentation/media/uapi/v4l/meta-formats.rst
> > index b10ca9ee3968..74c8659ee9d6 100644
> > --- a/Documentation/media/uapi/v4l/meta-formats.rst
> > +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> > @@ -24,3 +24,4 @@ These formats are used for the :ref:`metadata` interface 
> > only.
> >  pixfmt-meta-uvc
> >  pixfmt-meta-vsp1-hgo
> >  pixfmt-meta-vsp1-hgt
> > +pixfmt-meta-vivid
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vivid.rst 
> > b/Documentation/media/uapi/v4l/pixfmt-meta-vivid.rst
> > new file mode 100644
> > index ..e6c349fadf30
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vivid.rst
> > @@ -0,0 +1,43 @@
> > +.. 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, with no Invariant Sections, no Front-Cover Texts
> > +.. and no Back-Cover Texts. A copy of the license is included at
> > +.. Documentation/media/uapi/fdl-appendix.rst.
> > +..
> > +.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections

Could you please re-license it with dual GFDL and GPL?

See for example:
Documentation/media/uapi/mediactl/media-request-ioc-queue.rst

For the text we're adding to all new documentation files on media.

Regards,
Mauro

> > +
> > +.. _v4l2-meta-fmt-vivid:
> > +
> > +***
> > +V4L2_META_FMT_VIVID ('VIVID')  
> 
> That's a fivecc instead of a fourcc :-)
> 
> > +***
> > +
> > +VIVID Metadata Format
> > +
> > +
> > +Description
> > +===
> > +
> > +This format describes metadata in vivid driver.  
> 
> Say: ...describes the metadata format used by the vivid driver.
> 
> > +
> > +It sets Brightness, Saturation, Contrast and Hue, each of which maps to
> > +corresponding control in vivid driver with respect to its range and 
> > default values.  
> 
> ...controls of the...
> ...respect to the range...
> 
> > +
> > +It contains the following fields:
> > +
> > +.. flat-table:: VIVID Metadata
> > +:widths: 1 4
> > +:header-rows:  1
> > +:stub-columns: 0
> > +
> > +* - Field
> > +  - Description
> > +* - u16 brightness;
> > +  - Image brightness, value can be in range 0 to 255, with default 
> > value as 128.  
> 
>   - Image brightness, the value is in the range 0 to 255, with the 
> default value as 128.
> 
> > +* - u16 contrast;
> > +  - Image contrast, value can be in range 0 to 255, with default value 
> > as 128.
> > +* - u16 saturation;
> > +  - Image color saturation, value can be in range 0 to 255, with 
> > default value as 128.
> > +* - s16 hue;
> > +  - Image color balance, value can be in range -128 to 128, with 
> > default value as 0.
> >   
> 
> Ditto.
> 
> Regards,
> 
>   Hans



Thanks,
Mauro

Re: v4l-utils undefined symbol: dvb_dev_alloc

[Mauro Carvalho Chehab]

Em Sat, 12 Oct 2019 18:28:41 +0100
_ _ _ _ _  escreveu:

> I've been waiting for a working version of DVB-S2 capable tools and utilities 
> to appear in a stable release of Mint, but  it hasn't happened yet, so I 
> decided to build the latest stable v4l-utils from source.
> 
> I built v4l-utils version 1.18.0 on Linux Mint 18.3
> 
> the compilation process appeared to run through OK with only 9 warnings (see 
> below), but the resulting executables fail due to a lib ref issue.
> configure: WARNING: doxygen not found - will not generate any doxygen 
> documentation
> configure: WARNING: libelf library not available
> configure: WARNING: Qt5 or higher is not available
> configure: WARNING: ALSA library not available
>   CC   control/libv4lconvert_la-libv4lcontrol.lo
> control/libv4lcontrol.c: In function ‘v4lcontrol_create’:
> control/libv4lcontrol.c:728:3: warning: ignoring return value of ‘ftruncate’, 
> declared with attribute warn_unused_result [-Wunused-result]
>ftruncate(shm_fd, V4LCONTROL_SHM_SIZE);
>^
> libtool: warning: relinking 'libv4l2.la'
> libtool: warning: relinking 'v4l2convert.la'
> libtool: warning: relinking 'libv4l1.la'
> libtool: warning: relinking 'v4l1compat.la'
> 
> Most of these look insignificant but the fifth one looks a bit worrying.

Shouldn't have any real consequence. it is just because there's nothing
like:

ret = ftruncate(...)
if (ret) {
/* some error handling logic */
}

> 
> End result :-
> 
> stupiduser@somehost ~ $ gcc --version
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 2016060
> 
> stupiduser@somehost ~ $ dvbv5-scan -V
> dvbv5-scan version 1.18.0
> 
> stupiduser@somehost ~ $ dvbv5-scan /usr/share/dvb/dvb-s/Astra-28.2E
> dvbv5-scan: symbol lookup error: dvbv5-scan: undefined symbol: dvb_dev_alloc
> 
> stupiduser@somehost ~ $ dvb-fe-tool -m -a0 
> dvb-fe-tool: symbol lookup error: dvb-fe-tool: undefined symbol: dvb_dev_alloc

Probably you have an older version of DVB libraries installed on
your machine. It is trying to use the older library when you try
to run it.

There are some ways of solving it:

1) Make configure to override the old library with:

./configure --prefix=/usr

(the default is to install it at /usr/local)

2) Ensure that the dynamic linker will use the libraries from
/usr/local

Depending on how your distro is set, you could need to add a
new file at /etc/ld.so.conf.d/, in order to teach the dynamic
linker to use the /usr/local/lib directory to seek for libraries.

For example, create a "/etc/ld.so.conf.d/local.conf" file, and make the
system use it by running, as root:

# echo "/usr/local/lib" > /etc/ld.so.conf.d/local.conf
# ldconfig 

PS.: You may need to remove a previous install of the V4L and DVB
libs, in order to avoid any conflicts.

3) use the environment var LD_LIBRARY_PATH in order to add 
/usr/local/lib to the list of directories it will seek for a 
library.

Thanks,
Mauro

[PATCH v2] media: venus: fix build on 32bit environments

[Mauro Carvalho Chehab]

As reported by jenk...@linuxtv.org, the build with i386 fails
with:

ld: drivers/media/platform/qcom/venus/helpers.o: in function 
`venus_helper_load_scale_clocks':
(.text+0x1d77): undefined reference to `__udivdi3'
ld: (.text+0x1dce): undefined reference to `__udivdi3'
make: *** [Makefile:1094: vmlinux] Error 1

That's because it divides an u32 bit integer by a u64 one.

Fix it by explicitly callind do_div.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/qcom/venus/helpers.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5ea5d90f8e5f..a172f1ac0b35 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -520,10 +520,11 @@ static unsigned long calculate_inst_freq(struct 
venus_inst *inst,
 unsigned long filled_len)
 {
unsigned long vpp_freq = 0, vsp_freq = 0;
-   u64 fps = inst->fps;
+   u32 fps = (u32)inst->fps;
u32 mbs_per_sec;
 
-   mbs_per_sec = load_per_instance(inst) / inst->fps;
+   mbs_per_sec = load_per_instance(inst) / fps;
+
vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
/* 21 / 20 is overhead factor */
vpp_freq += vpp_freq / 20;
-- 
2.21.0

Re: [PATCH] media: venus: fix build on 32bit environments

[Mauro Carvalho Chehab]

Em Mon, 7 Oct 2019 11:55:51 -0300
Mauro Carvalho Chehab  escreveu:

> Em Mon, 7 Oct 2019 17:38:53 +0300
> Stanimir Varbanov  escreveu:
> 
> > Hi Mauro,
> > 
> > Thanks for the fix!
> > 
> > On 10/7/19 4:37 PM, Mauro Carvalho Chehab wrote:  
> > > As reported by jenk...@linuxtv.org, the build with i386 fails
> > > with:
> > > 
> > >   ld: drivers/media/platform/qcom/venus/helpers.o: in function 
> > > `venus_helper_load_scale_clocks':
> > >   (.text+0x1d77): undefined reference to `__udivdi3'
> > >   ld: (.text+0x1dce): undefined reference to `__udivdi3'
> > >   make: *** [Makefile:1094: vmlinux] Error 1
> > > 
> > > That's because it divides an u32 bit integer by a u64 one.
> > 
> > General question, shouldn't such errors been catch from builder on the
> > pull request?  
> 
> No, the pull request builder just builds drivers/media automatically
> when a patch arrives patchwork.
> 
> This error only happens after a full build, when it tries to linkedit
> vmlinux.
> 
> Due to time contraints, the complete build is done only after merging 
> stuff at patchwork, as it may take hours to build for the platforms we
> care.
> 
> My long term would be to push patches on a temporary tree, with would
> start the builders. Only after all builders finish without issues, the
> master one would be updated.
> 
> In thesis, jenkins supports it via pipelines. Basically, I would need to
> setup a pipeline that:
> 
> 1) it would fetch the latest tree on a common repository;
> 
> 2) for each arch/config we support, it will start a builder;
> 
> 3) after all builder process finishes, it will check if all builds
>went smoothly;
> 
> 4) if everything runs smoothly, do a git fetch to the "permanent"
> tree.
> 
> I quickly looked at Jenkins docs a few times: setting it doesn't
> seem to be trivial, as it envolves learning a macro language that 
> Jenkins uses internally. 
> 
> I failed to find a good documentation about the language it uses, and
> was unable to find any example of a similar setup. All examples I
> saw assumes that the tasks at the pipeline will use the same workspace.
> 
> I intend to seek for some time to better understand the pipeline
> settings on Jenkins in the future.

Ok, I'm investing some time on trying to set a single pipeline that will
handle all Kernel builds at once. It should take some time for it
to run, but hopefully I may be able to replace it by the individual
build jobs and, on some future, use it to automate the push to my
master branch in order to happen only after passing the tests.

The pipeline is at:

https://builder.linuxtv.org/job/media_kernel_pipeline/

Just the fetching time usually takes ~30 mins or so. So, it should
take a while to be sure that what I wrote would do the right thing.

Thanks,
Mauro

Re: [PATCH] media: venus: fix build on 32bit environments

[Mauro Carvalho Chehab]

Em Mon, 7 Oct 2019 17:38:53 +0300
Stanimir Varbanov  escreveu:

> Hi Mauro,
> 
> Thanks for the fix!
> 
> On 10/7/19 4:37 PM, Mauro Carvalho Chehab wrote:
> > As reported by jenk...@linuxtv.org, the build with i386 fails
> > with:
> > 
> > ld: drivers/media/platform/qcom/venus/helpers.o: in function 
> > `venus_helper_load_scale_clocks':
> > (.text+0x1d77): undefined reference to `__udivdi3'
> > ld: (.text+0x1dce): undefined reference to `__udivdi3'
> > make: *** [Makefile:1094: vmlinux] Error 1
> > 
> > That's because it divides an u32 bit integer by a u64 one.  
> 
> General question, shouldn't such errors been catch from builder on the
> pull request?

No, the pull request builder just builds drivers/media automatically
when a patch arrives patchwork.

This error only happens after a full build, when it tries to linkedit
vmlinux.

Due to time contraints, the complete build is done only after merging 
stuff at patchwork, as it may take hours to build for the platforms we
care.

My long term would be to push patches on a temporary tree, with would
start the builders. Only after all builders finish without issues, the
master one would be updated.

In thesis, jenkins supports it via pipelines. Basically, I would need to
setup a pipeline that:

1) it would fetch the latest tree on a common repository;

2) for each arch/config we support, it will start a builder;

3) after all builder process finishes, it will check if all builds
   went smoothly;

4) if everything runs smoothly, do a git fetch to the "permanent"
tree.

I quickly looked at Jenkins docs a few times: setting it doesn't
seem to be trivial, as it envolves learning a macro language that 
Jenkins uses internally. 

I failed to find a good documentation about the language it uses, and
was unable to find any example of a similar setup. All examples I
saw assumes that the tasks at the pipeline will use the same workspace.

I intend to seek for some time to better understand the pipeline
settings on Jenkins in the future.

> > Fix it by explicitly callind do_div.
> > 
> > That's said, why fps is a 64 bits integer?  
> 
> I don't have other explanation than - just to avoid casting after the
> math in vdec/venc_s_parm() functions.

IMO, avoiding the do_div() would be better than avoid the casting, but
that's your call.

> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/platform/qcom/venus/helpers.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/qcom/venus/helpers.c 
> > b/drivers/media/platform/qcom/venus/helpers.c
> > index 5ea5d90f8e5f..09fa87e3c0a0 100644
> > --- a/drivers/media/platform/qcom/venus/helpers.c
> > +++ b/drivers/media/platform/qcom/venus/helpers.c
> > @@ -522,8 +522,14 @@ static unsigned long calculate_inst_freq(struct 
> > venus_inst *inst,
> > unsigned long vpp_freq = 0, vsp_freq = 0;
> > u64 fps = inst->fps;
> > u32 mbs_per_sec;
> > +   u64 tmp;
> > +  
> 
> you have extra blank line here.

Ok, I'll remove it.

> 
> > +
> > +   tmp = load_per_instance(inst);
> > +   do_div(tmp, inst->fps);
> > +
> > +   mbs_per_sec = (u32)tmp;
> >  
> > -   mbs_per_sec = load_per_instance(inst) / inst->fps;
> > vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
> > /* 21 / 20 is overhead factor */
> > vpp_freq += vpp_freq / 20;
> >   
> 
> I guess this fix should be squashed with the commit which introduce it :(

Too late for that.

> Note taken, always build patches on i386 :/
> 



Thanks,
Mauro

[PATCH] media: venus: fix build on 32bit environments

[Mauro Carvalho Chehab]

As reported by jenk...@linuxtv.org, the build with i386 fails
with:

ld: drivers/media/platform/qcom/venus/helpers.o: in function 
`venus_helper_load_scale_clocks':
(.text+0x1d77): undefined reference to `__udivdi3'
ld: (.text+0x1dce): undefined reference to `__udivdi3'
make: *** [Makefile:1094: vmlinux] Error 1

That's because it divides an u32 bit integer by a u64 one.

Fix it by explicitly callind do_div.

That's said, why fps is a 64 bits integer?

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/qcom/venus/helpers.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5ea5d90f8e5f..09fa87e3c0a0 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -522,8 +522,14 @@ static unsigned long calculate_inst_freq(struct venus_inst 
*inst,
unsigned long vpp_freq = 0, vsp_freq = 0;
u64 fps = inst->fps;
u32 mbs_per_sec;
+   u64 tmp;
+
+
+   tmp = load_per_instance(inst);
+   do_div(tmp, inst->fps);
+
+   mbs_per_sec = (u32)tmp;
 
-   mbs_per_sec = load_per_instance(inst) / inst->fps;
vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
/* 21 / 20 is overhead factor */
vpp_freq += vpp_freq / 20;
-- 
2.21.0

[PATCH] media: cxd2841er: avoid too many status inquires

[Mauro Carvalho Chehab]

I2C ops are expensive, as the I2C bus typical speed is 100kbps.

Also, stats reading take some time, as it requires to retrieve a
certain number of packets to complete.

While we don't know the minimal for CXD2841er, trying to do it
too quickly is still a very bad idea.

So, add some sanity logic there, preventing to retrieve stats
faster than one second.

This shouldn't cause any issues with well behavior apps, as they
usually take stats on a polling rate slower than 1 second.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 1b30cf570803..758c95bc3b11 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -60,6 +60,7 @@ struct cxd2841er_priv {
enum cxd2841er_xtal xtal;
enum fe_caps caps;
u32 flags;
+   unsigned long   stats_time;
 };
 
 static const struct cxd2841er_cnr_data s_cn_data[] = {
@@ -3279,9 +3280,15 @@ static int cxd2841er_get_frontend(struct dvb_frontend 
*fe,
p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
 
if (status & FE_HAS_LOCK) {
+   if (priv->stats_time &&
+   (!time_after(jiffies, priv->stats_time)))
+   return 0;
+
+   /* Prevent retrieving stats faster than once per second */
+   priv->stats_time = jiffies + msecs_to_jiffies(1000);
+
cxd2841er_read_snr(fe);
cxd2841er_read_ucblocks(fe);
-
cxd2841er_read_ber(fe);
} else {
p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
@@ -3360,6 +3367,9 @@ static int cxd2841er_set_frontend_s(struct dvb_frontend 
*fe)
p->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
p->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
 
+   /* Reset the wait for jiffies logic */
+   priv->stats_time = 0;
+
return ret;
 }
 
-- 
2.21.0

Re: [PATCH v3] media: cxd2841er: avoid too many status inquires

[Mauro Carvalho Chehab]

Em Sat, 5 Oct 2019 10:02:05 +0200
Daniel Scheller  escreveu:

> Am Fri,  4 Oct 2019 11:02:28 -0300
> schrieb Mauro Carvalho Chehab :
> 
> > As reported at:
> > https://tvheadend.org/issues/5625
> > 
> > Retrieving certain status can cause discontinuity issues.
> > 
> > Prevent that by adding a timeout to each status logic.
> > 
> > Currently, the timeout is estimated based at the channel
> > bandwidth. There are other parameters that may also affect
> > the timeout, but that would require a per-delivery system
> > calculus and probably more information about how cxd2481er
> > works, with we don't have.
> > 
> > So, do a poor man's best guess.  
> 
> Such hardware quirk hack should clearly be enabled by a (new) config
> flag (see the bits at the top of cxd2841er.h) which consumer drivers
> can set if there are known issues with them. The reported issue is
> nothing every piece of hardware with a cxd28xx demod soldered on has -
> I believe the JokerTV devices which Abylay originally made this driver
> for suffers from this and at least the Digital Devices C/C2/T/T2/I
> boards (cxd2837/43/54) definitely don't have any issues (and I use them
> regularily in my TVheadend server which is frequently used).
> 
> So please hide this behind a flag named ie. "CXD2841ER_STAT_TIMEOUT"
> and enable that in the USB drivers which the affected USB sticks use.

I see your point.

There are a few things to consider here, though:

1) I2C bus calls are expensive, as the bus speed is typically 100kbps.
   Doing such ops too fast is known to have caused issues in the past
   with other frontends.

   So, a good practice, followed by almost all frontends, is to have 
   some logic that would prevent calling stats too fast;

2) Obtaining stats like BER, UCB, block error count and even S/N ratio takes
   time, as the frontend need to wait for enough data to arrive, in order to
   update the internal registers. At best, calling stats too fast will
   just make the frontend return a previously cached value, just spending
   I2C bus bandwidth for nothing.

3) If you look at the cxd2880 driver, wrote by Sony developers, you'll
   see that it has a complex logic to estimate the time where the
   next stats value is available. I bet that the timings calculated there
   would be similar to the minimal time to obtain a reliable measure also
   on cxd2841er.

4) The cxd2841er can't do any real estimation right now, as it tunes
   into a channel using auto mode and it misses the code that would
   retrieve the tuning parameters and would allow to properly estimate
   the bit rate of the received stream.

5) With regards to the tvheadend issue, I've been talking with the
   reporter at the IRC channel, sending him some patches to test.
   After some tests, I'm pretty sure that the issue is not Kernel
   related, but, instead, there's something broken at tvheadend
   (at least at the version he is using) that it is causing troubles
   when using the DVBv5 stats API.

With all the above considerations, I agree with you that this patch
should not be applied. Yet, we should at least apply a patch that would
prevent retrieving the stats registers too fast.

I'm sending a new version in a few.

Thanks,
Mauro

[PATCH v3] media: cxd2841er: avoid too many status inquires

[Mauro Carvalho Chehab]

As reported at:
https://tvheadend.org/issues/5625

Retrieving certain status can cause discontinuity issues.

Prevent that by adding a timeout to each status logic.

Currently, the timeout is estimated based at the channel
bandwidth. There are other parameters that may also affect
the timeout, but that would require a per-delivery system
calculus and probably more information about how cxd2481er
works, with we don't have.

So, do a poor man's best guess.

Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 1b30cf570803..218da631df19 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -60,6 +60,13 @@ struct cxd2841er_priv {
enum cxd2841er_xtal xtal;
enum fe_caps caps;
u32 flags;
+
+   unsigned long   ber_interval;
+   unsigned long   ucb_interval;
+
+   unsigned long   ber_time;
+   unsigned long   ucb_time;
+   unsigned long   snr_time;
 };
 
 static const struct cxd2841er_cnr_data s_cn_data[] = {
@@ -1941,6 +1948,10 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
struct cxd2841er_priv *priv = fe->demodulator_priv;
u32 ret, bit_error = 0, bit_count = 0;
 
+   if (priv->ber_time &&
+  (!time_after(jiffies, priv->ber_time)))
+   return;
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
@@ -1953,9 +1964,15 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
break;
case SYS_DVBS:
ret = cxd2841er_mon_read_ber_s(priv, &bit_error, &bit_count);
+
+   if (!priv->ber_interval && p->symbol_rate)
+   priv->ber_interval = (1000) / (p->symbol_rate / 
1000);
break;
case SYS_DVBS2:
ret = cxd2841er_mon_read_ber_s2(priv, &bit_error, &bit_count);
+
+   if (!priv->ber_interval && p->symbol_rate)
+   priv->ber_interval = (1000) / (p->symbol_rate / 
1000);
break;
case SYS_DVBT:
ret = cxd2841er_read_ber_t(priv, &bit_error, &bit_count);
@@ -1978,6 +1995,21 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
p->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
p->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
}
+
+   /*
+* If the per-delivery system doesn't specify, set a default timeout
+* that will wait for ~12.5 seconds for 8MHz channels
+*/
+   if (!priv->ber_interval && p->bandwidth_hz)
+   priv->ber_interval = (1) / (p->bandwidth_hz / 1000);
+
+   if (priv->ber_interval < 1000)
+   priv->ber_interval = 1000;
+
+// HACK:
+dev_info(&priv->i2c->dev, "BER interval: %d ms", priv->ber_interval);
+
+   priv->ber_time = jiffies + msecs_to_jiffies(priv->ber_interval);
 }
 
 static void cxd2841er_read_signal_strength(struct dvb_frontend *fe)
@@ -2037,6 +2069,16 @@ static void cxd2841er_read_snr(struct dvb_frontend *fe)
struct dtv_frontend_properties *p = &fe->dtv_property_cache;
struct cxd2841er_priv *priv = fe->demodulator_priv;
 
+   if (priv->snr_time &&
+  (!time_after(jiffies, priv->snr_time)))
+   return;
+
+   /* Preventing asking SNR more than once per second */
+   priv->snr_time = jiffies + msecs_to_jiffies(1000);
+
+// HACK
+dev_info(&priv->i2c->dev, "SNR interval: %d ms", 1000);
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
@@ -2081,6 +2123,10 @@ static void cxd2841er_read_ucblocks(struct dvb_frontend 
*fe)
struct cxd2841er_priv *priv = fe->demodulator_priv;
u32 ucblocks = 0;
 
+   if (priv->ucb_time &&
+  (!time_after(jiffies, priv->ucb_time)))
+   return;
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
@@ -2105,6 +2151,21 @@ static void cxd2841er_read_ucblocks(struct dvb_frontend 
*fe)
 
p->block_error.stat[0].scale = FE_SCALE_COUNTER;
p->block_error.stat[0].uvalue = ucblocks;
+
+   /*
+* If the per-delivery system doesn't specify, set a default timeout
+ 

Re: [PATCH] si2157: Add support for Logilink VG0022A.

[Mauro Carvalho Chehab]

Em Fri, 4 Oct 2019 13:50:43 +0200
JP  escreveu:

> On 10/3/19 10:03 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 3 Oct 2019 21:51:35 +0200
> > Gonsolo  escreveu:
> >  
> >>> 1) The firmware file is likely at the Windows driver for this device
> >>> (probably using a different format). It should be possible to get
> >>> it from there.  
> >> If you tell me how I'm willing to do this. :)  
> > I don't know. I was not the one that extracted the firmware. I guess
> > Antti did it.
> >
> > I suspect that there are some comments about that in the past at the
> > ML. seek at lore.kernel.org.
> >  
> >>> 2) Another possibility would be to add a way to tell the si2168 driver
> >>> to not try to load a firmware, using the original one. That would
> >>> require adding a field at si2168_config to allow signalizing to it
> >>> that it should not try to load a firmware file, and add a quirk at
> >>> the af9035 that would set such flag for Logilink VG0022A.  
> >> I don't get this. Which firmware, si2168 or si2157?  
> > The one that it is causing the problem. If I understood well, the
> > culprit was the si2168 firmware.
> >  
> >> I'm still for option 3: If there is a bogus chip revision number it's
> >> likely the VG0022A and we can safely set fw to NULL, in which case
> >> everything works.
> >> All already working devices will continue to work as before.
> >> With a low probability there are other devices that will return 0x
> >> but a) they didn't work until now and b) they receive a clear message
> >> that they return bogus numbers and this works just for the VG0022A, in
> >> which case this hardware can be tested.
> >> At last, *my* VG0022A will work without a custom kernel which I'm a
> >> big fan of. :))
> >>
> >> Are there any counterarguments except that it is not the cleanest
> >> solution in the universe? ;)  
> > That's a really bad solution. Returning 0xff is what happens when
> > things go wrong during I2C transfers. Several problems can cause it,
> > including device misfunction. Every time someone comes with a patch
> > trying to ignore it, things go sideways for other devices (existing
> > or future ones).
> >
> > Ignoring errors is always a bad idea.  
> add module param say 'gonso_hack_vg0022a'
> if true, act on error by setting a flag
> if this flag is set don't load firmware

Adding a module param should be the last resort, only when there's
no way for the driver to autodetect.

Making af9035 to detect vg0022a is quite simple.

Considering this device's entry:

{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x0100,
&it930x_props, "Logilink VG0022A", NULL) },

the check, at af9035 would be:

if (le16_to_cpu(d->udev->descriptor.idVendor) == USB_VID_DEXATEK &&
le16_to_cpu(d->udev->descriptor.idProduct) == 0x0100)
/* do something to disable firmware load */

So, no need to add any load time parameter.

It should be noticed that a change just at af9035 won't work, as the
firmware is updated by si2168 driver. So, the caller code needs to
pass a config parameter to si2168 driver.

Thanks,
Mauro

Re: [PATCH v4] venus: venc: Fix enum frameintervals

[Mauro Carvalho Chehab]

Em Thu,  3 Oct 2019 13:10:38 +0300
Stanimir Varbanov  escreveu:

> This fixes an issue when setting the encoder framerate because of
> missing precision. Now the frameinterval type is changed to
> TYPE_CONTINUOUS and step = 1. Also the math is changed when
> framerate property is called - the firmware side expects the
> framerate in Q16 values.
> 
> Signed-off-by: Stanimir Varbanov 

Didn't test the patch, but just reviewing the code, this version
looks OK on my eyes.

> ---
> 
> Changes since v3:
> Keep min/max numerator one, and divide frate(max/min) to frame
> factor (returned framerate max/min capabilities are in range
> 1 to 120fps but in Q16 i.e. 65536 to 7864320).
> 
>  drivers/media/platform/qcom/venus/venc.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/venc.c 
> b/drivers/media/platform/qcom/venus/venc.c
> index 1b7fb2d5887c..133ff7eceb83 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -22,6 +22,7 @@
>  #include "venc.h"
>  
>  #define NUM_B_FRAMES_MAX 4
> +#define FRAMERATE_FACTOR BIT(16)
>  
>  /*
>   * Three resons to keep MPLANE formats (despite that the number of planes
> @@ -576,7 +577,7 @@ static int venc_enum_frameintervals(struct file *file, 
> void *fh,
>   struct venus_inst *inst = to_inst(file);
>   const struct venus_format *fmt;
>  
> - fival->type = V4L2_FRMIVAL_TYPE_STEPWISE;
> + fival->type = V4L2_FRMIVAL_TYPE_CONTINUOUS;
>  
>   fmt = find_format(inst, fival->pixel_format,
> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
> @@ -600,11 +601,11 @@ static int venc_enum_frameintervals(struct file *file, 
> void *fh,
>   return -EINVAL;
>  
>   fival->stepwise.min.numerator = 1;
> - fival->stepwise.min.denominator = frate_max(inst);
> + fival->stepwise.min.denominator = frate_max(inst) / FRAMERATE_FACTOR;
>   fival->stepwise.max.numerator = 1;
> - fival->stepwise.max.denominator = frate_min(inst);
> + fival->stepwise.max.denominator = frate_min(inst) / FRAMERATE_FACTOR;
>   fival->stepwise.step.numerator = 1;
> - fival->stepwise.step.denominator = frate_max(inst);
> + fival->stepwise.step.denominator = 1;
>  
>   return 0;
>  }
> @@ -649,6 +650,7 @@ static int venc_set_properties(struct venus_inst *inst)
>   struct hfi_quantization quant;
>   struct hfi_quantization_range quant_range;
>   u32 ptype, rate_control, bitrate, profile = 0, level = 0;
> + u64 framerate;
>   int ret;
>  
>   ret = venus_helper_set_work_mode(inst, VIDC_WORK_MODE_2);
> @@ -659,9 +661,14 @@ static int venc_set_properties(struct venus_inst *inst)
>   if (ret)
>   return ret;
>  
> + framerate = inst->timeperframe.denominator * FRAMERATE_FACTOR;
> + /* next line is to round up */
> + framerate += inst->timeperframe.numerator - 1;
> + do_div(framerate, inst->timeperframe.numerator);
> +
>   ptype = HFI_PROPERTY_CONFIG_FRAME_RATE;
>   frate.buffer_type = HFI_BUFFER_OUTPUT;
> - frate.framerate = inst->fps * (1 << 16);
> + frate.framerate = framerate;
>  
>   ret = hfi_session_set_property(inst, ptype, &frate);
>   if (ret)



Thanks,
Mauro

[PATCH] media: mb86a20s: make the bit rate estimation function more generic

[Mauro Carvalho Chehab]

While 99% of the implementation of the bitrate estimation
routine for ISDB-T is generic, the current approach mangles it
with some mb86a20s-specific thing.

Split the calculus from the specific stuff, in order to make
easier to use the same approach on other drivers requiring
a similar formula.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/mb86a20s.c | 54 +++---
 1 file changed, 23 insertions(+), 31 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c 
b/drivers/media/dvb-frontends/mb86a20s.c
index 4e50441c247a..a7faf0cf8788 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -517,7 +517,7 @@ static void mb86a20s_reset_frontend_cache(struct 
dvb_frontend *fe)
  * Estimates the bit rate using the per-segment bit rate given by
  * ABNT/NBR 15601 spec (table 4).
  */
-static u32 isdbt_rate[3][5][4] = {
+static const u32 isdbt_rate[3][5][4] = {
{   /* DQPSK/QPSK */
{  280850,  312060,  330420,  340430 }, /* 1/2 */
{  374470,  416080,  440560,  453910 }, /* 2/3 */
@@ -539,13 +539,9 @@ static u32 isdbt_rate[3][5][4] = {
}
 };
 
-static void mb86a20s_layer_bitrate(struct dvb_frontend *fe, u32 layer,
-  u32 modulation, u32 forward_error_correction,
-  u32 guard_interval,
-  u32 segment)
+static u32 isdbt_layer_min_bitrate(struct dtv_frontend_properties *c,
+  u32 layer)
 {
-   struct mb86a20s_state *state = fe->demodulator_priv;
-   u32 rate;
int mod, fec, guard;
 
/*
@@ -553,7 +549,7 @@ static void mb86a20s_layer_bitrate(struct dvb_frontend *fe, 
u32 layer,
 * to consider the lowest bit rate, to avoid taking too long time
 * to get BER.
 */
-   switch (modulation) {
+   switch (c->layer[layer].modulation) {
case DQPSK:
case QPSK:
default:
@@ -567,7 +563,7 @@ static void mb86a20s_layer_bitrate(struct dvb_frontend *fe, 
u32 layer,
break;
}
 
-   switch (forward_error_correction) {
+   switch (c->layer[layer].fec) {
default:
case FEC_1_2:
case FEC_AUTO:
@@ -587,7 +583,7 @@ static void mb86a20s_layer_bitrate(struct dvb_frontend *fe, 
u32 layer,
break;
}
 
-   switch (guard_interval) {
+   switch (c->guard_interval) {
default:
case GUARD_INTERVAL_1_4:
guard = 0;
@@ -603,29 +599,14 @@ static void mb86a20s_layer_bitrate(struct dvb_frontend 
*fe, u32 layer,
break;
}
 
-   /* Samples BER at BER_SAMPLING_RATE seconds */
-   rate = isdbt_rate[mod][fec][guard] * segment * BER_SAMPLING_RATE;
-
-   /* Avoids sampling too quickly or to overflow the register */
-   if (rate < 256)
-   rate = 256;
-   else if (rate > (1 << 24) - 1)
-   rate = (1 << 24) - 1;
-
-   dev_dbg(&state->i2c->dev,
-   "%s: layer %c bitrate: %d kbps; counter = %d (0x%06x)\n",
-   __func__, 'A' + layer,
-   segment * isdbt_rate[mod][fec][guard]/1000,
-   rate, rate);
-
-   state->estimated_rate[layer] = rate;
+   return isdbt_rate[mod][fec][guard] * c->layer[layer].segment_count;
 }
 
 static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 {
struct mb86a20s_state *state = fe->demodulator_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
-   int layer, rc;
+   int layer, rc, rate, counter;
 
dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
 
@@ -676,10 +657,21 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
dev_dbg(&state->i2c->dev, "%s: interleaving %d.\n",
__func__, rc);
c->layer[layer].interleaving = rc;
-   mb86a20s_layer_bitrate(fe, layer, c->layer[layer].modulation,
-  c->layer[layer].fec,
-  c->guard_interval,
-  c->layer[layer].segment_count);
+
+   rate = isdbt_layer_min_bitrate(c, layer);
+   counter = rate * BER_SAMPLING_RATE;
+
+   /* Avoids sampling too quickly or to overflow the register */
+   if (counter < 256)
+   counter = 256;
+   else if (counter > (1 << 24) - 1)
+   counter = (1 << 24) - 1;
+
+   dev_dbg(&state->i2c->dev,
+   "%s: layer %c bitrate: %d kbps; counter = %d 
(0x%06x)\n",
+   __func__, 'A' + layer, rate / 1000, counter, counter);
+
+   state->estimated_rate[layer] = counter;
}
 
rc = mb86a20s_writereg(state, 0x6d, 0x84);
-- 
2.21.0

[PATCH] media: cxd2841er: avoid too many status inquires

[Mauro Carvalho Chehab]

As reported at:
https://tvheadend.org/issues/5625

Retrieving certain status can cause discontinuity issues.

Prevent that by adding a timeout to each status logic.

Currently, the timeout is estimated based at the channel
bandwidth. There are other parameters that may also affect
the timeout, but that would require a per-delivery system
calculus and probably more information about how cxd2481er
works, with we don't have.

So, do a poor man's best guess.

Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 59 +
 1 file changed, 59 insertions(+)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 1b30cf570803..71428b0d2620 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -60,6 +60,13 @@ struct cxd2841er_priv {
enum cxd2841er_xtal xtal;
enum fe_caps caps;
u32 flags;
+
+   unsigned long   ber_interval;
+   unsigned long   ucb_interval;
+
+   unsigned long   ber_time;
+   unsigned long   ucb_time;
+   unsigned long   snr_time;
 };
 
 static const struct cxd2841er_cnr_data s_cn_data[] = {
@@ -1941,12 +1948,20 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
struct cxd2841er_priv *priv = fe->demodulator_priv;
u32 ret, bit_error = 0, bit_count = 0;
 
+   if (priv->ber_time &&
+  (!time_after(jiffies, priv->ber_time)))
+   return;
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
case SYS_DVBC_ANNEX_B:
case SYS_DVBC_ANNEX_C:
ret = cxd2841er_read_ber_c(priv, &bit_error, &bit_count);
+
+   if (!priv->ber_interval && p->symbol_rate)
+   priv->ber_interval = (1000) / (p->symbol_rate / 
1000);
+
break;
case SYS_ISDBT:
ret = cxd2841er_read_ber_i(priv, &bit_error, &bit_count);
@@ -1978,6 +1993,18 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
p->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
p->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
}
+
+   /*
+* If the per-delivery system doesn't specify, set a default timeout
+* that will wait for ~12.5 seconds for 8MHz channels
+*/
+   if (!priv->ber_interval && p->bandwidth_hz)
+   priv->ber_interval = (1) / (p->bandwidth_hz / 1000);
+
+   if (priv->ber_interval < 1000)
+   priv->ber_interval = 1000;
+
+   priv->ber_time = jiffies + msecs_to_jiffies(priv->ber_interval);
 }
 
 static void cxd2841er_read_signal_strength(struct dvb_frontend *fe)
@@ -2037,6 +2064,13 @@ static void cxd2841er_read_snr(struct dvb_frontend *fe)
struct dtv_frontend_properties *p = &fe->dtv_property_cache;
struct cxd2841er_priv *priv = fe->demodulator_priv;
 
+   if (priv->snr_time &&
+  (!time_after(jiffies, priv->snr_time)))
+   return;
+
+   /* Preventing asking SNR more than once per second */
+   priv->snr_time = jiffies + msecs_to_jiffies(1000);
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
@@ -2081,12 +2115,18 @@ static void cxd2841er_read_ucblocks(struct dvb_frontend 
*fe)
struct cxd2841er_priv *priv = fe->demodulator_priv;
u32 ucblocks = 0;
 
+   if (priv->ucb_time &&
+  (!time_after(jiffies, priv->ucb_time)))
+   return;
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
case SYS_DVBC_ANNEX_B:
case SYS_DVBC_ANNEX_C:
cxd2841er_read_packet_errors_c(priv, &ucblocks);
+   if (!priv->ucb_interval && p->symbol_rate)
+   priv->ucb_interval = (100 * 204 * 1000 * 8) / 
p->symbol_rate;
break;
case SYS_DVBT:
cxd2841er_read_packet_errors_t(priv, &ucblocks);
@@ -2105,6 +2145,18 @@ static void cxd2841er_read_ucblocks(struct dvb_frontend 
*fe)
 
p->block_error.stat[0].scale = FE_SCALE_COUNTER;
p->block_error.stat[0].uvalue = ucblocks;
+
+   /*
+* If the per-delivery system doesn't specify, set a default timeout
+* that will wait 20-30 seconds
+*/
+   if (!priv->ucb_interval && p->bandwidth_hz)
+   priv->ucb_interval = (1

[PATCH] media: cxd2841er: avoid too many status inquires

[Mauro Carvalho Chehab]

As reported at:
https://tvheadend.org/issues/5625

Retrieving certain status can cause discontinuity issues.

Prevent that by adding a timeout to each status logic.

Currently, the timeout is estimated based at the channel
bandwidth. There are other parameters that may also affect
the timeout, but that would require a per-delivery system
calculus and probably more information about how cxd2481er
works, with we don't have.

So, do a poor man's best guess.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 54 +
 1 file changed, 54 insertions(+)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 1b30cf570803..c75e63b9cfa7 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -60,6 +60,13 @@ struct cxd2841er_priv {
enum cxd2841er_xtal xtal;
enum fe_caps caps;
u32 flags;
+
+   unsigned long   ber_interval;
+   unsigned long   ucb_interval;
+
+   unsigned long   ber_time;
+   unsigned long   ucb_time;
+   unsigned long   snr_time;
 };
 
 static const struct cxd2841er_cnr_data s_cn_data[] = {
@@ -1941,6 +1948,10 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
struct cxd2841er_priv *priv = fe->demodulator_priv;
u32 ret, bit_error = 0, bit_count = 0;
 
+   if (priv->ber_time &&
+  (!time_after(jiffies, priv->ber_time)))
+   return;
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
@@ -1978,6 +1989,19 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
p->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
p->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
}
+
+   /*
+* If the per-delivery system doesn't specify, set a default timeout
+* that will wait for 10^7 bits or 1 second
+*/
+   if (!priv->ber_interval && p->bandwidth_hz) {
+   priv->ber_interval = (1000) / (p->bandwidth_hz / 1000);
+   }
+
+   if (priv->ber_interval < 1000)
+   priv->ber_interval = 1000;
+
+   priv->ber_time = jiffies + msecs_to_jiffies(priv->ber_interval);
 }
 
 static void cxd2841er_read_signal_strength(struct dvb_frontend *fe)
@@ -2037,6 +2061,13 @@ static void cxd2841er_read_snr(struct dvb_frontend *fe)
struct dtv_frontend_properties *p = &fe->dtv_property_cache;
struct cxd2841er_priv *priv = fe->demodulator_priv;
 
+   if (priv->snr_time &&
+  (!time_after(jiffies, priv->snr_time)))
+   return;
+
+   /* Preventing asking SNR more than once per second */
+   priv->snr_time = jiffies + msecs_to_jiffies(1000);
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
@@ -2081,6 +2112,10 @@ static void cxd2841er_read_ucblocks(struct dvb_frontend 
*fe)
struct cxd2841er_priv *priv = fe->demodulator_priv;
u32 ucblocks = 0;
 
+   if (priv->ucb_time &&
+  (!time_after(jiffies, priv->ucb_time)))
+   return;
+
dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
case SYS_DVBC_ANNEX_A:
@@ -2105,6 +2140,18 @@ static void cxd2841er_read_ucblocks(struct dvb_frontend 
*fe)
 
p->block_error.stat[0].scale = FE_SCALE_COUNTER;
p->block_error.stat[0].uvalue = ucblocks;
+
+   /*
+* If the per-delivery system doesn't specify, set a default timeout
+* that will wait for 100 packets or 1 second
+*/
+   if (!priv->ucb_interval && p->bandwidth_hz)
+   priv->ucb_interval = (100 * 204 * 1000 * 8) / p->bandwidth_hz;
+
+   if (priv->ucb_interval < 1000)
+   priv->ucb_interval = 1000;
+
+   priv->ucb_time = jiffies + msecs_to_jiffies(priv->ucb_interval);
 }
 
 static int cxd2841er_dvbt2_set_profile(
@@ -3360,6 +3407,13 @@ static int cxd2841er_set_frontend_s(struct dvb_frontend 
*fe)
p->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
p->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
 
+   /* Reset the wait for jiffies logic */
+   priv->ber_interval = 0;
+   priv->ucb_interval = 0;
+   priv->ber_time = 0;
+   priv->ucb_time = 0;
+   priv->snr_time = 0;
+
return ret;
 }
 
-- 
2.21.0

Re: venus: venc: Fix enum frameintervals - was: [GIT PULL for v5.5] Venus updates, take 2

[Mauro Carvalho Chehab]

Em Wed,  2 Oct 2019 14:29:53 +0300
Stanimir Varbanov  escreveu:

> Hi Mauro,
> 
> The Venus driver updates include:
> 
> * three fixes: fail to suspend, enum frameinterval issue with encoder
> and frequency table modifications for v3 to handle performance issues.
> * two new features: interconnect bandwidth support on v4 and more precise
> clock-scaling on v4.
> 
> Please pull.
>
> Stanimir Varbanov (3):
>   venus: venc: Fix enum frameintervals

> From c430fca8f2b9b7274a1186f85b69c469378dbd8a Mon Sep 17 00:00:00 2001
> From: Stanimir Varbanov 
> Date: Tue, 22 Jan 2019 12:53:22 +0200
> Subject: venus: venc: Fix enum frameintervals
> To: Linux Media Mailing List 
> Cc: Mauro Carvalho Chehab 
> 
> This fixes an issue when setting the encoder framerate because of
> missing precision. Now the frameinterval type is changed to
> TYPE_CONTINUOUS and step = 1. Also the math is changed when
> framerate property is called - the firmware side expects the
> framerate in Q16 values.
> 
> Signed-off-by: Loic Poulain 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/platform/qcom/venus/venc.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/venc.c 
> b/drivers/media/platform/qcom/venus/venc.c
> index 1b7fb2d5887c..d0a97754ef18 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -22,6 +22,7 @@
>  #include "venc.h"
>  
>  #define NUM_B_FRAMES_MAX 4
> +#define FRAMERATE_FACTOR BIT(16)
>  
>  /*
>   * Three resons to keep MPLANE formats (despite that the number of planes
> @@ -576,7 +577,7 @@ static int venc_enum_frameintervals(struct file *file, 
> void *fh,
>   struct venus_inst *inst = to_inst(file);
>   const struct venus_format *fmt;
>  
> - fival->type = V4L2_FRMIVAL_TYPE_STEPWISE;
> + fival->type = V4L2_FRMIVAL_TYPE_CONTINUOUS;
>  
>   fmt = find_format(inst, fival->pixel_format,
> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
> @@ -599,12 +600,12 @@ static int venc_enum_frameintervals(struct file *file, 
> void *fh,
>   fival->height < frame_height_min(inst))
>   return -EINVAL;
>  
> - fival->stepwise.min.numerator = 1;
> - fival->stepwise.min.denominator = frate_max(inst);
> - fival->stepwise.max.numerator = 1;
> - fival->stepwise.max.denominator = frate_min(inst);
> + fival->stepwise.min.numerator = FRAMERATE_FACTOR;
> + fival->stepwise.min.denominator = frate_max(inst) * FRAMERATE_FACTOR;
> + fival->stepwise.max.numerator = FRAMERATE_FACTOR;
> + fival->stepwise.max.denominator = frate_min(inst) * FRAMERATE_FACTOR;

Hmm... this change seems plain wrong to me... Why do you want to change
the numerator? I mean:

1/frame_min(inst)

is equal to:

(const * 1) / (const * frame_min(inst))

Also, on every other driver, the returned fractions are normalized.

>   fival->stepwise.step.numerator = 1;
> - fival->stepwise.step.denominator = frate_max(inst);
> + fival->stepwise.step.denominator = 1;
>  
>   return 0;
>  }
> @@ -649,6 +650,7 @@ static int venc_set_properties(struct venus_inst *inst)
>   struct hfi_quantization quant;
>   struct hfi_quantization_range quant_range;
>   u32 ptype, rate_control, bitrate, profile = 0, level = 0;
> + u64 framerate;
>   int ret;
>  
>   ret = venus_helper_set_work_mode(inst, VIDC_WORK_MODE_2);
> @@ -659,9 +661,16 @@ static int venc_set_properties(struct venus_inst *inst)
>   if (ret)
>   return ret;
>  
> + framerate = inst->timeperframe.denominator * FRAMERATE_FACTOR;
> + /* next line is to round up */
> + framerate += inst->timeperframe.numerator - 1;
> + do_div(framerate, inst->timeperframe.numerator);
> +
>   ptype = HFI_PROPERTY_CONFIG_FRAME_RATE;
>   frate.buffer_type = HFI_BUFFER_OUTPUT;
> - frate.framerate = inst->fps * (1 << 16);
> + frate.framerate = framerate;
> + if (frate.framerate > frate_max(inst) * FRAMERATE_FACTOR)
> + frate.framerate = frate_max(inst) * FRAMERATE_FACTOR;

You should not assume that userspace will be multiplying by the
frame factor. I mean, the driver should work the same way, no matter
if userspace is setting the framerate as:

1/30, 2/60, ... n/(n *30)


>  
>   ret = hfi_session_set_property(inst, ptype, &frate);
>   if (ret)
> -- 
> 2.21.0
> 




Thanks,
Mauro

Re: [GIT PULL for v5.5] Venus updates, take 2

[Mauro Carvalho Chehab]

Em Wed,  2 Oct 2019 14:29:53 +0300
Stanimir Varbanov  escreveu:

> Hi Mauro,
> 
> The Venus driver updates include:
> 
> * three fixes: fail to suspend, enum frameinterval issue with encoder
> and frequency table modifications for v3 to handle performance issues.
> * two new features: interconnect bandwidth support on v4 and more precise
> clock-scaling on v4.
> 
> Please pull.
> 
> Changes since v1:
> Fixed checkpatch error/warn in 0003-venus-venc-Fix-enum-frameintervals.patch
> 
> regards,
> Stan
> 
> The following changes since commit 503e59365dd134b2c63864f14e2de0476284b003:
> 
>   media: i2c: ov2659: Switch to SPDX Licensing (2019-10-01 17:39:16 -0300)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/svarbanov/media_tree.git tags/venus-for-v5.5
> 
> for you to fetch changes up to e8938a0b5beb6f0fafc921010375cda64a5a4592:
> 
>   venus: Update clock scaling (2019-10-02 14:17:23 +0300)
> 
> 
> Venus updates for v5.5
> 
> 
> Aniket Masule (2):
>   venus: Add codec data table
>   venus: Update clock scaling
> 
> Loic Poulain (1):
>   venus: core: Fix msm8996 frequency table
> 
> Stanimir Varbanov (3):
>   venus: Use on-chip interconnect API
>   venus: venc: Fix enum frameintervals
>   venus: Fix occasionally failures to suspend

Hmm... I'm not seeing the patches at the ML. Please always send them
to the ML, in order for them to be properly reviewed.

Btw, I have some issues related to this patch:

venus: venc: Fix enum frameintervals

Thanks,
Mauro

Re: Build failed in Jenkins: v4l-utils #43

[Mauro Carvalho Chehab]

Em Wed, 2 Oct 2019 11:49:20 +0200
Hans Verkuil  escreveu:

> On 10/2/19 11:36 AM, Mauro Carvalho Chehab wrote:
> > Em Wed, 2 Oct 2019 10:25:02 +0200
> > Hans Verkuil  escreveu:
> >   
> >> Hi Mauro,
> >>
> >> On 10/2/19 10:16 AM, Jenkins Builder Robot wrote:  
> >>> See 
> >>> <https://builder.linuxtv.org/job/v4l-utils/43/display/redirect?page=changes>
> >>>
> >>> Changes:
> >>>
> >>> [hverkuil-cisco] keytable: add new generated keymaps
> >>>
> >>> [hverkuil-cisco] msg2ctl.pl: add newline after log_msg
> >>>
> >>> [hverkuil-cisco] cec-follower: drop the hardcoded UI commands list
> >>>
> >>> [hverkuil-cisco] cec-ctl/cec-log: use new CEC_OP_UI_CMD defines
> >>
> >> You need to remove utils/cec-follower/cec-log.h.
> >>
> >> This file was generated but the generated file is now called cec-log-gen.h.
> >> A new cec-log.h was also added to utils/common as a companion to 
> >> cec-log.cpp.
> >>
> >> Unfortunately, the old cec-log.h clashes with the new cec-log.h. And since
> >> the old cec-log.h was generated and so is not part of the git repo it is
> >> not removed as part of a 'git pull'.
> >>
> >> Anyway, just remove utils/cec-follower/cec-log.h and it compiles again.  
> > 
> > I manually removed the file at the builder and at the slave machines and
> > asked for a new build. The build now succeeded.
> > 
> > That's said, we should really avoid disruptive changes like that, fixing
> > the building system for it to do the right thing, as users of the v4l-utils 
> > will also face the same issue if they update their git trees.
> > 
> > At any time, a clean git update with something similar to:
> > 
> > git remote update
> > git fetch origin
> > git reset --hard origin/master
> > ./bootstrap.sh
> > ./configure
> > make
> > 
> > should work.
> > 
> > Regards,
> > Mauro
> >   
> 
> Yes, I discovered it too late. That said, I'm not sure what to do about
> it since the old generated file is not under the control of git.
> 
> A 'make distclean' before the 'git fetch' would remove it, but after the
> update it is just an orphaned file.
> 
> I've actually added a 'make distclean' in my daily build scripts.

That's a very bad idea. The builds should check and pinpoint to
regressions at the building system too.

If I understand the problem, you're saying that now cec-log.h depends on
the generated cec-log-gen.h, right?

If so, this could be easily fixable by adding an explicit dependency
rule to the Makefile.am, like:

cec-log.h: cec-log-gen.h

Thanks,
Mauro

Re: Build failed in Jenkins: v4l-utils #43

[Mauro Carvalho Chehab]

Em Wed, 2 Oct 2019 10:25:02 +0200
Hans Verkuil  escreveu:

> Hi Mauro,
> 
> On 10/2/19 10:16 AM, Jenkins Builder Robot wrote:
> > See 
> > 
> > 
> > Changes:
> > 
> > [hverkuil-cisco] keytable: add new generated keymaps
> > 
> > [hverkuil-cisco] msg2ctl.pl: add newline after log_msg
> > 
> > [hverkuil-cisco] cec-follower: drop the hardcoded UI commands list
> > 
> > [hverkuil-cisco] cec-ctl/cec-log: use new CEC_OP_UI_CMD defines  
> 
> You need to remove utils/cec-follower/cec-log.h.
> 
> This file was generated but the generated file is now called cec-log-gen.h.
> A new cec-log.h was also added to utils/common as a companion to cec-log.cpp.
> 
> Unfortunately, the old cec-log.h clashes with the new cec-log.h. And since
> the old cec-log.h was generated and so is not part of the git repo it is
> not removed as part of a 'git pull'.
> 
> Anyway, just remove utils/cec-follower/cec-log.h and it compiles again.

I manually removed the file at the builder and at the slave machines and
asked for a new build. The build now succeeded.

That's said, we should really avoid disruptive changes like that, fixing
the building system for it to do the right thing, as users of the v4l-utils 
will also face the same issue if they update their git trees.

At any time, a clean git update with something similar to:

git remote update
git fetch origin
git reset --hard origin/master
./bootstrap.sh
./configure
make

should work.

Regards,
Mauro

Re: [GIT PULL FOR v5.5] am437x-vpfe: overdue maintenance

[Mauro Carvalho Chehab]

Em Fri, 27 Sep 2019 16:27:00 +0200
Hans Verkuil  escreveu:

> Various fixes for am437x-vpfe.
> 
> One special note: the last three patches adds new macros to be able to
> print a V4L2 fourcc in a standard way, both for kernel and userspace,
> and uses them in v4l2-ioctl.c and am437x.
> 
> If you have concerns about this and do not want to merge those patches
> without discussing this some more, then please just drop these last three
> patches.

I looked at the patch with introduced the fourcc. While I like the idea,
IMHO, the implementation should be improved. Instead of adding obscure
subsystem-specific magic strings to be added at printk() lines, it should,
instead, add a new macro to be handled by printk, properly documenting
it at:

Documentation/core-api/printk-formats.rst

There are other subsystems with macros there, like the network subsystem.
So, I suspect that it shouldn't be hard to add something like "%pCC"
with would properly print the fourcc.

So, I'm dropping the last 3 patches on this series applying the
remaining ones.

Regards,
Mauro

> 
> Regards,
> 
>   Hans
> 
> The following changes since commit 6f51fdfd8229d5358c2d6e272cf73478866e8ddc:
> 
>   media: videobuf-core.c: poll_wait needs a non-NULL buf pointer (2019-09-05 
> 06:26:57 -0300)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.5c2
> 
> for you to fetch changes up to 743d13880c0749ca61a40ec4c57ebeb60d06f9c6:
> 
>   media: am437x-vpfe: Remove print_fourcc helper (2019-09-27 16:24:49 +0200)
> 
> 
> Tag branch
> 
> 
> Benoit Parrot (12):
>   media: am437x-vpfe: Fix missing first line
>   media: am437x-vpfe: Rework ISR routine for clarity
>   media: am437x-vpfe: Wait for end of frame before tear-down
>   media: am437x-vpfe: fix start streaming error path
>   media: am437x-vpfe: Streamlined vb2 buffer cleanup
>   media: am437x-vpfe: Setting STD to current value is not an error
>   media: am437x-vpfe: Use a per instance format array instead of a static 
> one
>   media: am437x-vpfe: fix function trace debug log
>   media: am437x-vpfe: TRY_FMT ioctl is not really trying anything
>   media: am437x-vpfe: Remove per bus width static data
>   media: am437x-vpfe: Switch to SPDX Licensing
>   media: am437x-vpfe: Remove print_fourcc helper
> 
> Dave Gerlach (1):
>   media: am437x-vpfe: Fix suspend path to always handle pinctrl config
> 
> Hans Verkuil (1):
>   v4l2-ioctl.c: use new v4l2_fourcc_conv/args macros
> 
> Sakari Ailus (1):
>   v4l: Add macros for printing V4L fourcc values
> 
>  Documentation/media/videodev2.h.rst.exceptions   |   2 +
>  drivers/media/platform/am437x/am437x-vpfe.c  | 880 
> +--
>  drivers/media/platform/am437x/am437x-vpfe.h  |  43 ++-
>  drivers/media/platform/am437x/am437x-vpfe_regs.h |  10 +-
>  drivers/media/v4l2-core/v4l2-ioctl.c |  58 ++--
>  include/uapi/linux/videodev2.h   |  27 ++
>  6 files changed, 453 insertions(+), 567 deletions(-)



Thanks,
Mauro

Re: [PATCH] cx231xx: convert to the vb2 framework

[Mauro Carvalho Chehab]

Em Fri, 27 Sep 2019 15:42:45 +0200
Hans Verkuil  escreveu:

> This patch converts the cx231xx driver to the vb2 framework.
> Since you can't do a partial conversion this is a big-bang patch,
> i.e. large and hard to review. I never found a way around this.
> 
> Signed-off-by: Hans Verkuil 
> Co-Developed-by: Mauro Carvalho Chehab 

Did some tests here with a few devices:

- Hauppauge USB-Live 2
- Capture only

- Hauppauge WinTV-HVR-955Q
- S-video and composite capture
- ATSC capture

Tested-by: Mauro Carvalho Chehab 

> ---
>  drivers/media/usb/cx231xx/Kconfig |   2 +-
>  drivers/media/usb/cx231xx/cx231xx-417.c   | 509 --
>  drivers/media/usb/cx231xx/cx231xx-cards.c |   6 +-
>  drivers/media/usb/cx231xx/cx231xx-vbi.c   | 172 ++---
>  drivers/media/usb/cx231xx/cx231xx-vbi.h   |   2 +-
>  drivers/media/usb/cx231xx/cx231xx-video.c | 795 +-
>  drivers/media/usb/cx231xx/cx231xx.h   |  30 +-
>  7 files changed, 407 insertions(+), 1109 deletions(-)
> 
> diff --git a/drivers/media/usb/cx231xx/Kconfig 
> b/drivers/media/usb/cx231xx/Kconfig
> index 74f3b29d9c60..2fe2b2d335ba 100644
> --- a/drivers/media/usb/cx231xx/Kconfig
> +++ b/drivers/media/usb/cx231xx/Kconfig
> @@ -4,7 +4,7 @@ config VIDEO_CX231XX
>   depends on VIDEO_DEV && I2C && I2C_MUX
>   select VIDEO_TUNER
>   select VIDEO_TVEEPROM
> - select VIDEOBUF_VMALLOC
> + select VIDEOBUF2_VMALLOC
>   select VIDEO_CX25840
>   select VIDEO_CX2341X
>  
> diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
> b/drivers/media/usb/cx231xx/cx231xx-417.c
> index 6d218a036966..46d0215deee6 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-417.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-417.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -60,10 +61,6 @@
>  #define  MCI_MODE_MEMORY_READ   0x000
>  #define  MCI_MODE_MEMORY_WRITE  0x4000
>  
> -static unsigned int mpegbufs = 8;
> -module_param(mpegbufs, int, 0644);
> -MODULE_PARM_DESC(mpegbufs, "number of mpeg buffers, range 2-32");
> -
>  static unsigned int mpeglines = 128;
>  module_param(mpeglines, int, 0644);
>  MODULE_PARM_DESC(mpeglines, "number of lines in an MPEG buffer, range 2-32");
> @@ -1080,16 +1077,6 @@ static int cx231xx_load_firmware(struct cx231xx *dev)
>   return 0;
>  }
>  
> -static void cx231xx_417_check_encoder(struct cx231xx *dev)
> -{
> - u32 status, seq;
> -
> - status = 0;
> - seq = 0;
> - cx231xx_api_cmd(dev, CX2341X_ENC_GET_SEQ_END, 0, 2, &status, &seq);
> - dprintk(1, "%s() status = %d, seq = %d\n", __func__, status, seq);
> -}
> -
>  static void cx231xx_codec_settings(struct cx231xx *dev)
>  {
>   dprintk(1, "%s()\n", __func__);
> @@ -1227,40 +1214,25 @@ static int cx231xx_initialize_codec(struct cx231xx 
> *dev)
>  
>  /* -- */
>  
> -static int bb_buf_setup(struct videobuf_queue *q,
> - unsigned int *count, unsigned int *size)
> +static int queue_setup(struct vb2_queue *vq,
> +unsigned int *nbuffers, unsigned int *nplanes,
> +unsigned int sizes[], struct device *alloc_devs[])
>  {
> - struct cx231xx_fh *fh = q->priv_data;
> + struct cx231xx *dev = vb2_get_drv_priv(vq);
> + unsigned int size = mpeglinesize * mpeglines;
>  
> - fh->dev->ts1.ts_packet_size  = mpeglinesize;
> - fh->dev->ts1.ts_packet_count = mpeglines;
> + dev->ts1.ts_packet_size  = mpeglinesize;
> + dev->ts1.ts_packet_count = mpeglines;
>  
> - *size = fh->dev->ts1.ts_packet_size * fh->dev->ts1.ts_packet_count;
> - *count = mpegbufs;
> -
> - return 0;
> -}
> -
> -static void free_buffer(struct videobuf_queue *vq, struct cx231xx_buffer 
> *buf)
> -{
> - struct cx231xx_fh *fh = vq->priv_data;
> - struct cx231xx *dev = fh->dev;
> - unsigned long flags = 0;
> + if (vq->num_buffers + *nbuffers < CX231XX_MIN_BUF)
> + *nbuffers = CX231XX_MIN_BUF - vq->num_buffers;
>  
> - BUG_ON(in_interrupt());
> + if (*nplanes)
> + return sizes[0] < size ? -EINVAL : 0;
> + *nplanes = 1;
> + sizes[0] = mpeglinesize * mpeglines;
>  
> - spin_lock_irqsave(&dev->video_mode.slock, flags);
> - if (dev->USE_ISO) {
> - if (dev->video_mode.isoc_ctl.buf == buf)
> - dev->video_mode.isoc_ctl.buf = NULL;
> - } else {
> - i

Re: Submit new entries in Digital TV scan tables

[Mauro Carvalho Chehab]

Em Wed, 25 Sep 2019 21:03:46 +0500
Алексей  escreveu:

> Scan tables for DVB-T2 channels in Perm (Russia)

Added, thanks!

Thanks,
Mauro

Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)

[Mauro Carvalho Chehab]

Em Sat, 21 Sep 2019 13:13:07 -0600
Jonathan Corbet  escreveu:

> On Wed, 18 Sep 2019 08:23:26 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > A simple/lazy solution would be to apply the enclosed patch - or a
> > variant of it that would place the contents of MAINTAINERS outside
> > process/index.html, and add instructions about how to use
> > get_maintainers.pl.
> > 
> > Jon,
> > 
> > Please let me know if you're willing to accept something like that.  
> 
> [Sorry for the slowness, I'm kind of tuned out this week]
> 
> I guess we could do that as a short-term thing.
> 
> In truth, though, this thing is a database; printing it out linearly is
> perhaps not the best thing we could do.  There should be better ways we
> could provide access to it.

Yeah, as this is a database, instead of just outputting it on a
formatted way, it is possible to generate other types of output.

We could, for example, have an extension with would implement something like:

.. maintainers:: 

Which would call get-maintainers in order to parse a subsystem-specific
set of entries and printing the maintainership details.

This could be added at the subsystem-specific profile, for the subsystems
that have it.

> 
> Also, that file is nearly 18K lines long.  If some unsuspecting person
> generates a PDF and prints it, they're going to get something along the
> lines of 300 pages of MAINTAINERS, which may not quite be what they had
> in mind.  It costs (almost) nothing to put that into HTML output, but
> other formats could be painful.

Even if we go for adding a Sphinx tag that would produce a parsed
output for a system-specific profile, we'll still have several other
subsystems that won't have a profile for a while, so I would still 
consider having somewhere an output with its contents. Yeah, someone
might be tempted to print it, but we could place it on a separate PDF,
in order to minimize the risks of someone printing the 300+ pages.

> 
> So I dunno, we need to think this through a bit...


> 
> jon



Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation

[Mauro Carvalho Chehab]

Em Thu, 19 Sep 2019 09:56:44 +0300
Dan Carpenter  escreveu:

> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > +Patches for the media subsystem should be sent to the media mailing 
> > > > list
> > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > +to copy the maintainer or sub-maintainer(s).
> > > 
> > > There's too much traffic on mailing lists for me to follow everything, I
> > > much prefer being CC'ed on patches.  
> > 
> > Well, by using patchwork, the best is to take a look on it at least for
> > the patches that you're interested. You could script something using
> > pwclient in order to make it easier.
> > 
> > Anyway, not sure if the other sub-maintainers see the same way. From my 
> > side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> > 
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be 
> > wise 
> > to also copy the sub-maintainer(s).  
> 
> The documentation should say "Use get_maintainer.pl" and do what it
> says.  Everything else is too complicated.

Works for me.

> Occasionally staging maintainers will complain that they aren't CC'd
> even though the staging/driver/README says to CC them and I am tell them
> "No, the responsibility is for you to add yourself to MAINTAINERS.  It
> doesn't matter what the documentation says, you messed up so you need to
> stop getting annoyed with newbies for not reading the documentation when
> it's your fault you weren't CC'd."
> 
> When I sent a patch, I use get_maintainer.pl then I add whoever the
> wrote the commit from the Fixes tag.  Then I remove Colin King and Kees
> Cook from the CC list because they worked all over the tree and I know
> them.  I also normally remove LKML if there is another mailing list but
> at least one subsystem uses LKML for patchwork so this isn't safe.

I use get_maintainer.pl myself, but when submitting some patches
(like documentation ones), I need to manually clean the list, as
it is not uncommon to have a really long c/c list.

> 
> So the safest instructions are "Use get_matainer.pl and add the person
> who wrote the commit in the Fixes tag".
> 
> regards,
> dan carpenter
> 
> 
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation

[Mauro Carvalho Chehab]

Em Wed, 18 Sep 2019 20:27:05 +0300
Laurent Pinchart  escreveu:

> > Anyway, not sure if the other sub-maintainers see the same way. From my 
> > side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> > 
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be 
> > wise 
> > to also copy the sub-maintainer(s).  
> 
> That works for me. As this is really a personal preference, is there a
> way it could be encoded in MAINTAINERS in a per-person fashion ?
> Something that would allow you to opt-out from CC from linux-media (but
> possibly opt-in for other parts of the kernel), and allow me to opt-in
> for the drivers I maintain ?

I don't think so. Perhaps we could add, instead, something like that at the
sub-maintainers section of the profile.

> > > > +Submit Checklist Addendum
> > > > +-
> > > > +
> > > > +There is a set of compliance tools at 
> > > > https://git.linuxtv.org/v4l-utils.git/
> > > > +that should be used in order to check if the drivers are properly
> > > > +implementing the media APIs.
> > > > +
> > > > +Those tests need to be passed before the patches go upstream.
> > > 
> > > s/need to be passed/need to pass/
> > >   
> > > > +
> > > > +Also, please notice that we build the Kernel with::
> > > > +
> > > > +   make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 
> > > > W=1 CHECK=check_script
> > > > +
> > > > +Where the check script is::
> > > > +
> > > > +   #!/bin/bash
> > > > +   /devel/smatch/smatch -p=kernel $@ >&2
> > > > +   /devel/sparse/sparse $@ >&2
> > > > +
> > > > +Be sure to not introduce new warnings on your patches.
> > > 
> > > While static analysers deliver value, I fear this is a high barrier to
> > > entry for new contributors.  
> > 
> > Will change this to:
> > 
> > Be sure to not introduce new warnings on your patches without a 
> > very good reason.
> > 
> > Especially for new contributors, I really expect patches to not introduce
> > new warnings, as it is usually a lot more painful to fix them later than
> > to ask devs to do things right at the first place.  
> 
> I fully agree with the goal, but asking a drive-by contributor, who
> usually has to go through issues with sending patches through e-mail
> already, to install smatch and sparse and use them, is setting the bar
> high. I think automating those checks is the way to go.

Yeah, I have plans to automate it, the same way we did for pull
requests. I'm planning to do that later, after upgrading patchwork
to the current upstream version (with requires upgrading some libraries
too at the server).

In any case, having this at the profile is a reminder for whomever is 
submitting a patch that it should be clean for static analyzers too.

> > > > +Coding Style Addendum
> > > > +-
> > > > +
> > > > +Media development uses checkpatch on strict mode to verify the code 
> > > > style, e. g.::
> > > > +
> > > > +   $ ./script/checkpatch.pl --strict
> > > 
> > > But we still accept some warnings. I think this should be documented.  
> > 
> > True, but not sure if we should enter into too specific details here.
> > 
> > What about adding something like:
> > 
> > Please notice that the goal here is to improve code readability. On a 
> > few 
> > cases, checkpatch may actually point to something that would look 
> > worse. 
> > 
> > So, you should use good send sense here, being prepared to justify any  
> >  
> 
> s/send sense/sense/

Gah... where this "send" came from??? :-p

> 
> > coding style decision.  
> 
> "being prepared to justify" sounds a bit harsh :-) But the general
> message is good.

Any suggestions for a lighter text with similar meaning? :-)

> > Please also notice that, on some cases, when you fix one issue, you may
> > receive warnings about lines longer than 80 columns. It is fine to have
> > longer lines if this means that other warnings will be fixed by that.
> > 
> > Yet, if you're having more than 80 columns on a line, please consider 
> > simplifying the code - if too idented - or to use shorter names for 
> > variables.  
> 
> That's already quite specific for my taste. We can keep it as-is if you
> think it's fine, but we clearly shouldn't go into more details.

Yeah, I see. Yet, IMHO, we should either not add anything about checkpatch
warnings that might not be relevant or add something similar like the above.

Thanks,
Mauro

Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)

[Mauro Carvalho Chehab]

Em Wed, 18 Sep 2019 10:39:32 -0700
Kees Cook  escreveu:

> On Wed, Sep 18, 2019 at 08:23:26AM -0300, Mauro Carvalho Chehab wrote:
> > You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,  
> 
> Right! Sorry, I meant what you'd suggested earlier: having a script
> convert it at doc-build-time.
> 
> > The latest RFC about that with I sent was this one:
> > 
> > 
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html  
> 
> Cool, I've found it on Lore now too:
> https://lore.kernel.org/lkml/20160923120733.546a4...@vento.lan/
> 
> I think having a script generate the entire thing might be better
> (instead of having duplicated instructions at the top of both files),
> which I see is what Joe suggested too.

Yes, I agree that having the instructions duplicated was not the best
idea :-)

I guess I did it, on that time, just to experiment with the approach,
but my plan were to avoid the duplication on some future patch.

The big issue, on that point, was the usage of the programoutput
extension. Some devs didn't like using it.


> 
> > +.. include:: ../../MAINTAINERS
> > +   :literal:  
> 
> Nah, let's do a full make target as you'd suggested back in that thread.
> 
> I'll give it a shot if you don't beat me to it. :)

Yeah, please give it a shot. Feel free to reuse anything from my past
approaches if needed. 

I suspect that, if we convert the first part of MAINTAINERS to ReST
syntax, we could add something similar to this to Documentation/Makefile:

$(BUILDDIR)/maintainers.rst:

awk '{if (match($0,"--")) exit; print}' MAINTAINERS 
>$(BUILDDIR)/maintainers.rst
awk '/--/{y=1;next}y' MAINTAINERS|sed -E 's,^(\w:),:\1,' 
>>$(BUILDDIR)/maintainers.rst


Thanks,
Mauro

Re: [PATCH v2] media: add a subsystem profile documentation

[Mauro Carvalho Chehab]

Em Wed, 18 Sep 2019 11:07:16 -0300
André Almeida  escreveu:

> Hello Mauro,
> 
> On 9/18/19 10:59 AM, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  Documentation/media/index.rst |   1 +
> >  .../media/maintainer-entry-profile.rst| 157 ++
> >  MAINTAINERS   |   1 +
> >  3 files changed, 159 insertions(+)
> >  create mode 100644 Documentation/media/maintainer-entry-profile.rst
> > 
> > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > index 0301c25ff887..ac94685b822a 100644
> > --- a/Documentation/media/index.rst
> > +++ b/Documentation/media/index.rst
> > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> >  .. toctree::
> > :maxdepth: 2
> >  
> > +   maintainer-entry-profile
> > media_uapi
> > media_kapi
> > dvb-drivers/index
> > diff --git a/Documentation/media/maintainer-entry-profile.rst 
> > b/Documentation/media/maintainer-entry-profile.rst
> > new file mode 100644
> > index ..68d642abe2c1
> > --- /dev/null
> > +++ b/Documentation/media/maintainer-entry-profile.rst
> > @@ -0,0 +1,157 @@
> > +Media Subsystem Profile
> > +===
> > +
> > +Overview
> > +
> > +
> > +The media subsystem covers support for a variety of devices: stream
> > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > +and media pipeline control.
> > +
> > +It covers, mainly, the contents of those directories:
> > +
> > +  - drivers/media
> > +  - drivers/staging/media
> > +  - Documentation/media
> > +  - include/media
> > +
> > +Both media userspace and Kernel APIs are documented and should be kept in
> > +sync with the API changes. It means that all patches that add new
> > +features to the subsystem should also bring changes to the corresponding
> > +API files.
> > +
> > +Also, patches that changes the Open Firmware/Device Tree bindings should
> > +also be reviewed by the Device Tree maintainers.
> > +
> > +Due to the size and wide scope of the media subsystem, media's
> > +maintainership model is to have sub-maintainers that have a broad
> > +knowledge of an specific aspect of the subsystem. It is a
> > +sub-maintainer's task to review the patches, providing feedback to users
> > +if the patches are following the subsystem rules and are properly using
> > +the media internal and external APIs.
> > +
> > +Patches for the media subsystem should be sent to the media mailing list
> > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > +HTML will be automatically rejected by the mail server. It could be wise
> > +to also copy the sub-maintainer(s).
> > +
> > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > +is submitted, it should appear at:
> > +
> > +   - https://patchwork.linuxtv.org/project/linux-media/list/
> > +
> > +If it doesn't automatically appear there after a few minutes, then
> > +probably something got wrong on your submission. Please check if the
> > +email is in plain text only and if your emailer is not mangling with
> > +whitespaces before complaining or submit it again.
> > +
> > +Sub-maintainers
> >   
> 
> What is the motivation for using "+++" instead of "---"?

Just cosmetics.

This chapter doesn't exist at the original profile, as sub-maintainers,
co-maintainers, etc. are used only on a few subsystems. 

So, I'm adding it as a sub-chapter.

Thanks,
Mauro

[PATCH v2] media: add a subsystem profile documentation

[Mauro Carvalho Chehab]

Document the basic policies of the media subsystem profile.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/index.rst |   1 +
 .../media/maintainer-entry-profile.rst| 157 ++
 MAINTAINERS   |   1 +
 3 files changed, 159 insertions(+)
 create mode 100644 Documentation/media/maintainer-entry-profile.rst

diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 0301c25ff887..ac94685b822a 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
 .. toctree::
:maxdepth: 2
 
+   maintainer-entry-profile
media_uapi
media_kapi
dvb-drivers/index
diff --git a/Documentation/media/maintainer-entry-profile.rst 
b/Documentation/media/maintainer-entry-profile.rst
new file mode 100644
index ..68d642abe2c1
--- /dev/null
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -0,0 +1,157 @@
+Media Subsystem Profile
+===
+
+Overview
+
+
+The media subsystem covers support for a variety of devices: stream
+capture, analog and digital TV, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+
+It covers, mainly, the contents of those directories:
+
+  - drivers/media
+  - drivers/staging/media
+  - Documentation/media
+  - include/media
+
+Both media userspace and Kernel APIs are documented and should be kept in
+sync with the API changes. It means that all patches that add new
+features to the subsystem should also bring changes to the corresponding
+API files.
+
+Also, patches that changes the Open Firmware/Device Tree bindings should
+also be reviewed by the Device Tree maintainers.
+
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of an specific aspect of the subsystem. It is a
+sub-maintainer's task to review the patches, providing feedback to users
+if the patches are following the subsystem rules and are properly using
+the media internal and external APIs.
+
+Patches for the media subsystem should be sent to the media mailing list
+at linux-media@vger.kernel.org as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. It could be wise
+to also copy the sub-maintainer(s).
+
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, it should appear at:
+
+   - https://patchwork.linuxtv.org/project/linux-media/list/
+
+If it doesn't automatically appear there after a few minutes, then
+probably something got wrong on your submission. Please check if the
+email is in plain text only and if your emailer is not mangling with
+whitespaces before complaining or submit it again.
+
+Sub-maintainers

+
+At the media subsystem, we have a group of experienced developers that
+are responsible for doing the code reviews at the drivers (called
+sub-maintainers), and another senior developer responsible for the
+subsystem as a hole. For core changes, whenever possible, multiple
+media (sub-)maintainers do the review.
+
+The sub-maintainers work on specific areas of the subsystem, as
+described below:
+
+Digital TV:
+  Sean Young 
+
+HDMI CEC:
+  Hans Verkuil 
+
+Media controller drivers:
+  Laurent Pinchart 
+
+Remote Controllers:
+  Sean Young 
+
+Sensor drivers:
+  Sakari Ailus 
+
+V4L2 drivers:
+  Hans Verkuil 
+
+Submit Checklist Addendum
+-
+
+There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
+that should be used in order to check if the drivers are properly
+implementing the media APIs.
+
+Those tests need to pass before the patches go upstream.
+
+Also, please notice that we build the Kernel with::
+
+   make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 
CHECK=check_script
+
+Where the check script is::
+
+   #!/bin/bash
+   /devel/smatch/smatch -p=kernel $@ >&2
+   /devel/sparse/sparse $@ >&2
+
+Be sure to not introduce new warnings on your patches without a
+very good reason.
+
+Key Cycle Dates
+---
+
+New submissions can be sent at any time, but if they intend to hit the
+next merge window they should be sent before -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+
+Coding Style Addendum
+-
+
+Media development uses checkpatch on strict mode to verify the code style, e. 
g.::
+
+   $ ./script/checkpatch.pl --strict
+
+Please notice that the goal here is to improve code readability. On a few
+cases, checkpatch may actually point to something that would look worse.
+
+So, you should use good send sense here, being prepared to justify any
+coding style decision.
+
+Please also notice that, on some cases, when you fix one issue, you may
+receive warnings about lines longer than 80 columns. It is fine to have
+longer lines if t

Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation

[Mauro Carvalho Chehab]

Em Wed, 18 Sep 2019 15:36:20 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > 
> > That's basically a modified version of:
> > https://patchwork.linuxtv.org/patch/52999/
> > 
> > Applied to the new template
> > 
> >  Documentation/media/index.rst |   1 +
> >  .../media/maintainer-entry-profile.rst| 140 ++
> >  MAINTAINERS   |   1 +
> >  3 files changed, 142 insertions(+)
> >  create mode 100644 Documentation/media/maintainer-entry-profile.rst
> > 
> > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > index 0301c25ff887..ac94685b822a 100644
> > --- a/Documentation/media/index.rst
> > +++ b/Documentation/media/index.rst
> > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> >  .. toctree::
> > :maxdepth: 2
> >  
> > +   maintainer-entry-profile
> > media_uapi
> > media_kapi
> > dvb-drivers/index
> > diff --git a/Documentation/media/maintainer-entry-profile.rst 
> > b/Documentation/media/maintainer-entry-profile.rst
> > new file mode 100644
> > index ..81d3b0f9c36a
> > --- /dev/null
> > +++ b/Documentation/media/maintainer-entry-profile.rst
> > @@ -0,0 +1,140 @@
> > +Media Subsystem Profile
> > +===
> > +
> > +Overview
> > +
> > +
> > +The media subsystem cover support for a variety of devices: stream  
> 
> s/cover/covers/
> 
> > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > +and media pipeline control.
> > +
> > +It covers, mainly, the contents of those directories:
> > +
> > +  - drivers/media
> > +  - drivers/staging/media
> > +  - Documentation/media
> > +  - include/media
> > +
> > +Both media userspace and Kernel APIs are documented and should be kept in
> > +sync with the API changes. It means that all patches that add new
> > +features to the subsystem should also bring changes to the corresponding
> > +API files.
> > +
> > +Also, patches for device drivers that changes the Open Firmware/Device
> > +Tree bindings should be reviewed by the Device Tree maintainers.  
> 
> You may want to make it clear that this covers bindings only, not driver
> code that parses the DT. I would just remove "for device drivers", as
> the rule should also apply to DT bindings documentation that is not
> driver-specific.
> 
> > +Due to the size and wide scope of the media subsystem, media's
> > +maintainership model is to have sub-maintainers that have a broad
> > +knowledge of an specific aspect of the subsystem. It is a
> > +sub-maintainers task to review the patches, providing feedback to users  
> 
> s/sub-maintainers/sub-maintainer's/
> 
> > +if the patches are following the subsystem rules and are properly using
> > +the media internal and external APIs.
> > +
> > +Patches for the media subsystem should be sent to the media mailing list
> > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > +HTML will be automatically rejected by the mail server. There's no need
> > +to copy the maintainer or sub-maintainer(s).  
> 
> There's too much traffic on mailing lists for me to follow everything, I
> much prefer being CC'ed on patches.

Well, by using patchwork, the best is to take a look on it at least for
the patches that you're interested. You could script something using
pwclient in order to make it easier.

Anyway, not sure if the other sub-maintainers see the same way. From my side,
I prefer not to be c/c, as this is just more noise, as I just rely on
patchwork for media patches. What about changing this to:

Patches for the media subsystem should be sent to the media mailing list
at linux-media@vger.kernel.org as plain text only e-mail. Emails with
HTML will be automatically rejected by the mail server. It could be 
wise 
to also copy the sub-maintainer(s).

> 
> > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > +is submitted, it should appear at:
> > +
> > +   - https://patchwork.linuxtv.org/project/linux-media/list/
> > +
> > +If it doesn't automatically appear there after a few minutes, then
> > +probably something got wrong on your submission. Please check if the
> > +em

Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)

[Mauro Carvalho Chehab]

Em Tue, 17 Sep 2019 09:33:11 -0700
Kees Cook  escreveu:

> On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote:
> > No matter where the profiles will physically be stored, its contents belong 
> > to subsystem-specific documentation, and should be visible at the same 
> > index 
> > file as the kAPI docs is located, as anyone interested on submitting patches
> > for a subsystem should be aware about the subsystem specific policies and
> > details.  
> 
> That's a good point. I think your other suggestions below address my
> "find them all" case...
> 
> > So, my vote is to store them at Documentation/*/ (together
> > with the kAPI book).
> >   
> > > since there are
> > > two ways someone would want to read profiles:
> > > 
> > > 1) a single profile, based on a MAINTAINERS entry which includes the path 
> > >  
> > 
> > That is the common case. The problem is that the MAINTAINERS file
> > currently doesn't generate html output. This is not a problem for
> > "old school" devs, but a newbie wanting to collaborate to a single
> > specific subsystem may not notice - or understand - the importance
> > of the MAINTAINERS file[1].
> > 
> > [1] btw, that's why I submitted a RFC, several years ago, a patch
> > converting it to ReST - and later - another patch that would be parsing
> > its contents and producing a ReST output.
> > 
> > That's, by far, the most relevant usecase for the profiles, as the
> > audience is the ~4k Kernel developers.  
> 
> Oh yes, having a .rst of the MAINTAINERS file would be pretty great.
> Seems like it could just be a build target (and then dependency) for the
> sphinx targets?

You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
as:

- The instructions at the top will be badly parsed;
- It will also parse wrong the entries.

On the patches I wrote several years ago, I fixed the instructions
to make them to produce something that would produce a good output.
That's the easiest part.

For the entries contents, the simplest solution would be something like:

diff --git a/MAINTAINERS b/MAINTAINERS
index 6b4bc320e6ab..ae2afb14ae01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -147,4 +147,4 @@ F:  drivers/net/ethernet/3com/3c59x.c
-M: David Dillow 
-L: net...@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/3com/typhoon*
+:M:David Dillow 
+:L:net...@vger.kernel.org
+:S:Maintained
+:F:drivers/net/ethernet/3com/typhoon*

A trivial change for a normal file, but doing this at MAINTAINERS
will be really painful, as it will cause lots of conflicts.

So, IMO, the best way to do it is to have a script (or to teach
get_maintainers.pl) to produce a ReST output that would do the
above.

The latest RFC about that with I sent was this one:


https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html

I would probably address this on a different way those days.

A simple/lazy solution would be to apply the enclosed patch - or a
variant of it that would place the contents of MAINTAINERS outside
process/index.html, and add instructions about how to use
get_maintainers.pl.

Jon,

Please let me know if you're willing to accept something like that.

Thanks,
Mauro

[PATCH RFC] docs: process: add MAINTAINERS file contents

Anyone working with the Kernel need to consider the contents of the
MAINTAINERS file. So, add it to the ReST output.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index e2c9ffc682c5..22e5b42b8470 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -59,6 +59,9 @@ lack of a better place.
volatile-considered-harmful
clang-format
 
+.. include:: ../../MAINTAINERS
+   :literal:
+
 .. only::  subproject and html
 
Indices

Re: single maintainer profile directory (was Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation)

[Mauro Carvalho Chehab]

Hi Kees,

Em Mon, 16 Sep 2019 20:35:45 -0700
Kees Cook  escreveu:

> On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > 
> > That's basically a modified version of:
> > https://patchwork.linuxtv.org/patch/52999/
> > 
> > Applied to the new template
> > 
> >  Documentation/media/index.rst |   1 +
> >  .../media/maintainer-entry-profile.rst| 140 ++  
> 
> One idea I proposed to Dan at the Maintainer's Summit was to collect all
> the profiles is a single directory in Documentation/, 

No matter where the profiles will physically be stored, its contents belong 
to subsystem-specific documentation, and should be visible at the same index 
file as the kAPI docs is located, as anyone interested on submitting patches
for a subsystem should be aware about the subsystem specific policies and
details.

So, my vote is to store them at Documentation/*/ (together
with the kAPI book).

> since there are
> two ways someone would want to read profiles:
> 
> 1) a single profile, based on a MAINTAINERS entry which includes the path

That is the common case. The problem is that the MAINTAINERS file
currently doesn't generate html output. This is not a problem for
"old school" devs, but a newbie wanting to collaborate to a single
specific subsystem may not notice - or understand - the importance
of the MAINTAINERS file[1].

[1] btw, that's why I submitted a RFC, several years ago, a patch
converting it to ReST - and later - another patch that would be parsing
its contents and producing a ReST output.

That's, by far, the most relevant usecase for the profiles, as the
audience is the ~4k Kernel developers.

> 2) all of them, to study for various reasons

I suspect that only core people will have interest on study them.

Those people are more skilled, and can easily find all those files with
a simple grep:

$ grep  "^P:\s" MAINTAINERS|cut -d':' -f2-

or

$ git grep "^P:\s" MAINTAINERS|cut -d: -f3-

If, for whatever reason, he would prefer an HTML output [1], he could even
create an index file with all of those with something like:

$ for i in $(grep  "^P:\s" MAINTAINERS|cut -d':' -f2-); do 
j=${i/rst/html}; echo "$j"; done 
>Documentation/output/index_profiles.html

We might, instead, teach the Documentation/Makefile to create something
like the above, but, IMHO, that would just add more complexity to the
build without a good reason.

[1] I doubt that core devs would prefer seeing this in html form, but some
variant of the above could be used, for example, to create symlinks for
all profile docs into a "study" directory.

> The #2 case is helped by having them all in one directory with a single
> index.rst, etc. Then similar profiles are able to merge, etc.


Thanks,
Mauro

[PATCH] media: add a subsystem profile documentation

[Mauro Carvalho Chehab]

Document the basic policies of the media subsystem profile.

Signed-off-by: Mauro Carvalho Chehab 
---

That's basically a modified version of:
https://patchwork.linuxtv.org/patch/52999/

Applied to the new template

 Documentation/media/index.rst |   1 +
 .../media/maintainer-entry-profile.rst| 140 ++
 MAINTAINERS   |   1 +
 3 files changed, 142 insertions(+)
 create mode 100644 Documentation/media/maintainer-entry-profile.rst

diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 0301c25ff887..ac94685b822a 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
 .. toctree::
:maxdepth: 2
 
+   maintainer-entry-profile
media_uapi
media_kapi
dvb-drivers/index
diff --git a/Documentation/media/maintainer-entry-profile.rst 
b/Documentation/media/maintainer-entry-profile.rst
new file mode 100644
index ..81d3b0f9c36a
--- /dev/null
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -0,0 +1,140 @@
+Media Subsystem Profile
+===
+
+Overview
+
+
+The media subsystem cover support for a variety of devices: stream
+capture, analog and digital TV, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+
+It covers, mainly, the contents of those directories:
+
+  - drivers/media
+  - drivers/staging/media
+  - Documentation/media
+  - include/media
+
+Both media userspace and Kernel APIs are documented and should be kept in
+sync with the API changes. It means that all patches that add new
+features to the subsystem should also bring changes to the corresponding
+API files.
+
+Also, patches for device drivers that changes the Open Firmware/Device
+Tree bindings should be reviewed by the Device Tree maintainers.
+
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of an specific aspect of the subsystem. It is a
+sub-maintainers task to review the patches, providing feedback to users
+if the patches are following the subsystem rules and are properly using
+the media internal and external APIs.
+
+Patches for the media subsystem should be sent to the media mailing list
+at linux-media@vger.kernel.org as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. There's no need
+to copy the maintainer or sub-maintainer(s).
+
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, it should appear at:
+
+   - https://patchwork.linuxtv.org/project/linux-media/list/
+
+If it doesn't automatically appear there after a few minutes, then
+probably something got wrong on your submission. Please check if the
+email is in plain text only and if your emailer is not mangling with
+whitespaces before complaining or submit it again.
+
+Sub-maintainers

+
+At the media subsystem, we have a group of senior developers that are
+responsible for doing the code reviews at the drivers (called
+sub-maintainers), and another senior developer responsible for the
+subsystem as a hole. For core changes, whenever possible, multiple
+media (sub-)maintainers do the review.
+
+The sub-maintainers work on specific areas of the subsystem, as
+described below:
+
+Digital TV:
+  Sean Young 
+
+HDMI CEC:
+  Hans Verkuil 
+
+Media controller drivers:
+  Laurent Pinchart 
+
+Remote Controllers:
+  Sean Young 
+
+Sensor drivers:
+  Sakari Ailus 
+
+V4L2 drivers:
+  Hans Verkuil 
+
+Submit Checklist Addendum
+-
+
+There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
+that should be used in order to check if the drivers are properly
+implementing the media APIs.
+
+Those tests need to be passed before the patches go upstream.
+
+Also, please notice that we build the Kernel with::
+
+   make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 
CHECK=check_script
+
+Where the check script is::
+
+   #!/bin/bash
+   /devel/smatch/smatch -p=kernel $@ >&2
+   /devel/sparse/sparse $@ >&2
+
+Be sure to not introduce new warnings on your patches.
+
+Key Cycle Dates
+---
+
+New submissions can be sent at any time, but if they intend to hit the
+next merge window they should be sent before -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+
+Coding Style Addendum
+-
+
+Media development uses checkpatch on strict mode to verify the code style, e. 
g.::
+
+   $ ./script/checkpatch.pl --strict
+
+Review Cadence
+--
+
+Provided that your patch is at https://patchwork.linuxtv.org, it should
+be sooner or later handled, so you don't need to re-submit a patch.
+
+Except for bug fixes, we don't usually add new patches to the development
+tree between -rc6 and the next -rc

Re: [RFC] V4L2 & Metadata: switch to /dev/v4l-metaX instead of /dev/videoX

[Mauro Carvalho Chehab]

Em Thu, 12 Sep 2019 14:16:11 +0100
Kieran Bingham  escreveu:

> Hi Hans,
> 
> On 12/09/2019 08:48, Hans Verkuil wrote:
> > Hi all,
> > 
> > I am increasingly unhappy about the choice of /dev/videoX for metadata 
> > devices.
> > 
> > It is confusing for end-users (especially w.r.t. the common uvc driver) and
> > if we want to change this, then we need to do it soon.

Kernel has (about) nothing to do with how the userspace devnodes are
named, as the actual name is given by udev.

Anyway, from Kernel standpoint, it sounds too late to change the name
of the devices from "videoX" to something else, as a change like that
may break existing apps.

It could make sense to have something like that at udev rules.

Btw, at least at the apps I'm maintaining on userspace, I'm not using
/dev/foo to detect devices anymore. Instead, I'm relying on udev
in order to enum devices, checking if the devnode support video stream
capabilities before exposing them for userspace to select.

> > 
> > This patch https://patchwork.linuxtv.org/patch/58693/ adds a new 
> > VFL_TYPE_METADATA
> > so at least drivers can now explicitly signal that they want to register a
> > metadata device.
> > 
> > This also makes it possible to add a kernel config option that allows you
> > to select whether you want metadata devices to appear as videoX or 
> > v4l-metaX.
> > I would prefer to set it to v4l-metaX by default.  
> 
> I think I prefer this separation (v4l-metaX).
> 
> Having metadata as a (separate) videoX seemed odd to me - but I only
> saw/was affected by the metadata topics when it was too late it seemed ...
> 
> 
> > We can also consider backporting this to the stable/long-term kernels.
> > 
> > Metadata capture was introduced in 4.12 for the vsp1 driver, in 4.16 for the
> > uvc driver and in 5.0 for the staging ipu3 driver.
> > 
> > Does someone remember the reason why we picked /dev/videoX for this in the
> > first place?  
> 
> I've wondered why it's not a separate queue on the same video device -
> much like we have multiple queues for V4L2-M2M devices 
> 
> The data is relative to the same frames coming from the main queue right ?
> 
> That might have been awkward to express through our device type flags
> though.
> 
> Anyway, I thought the horse had bolted on this topic ?
> 
>  :-D
> 
> 
> > Regards,
> > 
> > Hans
> >   
> 
> 



Thanks,
Mauro

Re: [PATCH v2 01/10] media: dt-bindings: Document 'location' property

[Mauro Carvalho Chehab]

Em Tue, 27 Aug 2019 15:21:26 +0300
Laurent Pinchart  escreveu:

> Hi Jacopo,
> 
> Thank you for the patch.
> 
> On Tue, Aug 27, 2019 at 11:23:27AM +0200, Jacopo Mondi wrote:
> > Add the 'location' device property, used to specify the camera device
> > mounting position. The property is particularly meaningful for mobile
> > devices with a well defined usage orientation.
> > 
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  .../devicetree/bindings/media/video-interfaces.txt | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
> > b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > index f884ada0bffc..865f4142f432 100644
> > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > @@ -89,6 +89,16 @@ Optional properties
> >but a number of degrees counter clockwise. Typical values are 0 and 180
> >(upside down).
> > 
> > +- location: The camera sensor mounting location, expressed as a position
> > +  relative to the usage orientation of the device the sensor is installed 
> > on.  
> 
> DT bindings being ABIs, we need to be precise and thorough there. One
> particular point that bothers me is that the property is named location,
> and its description refers to camera sensor mounting location.

Yeah, "location" doesn't sound a good name for me neither.
 
> 
> I see two options to fix this. One of them is to rename the property to
> camera-location, but that would limit its future usage for other types
> of devices. The other one is to document the property as applying to a
> "device" instead of a "camera sensor", and add one sentence stating that
> this property is valid for camera sensors only.
> 
> This will require finding another name for the device that the device is
> mounted on though, as using device twice would be very confusing.
> 
> > +  Possible values are:
> > +  0 - Front. The image sensor is mounted on the front facing side of the 
> > device.
> > +  For mobile devices such as smartphones, tablets and laptops the front 
> > side is
> > +  the user facing side of the device.
> > +  1 - Back. The image sensor is mounted on the back side of the device, 
> > which is
> > +  defined as the opposite side of the front facing one.
> > +  2 - External. The image sensor is connected to the device by extension 
> > cables,
> > +  and can be freely moved, regardless of the device position. 

Hmm...

Besides the point that Laurent and Rob already commented, just those 3 options 
doesn't seem good enough. I was reading a public article yesterday about a new
device (Samsung Galaxy Fold[1]) with comes with 6 cameras, being 3 at back, 
1 at front, when the device is opened, and 1 camera that could be either at the
back or at the front, depending if the device is opened or not. 

Btw, on a device with multiple cameras at the same side, it would
make sense to also be able to uniquely identify the location of each
sensor somehow.

There are also some other new devices with a front motorized slider camera
that sits hidden inside the phone, until when someone uses it.

Thanks,
Mauro

[PATCH] media: cx231xx: fix unregister logic

[Mauro Carvalho Chehab]

Right now, dev->users is not been decremented for VBI nodes,
causing unregister to fail. Fix it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/cx231xx/cx231xx-video.c | 25 +--
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c 
b/drivers/media/usb/cx231xx/cx231xx-video.c
index 6d2f4da3a3fa..69abafaebbf3 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -1557,6 +1557,18 @@ static int cx231xx_close(struct file *filp)
 
_vb2_fop_release(filp, NULL);
 
+   if (--dev->users == 0) {
+   /* Save some power by putting tuner to sleep */
+   call_all(dev, tuner, standby);
+
+   /* do this before setting alternate! */
+   if (dev->USE_ISO)
+   cx231xx_uninit_isoc(dev);
+   else
+   cx231xx_uninit_bulk(dev);
+   cx231xx_set_mode(dev, CX231XX_SUSPEND);
+   }
+
/*
 * To workaround error number=-71 on EP0 for VideoGrabber,
 *   need exclude following.
@@ -1577,20 +1589,11 @@ static int cx231xx_close(struct file *filp)
return 0;
}
 
-   if (--dev->users == 0) {
-   /* Save some power by putting tuner to sleep */
-   call_all(dev, tuner, standby);
-
-   /* do this before setting alternate! */
-   if (dev->USE_ISO)
-   cx231xx_uninit_isoc(dev);
-   else
-   cx231xx_uninit_bulk(dev);
-   cx231xx_set_mode(dev, CX231XX_SUSPEND);
-
+   if (dev->users == 0) {
/* set alternate 0 */
cx231xx_set_alt_setting(dev, INDEX_VIDEO, 0);
}
+
wake_up_interruptible(&dev->open);
return 0;
 }
-- 
2.21.0

Re: hdpvr.ko kernel 5.3-rc6

[Mauro Carvalho Chehab]

Em Wed, 4 Sep 2019 11:13:36 -0700
Scott Doty  escreveu:

> On 9/3/19 1:34 AM, Hans Verkuil wrote:
> >
> > Never mind, hdpvr uses read(), not streaming I/O. Of course this
> > doesn't work...
> >
> > Just plain 'cat /dev/videoX >x.mpg' will do.
> >
> >  
> 
> Okay, tried that, it produces data that vlc can then play back.
> 
> So I think I'm running into a problem with vlc instead of hdpvr. It's 
> just weird that mplayer, vlc, and ffplay would all three be unable to 
> use it.

You can use any of them, provided that it is opened as if it were a
normal file, using the read() interface. For example, this should work:

cat /dev/videoX | mplayer -cache 8000 -

The thing is that most apps assume that a V4L2 device supports mmap().

This is true for almost all devices, being hdpvr - and pvrusb - two
exceptions.


Thanks,
Mauro

Re: bug: dvbv5-scan segfaults

[Mauro Carvalho Chehab]

Em Tue, 27 Aug 2019 19:49:41 +0300
Olcay Korkmaz  escreveu:

> > Ok, the problem is happening here:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > dvb_store_channel (dvb_file=0x7fffe460, __p=0x555605d0, 
> > dvb_scan_handler=0x55565060, get_detected=0,
> > get_nit=0) at dvb-file.c:1345
> > 1345if (dvb_scan_handler->nit->transport) {
> > (gdb) bt
> > #0  dvb_store_channel (dvb_file=0x7fffe460, __p=0x555605d0, 
> > dvb_scan_handler=0x55565060, get_detected=0,
> > get_nit=0) at dvb-file.c:1345
> > #1  0x6847 in run_scan (dvb=0x555604f0, 
> > args=0x7fffe4b0) at dvbv5-scan.c:313
> > #2  main (argc=, argv=) at dvbv5-scan.c:562
> >
> > The enclosed patch should fix the issue. Could you please check?  
> 
> Thanks, patch fixed the problem.

Great!

Patch applied to master and to stable-1.16 and stable-1.14 branches:


https://git.linuxtv.org/v4l-utils.git/commit/?h=stable-1.14&id=0622c6d3592efa4817cfba148c64bd034baa2420

https://git.linuxtv.org/v4l-utils.git/commit/?h=stable-1.16&id=7c0eda007e698c5d2cbfb9fb33bb2472551ec46d

https://git.linuxtv.org/v4l-utils.git/commit/?id=58edfe080b1442c274c85b98cb6e7374c28695cf

Gregor,

Could you please place them on a next stable release for 1.14 and 1.16?

Thanks,
Mauro

[PATCH] libdvbv5: Don't assume that NIT table was parsed

[Mauro Carvalho Chehab]

It might happen that the NIT table doesn't get parsed.

As reported by Olcay, some transponders at Turksat-42.0E seem
to be missing the NIT table, causing dvb tools to crash with:

Program received signal SIGSEGV, Segmentation fault.
dvb_store_channel (dvb_file=0x7fffe460, __p=0x555605d0, 
dvb_scan_handler=0x55565060, get_detected=0,
get_nit=0) at dvb-file.c:1345
1345if (dvb_scan_handler->nit->transport) {

As both transport ID and network ID are optional information,
verify if the nit table was parsed before trying fill them.

Reported-by: Olcay Korkmaz 
Signed-off-by: Mauro Carvalho Chehab 
---
 lib/libdvbv5/dvb-file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/libdvbv5/dvb-file.c b/lib/libdvbv5/dvb-file.c
index d077271a6546..474b59cb6fce 100644
--- a/lib/libdvbv5/dvb-file.c
+++ b/lib/libdvbv5/dvb-file.c
@@ -1342,7 +1342,7 @@ int dvb_store_channel(struct dvb_file **dvb_file,
dvb_log(_("Storing as channel %s"), channel);
vchannel = dvb_vchannel(parms, dvb_scan_handler->nit, 
service->service_id);
 
-   if (dvb_scan_handler->nit->transport) {
+   if (dvb_scan_handler->nit && dvb_scan_handler->nit->transport) {
network_id = 
dvb_scan_handler->nit->transport->network_id;
transport_id = 
dvb_scan_handler->nit->transport->transport_id;
}
-- 
2.21.0

Re: bug: dvbv5-scan segfaults

[Mauro Carvalho Chehab]

Em Mon, 26 Aug 2019 22:25:28 +0300
Olcay Korkmaz  escreveu:

> 1.14.2 and git tree build gives the same error
> TS of entire transponder:
> https://drive.google.com/file/d/1zHouZSlbPowyJY5tzT5ro0r4ciPURkbi/view?usp=sharing

Thanks!

Please don't top-post.

> > Em Mon, 26 Aug 2019 19:59:17 +0300
> > Olcay Korkmaz  escreveu:
> >  


> > > Service TV8, provider TV8: digital television
> > > Storing as channel TV8
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x77ba5cff in dvb_store_channel ()
> > >from /usr/lib/x86_64-linux-gnu/libdvbv5.so.0
> > > (gdb) backtrace  
> >
> >  
> > > #0 0x77ba5cff in dvb_store_channel ()
> > >from /usr/lib/x86_64-linux-gnu/libdvbv5.so.0
> > > #1 0x60c6 in run_scan (dvb=0x5575d2e0, 
> > > args=0x7fffdc80)
> > > at dvbv5-scan.c:313
> > > #2 main (argc=, argv=) at dvbv5-scan.c:562

Ok, the problem is happening here:

Program received signal SIGSEGV, Segmentation fault.
dvb_store_channel (dvb_file=0x7fffe460, __p=0x555605d0, 
dvb_scan_handler=0x55565060, get_detected=0, 
get_nit=0) at dvb-file.c:1345
1345if (dvb_scan_handler->nit->transport) {
(gdb) bt
#0  dvb_store_channel (dvb_file=0x7fffe460, __p=0x555605d0, 
dvb_scan_handler=0x55565060, get_detected=0, 
get_nit=0) at dvb-file.c:1345
#1  0x6847 in run_scan (dvb=0x555604f0, args=0x7fffe4b0) at 
dvbv5-scan.c:313
#2  main (argc=, argv=) at dvbv5-scan.c:562

The enclosed patch should fix the issue. Could you please check?

diff --git a/lib/libdvbv5/dvb-file.c b/lib/libdvbv5/dvb-file.c
index d077271a6546..474b59cb6fce 100644
--- a/lib/libdvbv5/dvb-file.c
+++ b/lib/libdvbv5/dvb-file.c
@@ -1342,7 +1342,7 @@ int dvb_store_channel(struct dvb_file **dvb_file,
dvb_log(_("Storing as channel %s"), channel);
vchannel = dvb_vchannel(parms, dvb_scan_handler->nit, 
service->service_id);
 
-   if (dvb_scan_handler->nit->transport) {
+   if (dvb_scan_handler->nit && dvb_scan_handler->nit->transport) {
network_id = 
dvb_scan_handler->nit->transport->network_id;
transport_id = 
dvb_scan_handler->nit->transport->transport_id;
}


Regards,
Mauro

Re: bug: dvbv5-scan segfaults

[Mauro Carvalho Chehab]

Hi Olcay,

Em Mon, 26 Aug 2019 19:59:17 +0300
Olcay Korkmaz  escreveu:

> Hello,
> dvbv5-scan segfaults when scanning transponders at Turksat-42.0E
> (three of transponders are causing the error)

Are you using the latest version of dvbv5-scan from the git tree?

> 
> LANG=en_US.UTF-8 gdb -ex=r --args dvbv5-scan -l UNIVERSAL -S0 -v -o
> Turksat.conf ./Turksat-42.0E
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Using LNBf UNIVERSAL
>  Universal, Europe
>  Freqs : 10800 to 11800 MHz, LO: 9750 MHz
>  Freqs : 11600 to 12700 MHz, LO: 10600 MHz
> using demux 'dvb0.demux0'
> Device Montage Technology DS3000/TS2020 (/dev/dvb/adapter0/frontend0)
> capabilities:
>  CAN_2G_MODULATION
>  CAN_FEC_1_2
>  CAN_FEC_2_3
>  CAN_FEC_3_4
>  CAN_FEC_4_5
>  CAN_FEC_5_6
>  CAN_FEC_6_7
>  CAN_FEC_7_8
>  CAN_FEC_AUTO
>  CAN_INVERSION_AUTO
>  CAN_QPSK
>  CAN_RECOVER
> DVB API Version 5.11, Current v5 delivery system: DVBS
> Supported delivery systems:
> [DVBS]
>  DVBS2
> Failed to guess country from the current locale setting.
> 
> ERROR command BANDWIDTH_HZ (5) not found during retrieve
> Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable 
> (yet).
> Scanning frequency #1 12346000
> frequency: 12346,00 MHz, high_band: 1
> SEC: set voltage to 18V
> DiSEqC TONE: OFF
> DiSEqC command: e0 10 38 f3
> DiSEqC BURST: SEC_MINI_A
> DiSEqC TONE: ON
> L-Band frequency: 1746,00 MHz (offset = 10600,00 MHz)
> FREQUENCY = 12346000
> INVERSION = AUTO
> SYMBOL_RATE = 960
> INNER_FEC = 3/4
> POLARIZATION = HORIZONTAL
> DELIVERY_SYSTEM = DVBS
> Got parameters for DVBS:
> FREQUENCY = 12346000
> INVERSION = AUTO
> SYMBOL_RATE = 960
> INNER_FEC = 3/4
> POLARIZATION = HORIZONTAL
> DELIVERY_SYSTEM = DVBS
> Lock (0x1f) Signal= 37,86% C/N= 47,97% UCB= 31440 postBER= 0
> dvb_read_sections: waiting for table ID 0x00, program ID 0x00
> dvb_parse_section: received table 0x00, extension ID 0xa414, section 0/0
> dvb_parse_section: table 0x00, extension ID 0xa414: done
> PAT
> | table_id 0x00
> | section_length 25
> | one 3
> | zero 0
> | syntax 1
> | transport_stream_id 42004
> | current_next 1
> | version 14
> | one2 3
> | section_number 0
> | last_section_number 0
> |\ 4 program pids
> | pid 0x0010: service 0x
> | pid 0x0065: service 0x3264
> | pid 0x012d: service 0x3265
> | pid 0x0066: service 0x3269
> Program #0 is network PID: 0x0010
> Program #1 ID 0x0065, service ID 0x3264
> dvb_read_sections: waiting for table ID 0x02, program ID 0x65
> dvb_parse_section: received table 0x02, extension ID 0x3264, section 0/0
> dvb_parse_section: table 0x02, extension ID 0x3264: done
> PMT
> | table_id 0x02
> | section_length 112
> | one 3
> | zero 0
> | syntax 1
> | transport_stream_id 12900
> | current_next 1
> | version 7
> | one2 3
> | section_number 0
> | last_section_number 0
> |- pcr_pid 0b54
> | reserved2 7
> | descriptor length 11
> | zero3 0
> | reserved3 15
> | 0x0c: multiplex_buffer_utilization_descriptor
> | 80 b4 81 68 ...h
> | 0x0e: maximum_bitrate_descriptor
> | c0 3e a4 .>.
> |\
> |- stream 0x0b54: Video ISO/IEC 13818-2 (2)
> | descriptor length 16
> | 0x52: stream_identifier_descriptor
> | 01 .
> | 0x02: video_stream_descriptor
> | 1a 48 5f .H_
> | 0x06: ds_alignment_descriptor
> | 02 .
> | 0x0e: maximum_bitrate_descriptor
> | c0 39 4e .9N
> |- stream 0x0bb8: Audio ISO/IEC 13818-3 (4)
> | descriptor length 17
> | 0x52: stream_identifier_descriptor
> | 02 .
> | 0x0a: iso639_language_descriptor
> | lang: tur (type: 0)
> | 0x03: audio_stream_descriptor
> | 67 g
> | 0x0e: maximum_bitrate_descriptor
> | c0 02 90 ...
> |- stream 0x0c1c: Audio ISO/IEC 13818-3 (4)
> | descriptor length 17
> | 0x52: stream_identifier_descriptor
> | 03 .
> | 0x0a: iso639_language_descriptor
> | lang: eng (type: 0)
> | 0x03: audio_stream_descriptor
> | 67 g
> | 0x0e: maximum_bitrate_descriptor
> | c0 01 49 ..I
> |- stream 0x1779: ISO/IEC 13818-1 Private Sections (5)
> | descriptor length 5
> | 0x6f: application_signalling_descriptor
> | 00 10 e0 ...
> |- stream 0x1f48: ISO/IEC 13818-6 type C (c)
> | descriptor length 8
> | 0x52: stream_identifier_descriptor
> | 2e .
> | 0x0e: maximum_bitrate_descriptor
> | c0 00 4b ..K
> |_ 5 streams
> Program #2 ID 0x012d, service ID 0x3265
> dvb_read_sections: waiting for table ID 0x02, program ID 0x12d
> dvb_parse_section: received table 0x02, extension ID 0x3265, section 0/0
> dvb_parse_section: table 0x02, extension ID 0x3265: done
> PMT
> | table_id 0x02
> | section_length 85
> | one 3
> | zero 0
> | syntax 1
> | transport_stream_id 12901
> | current_next 1
> | version 14
> | one2 3
> | section_number 0
> | last_section_number 0
> |- pcr_pid 0b55
> | reserved2 7
> | descriptor length 11
> | zero3 0
> | reserved3 15
> | 0x0c: multiplex_buffer_utilization_descriptor
> | 80 b4 81 68 ...h
> | 0x0e: maximum_bitrate_descriptor
> | c0 35 b9 .5.
> |\
> |- stream 0x0b55: Video ISO/IEC 

[GIT PULL] media patches

[Mauro Carvalho Chehab]

The following changes since commit 01faced6f65d0224bf6ce1262a4137771e28519f:

  media: dt-bindings: media: Convert Allwinner A10 IR to a schema (2019-08-21 
18:39:55 -0300)

are available in the Git repository at:

  git://linuxtv.org/mchehab/experimental.git tags/patches/v5.3-1

for you to fetch changes up to 03905f3929e5c8241aa0188eda41dcb37ffd64c5:

  media: don't do a 31 bit shift on a signed int (2019-08-26 06:49:18 -0300)



Media patches solving some issues detected by cppcheck.


Mauro Carvalho Chehab (6):
  media: remove include stdarg.h from some drivers
  media: vicodec: make life easier for static analyzers
  media: aspeed-video: address a protential usage of an unit var
  media: ov9650: add a sanity check
  media: use the BIT() macro
  media: don't do a 31 bit shift on a signed int

 drivers/media/dvb-frontends/cx24123.c |   2 +-
 drivers/media/i2c/ov9650.c|   5 +
 drivers/media/pci/bt8xx/bttv-input.c  |   4 +-
 drivers/media/pci/cobalt/cobalt-driver.h  |  63 +--
 drivers/media/pci/cx18/cx18-ioctl.c   |   2 +-
 drivers/media/pci/cx18/cx18-mailbox.c |   2 +-
 drivers/media/pci/ivtv/ivtv-driver.c  |   2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c   |   4 +-
 drivers/media/pci/ivtv/ivtv-irq.h |  28 +-
 drivers/media/pci/ivtv/ivtv-mailbox.c |   2 -
 drivers/media/pci/mantis/mantis_reg.h | 152 +++---
 drivers/media/pci/solo6x10/solo6x10-gpio.c|   6 +-
 drivers/media/pci/solo6x10/solo6x10-regs.h| 286 +--
 drivers/media/pci/ttpci/av7110_hw.c   |   1 -
 drivers/media/platform/am437x/am437x-vpfe_regs.h  |  26 +-
 drivers/media/platform/aspeed-video.c |   5 +-
 drivers/media/platform/davinci/dm644x_ccdc_regs.h |  20 +-
 drivers/media/platform/exynos4-is/fimc-lite-reg.h |  80 +--
 drivers/media/platform/exynos4-is/fimc-reg.h  | 138 ++---
 drivers/media/platform/exynos4-is/mipi-csis.c |   6 +-
 drivers/media/platform/fsl-viu.c  |   2 +-
 drivers/media/platform/mx2_emmaprp.c  |   2 +-
 drivers/media/platform/omap3isp/ispreg.h  | 584 +++---
 drivers/media/platform/pxa_camera.c   |   4 +-
 drivers/media/platform/qcom/venus/core.c  |   2 +-
 drivers/media/platform/s3c-camif/camif-regs.h | 118 ++---
 drivers/media/platform/s5p-jpeg/jpeg-regs.h   |  10 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c   |   4 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c   |   2 +-
 drivers/media/platform/tegra-cec/tegra_cec.h  |  82 +--
 drivers/media/platform/ti-vpe/vpe_regs.h  |  94 ++--
 drivers/media/platform/vicodec/vicodec-core.c |  11 +-
 drivers/media/platform/vsp1/vsp1_regs.h   | 224 -
 drivers/media/platform/xilinx/xilinx-vip.h|  29 +-
 drivers/media/radio/radio-gemtek.c|   2 +-
 drivers/media/radio/radio-trust.c |   1 -
 drivers/media/radio/wl128x/fmdrv_common.h |  88 ++--
 drivers/media/usb/dvb-usb-v2/gl861.c  |   2 +-
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c   |  14 +-
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c  |   4 +-
 drivers/media/v4l2-core/v4l2-ioctl.c  |   2 +-
 drivers/staging/media/ipu3/ipu3-tables.h  |   4 +-
 42 files changed, 1068 insertions(+), 1051 deletions(-)

[GIT PULL] media patches

[Mauro Carvalho Chehab]

The following changes since commit 01faced6f65d0224bf6ce1262a4137771e28519f:

  media: dt-bindings: media: Convert Allwinner A10 IR to a schema (2019-08-21 
18:39:55 -0300)

are available in the Git repository at:

  git://git://linuxtv.org/mchehab/experimental.git patches/v5.3-1

for you to fetch changes up to 03905f3929e5c8241aa0188eda41dcb37ffd64c5:

  media: don't do a 31 bit shift on a signed int (2019-08-26 06:49:18 -0300)



Media patches solving some issues detected by cppcheck.


Mauro Carvalho Chehab (6):
  media: remove include stdarg.h from some drivers
  media: vicodec: make life easier for static analyzers
  media: aspeed-video: address a protential usage of an unit var
  media: ov9650: add a sanity check
  media: use the BIT() macro
  media: don't do a 31 bit shift on a signed int

 drivers/media/dvb-frontends/cx24123.c |   2 +-
 drivers/media/i2c/ov9650.c|   5 +
 drivers/media/pci/bt8xx/bttv-input.c  |   4 +-
 drivers/media/pci/cobalt/cobalt-driver.h  |  63 +--
 drivers/media/pci/cx18/cx18-ioctl.c   |   2 +-
 drivers/media/pci/cx18/cx18-mailbox.c |   2 +-
 drivers/media/pci/ivtv/ivtv-driver.c  |   2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c   |   4 +-
 drivers/media/pci/ivtv/ivtv-irq.h |  28 +-
 drivers/media/pci/ivtv/ivtv-mailbox.c |   2 -
 drivers/media/pci/mantis/mantis_reg.h | 152 +++---
 drivers/media/pci/solo6x10/solo6x10-gpio.c|   6 +-
 drivers/media/pci/solo6x10/solo6x10-regs.h| 286 +--
 drivers/media/pci/ttpci/av7110_hw.c   |   1 -
 drivers/media/platform/am437x/am437x-vpfe_regs.h  |  26 +-
 drivers/media/platform/aspeed-video.c |   5 +-
 drivers/media/platform/davinci/dm644x_ccdc_regs.h |  20 +-
 drivers/media/platform/exynos4-is/fimc-lite-reg.h |  80 +--
 drivers/media/platform/exynos4-is/fimc-reg.h  | 138 ++---
 drivers/media/platform/exynos4-is/mipi-csis.c |   6 +-
 drivers/media/platform/fsl-viu.c  |   2 +-
 drivers/media/platform/mx2_emmaprp.c  |   2 +-
 drivers/media/platform/omap3isp/ispreg.h  | 584 +++---
 drivers/media/platform/pxa_camera.c   |   4 +-
 drivers/media/platform/qcom/venus/core.c  |   2 +-
 drivers/media/platform/s3c-camif/camif-regs.h | 118 ++---
 drivers/media/platform/s5p-jpeg/jpeg-regs.h   |  10 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c   |   4 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c   |   2 +-
 drivers/media/platform/tegra-cec/tegra_cec.h  |  82 +--
 drivers/media/platform/ti-vpe/vpe_regs.h  |  94 ++--
 drivers/media/platform/vicodec/vicodec-core.c |  11 +-
 drivers/media/platform/vsp1/vsp1_regs.h   | 224 -
 drivers/media/platform/xilinx/xilinx-vip.h|  29 +-
 drivers/media/radio/radio-gemtek.c|   2 +-
 drivers/media/radio/radio-trust.c |   1 -
 drivers/media/radio/wl128x/fmdrv_common.h |  88 ++--
 drivers/media/usb/dvb-usb-v2/gl861.c  |   2 +-
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c   |  14 +-
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c  |   4 +-
 drivers/media/v4l2-core/v4l2-ioctl.c  |   2 +-
 drivers/staging/media/ipu3/ipu3-tables.h  |   4 +-
 42 files changed, 1068 insertions(+), 1051 deletions(-)


---

Ok, sending an e-mail to me sounds a little... selfish :-)

Yet, doing that makes the pull request to be parsed by the builder, so,
if everything wents fine, I may end doing it from now on.

[PATCH] v4l2-core: fix coding style for the two new c files

[Mauro Carvalho Chehab]

As I2C and SPI parts of the V4L2 core got split, let's take
the chance and solve the CodingStyle issues there, as reported
by checkpatch --strict.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-i2c.c | 66 +++---
 drivers/media/v4l2-core/v4l2-spi.c | 21 ++
 2 files changed, 54 insertions(+), 33 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-i2c.c 
b/drivers/media/v4l2-core/v4l2-i2c.c
index d549291ab22b..5bf99e7c0c09 100644
--- a/drivers/media/v4l2-core/v4l2-i2c.c
+++ b/drivers/media/v4l2-core/v4l2-i2c.c
@@ -28,7 +28,8 @@ void v4l2_i2c_subdev_unregister(struct v4l2_subdev *sd)
i2c_unregister_device(client);
 }
 
-void v4l2_i2c_subdev_set_name(struct v4l2_subdev *sd, struct i2c_client 
*client,
+void v4l2_i2c_subdev_set_name(struct v4l2_subdev *sd,
+ struct i2c_client *client,
  const char *devname, const char *postfix)
 {
if (!devname)
@@ -42,7 +43,7 @@ void v4l2_i2c_subdev_set_name(struct v4l2_subdev *sd, struct 
i2c_client *client,
 EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_set_name);
 
 void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct i2c_client *client,
-   const struct v4l2_subdev_ops *ops)
+ const struct v4l2_subdev_ops *ops)
 {
v4l2_subdev_init(sd, ops);
sd->flags |= V4L2_SUBDEV_FL_IS_I2C;
@@ -57,9 +58,11 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct 
i2c_client *client,
 EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
 
 /* Load an i2c sub-device. */
-struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev,
-   struct i2c_adapter *adapter, struct i2c_board_info *info,
-   const unsigned short *probe_addrs)
+struct v4l2_subdev
+*v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev,
+  struct i2c_adapter *adapter,
+  struct i2c_board_info *info,
+  const unsigned short *probe_addrs)
 {
struct v4l2_subdev *sd = NULL;
struct i2c_client *client;
@@ -76,14 +79,16 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct 
v4l2_device *v4l2_dev,
else
client = i2c_new_device(adapter, info);
 
-   /* Note: by loading the module first we are certain that c->driver
-  will be set if the driver was found. If the module was not loaded
-  first, then the i2c core tries to delay-load the module for us,
-  and then c->driver is still NULL until the module is finally
-  loaded. This delay-load mechanism doesn't work if other drivers
-  want to use the i2c device, so explicitly loading the module
-  is the best alternative. */
-   if (client == NULL || client->dev.driver == NULL)
+   /*
+* Note: by loading the module first we are certain that c->driver
+* will be set if the driver was found. If the module was not loaded
+* first, then the i2c core tries to delay-load the module for us,
+* and then c->driver is still NULL until the module is finally
+* loaded. This delay-load mechanism doesn't work if other drivers
+* want to use the i2c device, so explicitly loading the module
+* is the best alternative.
+*/
+   if (!client || !client->dev.driver)
goto error;
 
/* Lock the module so we can safely get the v4l2_subdev pointer */
@@ -91,35 +96,44 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct 
v4l2_device *v4l2_dev,
goto error;
sd = i2c_get_clientdata(client);
 
-   /* Register with the v4l2_device which increases the module's
-  use count as well. */
+   /*
+* Register with the v4l2_device which increases the module's
+* use count as well.
+*/
if (v4l2_device_register_subdev(v4l2_dev, sd))
sd = NULL;
/* Decrease the module use count to match the first try_module_get. */
module_put(client->dev.driver->owner);
 
 error:
-   /* If we have a client but no subdev, then something went wrong and
-  we must unregister the client. */
-   if (client && sd == NULL)
+   /*
+* If we have a client but no subdev, then something went wrong and
+* we must unregister the client.
+*/
+   if (client && !sd)
i2c_unregister_device(client);
return sd;
 }
 EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev_board);
 
 struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
-   struct i2c_adapter *adapter, const char *client_type,
-   u8 addr, const unsigned short *probe_addrs)
+   struct i2c_adapter *adapter,
+   const char *client_type,
+   u8 addr,
+

Re: [PATCH 6/7] media: don't do an unsigned int with a 31 bit shift

[Mauro Carvalho Chehab]

Em Fri, 23 Aug 2019 11:08:15 +0200
Marc Gonzalez  escreveu:

> On 22/08/2019 21:39, Mauro Carvalho Chehab wrote:
> 
> > [PATCH 6/7] media: don't do an unsigned int with a 31 bit shift  
> 
> s/unsigned int/signed int  ?
> 
> (See below as well.)
> 
> > Doing something like:
> > 
> > i32 foo = 1, bar;
> > 
> > bar = foo << 31;  
> 
> For my information, why did you split the expression over two lines,
> instead of just using 1 << 31 in the example above?
> (Most of the cases fixed involve a literal 1)
> 
> I.e. why didn't you just say "1 << 31 has undefined behavior" ?
> 
> Maybe patch subject can also be changed to "Don't use 1 << foo" ?
> 
> > has an undefined behavior in C, as warned by cppcheck, as we're
> > shifting a signed integer.  
> 
> Not quite right. Shifting a signed integer is well-defined in some cases.
> See paragraph 4 below. For example, 1 << 8 always resolves to 256.

I meant to say that, on a 32-bits arch, where a signed integer has
31 bits and we do a 31 bit shift, it will end touching the 32th bit,
with is an undefined behavior.

I'm changing the description to:

media: don't do a 31 bit shift on a signed int

On 32-bits archs, a signed integer has 31 bits plus on extra
bit for signal. Due to that, touching the 32th bit with something 
like:

int bar = 1 << 31;

has an undefined behavior in C on 32 bit architectures, as it
touches the signal bit. This is warned by cppcheck.

Instead, force the numbers to be unsigned, in order to solve this
issue.

I guess this makes it clearer.


> 
> 6.5.7 Bitwise shift operators
> 
> 1   Syntax
>  shift-expression:
>  additive-expression
>  shift-expression << additive-expression
>  shift-expression >> additive-expression
> 
> 2   Constraints
> Each of the operands shall have integer type.
> 
> 3   Semantics
> The integer promotions are performed on each of the operands. The type of 
> the result is
> that of the promoted left operand. If the value of the right operand is 
> negative or is
> greater than or equal to the width of the promoted left operand, the 
> behavior is undefined.

The problem is here: "greater than or equal to the width of the promoted left 
operand".
A 31 bit shift on a 31 bits value is undefined.

In the past, we got real issues like that at the code: gcc on x86 does the 
shift as
expected, so:

u32 a = 1 << 32;

it results in:

on i386:  a = 0
on arm:   a = 1

I've no idea how LLVM/clang implements this.

> 
> 4   The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits 
> are filled with
> zeros. If E1 has an unsigned type, the value of the result is E1 x 2^E2 , 
> reduced modulo
> one more than the maximum value representable in the result type. If E1 
> has a signed
> type and non-negative value, and E1 x 2^E2 is representable in the result 
> type, then that is
> the resulting value; otherwise, the behavior is undefined.
> 
> 5   The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an 
> unsigned type
> or if E1 has a signed type and a non-negative value, the value of the 
> result is the integral
> part of the quotient of E1 / 2^E2 . If E1 has a signed type and a 
> negative value, the
> resulting value is implementation-defined.
> 
> 
> > Instead, force the numbers to be unsigned, in order to solve this
> > issue.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/dvb-frontends/cx24123.c   |  2 +-
> >  drivers/media/pci/bt8xx/bttv-input.c|  4 ++--
> >  drivers/media/pci/cx18/cx18-ioctl.c |  2 +-
> >  drivers/media/pci/ivtv/ivtv-driver.c|  2 +-
> >  drivers/media/pci/ivtv/ivtv-ioctl.c |  4 ++--
> >  drivers/media/pci/solo6x10/solo6x10-gpio.c  |  6 +++---
> >  drivers/media/platform/exynos4-is/mipi-csis.c   |  6 +++---
> >  drivers/media/platform/fsl-viu.c|  2 +-
> >  drivers/media/platform/mx2_emmaprp.c|  2 +-
> >  drivers/media/platform/pxa_camera.c |  4 ++--
> >  drivers/media/platform/qcom/venus/core.c|  2 +-
> >  drivers/media/platform/s5p-jpeg/jpeg-regs.h | 10 +-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |  4 ++--
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  2 +-
> >  drivers/media/radio/radio-gemtek.c  |  2 +-

[PATCH v2 5/7] media: use the BIT() macro

[Mauro Carvalho Chehab]

As warned by cppcheck:

[drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed 
32-bit value by 31 bits is undefined behaviour
[drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed 
32-bit value by 31 bits is undefined behaviour
[drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed 
32-bit value by 31 bits is undefined behaviour
...
[drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed 
32-bit value by 31 bits is undefined behaviour

There are lots of places where we're doing 1 << 31. That's bad,
as, depending on the architecture, this has an undefined behavior.

The BIT() macro is already prepared to handle this, so, let's
just switch all "1 << number" macros by BIT(number) at the header files
with has 1 << 31.

Signed-off-by: Mauro Carvalho Chehab 
---

v2: 
  As suggested by Laurent:
 - Don't touch multi-bit masks
 - remove explicit casts

 drivers/media/pci/cobalt/cobalt-driver.h  |  63 +-
 drivers/media/pci/ivtv/ivtv-irq.h |  28 +-
 drivers/media/pci/mantis/mantis_reg.h | 152 ++---
 drivers/media/pci/solo6x10/solo6x10-regs.h| 286 -
 .../media/platform/am437x/am437x-vpfe_regs.h  |  26 +-
 .../media/platform/davinci/dm644x_ccdc_regs.h |  20 +-
 .../media/platform/exynos4-is/fimc-lite-reg.h |  80 +--
 drivers/media/platform/exynos4-is/fimc-reg.h  | 138 +++--
 drivers/media/platform/omap3isp/ispreg.h  | 580 +-
 drivers/media/platform/s3c-camif/camif-regs.h | 118 ++--
 drivers/media/platform/tegra-cec/tegra_cec.h  |  80 +--
 drivers/media/platform/ti-vpe/vpe_regs.h  |  94 +--
 drivers/media/platform/vsp1/vsp1_regs.h   | 224 +++
 drivers/media/platform/xilinx/xilinx-vip.h|  29 +-
 drivers/media/radio/wl128x/fmdrv_common.h |  88 +--
 drivers/staging/media/ipu3/ipu3-tables.h  |   4 +-
 16 files changed, 1011 insertions(+), 999 deletions(-)

diff --git a/drivers/media/pci/cobalt/cobalt-driver.h 
b/drivers/media/pci/cobalt/cobalt-driver.h
index 429bee4ef79c..bca68572b324 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.h
+++ b/drivers/media/pci/cobalt/cobalt-driver.h
@@ -11,6 +11,7 @@
 #ifndef COBALT_DRIVER_H
 #define COBALT_DRIVER_H
 
+#include 
 #include 
 #include 
 #include 
@@ -61,37 +62,37 @@
 #define COBALT_CLK 5000
 
 /* System status register */
-#define COBALT_SYSSTAT_DIP0_MSK(1 << 0)
-#define COBALT_SYSSTAT_DIP1_MSK(1 << 1)
-#define COBALT_SYSSTAT_HSMA_PRSNTN_MSK (1 << 2)
-#define COBALT_SYSSTAT_FLASH_RDYBSYN_MSK   (1 << 3)
-#define COBALT_SYSSTAT_VI0_5V_MSK  (1 << 4)
-#define COBALT_SYSSTAT_VI0_INT1_MSK(1 << 5)
-#define COBALT_SYSSTAT_VI0_INT2_MSK(1 << 6)
-#define COBALT_SYSSTAT_VI0_LOST_DATA_MSK   (1 << 7)
-#define COBALT_SYSSTAT_VI1_5V_MSK  (1 << 8)
-#define COBALT_SYSSTAT_VI1_INT1_MSK(1 << 9)
-#define COBALT_SYSSTAT_VI1_INT2_MSK(1 << 10)
-#define COBALT_SYSSTAT_VI1_LOST_DATA_MSK   (1 << 11)
-#define COBALT_SYSSTAT_VI2_5V_MSK  (1 << 12)
-#define COBALT_SYSSTAT_VI2_INT1_MSK(1 << 13)
-#define COBALT_SYSSTAT_VI2_INT2_MSK(1 << 14)
-#define COBALT_SYSSTAT_VI2_LOST_DATA_MSK   (1 << 15)
-#define COBALT_SYSSTAT_VI3_5V_MSK  (1 << 16)
-#define COBALT_SYSSTAT_VI3_INT1_MSK(1 << 17)
-#define COBALT_SYSSTAT_VI3_INT2_MSK(1 << 18)
-#define COBALT_SYSSTAT_VI3_LOST_DATA_MSK   (1 << 19)
-#define COBALT_SYSSTAT_VIHSMA_5V_MSK   (1 << 20)
-#define COBALT_SYSSTAT_VIHSMA_INT1_MSK (1 << 21)
-#define COBALT_SYSSTAT_VIHSMA_INT2_MSK (1 << 22)
-#define COBALT_SYSSTAT_VIHSMA_LOST_DATA_MSK(1 << 23)
-#define COBALT_SYSSTAT_VOHSMA_INT1_MSK (1 << 24)
-#define COBALT_SYSSTAT_VOHSMA_PLL_LOCKED_MSK   (1 << 25)
-#define COBALT_SYSSTAT_VOHSMA_LOST_DATA_MSK(1 << 26)
-#define COBALT_SYSSTAT_AUD_PLL_LOCKED_MSK  (1 << 28)
-#define COBALT_SYSSTAT_AUD_IN_LOST_DATA_MSK(1 << 29)
-#define COBALT_SYSSTAT_AUD_OUT_LOST_DATA_MSK   (1 << 30)
-#define COBALT_SYSSTAT_PCIE_SMBCLK_MSK (1 << 31)
+#define COBALT_SYSSTAT_DIP0_MSKBIT(0)
+#define COBALT_SYSSTAT_DIP1_MSKBIT(1)
+#define COBALT_SYSSTAT_HSMA_PRSNTN_MSK BIT(2)
+#define COBALT_SYSSTAT_FLASH_RDYBSYN_MSK   BIT(3)
+#define COBALT_SYSSTAT_VI0_5V_MSK  BIT(4)
+#define COBALT_SYSSTAT_VI0_INT1_MSKBIT(5)
+#define COBALT_SYSSTAT_VI0_INT2_MSKBIT(6)
+#define COBALT_SYSSTAT_VI0_LOST_DATA_MSK   BIT(7)
+#define COBALT_SYSSTAT_VI1_5V_MSK  BIT(8)
+#define COBALT_SYSSTAT_VI1_INT1_MSK   

Re: [PATCH 7/7] media: ngene: don't try to memcpy from NULL

[Mauro Carvalho Chehab]

Em Thu, 22 Aug 2019 16:39:34 -0300
Mauro Carvalho Chehab  escreveu:

> [drivers/media/pci/ngene/ngene-i2c.c:122] -> 
> [drivers/media/pci/ngene/ngene-i2c.c:39]: (error) Null pointer dereference: 
> out
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/pci/ngene/ngene-i2c.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/pci/ngene/ngene-i2c.c 
> b/drivers/media/pci/ngene/ngene-i2c.c
> index 2e9e9774dc6f..bfdb7286f6f0 100644
> --- a/drivers/media/pci/ngene/ngene-i2c.c
> +++ b/drivers/media/pci/ngene/ngene-i2c.c
> @@ -36,7 +36,10 @@ static int ngene_command_i2c_read(struct ngene *dev, u8 
> adr,
>   com.cmd.hdr.Opcode = CMD_I2C_READ;
>   com.cmd.hdr.Length = outlen + 3;
>   com.cmd.I2CRead.Device = adr << 1;
> - memcpy(com.cmd.I2CRead.Data, out, outlen);
> +
> + if (out)
> + memcpy(com.cmd.I2CRead.Data, out, outlen);
> +

Hmm... I actually forgot to drop this one from this series, as I guess it
is safe to do:

memcpy(out, NULL, 0);

>   com.cmd.I2CRead.Data[outlen] = inlen;
>   com.cmd.I2CRead.Data[outlen + 1] = 0;
>   com.in_len = outlen + 3;



Thanks,
Mauro

[PATCH 1/7] media: remove include stdarg.h from some drivers

[Mauro Carvalho Chehab]

It doesn't make any sense to have gcc's stdarg.h included
inside the Linux Kernel.

Get rid of those includes.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/cx18/cx18-mailbox.c | 2 +-
 drivers/media/pci/ivtv/ivtv-mailbox.c | 2 --
 drivers/media/pci/ttpci/av7110_hw.c   | 1 -
 drivers/media/radio/radio-trust.c | 1 -
 4 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-mailbox.c 
b/drivers/media/pci/cx18/cx18-mailbox.c
index 967ae2939099..162480ec68ca 100644
--- a/drivers/media/pci/cx18/cx18-mailbox.c
+++ b/drivers/media/pci/cx18/cx18-mailbox.c
@@ -6,7 +6,7 @@
  *  Copyright (C) 2008  Andy Walls 
  */
 
-#include 
+#include 
 
 #include "cx18-driver.h"
 #include "cx18-io.h"
diff --git a/drivers/media/pci/ivtv/ivtv-mailbox.c 
b/drivers/media/pci/ivtv/ivtv-mailbox.c
index 8393675c3f46..d3fdaaa903f1 100644
--- a/drivers/media/pci/ivtv/ivtv-mailbox.c
+++ b/drivers/media/pci/ivtv/ivtv-mailbox.c
@@ -10,8 +10,6 @@
 #include "ivtv-driver.h"
 #include "ivtv-mailbox.h"
 
-#include 
-
 /* Firmware mailbox flags*/
 #define IVTV_MBOX_FIRMWARE_DONE 0x0004
 #define IVTV_MBOX_DRIVER_DONE   0x0002
diff --git a/drivers/media/pci/ttpci/av7110_hw.c 
b/drivers/media/pci/ttpci/av7110_hw.c
index 8c2442a11f07..e8a8ec5405e2 100644
--- a/drivers/media/pci/ttpci/av7110_hw.c
+++ b/drivers/media/pci/ttpci/av7110_hw.c
@@ -14,7 +14,6 @@
 /* for debugging ARM communication: */
 //#define COM_DEBUG
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/radio/radio-trust.c 
b/drivers/media/radio/radio-trust.c
index 2fc009509c7c..dfb8b62f0e2b 100644
--- a/drivers/media/radio/radio-trust.c
+++ b/drivers/media/radio/radio-trust.c
@@ -16,7 +16,6 @@
  * Converted to V4L2 API by Mauro Carvalho Chehab 
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
2.21.0

[PATCH 7/7] media: ngene: don't try to memcpy from NULL

[Mauro Carvalho Chehab]

[drivers/media/pci/ngene/ngene-i2c.c:122] -> 
[drivers/media/pci/ngene/ngene-i2c.c:39]: (error) Null pointer dereference: out

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/ngene/ngene-i2c.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/ngene/ngene-i2c.c 
b/drivers/media/pci/ngene/ngene-i2c.c
index 2e9e9774dc6f..bfdb7286f6f0 100644
--- a/drivers/media/pci/ngene/ngene-i2c.c
+++ b/drivers/media/pci/ngene/ngene-i2c.c
@@ -36,7 +36,10 @@ static int ngene_command_i2c_read(struct ngene *dev, u8 adr,
com.cmd.hdr.Opcode = CMD_I2C_READ;
com.cmd.hdr.Length = outlen + 3;
com.cmd.I2CRead.Device = adr << 1;
-   memcpy(com.cmd.I2CRead.Data, out, outlen);
+
+   if (out)
+   memcpy(com.cmd.I2CRead.Data, out, outlen);
+
com.cmd.I2CRead.Data[outlen] = inlen;
com.cmd.I2CRead.Data[outlen + 1] = 0;
com.in_len = outlen + 3;
-- 
2.21.0

[PATCH 3/7] media: aspeed-video: address a protential usage of an unit var

[Mauro Carvalho Chehab]

While this might not occur in practice, if the device is doing
the right thing, it would be teoretically be possible to have
both hsync_counter and vsync_counter negatives.

If this ever happen, ctrl will be undefined, but the driver
will still call:

aspeed_video_update(video, VE_CTRL, 0, ctrl);

Change the code to prevent this to happen.

This was warned by cppcheck:

[drivers/media/platform/aspeed-video.c:653]: (error) Uninitialized 
variable: ctrl

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/aspeed-video.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/aspeed-video.c 
b/drivers/media/platform/aspeed-video.c
index f899ac3b4a61..4ef37cfc8446 100644
--- a/drivers/media/platform/aspeed-video.c
+++ b/drivers/media/platform/aspeed-video.c
@@ -630,7 +630,7 @@ static void aspeed_video_check_and_set_polarity(struct 
aspeed_video *video)
}
 
if (hsync_counter < 0 || vsync_counter < 0) {
-   u32 ctrl;
+   u32 ctrl = 0;
 
if (hsync_counter < 0) {
ctrl = VE_CTRL_HSYNC_POL;
@@ -650,7 +650,8 @@ static void aspeed_video_check_and_set_polarity(struct 
aspeed_video *video)
V4L2_DV_VSYNC_POS_POL;
}
 
-   aspeed_video_update(video, VE_CTRL, 0, ctrl);
+   if (ctrl)
+   aspeed_video_update(video, VE_CTRL, 0, ctrl);
}
 }
 
-- 
2.21.0

[PATCH 2/7] media: vicodec: make life easier for static analyzers

[Mauro Carvalho Chehab]

cppcheck incorrectly produces an error here:
[drivers/media/platform/vicodec/vicodec-core.c:1677]: (error) Pointer 
addition with NULL pointer.

While this is actually a false positive, it doesn't hurt to
reorder the checks to make the code simpler, handling first
the error patch, where no color or alpha components are there.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/vicodec/vicodec-core.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vicodec/vicodec-core.c 
b/drivers/media/platform/vicodec/vicodec-core.c
index 5152f44bcc0a..0ee143ae0f6b 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -1664,19 +1664,22 @@ static int vicodec_start_streaming(struct vb2_queue *q,
kvfree(state->compressed_frame);
state->compressed_frame = new_comp_frame;
 
-   if (info->components_num >= 3) {
-   state->ref_frame.cb = state->ref_frame.luma + size;
-   state->ref_frame.cr = state->ref_frame.cb + size / chroma_div;
-   } else {
+   if (info->components_num < 3) {
state->ref_frame.cb = NULL;
state->ref_frame.cr = NULL;
+   state->ref_frame.alpha = NULL;
+   return 0;
}
 
+   state->ref_frame.cb = state->ref_frame.luma + size;
+   state->ref_frame.cr = state->ref_frame.cb + size / chroma_div;
+
if (info->components_num == 4)
state->ref_frame.alpha =
state->ref_frame.cr + size / chroma_div;
else
state->ref_frame.alpha = NULL;
+
return 0;
 }
 
-- 
2.21.0

[PATCH 6/7] media: don't do an unsigned int with a 31 bit shift

[Mauro Carvalho Chehab]

Doing something like:

i32 foo = 1, bar;

bar = foo << 31;

has an undefined behavior in C, as warned by cppcheck, as we're
shifting a signed integer.

Instead, force the numbers to be unsigned, in order to solve this
issue.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cx24123.c   |  2 +-
 drivers/media/pci/bt8xx/bttv-input.c|  4 ++--
 drivers/media/pci/cx18/cx18-ioctl.c |  2 +-
 drivers/media/pci/ivtv/ivtv-driver.c|  2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c |  4 ++--
 drivers/media/pci/solo6x10/solo6x10-gpio.c  |  6 +++---
 drivers/media/platform/exynos4-is/mipi-csis.c   |  6 +++---
 drivers/media/platform/fsl-viu.c|  2 +-
 drivers/media/platform/mx2_emmaprp.c|  2 +-
 drivers/media/platform/pxa_camera.c |  4 ++--
 drivers/media/platform/qcom/venus/core.c|  2 +-
 drivers/media/platform/s5p-jpeg/jpeg-regs.h | 10 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |  4 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  2 +-
 drivers/media/radio/radio-gemtek.c  |  2 +-
 drivers/media/usb/dvb-usb-v2/gl861.c|  2 +-
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 14 +++---
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c|  4 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c|  2 +-
 19 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/media/dvb-frontends/cx24123.c 
b/drivers/media/dvb-frontends/cx24123.c
index ac519c3eff18..3d84ee17e54c 100644
--- a/drivers/media/dvb-frontends/cx24123.c
+++ b/drivers/media/dvb-frontends/cx24123.c
@@ -431,7 +431,7 @@ static u32 cx24123_int_log2(u32 a, u32 b)
u32 div = a / b;
if (a % b >= b / 2)
++div;
-   if (div < (1 << 31)) {
+   if (div < (1UL << 31)) {
for (exp = 1; div > exp; nearest++)
exp += exp;
}
diff --git a/drivers/media/pci/bt8xx/bttv-input.c 
b/drivers/media/pci/bt8xx/bttv-input.c
index 9adfac4d5187..492bc85c2700 100644
--- a/drivers/media/pci/bt8xx/bttv-input.c
+++ b/drivers/media/pci/bt8xx/bttv-input.c
@@ -84,7 +84,7 @@ static void ir_enltv_handle_key(struct bttv *btv)
data = ir_extract_bits(gpio, ir->mask_keycode);
 
/* Check if it is keyup */
-   keyup = (gpio & ir->mask_keyup) ? 1 << 31 : 0;
+   keyup = (gpio & ir->mask_keyup) ? 1UL << 31 : 0;
 
if ((ir->last_gpio & 0x7f) != data) {
dprintk("gpio=0x%x code=%d | %s\n",
@@ -95,7 +95,7 @@ static void ir_enltv_handle_key(struct bttv *btv)
if (keyup)
rc_keyup(ir->dev);
} else {
-   if ((ir->last_gpio & 1 << 31) == keyup)
+   if ((ir->last_gpio & 1UL << 31) == keyup)
return;
 
dprintk("(cnt) gpio=0x%x code=%d | %s\n",
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c 
b/drivers/media/pci/cx18/cx18-ioctl.c
index d9ffc9c359ca..85f3e7307538 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -78,7 +78,7 @@ static u16 select_service_from_set(int field, int line, u16 
set, int is_pal)
return 0;
}
for (i = 0; i < 32; i++) {
-   if ((1 << i) & set)
+   if (BIT(i) & set)
return 1 << i;
}
return 0;
diff --git a/drivers/media/pci/ivtv/ivtv-driver.c 
b/drivers/media/pci/ivtv/ivtv-driver.c
index dd727098daf4..3f3f40ea890b 100644
--- a/drivers/media/pci/ivtv/ivtv-driver.c
+++ b/drivers/media/pci/ivtv/ivtv-driver.c
@@ -910,7 +910,7 @@ static void ivtv_load_and_init_modules(struct ivtv *itv)
 
/* check which i2c devices are actually found */
for (i = 0; i < 32; i++) {
-   u32 device = 1 << i;
+   u32 device = BIT(i);
 
if (!(device & hw))
continue;
diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c 
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index 5595f6a274e7..137853944e46 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -73,8 +73,8 @@ static u16 select_service_from_set(int field, int line, u16 
set, int is_pal)
return 0;
}
for (i = 0; i < 32; i++) {
-   if ((1 << i) & set)
-   return 1 << i;
+   if (BIT(i) & set)
+   return BIT(i);
}
return 0;
 }
diff --git a/drivers/media/pci/solo6x10/solo6x10-gpio.c 
b/drivers/media/pci/solo6x10/solo6x10-gpio.c
index 5caeca8b5dd0..526d67cf9942 100644
--- a/drivers/media/pci/solo6x10/solo6x10-gpio.c
+++ b/drivers/media/pci/solo6x10/solo6x10-gpio.c
@@ -39,13 +39,13 @@ stat

[PATCH 4/7] media: ov9650: add a sanity check

[Mauro Carvalho Chehab]

As pointed by cppcheck:

[drivers/media/i2c/ov9650.c:706]: (error) Shifting by a negative value 
is undefined behaviour
[drivers/media/i2c/ov9650.c:707]: (error) Shifting by a negative value 
is undefined behaviour
[drivers/media/i2c/ov9650.c:721]: (error) Shifting by a negative value 
is undefined behaviour

Prevent mangling with gains with invalid values

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

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 8b56011446a9..cb49fda902fd 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -703,6 +703,11 @@ static int ov965x_set_gain(struct ov965x *ov965x, int 
auto_gain)
for (m = 6; m >= 0; m--)
if (gain >= (1 << m) * 16)
break;
+
+   /* Sanity check: don't adjust the gain with a negative val */
+   if (m < 0)
+   return -EINVAL;
+
rgain = (gain - ((1 << m) * 16)) / (1 << m);
rgain |= (((1 << m) - 1) << 4);
 
-- 
2.21.0

Re: [GIT PULL FOR v5.4] More DVB/RC changes

[Mauro Carvalho Chehab]

Em Wed, 21 Aug 2019 14:59:05 -0300
Mauro Carvalho Chehab  escreveu:

> Em Wed, 21 Aug 2019 17:43:27 +
> Jenkins  escreveu:
> 
> > From: buil...@linuxtv.org
> > 
> > Pull request: https://patchwork.linuxtv.org/patch/58337/
> > Build log: https://builder.linuxtv.org/job/patchwork/12664/
> > Build time: 00:00:00
> > Link: 
> > https://lore.kernel.org/linux-media/20190821130434.gh4drkm6tiawz...@gofer.mess.org
> > 
> > gpg: Signature made Wed 21 Aug 2019 12:58:58 PM UTC
> > gpg:using RSA key A624251A26084A9ED9E4C8B6425F639D3960FA9E
> > gpg:issuer "s...@mess.org"
> > gpg: Good signature from "Sean Young " [unknown]
> > gpg: WARNING: This key is not certified with a trusted signature!
> > gpg:  There is no indication that the signature belongs to the 
> > owner.
> > Primary key fingerprint: A624 251A 2608 4A9E D9E4  C8B6 425F 639D 3960 FA9E
> > 
> > 
> > Build aborted due to a fatal error:
> > FAILED: patch patch 
> > patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch 
> > doesn't apply:
> > Applying patch 
> > patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch
> > patching file 
> > Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> > patching file Documentation/devicetree/bindings/media/sunxi-ir.txt
> > Hunk #1 FAILED at 1.
> > Not deleting file Documentation/devicetree/bindings/media/sunxi-ir.txt as 
> > content differs from patch
> > 1 out of 1 hunk FAILED -- rejects in file 
> > Documentation/devicetree/bindings/media/sunxi-ir.txt
> > Patch 
> > patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch 
> > does not apply (enforce with -f)  
> 
> Errors are now appearing also at the Jenkins log. Will rebuild again after
> applying the previous IR PR, and see if this will pass now.

You're right: the script was not properly updating the work branch.

Should be fixed now. Asking a new build.


Thanks,
Mauro

Re: [GIT PULL FOR v5.4] More DVB/RC changes

[Mauro Carvalho Chehab]

Em Wed, 21 Aug 2019 17:43:27 +
Jenkins  escreveu:

> From: buil...@linuxtv.org
> 
> Pull request: https://patchwork.linuxtv.org/patch/58337/
> Build log: https://builder.linuxtv.org/job/patchwork/12664/
> Build time: 00:00:00
> Link: 
> https://lore.kernel.org/linux-media/20190821130434.gh4drkm6tiawz...@gofer.mess.org
> 
> gpg: Signature made Wed 21 Aug 2019 12:58:58 PM UTC
> gpg:using RSA key A624251A26084A9ED9E4C8B6425F639D3960FA9E
> gpg:issuer "s...@mess.org"
> gpg: Good signature from "Sean Young " [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> Primary key fingerprint: A624 251A 2608 4A9E D9E4  C8B6 425F 639D 3960 FA9E
> 
> 
> Build aborted due to a fatal error:
> FAILED: patch patch 
> patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch 
> doesn't apply:
> Applying patch 
> patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch
> patching file 
> Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> patching file Documentation/devicetree/bindings/media/sunxi-ir.txt
> Hunk #1 FAILED at 1.
> Not deleting file Documentation/devicetree/bindings/media/sunxi-ir.txt as 
> content differs from patch
> 1 out of 1 hunk FAILED -- rejects in file 
> Documentation/devicetree/bindings/media/sunxi-ir.txt
> Patch patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch 
> does not apply (enforce with -f)

Errors are now appearing also at the Jenkins log. Will rebuild again after
applying the previous IR PR, and see if this will pass now.


Thanks,
Mauro

Re: [GIT PULL FOR v5.4] More DVB/RC changes

[Mauro Carvalho Chehab]

Em Wed, 21 Aug 2019 14:28:16 +0100
Sean Young  escreveu:

> On Wed, Aug 21, 2019 at 01:16:59PM +, Jenkins wrote:
> > From: buil...@linuxtv.org
> > 
> > Pull request: https://patchwork.linuxtv.org/patch/58337/
> > Build log: https://builder.linuxtv.org/job/patchwork/12637/
> > Build time: 00:00:00
> > Link: 
> > https://lore.kernel.org/linux-media/20190821130434.gh4drkm6tiawz...@gofer.mess.org
> > 
> > FAILED: patch patch 
> > patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch 
> > doesn't apply:
> > Applying patch 
> > patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch
> > patching file 
> > Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> > patching file Documentation/devicetree/bindings/media/sunxi-ir.txt
> > Hunk #1 FAILED at 1.
> > Not deleting file Documentation/devicetree/bindings/media/sunxi-ir.txt as 
> > content differs from patch
> > 1 out of 1 hunk FAILED -- rejects in file 
> > Documentation/devicetree/bindings/media/sunxi-ir.txt
> > Patch 
> > patches/0009-dt-bindings-media-Convert-Allwinner-A10-IR-to-a-sche.patch 
> > does not apply (enforce with -f)  
> 
> This output makes no sense: this is branched off current media_tree
> master:
> d4e0f82ac840 (linuxtv/master) media: pixfmt-compressed.rst: improve 
> H264/HEVC/MPEG1+2/VP8+9 documentation

If this one depends on the previous PR, it will fail, as it applies just
the new the patches on this PR against linuxtv/master (and not after any 
preceding pull request or branch).

> Also -- and more importantly -- the build log linked above show no such error
> and ends with success.

Error paths are always less tested... There were some prints missing to the
builder output, when it aborts due to an error like that.

Just added it. I may force it to process the last two pull requests, in
order to see if the output is more coherent now.

Thanks,
Mauro

Re: [ANN] Topics for a media summit in Lyon in October

[Mauro Carvalho Chehab]

Em Fri, 16 Aug 2019 10:06:30 +0200
Hans Verkuil  escreveu:

> Rather then discussing topics for a meeting under the subject 'Lisbon'
> let's start a new thread referring to the right place :-)
> 
> I will try to organize a room, either during the ELCE or (if that doesn't
> work) perhaps on the Thursday afterwards. If that's going to be a problem
> for someone, please let me know.
> 
> I do need to know how many people I can expect. I have the following
> confirmed attendees (and please reply if you are not listed!):

I'm not planning to go to ELCE this year.

Regards,
Mauro

> 
> Alexandre Courbot 
> Tomasz Figa 
> Jacopo Mondi 
> Laurent Pinchart 
> Hans Verkuil 
> 
> I know there were more who mentioned on irc that they would attend,
> but it is easier to keep track if I have it in an email.
> 
> Topics posted under the previous thread:
> 
> Tomasz:
> 
> I would want to discuss various v4l2_buffer improvements, e.g.
> - DMA-buf import with plane offsets,
> - unifying the buffer structs for M and non-M formats,
> - ability to import different FDs with offsets for non-M formats if the
> layout matches driver expectations, etc.
> 
> Besides that, I would be interested in the general idea on handling
> complex cameras in the Linux kernel in spite of the remaining V4L2
> limitations, e.g.
> - combinatorial explosion of /dev/video nodes,
> - significant ioctl overhead,
> - huge amount of historical legacy making the driver and userspace
> implementations overly difficult and prone to repetitive mistakes,
> - the above also limiting the flexibility of the API - formats, frame
> rates, etc. set using distinct APIs, not covered by Request API, with
> non-failure "negotiation hell", etc.
> - lack of fences, etc.
> 
> Jacopo:
> 
> Apart from discussing libcamera and hope we could kickstart a review of
> its API, I would like to re-start discussing multiplexed stream support,
> but that would require Sakari to be there, something I'm not certain
> about. Sakari?
> 
> Alexandre:
> 
> If Collabora/Bootlin is there, I'd certainly want to discuss stateless
> codecs, in particular m2m codec helpers and finalize the specification
> in general.
> 
> Regards,
> 
>   Hans



Thanks,
Mauro

Re: [PATCH] videobuf2-core: avoid buffer operations while in stop_streaming

[Mauro Carvalho Chehab]

Em Thu, 15 Aug 2019 14:28:02 +0200
Hans Verkuil  escreveu:

> The stop_streaming callback is called with the queue lock held.
> 
> But some drivers (vivid being one of them) need to stop a kernel thread
> in stop_streaming, and if that kernel thread takes the same queue lock,
> then stop_streaming may have to unlock the queue lock, stop the thread,
> and lock it again.

I suspect that this is the real issue here: stop_streaming should keep
the lock held until it finishes.

Why don't you just stop the thread just before calling VB2?

IMO, the best fix is to really fix vivid for it to do the right thing,
instead of adding another hack at the VB2 core just due to it.

Regards,
Mauro

> 
> However, if you do that, then you must ensure that no other operations
> can take place that can change the list of buffers queued to the driver,
> specifically: QBUF, STREAMON/OFF, REQBUFS, CREATE_BUFS.
> 
> __vb2_wait_for_done_vb() also checks for this and won't try to wait for
> new buffers if in_stop_streaming is true.
> 
> This issue caused this syzbot report:
> 
> https://syzkaller.appspot.com/bug?extid=736c3aae4af7b50d9683
> 
> Signed-off-by: Hans Verkuil 
> Reported-by: syzbot+736c3aae4af7b50d9...@syzkaller.appspotmail.com
> ---
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 4489744fbbd9..7c70bb9f6cb8 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -677,6 +677,11 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum 
> vb2_memory memory,
>   return -EBUSY;
>   }
> 
> + if (q->in_stop_streaming) {
> + dprintk(1, "reqbufs while the stream is being stopped\n");
> + return -EBUSY;
> + }
> +
>   if (q->waiting_in_dqbuf && *count) {
>   dprintk(1, "another dup()ped fd is waiting for a buffer\n");
>   return -EBUSY;
> @@ -811,6 +816,11 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
> vb2_memory memory,
>   unsigned plane_sizes[VB2_MAX_PLANES] = { };
>   int ret;
> 
> + if (q->in_stop_streaming) {
> + dprintk(1, "create_bufs while the stream is being stopped\n");
> + return -EBUSY;
> + }
> +
>   if (q->num_buffers == VB2_MAX_FRAME) {
>   dprintk(1, "maximum number of buffers already allocated\n");
>   return -ENOBUFS;
> @@ -1514,6 +1524,11 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
> index, void *pb,
>   struct vb2_buffer *vb;
>   int ret;
> 
> + if (q->in_stop_streaming) {
> + dprintk(1, "qbuf while the stream is being stopped\n");
> + return -EBUSY;
> + }
> +
>   if (q->error) {
>   dprintk(1, "fatal error occurred on queue\n");
>   return -EIO;
> @@ -1675,6 +1690,11 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q, 
> int nonblocking)
>   return -EBUSY;
>   }
> 
> + if (q->in_stop_streaming) {
> + dprintk(1, "the stream is being stopped, will not wait 
> for buffers\n");
> + return -EINVAL;
> + }
> +
>   if (!q->streaming) {
>   dprintk(1, "streaming off, will not wait for 
> buffers\n");
>   return -EINVAL;
> @@ -1716,7 +1736,7 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q, 
> int nonblocking)
>   dprintk(3, "will sleep waiting for buffers\n");
>   ret = wait_event_interruptible(q->done_wq,
>   !list_empty(&q->done_list) || !q->streaming ||
> - q->error);
> + q->in_stop_streaming || q->error);
> 
>   /*
>* We need to reevaluate both conditions again after reacquiring
> @@ -1866,12 +1886,18 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
>  {
>   unsigned int i;
> 
> + if (WARN_ON(q->in_stop_streaming))
> + return;
> +
>   /*
>* Tell driver to stop all transactions and release all queued
>* buffers.
>*/
> - if (q->start_streaming_called)
> + if (q->start_streaming_called) {
> + q->in_stop_streaming = 1;
>   call_void_qop(q, stop_streaming, q);
> + q->in_stop_streaming = 0;
> + }
> 
>   /*
>* If you see this warning, then the driver isn't cleaning up properly
> @@ -1975,6 +2001,11 @@ int vb2_core_streamon(struct vb2_queue *q, unsigned 
> int type)
>   return -EINVAL;
>   }
> 
> + if (q->in_stop_streaming) {
> + dprintk(1, "streamon while the stream is being stopped\n");
> + return -EBUSY;
> + }
> +
>   if (q->streaming) {
>   dprintk(3, "already streaming\n");
>   return 0;
> @@ -2026,6 +2057,11 @@ int vb2_core_streamoff(struct vb2_queue *q, unsigned 
> int type)

Re: [PATCH] dvb-usb-v2/gl861: fix wrong memcpy

[Mauro Carvalho Chehab]

Akihiro-san,

Em Fri, 16 Aug 2019 10:04:59 +0900
Akihiro TSUKADA  escreveu:

> > Does anyone have this hardware? This device must have been dead for about
> > a year, ever since commit b30cc07de8a9 was merged.  
> 
> I have one. (and I wrote the patch).
> Since I do not use it regularly and
> my app did not use the return value meaningfully,
> I have not noticed.

Could you please test the patch and check if the return results are
now consistent and that it won't break anything?

Also, please send us a Reviewed-by and/or Tested-by.


Thanks,
Mauro

[ANN] LinuxTV CI builder

[Mauro Carvalho Chehab]

Hi all,

Just want you to know about the latest news:

==
CI builder service for LinuxTV.org
==

Some of you may probably noticed already: thanks to OSU Open Source Lab[1], 
with is providing us a few VM instances, we now have a Jenkins server
running for the media subsystem. It can be accessed via this URL:

https://builder.linuxtv.org/

[1] https://osuosl.org/

It is doing periodic builds on the projects related to our work, specially
for the trees hosted at linuxtv.org. I didn't add a job for a few projects
with already have another CI instance running.

Right now, we have the following projects being built:

Userspace:
- camorama
- dtv-scan-tables
- edid-decode
- libcamera
- tvtime
- v4l-utils
- xawtv3
- xawtv4

Kernelspace:
- media_build 
  (against Debian 10.0 Kernel - v4.19);
- media_tree:
- allmodconfig: x86_64
- allyesconfig
- x86_64, i386, arm and arm64
- pull requests received by patchwork

Patchwork job
=

The patchwork job is currently meant to help me to test the pull requests
sent by a media core maintainer, doing part of my own testing workflow.

Right now, it always apply the pull request against the master branch.

This will help me to merge patches quickly, as I'm doing a quicker review
on patches sent by a media core maintainer that the script won't point
any issues.

For patchwork pull requests, it should always do a build and provide
an answer for the build, testing against bisect breakages, and running
checkpatch/sparse/smatch, patch per patch. Currently, it is sending replies
in about 10 minutes or so, but the build time actually depends on the 
number of patches and if they're touching core header files or not.

Email policy


Except for the patchwork, the other jobs should send an e-mail to the ML
(and to me) when:

- a build fails;
- a failed build got fixed.

It shouldn't be sending e-mails if everything is fine.

Other CI instances related to media
===

Please notice that we have some trees with have already a CI instance
running:

- ZBar:
  https://travis-ci.org/mchehab/zbar

- Kaffeine:
  https://travis-ci.org/mchehab/kaffeine

So, no need to duplicate the efforts by adding them also to our builder.

Please let me know if you find any issues.

Future Plans


I'm planning to add support in the future for the CI to also handle patch
series builds from patchwork (against the master branch), but, for that to
work,  it seems that we'll need to upgrade from patchwork's stable version
to  the latest one - or wait for the next patchwork stable version. 

I'm also planning to change the media_build logic in a way that it would
not download media driver tallbals that failed on the builder machine.

Any other suggestions?

Thanks,
Mauro

Re: [PATCHv2] omap-dma/omap_vout_vrfb: fix off-by-one fi value

[Mauro Carvalho Chehab]

Em Fri, 9 Aug 2019 10:32:40 +0200
Hans Verkuil  escreveu:

> The OMAP 4 TRM specifies that when using double-index addressing
> the address increases by the ES plus the EI value minus 1 within
> a frame. When a full frame is transferred, the address increases
> by the ES plus the frame index (FI) value minus 1.
> 
> The omap-dma code didn't account for the 'minus 1' in the FI register.
> To get correct addressing, add 1 to the src_icg value.
> 
> This was found when testing a hacked version of the media m2m-deinterlace.c
> driver on a Pandaboard.
> 
> The only other source that uses this feature is omap_vout_vrfb.c,
> and that adds a + 1 when setting the dst_icg. This is a workaround
> for the broken omap-dma.c behavior. So remove the workaround at the
> same time that we fix omap-dma.c.
> 
> I tested the omap_vout driver with a Beagle XM board to check that
> the '+ 1' in omap_vout_vrfb.c was indeed a workaround for the omap-dma
> bug.
> 
> Signed-off-by: Hans Verkuil 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Peter Ujfalusi 

Acked-by: Mauro Carvalho Chehab 

Regards,
Mauro

> ---
> Changes since v1: removed unnecessary parenthesis in omap_vout_vrfb.c
> as suggested by Laurent.
> 
> It makes sense that this patch goes in through the dmaengine subsystem
> (Mauro, can you Ack this patch?), but if preferred it can also go in
> through the media subsystem if we get an Ack from Vinod.
> ---
>  drivers/dma/ti/omap-dma.c| 4 ++--
>  drivers/media/platform/omap/omap_vout_vrfb.c | 3 +--
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
> index ba2489d4ea24..ba27802efcd0 100644
> --- a/drivers/dma/ti/omap-dma.c
> +++ b/drivers/dma/ti/omap-dma.c
> @@ -1234,7 +1234,7 @@ static struct dma_async_tx_descriptor 
> *omap_dma_prep_dma_interleaved(
>   if (src_icg) {
>   d->ccr |= CCR_SRC_AMODE_DBLIDX;
>   d->ei = 1;
> - d->fi = src_icg;
> + d->fi = src_icg + 1;
>   } else if (xt->src_inc) {
>   d->ccr |= CCR_SRC_AMODE_POSTINC;
>   d->fi = 0;
> @@ -1249,7 +1249,7 @@ static struct dma_async_tx_descriptor 
> *omap_dma_prep_dma_interleaved(
>   if (dst_icg) {
>   d->ccr |= CCR_DST_AMODE_DBLIDX;
>   sg->ei = 1;
> - sg->fi = dst_icg;
> + sg->fi = dst_icg + 1;
>   } else if (xt->dst_inc) {
>   d->ccr |= CCR_DST_AMODE_POSTINC;
>   sg->fi = 0;
> diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c 
> b/drivers/media/platform/omap/omap_vout_vrfb.c
> index 29e3f5da59c1..11ec048929e8 100644
> --- a/drivers/media/platform/omap/omap_vout_vrfb.c
> +++ b/drivers/media/platform/omap/omap_vout_vrfb.c
> @@ -253,8 +253,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
>*/
> 
>   pixsize = vout->bpp * vout->vrfb_bpp;
> - dst_icg = ((MAX_PIXELS_PER_LINE * pixsize) -
> -   (vout->pix.width * vout->bpp)) + 1;
> + dst_icg = MAX_PIXELS_PER_LINE * pixsize - vout->pix.width * vout->bpp;
> 
>   xt->src_start = vout->buf_phy_addr[vb->i];
>   xt->dst_start = vout->vrfb_context[vb->i].paddr[0];

Re: [ANN] Media summit in Lisbon at September

[Mauro Carvalho Chehab]

Em Thu, 1 Aug 2019 09:34:00 -0300
Mauro Carvalho Chehab  escreveu:

> Em Sun, 30 Jun 2019 13:44:04 -0300
> Mauro Carvalho Chehab  escreveu:
> 
> > Hi all,
> > 
> > We are organizing a media mini-summit in Lisbon to happen in September,
> > at the same week as the Linux Plumber Conference and the Kernel Summit.
> > 
> > We're still discussing the details about that.  
> 
> Gently reminder.
> 
> Right now, we have just one extra theme proposal from Sean:
> 
>   - possible dvb improvements.
> 
> If we don't have more proposals, we may end skipping the Media
> Summit this year.

It sounds that we won't have material to have a media summit this year.
So, let's cancel the media summit this year.

Regards,
Mauro

> 
> Regards,
> Mauro
> 
> 
> > 
> > In principle, it will be a free event for the ones registered
> > to Linux Plumbers Conference, happening between Sept 9-11.
> > They have a room available that we could use for the meeting on that
> > period of time, but we need to adjust to avoid conflicts with other
> > interesting micro-conferences that will happen in parallel (or
> > eventually do it outside that period, but that would be harder to
> > organize).
> > 
> > I'll let you know more details once we got it.
> > 
> > If you plan to attend, please let me know. It is open for all, but
> > we'll have a limited number of seats. So, the earliest we get the
> > number of interested people, the best.
> > 
> > -
> > 
> > At the last summit, we were supposed to do a Key Signing Party, but
> > we end not doing it, due to lack of time. I suggest we add this again,
> > but doing it earlier, in order to avoid getting out of time for doing
> > it.
> > 
> > From my side, I'd like to discuss what criteria we should adopt for
> > the code that comes via /drivers/staging/media, in particular:
> > how much time should we keep a code there that doesn't receive any
> > patch addressing the drivers real issues (excluding codepatch,
> > cleanups and kAPI changes)?
> > 
> > What other themes should be discussed?
> > 
> > Thanks,
> > Mauro  
> 
> 
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: [GIT PULL FOR v5.4] dvb/rc fixes, take #2

[Mauro Carvalho Chehab]

Em Thu, 1 Aug 2019 13:31:31 +0100
Sean Young  escreveu:

> Hi Mauro,
> 
> Here is another dvb/rc pull request. More to come.
> 
> Thanks
> Sean
> 
> The following changes since commit 4590c07462fbff4ecbfe1deec44431c16191bd19:
> 
>   media: via-camera: convert to the vb2 framework (2019-07-30 12:18:34 -0400)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/syoung/media_tree.git tags/v5.4b
> 
> for you to fetch changes up to 6eedaba3f5a2c733c211b4fea91a348f058bc025:
> 
>   dt-bindings: media: sunxi-ir: Add H6 compatible (2019-08-01 21:09:15 +0900)
> 
> 
> Arnd Bergmann (1):
>   media: don't drop front-end reference count for ->detach
> 
> Clément Péron (6):
>   dt-bindings: media: sunxi-ir: Add A31 compatible
>   media: rc: Introduce sunxi_ir_quirks
>   media: rc: sunxi: Add A31 compatible
>   media: rc: sunxi: Add RXSTA bits definition
>   dt-bindings: media: sunxi-ir: Add A64 compatible
>   dt-bindings: media: sunxi-ir: Add H6 compatible
> 
> Oliver Neukum (1):
>   media: iguanair: add sanity checks
> 
> Sean Young (2):
>   media: lirc: document BPF IR decoding
>   media: rc: describe rc protocols and their scancodes
> 
> Wolfram Sang (2):
>   media: ir-kbd-i2c: convert to i2c_new_dummy_device()

I don't think this one is a good idea, as it may cause troubles
during unbind time.

>   media: ir-kbd-i2c: remove outdated comments
> 
>  .../devicetree/bindings/media/sunxi-ir.txt |  11 +-
>  Documentation/media/uapi/rc/lirc-dev-intro.rst |  57 ++-
>  Documentation/media/uapi/rc/lirc-read.rst  |   3 +-
>  Documentation/media/uapi/rc/lirc-write.rst |   3 +-
>  Documentation/media/uapi/rc/rc-protos.rst  | 456 
> +
>  Documentation/media/uapi/rc/remote_controllers.rst |   1 +
>  drivers/media/dvb-core/dvb_frontend.c  |   4 +-
>  drivers/media/i2c/ir-kbd-i2c.c |  17 +-
>  drivers/media/rc/iguanair.c|  15 +-
>  drivers/media/rc/sunxi-cir.c   |  88 +++-
>  drivers/media/usb/dvb-usb/pctv452e.c   |   8 -
>  11 files changed, 597 insertions(+), 66 deletions(-)
>  create mode 100644 Documentation/media/uapi/rc/rc-protos.rst



Thanks,
Mauro

Re: [GIT PULL for v5.4] Venus updates - stateful decoder

[Mauro Carvalho Chehab]

Hi Stanimir,

Em Sat,  3 Aug 2019 11:58:07 +
Jenkins  escreveu:

> From: buil...@linuxtv.org
> 
> Pull request: https://patchwork.linuxtv.org/patch/57868/mbox/
> Build log: https://builder.linuxtv.org/job/patchwork/866/
> Build time: 00:04:24
> 
> Summary: 1 issues, being 0 build regressions
> 
> Error/warnings:
> 
> patches/0009-venus-make-decoder-compliant-with-stateful-codec-API.patch:31: 
> WARNING: please, no space before tabs
> patches/0009-venus-make-decoder-compliant-with-stateful-codec-API.patch:41: 
> CHECK: Please don't use multiple blank lines
> patches/0009-venus-make-decoder-compliant-with-stateful-codec-API.patch:139: 
> CHECK: Please don't use multiple blank lines
> 
> Error #256 when running ./scripts/checkpatch.pl --terse --mailback 
> --no-summary --strict 
> patches/0009-venus-make-decoder-compliant-with-stateful-codec-API.patch

Please fix the above warnings on your pull request.

Thanks,
Mauro

Re: [ANN] Media summit in Lisbon at September

[Mauro Carvalho Chehab]

Em Sun, 30 Jun 2019 13:44:04 -0300
Mauro Carvalho Chehab  escreveu:

> Hi all,
> 
> We are organizing a media mini-summit in Lisbon to happen in September,
> at the same week as the Linux Plumber Conference and the Kernel Summit.
> 
> We're still discussing the details about that.

Gently reminder.

Right now, we have just one extra theme proposal from Sean:

- possible dvb improvements.

If we don't have more proposals, we may end skipping the Media
Summit this year.

Regards,
Mauro


> 
> In principle, it will be a free event for the ones registered
> to Linux Plumbers Conference, happening between Sept 9-11.
> They have a room available that we could use for the meeting on that
> period of time, but we need to adjust to avoid conflicts with other
> interesting micro-conferences that will happen in parallel (or
> eventually do it outside that period, but that would be harder to
> organize).
> 
> I'll let you know more details once we got it.
> 
> If you plan to attend, please let me know. It is open for all, but
> we'll have a limited number of seats. So, the earliest we get the
> number of interested people, the best.
> 
> -
> 
> At the last summit, we were supposed to do a Key Signing Party, but
> we end not doing it, due to lack of time. I suggest we add this again,
> but doing it earlier, in order to avoid getting out of time for doing
> it.
> 
> From my side, I'd like to discuss what criteria we should adopt for
> the code that comes via /drivers/staging/media, in particular:
> how much time should we keep a code there that doesn't receive any
> patch addressing the drivers real issues (excluding codepatch,
> cleanups and kAPI changes)?
> 
> What other themes should be discussed?
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: [GIT PULL FOR v5.4] Fixes, via-camera, vivid

[Mauro Carvalho Chehab]

Em Tue, 30 Jul 2019 13:44:18 +0200
Hans Verkuil  escreveu:

> Small fixes, via-camera vb2 conversion (yeah!) and extended pixelformat
> support in v4l2-tpg/vivid. Patches for the corresponding v4l-utils support
> for these pixelformats is ready as well.
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit a8f910ec66583bfb61558c3f333195b3960d832d:
> 
>   media: v4l2-core: Cleanup Makefile (2019-07-25 12:28:28 -0400)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.4g
> 
> for you to fetch changes up to 1de3c46bf602d9edb34d19259af719824b11b24a:
> 
>   via-camera: convert to the vb2 framework (2019-07-30 13:10:33 +0200)

...

> gtk_ruiwang (1):
>   media: mtk-vcodec: Handle H264 error bitstreams

Applied all patches but this one. Author/SoB should have the author's
name, and not a random string.

Thanks,
Mauro

Re: [PATCH 2/2] media: Don't hide any menu if "ancillary drivers autoselect" is enabled

[Mauro Carvalho Chehab]

Em Fri, 26 Jul 2019 21:17:00 -0300
Ezequiel Garcia  escreveu:

> On Thu, 2019-07-25 at 23:09 -0300, Mauro Carvalho Chehab wrote:
> > Em Thu, 25 Jul 2019 20:55:13 -0300
> > Ezequiel Garcia  escreveu:
> >   
> > > On Thu, 2019-07-25 at 15:41 -0300, Mauro Carvalho Chehab wrote:  
> > > > Em Fri, 26 Jul 2019 01:29:58 +0800
> > > > Chen-Yu Tsai  escreveu:
> > > > 
> > > > > On Fri, Jul 26, 2019 at 1:06 AM Ezequiel Garcia 
> > > > >  wrote:
> > > > > > On Thu, 2019-07-25 at 12:57 -0300, Mauro Carvalho Chehab wrote: 
> > > > > >  
> > > > > > > Em Mon, 15 Jul 2019 18:23:16 -0300
> > > > > > > Ezequiel Garcia  escreveu:
> > > > > > >  
> > > > > > > > Many users have been complaining about not being able 
> > > > > > > > to find
> > > > > > > > certain menu options. One such example are camera sensor drivers
> > > > > > > > (e.g IMX219, OV5645, etc) which are common on embedded platforms
> > > > > > > > and not always ancillary devices.
> > > > > > > > 
> > > > > > > > The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related
> > > > > > > > to the fact that it uses the "visible" kbuild syntax to hide
> > > > > > > > entire group of drivers.
> > > > > > > > 
> > > > > > > > This is not obvious and, as explained above, not always desired.
> > > > > > > > 
> > > > > > > > To fix the problem, drop the "visible" and stop hiding any menu
> > > > > > > > options. Users skilled enough to configure their kernel are 
> > > > > > > > expected
> > > > > > > > to be skilled enough to know what (not) to configure anyway.
> > > > > > > > 
> > > > > > > > Signed-off-by: Ezequiel Garcia 
> > > > > > > > ---
> > > > > > > >  drivers/media/dvb-frontends/Kconfig | 1 -
> > > > > > > >  drivers/media/i2c/Kconfig   | 1 -
> > > > > > > >  drivers/media/spi/Kconfig   | 1 -
> > > > > > > >  drivers/media/tuners/Kconfig| 1 -
> > > > > > > >  4 files changed, 4 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/media/dvb-frontends/Kconfig 
> > > > > > > > b/drivers/media/dvb-frontends/Kconfig
> > > > > > > > index dc43749177df..2d1fea3bf546 100644
> > > > > > > > --- a/drivers/media/dvb-frontends/Kconfig
> > > > > > > > +++ b/drivers/media/dvb-frontends/Kconfig
> > > > > > > > @@ -1,5 +1,4 @@
> > > > > > > >  menu "Customise DVB Frontends"
> > > > > > > > -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || 
> > > > > > > > EXPERT
> > > > > > > > 
> > > > > > > >  comment "Multistandard (satellite) frontends"
> > > > > > > > depends on DVB_CORE
> > > > > > > > diff --git a/drivers/media/i2c/Kconfig 
> > > > > > > > b/drivers/media/i2c/Kconfig
> > > > > > > > index 79ce9ec6fc1b..475072bb67d6 100644
> > > > > > > > --- a/drivers/media/i2c/Kconfig
> > > > > > > > +++ b/drivers/media/i2c/Kconfig
> > > > > > > > @@ -23,7 +23,6 @@ config VIDEO_IR_I2C
> > > > > > > >  #
> > > > > > > > 
> > > > > > > >  menu "I2C Encoders, decoders, sensors and other helper chips"
> > > > > > > > -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || 
> > > > > > > > EXPERT  
> > > > > > > 
> > > > > > > Hmm... Hans picked this patch, but IMO it doesn't make sense
> > > > > > > for PC consumer people to see the hundreds of extra options
> > > > > > > that making those menus visible will produce.
> > > > > > > 
> > > > > > > This was added because in the past we had lots of issues with
> > > > > > > people desktop/laptop settings with all those

Re: [PATCH 2/2] media: Don't hide any menu if "ancillary drivers autoselect" is enabled

[Mauro Carvalho Chehab]

Em Thu, 25 Jul 2019 20:55:13 -0300
Ezequiel Garcia  escreveu:

> On Thu, 2019-07-25 at 15:41 -0300, Mauro Carvalho Chehab wrote:
> > Em Fri, 26 Jul 2019 01:29:58 +0800
> > Chen-Yu Tsai  escreveu:
> >   
> > > On Fri, Jul 26, 2019 at 1:06 AM Ezequiel Garcia  
> > > wrote:  
> > > > On Thu, 2019-07-25 at 12:57 -0300, Mauro Carvalho Chehab wrote:
> > > > > Em Mon, 15 Jul 2019 18:23:16 -0300
> > > > > Ezequiel Garcia  escreveu:
> > > > >
> > > > > > Many users have been complaining about not being able to find
> > > > > > certain menu options. One such example are camera sensor drivers
> > > > > > (e.g IMX219, OV5645, etc) which are common on embedded platforms
> > > > > > and not always ancillary devices.
> > > > > > 
> > > > > > The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related
> > > > > > to the fact that it uses the "visible" kbuild syntax to hide
> > > > > > entire group of drivers.
> > > > > > 
> > > > > > This is not obvious and, as explained above, not always desired.
> > > > > > 
> > > > > > To fix the problem, drop the "visible" and stop hiding any menu
> > > > > > options. Users skilled enough to configure their kernel are expected
> > > > > > to be skilled enough to know what (not) to configure anyway.
> > > > > > 
> > > > > > Signed-off-by: Ezequiel Garcia 
> > > > > > ---
> > > > > >  drivers/media/dvb-frontends/Kconfig | 1 -
> > > > > >  drivers/media/i2c/Kconfig   | 1 -
> > > > > >  drivers/media/spi/Kconfig   | 1 -
> > > > > >  drivers/media/tuners/Kconfig| 1 -
> > > > > >  4 files changed, 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/media/dvb-frontends/Kconfig 
> > > > > > b/drivers/media/dvb-frontends/Kconfig
> > > > > > index dc43749177df..2d1fea3bf546 100644
> > > > > > --- a/drivers/media/dvb-frontends/Kconfig
> > > > > > +++ b/drivers/media/dvb-frontends/Kconfig
> > > > > > @@ -1,5 +1,4 @@
> > > > > >  menu "Customise DVB Frontends"
> > > > > > -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
> > > > > > 
> > > > > >  comment "Multistandard (satellite) frontends"
> > > > > > depends on DVB_CORE
> > > > > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > > > > index 79ce9ec6fc1b..475072bb67d6 100644
> > > > > > --- a/drivers/media/i2c/Kconfig
> > > > > > +++ b/drivers/media/i2c/Kconfig
> > > > > > @@ -23,7 +23,6 @@ config VIDEO_IR_I2C
> > > > > >  #
> > > > > > 
> > > > > >  menu "I2C Encoders, decoders, sensors and other helper chips"
> > > > > > -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT   
> > > > > >  
> > > > > 
> > > > > Hmm... Hans picked this patch, but IMO it doesn't make sense
> > > > > for PC consumer people to see the hundreds of extra options
> > > > > that making those menus visible will produce.
> > > > > 
> > > > > This was added because in the past we had lots of issues with
> > > > > people desktop/laptop settings with all those things enabled.
> > > > > 
> > > > > In any case, if the desktop/laptop user is smart enough to
> > > > > go though it, he can simply disable MEDIA_SUBDRV_AUTOSELECT and
> > > > > manually select what he wants, so I really miss the point of
> > > > > making those stuff always visible.
> > > > > 
> > > > > Now, from this patch's comments, it seems that you want this
> > > > > to be visible if CONFIG_EMBEDDED. So, I won't complain if you
> > > > > replace the changes on this patch to:
> > > > > 
> > > > >   menu "foo"
> > > > >   visible if !MEDIA_SUBDRV_AUTOSELECT || !EMBEDDED || 
> > > > > COMPILE_TEST || EXPERT
> > > > > 
> > > > > In other words, for the normal guy that just wants to build the
> > > > > latest med

Re: [PATCH 2/2] media: Don't hide any menu if "ancillary drivers autoselect" is enabled

[Mauro Carvalho Chehab]

Em Thu, 25 Jul 2019 16:00:02 -0300
Helen Koike  escreveu:

> On 7/25/19 3:41 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 26 Jul 2019 01:29:58 +0800
> > Chen-Yu Tsai  escreveu:
> >   
> >> On Fri, Jul 26, 2019 at 1:06 AM Ezequiel Garcia  
> >> wrote:  
> >>>
> >>> On Thu, 2019-07-25 at 12:57 -0300, Mauro Carvalho Chehab wrote:
> >>>> Em Mon, 15 Jul 2019 18:23:16 -0300
> >>>> Ezequiel Garcia  escreveu:
> >>>>
> >>>>> Many users have been complaining about not being able to find
> >>>>> certain menu options. One such example are camera sensor drivers
> >>>>> (e.g IMX219, OV5645, etc) which are common on embedded platforms
> >>>>> and not always ancillary devices.
> >>>>>
> >>>>> The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related
> >>>>> to the fact that it uses the "visible" kbuild syntax to hide
> >>>>> entire group of drivers.
> >>>>>
> >>>>> This is not obvious and, as explained above, not always desired.
> >>>>>
> >>>>> To fix the problem, drop the "visible" and stop hiding any menu
> >>>>> options. Users skilled enough to configure their kernel are expected
> >>>>> to be skilled enough to know what (not) to configure anyway.
> >>>>>
> >>>>> Signed-off-by: Ezequiel Garcia 
> >>>>> ---
> >>>>>  drivers/media/dvb-frontends/Kconfig | 1 -
> >>>>>  drivers/media/i2c/Kconfig   | 1 -
> >>>>>  drivers/media/spi/Kconfig   | 1 -
> >>>>>  drivers/media/tuners/Kconfig| 1 -
> >>>>>  4 files changed, 4 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/media/dvb-frontends/Kconfig 
> >>>>> b/drivers/media/dvb-frontends/Kconfig
> >>>>> index dc43749177df..2d1fea3bf546 100644
> >>>>> --- a/drivers/media/dvb-frontends/Kconfig
> >>>>> +++ b/drivers/media/dvb-frontends/Kconfig
> >>>>> @@ -1,5 +1,4 @@
> >>>>>  menu "Customise DVB Frontends"
> >>>>> -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
> >>>>>
> >>>>>  comment "Multistandard (satellite) frontends"
> >>>>> depends on DVB_CORE
> >>>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> >>>>> index 79ce9ec6fc1b..475072bb67d6 100644
> >>>>> --- a/drivers/media/i2c/Kconfig
> >>>>> +++ b/drivers/media/i2c/Kconfig
> >>>>> @@ -23,7 +23,6 @@ config VIDEO_IR_I2C
> >>>>>  #
> >>>>>
> >>>>>  menu "I2C Encoders, decoders, sensors and other helper chips"
> >>>>> -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
> >>>>
> >>>> Hmm... Hans picked this patch, but IMO it doesn't make sense
> >>>> for PC consumer people to see the hundreds of extra options
> >>>> that making those menus visible will produce.
> >>>>
> >>>> This was added because in the past we had lots of issues with
> >>>> people desktop/laptop settings with all those things enabled.
> >>>>
> >>>> In any case, if the desktop/laptop user is smart enough to
> >>>> go though it, he can simply disable MEDIA_SUBDRV_AUTOSELECT and
> >>>> manually select what he wants, so I really miss the point of
> >>>> making those stuff always visible.
> >>>>
> >>>> Now, from this patch's comments, it seems that you want this
> >>>> to be visible if CONFIG_EMBEDDED. So, I won't complain if you
> >>>> replace the changes on this patch to:
> >>>>
> >>>>   menu "foo"
> >>>>   visible if !MEDIA_SUBDRV_AUTOSELECT || !EMBEDDED || 
> >>>> COMPILE_TEST || EXPERT
> >>>>
> >>>> In other words, for the normal guy that just wants to build the
> >>>> latest media stuff for his PC camera or TV device to work, he won't
> >>>> need to dig into hundreds of things that won't make any difference
> >>>> if he enables, except for making the Kernel bigger.
> >>>>
> >>>
> >>> Well, I thin

Re: [PATCH 2/2] media: Don't hide any menu if "ancillary drivers autoselect" is enabled

[Mauro Carvalho Chehab]

Em Fri, 26 Jul 2019 01:29:58 +0800
Chen-Yu Tsai  escreveu:

> On Fri, Jul 26, 2019 at 1:06 AM Ezequiel Garcia  
> wrote:
> >
> > On Thu, 2019-07-25 at 12:57 -0300, Mauro Carvalho Chehab wrote:  
> > > Em Mon, 15 Jul 2019 18:23:16 -0300
> > > Ezequiel Garcia  escreveu:
> > >  
> > > > Many users have been complaining about not being able to find
> > > > certain menu options. One such example are camera sensor drivers
> > > > (e.g IMX219, OV5645, etc) which are common on embedded platforms
> > > > and not always ancillary devices.
> > > >
> > > > The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related
> > > > to the fact that it uses the "visible" kbuild syntax to hide
> > > > entire group of drivers.
> > > >
> > > > This is not obvious and, as explained above, not always desired.
> > > >
> > > > To fix the problem, drop the "visible" and stop hiding any menu
> > > > options. Users skilled enough to configure their kernel are expected
> > > > to be skilled enough to know what (not) to configure anyway.
> > > >
> > > > Signed-off-by: Ezequiel Garcia 
> > > > ---
> > > >  drivers/media/dvb-frontends/Kconfig | 1 -
> > > >  drivers/media/i2c/Kconfig   | 1 -
> > > >  drivers/media/spi/Kconfig   | 1 -
> > > >  drivers/media/tuners/Kconfig| 1 -
> > > >  4 files changed, 4 deletions(-)
> > > >
> > > > diff --git a/drivers/media/dvb-frontends/Kconfig 
> > > > b/drivers/media/dvb-frontends/Kconfig
> > > > index dc43749177df..2d1fea3bf546 100644
> > > > --- a/drivers/media/dvb-frontends/Kconfig
> > > > +++ b/drivers/media/dvb-frontends/Kconfig
> > > > @@ -1,5 +1,4 @@
> > > >  menu "Customise DVB Frontends"
> > > > -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
> > > >
> > > >  comment "Multistandard (satellite) frontends"
> > > > depends on DVB_CORE
> > > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > > index 79ce9ec6fc1b..475072bb67d6 100644
> > > > --- a/drivers/media/i2c/Kconfig
> > > > +++ b/drivers/media/i2c/Kconfig
> > > > @@ -23,7 +23,6 @@ config VIDEO_IR_I2C
> > > >  #
> > > >
> > > >  menu "I2C Encoders, decoders, sensors and other helper chips"
> > > > -   visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT  
> > >
> > > Hmm... Hans picked this patch, but IMO it doesn't make sense
> > > for PC consumer people to see the hundreds of extra options
> > > that making those menus visible will produce.
> > >
> > > This was added because in the past we had lots of issues with
> > > people desktop/laptop settings with all those things enabled.
> > >
> > > In any case, if the desktop/laptop user is smart enough to
> > > go though it, he can simply disable MEDIA_SUBDRV_AUTOSELECT and
> > > manually select what he wants, so I really miss the point of
> > > making those stuff always visible.
> > >
> > > Now, from this patch's comments, it seems that you want this
> > > to be visible if CONFIG_EMBEDDED. So, I won't complain if you
> > > replace the changes on this patch to:
> > >
> > >   menu "foo"
> > >   visible if !MEDIA_SUBDRV_AUTOSELECT || !EMBEDDED || 
> > > COMPILE_TEST || EXPERT
> > >
> > > In other words, for the normal guy that just wants to build the
> > > latest media stuff for his PC camera or TV device to work, he won't
> > > need to dig into hundreds of things that won't make any difference
> > > if he enables, except for making the Kernel bigger.
> > >  
> >
> > Well, I think the real value of MEDIA_SUBDRV_AUTOSELECT is the 
> > autoselection,
> > not the hidden part. I'm really missing to see what hiding anything gives 
> > you.
> >
> > In other words, this option gets useful when driver authors select ancillary
> > drivers such as:
> >
> > config VIDEO_USBVISION
> > tristate "USB video devices based on Nogatech NT1003/1004/1005"
> > depends on I2C && VIDEO_V4L2
> > select VIDEO_TUNER
> > select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT
> >
> > What's so confusing about having these drive

Re: [PATCH 2/2] media: Don't hide any menu if "ancillary drivers autoselect" is enabled

[Mauro Carvalho Chehab]

Em Thu, 25 Jul 2019 14:05:58 -0300
Ezequiel Garcia  escreveu:

> On Thu, 2019-07-25 at 12:57 -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 15 Jul 2019 18:23:16 -0300
> > Ezequiel Garcia  escreveu:
> >   
> > > Many users have been complaining about not being able to find
> > > certain menu options. One such example are camera sensor drivers
> > > (e.g IMX219, OV5645, etc) which are common on embedded platforms
> > > and not always ancillary devices.
> > > 
> > > The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related
> > > to the fact that it uses the "visible" kbuild syntax to hide
> > > entire group of drivers.
> > > 
> > > This is not obvious and, as explained above, not always desired.
> > > 
> > > To fix the problem, drop the "visible" and stop hiding any menu
> > > options. Users skilled enough to configure their kernel are expected
> > > to be skilled enough to know what (not) to configure anyway.
> > > 
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > >  drivers/media/dvb-frontends/Kconfig | 1 -
> > >  drivers/media/i2c/Kconfig   | 1 -
> > >  drivers/media/spi/Kconfig   | 1 -
> > >  drivers/media/tuners/Kconfig| 1 -
> > >  4 files changed, 4 deletions(-)
> > > 
> > > diff --git a/drivers/media/dvb-frontends/Kconfig 
> > > b/drivers/media/dvb-frontends/Kconfig
> > > index dc43749177df..2d1fea3bf546 100644
> > > --- a/drivers/media/dvb-frontends/Kconfig
> > > +++ b/drivers/media/dvb-frontends/Kconfig
> > > @@ -1,5 +1,4 @@
> > >  menu "Customise DVB Frontends"
> > > - visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
> > >  
> > >  comment "Multistandard (satellite) frontends"
> > >   depends on DVB_CORE
> > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > index 79ce9ec6fc1b..475072bb67d6 100644
> > > --- a/drivers/media/i2c/Kconfig
> > > +++ b/drivers/media/i2c/Kconfig
> > > @@ -23,7 +23,6 @@ config VIDEO_IR_I2C
> > >  #
> > >  
> > >  menu "I2C Encoders, decoders, sensors and other helper chips"
> > > - visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT  
> > 
> > Hmm... Hans picked this patch, but IMO it doesn't make sense
> > for PC consumer people to see the hundreds of extra options
> > that making those menus visible will produce.
> > 
> > This was added because in the past we had lots of issues with
> > people desktop/laptop settings with all those things enabled.
> > 
> > In any case, if the desktop/laptop user is smart enough to
> > go though it, he can simply disable MEDIA_SUBDRV_AUTOSELECT and
> > manually select what he wants, so I really miss the point of
> > making those stuff always visible.
> > 
> > Now, from this patch's comments, it seems that you want this
> > to be visible if CONFIG_EMBEDDED. So, I won't complain if you
> > replace the changes on this patch to:
> > 
> > menu "foo"
> > visible if !MEDIA_SUBDRV_AUTOSELECT || !EMBEDDED || COMPILE_TEST || 
> > EXPERT
> > 
> > In other words, for the normal guy that just wants to build the
> > latest media stuff for his PC camera or TV device to work, he won't
> > need to dig into hundreds of things that won't make any difference
> > if he enables, except for making the Kernel bigger.
> >   
> 
> Well, I think the real value of MEDIA_SUBDRV_AUTOSELECT is the autoselection,
> not the hidden part. I'm really missing to see what hiding anything gives you.
> 
> In other words, this option gets useful when driver authors select ancillary
> drivers such as:
> 
> config VIDEO_USBVISION
> tristate "USB video devices based on Nogatech NT1003/1004/1005"
> depends on I2C && VIDEO_V4L2
> select VIDEO_TUNER
> select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT
> 
> What's so confusing about having these drivers visible? Compared to the
> rest of the zillion menu options, what's more confusing about seeing these?

There are not zillion of media menu options. We want to make as easy as
possible for people that, for instance, rebuilds the media subsystem
from:
https://git.linuxtv.org/media_build.git/

For them to be able to build the driver they need without need to
be a technical person that knows what SAA711X means, and why
it shouldn't select TVP5150 if he has a board supported by the USBVision
driver.

> Now, while I would agree with EMBEDDED, the problem with that is that
> many "embedded" platforms don't enable EMBEDDED. So, it's not that useful.

Well, so the problem is elsewhere, not on media.

> 
> Finally, let me give an example of why hiding the menus is so bad.
> Normally, to enable a symbol, we use the search tool.
> 
> Now, when MEDIA_SUBDRV_AUTOSELECT=y, the search tool will _not_ take you
> there and there's no indication why.

If the search tool is not capable of properly handling visible
and explain why a symbol can't be selected, it should be fixed.

Thanks,
Mauro

Re: [PATCH 2/6] media: v4l2-core: Module re-organization

[Mauro Carvalho Chehab]

Em Thu, 25 Jul 2019 13:41:34 -0300
Ezequiel Garcia  escreveu:

> On Thu, 2019-07-25 at 13:31 -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 15 Jul 2019 18:06:43 -0300
> > Ezequiel Garcia  escreveu:
> >   
> > > videodev.ko and v4l2-common.ko driver are built under
> > > the same conditions. Therefore, it doesn't make much sense
> > > to split them in two different modules.
> > > 
> > > Splitting v4l2-common to its own driver has done many
> > > years ago:
> > > 
> > >   commit a9254475bbfbed5f0596d952c6a3c9806e19dd0b
> > >   Author: Mauro Carvalho Chehab 
> > >   Date:   Tue Jan 29 18:32:35 2008 -0300
> > > 
> > >   V4L/DVB (7115): Fix bug #9833: regression when compiling V4L 
> > > without I2C
> > > 
> > > Back then, the subsystem organization was different.
> > > However, With the current organization, there is no issue
> > > compiling V4L2 with I2C as y/m/n.
> > > 
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > >  drivers/media/v4l2-core/Makefile | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/media/v4l2-core/Makefile 
> > > b/drivers/media/v4l2-core/Makefile
> > > index 4d42418e603e..8e2f52f7800b 100644
> > > --- a/drivers/media/v4l2-core/Makefile
> > > +++ b/drivers/media/v4l2-core/Makefile
> > > @@ -7,14 +7,13 @@ tuner-objs  :=  tuner-core.o
> > >  
> > >  videodev-objs:=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o 
> > > \
> > >   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
> > > - v4l2-async.o
> > > + v4l2-async.o v4l2-common.o
> > >  videodev-$(CONFIG_COMPAT) += v4l2-compat-ioctl32.o
> > >  videodev-$(CONFIG_TRACEPOINTS) += v4l2-trace.o
> > >  videodev-$(CONFIG_MEDIA_CONTROLLER) += v4l2-mc.o
> > >  
> > >  obj-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o
> > >  obj-$(CONFIG_VIDEO_V4L2) += videodev.o
> > > -obj-$(CONFIG_VIDEO_V4L2) += v4l2-common.o
> > >  obj-$(CONFIG_VIDEO_V4L2) += v4l2-dv-timings.o
> > >  
> > >  obj-$(CONFIG_VIDEO_TUNER) += tuner.o  
> > 
> > Huh? This patch sounds incomplete... Where are you removing the
> > MODULE_foo macros) from v4l2-common.c?
> >   
> 
> If you are refering to:
> 
> MODULE_AUTHOR("Bill Dirks, Justin Schoeman, Gerd Knorr");
> MODULE_DESCRIPTION("misc helper functions for v4l2 device drivers");
> MODULE_LICENSE("GPL");
> 
> I decided to keep them for documentation purposes,
> but more importantly because they were already there
> before commit a9254475bbfbed5f0596d952c6a3c9806e19dd0b
> (when v4l2-common.c was not a module, afaics).
> 
> Do you think we should remove them?

Well, it needs to be handled somehow. Please notice, however, that
there are some differences between v4l2-common and v4l2-dev:

drivers/media/v4l2-core/v4l2-common.c:MODULE_AUTHOR("Bill Dirks, Justin 
Schoeman, Gerd Knorr");
drivers/media/v4l2-core/v4l2-common.c:MODULE_DESCRIPTION("misc helper functions 
for v4l2 device drivers");
drivers/media/v4l2-core/v4l2-common.c:MODULE_LICENSE("GPL");
drivers/media/v4l2-core/v4l2-common.c:  request_module(I2C_MODULE_PREFIX "%s", 
info->type);
drivers/media/v4l2-core/v4l2-dev.c:MODULE_AUTHOR("Alan Cox, Mauro Carvalho 
Chehab ");
drivers/media/v4l2-core/v4l2-dev.c:MODULE_DESCRIPTION("Device registrar for 
Video4Linux drivers v2");
drivers/media/v4l2-core/v4l2-dev.c:MODULE_LICENSE("GPL");
drivers/media/v4l2-core/v4l2-dev.c:MODULE_ALIAS_CHARDEV_MAJOR(VIDEO_MAJOR);

So, you can't simply remove. You'll probably need to touch
both files, do some cleanup and keep some things under the
licensing comment at the top of the file (if not there yet).

Thanks,
Mauro

Re: [GIT PULL FOR v5.4] Support RK3399 VP8 decoding, various fixes, rcar-vin improvements

[Mauro Carvalho Chehab]

Em Thu, 25 Jul 2019 17:33:47 +0200
Hans Verkuil  escreveu:

> Hi Mauro,
> 
> Please note the 'v4l2-dev: fix WARN_ON(!vdev->device_caps)' patch. Sorry about
> that. I did test the original patch with vimc, but test-media doesn't actually
> create a FAIL if a module can't be loaded. I'll fix that.
> 
> Other than that it's the usual fixes/cleanups and also it adds RK3399 VP8 
> decoding.
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit 6ddb094a9f8c451c42bc7c58cfed22275e8a1e38:
> 
>   media: staging/intel-ipu3: Use dev_get_drvdata where possible (2019-07-25 
> 06:45:46 -0400)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.4e2
> 
> for you to fetch changes up to bb636bb902862c0008d7cd96ebae38fe41656233:
> 
>   media: v4l2-core: introduce a helper to unregister a I2C subdev (2019-07-25 
> 17:13:27 +0200)
> 

...

> Ezequiel Garcia (9):

...

>   media: v4l2-core: Module re-organization
>   media: v4l2-core: move spi helpers out of v4l2-common.c
>   media: v4l2-core: move i2c helpers out of v4l2-common.c
>   media: v4l2-core: introduce a helper to unregister a SPI subdev
>   media: v4l2-core: introduce a helper to unregister a I2C subdev

Didn't apply those. The first patch is incomplete, as it is keeping
MODULE_FOO at the now-dead v4l2-common module.

As the other patches depend on it, I just applied the non-related
patches, keeping this out of the patches merged upstream.

Thanks,
Mauro

Re: [PATCH 2/6] media: v4l2-core: Module re-organization

[Mauro Carvalho Chehab]

Em Mon, 15 Jul 2019 18:06:43 -0300
Ezequiel Garcia  escreveu:

> videodev.ko and v4l2-common.ko driver are built under
> the same conditions. Therefore, it doesn't make much sense
> to split them in two different modules.
> 
> Splitting v4l2-common to its own driver has done many
> years ago:
> 
>   commit a9254475bbfbed5f0596d952c6a3c9806e19dd0b
>   Author: Mauro Carvalho Chehab 
>   Date:   Tue Jan 29 18:32:35 2008 -0300
> 
>   V4L/DVB (7115): Fix bug #9833: regression when compiling V4L without I2C
> 
> Back then, the subsystem organization was different.
> However, With the current organization, there is no issue
> compiling V4L2 with I2C as y/m/n.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/v4l2-core/Makefile | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/Makefile 
> b/drivers/media/v4l2-core/Makefile
> index 4d42418e603e..8e2f52f7800b 100644
> --- a/drivers/media/v4l2-core/Makefile
> +++ b/drivers/media/v4l2-core/Makefile
> @@ -7,14 +7,13 @@ tuner-objs  :=  tuner-core.o
>  
>  videodev-objs:=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o 
> \
>   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
> - v4l2-async.o
> + v4l2-async.o v4l2-common.o
>  videodev-$(CONFIG_COMPAT) += v4l2-compat-ioctl32.o
>  videodev-$(CONFIG_TRACEPOINTS) += v4l2-trace.o
>  videodev-$(CONFIG_MEDIA_CONTROLLER) += v4l2-mc.o
>  
>  obj-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o
>  obj-$(CONFIG_VIDEO_V4L2) += videodev.o
> -obj-$(CONFIG_VIDEO_V4L2) += v4l2-common.o
>  obj-$(CONFIG_VIDEO_V4L2) += v4l2-dv-timings.o
>  
>  obj-$(CONFIG_VIDEO_TUNER) += tuner.o


Huh? This patch sounds incomplete... Where are you removing the
MODULE_foo macros) from v4l2-common.c?


Thanks,
Mauro

[PATCH] media: staging: hantro: avoid future namespace collisions

[Mauro Carvalho Chehab]

Rename:
vp8_dec_mc_filter -> hantro_vp8_dec_mc_filter

As other drivers may end implementing something with the same
name.

So, prepend driver's name here, in order to make symbol namespace
cleaner.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/hantro/hantro_g1_vp8_dec.c | 5 +++--
 drivers/staging/media/hantro/hantro_hw.h | 2 +-
 drivers/staging/media/hantro/hantro_vp8.c| 2 +-
 drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c 
b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 181e2f76d8cb..6d99c2be01cf 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -342,11 +342,12 @@ static void cfg_tap(struct hantro_ctx *ctx,
return; /* Tap filter not used. */
 
for (i = 0; i < 8; i++) {
-   val = (vp8_dec_mc_filter[i][0] << 2) | vp8_dec_mc_filter[i][5];
+   val = (hantro_vp8_dec_mc_filter[i][0] << 2) |
+  hantro_vp8_dec_mc_filter[i][5];
 
for (j = 0; j < 4; j++)
hantro_reg_write(vpu, &vp8_dec_pred_bc_tap[i][j],
-vp8_dec_mc_filter[i][j + 1]);
+hantro_vp8_dec_mc_filter[i][j + 1]);
 
switch (i) {
case 2:
diff --git a/drivers/staging/media/hantro/hantro_hw.h 
b/drivers/staging/media/hantro/hantro_hw.h
index e86c84fbfe1a..2b8029674a75 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -95,7 +95,7 @@ extern const struct hantro_variant rk3399_vpu_variant;
 extern const struct hantro_variant rk3328_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
 
-extern const u32 vp8_dec_mc_filter[8][6];
+extern const u32 hantro_vp8_dec_mc_filter[8][6];
 
 void hantro_watchdog(struct work_struct *work);
 void hantro_run(struct hantro_ctx *ctx);
diff --git a/drivers/staging/media/hantro/hantro_vp8.c 
b/drivers/staging/media/hantro/hantro_vp8.c
index cd01661cac21..0e02d147b189 100644
--- a/drivers/staging/media/hantro/hantro_vp8.c
+++ b/drivers/staging/media/hantro/hantro_vp8.c
@@ -35,7 +35,7 @@ struct vp8_prob_tbl_packed {
  * filter taps taken to 7-bit precision,
  * reference RFC6386#Page-16, filters[8][6]
  */
-const u32 vp8_dec_mc_filter[8][6] = {
+const u32 hantro_vp8_dec_mc_filter[8][6] = {
{ 0, 0, 128, 0, 0, 0 },
{ 0, -6, 123, 12, -1, 0 },
{ 2, -11, 108, 36, -8, 1 },
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c 
b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
index c5e9f8befe9c..f17e32620b08 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
@@ -439,7 +439,7 @@ static void cfg_tap(struct hantro_ctx *ctx,
if (vp8_dec_pred_bc_tap[i][j].base != 0)
hantro_reg_write(vpu,
 &vp8_dec_pred_bc_tap[i][j],
-vp8_dec_mc_filter[i][j]);
+
hantro_vp8_dec_mc_filter[i][j]);
}
}
 }
-- 
2.21.0

Re: [PATCH 2/2] media: Don't hide any menu if "ancillary drivers autoselect" is enabled

[Mauro Carvalho Chehab]

Em Mon, 15 Jul 2019 18:23:16 -0300
Ezequiel Garcia  escreveu:

> Many users have been complaining about not being able to find
> certain menu options. One such example are camera sensor drivers
> (e.g IMX219, OV5645, etc) which are common on embedded platforms
> and not always ancillary devices.
> 
> The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related
> to the fact that it uses the "visible" kbuild syntax to hide
> entire group of drivers.
> 
> This is not obvious and, as explained above, not always desired.
> 
> To fix the problem, drop the "visible" and stop hiding any menu
> options. Users skilled enough to configure their kernel are expected
> to be skilled enough to know what (not) to configure anyway.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/dvb-frontends/Kconfig | 1 -
>  drivers/media/i2c/Kconfig   | 1 -
>  drivers/media/spi/Kconfig   | 1 -
>  drivers/media/tuners/Kconfig| 1 -
>  4 files changed, 4 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/Kconfig 
> b/drivers/media/dvb-frontends/Kconfig
> index dc43749177df..2d1fea3bf546 100644
> --- a/drivers/media/dvb-frontends/Kconfig
> +++ b/drivers/media/dvb-frontends/Kconfig
> @@ -1,5 +1,4 @@
>  menu "Customise DVB Frontends"
> - visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
>  
>  comment "Multistandard (satellite) frontends"
>   depends on DVB_CORE
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 79ce9ec6fc1b..475072bb67d6 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -23,7 +23,6 @@ config VIDEO_IR_I2C
>  #
>  
>  menu "I2C Encoders, decoders, sensors and other helper chips"
> - visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT

Hmm... Hans picked this patch, but IMO it doesn't make sense
for PC consumer people to see the hundreds of extra options
that making those menus visible will produce.

This was added because in the past we had lots of issues with
people desktop/laptop settings with all those things enabled.

In any case, if the desktop/laptop user is smart enough to
go though it, he can simply disable MEDIA_SUBDRV_AUTOSELECT and
manually select what he wants, so I really miss the point of
making those stuff always visible.

Now, from this patch's comments, it seems that you want this
to be visible if CONFIG_EMBEDDED. So, I won't complain if you
replace the changes on this patch to:

menu "foo"
visible if !MEDIA_SUBDRV_AUTOSELECT || !EMBEDDED || COMPILE_TEST || 
EXPERT

In other words, for the normal guy that just wants to build the
latest media stuff for his PC camera or TV device to work, he won't
need to dig into hundreds of things that won't make any difference
if he enables, except for making the Kernel bigger.


>  
>  comment "Audio decoders, processors and mixers"
>  
> diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
> index 08386abb9bbc..d94921fe3db5 100644
> --- a/drivers/media/spi/Kconfig
> +++ b/drivers/media/spi/Kconfig
> @@ -2,7 +2,6 @@
>  if VIDEO_V4L2
>  
>  menu "SPI helper chips"
> - visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
>  
>  config VIDEO_GS1662
>   tristate "Gennum Serializers video"
> diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
> index a7108e575e9b..01212df505ae 100644
> --- a/drivers/media/tuners/Kconfig
> +++ b/drivers/media/tuners/Kconfig
> @@ -16,7 +16,6 @@ config MEDIA_TUNER
>   select MEDIA_TUNER_MC44S803 if MEDIA_SUBDRV_AUTOSELECT
>  
>  menu "Customize TV tuners"
> - visible if !MEDIA_SUBDRV_AUTOSELECT || COMPILE_TEST || EXPERT
>   depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || 
> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT
>  
>  config MEDIA_TUNER_SIMPLE



Thanks,
Mauro

Re: [GIT PULL for 5.4] V4L2 ISP, fwnode, sensor and CSI2 patches

[Mauro Carvalho Chehab]

Em Thu, 25 Jul 2019 12:50:30 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> Here's my first set of V4L2 patches for 5.4. Included are sensor driver
> patches, but also update for the Cadence CSI2TX driver and odd fixes and
> cleanups. No new drivers this time.
> 
> Please pull.
> 
> 
> The following changes since commit ebe15c7679680308268b99d911b1db15d514c7b8:
> 
>   media: tegra-cec: use cec_notifier_cec_adap_(un)register (2019-07-23 
> 08:40:57 -0400)
> 
> are available in the Git repository at:
> 
>   ssh://linuxtv.org/git/sailus/media_tree.git tags/for-5.4-3-signed
> 
> for you to fetch changes up to d0de3d651cbc2ff02084a1671368c461bb3c3e78:
> 
>   media: staging/intel-ipu3: Use dev_get_drvdata where possible (2019-07-25 
> 12:30:25 +0300)
> 
> 
> V4L2 patches for 5.4
> 
> 
> Andy Shevchenko (1):
>   media: v4l2-fwnode: Switch to use fwnode_property_count_uXX()
> 
> Christophe JAILLET (1):
>   media: ov2680: fix a typo in a function name
> 
> Chuhong Yuan (2):
>   media: pci: Use dev_get_drvdata where possible
>   media: staging/intel-ipu3: Use dev_get_drvdata where possible
> 
> Fabio Estevam (5):
>   media: ov5645: Remove unneeded regulator_set_voltage()
>   media: ov5645: Use regulator_bulk() functions
>   media: i2c: ov5640: Check for devm_gpiod_get_optional() error
>   media: i2c: ov5640: Fix the order for enabling regulators

>   media: imx7.rst: Fix the references to the CSI multiplexer

This patch has an issue: it breaks a code block at documentation.

So, I'm skipping this one, picking the remaining patches.

Regards,
Mauro


> 
> Jan Kotas (4):
>   media: dt-bindings: Update bindings for Cadence CSI2TX version 2.1
>   media: Add lane checks for Cadence CSI2TX
>   media: Fix Lane mapping in Cadence CSI2TX
>   media: Add support for Cadence CSI2TX 2.1
> 
>  .../devicetree/bindings/media/cdns,csi2tx.txt  |   3 +-
>  Documentation/media/v4l-drivers/imx7.rst   | 127 +
>  drivers/media/i2c/ov2680.c |   4 +-
>  drivers/media/i2c/ov5640.c |   7 +-
>  drivers/media/i2c/ov5645.c | 120 +++-
>  drivers/media/pci/intel/ipu3/ipu3-cio2.c   |   3 +-
>  drivers/media/pci/pt1/pt1.c|   6 +-
>  drivers/media/pci/pt3/pt3.c|   6 +-
>  drivers/media/platform/cadence/cdns-csi2tx.c   | 155 
> -
>  drivers/media/v4l2-core/v4l2-fwnode.c  |   8 +-
>  drivers/staging/media/ipu3/ipu3.c  |   3 +-
>  11 files changed, 225 insertions(+), 217 deletions(-)
> 



Thanks,
Mauro

Re: [PATCH] media: imx7.rst: Fix the references to the CSI multiplexer

[Mauro Carvalho Chehab]

Em Sat, 29 Jun 2019 09:16:23 -0300
Fabio Estevam  escreveu:

> In imx7s.dtsi the node name for the CSI multiplexer is "csi-mux", not
> "csi_mux", so fix all the references in the document.
> 
> This fixes the following error when the instructions are followed:
> 
> # media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]"
> Unable to parse link: Invalid argument (22)
> 
> While at it, provide the "media-ctl -p" output from 5.2 kernel
> version, so that users can see a more updated output.
> 
> Fixes: fa88fbdafb4a ("media: imx7.rst: add documentation for i.MX7 media 
> driver")
> Signed-off-by: Fabio Estevam 
> ---
>  Documentation/media/v4l-drivers/imx7.rst | 127 +++
>  1 file changed, 63 insertions(+), 64 deletions(-)
> 
> diff --git a/Documentation/media/v4l-drivers/imx7.rst 
> b/Documentation/media/v4l-drivers/imx7.rst
> index fe411f65c01c..ab9e17d111bf 100644
> --- a/Documentation/media/v4l-drivers/imx7.rst
> +++ b/Documentation/media/v4l-drivers/imx7.rst
> @@ -41,7 +41,7 @@ data from MIPI CSI-2 camera sensor. It has one source pad, 
> corresponding to the
>  virtual channel 0. This module is compliant to previous version of Samsung
>  D-phy, and supports two D-PHY Rx Data lanes.
>  
> -csi_mux
> +csi-mux
>  ---
>  
>  This is the video multiplexer. It has two sink pads to select from either 
> camera
> @@ -56,7 +56,7 @@ can interface directly with Parallel and MIPI CSI-2 buses. 
> It has 256 x 64 FIFO
>  to store received image pixel data and embedded DMA controllers to transfer 
> data
>  from the FIFO through AHB bus.
>  
> -This entity has one sink pad that receives from the csi_mux entity and a 
> single
> +This entity has one sink pad that receives from the csi-mux entity and a 
> single
>  source pad that routes video frames directly to memory buffers. This pad is
>  routed to a capture device node.
>  
> @@ -81,14 +81,14 @@ an output of 800x600, and BGGR 10 bit bayer format:
>  
> # Setup links
> media-ctl -l "'ov2680 1-0036':0 -> 'imx7-mipi-csis.0':0[1]"
> -   media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]"
> -   media-ctl -l "'csi_mux':2 -> 'csi':0[1]"
> +   media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi-mux':1[1]"
> +   media-ctl -l "'csi-mux':2 -> 'csi':0[1]"
> media-ctl -l "'csi':1 -> 'csi capture':0[1]"
>  
> # Configure pads for pipeline
> media-ctl -V "'ov2680 1-0036':0 [fmt:SBGGR10_1X10/800x600 field:none]"
> -   media-ctl -V "'csi_mux':1 [fmt:SBGGR10_1X10/800x600 field:none]"
> -   media-ctl -V "'csi_mux':2 [fmt:SBGGR10_1X10/800x600 field:none]"
> +   media-ctl -V "'csi-mux':1 [fmt:SBGGR10_1X10/800x600 field:none]"
> +   media-ctl -V "'csi-mux':2 [fmt:SBGGR10_1X10/800x600 field:none]"
> media-ctl -V "'imx7-mipi-csis.0':0 [fmt:SBGGR10_1X10/800x600 field:none]"
> media-ctl -V "'csi':0 [fmt:SBGGR10_1X10/800x600 field:none]"
>  
> @@ -97,64 +97,63 @@ the resolutions supported by the sensor.
>  
>  .. code-block:: none
>  
> -root@imx7s-warp:~# media-ctl -p
> -Media controller API version 4.17.0
> -
> -Media device information
> -
> -driver  imx-media
> -model   imx-media
> -serial
> -bus info
> -hw revision 0x0
> -driver version  4.17.0
> -
> -Device topology
> -- entity 1: csi (2 pads, 2 links)
> - type V4L2 subdev subtype Unknown flags 0
> - device node name /dev/v4l-subdev0
> - pad0: Sink
> - [fmt:SBGGR10_1X10/800x600 field:none]
> - <- "csi_mux":2 [ENABLED]
> - pad1: Source
> - [fmt:SBGGR10_1X10/800x600 field:none]
> - -> "csi capture":0 [ENABLED]  
> -
> -- entity 4: csi capture (1 pad, 1 link)
> - type Node subtype V4L flags 0
> - device node name /dev/video0
> - pad0: Sink
> - <- "csi":1 [ENABLED]
> -
> -- entity 10: csi_mux (3 pads, 2 links)
> - type V4L2 subdev subtype Unknown flags 0
> - device node name /dev/v4l-subdev1
> - pad0: Sink
> - [fmt:unknown/0x0]
> - pad1: Sink
> - [fmt:unknown/800x600 field:none]
> - <- "imx7-mipi-csis.0":1 [ENABLED]
> - pad2: Source
> - [fmt:unknown/800x600 field:none]
> - -> "csi":0 [ENABLED]  
> -
> -- entity 14: imx7-mipi-csis.0 (2 pads, 2 links)
> - type V4L2 subdev subtype Unknown flags 0
> - device node name /dev/v4l-subdev2
> - pad0: Sink
> - [fmt:SBGGR10_1X10/800x600 field:none]
> - <- "ov2680 1-0036":0 [ENABLED]
> - pad1: Source
> - [fmt:SBGGR10_1X10/800x600 field:none]
> - -> "csi_mux":1 [ENABLED]  
> -
> -- entity 17: ov2680 1-0036 (1 pad, 1 link)
> - type V4L2 subdev subtype Sensor flags 0
> - device node name /dev/v4l-subdev3
> - pad0: Source
> - [fmt:SBGG

Re: [GIT PULL FOR v5.4] Fix device_caps, don't set fmt description

[Mauro Carvalho Chehab]

Em Mon, 22 Jul 2019 16:06:01 +0200
Hans Verkuil  escreveu:

> Contains these two patch series, rebased on top of v5.3-rc1

>   media/usb: don't set description in ENUM_FMT

Hmm...

trying to apply this on the top of upstream caused a lot of issues:

Applying patch 
patches/0002-0021-media-usb-don-t-set-description-in-ENUM_FMT.patch
patching file drivers/media/dvb-frontends/rtl2832_sdr.c
Hunk #1 FAILED at 998.
1 out of 1 hunk FAILED -- rejects in file drivers/media/usb/gspca/gspca.c
patching file drivers/media/usb/hdpvr/hdpvr-video.c
Hunk #1 succeeded at 984 with fuzz 2.
patching file drivers/media/usb/msi2500/msi2500.c
Hunk #2 FAILED at 890.
1 out of 2 hunks FAILED -- rejects in file drivers/media/usb/msi2500/msi2500.c
patching file drivers/media/usb/pwc/pwc-v4l.c
Hunk #1 FAILED at 867.
1 out of 1 hunk FAILED -- rejects in file drivers/media/usb/pwc/pwc-v4l.c
patching file drivers/media/usb/s2255/s2255drv.c
Hunk #3 FAILED at 723.
1 out of 3 hunks FAILED -- rejects in file drivers/media/usb/s2255/s2255drv.c
patching file drivers/media/usb/stk1160/stk1160-v4l.c
Hunk #2 FAILED at 342.
1 out of 2 hunks FAILED -- rejects in file 
drivers/media/usb/stk1160/stk1160-v4l.c
patching file drivers/media/usb/stk1160/stk1160.h
patching file drivers/media/usb/stkwebcam/stk-webcam.c
patching file drivers/media/usb/tm6000/tm6000-video.c
Hunk #2 FAILED at 869.
1 out of 2 hunks FAILED -- rejects in file 
drivers/media/usb/tm6000/tm6000-video.c
patching file drivers/media/usb/tm6000/tm6000.h
patching file drivers/media/usb/usbtv/usbtv-video.c
Hunk #1 FAILED at 630.
1 out of 1 hunk FAILED -- rejects in file drivers/media/usb/usbtv/usbtv-video.c

It doesn't seem you did a rebase on this branch
git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.4a2

Thanks,
Mauro

Re: [git:media_tree/master] docs: interconnect.rst: add it to the driver-api guide

[Mauro Carvalho Chehab]

Em Mon, 22 Jul 2019 16:07:23 +0300
Georgi Djakov  escreveu:

> On 7/15/19 15:20, Mauro Carvalho Chehab wrote:
> > This is an automatic generated email to let you know that the following 
> > patch were queued:
> > 
> > Subject: docs: interconnect.rst: add it to the driver-api guide
> > Author:  Mauro Carvalho Chehab 
> > Date:Tue Jun 18 17:15:10 2019 -0300
> > 
> > This is intended for Kernel hackers audience.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > Reviewed-by: Georgi Djakov 
> > 
> >  Documentation/driver-api/index.rst  |  1 +
> >  Documentation/driver-api/interconnect.rst   | 93 
> > 
> >  Documentation/interconnect/interconnect.rst | 95 
> > -
> >  MAINTAINERS |  2 +-
> >  4 files changed, 95 insertions(+), 96 deletions(-)  
> 
> Hi Mauro,
> 
> Maybe the script that generated this email can be improved a bit, as it does 
> not
> show the renames. So the diffstat here looks a bit different compared with the
> original git commit:
> https://git.linuxtv.org/media_tree.git/commit/?id=9b1f44028ff2e051816517781153e10a2d748dc3

Thanks for the hint. I changed the post-receive script to do:

$ git show -M -C -D

instead of just git show.

Thanks,
Mauro

Re: kernel Warning when using vivid with contiguous dma

[Mauro Carvalho Chehab]

Em Mon, 22 Jul 2019 13:21:00 +0200
Dafna Hirschfeld  escreveu:

> I loaded the vivid module with contiguous DMA and ran streaming with
> it with large image dimensions

> [  306.437327] Call Trace:
> [  306.437338]  __dma_direct_alloc_pages+0xc9/0x1c0
> [  306.437343]  dma_direct_alloc_pages+0x24/0xf0
> [  306.437348]  dma_direct_alloc+0xe/0x10
> [  306.437351]  dma_alloc_attrs+0x84/0xd0

Hmm... we had a recent regression affecting other media devices,
reported via Kaffeine mailing list:

https://bugs.kde.org/show_bug.cgi?id=408004#c35

While this one was for S/G, maybe it is somewhat related.

Thanks,
Mauro

[ANN] Media summit in Lisbon at September

[Mauro Carvalho Chehab]

Hi all,

We are organizing a media mini-summit in Lisbon to happen in September,
at the same week as the Linux Plumber Conference and the Kernel Summit.

We're still discussing the details about that.

In principle, it will be a free event for the ones registered
to Linux Plumbers Conference, happening between Sept 9-11.
They have a room available that we could use for the meeting on that
period of time, but we need to adjust to avoid conflicts with other
interesting micro-conferences that will happen in parallel (or
eventually do it outside that period, but that would be harder to
organize).

I'll let you know more details once we got it.

If you plan to attend, please let me know. It is open for all, but
we'll have a limited number of seats. So, the earliest we get the
number of interested people, the best.

-

At the last summit, we were supposed to do a Key Signing Party, but
we end not doing it, due to lack of time. I suggest we add this again,
but doing it earlier, in order to avoid getting out of time for doing
it.

From my side, I'd like to discuss what criteria we should adopt for
the code that comes via /drivers/staging/media, in particular:
how much time should we keep a code there that doesn't receive any
patch addressing the drivers real issues (excluding codepatch,
cleanups and kAPI changes)?

What other themes should be discussed?

Thanks,
Mauro

Re: [PATCH 00/31] staging: bcm2835-camera: Improvements

[Mauro Carvalho Chehab]

Em Fri, 28 Jun 2019 15:13:03 +0200
Hans Verkuil  escreveu:

> On 6/27/19 8:55 PM, Stefan Wahren wrote:
> > This is an attempt to help Dave Stevenson to get all the fixes and
> > improvements of the bcm2835-camera driver into mainline.
> > 
> > Mostly i only polished the commit logs for upstream.
> > 
> > The series based on the latest bugfix V2 of staging: bcm2835-camera: Resto=
> > re
> > return behavior of ctrl_set_bitrate().
> > 
> > Dave Stevenson (31):
> >   staging: bcm2835-camera: Ensure H264 header bytes get a sensible
> > timestamp
> >   staging: bcm2835-camera: Check the error for REPEAT_SEQ_HEADER
> >   staging: bcm2835-camera: Replace spinlock protecting context_map with
> > mutex
> >   staging: bcm2835-camera: Do not bulk receive from service thread
> >   staging: bcm2835-camera: Correctly denote key frames in encoded data
> >   staging: bcm2835-camera: Return early on errors
> >   staging: bcm2835-camera: Remove dead email addresses
> >   staging: bcm2835-camera: Fix comment style violations.
> >   staging: bcm2835-camera: Fix spacing around operators
> >   staging: bcm2835-camera: Reduce length of enum names
> >   staging: bcm2835-camera: Fix multiple line dereference errors
> >   staging: bcm2835-camera: Fix brace style issues.
> >   staging: bcm2835-camera: Fix missing lines between items
> >   staging: bcm2835-camera: Fix open parenthesis alignment
> >   staging: bcm2835-camera: Ensure all buffers are returned on disable
> >   staging: bcm2835-camera: Remove check of the number of buffers
> > supplied
> >   staging: bcm2835-camera: Handle empty EOS buffers whilst streaming
> >   staging: bcm2835-camera: Set sequence number correctly
> >   staging: bcm2835-camera: Ensure timestamps never go backwards.
> >   staging: bcm2835-camera: Add multiple inclusion protection to headers
> >   staging: bcm2835-camera: Unify header inclusion defines
> >   staging: bcm2835-camera: Fix multiple assignments should be avoided
> >   staging: bcm2835-camera: Fix up mmal-parameters.h
> >   staging: bcm2835-camera: Use enums for max value in controls
> >   staging: bcm2835-camera: Correct V4L2_CID_COLORFX_CBCR behaviour
> >   staging: bcm2835-camera: Remove/amend some obsolete comments
> >   staging: mmal-vchiq: Avoid use of bool in structures
> >   staging: bcm2835-camera: Fix stride on RGB3/BGR3 formats
> >   staging: bcm2835-camera: Add sanity checks for queue_setup/CREATE_BUFS
> >   staging: bcm2835-camera: Set the field value within ach buffer  
> 
> ach -> each
> 
> >   staging: bcm2835-camera: Correct ctrl min/max/step/def to 64bit
> > 
> >  .../vc04_services/bcm2835-camera/bcm2835-camera.c  | 378 =
> > -
> >  .../vc04_services/bcm2835-camera/bcm2835-camera.h  |  34 +-
> >  .../vc04_services/bcm2835-camera/controls.c| 184 +-
> >  .../vc04_services/bcm2835-camera/mmal-common.h |  12 +-
> >  .../vc04_services/bcm2835-camera/mmal-encodings.h  |   9 +-
> >  .../vc04_services/bcm2835-camera/mmal-msg-common.h |   9 +-
> >  .../vc04_services/bcm2835-camera/mmal-msg-format.h | 104 +++---
> >  .../vc04_services/bcm2835-camera/mmal-msg-port.h   | 133 
> >  .../vc04_services/bcm2835-camera/mmal-msg.h| 150 
> >  .../vc04_services/bcm2835-camera/mmal-parameters.h | 286 +---
> >  .../vc04_services/bcm2835-camera/mmal-vchiq.c  | 159 +
> >  .../vc04_services/bcm2835-camera/mmal-vchiq.h  |  22 +-
> >  12 files changed, 826 insertions(+), 654 deletions(-)
> > 
> > =2D-
> > 2.7.4
> >   
> 
> This series looks good. Others made some comments that should be addressed,
> and the H264 changes should, I think, be dealt with in a separate patch
> series.
> 
> I guess this should go in via Greg?

Works for me. I won't be able to handle this before the merge window,
as I'll be on PTO next week.

> When you make a v2 (excluding the H264
> changes, and incorporating Dan's comments), then you can add my:
> 
> Acked-by: Hans Verkuil 

Greg, once the issues get fixed - and if you want to pick this for this
merge window, feel fee to pick with my ack:

Acked-by: Mauro Carvalho Chehab 

Otherwise, if too late for this merge window, It is probably better to
apply those against the linux-media tree after -rc1.

Thanks,
Mauro

[PATCH] MAINTAINERS: mark soc_camera as Orphan/Obsolete

[Mauro Carvalho Chehab]

The soc_camera is obsolete, and it is in process of being
stripped out of the Linux Kernel

Suggested-by: Joe Perches 
Signed-off-by: Mauro Carvalho Chehab 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 866969b36a13..a673c1e78121 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14565,7 +14565,7 @@ F:  drivers/net/ethernet/smsc/smsc9420.*
 SOC-CAMERA V4L2 SUBSYSTEM
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
-S: Orphan
+S: Orphan / Obsolete
 F: include/media/soc_camera.h
 F: drivers/staging/media/soc_camera/
 
-- 
2.21.0

[Media summit topic] Criteria to drop drivers from staging - Was: Re: [PATCH] media: schedule removal for legacy staging drivers

[Mauro Carvalho Chehab]

For the next Media Summit, I'd like to discuss some criteria in order to avoid
drivers to stay at staging from longer than needed.

We have drivers at staging that aren't touched since 2014 (except for trivial
and cleanup changes or due to changes at kABI). It sounds really doubtful that
such drivers will get any care anytime soon.

The way I see from some developers is that they rush to get stuff under 
staging, but, once the code is there, they relax and pretend that their 
drivers are already at the Linux Kernel and are first class citizens.

I suspect that part of such behavior is due to some sort of pressure from
the vendors that are sponsoring their work, but, once things enter at
staging, they stop their sponsorship to fix the problems there.

Staging is not supposed to work like that: once the driver gets merged there,
developers and their sponsors should actually be committing to do whatever
required to get the driver done to be part of the Linux Kernel's full body,
and not to stay forever on a sort of Kernel's refugee camp. 

If, for whatever reason this doesn't happen, we should be dropping those
drivers after a while.

So, I'd like to discuss a set of criteria we'll be adopting in order to
decide when it is time to send unloved staging code to /dev/null.

Regards,
Mauro


Em Tue, 25 Jun 2019 08:48:26 -0300
Mauro Carvalho Chehab  escreveu:

> Keeping legacy problematic code forever is not a good idea.
> 
> So, let's schedule a date for those legacy stuff to rest in piece.
> 
> If someone wants to steps up and take them from the staging ostracism
> and do give them a rejuvenation shower in order to address the
> isues pointed on their TODO lists, be our guest!
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/staging/media/bcm2048/TODO  | 6 ++
>  drivers/staging/media/davinci_vpfe/TODO | 7 +++
>  drivers/staging/media/omap4iss/TODO | 7 +++
>  drivers/staging/media/soc_camera/TODO   | 9 +
>  4 files changed, 29 insertions(+)
> 
> diff --git a/drivers/staging/media/bcm2048/TODO 
> b/drivers/staging/media/bcm2048/TODO
> index 6bee2a2dad68..478984672c9b 100644
> --- a/drivers/staging/media/bcm2048/TODO
> +++ b/drivers/staging/media/bcm2048/TODO
> @@ -1,3 +1,9 @@
> +NOTE:
> +   The bcm2048 driver fixes on this TODO were not addressed yet.
> +   It has been a long time since the last related change.
> +   Unless someone steps up addressing those, this driver is
> +   scheduled to be removed for Kernel 5.4.
> +
>  TODO:
>  
>  From the initial code review:
> diff --git a/drivers/staging/media/davinci_vpfe/TODO 
> b/drivers/staging/media/davinci_vpfe/TODO
> index cc8bd9306f2a..9d4577a911c9 100644
> --- a/drivers/staging/media/davinci_vpfe/TODO
> +++ b/drivers/staging/media/davinci_vpfe/TODO
> @@ -1,3 +1,10 @@
> +NOTE:
> +   The davinci_vpfe driver fixes on this TODO were not addressed yet.
> +   It has been a long time since the last related change.
> +   Unless someone steps up addressing those, this driver is
> +   scheduled to be removed for Kernel 5.4.
> +
> +
>  TODO (general):
>  ==
>  
> diff --git a/drivers/staging/media/omap4iss/TODO 
> b/drivers/staging/media/omap4iss/TODO
> index 4d220ef82653..fb90be3c1f32 100644
> --- a/drivers/staging/media/omap4iss/TODO
> +++ b/drivers/staging/media/omap4iss/TODO
> @@ -1,3 +1,10 @@
> +NOTE:
> +   The omap4iss driver fixes on this TODO were not addressed yet.
> +   It has been a long time since the last related change.
> +   Unless someone steps up addressing those, this driver is
> +   scheduled to be removed for Kernel 5.4.
> +
> +
>  * Fix FIFO/buffer overflows and underflows
>  * Replace dummy resizer code with a real implementation
>  * Fix checkpatch errors and warnings
> diff --git a/drivers/staging/media/soc_camera/TODO 
> b/drivers/staging/media/soc_camera/TODO
> index 932af6443b67..677dcdc1de61 100644
> --- a/drivers/staging/media/soc_camera/TODO
> +++ b/drivers/staging/media/soc_camera/TODO
> @@ -1,3 +1,12 @@
> +NOTE:
> +   The old drivers that depends on SoC camera framework require
> +   conversion. We're not accepting any patches that are doing just
> +   checkpatch or style fixes before such conversion.
> +
> +   If nobody steps up addressing those, this driver is scheduled to be
> +   removed for Kernel 5.5.
> +
> +
>  The SoC camera framework is obsolete and scheduled for removal in the near
>  future. Developers are encouraged to convert the drivers to use the
>  regular V4L2 API if these drivers are still needed (and if someone has the



Thanks,
Mauro

[PATCH] media: schedule removal for legacy staging drivers

[Mauro Carvalho Chehab]

Keeping legacy problematic code forever is not a good idea.

So, let's schedule a date for those legacy stuff to rest in piece.

If someone wants to steps up and take them from the staging ostracism
and do give them a rejuvenation shower in order to address the
isues pointed on their TODO lists, be our guest!

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/bcm2048/TODO  | 6 ++
 drivers/staging/media/davinci_vpfe/TODO | 7 +++
 drivers/staging/media/omap4iss/TODO | 7 +++
 drivers/staging/media/soc_camera/TODO   | 9 +
 4 files changed, 29 insertions(+)

diff --git a/drivers/staging/media/bcm2048/TODO 
b/drivers/staging/media/bcm2048/TODO
index 6bee2a2dad68..478984672c9b 100644
--- a/drivers/staging/media/bcm2048/TODO
+++ b/drivers/staging/media/bcm2048/TODO
@@ -1,3 +1,9 @@
+NOTE:
+   The bcm2048 driver fixes on this TODO were not addressed yet.
+   It has been a long time since the last related change.
+   Unless someone steps up addressing those, this driver is
+   scheduled to be removed for Kernel 5.4.
+
 TODO:
 
 From the initial code review:
diff --git a/drivers/staging/media/davinci_vpfe/TODO 
b/drivers/staging/media/davinci_vpfe/TODO
index cc8bd9306f2a..9d4577a911c9 100644
--- a/drivers/staging/media/davinci_vpfe/TODO
+++ b/drivers/staging/media/davinci_vpfe/TODO
@@ -1,3 +1,10 @@
+NOTE:
+   The davinci_vpfe driver fixes on this TODO were not addressed yet.
+   It has been a long time since the last related change.
+   Unless someone steps up addressing those, this driver is
+   scheduled to be removed for Kernel 5.4.
+
+
 TODO (general):
 ==
 
diff --git a/drivers/staging/media/omap4iss/TODO 
b/drivers/staging/media/omap4iss/TODO
index 4d220ef82653..fb90be3c1f32 100644
--- a/drivers/staging/media/omap4iss/TODO
+++ b/drivers/staging/media/omap4iss/TODO
@@ -1,3 +1,10 @@
+NOTE:
+   The omap4iss driver fixes on this TODO were not addressed yet.
+   It has been a long time since the last related change.
+   Unless someone steps up addressing those, this driver is
+   scheduled to be removed for Kernel 5.4.
+
+
 * Fix FIFO/buffer overflows and underflows
 * Replace dummy resizer code with a real implementation
 * Fix checkpatch errors and warnings
diff --git a/drivers/staging/media/soc_camera/TODO 
b/drivers/staging/media/soc_camera/TODO
index 932af6443b67..677dcdc1de61 100644
--- a/drivers/staging/media/soc_camera/TODO
+++ b/drivers/staging/media/soc_camera/TODO
@@ -1,3 +1,12 @@
+NOTE:
+   The old drivers that depends on SoC camera framework require
+   conversion. We're not accepting any patches that are doing just
+   checkpatch or style fixes before such conversion.
+
+   If nobody steps up addressing those, this driver is scheduled to be
+   removed for Kernel 5.5.
+
+
 The SoC camera framework is obsolete and scheduled for removal in the near
 future. Developers are encouraged to convert the drivers to use the
 regular V4L2 API if these drivers are still needed (and if someone has the
-- 
2.21.0

[PATCH] media: stv0297: fix frequency range limit

[Mauro Carvalho Chehab]

There was a typo at the lower frequency limit for a DVB-C
card, causing the driver to fail while tuning channels at the
VHF range.

https://bugzilla.kernel.org/show_bug.cgi?id=202083

Fixes: f1b1eabff0eb ("media: dvb: represent min/max/step/tolerance freqs in Hz")
Reported-by: Ari Kohtamäki 
Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/stv0297.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/stv0297.c 
b/drivers/media/dvb-frontends/stv0297.c
index dac396c95a59..6d5962d5697a 100644
--- a/drivers/media/dvb-frontends/stv0297.c
+++ b/drivers/media/dvb-frontends/stv0297.c
@@ -682,7 +682,7 @@ static const struct dvb_frontend_ops stv0297_ops = {
.delsys = { SYS_DVBC_ANNEX_A },
.info = {
 .name = "ST STV0297 DVB-C",
-.frequency_min_hz = 470 * MHz,
+.frequency_min_hz = 47 * MHz,
 .frequency_max_hz = 862 * MHz,
 .frequency_stepsize_hz = 62500,
 .symbol_rate_min = 87,
-- 
2.21.0

[PATCH] media: cafe-driver: mark an static var as such

[Mauro Carvalho Chehab]

As warned by sparse:

drivers/media/platform/marvell-ccic/cafe-driver.c:475:23:  warning: 
symbol 'ov7670_info' was not declared. Should it be static?

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/marvell-ccic/cafe-driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/marvell-ccic/cafe-driver.c 
b/drivers/media/platform/marvell-ccic/cafe-driver.c
index 16602628f895..37fdcc53a1c4 100644
--- a/drivers/media/platform/marvell-ccic/cafe-driver.c
+++ b/drivers/media/platform/marvell-ccic/cafe-driver.c
@@ -472,7 +472,7 @@ static struct ov7670_config sensor_cfg = {
.use_smbus = 1,
 };
 
-struct i2c_board_info ov7670_info = {
+static struct i2c_board_info ov7670_info = {
.type = "ov7670",
.addr = 0x42 >> 1,
.platform_data = &sensor_cfg,
-- 
2.21.0

Re: [PATCH 1/1] MAINTAINERS: Add maintainers for Media Controller

[Mauro Carvalho Chehab]

Em Thu, 20 Jun 2019 17:19:55 +0300
Laurent Pinchart  escreveu:

> Hi Sakari,
> 
> Thank you for the patch.
> 
> On Thu, Jun 20, 2019 at 05:17:53PM +0300, Sakari Ailus wrote:
> > When Media Controller was merged to mainline long, long time ago, no-one
> > bothered to think what its MAINTAINERS entry should be. Now that Media
> > Controller is moved into its own directory, address this at the same time.
> > 
> > So tell people to mail patches to myself and Laurent Pinchart.
> > 
> > Note that the patches are still merged through the Media tree, just like
> > any other driver or framework bits that have separate "mail patches to"
> > entries different from the main drivers/media one.
> > 
> > Signed-off-by: Sakari Ailus   
> 
> This will help me catching changes to the media controller, and being
> more active on reviews, so I welcome that change.

Ok, but please notice that this is a core part of the subsystem, and
not a driver one.

So, you should be sure that you'll have enough bandwidth to not
get patches accumulated here for no more than a reasonable time
(a couple of weeks).

If both you and Sakari are ok with that, I'll pick it.

Regards,
Mauro

Re: [GIT PULL for 5.3] More sensor and CSI-2 driver patches

[Mauro Carvalho Chehab]

Em Sat, 22 Jun 2019 06:58:44 -0300
Mauro Carvalho Chehab  escreveu:

> Em Sat, 22 Jun 2019 11:39:09 +0300
> Sakari Ailus  escreveu:
> 
> > On Sat, Jun 22, 2019 at 11:29:12AM +0300, Sakari Ailus wrote:  
> > > Hi Mauro,
> > > 
> > > Here's another set of CSI-2 and sensor driver patches for 5.3.
> > 
> > Oops! This should have been for 5.4, not 5.3!
> >   
> 
> I already applied those yesterday. 

No, I didn't apply this series. I applied the last one. If this is
not for 5.4, just mark the PR as rejected at patchwork.

Thanks,
Mauro

Re: [GIT PULL for 5.3] More sensor and CSI-2 driver patches

[Mauro Carvalho Chehab]

Em Sat, 22 Jun 2019 11:39:09 +0300
Sakari Ailus  escreveu:

> On Sat, Jun 22, 2019 at 11:29:12AM +0300, Sakari Ailus wrote:
> > Hi Mauro,
> > 
> > Here's another set of CSI-2 and sensor driver patches for 5.3.  
> 
> Oops! This should have been for 5.4, not 5.3!
> 

I already applied those yesterday. 

Should them be reverted? If so, why?

Thanks,
Mauro

Re: [GIT PULL FOR v5.3] Add Hauppauge DVB devices

[Mauro Carvalho Chehab]

Em Thu, 13 Jun 2019 13:14:47 -0500
Brad Love  escreveu:

> Hi Mauro,
> 
> Here is my first pull request. Please be gentle :)

:-)

First problem:

error: FETCH_HEAD: cannot verify a non-tag object of type commit.

You should use branches and sign them with your gpg signature.

Patches applied, thanks!

There are also a /12 patch series from you:


https://patchwork.linuxtv.org/project/linux-media/list/?series=&submitter=7220&state=13&q=&archive=&delegate=
> 
> This adds support for Hauppauge HVR1955 and HVR1975 devices, along with
> adding a vid:pid for a missing OEM Hauppauge 955Q variant.
> 
> Cheers,
> 
> Brad
> ---
> The following changes since commit 513dbd35b5d93c45fa7291147f21fc0227a9f999:
> 
>   media: add SPDX headers to some files (2019-06-12 11:42:27 -0400)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/brad/media_tree.git pr-5.3
> 
> for you to fetch changes up to 24a620ad0b74d485a1e61d5babe043f59a0ddd57:
> 
>   cx231xx-cards: Add Hauppauge 955Q variant (2019-06-13 12:27:57 -0500)
> 
> 
> Brad Love (5):
>   si2157: add detection of si2177 tuner
>   pvrusb2: Add multiple dvb frontend support
>   pvrusb2: Add i2c client demod/tuner support
>   pvrusb2: Add Hauppauge HVR1955/1975 devices
>   cx231xx-cards: Add Hauppauge 955Q variant
> 
>  drivers/media/tuners/si2157.c   |   6 +
>  drivers/media/tuners/si2157_priv.h  |   3 +-
>  drivers/media/usb/cx231xx/cx231xx-cards.c   |   2 +
>  drivers/media/usb/pvrusb2/Kconfig   |   2 +
>  drivers/media/usb/pvrusb2/pvrusb2-cx2584x-v4l.c |  25 +++
>  drivers/media/usb/pvrusb2/pvrusb2-devattr.c | 212 
> +---
>  drivers/media/usb/pvrusb2/pvrusb2-devattr.h |   1 +
>  drivers/media/usb/pvrusb2/pvrusb2-dvb.c |  88 +++---
>  drivers/media/usb/pvrusb2/pvrusb2-dvb.h |   5 +-
>  drivers/media/usb/pvrusb2/pvrusb2-fx2-cmd.h |   4 +
>  drivers/media/usb/pvrusb2/pvrusb2-hdw.c |  36 +++-
>  11 files changed, 339 insertions(+), 45 deletions(-)



Thanks,
Mauro

Re: [GIT PULL FOR v5.3] UVC and sensor changes

[Mauro Carvalho Chehab]

Hi Laurent,

Em Sat, 8 Jun 2019 15:02:22 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> The following changes since commit edadd68031e5b7c1ba0c413a9549dce62a02844c:
> 
>   media: MAINTAINERS: update email address (2019-06-05 15:58:40 -0400)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/pinchartl/media.git tags/v4l2-next-20190608
> 
> for you to fetch changes up to b9cc8bb11c6bd9036d3ff36cfeb4e12f9ff80463:
> 
>   media: i2c: mt9p031: simplify getting the adapter of a client (2019-06-08 
> 14:54:15 +0300)
> 
> 
> uvcvideo and sensor changes for v5.3
> 
> 
> Laurent Pinchart (1):
>   media: uvcvideo: Replace copyright text with SPDX header

This patch was superseded by an upstream change:

Author: Thomas Gleixner 
Date:   Mon May 27 08:55:01 2019 +0200

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

There's one little difference: your patch is using:

// SPDX-License-Identifier: GPL-2.0+

While upstream opted for:

// SPDX-License-Identifier: GPL-2.0-or-later

Both are equivalent. So, I dropped this patch.

> 
> Oliver Neukum (1):
>   media: uvcvideo: Fix access to uninitialized fields on probe error
> 
> Torleiv Sundre (1):
>   media: uvcvideo: Include streaming interface number in debugfs dir name
> 
> Wolfram Sang (1):
>   media: i2c: mt9p031: simplify getting the adapter of a client

Applied, thanks!

> 
>  drivers/media/i2c/mt9p031.c  |  2 +-
>  drivers/media/usb/uvc/uvc_ctrl.c | 11 ---
>  drivers/media/usb/uvc/uvc_debugfs.c  | 12 
>  drivers/media/usb/uvc/uvc_driver.c   |  7 +--
>  drivers/media/usb/uvc/uvc_entity.c   |  7 +--
>  drivers/media/usb/uvc/uvc_isight.c   |  7 +--
>  drivers/media/usb/uvc/uvc_metadata.c |  6 +-
>  drivers/media/usb/uvc/uvc_queue.c|  7 +--
>  drivers/media/usb/uvc/uvc_status.c   |  7 +--
>  drivers/media/usb/uvc/uvc_v4l2.c |  7 +--
>  drivers/media/usb/uvc/uvc_video.c|  7 +--
>  11 files changed, 17 insertions(+), 63 deletions(-)
> 



Thanks,
Mauro

Re: [ANN] Patchwork version upgrade

[Mauro Carvalho Chehab]

Em Fri, 31 May 2019 12:40:50 -0300
Mauro Carvalho Chehab  escreveu:

> Hi all,
> 
> For a long time, we were running an old Patchwork version. The thing is that
> we had applied some patches on the top of it, and the upgrade was not
> trivial.
> 
> Today, we upgraded it to its latest stable version. Just like before,
> you can access it via:
> 
>   https://patchwork.linuxtv.org
> 
> As this is a new version, please report if you find any issues on it.

Btw, I just added a page that will track the number of patches that
are inside patchwork:

https://linuxtv.org/patchwork_stats.php

The stats are generated for patches received over the last two years.

This is accessible via the main http://linuxtv.org menu. 

Thanks,
Mauro

[PATCH] media: add SPDX headers to some files

[Mauro Carvalho Chehab]

Add SPDX headers and fix MODULE_LICENSE() when needed on
some files I co-authored.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/tda7432.c   |  4 +++-
 drivers/media/pci/bt8xx/bttv-audio-hook.c |  3 ++-
 drivers/media/pci/bt8xx/bttv-audio-hook.h |  2 ++
 drivers/media/pci/cx88/cx88-alsa.c| 14 +++---
 drivers/media/pci/cx88/cx88-blackbird.c   | 14 +++---
 drivers/media/pci/cx88/cx88-core.c| 14 +++---
 drivers/media/pci/cx88/cx88-i2c.c | 11 +--
 drivers/media/pci/cx88/cx88-video.c   | 14 +++---
 drivers/media/usb/gspca/zc3xx-reg.h   |  2 ++
 drivers/media/v4l2-core/v4l2-dev.c|  7 ++-
 drivers/media/v4l2-core/v4l2-ioctl.c  |  7 ++-
 drivers/media/v4l2-core/videobuf-core.c   |  6 ++
 drivers/media/v4l2-core/videobuf-dma-contig.c |  6 ++
 drivers/media/v4l2-core/videobuf-dma-sg.c |  6 ++
 drivers/media/v4l2-core/videobuf-vmalloc.c|  8 +++-
 15 files changed, 35 insertions(+), 83 deletions(-)

diff --git a/drivers/media/i2c/tda7432.c b/drivers/media/i2c/tda7432.c
index 06a78c2cdaab..5cdeb6408a8d 100644
--- a/drivers/media/i2c/tda7432.c
+++ b/drivers/media/i2c/tda7432.c
@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: GPL-1.0+
+
 /*
  * For the STS-Thompson TDA7432 audio processor chip
  *
@@ -9,7 +11,7 @@
  *
  * Copyright (c) 2000 Eric Sandeen 
  * Copyright (c) 2006 Mauro Carvalho Chehab 
- * This code is placed under the terms of the GNU General Public License
+ *
  * Based on tda9855.c by Steve VanDeBogart (vand...@uclink.berkeley.edu)
  * Which was based on tda8425.c by Greg Alexander (c) 1998
  *
diff --git a/drivers/media/pci/bt8xx/bttv-audio-hook.c 
b/drivers/media/pci/bt8xx/bttv-audio-hook.c
index 8febe7358a8f..4f9943312caf 100644
--- a/drivers/media/pci/bt8xx/bttv-audio-hook.c
+++ b/drivers/media/pci/bt8xx/bttv-audio-hook.c
@@ -1,8 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+
 /*
  * Handlers for board audio hooks, split from bttv-cards
  *
  * Copyright (c) 2006 Mauro Carvalho Chehab 
- * This code is placed under the terms of the GNU General Public License
  */
 
 #include "bttv-audio-hook.h"
diff --git a/drivers/media/pci/bt8xx/bttv-audio-hook.h 
b/drivers/media/pci/bt8xx/bttv-audio-hook.h
index c61b9ac4f4e3..d6a1a5a60a56 100644
--- a/drivers/media/pci/bt8xx/bttv-audio-hook.h
+++ b/drivers/media/pci/bt8xx/bttv-audio-hook.h
@@ -1,4 +1,6 @@
 /*
+ * SPDX-License-Identifier: GPL-2.0
+ *
  * Handlers for board audio hooks, split from bttv-cards
  *
  * Copyright (c) 2006 Mauro Carvalho Chehab 
diff --git a/drivers/media/pci/cx88/cx88-alsa.c 
b/drivers/media/pci/cx88/cx88-alsa.c
index b683cbe13dee..05e0d15d61a8 100644
--- a/drivers/media/pci/cx88/cx88-alsa.c
+++ b/drivers/media/pci/cx88/cx88-alsa.c
@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0+
+
 /*
  *  Support for audio capture
  *  PCI function #1 of the cx2388x.
@@ -7,16 +9,6 @@
  *    (c) 2005 Mauro Carvalho Chehab 
  *Based on a dummy cx88 module by Gerd Knorr 
  *Based on dummy.c by Jaroslav Kysela 
- *
- *  This program 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.
  */
 
 #include "cx88.h"
@@ -104,7 +96,7 @@ MODULE_PARM_DESC(index, "Index value for cx88x capture 
interface(s).");
 MODULE_DESCRIPTION("ALSA driver module for cx2388x based TV cards");
 MODULE_AUTHOR("Ricardo Cerqueira");
 MODULE_AUTHOR("Mauro Carvalho Chehab ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_VERSION(CX88_VERSION);
 
 
MODULE_SUPPORTED_DEVICE("{{Conexant,23881},{{Conexant,23882},{{Conexant,23883}");
diff --git a/drivers/media/pci/cx88/cx88-blackbird.c 
b/drivers/media/pci/cx88/cx88-blackbird.c
index 6c0bb9fe4a31..a7ef9090dbd4 100644
--- a/drivers/media/pci/cx88/cx88-blackbird.c
+++ b/drivers/media/pci/cx88/cx88-blackbird.c
@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0+
+
 /*
  *  Support for a cx23416 mpeg encoder via cx2388x host port.
  *  "blackbird" reference design.
@@ -9,16 +11,6 @@
  *- video_ioctl2 conversion
  *
  *  Includes parts from the ivtv driver <http://sourceforge.net/projects/ivtv/>
- *
- *  This program 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 

Re: [RFC] Documentation clarifications

[Mauro Carvalho Chehab]

Em Wed, 5 Jun 2019 10:08:31 +0200
Marc Gonzalez  escreveu:

> On 04/06/2019 19:26, Mauro Carvalho Chehab wrote:
> 
> > Em Tue, 4 Jun 2019 18:41:44 +0200, Marc Gonzalez escreveu:
> >   
> >> Not sure about these changes, hence the RFC (some are quite trivial)  
> > 
> > Looks ok to me. You should submit it as a patch, though, with your SOB.  
> 
> I thought that since these were trivial changes, and you were the original
> author, you might want to patch them yourself (to keep git "ownership").
> 
> If you prefer that I send a formal patch, I can do that instead.

I prefer to receive it as a formal patch and give you credits for
this :-)

Thanks,
Mauro

Re: [RFC] Documentation clarifications

[Mauro Carvalho Chehab]

Em Tue, 4 Jun 2019 18:41:44 +0200
Marc Gonzalez  escreveu:

> Not sure about these changes, hence the RFC (some are quite trivial)

Looks ok to me. You should submit it as a patch, though, with your SOB.

See https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches.

> 
> diff --git a/Documentation/media/kapi/dtv-core.rst 
> b/Documentation/media/kapi/dtv-core.rst
> index ac005b46f23e..9a74b8ba64b7 100644
> --- a/Documentation/media/kapi/dtv-core.rst
> +++ b/Documentation/media/kapi/dtv-core.rst
> @@ -11,8 +11,8 @@ Digital TV devices are implemented by several different 
> drivers:
>  
>  - Frontend drivers that are usually implemented as two separate drivers:
>  
> -  - A tuner driver that implements the logic with commands the part of the
> -hardware with is responsible to tune into a digital TV transponder or
> +  - A tuner driver that implements the logic which commands the part of
> +the hardware responsible for tuning into a digital TV transponder or
>  physical channel. The output of a tuner is usually a baseband or
>  Intermediate Frequency (IF) signal;
>  
> diff --git a/include/media/dvbdev.h b/include/media/dvbdev.h
> index 881ca461b7bb..8e47411cf1d9 100644
> --- a/include/media/dvbdev.h
> +++ b/include/media/dvbdev.h
> @@ -86,8 +86,8 @@ struct dvb_frontend;
>   * @priv:private data
>   * @device:  pointer to struct device
>   * @module:  pointer to struct module
> - * @mfe_shared:  mfe shared: indicates mutually exclusive 
> frontends
> - *   Thie usage of this flag is currently deprecated
> + * @mfe_shared:  indicates mutually exclusive frontends.
> + *   Use of this flag is currently deprecated.
>   * @mfe_dvbdev:  Frontend device in use, in the case of MFE
>   * @mfe_lock:Lock to prevent using the other frontends when 
> MFE is
>   *   used.



Thanks,
Mauro

[PATCH] media: dvb: tag deprecated DVB APIs as such

[Mauro Carvalho Chehab]

There are three headers at DVB that should not be used on
future projects: audio.h, osd.h and video.h.

While this is already clear at the docs, make clear also at
the headers that those files should not be used on future
drivers.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/uapi/linux/dvb/audio.h | 4 +++-
 include/uapi/linux/dvb/osd.h   | 4 +++-
 include/uapi/linux/dvb/video.h | 4 +++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/dvb/audio.h b/include/uapi/linux/dvb/audio.h
index afeae063e640..81f85c0c17c7 100644
--- a/include/uapi/linux/dvb/audio.h
+++ b/include/uapi/linux/dvb/audio.h
@@ -1,6 +1,8 @@
 /* SPDX-License-Identifier: LGPL-2.1+ WITH Linux-syscall-note */
 /*
- * audio.h
+ * audio.h - DEPRECATED MPEG-TS audio decoder API
+ *
+ * NOTE: should not be used on future drivers
  *
  * Copyright (C) 2000 Ralph  Metzler 
  *  & Marcus Metzler 
diff --git a/include/uapi/linux/dvb/osd.h b/include/uapi/linux/dvb/osd.h
index e163508b9ae8..ddc35ebded34 100644
--- a/include/uapi/linux/dvb/osd.h
+++ b/include/uapi/linux/dvb/osd.h
@@ -1,6 +1,8 @@
 /* SPDX-License-Identifier: LGPL-2.1+ WITH Linux-syscall-note */
 /*
- * osd.h
+ * osd.h - DEPRECATED On Screen Display API
+ *
+ * NOTE: should not be used on future drivers
  *
  * Copyright (C) 2001 Ralph  Metzler 
  *  & Marcus Metzler 
diff --git a/include/uapi/linux/dvb/video.h b/include/uapi/linux/dvb/video.h
index 43ba8b0a3d14..179f1ec60af6 100644
--- a/include/uapi/linux/dvb/video.h
+++ b/include/uapi/linux/dvb/video.h
@@ -1,6 +1,8 @@
 /* SPDX-License-Identifier: LGPL-2.1+ WITH Linux-syscall-note */
 /*
- * video.h
+ * video.h - DEPRECATED MPEG-TS video decoder API
+ *
+ * NOTE: should not be used on future drivers
  *
  * Copyright (C) 2000 Marcus Metzler 
  *  & Ralph  Metzler 
-- 
2.21.0

Re: [ANN] Patchwork version upgrade

[Mauro Carvalho Chehab]

Em Fri, 31 May 2019 12:40:50 -0300
Mauro Carvalho Chehab  escreveu:

> Hi all,
> 
> For a long time, we were running an old Patchwork version. The thing is that
> we had applied some patches on the top of it, and the upgrade was not
> trivial.
> 
> Today, we upgraded it to its latest stable version. Just like before,
> you can access it via:
> 
>   https://patchwork.linuxtv.org
> 
> As this is a new version, please report if you find any issues on it.

I found a minor issue at the database where 166 patches didn't have
a commit message. On patchwork 2.1, the commit message is mandatory.
Not having it prevents being able to change the patch status.

After looking into it, it seems that this was due to some bugs with
the initial versions of patchwork, as the database before the
migration were also missing the data.

This was fixed by setting the commit message with an empty value.

From all I see, this happened only with patches that were already
applied, so it shouldn't be an issue. Yet, if you have any patches
pending to be applied, it doesn't hurt to check if the commit
message is empty at patchwork.

Btw, I'm tagging all patches that aren't with "new", "under review"
or "TODO" status to the archive.

Regards

Thanks,
Mauro

Re: [ANN] Patchwork version upgrade

[Mauro Carvalho Chehab]

Em Fri, 31 May 2019 17:07:01 -0300
André Almeida  escreveu:

> If one tries to access a page that doesn't exists (e.g. [1]), the page
> shows that Django is on debug mode. According to Django
> documentation[2], is not a good idea running with debugging enabled on
> production environment. To fix this, just change the `DEBUG = True` to
> `DEBUG = False` on `settings.py`. The result should be something like
> this [3].

Fixed.

> 
> Thanks,
> André

Thanks,
Mauro

Re: [ANN] Patchwork version upgrade

[Mauro Carvalho Chehab]

Em Fri, 31 May 2019 16:40:21 -0300
Mauro Carvalho Chehab  escreveu:

> Em Fri, 31 May 2019 15:01:06 -0400
> Nicolas Dufresne  escreveu:
> 

> > Actually I went a little into it, the black and white alternance for
> > lines clearly does not work.  
> 
> Black and white alternance? Here, the background is always black
> (tested with both Firefox and Chromium browser). Perhaps your browser
> didn't apply the style.css correctly, ignoring this from style.css:
> 
>   .table-striped > tbody > tr:nth-of-type(odd) {
>   background-color: black;
>   }
> 
> What browser are you using?

I did some changes at style.css. Please check if it looks better now.


Thanks,
Mauro

Re: [ANN] Patchwork version upgrade

[Mauro Carvalho Chehab]

Em Fri, 31 May 2019 15:01:06 -0400
Nicolas Dufresne  escreveu:

> Le vendredi 31 mai 2019 à 12:40 -0300, Mauro Carvalho Chehab a écrit :
> > Hi all,
> > 
> > For a long time, we were running an old Patchwork version. The thing is that
> > we had applied some patches on the top of it, and the upgrade was not
> > trivial.
> > 
> > Today, we upgraded it to its latest stable version. Just like before,
> > you can access it via:
> > 
> > https://patchwork.linuxtv.org
> > 
> > As this is a new version, please report if you find any issues on it.  
> 
> Actually I went a little into it, the black and white alternance for
> lines clearly does not work.

Black and white alternance? Here, the background is always black
(tested with both Firefox and Chromium browser). Perhaps your browser
didn't apply the style.css correctly, ignoring this from style.css:

.table-striped > tbody > tr:nth-of-type(odd) {
background-color: black;
}

What browser are you using?

> Any reason not to stick with the default CSS for the content ? 
> 
> An example that is readable:
> https://patchwork.kernel.org/project/dri-devel/list/

Well, changing the entire layout of LinuxTV site would be a lot harder.

Also, from my side, having a black background makes it less tiring
to work with patchwork.

Thanks,
Mauro