Re: [PATCH v2 9/9] cx231xx: Add I2C_MUX dependency

[kbuild test robot]

Hi Brad,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Brad-Love/cx231xx-House-cleaning/20180505-040333
base:   git://linuxtv.org/media_tree.git master
config: x86_64-lkp (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/i2c/Kconfig:61:error: recursive dependency detected!
>> drivers/i2c/Kconfig:61: symbol I2C_MUX is selected by VIDEO_CX231XX
>> drivers/media/usb/cx231xx/Kconfig:1: symbol VIDEO_CX231XX depends on I2C_MUX
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"

vim +61 drivers/i2c/Kconfig

16538e6b Jan Engelhardt   2007-05-01  37  
9c1600ed David Brownell   2007-05-01  38  config I2C_BOARDINFO
6341e62b Christoph Jaeger 2014-12-20  39bool
9c1600ed David Brownell   2007-05-01  40default y
9c1600ed David Brownell   2007-05-01  41  
2bb5095a Jean Delvare 2009-09-18  42  config I2C_COMPAT
6341e62b Christoph Jaeger 2014-12-20  43bool "Enable compatibility bits 
for old user-space"
2bb5095a Jean Delvare 2009-09-18  44default y
2bb5095a Jean Delvare 2009-09-18  45help
2bb5095a Jean Delvare 2009-09-18  46  Say Y here if you intend to 
run lm-sensors 3.1.1 or older, or any
2bb5095a Jean Delvare 2009-09-18  47  other user-space package 
which expects i2c adapters to be class
2bb5095a Jean Delvare 2009-09-18  48  devices. If you don't know, 
say Y.
2bb5095a Jean Delvare 2009-09-18  49  
^1da177e Linus Torvalds   2005-04-16  50  config I2C_CHARDEV
^1da177e Linus Torvalds   2005-04-16  51tristate "I2C device interface"
^1da177e Linus Torvalds   2005-04-16  52help
^1da177e Linus Torvalds   2005-04-16  53  Say Y here to use i2c-* 
device files, usually found in the /dev
^1da177e Linus Torvalds   2005-04-16  54  directory on your system.  
They make it possible to have user-space
^1da177e Linus Torvalds   2005-04-16  55  programs use the I2C bus.  
Information on how to do this is
^1da177e Linus Torvalds   2005-04-16  56  contained in the file 
.
^1da177e Linus Torvalds   2005-04-16  57  
^1da177e Linus Torvalds   2005-04-16  58  This support is also 
available as a module.  If so, the module 
^1da177e Linus Torvalds   2005-04-16  59  will be called i2c-dev.
^1da177e Linus Torvalds   2005-04-16  60  
0826374b Michael Lawnick  2010-08-11 @61  config I2C_MUX
0826374b Michael Lawnick  2010-08-11  62tristate "I2C bus multiplexing 
support"
0826374b Michael Lawnick  2010-08-11  63help
0826374b Michael Lawnick  2010-08-11  64  Say Y here if you want the 
I2C core to support the ability to
0826374b Michael Lawnick  2010-08-11  65  handle multiplexed I2C bus 
topologies, by presenting each
0826374b Michael Lawnick  2010-08-11  66  multiplexed segment as a I2C 
adapter.
0826374b Michael Lawnick  2010-08-11  67  
0826374b Michael Lawnick  2010-08-11  68  This support is also 
available as a module.  If so, the module
0826374b Michael Lawnick  2010-08-11  69  will be called i2c-mux.
0826374b Michael Lawnick  2010-08-11  70  

:: The code at line 61 was first introduced by commit
:: 0826374bff57411d239f2fcb15da3c35af0a93cd i2c: Multiplexed I2C bus core 
support

:: TO: Michael Lawnick <ml.lawn...@gmx.de>
:: CC: Jean Delvare <kh...@linux-fr.org>

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


.config.gz
Description: application/gzip

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sat May  5 05:00:13 CEST 2018
media-tree git hash:baa057e29b5824b3727e2eb643e513ba5e35aea0
media_build git hash:   2945d108c680b3c09c9843e001e84a9797d7f379
v4l-utils git hash: 03e763fd4b361b2082019032fc315b7606669335
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.101-i686: ERRORS
linux-3.2.101-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.113-i686: ERRORS
linux-3.4.113-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.10-i686: ERRORS
linux-3.7.10-x86_64: ERRORS
linux-3.8.13-i686: ERRORS
linux-3.8.13-x86_64: ERRORS
linux-3.9.11-i686: ERRORS
linux-3.9.11-x86_64: ERRORS
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.56-i686: ERRORS
linux-3.16.56-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.102-i686: ERRORS
linux-3.18.102-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.51-i686: ERRORS
linux-4.1.51-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.109-i686: ERRORS
linux-4.4.109-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.91-i686: ERRORS
linux-4.9.91-x86_64: ERRORS
linux-4.14.31-i686: ERRORS
linux-4.14.31-x86_64: ERRORS
linux-4.15.14-i686: ERRORS
linux-4.15.14-x86_64: ERRORS
linux-4.16-i686: WARNINGS
linux-4.16-x86_64: WARNINGS
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Applied "media: i2c: tda1997: replace codec to component" to the asoc tree

[Mark Brown]

The patch

   media: i2c: tda1997: replace codec to component

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 2d8102cc9a27577ffa4335aaaed4a26060688de2 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Mon, 23 Apr 2018 02:10:26 +
Subject: [PATCH] media: i2c: tda1997: replace codec to component

Now we can replace Codec to Component. Let's do it.

Note:
xxx_codec_xxx() ->  xxx_component_xxx()
.idle_bias_off = 0  ->  .idle_bias_on = 1
.ignore_pmdown_time = 0 ->  .use_pmdown_time = 1
-   ->  .endianness = 1
-   ->  .non_legacy_dai_naming = 1

Signed-off-by: Kuninori Morimoto 
Tested-by: Tim Harvey 
Acked-by: Tim Harvey 
Acked-by: Mauro Carvalho Chehab 
Signed-off-by: Mark Brown 
---
 drivers/media/i2c/tda1997x.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
index 3021913c28fa..33d7fcf541fc 100644
--- a/drivers/media/i2c/tda1997x.c
+++ b/drivers/media/i2c/tda1997x.c
@@ -2444,7 +2444,7 @@ static int tda1997x_pcm_startup(struct snd_pcm_substream 
*substream,
struct snd_soc_dai *dai)
 {
struct tda1997x_state *state = snd_soc_dai_get_drvdata(dai);
-   struct snd_soc_codec *codec = dai->codec;
+   struct snd_soc_component *component = dai->component;
struct snd_pcm_runtime *rtd = substream->runtime;
int rate, err;
 
@@ -2452,11 +2452,11 @@ static int tda1997x_pcm_startup(struct 
snd_pcm_substream *substream,
err = snd_pcm_hw_constraint_minmax(rtd, SNDRV_PCM_HW_PARAM_RATE,
   rate, rate);
if (err < 0) {
-   dev_err(codec->dev, "failed to constrain samplerate to %dHz\n",
+   dev_err(component->dev, "failed to constrain samplerate to 
%dHz\n",
rate);
return err;
}
-   dev_info(codec->dev, "set samplerate constraint to %dHz\n", rate);
+   dev_info(component->dev, "set samplerate constraint to %dHz\n", rate);
 
return 0;
 }
@@ -2479,20 +2479,22 @@ static struct snd_soc_dai_driver tda1997x_audio_dai = {
.ops = _dai_ops,
 };
 
-static int tda1997x_codec_probe(struct snd_soc_codec *codec)
+static int tda1997x_codec_probe(struct snd_soc_component *component)
 {
return 0;
 }
 
-static int tda1997x_codec_remove(struct snd_soc_codec *codec)
+static void tda1997x_codec_remove(struct snd_soc_component *component)
 {
-   return 0;
 }
 
-static struct snd_soc_codec_driver tda1997x_codec_driver = {
-   .probe = tda1997x_codec_probe,
-   .remove = tda1997x_codec_remove,
-   .reg_word_size = sizeof(u16),
+static struct snd_soc_component_driver tda1997x_codec_driver = {
+   .probe  = tda1997x_codec_probe,
+   .remove = tda1997x_codec_remove,
+   .idle_bias_on   = 1,
+   .use_pmdown_time= 1,
+   .endianness = 1,
+   .non_legacy_dai_naming  = 1,
 };
 
 static int tda1997x_probe(struct i2c_client *client,
@@ -2737,7 +2739,7 @@ static int tda1997x_probe(struct i2c_client *client,
else
formats = SNDRV_PCM_FMTBIT_S16_LE;
tda1997x_audio_dai.capture.formats = formats;
-   ret = snd_soc_register_codec(>client->dev,
+   ret = devm_snd_soc_register_component(>client->dev,
 _codec_driver,
 _audio_dai, 1);
if (ret) {
@@ -2782,7 +2784,6 @@ static int tda1997x_remove(struct i2c_client *client)
struct tda1997x_platform_data *pdata = >pdata;
 
if (pdata->audout_format) {
-   snd_soc_unregister_codec(>dev);
mutex_destroy(>audio_lock);
}
 
-- 
2.17.0

Re: [PATCH] media: i2c: adv748x: Fix pixel rate values

[Niklas Söderlund]

Hi Laurent,

On 2018-04-25 01:36:42 +0200, Niklas Söderlund wrote:
> Hi Laurent,
> 
> Thanks for your patch.
> 
> On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> > The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> > include both horizontal and vertical blanking. Both the AFE and HDMI
> > receiver program it incorrectly:
> > 
> > - The HDMI receiver goes to the trouble of removing blanking to compute
> > the rate of active pixels. This is easy to fix by removing the
> > computation and returning the incoming pixel clock rate directly.
> > 
> > - The AFE performs similar calculation, while it should simply return
> > the fixed pixel rate for analog sources, mandated by the ADV748x to be
> > 28.63636 MHz.
> > 
> > Signed-off-by: Laurent Pinchart 
> 
> Reviewed-by: Niklas Söderlund 

I'm afraid I would like to revoke this review tag, please see bellow.

> 
> This patch uncovered a calculation error in rcar-csi2 which compensated 
> for the removing of the blanking in the adv748x, thanks for that! Good 
> thing that it's not merged yet, will include the fix in the next version 
> of the CSI-2 driver.
> 
> > ---
> >  drivers/media/i2c/adv748x/adv748x-afe.c  | 11 +--
> >  drivers/media/i2c/adv748x/adv748x-hdmi.c |  8 +---
> >  2 files changed, 6 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> > b/drivers/media/i2c/adv748x/adv748x-afe.c
> > index 61514bae7e5c..3e18d5ae813b 100644
> > --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> > +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> > @@ -321,17 +321,16 @@ static const struct v4l2_subdev_video_ops 
> > adv748x_afe_video_ops = {
> >  static int adv748x_afe_propagate_pixelrate(struct adv748x_afe *afe)
> >  {
> > struct v4l2_subdev *tx;
> > -   unsigned int width, height, fps;
> >  
> > tx = adv748x_get_remote_sd(>pads[ADV748X_AFE_SOURCE]);
> > if (!tx)
> > return -ENOLINK;
> >  
> > -   width = 720;
> > -   height = afe->curr_norm & V4L2_STD_525_60 ? 480 : 576;
> > -   fps = afe->curr_norm & V4L2_STD_525_60 ? 30 : 25;
> > -
> > -   return adv748x_csi2_set_pixelrate(tx, width * height * fps);
> > +   /*
> > +* The ADV748x samples analog video signals using an externally supplied
> > +* clock whose frequency is required to be 28.63636 MHz.
> > +*/
> > +   return adv748x_csi2_set_pixelrate(tx, 28636360);

I believe this is wrong. The sampling rate of the AFE is 28.63636 MHz 
but the pixelrate output on the CSI-TXB might not be right? The adv7482 
is a complex and badly documented thing. But it's internal plumbing 
shows that the CVBS signal sampled by the AFE is passed to the SD core 
and then to the TXB CSI-2 transmitter.  

Reading the documentation we have such registers as LTA[1:0] which 
controls the delay between the chroma and luma samples. I do believe the 
adv748x is running with the default of AUTO_PDC_EN which indicates that 
the timings are automatically controlled by the adv748x hardware. And 
there are other registers in the SD core which to me looks like it can 
be configured to make use of the samples so that it won't correlate 1:1 
with the pixel rate.

Looking at the CSI-TXA and CSI-TXB cores which are particularly badly 
documented and the driver contains a lot of undocumented register 
writes. One that is documented and I find interesting in this context is 
EN_AUTOCALC_DPHY_PARAMS which is set 'yes' for the adv748x driver. This 
leads me to believe that the pixel rate output on the CSI-2 bus is not 
correlated with the AFE sampling clock. There are lots of holes in the 
documentation here but some stand out, the undocumented hole around 0xda 
which contains the few documented bits in that area, MIPI_PLL_LOCK_FLAG, 
MIPI_PLL_CLK_DET and MIPI_PLL_EN. Maybe the true link_freq or pixel_rate 
could be read from a undocumented register in that darkness :-)

The real reason I started to dig into this is that after you corrected 
my assumption about how to setup the R-Car CSI-2 receiver link freq this 
change breaks capture of CVBS for me. Looking at how I on your 
suggestion calculate link speed.

link_freq = (pixel_rate * bits_per_sample) / (2 * nr_of_lanes)

pixel_rate = 28636360 (from the adv748x V4L2_CID_PIXEL_RATE)
bits_per_sample = 16 (adv748x reports MEDIA_BUS_FMT_UYVY8_2X8)
nr_of_lanes = 1 (Using TXB of the adv748x)

Gives a link_freq of 229Mhz or as the R-Car CSI-2 deals with in Mbps 
~460Mbps as CSI-2 is DDR. If I try to capture CVBS using such a high 
link speed capture fail. I tried using the lowest link speed R-Car CSI-2 
receiver supports of 80Mbps and then capture works perfectly. But 
settings as high as 235Mps still manage to capture.

I'm not sure how to proceed here and have the adv748x and rcar-csi2 to 
agree on the link speed. But I do think this is wrong.

The change for the adv748x HDMI pixel rate is tested and works for both 

[PATCH v3] saa7164: Fix driver name in debug output

[Brad Love]

This issue was reported by a user who downloaded a corrupt saa7164
firmware, then went looking for a valid xc5000 firmware to fix the
error displayed...but the device in question has no xc5000, thus after
much effort, the wild goose chase eventually led to a support call.

The xc5000 has nothing to do with saa7164 (as far as I can tell),
so replace the string with saa7164 as well as give a meaningful
hint on the firmware mismatch.

Signed-off-by: Brad Love 
---
Since v2:
- 0day bot bite: Looked up what specifier size_t requires this time...

Since v1:
- Appease the 0-day bot, fix print format related kernel warnings.

 drivers/media/pci/saa7164/saa7164-fw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/saa7164/saa7164-fw.c 
b/drivers/media/pci/saa7164/saa7164-fw.c
index ef49064..ee65ea8 100644
--- a/drivers/media/pci/saa7164/saa7164-fw.c
+++ b/drivers/media/pci/saa7164/saa7164-fw.c
@@ -426,7 +426,8 @@ int saa7164_downloadfirmware(struct saa7164_dev *dev)
__func__, fw->size);
 
if (fw->size != fwlength) {
-   printk(KERN_ERR "xc5000: firmware incorrect size\n");
+   printk(KERN_ERR "saa7164: firmware incorrect size %zu 
!= %u\n",
+   fw->size, fwlength);
ret = -ENOMEM;
goto out;
}
-- 
2.7.4

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

[Sam Bobrowicz]

> Hi,
>
>> Good news, MIPI is now working on my platform. I had to make several
>> changes to how the mipi clocking is calculated in order to get things
>> stable, but I think I got it figured out. Maxime's changes were really
>> helpful.
>
> Great, I also try to make it work with MIPI-CSI2, If you have found
> the magic formula to configure the registers, I would be pleased to
> test it on my side.
>
>>
>> I will try to get some patches out today or tomorrow that should get
>> you up and running.
>>
>> Maxime, I'd prefer to create the patches myself for the experience.
>> I've read all of the submission guidelines and I understand the
>> general process, but how should I submit them to the mailing list
>> since they are based to your patches, which are still under review?
>> Should I send the patch series to the mailing list myself and just
>> mention this patch series, maybe with the In-Reply-To header? Or
>> should I just post a link to them here so you can review them and add
>> them to a new version of your patch series?
>
> Yes, I think your patch(es) should be integrated in the Maxime's series.
>
> Regards,
> Loic

Based on Maxime's reply, I have decided to make the patches based off
of that series, post it on dropbox, and provide a link here. Then we
can discuss how to integrate them into v2 of the series.

The patches are taking longer than expected, my tree is pretty chaotic
since I've been running rapid-fire experiments for weeks now. I'm
still working on getting the changes organized into an appropriate set
of patches. I think they will go out over the weekend.

Sam

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

[Sam Bobrowicz]

> Hi,
>
> On 3 May 2018 at 17:16, Maxime Ripard  wrote:
> > Hi,
> >
> > On Wed, May 02, 2018 at 11:11:55AM -0700, Sam Bobrowicz wrote:
> >> > On Wednesday, 25 April 2018 01:11:19 EEST Sam Bobrowicz wrote:
> >> >> FYI, still hard at work on this. Did some more experiments last week
> >> >> that seemed to corroborate the clock tree in the spreadsheet. It also
> >> >> seems that the output of the P divider cell, SCLK cell and MIPI Rate
> >> >> cell in the spreadsheet must have a ratio of 2x:1x:8x (respectively)
> >> >> in order for the sensor to work properly on my platform, and that the
> >> >> SCLK value must be close to the "rate" variable that you calculate and
> >> >> pass to set_mipi_pclk. Unfortunately, I've only got the sensor working
> >> >> well for 1080p@15Hz and 720p@30Hz, both with a SCLK of 42MHz (aka
> >> >> 84:42:336). I'm running experiments now trying to adjust the htot and
> >> >> vtot values to create different required rates, and also to try to get
> >> >> faster Mipi rates working. Any information you have on the
> >> >> requirements of the htot and vtot values with respect to vact and hact
> >> >> values would likely be helpful.
> >> >>
> >> >> I'm also keeping an eye on the scaler clock, which I think may be
> >> >> affecting certain resolutions, but haven't been able to see it make a
> >> >> difference yet (see register 0x3824 and 0x460c)
> >> >>
> >> >> I plan on pushing a set of patches once I get this figured out, we can
> >> >> discuss what I should base them on when I get closer to that point.
> >> >> I'm new to this process :)
> >> >
> >> > I'm also interested in getting the ov5640 driver working with MIPI CSI-2.
> >> > Studying the datasheet and the driver code, I found the stream on 
> >> > sequence to
> >> > be a bit weird. In particular the configuration of 
> >> > OV5640_REG_IO_MIPI_CTRL00,
> >> > OV5640_REG_PAD_OUTPUT00 and OV5640_REG_MIPI_CTRL00 caught my attention.
> >> >
> >> > OV5640_REG_IO_MIPI_CTRL00 (0x300e) is set to 0x45 in the large array of 
> >> > init
> >> > mode data and never touched for MIPI CSI-2 (the register is only touched 
> >> > in
> >> > ov5640_set_stream_dvp). The value means
> >> >
> >> > - mipi_lane_mode: 010 is documented as "debug mode", I would have 
> >> > expected 000
> >> > for one lane or 001 for two lanes.
> >>
> >> I noticed this too, but it seems that 010 is the correct value for two
> >> lane mode. I think this is a typo in the datasheet.
> >>
> >> >
> >> > - MIPI TX PHY power down: 0 is documented as "debug mode" and 1 as 
> >> > "Power down
> >> > PHY HS TX", so I suppose 0 is correct.
> >> >
> >> > - MIPI RX PHY power down: 0 is documented as "debug mode" and 1 as 
> >> > "Power down
> >> > PHY LP RX module", so I suppose 0 is correct. I however wonder why 
> >> > there's a
> >> > RX PHY, it could be a typo.
> >> >
> >> > - mipi_en: 1 means MIPI enable, which should be correct.
> >> >
> >> > - BIT(0) is undocumented.
> >> >
> >> > OV5640_REG_PAD_OUTPUT00 (0x3019) isn't initialized explicitly and thus 
> >> > retains
> >> > its default value of 0x00, and is controlled when starting and stopping 
> >> > the
> >> > stream where it's set to 0x00 and 0x70 respectively. Bits 6:4 control the
> >> > "sleep mode" state of lane 2, lane 1 and clock lane respectively, and 
> >> > should
> >> > be LP11 in my opinion (that's the PHY stop state). However, setting them 
> >> > to
> >> > 0x00 when starting the stream mean that LP00 is selected as the sleep 
> >> > state at
> >> > stream start, and LP11 when stopping the stream. Maybe "sleep mode" means
> >> > LPDT, but I would expect that to be controlled by the idle status bit in
> >> > register 0x4800.
> >> >
> >>
> >> I did not need to mess with the accesses to 0x3019 in order to get
> >> things working on my system. I'm not sure of this registers actual
> >> behavior, but it might affect idling while not streaming (after power
> >> on). My pipeline currently only powers the sensor while streaming, so
> >> I might be missing some ramifications of this register.
> >>
> >> > OV5640_REG_MIPI_CTRL00 (0x4800) is set to 0x04 in the large array of 
> >> > init mode
> >> > data, and BIT(5) is then cleared at stream on time and set at stream off 
> >> > time.
> >> > This means:
> >> >
> >> > - Clock lane gate enable: Clock lane is free running
> >> > - Line sync enable: Do not send line short packets for each line (I 
> >> > assume
> >> > that's LS/LE)
> >> > - Lane select: Use lane1 as default data lane.
> >> > - Idle status: MIPI bus will be LP11 when no packet to transmit. I would 
> >> > have
> >> > expected the idle status to correspond to LPDT, and thus be LP00 (as 
> >> > opposed
> >> > to the stop state that should be LP11, which I believe is named "sleep 
> >> > mode"
> >> > in the datasheet and controlled in register 0x3019).
> >> >
> >> > BIT(5) is the clock lane gate enable, so at stream on time the clock is 
> >> > set to
> >> > free running, and at stream off time 

[PATCH] media: include/video/omapfb_dss.h: use IS_ENABLED()

[Mauro Carvalho Chehab]

Just checking for ifdefs cause build issues as reported by
kernel test:

config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)

All errors (new ones prefixed by >>):

   drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
'omapfb_init_connections':
>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:8: error: implicit 
>> declaration of function 'omapdss_find_mgr_from_display' 
>> [-Werror=implicit-function-declaration]
 mgr = omapdss_find_mgr_from_display(def_dssdev);
   ^
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:6: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
 mgr = omapdss_find_mgr_from_display(def_dssdev);
 ^
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
'omapfb_find_default_display':
>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:13: error: implicit 
>> declaration of function 'omapdss_get_default_display_name' 
>> [-Werror=implicit-function-declaration]
 def_name = omapdss_get_default_display_name();
^~~~
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:11: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
 def_name = omapdss_get_default_display_name();
  ^

So, use IS_ENABLED() instead.

Cc: Bartlomiej Zolnierkiewicz 
Cc: Randy Dunlap 
Cc: tomi.valkei...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Fixes: 771f7be87ff9 ("media: omapfb: omapfb_dss.h: add stubs to build with 
COMPILE_TEST && DRM_OMAP")
Signed-off-by: Mauro Carvalho Chehab 
---
 include/video/omapfb_dss.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index e9775144ff3b..12755d8d9b4f 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -778,7 +778,7 @@ struct omap_dss_driver {
 
 typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 
-#ifdef CONFIG_FB_OMAP2
+#if IS_ENABLED(CONFIG_FB_OMAP2)
 
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
-- 
2.17.0

[PATCH v9 00/15] V4L2 Explicit Synchronization

[Ezequiel Garcia]

Hi all,

Gustavo has asked to me to take care of the final
issues with this series.

I'm working on adding some fences tests to v4l2-compliance,
which I'll be posting shortly.

So, here's a new version of the "video4linux meet fences"
series. This new round hopefully addresses all the feedback
received in v8.

There are some additional changes:

 * Removed the vb2_ops_is_unordered callback,
   and instead use a simpler unordered bitfield.
   After inspecting the code, I really saw no reason
   for having a callback. Please correct me if I missed
   anything.

 * Reworked the out-fence setup in vb2_core_qbuf,
   which results in getting rid of the sync_file
   state. After inspecting the code, it became apparent
   that the sync_file wasn't meant to be part of the
   buffer state. The resulting code is simpler.

 * Avoid returning fence file descriptors anywhere
   but in the QBUF result. Also, fixed the documentation
   to be clear about this.

Worth mentioning, I've decided to drop the is-signaled
flag suggested by Hans. It'll be easier to review and
merge if we keep this simple. We can always add stuff
later.

Gustavo Padovan (15):
  xilinx: regroup caps on querycap
  hackrf: group device capabilities
  omap3isp: group device capabilities
  vb2: move vb2_ops functions to videobuf2-core.[ch]
  vb2: add unordered vb2_queue property for drivers
  v4l: add unordered flag to format description ioctl
  v4l: mark unordered formats
  cobalt: set queue as unordered
  vb2: mark codec drivers as unordered
  vb2: add explicit fence user API
  vb2: add in-fence support to QBUF
  vb2: add out-fence support to QBUF
  v4l: introduce the fences capability
  v4l: Add V4L2_CAP_FENCES to drivers
  v4l: Document explicit synchronization behavior

 Documentation/media/uapi/v4l/buffer.rst|  45 +++-
 Documentation/media/uapi/v4l/vidioc-enum-fmt.rst   |   7 +
 Documentation/media/uapi/v4l/vidioc-qbuf.rst   |  54 +++-
 Documentation/media/uapi/v4l/vidioc-querybuf.rst   |  12 +-
 Documentation/media/uapi/v4l/vidioc-querycap.rst   |   3 +
 drivers/media/common/videobuf2/videobuf2-core.c| 298 +++--
 drivers/media/common/videobuf2/videobuf2-v4l2.c|  66 +++--
 drivers/media/dvb-core/dvb_vb2.c   |   2 +-
 drivers/media/pci/cobalt/cobalt-v4l2.c |   1 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c |   2 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c |   1 +
 drivers/media/platform/omap3isp/ispvideo.c |  10 +-
 drivers/media/platform/qcom/venus/venc.c   |   2 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c   |   2 +
 drivers/media/platform/xilinx/xilinx-dma.c |  10 +-
 drivers/media/usb/hackrf/hackrf.c  |  11 +-
 drivers/media/v4l2-core/Kconfig|  33 +++
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c  |   4 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |  63 +++--
 include/media/v4l2-fh.h|   2 -
 include/media/videobuf2-core.h |  49 +++-
 include/media/videobuf2-v4l2.h |  18 --
 include/uapi/linux/videodev2.h |  10 +-
 23 files changed, 590 insertions(+), 115 deletions(-)

-- 
2.16.3

[PATCH v9 12/15] vb2: add out-fence support to QBUF

[Ezequiel Garcia]

From: Gustavo Padovan 

If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send its fd to userspace in the fence_fd field as a
return arg for the QBUF call.

The fence is signaled on buffer_done(), when the job on the buffer is
finished.

v11: - Return fence_fd to userpace only in the QBUF ioctl.
 - Rework implementation to avoid storing the sync_file
   as state, which is not really needed.

v10: - use -EIO for fence error (Hans Verkuil)
 - add comment around fence context creation (Hans Verkuil)

v9: - remove in-fences changes from this patch (Alex Courbot)
- improve fence context creation (Hans Verkuil)
- clean up out fences if vb2_core_qbuf() fails (Hans Verkuil)

v8: - return 0 as fence_fd if OUT_FENCE flag not used (Mauro)
- fix crash when checking not using fences in vb2_buffer_done()

v7: - merge patch that add the infrastructure to out-fences into
  this one (Alex Courbot)
- Do not install the fd if there is no fence. (Alex Courbot)
- do not report error on requeueing, just WARN_ON_ONCE() (Hans)

v6: - get rid of the V4L2_EVENT_OUT_FENCE event. We always keep the
  ordering in vb2 for queueing in the driver, so the event is not
  necessary anymore and the out_fence_fd is sent back to userspace
  on QBUF call return arg
- do not allow requeueing with out-fences, instead mark the buffer
  with an error and wake up to userspace.
- send the out_fence_fd back to userspace on the fence_fd field

v5: - delay fd_install to DQ_EVENT (Hans)
- if queue is fully ordered send OUT_FENCE event right away
  (Brian)
- rename 'q->ordered' to 'q->ordered_in_driver'
- merge change to implement OUT_FENCE event here

v4: - return the out_fence_fd in the BUF_QUEUED event(Hans)

v3: - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
- set the OUT_FENCE flag if there is a fence pending (Hans)
- call fd_install() after vb2_core_qbuf() (Hans)
- clean up fence if vb2_core_qbuf() fails (Hans)
- add list to store sync_file and fence for the next queued buffer

v2: check if the queue is ordered.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Ezequiel Garcia 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 95 +++--
 drivers/media/common/videobuf2/videobuf2-v4l2.c | 22 +-
 drivers/media/dvb-core/dvb_vb2.c|  2 +-
 include/media/videobuf2-core.h  | 16 -
 4 files changed, 127 insertions(+), 8 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 996b99497a98..0f7306a04db7 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -357,6 +358,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+   vb->out_fence_fd = -1;
q->bufs[vb->index] = vb;
 
/* Allocate video buffer memory for the MMAP type */
@@ -948,10 +950,22 @@ static void vb2_process_buffer_done(struct vb2_buffer 
*vb, enum vb2_buffer_state
case VB2_BUF_STATE_QUEUED:
return;
case VB2_BUF_STATE_REQUEUEING:
+   /* Requeuing with explicit synchronization, spit warning */
+   WARN_ON_ONCE(vb->out_fence);
+
if (q->start_streaming_called)
__enqueue_in_driver(vb);
return;
default:
+   if (vb->out_fence) {
+   if (state == VB2_BUF_STATE_ERROR)
+   dma_fence_set_error(vb->out_fence, -EIO);
+   dma_fence_signal(vb->out_fence);
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   vb->out_fence_fd = -1;
+   }
+
/* Inform any processes that may be waiting for buffers */
wake_up(>done_wq);
break;
@@ -1367,6 +1381,68 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
int index, void *pb)
 }
 EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
 
+static inline const char *vb2_fence_get_driver_name(struct dma_fence *fence)
+{
+   return "vb2_fence";
+}
+
+static inline const char *vb2_fence_get_timeline_name(struct dma_fence *fence)
+{
+   return "vb2_fence_timeline";
+}
+
+static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops vb2_fence_ops = {
+   .get_driver_name = vb2_fence_get_driver_name,
+   .get_timeline_name = 

[PATCH v9 03/15] omap3isp: group device capabilities

[Ezequiel Garcia]

From: Gustavo Padovan 

Instead of putting V4L2_CAP_STREAMING everywhere, set device_caps
earlier with this value.

v2: move cap->capabilities assignment down (Hans Verkuil)

Signed-off-by: Gustavo Padovan 
---
 drivers/media/platform/omap3isp/ispvideo.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
b/drivers/media/platform/omap3isp/ispvideo.c
index a751c89a3ea8..db9aae222134 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -658,13 +658,15 @@ isp_video_querycap(struct file *file, void *fh, struct 
v4l2_capability *cap)
strlcpy(cap->card, video->video.name, sizeof(cap->card));
strlcpy(cap->bus_info, "media", sizeof(cap->bus_info));
 
-   cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT
-   | V4L2_CAP_STREAMING | V4L2_CAP_DEVICE_CAPS;
+   cap->device_caps = V4L2_CAP_STREAMING;
 
if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
-   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+   cap->device_caps |= V4L2_CAP_VIDEO_CAPTURE;
else
-   cap->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
+   cap->device_caps |= V4L2_CAP_VIDEO_OUTPUT;
+
+   cap->capabilities = cap->device_caps | V4L2_CAP_VIDEO_CAPTURE |
+   V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_DEVICE_CAPS;
 
return 0;
 }
-- 
2.16.3

[PATCH v9 02/15] hackrf: group device capabilities

[Ezequiel Garcia]

From: Gustavo Padovan 

Instead of putting V4L2_CAP_STREAMING and V4L2_CAP_READWRITE
everywhere, set device_caps earlier with these values.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/usb/hackrf/hackrf.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/media/usb/hackrf/hackrf.c 
b/drivers/media/usb/hackrf/hackrf.c
index 7eb53517a82f..6d692fb3e8dd 100644
--- a/drivers/media/usb/hackrf/hackrf.c
+++ b/drivers/media/usb/hackrf/hackrf.c
@@ -909,18 +909,15 @@ static int hackrf_querycap(struct file *file, void *fh,
 
dev_dbg(>dev, "\n");
 
+   cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
if (vdev->vfl_dir == VFL_DIR_RX)
-   cap->device_caps = V4L2_CAP_SDR_CAPTURE | V4L2_CAP_TUNER |
-  V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
-
+   cap->device_caps |= V4L2_CAP_SDR_CAPTURE | V4L2_CAP_TUNER;
else
-   cap->device_caps = V4L2_CAP_SDR_OUTPUT | V4L2_CAP_MODULATOR |
-  V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
+   cap->device_caps |= V4L2_CAP_SDR_OUTPUT | V4L2_CAP_MODULATOR;
 
cap->capabilities = V4L2_CAP_SDR_CAPTURE | V4L2_CAP_TUNER |
V4L2_CAP_SDR_OUTPUT | V4L2_CAP_MODULATOR |
-   V4L2_CAP_STREAMING | V4L2_CAP_READWRITE |
-   V4L2_CAP_DEVICE_CAPS;
+   V4L2_CAP_DEVICE_CAPS | cap->device_caps;
strlcpy(cap->driver, KBUILD_MODNAME, sizeof(cap->driver));
strlcpy(cap->card, dev->rx_vdev.name, sizeof(cap->card));
usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info));
-- 
2.16.3

[PATCH v9 09/15] vb2: mark codec drivers as unordered

[Ezequiel Garcia]

From: Gustavo Padovan 

In preparation to have full support to explicit fence we are
marking codec as non-ordered preventively. It is easier and safer from an
uAPI point of view to move from unordered to ordered than the opposite.

v3: set property instead of callback
v2: mark only codec drivers as unordered (Nicolas and Hans)

Signed-off-by: Gustavo Padovan 
Signed-off-by: Ezequiel Garcia 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 ++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 +
 drivers/media/platform/qcom/venus/venc.c   | 2 ++
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 2 ++
 4 files changed, 7 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 86f0a7134365..c03cefde0c28 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1498,6 +1498,7 @@ int mtk_vcodec_dec_queue_init(void *priv, struct 
vb2_queue *src_vq,
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock= >dev->dev_mutex;
src_vq->dev = >dev->plat_dev->dev;
+   src_vq->unordered   = 1;
 
ret = vb2_queue_init(src_vq);
if (ret) {
@@ -1513,6 +1514,7 @@ int mtk_vcodec_dec_queue_init(void *priv, struct 
vb2_queue *src_vq,
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock= >dev->dev_mutex;
dst_vq->dev = >dev->plat_dev->dev;
+   src_vq->unordered   = 1;
 
ret = vb2_queue_init(dst_vq);
if (ret) {
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 1b1a28abbf1f..81751c9aa19d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -1340,6 +1340,7 @@ int mtk_vcodec_enc_queue_init(void *priv, struct 
vb2_queue *src_vq,
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock= >dev->dev_mutex;
dst_vq->dev = >dev->plat_dev->dev;
+   dst_vq->unordered   = 1;
 
return vb2_queue_init(dst_vq);
 }
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 6b2ce479584e..17ec2d218aa5 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -1053,6 +1053,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue 
*src_vq,
src_vq->buf_struct_size = sizeof(struct venus_buffer);
src_vq->allow_zero_bytesused = 1;
src_vq->min_buffers_needed = 1;
+   src_vq->unordered = 1;
src_vq->dev = inst->core->dev;
if (inst->core->res->hfi_version == HFI_VERSION_1XX)
src_vq->bidirectional = 1;
@@ -1069,6 +1070,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue 
*src_vq,
dst_vq->buf_struct_size = sizeof(struct venus_buffer);
dst_vq->allow_zero_bytesused = 1;
dst_vq->min_buffers_needed = 1;
+   src_vq->unordered = 1;
dst_vq->dev = inst->core->dev;
ret = vb2_queue_init(dst_vq);
if (ret) {
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index a80251ed3143..6a4251f988ab 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -863,6 +863,7 @@ static int s5p_mfc_open(struct file *file)
q->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES;
q->mem_ops = _dma_contig_memops;
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
+   q->unordered = 1;
ret = vb2_queue_init(q);
if (ret) {
mfc_err("Failed to initialize videobuf2 queue(capture)\n");
@@ -898,6 +899,7 @@ static int s5p_mfc_open(struct file *file)
q->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES;
q->mem_ops = _dma_contig_memops;
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
+   q->unordered = 1;
ret = vb2_queue_init(q);
if (ret) {
mfc_err("Failed to initialize videobuf2 queue(output)\n");
-- 
2.16.3

[PATCH v9 01/15] xilinx: regroup caps on querycap

[Ezequiel Garcia]

From: Gustavo Padovan 

To better organize the code we concentrate the setting of
V4L2_CAP_STREAMING in one place.

v2: move cap->capabilities assignment down (Hans Verkuil)

Signed-off-by: Gustavo Padovan 
---
 drivers/media/platform/xilinx/xilinx-dma.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 522cdfdd3345..d041f94be832 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -494,13 +494,15 @@ xvip_dma_querycap(struct file *file, void *fh, struct 
v4l2_capability *cap)
struct v4l2_fh *vfh = file->private_data;
struct xvip_dma *dma = to_xvip_dma(vfh->vdev);
 
-   cap->capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
- | dma->xdev->v4l2_caps;
+   cap->device_caps = V4L2_CAP_STREAMING;
 
if (dma->queue.type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
-   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+   cap->device_caps |= V4L2_CAP_VIDEO_CAPTURE;
else
-   cap->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
+   cap->device_caps |= V4L2_CAP_VIDEO_OUTPUT;
+
+   cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS
+ | dma->xdev->v4l2_caps;
 
strlcpy(cap->driver, "xilinx-vipp", sizeof(cap->driver));
strlcpy(cap->card, dma->video.name, sizeof(cap->card));
-- 
2.16.3

[PATCH v9 04/15] vb2: move vb2_ops functions to videobuf2-core.[ch]

[Ezequiel Garcia]

From: Gustavo Padovan 

vb2_ops_wait_prepare() and vb2_ops_wait_finish() were in the
wrong file.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 14 ++
 drivers/media/common/videobuf2/videobuf2-v4l2.c | 14 --
 include/media/videobuf2-core.h  | 18 ++
 include/media/videobuf2-v4l2.h  | 18 --
 4 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index d3f7bb33a54d..6b8e083893ad 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -656,6 +656,20 @@ int vb2_verify_memory_type(struct vb2_queue *q,
 }
 EXPORT_SYMBOL(vb2_verify_memory_type);
 
+/* vb2_ops helpers. Only use if vq->lock is non-NULL. */
+
+void vb2_ops_wait_prepare(struct vb2_queue *vq)
+{
+   mutex_unlock(vq->lock);
+}
+EXPORT_SYMBOL_GPL(vb2_ops_wait_prepare);
+
+void vb2_ops_wait_finish(struct vb2_queue *vq)
+{
+   mutex_lock(vq->lock);
+}
+EXPORT_SYMBOL_GPL(vb2_ops_wait_finish);
+
 int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
unsigned int *count)
 {
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 886a2d8d5c6c..64503615d00b 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -947,20 +947,6 @@ unsigned long vb2_fop_get_unmapped_area(struct file *file, 
unsigned long addr,
 EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area);
 #endif
 
-/* vb2_ops helpers. Only use if vq->lock is non-NULL. */
-
-void vb2_ops_wait_prepare(struct vb2_queue *vq)
-{
-   mutex_unlock(vq->lock);
-}
-EXPORT_SYMBOL_GPL(vb2_ops_wait_prepare);
-
-void vb2_ops_wait_finish(struct vb2_queue *vq)
-{
-   mutex_lock(vq->lock);
-}
-EXPORT_SYMBOL_GPL(vb2_ops_wait_finish);
-
 MODULE_DESCRIPTION("Driver helper framework for Video for Linux 2");
 MODULE_AUTHOR("Pawel Osciak , Marek Szyprowski");
 MODULE_LICENSE("GPL");
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f6818f732f34..f9633de0386c 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -400,6 +400,24 @@ struct vb2_ops {
void (*buf_queue)(struct vb2_buffer *vb);
 };
 
+/**
+ * vb2_ops_wait_prepare - helper function to lock a struct _queue
+ *
+ * @vq: pointer to  vb2_queue
+ *
+ * ..note:: only use if vq->lock is non-NULL.
+ */
+void vb2_ops_wait_prepare(struct vb2_queue *vq);
+
+/**
+ * vb2_ops_wait_finish - helper function to unlock a struct _queue
+ *
+ * @vq: pointer to  vb2_queue
+ *
+ * ..note:: only use if vq->lock is non-NULL.
+ */
+void vb2_ops_wait_finish(struct vb2_queue *vq);
+
 /**
  * struct vb2_buf_ops - driver-specific callbacks.
  *
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 3d5e2d739f05..cf83b01dc44e 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -273,22 +273,4 @@ unsigned long vb2_fop_get_unmapped_area(struct file *file, 
unsigned long addr,
unsigned long len, unsigned long pgoff, unsigned long flags);
 #endif
 
-/**
- * vb2_ops_wait_prepare - helper function to lock a struct _queue
- *
- * @vq: pointer to  vb2_queue
- *
- * ..note:: only use if vq->lock is non-NULL.
- */
-void vb2_ops_wait_prepare(struct vb2_queue *vq);
-
-/**
- * vb2_ops_wait_finish - helper function to unlock a struct _queue
- *
- * @vq: pointer to  vb2_queue
- *
- * ..note:: only use if vq->lock is non-NULL.
- */
-void vb2_ops_wait_finish(struct vb2_queue *vq);
-
 #endif /* _MEDIA_VIDEOBUF2_V4L2_H */
-- 
2.16.3

[PATCH v9 05/15] vb2: add unordered vb2_queue property for drivers

[Ezequiel Garcia]

From: Gustavo Padovan 

Explicit synchronization benefits a lot from ordered queues, they fit
better in a pipeline with DRM for example so create a opt-in way for
drivers notify videobuf2 that the queue is unordered.

v5: go back to a bitfield property for the unordered property.

v4: rename it to vb2_ops_is_unordered() (Hans Verkuil)

v3: - make it bool (Hans)
- create vb2_ops_set_unordered() helper

v2: improve comments for is_unordered flag (Hans Verkuil)

Signed-off-by: Gustavo Padovan 
Signed-off-by: Ezequiel Garcia 
---
 include/media/videobuf2-core.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f9633de0386c..364e4cb41b10 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -467,6 +467,8 @@ struct vb2_buf_ops {
  * @quirk_poll_must_check_waiting_for_buffers: Return %EPOLLERR at poll when 
QBUF
  *  has not been called. This is a vb1 idiom that has been adopted
  *  also by vb2.
+ * @unordered: tell if the queue is unordered, i.e. buffers can be
+ * dequeued in a different order from how they were queued.
  * @lock:  pointer to a mutex that protects the  vb2_queue. The
  * driver can set this to a mutex to let the v4l2 core serialize
  * the queuing ioctls. If the driver wants to handle locking
@@ -533,6 +535,7 @@ struct vb2_queue {
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
+   unsignedunordered:1;
unsigned   quirk_poll_must_check_waiting_for_buffers:1;
 
struct mutex*lock;
-- 
2.16.3

[PATCH v9 07/15] v4l: mark unordered formats

[Ezequiel Garcia]

From: Gustavo Padovan 

Now that we've introduced the V4L2_FMT_FLAG_UNORDERED flag,
mark the appropriate formats.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 55 
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index f48c505550e0..f75ad954a6f2 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1260,20 +1260,6 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_MJPEG:descr = "Motion-JPEG"; break;
case V4L2_PIX_FMT_JPEG: descr = "JFIF JPEG"; break;
case V4L2_PIX_FMT_DV:   descr = "1394"; break;
-   case V4L2_PIX_FMT_MPEG: descr = "MPEG-1/2/4"; break;
-   case V4L2_PIX_FMT_H264: descr = "H.264"; break;
-   case V4L2_PIX_FMT_H264_NO_SC:   descr = "H.264 (No Start 
Codes)"; break;
-   case V4L2_PIX_FMT_H264_MVC: descr = "H.264 MVC"; break;
-   case V4L2_PIX_FMT_H263: descr = "H.263"; break;
-   case V4L2_PIX_FMT_MPEG1:descr = "MPEG-1 ES"; break;
-   case V4L2_PIX_FMT_MPEG2:descr = "MPEG-2 ES"; break;
-   case V4L2_PIX_FMT_MPEG4:descr = "MPEG-4 part 2 ES"; 
break;
-   case V4L2_PIX_FMT_XVID: descr = "Xvid"; break;
-   case V4L2_PIX_FMT_VC1_ANNEX_G:  descr = "VC-1 (SMPTE 412M Annex 
G)"; break;
-   case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1 (SMPTE 412M Annex 
L)"; break;
-   case V4L2_PIX_FMT_VP8:  descr = "VP8"; break;
-   case V4L2_PIX_FMT_VP9:  descr = "VP9"; break;
-   case V4L2_PIX_FMT_HEVC: descr = "HEVC"; break; /* aka 
H.265 */
case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA YUV"; break;
case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break;
case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA SN9C10X"; break;
@@ -1294,17 +1280,36 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_S5C_UYVY_JPG: descr = "S5C73MX interleaved 
UYVY/JPEG"; break;
case V4L2_PIX_FMT_MT21C:descr = "Mediatek Compressed 
Format"; break;
default:
-   WARN(1, "Unknown pixelformat 0x%08x\n", 
fmt->pixelformat);
-   if (fmt->description[0])
-   return;
-   flags = 0;
-   snprintf(fmt->description, sz, "%c%c%c%c%s",
-   (char)(fmt->pixelformat & 0x7f),
-   (char)((fmt->pixelformat >> 8) & 0x7f),
-   (char)((fmt->pixelformat >> 16) & 0x7f),
-   (char)((fmt->pixelformat >> 24) & 0x7f),
-   (fmt->pixelformat & (1 << 31)) ? "-BE" 
: "");
-   break;
+   /* Unordered formats */
+   flags = V4L2_FMT_FLAG_UNORDERED;
+   switch (fmt->pixelformat) {
+   case V4L2_PIX_FMT_MPEG: descr = "MPEG-1/2/4"; 
break;
+   case V4L2_PIX_FMT_H264: descr = "H.264"; break;
+   case V4L2_PIX_FMT_H264_NO_SC:   descr = "H.264 (No 
Start Codes)"; break;
+   case V4L2_PIX_FMT_H264_MVC: descr = "H.264 MVC"; 
break;
+   case V4L2_PIX_FMT_H263: descr = "H.263"; break;
+   case V4L2_PIX_FMT_MPEG1:descr = "MPEG-1 ES"; 
break;
+   case V4L2_PIX_FMT_MPEG2:descr = "MPEG-2 ES"; 
break;
+   case V4L2_PIX_FMT_MPEG4:descr = "MPEG-4 part 2 
ES"; break;
+   case V4L2_PIX_FMT_XVID: descr = "Xvid"; break;
+   case V4L2_PIX_FMT_VC1_ANNEX_G:  descr = "VC-1 (SMPTE 
412M Annex G)"; break;
+   case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1 (SMPTE 
412M Annex L)"; break;
+   case V4L2_PIX_FMT_VP8:  descr = "VP8"; break;
+   case V4L2_PIX_FMT_VP9:  descr = "VP9"; break;
+   case V4L2_PIX_FMT_HEVC: descr = "HEVC"; break; 
/* aka H.265 */
+   default:
+   WARN(1, "Unknown pixelformat 0x%08x\n", 
fmt->pixelformat);
+   if (fmt->description[0])
+   return;
+   flags = 0;
+   snprintf(fmt->description, sz, "%c%c%c%c%s",
+   

[PATCH v9 11/15] vb2: add in-fence support to QBUF

[Ezequiel Garcia]

From: Gustavo Padovan 

Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers can't be queued to the
driver before its fences signal. And a buffer can't be queued to the driver
out of the order they were queued from userspace. That means that even if
its fence signals it must wait for all other buffers, ahead of it in the queue,
to signal first.

If the fence for some buffer fails we do not queue it to the driver,
instead we mark it as error and wait until the previous buffer is done
to notify userspace of the error. We wait here to deliver the buffers back
to userspace in order.

v12: fixed dvb_vb2.c usage of vb2_core_qbuf.

v11: - minor doc/comments fixes (Hans Verkuil)
 - reviewed the in-fence path at __fill_v4l2_buffer()

v10: - rename fence to in_fence in many places
 - handle fences signalling with error better (Hans Verkuil)

v9: - improve comments and docs (Hans Verkuil)
- fix unlocking of vb->fence_cb_lock on vb2_core_qbuf (Hans Verkuil)
- move in-fences code that was in the out-fences patch here (Alex)

v8: - improve comments about fences with errors

v7: - get rid of the fence array stuff for ordering and just use
  get_num_buffers_ready() (Hans)
- fix issue of queuing the buffer twice (Hans)
- avoid the dma_fence_wait() in core_qbuf() (Alex)
- merge preparation commit in

v6: - With fences always keep the order userspace queues the buffers.
- Protect in_fence manipulation with a lock (Brian Starkey)
- check if fences have the same context before adding a fence array
- Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
- Clean up fence if __set_in_fence() fails (Brian Starkey)
- treat -EINVAL from dma_fence_add_callback() (Brian Starkey)

v5: - use fence_array to keep buffers ordered in vb2 core when
  needed (Brian Starkey)
- keep backward compat on the reserved2 field (Brian Starkey)
- protect fence callback removal with lock (Brian Starkey)

v4: - Add a comment about dma_fence_add_callback() not returning a
  error (Hans)
- Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
- select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
- Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
- Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
- Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
  vb2_start_streaming() (Hans)
- set IN_FENCE flags on __fill_v4l2_buffer (Hans)
- Queue buffers to the driver as soon as they are ready (Hans)
- call fill_user_buffer() after queuing the buffer (Hans)
- add err: label to clean up fence
- add dma_fence_wait() before calling vb2_start_streaming()

v3: - document fence parameter
- remove ternary if at vb2_qbuf() return (Mauro)
- do not change if conditions behaviour (Mauro)

v2: - fix vb2_queue_or_prepare_buf() ret check
- remove check for VB2_MEMORY_DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel

Signed-off-by: Gustavo Padovan 
Signed-off-by: Ezequiel Garcia 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 197 
 drivers/media/common/videobuf2/videobuf2-v4l2.c |  34 +++-
 drivers/media/dvb-core/dvb_vb2.c|   2 +-
 drivers/media/v4l2-core/Kconfig |  33 
 include/media/videobuf2-core.h  |  14 +-
 5 files changed, 249 insertions(+), 31 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 6b8e083893ad..996b99497a98 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -352,6 +352,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->index = q->num_buffers + buffer;
vb->type = q->type;
vb->memory = memory;
+   spin_lock_init(>fence_cb_lock);
for (plane = 0; plane < num_planes; ++plane) {
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
@@ -905,20 +906,12 @@ void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned 
int plane_no)
 }
 EXPORT_SYMBOL_GPL(vb2_plane_cookie);
 
-void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state)
+static void vb2_process_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
 {
struct vb2_queue *q = vb->vb2_queue;
unsigned long flags;
unsigned int plane;
 
-   if (WARN_ON(vb->state != VB2_BUF_STATE_ACTIVE))
-   return;
-
-   if (WARN_ON(state != VB2_BUF_STATE_DONE &&
-   state != VB2_BUF_STATE_ERROR &&
-   

[PATCH v9 10/15] vb2: add explicit fence user API

[Ezequiel Garcia]

From: Gustavo Padovan 

Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel or return an out-fence from the kernel to
userspace.

Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending an in-fence to the kernel to be waited on, and
V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.

v7: minor fixes on the Documentation (Hans Verkuil)

v6: big improvement on doc (Hans Verkuil)

v5: - keep using reserved2 field for cpia2
- set fence_fd to 0 for now, for compat with userspace(Mauro)

v4: make it a union with reserved2 and fence_fd (Hans Verkuil)

v3: make the out_fence refer to the current buffer (Hans Verkuil)

v2: add documentation

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/buffer.rst | 45 +++--
 drivers/media/common/videobuf2/videobuf2-v4l2.c |  2 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c   |  4 +--
 include/uapi/linux/videodev2.h  |  8 -
 4 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index e2c85ddc990b..be9719cf5745 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -301,10 +301,22 @@ struct v4l2_buffer
elements in the ``planes`` array. The driver will fill in the
actual number of valid elements in that array.
 * - __u32
-  - ``reserved2``
+  - ``fence_fd``
   -
-  - A place holder for future extensions. Drivers and applications
-   must set this to 0.
+  - Used to communicate a fence file descriptors from userspace to kernel
+   and vice-versa. On :ref:`VIDIOC_QBUF ` when sending
+   an in-fence for V4L2 to wait on, the ``V4L2_BUF_FLAG_IN_FENCE`` flag 
must
+   be used and this field set to the fence file descriptor of the in-fence.
+   If the in-fence is not valid ` VIDIOC_QBUF`` returns an error.
+
+To get an out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE``
+   must be set, the kernel will return the out-fence file descriptor in
+   this field. If it fails to create the out-fence ``VIDIOC_QBUF` returns
+an error.
+
+   For all other ioctls V4L2 sets this field to -1 if
+   ``V4L2_BUF_FLAG_IN_FENCE`` and/or ``V4L2_BUF_FLAG_OUT_FENCE`` are set,
+   otherwise this field is set to 0 for backward compatibility.
 * - __u32
   - ``reserved``
   -
@@ -648,6 +660,33 @@ Buffer Flags
   - Start Of Exposure. The buffer timestamp has been taken when the
exposure of the frame has begun. This is only valid for the
``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
+* .. _`V4L2-BUF-FLAG-IN-FENCE`:
+
+  - ``V4L2_BUF_FLAG_IN_FENCE``
+  - 0x0020
+  - Ask V4L2 to wait on the fence passed in the ``fence_fd`` field. The
+   buffer won't be queued to the driver until the fence signals. The order
+   in which buffers are queued is guaranteed to be preserved, so any
+   buffers queued after this buffer will also be blocked until this fence
+   signals. This flag must be set before calling ``VIDIOC_QBUF``. For
+   other ioctls the driver just reports the value of the flag.
+
+If the fence signals the flag is cleared and not reported anymore.
+   If the fence is not valid ``VIDIOC_QBUF`` returns an error.
+
+
+* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
+
+  - ``V4L2_BUF_FLAG_OUT_FENCE``
+  - 0x0040
+  - Request for a fence to be attached to the buffer. The driver will fill
+   in the out-fence fd in the ``fence_fd`` field when :ref:`VIDIOC_QBUF
+   ` returns. This flag must be set before calling
+   ``VIDIOC_QBUF``. For other ioctls the driver just reports the value of
+   the flag.
+
+If the creation of the out-fence fails ``VIDIOC_QBUF`` returns an
+   error.
 
 
 
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 64503615d00b..b1c0fa2b0b88 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->reserved2 = 0;
+   b->fence_fd = 0;
b->reserved = 0;
 
if (q->is_multiplanar) {
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 4312935f1dfc..93c752459aec 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -388,7 +388,7 @@ struct v4l2_buffer32 {
__s32   fd;
} m;
__u32   length;
-   __u32   

[PATCH v9 13/15] v4l: introduce the fences capability

[Ezequiel Garcia]

From: Gustavo Padovan 

Drivers capable of using fences (vb2 drivers) should report the
V4L2_CAP_FENCES to userspace, so add this flag to the uapi.

v2: minor doc/english fix (Hans Verkuil)

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 +++
 include/uapi/linux/videodev2.h   | 1 +
 2 files changed, 4 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 66fb1b3d6e6e..df3ad57f07a3 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -254,6 +254,9 @@ specification the ioctl returns an ``EINVAL`` error code.
 * - ``V4L2_CAP_TOUCH``
   - 0x1000
   - This is a touch device.
+* - ``V4L2_CAP_FENCES``
+  - 0x2000
+  - The device supports explicit synchronization.
 * - ``V4L2_CAP_DEVICE_CAPS``
   - 0x8000
   - The driver fills the ``device_caps`` field. This capability can
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 1f18dc68ecab..cab35fca7c7f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -460,6 +460,7 @@ struct v4l2_capability {
 #define V4L2_CAP_STREAMING  0x0400  /* streaming I/O ioctls */
 
 #define V4L2_CAP_TOUCH  0x1000  /* Is a touch device */
+#define V4L2_CAP_FENCES 0x2000  /* Supports explicit 
synchronization */
 
 #define V4L2_CAP_DEVICE_CAPS0x8000  /* sets device 
capabilities field */
 
-- 
2.16.3

[PATCH v9 15/15] v4l: Document explicit synchronization behavior

[Ezequiel Garcia]

From: Gustavo Padovan 

Add section to VIDIOC_QBUF and VIDIOC_QUERY_BUF about it

v8: amend querybuf documentation.

v7: minor issues and English improvements (Hans Verkuil)

v6: Close some gaps in the docs (Hans)

v5: - Remove V4L2_CAP_ORDERED
- Add doc about V4L2_FMT_FLAG_UNORDERED

v4: - Document ordering behavior for in-fences
- Document V4L2_CAP_ORDERED capability
- Remove doc about OUT_FENCE event
- Document immediate return of out-fence in QBUF

v3: - make the out_fence refer to the current buffer (Hans)
- Note what happens when the IN_FENCE is not set (Hans)

v2: - mention that fences are files (Hans)
- rework for the new API

Signed-off-by: Gustavo Padovan 
Signed-off-by: Ezequiel Garcia 
---
 Documentation/media/uapi/v4l/vidioc-qbuf.rst | 54 +++-
 Documentation/media/uapi/v4l/vidioc-querybuf.rst | 12 --
 2 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
index 9e448a4aa3aa..88a51b8bec7e 100644
--- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
@@ -54,7 +54,7 @@ When the buffer is intended for output (``type`` is
 or ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the
 ``bytesused``, ``field`` and ``timestamp`` fields, see :ref:`buffer`
 for details. Applications must also set ``flags`` to 0. The
-``reserved2`` and ``reserved`` fields must be set to 0. When using the
+``reserved`` field must be set to 0. When using the
 :ref:`multi-planar API `, the ``m.planes`` field must
 contain a userspace pointer to a filled-in array of struct
 :c:type:`v4l2_plane` and the ``length`` field must be set
@@ -118,6 +118,58 @@ immediately with an ``EAGAIN`` error code when no buffer 
is available.
 The struct :c:type:`v4l2_buffer` structure is specified in
 :ref:`buffer`.
 
+Explicit Synchronization
+
+
+Explicit Synchronization allows us to control the synchronization of
+shared buffers from userspace by passing fences to the kernel and/or
+receiving them from it. Fences passed to the kernel are named in-fences and
+the kernel should wait on them to signal before using the buffer. On the other
+side, the kernel can create out-fences for the buffers it queues to the
+drivers. Out-fences signal when the driver is finished with buffer, i.e., the
+buffer is ready. The fences are represented as a file and passed as a file
+descriptor to userspace.
+
+The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
+using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer flag and the `fence_fd` field. If
+an in-fence needs to be passed to the kernel, `fence_fd` should be set to the
+fence file descriptor number and the ``V4L2_BUF_FLAG_IN_FENCE`` should be set
+as well. Setting one but not the othe will cause ``VIDIOC_QBUF`` to return
+with an error.
+
+The videobuf2-core will guarantee that all buffers queued with an in-fence will
+be queued to the drivers in the same order. Fences may signal out of order, so
+this guarantee at videobuf2 is necessary to not change ordering. So when
+waiting on a fence to signal all buffers queued afterwards will also be blocked
+until that fence signals.
+
+If the in-fence signals with an error the buffer will be marked with
+``V4L2_BUF_FLAG_ERROR`` when returned to userspace at ``VIDIOC_DQBUF``.
+Even with the error the order of dequeueing the buffers is preserved.
+
+To get an out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag should
+be set to ask for a fence to be attached to the buffer. The out-fence fd is
+sent to userspace as a ``VIDIOC_QBUF`` return argument in the `fence_fd` field.
+
+Note the same `fence_fd` field is used for both sending the in-fence as
+at input argument and to receive the out-fence as a return argument. A buffer 
can
+have both an in-fence and an out-fence.
+
+At streamoff the out-fences will either signal normally if the driver waits
+for the operations on the buffers to finish or signal with an error if the
+driver cancels the pending operations. Buffers with in-fences won't be queued
+to the driver if their fences signal. They will be cleaned up.
+
+The ``V4L2_FMT_FLAG_UNORDERED`` flag in ``VIDIOC_ENUM_FMT`` tells userspace
+that the  when using this format the order in which buffers are dequeued can
+be different from the order in which they were queued.
+
+Ordering is important to fences because it can optimize the pipeline with
+other drivers like a DRM/KMS display driver. For example, if a capture from the
+camera is happening in an orderly manner one can send the capture buffer
+out-fence to the DRM/KMS driver and rest sure that the buffers will be shown on
+the screen at the correct order. If an ordered queue can not be set then such
+arrangements with other drivers may not be possible.
 
 Return Value
 

[PATCH v9 14/15] v4l: Add V4L2_CAP_FENCES to drivers

[Ezequiel Garcia]

From: Gustavo Padovan 

Drivers that use videobuf2 are capable of using fences and
should report that to userspace.

v9: Add in the core.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Ezequiel Garcia 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 8 
 include/media/v4l2-fh.h  | 2 --
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index f75ad954a6f2..2ae527ef0bc7 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1002,12 +1002,20 @@ static int v4l_querycap(const struct v4l2_ioctl_ops 
*ops,
 {
struct v4l2_capability *cap = (struct v4l2_capability *)arg;
struct video_device *vfd = video_devdata(file);
+   struct v4l2_fh *vfh =
+   test_bit(V4L2_FL_USES_V4L2_FH, >flags) ? fh : NULL;
int ret;
 
cap->version = LINUX_VERSION_CODE;
cap->device_caps = vfd->device_caps;
cap->capabilities = vfd->device_caps | V4L2_CAP_DEVICE_CAPS;
 
+   /* If it has a queue or a m2m context, then the
+* device supports fence synchronization.
+*/
+   if (vfd->queue || (vfh && vfh->m2m_ctx))
+   cap->device_caps |= V4L2_CAP_FENCES;
+
ret = ops->vidioc_querycap(file, fh, cap);
 
cap->capabilities |= V4L2_CAP_EXT_PIX_FORMAT;
diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
index ea73fef8bdc0..e993ddc06991 100644
--- a/include/media/v4l2-fh.h
+++ b/include/media/v4l2-fh.h
@@ -57,9 +57,7 @@ struct v4l2_fh {
unsigned intnavailable;
u32 sequence;
 
-#if IS_ENABLED(CONFIG_V4L2_MEM2MEM_DEV)
struct v4l2_m2m_ctx *m2m_ctx;
-#endif
 };
 
 /**
-- 
2.16.3

[PATCH v9 08/15] cobalt: set queue as unordered

[Ezequiel Garcia]

From: Gustavo Padovan 

The cobalt driver may reorder the capture buffers so we need to report
it as such.

v3: set unordered as a property
v2: use vb2_ops_set_unordered() helper

Signed-off-by: Gustavo Padovan 
Signed-off-by: Ezequiel Garcia 
---
 drivers/media/pci/cobalt/cobalt-v4l2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
b/drivers/media/pci/cobalt/cobalt-v4l2.c
index e2a4c705d353..8f06cc7f1c81 100644
--- a/drivers/media/pci/cobalt/cobalt-v4l2.c
+++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
@@ -1236,6 +1236,7 @@ static int cobalt_node_register(struct cobalt *cobalt, 
int node)
q->min_buffers_needed = 2;
q->lock = >lock;
q->dev = >pci_dev->dev;
+   q->unordered = 1;
vdev->queue = q;
 
video_set_drvdata(vdev, s);
-- 
2.16.3

[PATCH v9 06/15] v4l: add unordered flag to format description ioctl

[Ezequiel Garcia]

From: Gustavo Padovan 

For explicit synchronization it important for userspace to know if the
format being used by the driver can deliver the buffers back to userspace
in the same order they were queued with QBUF.

Ordered streams fits nicely in a pipeline with DRM for example, where
ordered buffer are expected.

v2: Improve documentation (Hans)

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 7 +++
 include/uapi/linux/videodev2.h   | 1 +
 2 files changed, 8 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst 
b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
index 019c513df217..df8e039b9ac2 100644
--- a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
+++ b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
@@ -116,6 +116,13 @@ one until ``EINVAL`` is returned.
   - This format is not native to the device but emulated through
software (usually libv4l2), where possible try to use a native
format instead for better performance.
+* - ``V4L2_FMT_FLAG_UNORDERED``
+  - 0x0004
+  - This format doesn't guarantee ordered buffer handling. I.e. the order
+   in which buffers are dequeued with
+   :ref:`VIDIOC_DQBUF ` may be different
+   from the order in which they were queued with
+   :ref:`VIDIOC_QBUF `.
 
 
 Return Value
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 600877be5c22..a8842a5ca636 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -717,6 +717,7 @@ struct v4l2_fmtdesc {
 
 #define V4L2_FMT_FLAG_COMPRESSED 0x0001
 #define V4L2_FMT_FLAG_EMULATED   0x0002
+#define V4L2_FMT_FLAG_UNORDERED  0x0004
 
/* Frame Size and frame rate enumeration */
 /*
-- 
2.16.3

Re: [PATCH 1/1] v4l: Add macros for printing V4L 4cc values

[Mauro Carvalho Chehab]

Em Wed,  4 Apr 2018 16:02:10 +0300
Sakari Ailus  escreveu:

> Add two macros that facilitate printing V4L fourcc values with printf
> family of functions. v4l2_fourcc_conv provides the printf conversion
> specifier for printing formats and v4l2_fourcc_to_conv provides the actual
> arguments for that conversion specifier.
> 
> These macros are useful in both user and kernel code, therefore put them
> into videodev2.h.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  include/uapi/linux/videodev2.h | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index caec178..93184929 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -82,6 +82,31 @@
>   ((__u32)(a) | ((__u32)(b) << 8) | ((__u32)(c) << 16) | ((__u32)(d) << 
> 24))
>  #define v4l2_fourcc_be(a, b, c, d)   (v4l2_fourcc(a, b, c, d) | (1 << 31))
>  
> +/**
> + * v4l2_fourcc_conv - Printf fourcc conversion specifiers for V4L2 formats
> + *
> + * Use as part of the format string. The values are obtained using
> + * @v4l2_fourcc_to_conv macro.
> + *
> + * Example ("format" is the V4L2 pixelformat in __u32):
> + *
> + * printf("V4L2 format is: " v4l2_fourcc_conv "\n", 
> v4l2_fourcc_to_conv(format);
> + */
> +#define v4l2_fourcc_conv "%c%c%c%c%s"
> +
> +/**
> + * v4l2_fourcc_to_conv - Arguments for V4L2 fourcc format conversion
> + *
> + * @fourcc: V4L2 pixelformat, as in __u32
> + *
> + * Yields to a comma-separated list of arguments for printf that matches with
> + * conversion specifiers provided by @v4l2_fourcc_conv.
> + */
> +#define v4l2_fourcc_to_conv(fourcc)  \
> + (fourcc) & 0x7f, ((fourcc) >> 8) & 0x7f, ((fourcc) >> 16) & 0x7f, \
> + ((fourcc) >> 24) & 0x7f, (fourcc) & (1 << 31) ? "-BE" : ""
> +

IMO, it doesn't make sense to have this at uAPI.


Thanks,
Mauro

Re: [PATCH 04/15] media: pxa_camera: remove the dmaengine compat need

[Mauro Carvalho Chehab]

Em Sun, 22 Apr 2018 13:06:12 +0200
Hans Verkuil  escreveu:

> On 04/02/2018 04:26 PM, Robert Jarzmik wrote:
> > From: Robert Jarzmik 
> > 
> > As the pxa architecture switched towards the dmaengine slave map, the
> > old compatibility mechanism to acquire the dma requestor line number and
> > priority are not needed anymore.
> > 
> > This patch simplifies the dma resource acquisition, using the more
> > generic function dma_request_slave_channel().
> > 
> > Signed-off-by: Robert Jarzmik   
> 
> Acked-by: Hans Verkuil 

I'm assuming that you'll be applying it together with other PXA patches.
So:

Acked-by: Mauro Carvalho Chehab 

Regards,
Mauro
> 
> Regards,
> 
>   Hans
> 
> > ---
> >  drivers/media/platform/pxa_camera.c | 22 +++---
> >  1 file changed, 3 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/media/platform/pxa_camera.c 
> > b/drivers/media/platform/pxa_camera.c
> > index c71a00736541..4c82d1880753 100644
> > --- a/drivers/media/platform/pxa_camera.c
> > +++ b/drivers/media/platform/pxa_camera.c
> > @@ -2357,8 +2357,6 @@ static int pxa_camera_probe(struct platform_device 
> > *pdev)
> > .src_maxburst = 8,
> > .direction = DMA_DEV_TO_MEM,
> > };
> > -   dma_cap_mask_t mask;
> > -   struct pxad_param params;
> > char clk_name[V4L2_CLK_NAME_SIZE];
> > int irq;
> > int err = 0, i;
> > @@ -2432,34 +2430,20 @@ static int pxa_camera_probe(struct platform_device 
> > *pdev)
> > pcdev->base = base;
> >  
> > /* request dma */
> > -   dma_cap_zero(mask);
> > -   dma_cap_set(DMA_SLAVE, mask);
> > -   dma_cap_set(DMA_PRIVATE, mask);
> > -
> > -   params.prio = 0;
> > -   params.drcmr = 68;
> > -   pcdev->dma_chans[0] =
> > -   dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > -, >dev, "CI_Y");
> > +   pcdev->dma_chans[0] = dma_request_slave_channel(>dev, "CI_Y");
> > if (!pcdev->dma_chans[0]) {
> > dev_err(>dev, "Can't request DMA for Y\n");
> > return -ENODEV;
> > }
> >  
> > -   params.drcmr = 69;
> > -   pcdev->dma_chans[1] =
> > -   dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > -, >dev, "CI_U");
> > +   pcdev->dma_chans[1] = dma_request_slave_channel(>dev, "CI_U");
> > if (!pcdev->dma_chans[1]) {
> > dev_err(>dev, "Can't request DMA for Y\n");
> > err = -ENODEV;
> > goto exit_free_dma_y;
> > }
> >  
> > -   params.drcmr = 70;
> > -   pcdev->dma_chans[2] =
> > -   dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > -, >dev, "CI_V");
> > +   pcdev->dma_chans[2] = dma_request_slave_channel(>dev, "CI_V");
> > if (!pcdev->dma_chans[2]) {
> > dev_err(>dev, "Can't request DMA for V\n");
> > err = -ENODEV;
> >   
> 



Thanks,
Mauro

Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 13:59:32 -0700
Tim Harvey  escreveu:

> On Mon, Apr 23, 2018 at 9:52 AM, Mark Brown  wrote:
> > On Mon, Apr 23, 2018 at 09:44:17AM -0700, Tim Harvey wrote:
> >  
> >> Could you add some detail to the commit explaining why we need to
> >> replace codec to component? I don't really know what that means.
> >> Please refer to a commit if the ASoC API is changing in some way we
> >> need to catch up with.  
> >
> > This is a big transition in the ASoC API which is nearing completion -
> > this driver is one of the last users of the CODEC struct, we've (well,
> > mainly Morimoto-san) been migrating things away from it to the more
> > general purpose component.  There's no one commit to point at really as
> > the two have coexisted for a while and we won't be able to finally
> > remove the CODEC struct until all the drivers have transitioned away.  
> 
> Mark,
> 
> Ok - thanks for the explanation!
> 
> Kuninori,
> 
> Sorry this took so long to get to. Tested on a GW5404
> 
> Tested-by: Tim Harvey 
> Acked-by: Tim Harvey 

In order to keep it together with the patches doing the removal of
the old API, it is probably better to apply this via ALSA tree:

Acked-by: Mauro Carvalho Chehab 

> 
> Regards,
> 
> Tim



Thanks,
Mauro

4.17-rc3 regression in UVC driver

[Sebastian Reichel]

Hi,

I just got the following error message every ms with 4.17-rc3 after
upgrading to for first ~192 seconds after system start (Debian
4.17~rc3-1~exp1 kernel) on my Thinkpad X250:

> uvcvideo: Failed to query (GET_MIN) UVC control 2 on unit 1: -32 (exp. 1).

I see /dev/video0 and /dev/video1. The first one seems to be
functional. The second one does not work and does not make
sense to me (the system has only one webcam). I did not try to
bisect anything. Here is some more information, that might
be useful:

> sre@earth ~ % mpv /dev/video1 
> Playing: /dev/video1
> [ffmpeg/demuxer] video4linux2,v4l2: ioctl(VIDIOC_G_INPUT): Inappropriate 
> ioctl for device
> [lavf] avformat_open_input() failed
> Failed to recognize file format.
> sre@earth ~ % udevadm info /dev/video0
> P: /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0
> N: video0
> E: DEVNAME=/dev/video0
> E: 
> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0
> E: MAJOR=81
> E: MINOR=0
> E: SUBSYSTEM=video4linux
> sre@earth ~ % udevadm info /dev/video1
> P: /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1
> N: video1
> E: DEVNAME=/dev/video1
> E: 
> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1
> E: MAJOR=81
> E: MINOR=1
> E: SUBSYSTEM=video4linux
> sre@earth ~ % lsusb -d 04ca:703c
> Bus 001 Device 004: ID 04ca:703c Lite-On Technology Corp. 

-- Sebastian


signature.asc
Description: PGP signature

[PATCH] media: pt3: no need to check if null for dvb_module_release()

[Mauro Carvalho Chehab]

Such check is already there at the routine. So, no need to
repeat it outside.

Cc: Akihiro Tsukada 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/pt3/pt3.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c
index b2d9fb976c9a..cbec5c42fcbc 100644
--- a/drivers/media/pci/pt3/pt3.c
+++ b/drivers/media/pci/pt3/pt3.c
@@ -619,10 +619,8 @@ static void pt3_cleanup_adapter(struct pt3_board *pt3, int 
index)
adap->fe->callback = NULL;
if (adap->fe->frontend_priv)
dvb_unregister_frontend(adap->fe);
-   if (adap->i2c_tuner)
-   dvb_module_release(adap->i2c_tuner);
-   if (adap->i2c_demod)
-   dvb_module_release(adap->i2c_demod);
+   dvb_module_release(adap->i2c_tuner);
+   dvb_module_release(adap->i2c_demod);
}
pt3_free_dmabuf(adap);
dvb_dmxdev_release(>dmxdev);
-- 
2.17.0

[PATCH] dma-buf: Remove unneeded stubs around sync_debug interfaces

[Ezequiel Garcia]

The sync_debug.h header is internal, and only used by
sw_sync.c. Therefore, SW_SYNC is always defined and there
is no need for the stubs. Remove them and make the code
simpler.

Signed-off-by: Ezequiel Garcia 
---
 drivers/dma-buf/sync_debug.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
index d615a89f774c..05e33f937ad0 100644
--- a/drivers/dma-buf/sync_debug.h
+++ b/drivers/dma-buf/sync_debug.h
@@ -62,8 +62,6 @@ struct sync_pt {
struct rb_node node;
 };
 
-#ifdef CONFIG_SW_SYNC
-
 extern const struct file_operations sw_sync_debugfs_fops;
 
 void sync_timeline_debug_add(struct sync_timeline *obj);
@@ -72,12 +70,4 @@ void sync_file_debug_add(struct sync_file *fence);
 void sync_file_debug_remove(struct sync_file *fence);
 void sync_dump(void);
 
-#else
-# define sync_timeline_debug_add(obj)
-# define sync_timeline_debug_remove(obj)
-# define sync_file_debug_add(fence)
-# define sync_file_debug_remove(fence)
-# define sync_dump()
-#endif
-
 #endif /* _LINUX_SYNC_H */
-- 
2.16.3

Re: [v3] [media] Use common error handling code in 19 functions

[Mauro Carvalho Chehab]

Em Fri, 4 May 2018 18:08:59 +0200
SF Markus Elfring  escreveu:

> > Adjust jump targets so that a bit of exception handling can be better
> > reused at the end of these functions.  
> 
> Why was this update suggestion rejected once more a moment ago?
> 
> https://patchwork.linuxtv.org/patch/47827/
> lkml.kernel.org/r/<57ef3a56-2578-1d5f-1268-348b49b0c...@users.sourceforge.net>
> https://lkml.org/lkml/2018/3/9/823

Taking just the first diff there as an example:


diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index 61a750fae465..17d05b05fa9d 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -656,18 +656,18 @@  static int dvb_dmxdev_start_feed(struct dmxdev *dmxdev,
tsfeed->priv = filter;
 
ret = tsfeed->set(tsfeed, feed->pid, ts_type, ts_pes, timeout);
-   if (ret < 0) {
-   dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed);
-   return ret;
-   }
+   if (ret < 0)
+   goto release_feed;
 
ret = tsfeed->start_filtering(tsfeed);
-   if (ret < 0) {
-   dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed);
-   return ret;
-   }
+   if (ret < 0)
+   goto release_feed;
 
return 0;
+
+release_feed:
+   dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed);
+   return ret;
 }

There's *nothing* wrong with the above. It works fine, avoids goto
and probably even produce the same code, as gcc will likely optimize
it. It is also easier to review, as the error handling is closer
to the code. On the other hand, there's nothing wrong on taking
the approach you're proposing.

In the end, using goto or not on error handling like the above is 
a matter of personal taste - and taste changes with time and with
developer. I really don't have time to keep reviewing patches that
are just churning the code just due to someone's personal taste.

I'm pretty sure if I start accepting things like that, someone
else would be on some future doing patches just reverting it,
and I would be likely having to apply them too.

So, except if the patch is really fixing something - e.g. a broken
error handling code, I'll just ignore such patches and mark as
rejected without further notice/comments from now on.


Thanks,
Mauro

[linuxtv-media:master 167/207] drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c:319:2: error: implicit declaration of function 'omapdss_unregister_display'

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git master
head:   53dcd70eb710607b2d4085ca91a433cd9feb7b41
commit: 771f7be87ff921e9a3d744febd606af39a150e14 [167/207] media: omapfb: 
omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 771f7be87ff921e9a3d744febd606af39a150e14
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
'omapfb_init_connections':
>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:8: error: implicit 
>> declaration of function 'omapdss_find_mgr_from_display' 
>> [-Werror=implicit-function-declaration]
 mgr = omapdss_find_mgr_from_display(def_dssdev);
   ^
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:6: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
 mgr = omapdss_find_mgr_from_display(def_dssdev);
 ^
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
'omapfb_find_default_display':
>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:13: error: implicit 
>> declaration of function 'omapdss_get_default_display_name' 
>> [-Werror=implicit-function-declaration]
 def_name = omapdss_get_default_display_name();
^~~~
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:11: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
 def_name = omapdss_get_default_display_name();
  ^
   cc1: some warnings being treated as errors
--
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 
'opa362_connect':
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:45:6: error: 
implicit declaration of function 'omapdss_device_is_connected' 
[-Werror=implicit-function-declaration]
 if (omapdss_device_is_connected(dssdev))
 ^~~
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 
'opa362_enable':
>> drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:91:6: error: 
>> implicit declaration of function 'omapdss_device_is_enabled' 
>> [-Werror=implicit-function-declaration]
 if (omapdss_device_is_enabled(dssdev))
 ^
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 
'opa362_probe':
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:210:7: error: 
implicit declaration of function 'omapdss_of_find_source_for_first_ep' 
[-Werror=implicit-function-declaration]
 in = omapdss_of_find_source_for_first_ep(node);
  ^~~
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:210:5: warning: 
assignment makes pointer from integer without a cast [-Wint-conversion]
 in = omapdss_of_find_source_for_first_ep(node);
^
>> drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:225:6: error: 
>> implicit declaration of function 'omapdss_register_output' 
>> [-Werror=implicit-function-declaration]
 r = omapdss_register_output(dssdev);
 ^~~
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 
'opa362_remove':
>> drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:243:2: error: 
>> implicit declaration of function 'omapdss_unregister_output' 
>> [-Werror=implicit-function-declaration]
 omapdss_unregister_output(>dssdev);
 ^
   cc1: some warnings being treated as errors
--
   drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function 
'tfp410_connect':
   drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:39:6: error: 
implicit declaration of function 'omapdss_device_is_connected' 
[-Werror=implicit-function-declaration]
 if (omapdss_device_is_connected(dssdev))
 ^~~
   drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function 
'tfp410_enable':
>> drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:81:6: error: 
>> implicit declaration of function 'omapdss_device_is_enabled' 
>> [-Werror=implicit-function-declaration]
 if (omapdss_device_is_enabled(dssdev))
 ^
   drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function 
'tfp410_probe_of':
   drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:184:7: error: 
implicit declaration of function 'omapdss_of_find_source_for_first_ep' 
[-Werror=implicit-function-declaration]
 in = omapdss_of_find_source_for_first_ep(node);
  ^~~
   

[linuxtv-media:master 167/207] drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:44: sparse: call with no type!

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git master
head:   53dcd70eb710607b2d4085ca91a433cd9feb7b41
commit: 771f7be87ff921e9a3d744febd606af39a150e14 [167/207] media: omapfb: 
omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
reproduce:
# apt-get install sparse
git checkout 771f7be87ff921e9a3d744febd606af39a150e14
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1461:32: sparse: expression 
using sizeof(void)
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1461:32: sparse: expression 
using sizeof(void)
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1924:25: sparse: expression 
using sizeof(void)
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1924:25: sparse: expression 
using sizeof(void)
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:15: sparse: undefined 
identifier 'omapdss_find_mgr_from_display'
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:20: sparse: undefined 
identifier 'omapdss_get_default_display_name'
>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:44: sparse: call with no 
>> type!
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:52: sparse: call with no 
type!
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
'omapfb_init_connections':
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:8: error: implicit 
declaration of function 'omapdss_find_mgr_from_display'; did you mean 
'omapfb_init_display'? [-Werror=implicit-function-declaration]
 mgr = omapdss_find_mgr_from_display(def_dssdev);
   ^
   omapfb_init_display
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:6: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
 mgr = omapdss_find_mgr_from_display(def_dssdev);
 ^
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
'omapfb_find_default_display':
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:13: error: implicit 
declaration of function 'omapdss_get_default_display_name'; did you mean 
'omapfb_find_default_display'? [-Werror=implicit-function-declaration]
 def_name = omapdss_get_default_display_name();
^~~~
omapfb_find_default_display
   drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:11: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
 def_name = omapdss_get_default_display_name();
  ^
   cc1: some warnings being treated as errors
--
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:45:13: sparse: 
undefined identifier 'omapdss_device_is_connected'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:66:9: sparse: 
undefined identifier 'omapdss_device_is_connected'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:67:14: sparse: 
undefined identifier 'omapdss_device_is_connected'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:88:14: sparse: 
undefined identifier 'omapdss_device_is_connected'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:91:13: sparse: 
undefined identifier 'omapdss_device_is_enabled'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:115:14: sparse: 
undefined identifier 'omapdss_device_is_enabled'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:210:14: sparse: 
undefined identifier 'omapdss_of_find_source_for_first_ep'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:225:13: sparse: 
undefined identifier 'omapdss_register_output'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:243:9: sparse: 
undefined identifier 'omapdss_unregister_output'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:245:9: sparse: 
undefined identifier 'omapdss_device_is_enabled'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:246:13: sparse: 
undefined identifier 'omapdss_device_is_enabled'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:249:9: sparse: 
undefined identifier 'omapdss_device_is_connected'
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:250:13: sparse: 
undefined identifier 'omapdss_device_is_connected'
>> drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:45:40: sparse: 
>> call with no type!
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:66:9: sparse: 
call with no type!
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:67:41: sparse: 
call with no type!
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:88:41: sparse: 
call with no type!
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:91:38: sparse: 
call with no type!
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:115:39: sparse: 
call with no type!
   drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:210:49: sparse: 
call with no type!
   

Re: [PATCH v4 10/14] media: ov772x: reconstruct s_frame_interval()

[Akinobu Mita]

2018-05-04 5:29 GMT+09:00 jacopo mondi :
> Hi Akinobu,
>thank you for the patch
>
> On Mon, Apr 30, 2018 at 02:13:09AM +0900, Akinobu Mita wrote:
>> This splits the s_frame_interval() in subdev video ops into selecting the
>> frame interval and setting up the registers.
>>
>> This is a preparatory change to avoid accessing registers under power
>> saving mode.
>>
>> Cc: Jacopo Mondi 
>> Cc: Laurent Pinchart 
>> Cc: Hans Verkuil 
>> Cc: Sakari Ailus 
>> Cc: Mauro Carvalho Chehab 
>> Signed-off-by: Akinobu Mita 
>> ---
>> * v4
>> - No changes
>>
>>  drivers/media/i2c/ov772x.c | 56 
>> +-
>>  1 file changed, 35 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
>> index edc013d..7ea157e 100644
>> --- a/drivers/media/i2c/ov772x.c
>> +++ b/drivers/media/i2c/ov772x.c
>> @@ -617,25 +617,16 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int 
>> enable)
>>   return 0;
>>  }
>>
>> -static int ov772x_set_frame_rate(struct ov772x_priv *priv,
>> -  struct v4l2_fract *tpf,
>> -  const struct ov772x_color_format *cfmt,
>> -  const struct ov772x_win_size *win)
>> +static unsigned int ov772x_select_fps(struct ov772x_priv *priv,
>> +  struct v4l2_fract *tpf)
>
> Please align to the open brace, as all the other functions in the
> driver.

OK.

> Also, is it worth making a function out of this? It is called from one
> place only... see below.
>
>>  {
>> - struct i2c_client *client = v4l2_get_subdevdata(>subdev);
>> - unsigned long fin = clk_get_rate(priv->clk);
>>   unsigned int fps = tpf->numerator ?
>>  tpf->denominator / tpf->numerator :
>>  tpf->denominator;
>>   unsigned int best_diff;
>> - unsigned int fsize;
>> - unsigned int pclk;
>>   unsigned int diff;
>>   unsigned int idx;
>>   unsigned int i;
>> - u8 clkrc = 0;
>> - u8 com4 = 0;
>> - int ret;
>>
>>   /* Approximate to the closest supported frame interval. */
>>   best_diff = ~0L;
>> @@ -646,7 +637,25 @@ static int ov772x_set_frame_rate(struct ov772x_priv 
>> *priv,
>>   best_diff = diff;
>>   }
>>   }
>> - fps = ov772x_frame_intervals[idx];
>> +
>> + return ov772x_frame_intervals[idx];
>> +}
>> +
>> +static int ov772x_set_frame_rate(struct ov772x_priv *priv,
>> +  unsigned int fps,
>> +  const struct ov772x_color_format *cfmt,
>> +  const struct ov772x_win_size *win)
>> +{
>> + struct i2c_client *client = v4l2_get_subdevdata(>subdev);
>> + unsigned long fin = clk_get_rate(priv->clk);
>> + unsigned int fsize;
>> + unsigned int pclk;
>> + unsigned int best_diff;
>
> Please keep variable declarations sorted as in other functions in the
> driver.

OK.

>> + unsigned int diff;
>> + unsigned int i;
>> + u8 clkrc = 0;
>> + u8 com4 = 0;
>> + int ret;
>>
>>   /* Use image size (with blankings) to calculate desired pixel clock. */
>>   switch (cfmt->com7 & OFMT_MASK) {
>> @@ -711,10 +720,6 @@ static int ov772x_set_frame_rate(struct ov772x_priv 
>> *priv,
>>   if (ret < 0)
>>   return ret;
>>
>> - tpf->numerator = 1;
>> - tpf->denominator = fps;
>> - priv->fps = tpf->denominator;
>> -
>>   return 0;
>>  }
>>
>> @@ -735,8 +740,20 @@ static int ov772x_s_frame_interval(struct v4l2_subdev 
>> *sd,
>>  {
>>   struct ov772x_priv *priv = to_ov772x(sd);
>>   struct v4l2_fract *tpf = >interval;
>> + unsigned int fps;
>> + int ret;
>> +
>> + fps = ov772x_select_fps(priv, tpf);
>
> That's the only caller of this function. I'm fine if you want to keep
> it as it is though.

I would like to keep ov772x_select_fps() because the function name is
self descriptive and imples it doesn't change HW registers.  So I feel
it helps readability a bit.

> Thanks
>j
>
>
>> +
>> + ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
>> + if (ret)
>> + return ret;
>>
>> - return ov772x_set_frame_rate(priv, tpf, priv->cfmt, priv->win);
>> + tpf->numerator = 1;
>> + tpf->denominator = fps;
>> + priv->fps = fps;
>> +
>> + return 0;
>>  }
>>
>>  static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
>> @@ -993,7 +1010,6 @@ static int ov772x_set_params(struct ov772x_priv *priv,
>>const struct ov772x_win_size *win)
>>  {
>>   struct i2c_client *client = v4l2_get_subdevdata(>subdev);
>> - struct v4l2_fract tpf;
>>   int ret;
>>   u8  val;
>>
>> @@ -1075,9 +1091,7 @@ static int 

Re: [v3] [media] Use common error handling code in 19 functions

[SF Markus Elfring]

> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of these functions.

Why was this update suggestion rejected once more a moment ago?

https://patchwork.linuxtv.org/patch/47827/
lkml.kernel.org/r/<57ef3a56-2578-1d5f-1268-348b49b0c...@users.sourceforge.net>
https://lkml.org/lkml/2018/3/9/823

Would you like to integrate such a source code transformation after any further 
adjustments?

Regards,
Markus

Re: [PATCH v3 1/3] [media] dvb_frontend: add S2X and misc. other enums

[Mauro Carvalho Chehab]

Em Tue, 13 Mar 2018 23:18:03 +0100
Daniel Scheller  escreveu:

> From: Daniel Scheller 
> 
> Additional enums:
>  * FEC ratios 1/4 and 1/3
>  * 64/128/256-APSK modulations (DVB-S2X)
>  * 15%, 10% and 5% rolloff factors (DVB-S2X)
>  * 64K transmission mode (DVB-T2)
> 
> Add these enums to the frontend.h docs exceptions aswell (uapi docs are
> updated separately).
> 
> Also, bump the DVB API version to 5.12 to make userspace aware of these
> new enums.

Series look good, except for one detail: how userspace would know if
a device supports S2(X) or not?

> 
> Signed-off-by: Daniel Scheller 
> ---
> v2 to v3:
> - All new enum patches squashed into one commit
> - DVB API bump to 5.12
> 
> Please take note of some additional things in the cover letter.
> 
>  Documentation/media/frontend.h.rst.exceptions |  9 +
>  drivers/media/dvb-core/dvb_frontend.c |  9 +
>  include/uapi/linux/dvb/frontend.h | 29 
> ++-
>  include/uapi/linux/dvb/version.h  |  2 +-
>  4 files changed, 43 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/media/frontend.h.rst.exceptions 
> b/Documentation/media/frontend.h.rst.exceptions
> index f7c4df620a52..c1643ce93426 100644
> --- a/Documentation/media/frontend.h.rst.exceptions
> +++ b/Documentation/media/frontend.h.rst.exceptions
> @@ -84,6 +84,9 @@ ignore symbol APSK_16
>  ignore symbol APSK_32
>  ignore symbol DQPSK
>  ignore symbol QAM_4_NR
> +ignore symbol APSK_64
> +ignore symbol APSK_128
> +ignore symbol APSK_256
>  
>  ignore symbol SEC_VOLTAGE_13
>  ignore symbol SEC_VOLTAGE_18
> @@ -117,6 +120,8 @@ ignore symbol FEC_AUTO
>  ignore symbol FEC_3_5
>  ignore symbol FEC_9_10
>  ignore symbol FEC_2_5
> +ignore symbol FEC_1_4
> +ignore symbol FEC_1_3
>  
>  ignore symbol TRANSMISSION_MODE_AUTO
>  ignore symbol TRANSMISSION_MODE_1K
> @@ -129,6 +134,7 @@ ignore symbol TRANSMISSION_MODE_C1
>  ignore symbol TRANSMISSION_MODE_C3780
>  ignore symbol TRANSMISSION_MODE_2K
>  ignore symbol TRANSMISSION_MODE_8K
> +ignore symbol TRANSMISSION_MODE_64K
>  
>  ignore symbol GUARD_INTERVAL_AUTO
>  ignore symbol GUARD_INTERVAL_1_128
> @@ -161,6 +167,9 @@ ignore symbol ROLLOFF_35
>  ignore symbol ROLLOFF_20
>  ignore symbol ROLLOFF_25
>  ignore symbol ROLLOFF_AUTO
> +ignore symbol ROLLOFF_15
> +ignore symbol ROLLOFF_10
> +ignore symbol ROLLOFF_5
>  
>  ignore symbol INVERSION_ON
>  ignore symbol INVERSION_OFF
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index a7ed16e0841d..52c76e32f864 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -2183,6 +2183,15 @@ static int dtv_set_frontend(struct dvb_frontend *fe)
>   break;
>   case SYS_DVBS2:
>   switch (c->rolloff) {
> + case ROLLOFF_5:
> + rolloff = 105;
> + break;
> + case ROLLOFF_10:
> + rolloff = 110;
> + break;
> + case ROLLOFF_15:
> + rolloff = 115;
> + break;
>   case ROLLOFF_20:
>   rolloff = 120;
>   break;
> diff --git a/include/uapi/linux/dvb/frontend.h 
> b/include/uapi/linux/dvb/frontend.h
> index 4f9b4551c534..8bf1c63627a2 100644
> --- a/include/uapi/linux/dvb/frontend.h
> +++ b/include/uapi/linux/dvb/frontend.h
> @@ -296,6 +296,8 @@ enum fe_spectral_inversion {
>   * @FEC_3_5:  Forward Error Correction Code 3/5
>   * @FEC_9_10: Forward Error Correction Code 9/10
>   * @FEC_2_5:  Forward Error Correction Code 2/5
> + * @FEC_1_4:  Forward Error Correction Code 1/4
> + * @FEC_1_3:  Forward Error Correction Code 1/3
>   *
>   * Please note that not all FEC types are supported by a given standard.
>   */
> @@ -313,6 +315,8 @@ enum fe_code_rate {
>   FEC_3_5,
>   FEC_9_10,
>   FEC_2_5,
> + FEC_1_4,
> + FEC_1_3,
>  };
>  
>  /**
> @@ -331,6 +335,9 @@ enum fe_code_rate {
>   * @APSK_32: 32-APSK modulation
>   * @DQPSK:   DQPSK modulation
>   * @QAM_4_NR:4-QAM-NR modulation
> + * @APSK_64: 64-APSK modulation
> + * @APSK_128:128-APSK modulation
> + * @APSK_256:256-APSK modulation
>   *
>   * Please note that not all modulations are supported by a given standard.
>   *
> @@ -350,6 +357,9 @@ enum fe_modulation {
>   APSK_32,
>   DQPSK,
>   QAM_4_NR,
> + APSK_64,
> + APSK_128,
> + APSK_256,
>  };
>  
>  /**
> @@ -374,6 +384,8 @@ enum fe_modulation {
>   *   Single Carrier (C=1) transmission mode (DTMB only)
>   * @TRANSMISSION_MODE_C3780:
>   *   Multi Carrier (C=3780) transmission mode (DTMB only)
> + * @TRANSMISSION_MODE_64K:
> + *   Transmission mode 64K
>   *
>   * Please note that not all transmission modes are supported by a given
>   * standard.
> @@ -388,6 +400,7 @@ enum fe_transmit_mode {
>   

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Maxime Ripard]

On Fri, May 04, 2018 at 03:57:48PM +0200, Paul Kocialkowski wrote:
> On Fri, 2018-05-04 at 15:40 +0200, Maxime Ripard wrote:
> > On Fri, May 04, 2018 at 02:04:38PM +0200, Paul Kocialkowski wrote:
> > > On Fri, 2018-05-04 at 11:15 +0200, Maxime Ripard wrote:
> > > > On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote:
> > > > > > > > > + reg = <0x01c0e000 0x1000>;
> > > > > > > > > + memory-region = <_memory>;
> > > > > > > > 
> > > > > > > > Since you made the CMA region the default one, you don't
> > > > > > > > need
> > > > > > > > to
> > > > > > > > tie
> > > > > > > > it to that device in particular (and you can drop it being
> > > > > > > > mandatory
> > > > > > > > from your binding as well).
> > > > > > > 
> > > > > > > What if another driver (or the system) claims memory from
> > > > > > > that
> > > > > > > zone
> > > > > > > and
> > > > > > > that the reserved memory ends up not being available for the
> > > > > > > VPU
> > > > > > > anymore?
> > > > > > > 
> > > > > > > Acccording to the reserved-memory documentation, the
> > > > > > > reusable
> > > > > > > property
> > > > > > > (that we need for dmabuf) puts a limitation that the device
> > > > > > > driver
> > > > > > > owning the region must be able to reclaim it back.
> > > > > > > 
> > > > > > > How does that work out if the CMA region is not tied to a
> > > > > > > driver
> > > > > > > in
> > > > > > > particular?
> > > > > > 
> > > > > > I'm not sure to get what you're saying. You have the property
> > > > > > linux,cma-default in your reserved region, so the behaviour
> > > > > > you
> > > > > > described is what you explicitly asked for.
> > > > > 
> > > > > My point is that I don't see how the driver can claim back (part
> > > > > of)
> > > > > the
> > > > > reserved area if the area is not explicitly attached to it.
> > > > > 
> > > > > Or is that mechanism made in a way that all drivers wishing to
> > > > > use
> > > > > the
> > > > > reserved memory area can claim it back from the system, but
> > > > > there is
> > > > > no
> > > > > priority (other than first-come first-served) for which drivers
> > > > > claims
> > > > > it back in case two want to use the same reserved region (in a
> > > > > scenario
> > > > > where there isn't enough memory to allow both drivers)?
> > > > 
> > > > This is indeed what happens. Reusable is to let the system use the
> > > > reserved memory for things like caches that can easily be dropped
> > > > when
> > > > a driver wants to use the memory in that reserved area. Once that
> > > > memory has been allocated, there's no claiming back, unless that
> > > > memory segment was freed of course.
> > > 
> > > Thanks for the clarification. So in our case, perhaps the best fit
> > > would
> > > be to make that area the default CMA pool so that we can be ensured
> > > that
> > > the whole 96 MiB is available for the VPU and that no other consumer
> > > of
> > > CMA will use it?
> > 
> > The best fit for what use case ? We already discussed this, and I
> > don't see any point in having two separate CMA regions. If you have a
> > reasonably sized region that will accomodate for both the VPU and
> > display engine, why would we want to split them?
> 
> The use case I have in mind is boilerplate use of the VPU with the
> display engine, say with DMAbuf.
> 
> It wasn't exactly clear in my memory whether we had decided that the CMA
> pool we use for the VPU should also be used for other CMA consumers (I
> realize that this is what we've been doing all along by having
> linux,cma-default; though).
> 
> The fact that the memory region will accomodate for both the display
> engine and the VPU is not straightforward IMO and I think this has to be
> an explicit choice that we take. I was under the impression that we
> chose the 96 MiB because that's what the Allwinner reference code does.
> Does the reference code also use this pool for display?

Yes

> I liked the idea of having 96 MiB fully reserved to the VPU because it
> allows us to provide a limit on the use case, such as "this guarantees N
> buffers for resolution foo in format bar". If the display engine also
> uses it, then the limit also depends on how many GEM buffers are
> allocated (unless I'm missing something).

This also guarantees that you take away a fifth of the RAM on some
boards. If we had yet another CMA pool of 64MB as is the multi_v7
defconfig, that's a third of your RAM that's gone, possibly for no
particular reason.

If we make the math, let's say that we are running a system with 4
planes used in 1080p, with 4 Bpp, in double buffering (which is
already an unlikely setup). Let's add on top of that that we're
decoding a 1080p video with 8 buffers pre-allocated with 2Bpp (in
YUV422). Which really seems extreme now :)

And we're at 80MB. My guess is that your memory bus is going to be
dead before you need to use all that memory.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)

Re: [PATCH] media: vsp1: cleanup a false positive warning

[Mauro Carvalho Chehab]

Em Fri, 4 May 2018 16:37:23 +0200
Geert Uytterhoeven  escreveu:

> Hi Mauro,
> 
> On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab
>  wrote:
> > With the new vsp1 code changes introduced by changeset
> > f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines 
> > dynamically"),
> > smatch complains with:
> > drivers/media/platform/vsp1/vsp1_drm.c:262 
> > vsp1_du_pipeline_setup_bru() error: we previously assumed 'pipe->bru' could 
> > be null (see line 180)
> >
> > This is a false positive, as, if pipe->bru is NULL, the brx
> > var will be different, with ends by calling a code that will
> > set pipe->bru to another value.
> >
> > Yet, cleaning this false positive is as easy as adding an explicit
> > check if pipe->bru is NULL.
> >
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> Thanks for your patch!
> 
> s/bru/brx/

Hah, yeah... there was a rename from bru->brx... 
I guess that confused me, as I saw this error before the renaming patch
(even though I wrote it to be applied after them) :-)

> 
> > --- a/drivers/media/platform/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> > @@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct 
> > vsp1_device *vsp1,
> > brx = >brs->entity;
> >
> > /* Switch BRx if needed. */
> > -   if (brx != pipe->brx) {
> > +   if (brx != pipe->brx || !pipe->brx) {
> > struct vsp1_entity *released_brx = NULL;
> >
> > /* Release our BRx if we have one. */  
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 



Thanks,
Mauro

[PATCH] media: lgdt330x: don't use an uninitialized state

[Mauro Carvalho Chehab]

If state is not initialized or is freed, we can't use it:
drivers/media/dvb-frontends/lgdt330x.c:920 lgdt330x_probe() error: 
potential null dereference 'state'.  (kzalloc returns null)
drivers/media/dvb-frontends/lgdt330x.c:920 lgdt330x_probe() error: we 
previously assumed 'state' could be null (see line 878)
drivers/media/dvb-frontends/lgdt330x.c:920 lgdt330x_probe() error: 
dereferencing freed memory 'state'

Fixes: 23ba635d45f5 ("media: lgdt330x: convert it to the new I2C binding way")
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/lgdt330x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/lgdt330x.c 
b/drivers/media/dvb-frontends/lgdt330x.c
index 927fd68e05ec..f6731738b073 100644
--- a/drivers/media/dvb-frontends/lgdt330x.c
+++ b/drivers/media/dvb-frontends/lgdt330x.c
@@ -917,7 +917,8 @@ static int lgdt330x_probe(struct i2c_client *client,
 
 error:
kfree(state);
-   dprintk(state, "ERROR\n");
+   if (debug)
+   dev_printk(KERN_DEBUG, >dev, "Error loading lgdt330x 
driver\n");
return -ENODEV;
 }
 struct dvb_frontend *lgdt330x_attach(const struct lgdt330x_config *_config,
-- 
2.17.0

Re: [PATCH v2] saa7164: Fix driver name in debug output

[kbuild test robot]

Hi Brad,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Brad-Love/saa7164-Fix-driver-name-in-debug-output/20180504-114908
base:   git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/pci/saa7164/saa7164-fw.c: In function 
'saa7164_downloadfirmware':
>> drivers/media/pci/saa7164/saa7164-fw.c:429:11: warning: format '%ld' expects 
>> argument of type 'long int', but argument 2 has type 'size_t {aka const 
>> unsigned int}' [-Wformat=]
   printk(KERN_ERR "saa7164: firmware incorrect size %ld != %u\n",
  ^~
fw->size, fwlength);


vim +429 drivers/media/pci/saa7164/saa7164-fw.c

   195  
   196  /* TODO: Excessive debug */
   197  /* Load the firmware. Optionally it can be in ROM or newer versions
   198   * can be on disk, saving the expense of the ROM hardware. */
   199  int saa7164_downloadfirmware(struct saa7164_dev *dev)
   200  {
   201  /* u32 second_timeout = 60 * SAA_DEVICE_TIMEOUT; */
   202  u32 tmp, filesize, version, err_flags, first_timeout, fwlength;
   203  u32 second_timeout, updatebootloader = 1, bootloadersize = 0;
   204  const struct firmware *fw = NULL;
   205  struct fw_header *hdr, *boothdr = NULL, *fwhdr;
   206  u32 bootloaderversion = 0, fwloadersize;
   207  u8 *bootloaderoffset = NULL, *fwloaderoffset;
   208  char *fwname;
   209  int ret;
   210  
   211  dprintk(DBGLVL_FW, "%s()\n", __func__);
   212  
   213  if (saa7164_boards[dev->board].chiprev == SAA7164_CHIP_REV2) {
   214  fwname = SAA7164_REV2_FIRMWARE;
   215  fwlength = SAA7164_REV2_FIRMWARE_SIZE;
   216  } else {
   217  fwname = SAA7164_REV3_FIRMWARE;
   218  fwlength = SAA7164_REV3_FIRMWARE_SIZE;
   219  }
   220  
   221  version = saa7164_getcurrentfirmwareversion(dev);
   222  
   223  if (version == 0x00) {
   224  
   225  second_timeout = 100;
   226  first_timeout = 100;
   227  err_flags = saa7164_readl(SAA_BOOTLOADERERROR_FLAGS);
   228  dprintk(DBGLVL_FW, "%s() err_flags = %x\n",
   229  __func__, err_flags);
   230  
   231  while (err_flags != SAA_DEVICE_IMAGE_BOOTING) {
   232  dprintk(DBGLVL_FW, "%s() err_flags = %x\n",
   233  __func__, err_flags);
   234  msleep(10); /* Checkpatch throws a < 20ms 
warning */
   235  
   236  if (err_flags & SAA_DEVICE_IMAGE_CORRUPT) {
   237  printk(KERN_ERR "%s() firmware 
corrupt\n",
   238  __func__);
   239  break;
   240  }
   241  if (err_flags & SAA_DEVICE_MEMORY_CORRUPT) {
   242  printk(KERN_ERR "%s() device memory 
corrupt\n",
   243  __func__);
   244  break;
   245  }
   246  if (err_flags & SAA_DEVICE_NO_IMAGE) {
   247  printk(KERN_ERR "%s() no first image\n",
   248  __func__);
   249  break;
   250  }
   251  if (err_flags & SAA_DEVICE_IMAGE_SEARCHING) {
   252  first_timeout -= 10;
   253  if (first_timeout == 0) {
   254  printk(KERN_ERR
   255  "%s() no first image\n",
   256  __func__);
   257  break;
   258  }
   259  } else if (err_flags & 
SAA_DEVICE_IMAGE_LOADING) {
   260  second_timeout -= 10;
   261  if (second_timeout == 0) {
   262  printk(KERN_ERR
   263  "%s() FW load time exceeded\n",
   264 

Re: [PATCH v4 12/14] media: ov772x: avoid accessing registers under power saving mode

[jacopo mondi]

Hi Akinobu,

On Fri, May 04, 2018 at 11:50:39PM +0900, Akinobu Mita wrote:
> 2018-05-04 6:03 GMT+09:00 jacopo mondi :
> > Hi Akinobu,
> >   let me see if I got this right...
> >
> > On Mon, Apr 30, 2018 at 02:13:11AM +0900, Akinobu Mita wrote:
> >> The set_fmt() in subdev pad ops, the s_ctrl() for subdev control handler,
> >> and the s_frame_interval() in subdev video ops could be called when the
> >> device is under power saving mode.  These callbacks for ov772x driver
> >> cause updating H/W registers that will fail under power saving mode.
> >>
> >> This avoids it by not apply any changes to H/W if the device is not powered
> >> up.  Instead the changes will be restored right after power-up.
> >>
> >> Cc: Jacopo Mondi 
> >> Cc: Laurent Pinchart 
> >> Cc: Hans Verkuil 
> >> Cc: Sakari Ailus 
> >> Cc: Mauro Carvalho Chehab 
> >> Signed-off-by: Akinobu Mita 
> >> ---
> >> * v4
> >> - No changes
> >>
> >>  drivers/media/i2c/ov772x.c | 79 
> >> +-
> >>  1 file changed, 64 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> >> index 3e6ca98..bd37169 100644
> >> --- a/drivers/media/i2c/ov772x.c
> >> +++ b/drivers/media/i2c/ov772x.c
> >> @@ -741,19 +741,30 @@ static int ov772x_s_frame_interval(struct 
> >> v4l2_subdev *sd,
> >>   struct ov772x_priv *priv = to_ov772x(sd);
> >>   struct v4l2_fract *tpf = >interval;
> >>   unsigned int fps;
> >> - int ret;
> >> + int ret = 0;
> >>
> >>   fps = ov772x_select_fps(priv, tpf);
> >>
> >> - ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
> >> - if (ret)
> >> - return ret;
> >> + mutex_lock(>lock);
> >> + /*
> >> +  * If the device is not powered up by the host driver do
> >> +  * not apply any changes to H/W at this time. Instead
> >> +  * the frame rate will be restored right after power-up.
> >> +  */
> >> + if (priv->power_count > 0) {
> >
> > If I'm not wrong this is not protected when the device is
> > streaming.
> >
> > Since Hans' series frame control is called by g/s_parm (until a new
> > ioctl is not introduced) and I've looked at the call stack and it
> > seems to me it does not check for active streaming[1]. I -think-
> > this is even worse when this is called on the subdev, as there is
> > no shared notion of active streaming. Am I wrong?
> >
> > If you have to check for active streaming here (I see some other
> > drivers doing that, eg ov5640), then I see two ways, or you just
> > return -EBUSY, or you save the desired FPS for later, but then it gets
> > messy as you won't be able to just restore paramters at power_on()
> > time, but you would need to do that also at start streaming time.
> >
> > My opinion is that you should check for streaming active (as you're
> > doing for the set_fmt() function in [13/14], do you agree?
>
> I agree.  I would like to make ov772x_s_frame_interval() return -EBUSY
> without saving the desired FPS for later when the device is streaming.
>
> I'm going to prepare v5 patches that address the above and other issues
> you found in v4 unless you prefer the incremental patch series.

Thank you. Please send v5, the incremental patches thing only applies
to new developments and fixes not already part of this series.

Thanks
   j

>
> > [1] This calls for a device wise 'streaming' state handler. Maybe it's
> > there but I failed to find checks for that.


signature.asc
Description: PGP signature

Re: [PATCH v4 12/14] media: ov772x: avoid accessing registers under power saving mode

[Akinobu Mita]

2018-05-04 6:03 GMT+09:00 jacopo mondi :
> Hi Akinobu,
>   let me see if I got this right...
>
> On Mon, Apr 30, 2018 at 02:13:11AM +0900, Akinobu Mita wrote:
>> The set_fmt() in subdev pad ops, the s_ctrl() for subdev control handler,
>> and the s_frame_interval() in subdev video ops could be called when the
>> device is under power saving mode.  These callbacks for ov772x driver
>> cause updating H/W registers that will fail under power saving mode.
>>
>> This avoids it by not apply any changes to H/W if the device is not powered
>> up.  Instead the changes will be restored right after power-up.
>>
>> Cc: Jacopo Mondi 
>> Cc: Laurent Pinchart 
>> Cc: Hans Verkuil 
>> Cc: Sakari Ailus 
>> Cc: Mauro Carvalho Chehab 
>> Signed-off-by: Akinobu Mita 
>> ---
>> * v4
>> - No changes
>>
>>  drivers/media/i2c/ov772x.c | 79 
>> +-
>>  1 file changed, 64 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
>> index 3e6ca98..bd37169 100644
>> --- a/drivers/media/i2c/ov772x.c
>> +++ b/drivers/media/i2c/ov772x.c
>> @@ -741,19 +741,30 @@ static int ov772x_s_frame_interval(struct v4l2_subdev 
>> *sd,
>>   struct ov772x_priv *priv = to_ov772x(sd);
>>   struct v4l2_fract *tpf = >interval;
>>   unsigned int fps;
>> - int ret;
>> + int ret = 0;
>>
>>   fps = ov772x_select_fps(priv, tpf);
>>
>> - ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
>> - if (ret)
>> - return ret;
>> + mutex_lock(>lock);
>> + /*
>> +  * If the device is not powered up by the host driver do
>> +  * not apply any changes to H/W at this time. Instead
>> +  * the frame rate will be restored right after power-up.
>> +  */
>> + if (priv->power_count > 0) {
>
> If I'm not wrong this is not protected when the device is
> streaming.
>
> Since Hans' series frame control is called by g/s_parm (until a new
> ioctl is not introduced) and I've looked at the call stack and it
> seems to me it does not check for active streaming[1]. I -think-
> this is even worse when this is called on the subdev, as there is
> no shared notion of active streaming. Am I wrong?
>
> If you have to check for active streaming here (I see some other
> drivers doing that, eg ov5640), then I see two ways, or you just
> return -EBUSY, or you save the desired FPS for later, but then it gets
> messy as you won't be able to just restore paramters at power_on()
> time, but you would need to do that also at start streaming time.
>
> My opinion is that you should check for streaming active (as you're
> doing for the set_fmt() function in [13/14], do you agree?

I agree.  I would like to make ov772x_s_frame_interval() return -EBUSY
without saving the desired FPS for later when the device is streaming.

I'm going to prepare v5 patches that address the above and other issues
you found in v4 unless you prefer the incremental patch series.

> [1] This calls for a device wise 'streaming' state handler. Maybe it's
> there but I failed to find checks for that.

Re: [PATCH v2 15/19] [media] ddbridge: initial support for MCI-based MaxSX8 cards

[Mauro Carvalho Chehab]

Em Mon,  9 Apr 2018 18:47:48 +0200
Daniel Scheller  escreveu:

> From: Daniel Scheller 
> 
> This adds initial support for the new MCI-based (micro-code interface)
> DD cards, with the first one being the MaxSX8 eight-tuner DVB-S/S2/S2X
> PCIe card. The MCI is basically a generalized interface implemented in
> the card's FPGA firmware and usable for all kind of cards, without the
> need to implement any demod/tuner drivers as this interface "hides" any
> I2C interface to the actual ICs, in other words any required driver is
> implemented in the card firmware.
> 
> At this stage, the MCI interface is quite rudimentary with things like
> signal statistics reporting missing, but is already working to serve
> DVB streams to DVB applications. Missing functionality will be enabled
> over time.
> 
> This implements only the ddbridge-mci sub-object and hooks it up to the
> Makefile so the object gets build. The upcoming commits hook this module
> into all other ddbridge parts where required, including device IDs etc.
> 
> Picked up from the upstream dddvb-0.9.33 release.

There are three checkpatch issues to be handled here:

WARNING: function definition argument 'int' should also have an identifier name
#764: FILE: drivers/media/pci/ddbridge/ddbridge-mci.h:147:
+struct dvb_frontend

WARNING: function definition argument 'struct dvb_frontend *' should also have 
an identifier name
#764: FILE: drivers/media/pci/ddbridge/ddbridge-mci.h:147:
+struct dvb_frontend

WARNING: function definition argument 'int' should also have an identifier name
#764: FILE: drivers/media/pci/ddbridge/ddbridge-mci.h:147:
+struct dvb_frontend

Please submit a patch later addressing it.

> 
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/pci/ddbridge/Makefile   |   2 +-
>  drivers/media/pci/ddbridge/ddbridge-mci.c | 550 
> ++
>  drivers/media/pci/ddbridge/ddbridge-mci.h | 152 +
>  3 files changed, 703 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/pci/ddbridge/ddbridge-mci.c
>  create mode 100644 drivers/media/pci/ddbridge/ddbridge-mci.h
> 
> diff --git a/drivers/media/pci/ddbridge/Makefile 
> b/drivers/media/pci/ddbridge/Makefile
> index 745b37d07558..9b9e35f171b7 100644
> --- a/drivers/media/pci/ddbridge/Makefile
> +++ b/drivers/media/pci/ddbridge/Makefile
> @@ -4,7 +4,7 @@
>  #
>  
>  ddbridge-objs := ddbridge-main.o ddbridge-core.o ddbridge-ci.o \
> - ddbridge-hw.o ddbridge-i2c.o ddbridge-max.o
> + ddbridge-hw.o ddbridge-i2c.o ddbridge-max.o ddbridge-mci.o
>  
>  obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
>  
> diff --git a/drivers/media/pci/ddbridge/ddbridge-mci.c 
> b/drivers/media/pci/ddbridge/ddbridge-mci.c
> new file mode 100644
> index ..214b301f30a5
> --- /dev/null
> +++ b/drivers/media/pci/ddbridge/ddbridge-mci.c
> @@ -0,0 +1,550 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ddbridge-mci.c: Digital Devices microcode interface
> + *
> + * Copyright (C) 2017 Digital Devices GmbH
> + *Ralph Metzler 
> + *Marcus Metzler 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 only, as published by the Free Software Foundation.
> + *
> + * 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 "ddbridge.h"
> +#include "ddbridge-io.h"
> +#include "ddbridge-mci.h"
> +
> +static LIST_HEAD(mci_list);
> +
> +static const u32 MCLK = (155000 / 12);
> +static const u32 MAX_DEMOD_LDPC_BITRATE = (155000 / 6);
> +static const u32 MAX_LDPC_BITRATE = (72000);
> +
> +struct mci_base {
> + struct list_head mci_list;
> + void*key;
> + struct ddb_link *link;
> + struct completioncompletion;
> +
> + struct device   *dev;
> + struct mutex tuner_lock; /* concurrent tuner access lock */
> + u8   adr;
> + struct mutex mci_lock; /* concurrent MCI access lock */
> + int  count;
> +
> + u8   tuner_use_count[4];
> + u8   assigned_demod[8];
> + u32  used_ldpc_bitrate[8];
> + u8   demod_in_use[8];
> + u32  iq_mode;
> +};
> +
> +struct mci {
> + struct mci_base *base;
> + struct dvb_frontend  fe;
> + int  nr;
> + int  demod;
> + int  tuner;
> + int  first_time_lock;
> + int  started;
> + struct mci_resultsignal_info;
> +
> + u32  

Re: [PATCH 2/2] media: imx: add support for RGB565_2X8 on parallel bus

[Jan Lübbe]

On Fri, 2018-05-04 at 13:07 +0800, kbuild test robot wrote:
>drivers/staging/media/imx/imx-media-csi.c: In function
> 'csi_setup':
> >> drivers/staging/media/imx/imx-media-csi.c:652:8: warning:
> assignment discards 'const' qualifier from pointer target type [-
> Wdiscarded-qualifiers]
>  outcc = priv->cc[priv->active_output_pad];
>^

I've fixed this and the unneeded semicolon for the next round.

Regards,
Jan
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] media: vsp1: cleanup a false positive warning

[Geert Uytterhoeven]

Hi Mauro,

On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab
 wrote:
> With the new vsp1 code changes introduced by changeset
> f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines 
> dynamically"),
> smatch complains with:
> drivers/media/platform/vsp1/vsp1_drm.c:262 
> vsp1_du_pipeline_setup_bru() error: we previously assumed 'pipe->bru' could 
> be null (see line 180)
>
> This is a false positive, as, if pipe->bru is NULL, the brx
> var will be different, with ends by calling a code that will
> set pipe->bru to another value.
>
> Yet, cleaning this false positive is as easy as adding an explicit
> check if pipe->bru is NULL.
>
> Signed-off-by: Mauro Carvalho Chehab 

Thanks for your patch!

s/bru/brx/

> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device 
> *vsp1,
> brx = >brs->entity;
>
> /* Switch BRx if needed. */
> -   if (brx != pipe->brx) {
> +   if (brx != pipe->brx || !pipe->brx) {
> struct vsp1_entity *released_brx = NULL;
>
> /* Release our BRx if we have one. */

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

On Friday, May 04, 2018 11:07:01 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:19:31 +0200
> Bartlomiej Zolnierkiewicz  escreveu:
> 
> 
> > How's about just allowing COMPILE_TEST for FB_VIA instead of adding
> > all these stubs?
> 
> Works for me.
> 
> Do you want to apply it via your tree or via the media one?
> 
> If you prefer to apply on yours:
> 
> Reviewed-by: Mauro Carvalho Chehab 

Thanks, I'll apply it to my tree later.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH] media: video-i2c: get rid of two gcc warnings

[Mauro Carvalho Chehab]

After adding this driver, gcc complains with:

drivers/media/i2c/video-i2c.c:55:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static struct v4l2_fmtdesc amg88xx_format = {
 ^
drivers/media/i2c/video-i2c.c:59:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static struct v4l2_frmsize_discrete amg88xx_size = {
 ^

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

diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
index 971eb46c87f6..0b347cc19aa5 100644
--- a/drivers/media/i2c/video-i2c.c
+++ b/drivers/media/i2c/video-i2c.c
@@ -52,11 +52,11 @@ struct video_i2c_data {
struct list_head vid_cap_active;
 };
 
-const static struct v4l2_fmtdesc amg88xx_format = {
+static const struct v4l2_fmtdesc amg88xx_format = {
.pixelformat = V4L2_PIX_FMT_Y12,
 };
 
-const static struct v4l2_frmsize_discrete amg88xx_size = {
+static const struct v4l2_frmsize_discrete amg88xx_size = {
.width = 8,
.height = 8,
 };
-- 
2.17.0

Re: atomisp: drop from staging ?

[Mauro Carvalho Chehab]

Em Thu, 3 May 2018 11:30:50 +0300
Sakari Ailus  escreveu:

> On Mon, Apr 30, 2018 at 12:41:00PM +0300, Sakari Ailus wrote:
> > Hi Alan,
> > 
> > On Sun, Apr 29, 2018 at 01:18:37AM +0100, Alan Cox wrote:  
> > > 
> > > I think this is going to be the best option. When I started cleaning up
> > > the atomisp code I had time to work on it. Then spectre/meltdown
> > > happened (which btw is why the updating suddenly and mysteriously stopped
> > > last summer).
> > > 
> > > I no longer have time to work on it and it's becoming evident that the
> > > world of speculative side channel is going to be mean that I am
> > > not going to get time in the forseeable future despite me trying to find
> > > space to get back into atomisp cleaning up. It sucks because we made some
> > > good initial progress but shit happens.
> > > 
> > > There are at this point (unsurprisngly ;)) no other volunteers I can
> > > find crazy enough to take this on.  
> > 
> > The driver has been in the staging tree for quite some time now and is a
> > regular target of cleanup patches but little has been done to address the
> > growing list of entries in the associated TODO file to get it out of
> > staging. Beyond this, I don't have the hardware but as far as I understand,
> > the driver is not functional in its current state.
> > 
> > I agree with removing the driver. It can always be brought back if someone
> > wishes to continue working it.
> > 
> > I can send patches to remove it.  
> 
> The patch didn't make it to the list likely because it was too big --- even
> with -D option to git format-patch!
> 
> It's here:
> 
> 

I really hate remove things like that, but atomisp is on real bad shape.
I'm wandering if at least the sensor drivers could be converted before
dropping it.

That's said, I don't have atomisp hardware either, and, even if I had,
I probably won't have enough time to fix it. So, if you all won't be
able to do any work on it any time soon, and that's what you want
for now, I'm ok with removing it.

Sakari,

Please send me a pull request with the driver removal patch and I'll
apply it.


Thanks,
Mauro

[PATCH 2/7 v2] media: meye: allow building it with COMPILE_TEST on non-x86

[Mauro Carvalho Chehab]

From: Mauro Carvalho Chehab 

This driver depends on sony-laptop driver, but this is available
only for x86. So, add a stub function, in order to allow building
it on non-x86 too.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/meye/Kconfig | 3 ++-
 include/linux/sony-laptop.h| 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/meye/Kconfig b/drivers/media/pci/meye/Kconfig
index b4bf848be5a0..2e60334ffef5 100644
--- a/drivers/media/pci/meye/Kconfig
+++ b/drivers/media/pci/meye/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_MEYE
tristate "Sony Vaio Picturebook Motion Eye Video For Linux"
-   depends on PCI && SONY_LAPTOP && VIDEO_V4L2
+   depends on PCI && VIDEO_V4L2
+   depends on SONY_LAPTOP || COMPILE_TEST
---help---
  This is the video4linux driver for the Motion Eye camera found
  in the Vaio Picturebook laptops. Please read the material in
diff --git a/include/linux/sony-laptop.h b/include/linux/sony-laptop.h
index 1a4b77317fa1..374d0fdb0743 100644
--- a/include/linux/sony-laptop.h
+++ b/include/linux/sony-laptop.h
@@ -28,7 +28,11 @@
 #define SONY_PIC_COMMAND_GETCAMERAROMVERSION   18  /* obsolete */
 #define SONY_PIC_COMMAND_GETCAMERAREVISION 19  /* obsolete */
 
+#if IS_ENABLED(CONFIG_SONY_LAPTOP)
 int sony_pic_camera_command(int command, u8 value);
+#else
+static inline int sony_pic_camera_command(int command, u8 value) { return 0; };
+#endif
 
 #endif /* __KERNEL__ */
 
-- 
2.17.0

[PATCH] dma-fence: Make ->enable_signaling optional

[Daniel Vetter]

Many drivers have a trivial implementation for ->enable_signaling.
Let's make it optional by assuming that signalling is already
available when the callback isn't present.

v2: Don't do the trick to set the ENABLE_SIGNAL_BIT
unconditionally, it results in an expensive spinlock take for
everyone. Instead just check if the callback is present. Suggested by
Maarten.

Also move misplaced kerneldoc hunk to the right patch.

Cc: Maarten Lankhorst 
Reviewed-by: Christian König  (v1)
Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/dma-fence.c | 9 +
 include/linux/dma-fence.h   | 3 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 4edb9fd3cf47..dd01a1720be9 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -200,7 +200,8 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence)
 
if (!test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
  >flags) &&
-   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags) &&
+   fence->ops->enable_signaling) {
trace_dma_fence_enable_signal(fence);
 
spin_lock_irqsave(fence->lock, flags);
@@ -260,7 +261,7 @@ int dma_fence_add_callback(struct dma_fence *fence, struct 
dma_fence_cb *cb,
 
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
ret = -ENOENT;
-   else if (!was_set) {
+   else if (!was_set && fence->ops->enable_signaling) {
trace_dma_fence_enable_signal(fence);
 
if (!fence->ops->enable_signaling(fence)) {
@@ -388,7 +389,7 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, 
signed long timeout)
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
goto out;
 
-   if (!was_set) {
+   if (!was_set && fence->ops->enable_signaling) {
trace_dma_fence_enable_signal(fence);
 
if (!fence->ops->enable_signaling(fence)) {
@@ -560,7 +561,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
dma_fence_ops *ops,
   spinlock_t *lock, u64 context, unsigned seqno)
 {
BUG_ON(!lock);
-   BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
+   BUG_ON(!ops || !ops->wait ||
   !ops->get_driver_name || !ops->get_timeline_name);
 
kref_init(>refcount);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 111aefe1c956..c053d19e1e24 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -166,7 +166,8 @@ struct dma_fence_ops {
 * released when the fence is signalled (through e.g. the interrupt
 * handler).
 *
-* This callback is mandatory.
+* This callback is optional. If this callback is not present, then the
+* driver must always have signaling enabled.
 */
bool (*enable_signaling)(struct dma_fence *fence);
 
-- 
2.17.0

[PATCH v12 1/4] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on
the hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Rob Herring 
Acked-by: Benoit Parrot 
Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2rx.txt | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
new file mode 100644
index ..6b02a0657ad9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
@@ -0,0 +1,100 @@
+Cadence MIPI-CSI2 RX controller
+===
+
+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+lanes in input, and 4 different pixel streams in output.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* sys_clk: main clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties:
+  - phys: phandle to the external D-PHY, phy-names must be provided
+  - phy-names: must contain "dphy", if the implementation uses an
+   external D-PHY
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes are numbered as follows:
+
+   Port Description
+   -
+   0CSI-2 input
+   1Stream 0 output
+   2Stream 1 output
+   3Stream 2 output
+   4Stream 3 output
+
+   The stream output port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design.Since there is only one endpoint per port,
+   the endpoints are not numbered.
+
+
+Example:
+
+csi2rx: csi-bridge@0d06 {
+   compatible = "cdns,csi2rx";
+   reg = <0x0d06 0x1000>;
+   clocks = <>, <>
+<>, <>,
+<>, <>;
+   clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2rx_in_sensor: endpoint {
+   remote-endpoint = <_out_csi2rx>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2rx_out_grabber0: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2rx_out_grabber1: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2rx_out_grabber2: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2rx_out_grabber3: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+   };
+};
-- 
2.17.0

[PATCH v12 2/4] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Maxime Ripard]

The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
bridge between a CSI-2 bus and pixel grabbers.

It supports operating with internal or external D-PHY, with up to 4 lanes,
or without any D-PHY. The current code only supports the latter case.

It also support dynamic mapping of the CSI-2 virtual channels to the
associated pixel grabbers, but that isn't allowed at the moment either.

Acked-by: Benoit Parrot 
Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 MAINTAINERS  |   7 +
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   1 +
 drivers/media/platform/cadence/Kconfig   |  23 +
 drivers/media/platform/cadence/Makefile  |   3 +
 drivers/media/platform/cadence/cdns-csi2rx.c | 498 +++
 6 files changed, 533 insertions(+)
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d5a621..2c27d39611eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3133,6 +3133,13 @@ S:   Supported
 F: Documentation/filesystems/caching/cachefiles.txt
 F: fs/cachefiles/
 
+CADENCE MIPI-CSI2 BRIDGES
+M: Maxime Ripard 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/cdns,*.txt
+F: drivers/media/platform/cadence/cdns-csi2*
+
 CADET FM/AM RADIO RECEIVER DRIVER
 M: Hans Verkuil 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8a1b01..029340ec3da4 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
 #
 # Platform multimedia device configuration
 #
+source "drivers/media/platform/cadence/Kconfig"
 
 source "drivers/media/platform/davinci/Kconfig"
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515df4477..04bc1502a30e 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -3,6 +3,7 @@
 # Makefile for the video capture/playback device drivers.
 #
 
+obj-$(CONFIG_VIDEO_CADENCE)+= cadence/
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
 obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
 obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
new file mode 100644
index ..70c95d79c8f7
--- /dev/null
+++ b/drivers/media/platform/cadence/Kconfig
@@ -0,0 +1,23 @@
+config VIDEO_CADENCE
+   bool "Cadence Video Devices"
+   help
+ If you have a media device designed by Cadence, say Y.
+
+ Note that this option doesn't include new drivers in the kernel:
+ saying N will just cause Kconfig to skip all the questions about
+ Cadence media devices.
+
+if VIDEO_CADENCE
+
+config VIDEO_CADENCE_CSI2RX
+   tristate "Cadence MIPI-CSI2 RX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ Support for the Cadence MIPI CSI2 Receiver controller.
+
+ To compile this driver as a module, choose M here: the module will be
+ called cdns-csi2rx.
+
+endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
new file mode 100644
index ..388e4f8c3b90
--- /dev/null
+++ b/drivers/media/platform/cadence/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
new file mode 100644
index ..fe612ec1f99f
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -0,0 +1,498 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 RX Controller v1.3
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2RX_DEVICE_CFG_REG  0x000
+
+#define CSI2RX_SOFT_RESET_REG  0x004
+#define CSI2RX_SOFT_RESET_PROTOCOL BIT(1)
+#define CSI2RX_SOFT_RESET_FRONTBIT(0)
+
+#define CSI2RX_STATIC_CFG_REG  0x008
+#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)  ((plane) << (16 + 
(llane) * 4))
+#define CSI2RX_STATIC_CFG_LANES_MASK   GENMASK(11, 8)
+
+#define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
+
+#define 

[PATCH v12 3/4] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is a CSI2 bridge that supports up to 4
video streams and can output on up to 4 CSI-2 lanes, depending on the
hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Benoit Parrot 
Acked-by: Rob Herring 
Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2tx.txt | 98 +++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
new file mode 100644
index ..459c6e332f52
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
@@ -0,0 +1,98 @@
+Cadence MIPI-CSI2 TX controller
+===
+
+The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to
+4 CSI lanes in output, and up to 4 different pixel streams in input.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2tx"
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* esc_clk: escape mode clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties
+  - phys: phandle to the D-PHY. If it is set, phy-names need to be set
+  - phy-names: must contain "dphy"
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes are numbered as follows.
+
+   Port Description
+   -
+   0CSI-2 output
+   1Stream 0 input
+   2Stream 1 input
+   3Stream 2 input
+   4Stream 3 input
+
+   The stream input port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design. Since there is only one endpoint per port,
+   the endpoints are not numbered.
+
+Example:
+
+csi2tx: csi-bridge@0d0e1000 {
+   compatible = "cdns,csi2tx";
+   reg = <0x0d0e1000 0x1000>;
+   clocks = <>, <>,
+<>, <>,
+<>, <>;
+   clock-names = "p_clk", "esc_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2tx_out: endpoint {
+   remote-endpoint = <_in>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2tx_in_stream0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2tx_in_stream1: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2tx_in_stream2: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2tx_in_stream3: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
2.17.0

[PATCH v12 4/4] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
as a bridge between pixel interfaces and a CSI-2 bus.

It supports operating with an internal or external D-PHY, with up to 4
lanes, or without any D-PHY. The current code only supports the latter
case.

While the virtual channel input on the pixel interface can be directly
mapped to CSI2, the datatype input is actually a selection signal (3-bits)
mapping to a table of up to 8 preconfigured datatypes/formats (programmed
at start-up)

The block supports up to 8 input datatypes.

Acked-by: Benoit Parrot 
Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/cadence/Kconfig   |  11 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c | 563 +++
 3 files changed, 575 insertions(+)
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
index 70c95d79c8f7..3bf0f2454384 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -20,4 +20,15 @@ config VIDEO_CADENCE_CSI2RX
  To compile this driver as a module, choose M here: the module will be
  called cdns-csi2rx.
 
+config VIDEO_CADENCE_CSI2TX
+   tristate "Cadence MIPI-CSI2 TX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ Support for the Cadence MIPI CSI2 Transceiver controller.
+
+ To compile this driver as a module, choose M here: the module will be
+ called cdns-csi2tx.
+
 endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
index 388e4f8c3b90..be59a8728a01 100644
--- a/drivers/media/platform/cadence/Makefile
+++ b/drivers/media/platform/cadence/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
+obj-$(CONFIG_VIDEO_CADENCE_CSI2TX) += cdns-csi2tx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
b/drivers/media/platform/cadence/cdns-csi2tx.c
new file mode 100644
index ..dfa1d88d955b
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2tx.c
@@ -0,0 +1,563 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 TX Controller
+ *
+ * Copyright (C) 2017-2018 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2TX_DEVICE_CONFIG_REG   0x00
+#define CSI2TX_DEVICE_CONFIG_STREAMS_MASK  GENMASK(6, 4)
+#define CSI2TX_DEVICE_CONFIG_HAS_DPHY  BIT(3)
+#define CSI2TX_DEVICE_CONFIG_LANES_MASKGENMASK(2, 0)
+
+#define CSI2TX_CONFIG_REG  0x20
+#define CSI2TX_CONFIG_CFG_REQ  BIT(2)
+#define CSI2TX_CONFIG_SRST_REQ BIT(1)
+
+#define CSI2TX_DPHY_CFG_REG0x28
+#define CSI2TX_DPHY_CFG_CLK_RESET  BIT(16)
+#define CSI2TX_DPHY_CFG_LANE_RESET(n)  BIT((n) + 12)
+#define CSI2TX_DPHY_CFG_MODE_MASK  GENMASK(9, 8)
+#define CSI2TX_DPHY_CFG_MODE_LPDT  (2 << 8)
+#define CSI2TX_DPHY_CFG_MODE_HS(1 << 8)
+#define CSI2TX_DPHY_CFG_MODE_ULPS  (0 << 8)
+#define CSI2TX_DPHY_CFG_CLK_ENABLE BIT(4)
+#define CSI2TX_DPHY_CFG_LANE_ENABLE(n) BIT(n)
+
+#define CSI2TX_DPHY_CLK_WAKEUP_REG 0x2c
+#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)  ((n) & 0x)
+
+#define CSI2TX_DT_CFG_REG(n)   (0x80 + (n) * 8)
+#define CSI2TX_DT_CFG_DT(n)(((n) & 0x3f) << 2)
+
+#define CSI2TX_DT_FORMAT_REG(n)(0x84 + (n) * 8)
+#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n) (((n) & 0x) << 16)
+#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n)   ((n) & 0x)
+
+#define CSI2TX_STREAM_IF_CFG_REG(n)(0x100 + (n) * 4)
+#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n) ((n) & 0x1f)
+
+#define CSI2TX_LANES_MAX   4
+#define CSI2TX_STREAMS_MAX 4
+
+enum csi2tx_pads {
+   CSI2TX_PAD_SOURCE,
+   CSI2TX_PAD_SINK_STREAM0,
+   CSI2TX_PAD_SINK_STREAM1,
+   CSI2TX_PAD_SINK_STREAM2,
+   CSI2TX_PAD_SINK_STREAM3,
+   CSI2TX_PAD_MAX,
+};
+
+struct csi2tx_fmt {
+   u32 mbus;
+   u32 dt;
+   u32 bpp;
+};
+
+struct csi2tx_priv {
+   struct device   *dev;
+   unsigned intcount;
+
+   /*
+* Used to prevent race conditions between multiple,
+* concurrent calls to start and stop.
+*/
+   struct mutexlock;
+
+   void __iomem*base;
+
+   struct clk  *esc_clk;
+   

[PATCH v12 0/4] media: v4l: Add support for the Cadence MIPI-CSI2 TX controller

[Maxime Ripard]

Hi,

Here is a hopefully final attempt at supporting the MIPI-CSI2 RX and
TX blocks from Cadence.

This is a merged serie of the CSI2-RX and CSI2-TX series I've been
sending for a while now and gathered a significant amount of
Reviewed-by/Acked-by. The merge has been done thanks to Sakari's
suggestion to ease the merge and the dependency between the two
drivers on the MAINTAINERS/Kconfig/Makefile sides.

The CSI2-RX has not received any comment on its previous iteration,
and CSI2-TX received some minor comments from Sakari that have been
fixed in this series. You can have a look at the Changelog below if
needed.

The TX controller is able to receive 4 video streams and stream them over a
MIPI-CSI2 link using up to 4 lanes. Those streams are basically the
interfaces to controllers generating some video signals, like a camera
or a pattern generator.

The RX controller is able to receive CSI data over up to 4 lanes, and
split it to over 4 streams. Those streams are basically the interfaces
to the video grabbers that will perform the capture.

TX is then able to map input streams to CSI2 virtual channels and
datatypes dynamically. The streaming devices choose their virtual
channels through an additional signal that is transparent to the
CSI2-TX. The datatypes however are yet another additional input
signal, and can be mapped to any CSI2 datatypes. RX can do the
opposite, being able to take virtual channel / datatypes and route
them to proper pixel interfaces on demand.

Since v4l2 doesn't really allow for that setup at the moment, this
preliminary version is a rather dumb one in order to start the
discussion on how to address this properly.

Let me know what you think!
Maxime

Changes from v11:
  - Added Makefile license
  - Added Benoit's Acked-by
  - Ignored the CSI2-RX return code on stop, and just log an error
instead

Changes from CSI2-TX v10:
  - Reword the source pad exception comment
  - Handle the V4L2_SUBDEV_FORMAT_TRY case for get_fmt / set_fmt

Maxime Ripard (4):
  dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 RX driver
  dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 TX driver

 .../devicetree/bindings/media/cdns,csi2rx.txt | 100 
 .../devicetree/bindings/media/cdns,csi2tx.txt |  98 +++
 MAINTAINERS   |   7 +
 drivers/media/platform/Kconfig|   1 +
 drivers/media/platform/Makefile   |   1 +
 drivers/media/platform/cadence/Kconfig|  34 ++
 drivers/media/platform/cadence/Makefile   |   4 +
 drivers/media/platform/cadence/cdns-csi2rx.c  | 498 
 drivers/media/platform/cadence/cdns-csi2tx.c  | 563 ++
 9 files changed, 1306 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

-- 
2.17.0

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz  escreveu:


> How's about just allowing COMPILE_TEST for FB_VIA instead of adding
> all these stubs?

Works for me.

Do you want to apply it via your tree or via the media one?

If you prefer to apply on yours:

Reviewed-by: Mauro Carvalho Chehab 

Thanks!
Mauro

> 
> 
> From: Bartlomiej Zolnierkiewicz 
> Subject: [PATCH] video: fbdev: via: allow COMPILE_TEST build
> 
> This patch allows viafb driver to be build on !X86 archs
> using COMPILE_TEST config option.
> 
> Since via-camera driver (VIDEO_VIA_CAMERA) depends on viafb
> it also needs a little fixup.
> 
> Cc: Florian Tobias Schandinat 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/media/platform/via-camera.c |5 +
>  drivers/video/fbdev/Kconfig |2 +-
>  drivers/video/fbdev/via/global.h|6 ++
>  drivers/video/fbdev/via/hw.c|1 -
>  drivers/video/fbdev/via/via-core.c  |1 -
>  drivers/video/fbdev/via/via_clock.c |2 +-
>  drivers/video/fbdev/via/viafbdev.c  |1 -
>  7 files changed, 13 insertions(+), 5 deletions(-)
> 
> Index: b/drivers/media/platform/via-camera.c
> ===
> --- a/drivers/media/platform/via-camera.c 2018-04-23 13:46:37.0 
> +0200
> +++ b/drivers/media/platform/via-camera.c 2018-04-23 14:01:07.873322815 
> +0200
> @@ -27,7 +27,12 @@
>  #include 
>  #include 
>  #include 
> +
> +#ifdef CONFIG_X86
>  #include 
> +#else
> +#define machine_is_olpc(x) 0
> +#endif
>  
>  #include "via-camera.h"
>  
> Index: b/drivers/video/fbdev/Kconfig
> ===
> --- a/drivers/video/fbdev/Kconfig 2018-04-10 12:34:26.618867549 +0200
> +++ b/drivers/video/fbdev/Kconfig 2018-04-23 13:55:41.389314593 +0200
> @@ -1437,7 +1437,7 @@ config FB_SIS_315
>  
>  config FB_VIA
> tristate "VIA UniChrome (Pro) and Chrome9 display support"
> -   depends on FB && PCI && X86 && GPIOLIB && I2C
> +   depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> Index: b/drivers/video/fbdev/via/global.h
> ===
> --- a/drivers/video/fbdev/via/global.h2017-10-18 14:35:22.079448310 
> +0200
> +++ b/drivers/video/fbdev/via/global.h2018-04-23 13:52:57.121310456 
> +0200
> @@ -33,6 +33,12 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_X86
> +#include 
> +#else
> +#define machine_is_olpc(x) 0
> +#endif
> +
>  #include "debug.h"
>  
>  #include "viafbdev.h"
> Index: b/drivers/video/fbdev/via/hw.c
> ===
> --- a/drivers/video/fbdev/via/hw.c2017-10-18 14:35:22.079448310 +0200
> +++ b/drivers/video/fbdev/via/hw.c2018-04-23 13:54:24.881312666 +0200
> @@ -20,7 +20,6 @@
>   */
>  
>  #include 
> -#include 
>  #include "global.h"
>  #include "via_clock.h"
>  
> Index: b/drivers/video/fbdev/via/via-core.c
> ===
> --- a/drivers/video/fbdev/via/via-core.c  2017-11-22 14:11:59.852728679 
> +0100
> +++ b/drivers/video/fbdev/via/via-core.c  2018-04-23 13:53:24.893311156 
> +0200
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  /*
>   * The default port config.
> Index: b/drivers/video/fbdev/via/via_clock.c
> ===
> --- a/drivers/video/fbdev/via/via_clock.c 2017-10-18 14:35:22.083448309 
> +0200
> +++ b/drivers/video/fbdev/via/via_clock.c 2018-04-23 13:53:45.389311672 
> +0200
> @@ -25,7 +25,7 @@
>  
>  #include 
>  #include 
> -#include 
> +
>  #include "via_clock.h"
>  #include "global.h"
>  #include "debug.h"
> Index: b/drivers/video/fbdev/via/viafbdev.c
> ===
> --- a/drivers/video/fbdev/via/viafbdev.c  2017-11-22 14:11:59.852728679 
> +0100
> +++ b/drivers/video/fbdev/via/viafbdev.c  2018-04-23 13:53:55.325311922 
> +0200
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #define _MASTER_FILE
>  #include "global.h"
> 
> 



Thanks,
Mauro

[PATCH] dma-fence: Polish kernel-doc for dma-fence.c

[Daniel Vetter]

- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish

v2: Add misplaced hunk of kerneldoc from a different patch.

Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 Documentation/driver-api/dma-buf.rst |   6 ++
 drivers/dma-buf/dma-fence.c  | 147 +++
 2 files changed, 109 insertions(+), 44 deletions(-)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index dc384f2f7f34..b541e97c7ab1 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -130,6 +130,12 @@ Reservation Objects
 DMA Fences
 --
 
+.. kernel-doc:: drivers/dma-buf/dma-fence.c
+   :doc: DMA fences overview
+
+DMA Fences Functions Reference
+~~
+
 .. kernel-doc:: drivers/dma-buf/dma-fence.c
:export:
 
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 7a92f85a4cec..1551ca7df394 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -38,12 +38,43 @@ EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
  */
 static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
 
+/**
+ * DOC: DMA fences overview
+ *
+ * DMA fences, represented by  dma_fence, are the kernel internal
+ * synchronization primitive for DMA operations like GPU rendering, video
+ * encoding/decoding, or displaying buffers on a screen.
+ *
+ * A fence is initialized using dma_fence_init() and completed using
+ * dma_fence_signal(). Fences are associated with a context, allocated through
+ * dma_fence_context_alloc(), and all fences on the same context are
+ * fully ordered.
+ *
+ * Since the purposes of fences is to facilitate cross-device and
+ * cross-application synchronization, there's multiple ways to use one:
+ *
+ * - Individual fences can be exposed as a _file, accessed as a file
+ *   descriptor from userspace, created by calling sync_file_create(). This is
+ *   called explicit fencing, since userspace passes around explicit
+ *   synchronization points.
+ *
+ * - Some subsystems also have their own explicit fencing primitives, like
+ *   _syncobj. Compared to _file, a _syncobj allows the underlying
+ *   fence to be updated.
+ *
+ * - Then there's also implicit fencing, where the synchronization points are
+ *   implicitly passed around as part of shared _buf instances. Such
+ *   implicit fences are stored in  reservation_object through the
+ *   _buf.resv pointer.
+ */
+
 /**
  * dma_fence_context_alloc - allocate an array of fence contexts
- * @num:   [in]amount of contexts to allocate
+ * @num: amount of contexts to allocate
  *
- * This function will return the first index of the number of fences allocated.
- * The fence context is used for setting fence->context to a unique number.
+ * This function will return the first index of the number of fence contexts
+ * allocated.  The fence context is used for setting _fence.context to a
+ * unique number by passing the context to dma_fence_init().
  */
 u64 dma_fence_context_alloc(unsigned num)
 {
@@ -59,10 +90,14 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
  * Signal completion for software callbacks on a fence, this will unblock
  * dma_fence_wait() calls and run all the callbacks added with
  * dma_fence_add_callback(). Can be called multiple times, but since a fence
- * can only go from unsignaled to signaled state, it will only be effective
- * the first time.
+ * can only go from the unsignaled to the signaled state and not back, it will
+ * only be effective the first time.
+ *
+ * Unlike dma_fence_signal(), this function must be called with _fence.lock
+ * held.
  *
- * Unlike dma_fence_signal, this function must be called with fence->lock held.
+ * Returns 0 on success and a negative error value when @fence has been
+ * signalled already.
  */
 int dma_fence_signal_locked(struct dma_fence *fence)
 {
@@ -102,8 +137,11 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
  * Signal completion for software callbacks on a fence, this will unblock
  * dma_fence_wait() calls and run all the callbacks added with
  * dma_fence_add_callback(). Can be called multiple times, but since a fence
- * can only go from unsignaled to signaled state, it will only be effective
- * the first time.
+ * can only go from the unsignaled to the signaled state and not back, it will
+ * only be effective the first time.
+ *
+ * Returns 0 on success and a negative error value when @fence has been
+ * signalled already.
  */
 int dma_fence_signal(struct dma_fence *fence)
 {
@@ -136,9 +174,9 @@ EXPORT_SYMBOL(dma_fence_signal);
 /**
  * dma_fence_wait_timeout - sleep until the fence gets signaled
  * or until timeout elapses
- * @fence: [in]the fence to wait on
- * @intr:  [in]if true, do an 

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 12:47:34 +0200
Bartlomiej Zolnierkiewicz  escreveu:

> On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:47:28 +0200
> > Bartlomiej Zolnierkiewicz  escreveu:
> >   
> > > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > > Add stubs for omapfb_dss.h, in the case it is included by
> > > > some driver when CONFIG_FB_OMAP2 is not defined, with can
> > > > happen on ARM when DRM_OMAP is not 'n'.
> > > > 
> > > > That allows building such driver(s) with COMPILE_TEST.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > 
> > > This patch should be dropped (together with patch #6/7) as it was
> > > superseded by a better solution suggested by Laurent:
> > > 
> > > https://patchwork.kernel.org/patch/10325193/
> > > 
> > > ACK-ed by Tomi:
> > > 
> > > https://www.spinics.net/lists/dri-devel/msg171918.html
> > > 
> > > and already merged by you (commit 7378f1149884 "media: omap2:
> > > omapfb: allow building it with COMPILE_TEST")..  
> > 
> > I "ressurected" this patch due to patch 6/7.
> > 
> > The problem with the solution already acked/merged is that
> > it works *only* if you don't try to build for ARM.
> > 
> > At the moment you want to build a FB_OMAP2-dependent driver
> > on ARM with allyesc onfig, DRM_OMAP will be true, and FB_OMAP2
> > will be disabled:
> > 
> > menuconfig FB_OMAP2
> > tristate "OMAP2+ frame buffer support"
> > depends on FB
> > depends on DRM_OMAP = n
> > 
> > One solution might be to change the depends on to:
> > depends on (DRM_OMAP = n || COMPILE_TEST)
> > 
> > But someone pointed me that the above check was added to avoid building
> > duplicated symbols. So, the above would cause build failures.
> > 
> > So, in order to build for ARM with DRM_OMAP selected (allyesconfig,
> > allmodconfig), we have the following alternatives:
> > 
> > 1) apply patch 5/7;
> > 2) make sure that FB_OMAP2 and DRM_OMAP won't declare the
> >same non-static symbols;
> > 3) redesign FB_OMAP2 to work with DRM_OMAP built.
> > 
> > I suspect that (1) is easier.  
> 
> I agree.
> 
> You can merge this patch through your tree with:
> 
> Acked-by: Bartlomiej Zolnierkiewicz 

Thanks, I'll merge it. It would still be really cool if Tony
or someone else could find a better way for omap3isp driver to
not depend on it.

Regards,
Maur

Thanks,
Mauro

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz  escreveu:

> Hi Mauro,
> 
> On Friday, April 20, 2018 04:03:21 PM Mauro Carvalho Chehab wrote:
> > This driver depends on FB_VIA for lots of things. Provide stubs
> > for the functions it needs, in order to allow building it with
> > COMPILE_TEST outside x86 architecture.  
> 
> Please cc: me on fbdev related patches (patch adding new FB_VIA
> ifdefs _is_ definitely fbdev related).

Ok. Btw, get maintainer script only gets the fbdev ML:

$ ./scripts/get_maintainer.pl -f include/linux/via-core.h
Florian Tobias Schandinat  (maintainer:VIA 
UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER)
linux-fb...@vger.kernel.org (open list:VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER 
DRIVER)
linux-ker...@vger.kernel.org (open list)

It probably makes sense to add a:

R: Bartlomiej Zolnierkiewicz 

At the MAINTAINERS' entry for VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER.


> 
> > Signed-off-by: Mauro Carvalho Chehab 
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index e3229f7baed1..abaaed98a044 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -15,7 +15,7 @@ source "drivers/media/platform/marvell-ccic/Kconfig"
> >  
> >  config VIDEO_VIA_CAMERA
> > tristate "VIAFB camera controller support"
> > -   depends on FB_VIA
> > +   depends on FB_VIA || COMPILE_TEST  
> 
> This is incorrect (too simple), please take a look at FB_VIA entry:
> 
> config FB_VIA
>tristate "VIA UniChrome (Pro) and Chrome9 display support"
>depends on FB && PCI && X86 && GPIOLIB && I2C
>select FB_CFB_FILLRECT
>select FB_CFB_COPYAREA
>select FB_CFB_IMAGEBLIT
>select I2C_ALGOBIT
>help
> 
> Therefore you also need to check PCI, GPIOLIB && I2C dependencies.

OK. I'll add id, addressing the other issues you pointed and send
a version 2 of the patches on this series that weren't merged.

> 
> * For PCI=n:
> 
> drivers/media/platform/via-camera.c: In function ‘viacam_serial_is_enabled’:
> drivers/media/platform/via-camera.c:1286:9: error: implicit declaration of 
> function ‘pci_find_bus’ [-Werror=implicit-function-declaration]
> drivers/media/platform/via-camera.c:1286:25: warning: initialization makes 
> pointer from integer without a cast [enabled by default]
> drivers/media/platform/via-camera.c:1296:2: error: implicit declaration of 
> function ‘pci_bus_read_config_byte’ [-Werror=implicit-function-declaration]
> drivers/media/platform/via-camera.c:1308:2: error: implicit declaration of 
> function ‘pci_bus_write_config_byte’ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[3]: *** [drivers/media/platform/via-camera.o] Error 1
> 
> * For I2C=n:
> 
> WARNING: unmet direct dependencies detected for VIDEO_OV7670
>   Depends on [n]: MEDIA_SUPPORT [=y] && I2C [=n] && VIDEO_V4L2 [=y] && 
> MEDIA_CAMERA_SUPPORT [=y]
>   Selected by [y]:
>   - VIDEO_VIA_CAMERA [=y] && MEDIA_SUPPORT [=y] && V4L_PLATFORM_DRIVERS [=y] 
> && (FB_VIA [=n] || COMPILE_TEST [=y])
> 
> drivers/media/i2c/ov7670.c: In function ‘ov7670_read_smbus’:
> drivers/media/i2c/ov7670.c:483:2: error: implicit declaration of function 
> ‘i2c_smbus_read_byte_data’ [-Werror=implicit-function-declaration]
>   ret = i2c_smbus_read_byte_data(client, reg);
>   ^
> drivers/media/i2c/ov7670.c: In function ‘ov7670_write_smbus’:
> drivers/media/i2c/ov7670.c:496:2: error: implicit declaration of function 
> ‘i2c_smbus_write_byte_data’ [-Werror=implicit-function-declaration]
>   int ret = i2c_smbus_write_byte_data(client, reg, value);
>   ^
> drivers/media/i2c/ov7670.c: In function ‘ov7670_read_i2c’:
> drivers/media/i2c/ov7670.c:521:2: error: implicit declaration of function 
> ‘i2c_transfer’ [-Werror=implicit-function-declaration]
>   ret = i2c_transfer(client->adapter, , 1);
>   ^
> drivers/media/i2c/ov7670.c: In function ‘ov7670_probe’:
> drivers/media/i2c/ov7670.c:1835:3: error: implicit declaration of function 
> ‘i2c_adapter_id’ [-Werror=implicit-function-declaration]
>v4l_dbg(1, debug, client,
>^
> drivers/media/i2c/ov7670.c: At top level:
> drivers/media/i2c/ov7670.c:1962:1: warning: data definition has no type or 
> storage class [enabled by default]
>  module_i2c_driver(ov7670_driver);
>  ^
> drivers/media/i2c/ov7670.c:1962:1: error: type defaults to ‘int’ in 
> declaration of ‘module_i2c_driver’ [-Werror=implicit-int]
> drivers/media/i2c/ov7670.c:1962:1: warning: parameter names (without types) 
> in function declaration [enabled by default]
> drivers/media/i2c/ov7670.c:1952:26: warning: ‘ov7670_driver’ defined but not 
> used [-Wunused-variable]
>  static struct i2c_driver ov7670_driver = {
>   ^
> cc1: some warnings being treated as errors
> make[3]: *** [drivers/media/i2c/ov7670.o] Error 1
> 
> * For GPIOLIB=n it builds fine.

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Paul Kocialkowski]

On Fri, 2018-05-04 at 15:40 +0200, Maxime Ripard wrote:
> On Fri, May 04, 2018 at 02:04:38PM +0200, Paul Kocialkowski wrote:
> > On Fri, 2018-05-04 at 11:15 +0200, Maxime Ripard wrote:
> > > On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote:
> > > > > > > > +   reg = <0x01c0e000 0x1000>;
> > > > > > > > +   memory-region = <_memory>;
> > > > > > > 
> > > > > > > Since you made the CMA region the default one, you don't
> > > > > > > need
> > > > > > > to
> > > > > > > tie
> > > > > > > it to that device in particular (and you can drop it being
> > > > > > > mandatory
> > > > > > > from your binding as well).
> > > > > > 
> > > > > > What if another driver (or the system) claims memory from
> > > > > > that
> > > > > > zone
> > > > > > and
> > > > > > that the reserved memory ends up not being available for the
> > > > > > VPU
> > > > > > anymore?
> > > > > > 
> > > > > > Acccording to the reserved-memory documentation, the
> > > > > > reusable
> > > > > > property
> > > > > > (that we need for dmabuf) puts a limitation that the device
> > > > > > driver
> > > > > > owning the region must be able to reclaim it back.
> > > > > > 
> > > > > > How does that work out if the CMA region is not tied to a
> > > > > > driver
> > > > > > in
> > > > > > particular?
> > > > > 
> > > > > I'm not sure to get what you're saying. You have the property
> > > > > linux,cma-default in your reserved region, so the behaviour
> > > > > you
> > > > > described is what you explicitly asked for.
> > > > 
> > > > My point is that I don't see how the driver can claim back (part
> > > > of)
> > > > the
> > > > reserved area if the area is not explicitly attached to it.
> > > > 
> > > > Or is that mechanism made in a way that all drivers wishing to
> > > > use
> > > > the
> > > > reserved memory area can claim it back from the system, but
> > > > there is
> > > > no
> > > > priority (other than first-come first-served) for which drivers
> > > > claims
> > > > it back in case two want to use the same reserved region (in a
> > > > scenario
> > > > where there isn't enough memory to allow both drivers)?
> > > 
> > > This is indeed what happens. Reusable is to let the system use the
> > > reserved memory for things like caches that can easily be dropped
> > > when
> > > a driver wants to use the memory in that reserved area. Once that
> > > memory has been allocated, there's no claiming back, unless that
> > > memory segment was freed of course.
> > 
> > Thanks for the clarification. So in our case, perhaps the best fit
> > would
> > be to make that area the default CMA pool so that we can be ensured
> > that
> > the whole 96 MiB is available for the VPU and that no other consumer
> > of
> > CMA will use it?
> 
> The best fit for what use case ? We already discussed this, and I
> don't see any point in having two separate CMA regions. If you have a
> reasonably sized region that will accomodate for both the VPU and
> display engine, why would we want to split them?

The use case I have in mind is boilerplate use of the VPU with the
display engine, say with DMAbuf.

It wasn't exactly clear in my memory whether we had decided that the CMA
pool we use for the VPU should also be used for other CMA consumers (I
realize that this is what we've been doing all along by having
linux,cma-default; though).

The fact that the memory region will accomodate for both the display
engine and the VPU is not straightforward IMO and I think this has to be
an explicit choice that we take. I was under the impression that we
chose the 96 MiB because that's what the Allwinner reference code does.
Does the reference code also use this pool for display?

I liked the idea of having 96 MiB fully reserved to the VPU because it
allows us to provide a limit on the use case, such as "this guarantees N
buffers for resolution foo in format bar". If the display engine also
uses it, then the limit also depends on how many GEM buffers are
allocated (unless I'm missing something).

> Or did you have any experience of running out of buffers?

Not yet, I haven't. I have no objection with making the reserved region
the default CMA pool and have other consumers use it too.

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] media: staging: atomisp: fix a potential missing-check bug

[Andy Shevchenko]

On Fri, 2018-05-04 at 02:29 -0500, Wenwen Wang wrote:
> At the end of atomisp_subdev_set_selection(), the function
> atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect.
> Since
> this function may return a NULL pointer, it is firstly invoked to
> check
> the returned pointer. If the returned pointer is not NULL, then the
> function is invoked again to obtain the pointer and the memory content
> at the location of the returned pointer is copied to the memory
> location of
> r. In most cases, the pointers returned by the two invocations are
> same.
> However, given that the pointer returned by the function
> atomisp_subdev_get_rect() is not a constant, it is possible that the
> two
> invocations return two different pointers. For example, another thread
> may
> race to modify the related pointers during the two invocations. In
> that
> case, even if the first returned pointer is not null, the second
> returned
> pointer might be null, which will cause issues such as null pointer
> dereference.
> 
> This patch saves the pointer returned by the first invocation and
> removes
> the second invocation. If the returned pointer is not NULL, the memory
> content is copied according to the original code.
> 

The driver will be gone soon, don't bother with it anymore.
Thanks!

> Signed-off-by: Wenwen Wang 
> ---
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 6 -
> -
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git
> a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> index 49a9973..d5fa513 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> @@ -366,6 +366,7 @@ int atomisp_subdev_set_selection(struct
> v4l2_subdev *sd,
>   unsigned int i;
>   unsigned int padding_w = pad_w;
>   unsigned int padding_h = pad_h;
> + struct v4l2_rect *p;
>  
>   stream_id = atomisp_source_pad_to_stream_id(isp_sd,
> vdev_pad);
>  
> @@ -536,9 +537,10 @@ int atomisp_subdev_set_selection(struct
> v4l2_subdev *sd,
>   ffmt[pad]->height = comp[pad]->height;
>   }
>  
> - if (!atomisp_subdev_get_rect(sd, cfg, which, pad, target))
> + p = atomisp_subdev_get_rect(sd, cfg, which, pad, target);
> + if (!p)
>   return -EINVAL;
> - *r = *atomisp_subdev_get_rect(sd, cfg, which, pad, target);
> + *r = *p;
>  
>   dev_dbg(isp->dev, "sel actual: l %d t %d w %d h %d\n",
>   r->left, r->top, r->width, r->height);

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

[Daniel Vetter]

On Fri, May 04, 2018 at 03:17:08PM +0200, Christian König wrote:
> Am 04.05.2018 um 11:25 schrieb Daniel Vetter:
> > On Fri, May 4, 2018 at 11:16 AM, Chris Wilson  
> > wrote:
> > > Quoting Daniel Vetter (2018-05-04 09:57:59)
> > > > On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote:
> > > > > Quoting Daniel Vetter (2018-05-04 09:23:01)
> > > > > > On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote:
> > > > > > > On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote:
> > > > > > > > Quoting Daniel Vetter (2018-05-03 15:25:52)
> > > > > > > > > Almost everyone uses dma_fence_default_wait.
> > > > > > > > > 
> > > > > > > > > v2: Also remove the BUG_ON(!ops->wait) (Chris).
> > > > > > > > I just don't get the rationale for implicit over explicit.
> > > > > > > Closer approximation of dwim semantics. There's been tons of 
> > > > > > > patch series
> > > > > > > all over drm and related places to get there, once we have a big 
> > > > > > > pile of
> > > > > > > implementations and know what the dwim semantics should be. 
> > > > > > > Individually
> > > > > > > they're all not much, in aggregate they substantially simplify 
> > > > > > > simple
> > > > > > > drivers.
> > > > > > I also think clearer separation between optional optimization hooks 
> > > > > > and
> > > > > > mandatory core parts is useful in itself.
> > > > > A new spelling of midlayer ;) I don't see the contradiction with a
> > > > > driver saying use the default and simplicity. (I know which one the
> > > > > compiler thinks is simpler ;)
> > > > If the compiler overhead is real then I guess it would makes to be
> > > > explicit. I don't expect that to be a problem though for a blocking
> > > > function.
> > > > 
> > > > I disagree on this being a midlayer - you can still overwrite everything
> > > > you please to. What it does help is people doing less copypasting (and
> > > > assorted bugs), at least in the grand scheme of things. And we do have a
> > > > _lot_ more random small drivers than just a few years ago. Reducing the
> > > > amount of explicit typing just to get default bahaviour has been an
> > > > ongoing theme for a few years now, and your objection here is about the
> > > > first that this is not a good idea. So I'm somewhat confused.
> > > I'm just saying I don't see any rationale for this patch.
> > > 
> > >  "Almost everyone uses dma_fence_default_wait."
> > > 
> > > Why change?
> > > 
> > > Making it look simpler on the surface, so that you don't have to think
> > > about things straight away? I understand the appeal, but I do worry
> > > about it just being an illusion. (Cutting and pasting a line saying
> > > .wait = default_wait, doesn't feel that onerous, as you likely cut and
> > > paste the ops anyway, and at the very least you are reminded about some
> > > of the interactions. You could even have default initializers and/or
> > > magic macros to hide the cut and paste; maybe a simple_dma_fence [now
> > > that's a midlayer!] but I haven't looked.)
> > In really monolithic vtables like drm_driver we do use default
> > function macros, so you type 1 line, get them all. But dma_fence_ops
> > is pretty small, and most drivers only implement a few callbacks. Also
> > note that e.g. the ->release callback already works like that, so this
> > pattern is there already. I simply extended it to ->wait and
> > ->enable_signaling. Also note that I leave the EXPORT_SYMBOL in place,
> > you can still wrap dma_fence_default_wait if you wish to do so.
> > 
> > But I just realized that I didn't clean out the optional release
> > hooks, I guess I should do that too (for the few cases it's not yet
> > done) and respin.
> 
> I kind of agree with Chris here, but also see the practical problem to copy
> the default function in all the implementations.
> 
> We had the same problem in TTM and I also don't really like the result to
> always have that "if (some_callback) default(); else some_callback();".
> 
> Might be that the run time overhead is negligible, but it doesn't feels
> right from the coding style perspective.

Hm, maybe I've seen too much bad code, but modeset helpers is choke full
of exactly that pattern. It's imo also a trade-off. If you have a fairly
specialized library like ttm that's used by relatively few things, doing
everything explicitly is probably better. It's also where kms started out
from.

But if you have a huge pile of fairly simple drivers, imo the balance
starts to tip the other way, and a bit of additional logic in the shared
code to make all the implementations a notch simpler is good. If we
wouldn't have acquired quite a pile of dma_fence implementations I
wouldn't have bothered with all this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Maxime Ripard]

On Fri, May 04, 2018 at 02:04:38PM +0200, Paul Kocialkowski wrote:
> On Fri, 2018-05-04 at 11:15 +0200, Maxime Ripard wrote:
> > On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote:
> > > > > > > + reg = <0x01c0e000 0x1000>;
> > > > > > > + memory-region = <_memory>;
> > > > > > 
> > > > > > Since you made the CMA region the default one, you don't need
> > > > > > to
> > > > > > tie
> > > > > > it to that device in particular (and you can drop it being
> > > > > > mandatory
> > > > > > from your binding as well).
> > > > > 
> > > > > What if another driver (or the system) claims memory from that
> > > > > zone
> > > > > and
> > > > > that the reserved memory ends up not being available for the VPU
> > > > > anymore?
> > > > > 
> > > > > Acccording to the reserved-memory documentation, the reusable
> > > > > property
> > > > > (that we need for dmabuf) puts a limitation that the device
> > > > > driver
> > > > > owning the region must be able to reclaim it back.
> > > > > 
> > > > > How does that work out if the CMA region is not tied to a driver
> > > > > in
> > > > > particular?
> > > > 
> > > > I'm not sure to get what you're saying. You have the property
> > > > linux,cma-default in your reserved region, so the behaviour you
> > > > described is what you explicitly asked for.
> > > 
> > > My point is that I don't see how the driver can claim back (part of)
> > > the
> > > reserved area if the area is not explicitly attached to it.
> > > 
> > > Or is that mechanism made in a way that all drivers wishing to use
> > > the
> > > reserved memory area can claim it back from the system, but there is
> > > no
> > > priority (other than first-come first-served) for which drivers
> > > claims
> > > it back in case two want to use the same reserved region (in a
> > > scenario
> > > where there isn't enough memory to allow both drivers)?
> > 
> > This is indeed what happens. Reusable is to let the system use the
> > reserved memory for things like caches that can easily be dropped when
> > a driver wants to use the memory in that reserved area. Once that
> > memory has been allocated, there's no claiming back, unless that
> > memory segment was freed of course.
> 
> Thanks for the clarification. So in our case, perhaps the best fit would
> be to make that area the default CMA pool so that we can be ensured that
> the whole 96 MiB is available for the VPU and that no other consumer of
> CMA will use it?

The best fit for what use case ? We already discussed this, and I
don't see any point in having two separate CMA regions. If you have a
reasonably sized region that will accomodate for both the VPU and
display engine, why would we want to split them?

Or did you have any experience of running out of buffers?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 0/9] cx231xx: House cleaning

[Brad Love]

Hi Hans,


On 2018-05-04 01:27, Hans Verkuil wrote:
> Hi Brad,
>
> On 03/05/18 23:20, Brad Love wrote:
>> Included in this patch set is:
>> - Bugfix for a device not working
>> - Some clean up and value corrections
>> - Conversion to new dvb i2c helpers
>> - Update of device from old dvb attach to i2c device
>> - Dependency fixes
>> - Style fixes
>>
>> Changes since v1:
>> - Style fixes in i2c helper patch
>> - Some comment cleanup
>> - Hardware validation of analog tuning
>>
>> Brad Love (9):
>>   cx231xx: Fix several incorrect demod addresses
>>   cx231xx: Use board profile values for addresses
>>   cx231xx: Style fix for struct zero init
>>   cx231xx: [bug] Ignore an i2c mux adapter
>>   cx231xx: Switch to using new dvb i2c helpers
>>   cx231xx: Update 955Q from dvb attach to i2c device
>>   cx231xx: Remove unnecessary parameter clear
>>   cx231xx: Remove RC_CORE dependency
>>   cx231xx: Add I2C_MUX dependency
>>
>>  drivers/media/usb/cx231xx/Kconfig |   1 -
>>  drivers/media/usb/cx231xx/cx231xx-cards.c |   6 +-
>>  drivers/media/usb/cx231xx/cx231xx-dvb.c   | 365 
>> --
>>  3 files changed, 94 insertions(+), 278 deletions(-)
>>
> In case you are ever interested in converting this driver to vb2,
> I made an attempt back in 2015:
>
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=cx231xx
>
> I never got it to work (I think it was mainly the DVB part that
> didn't work, but I'm not certain anymore as it is such a long time
> ago). I ran out of time and haven't continued with it, but it would
> be really nice if someone could finish this vb2 conversion.
>
> Regards,
>
>   Hans

I'll check this out and add it to my queue.

Cheers,

Brad

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

[Christian König]

Am 04.05.2018 um 11:25 schrieb Daniel Vetter:

On Fri, May 4, 2018 at 11:16 AM, Chris Wilson  wrote:

Quoting Daniel Vetter (2018-05-04 09:57:59)

On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote:

Quoting Daniel Vetter (2018-05-04 09:23:01)

On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote:

On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote:

Quoting Daniel Vetter (2018-05-03 15:25:52)

Almost everyone uses dma_fence_default_wait.

v2: Also remove the BUG_ON(!ops->wait) (Chris).

I just don't get the rationale for implicit over explicit.

Closer approximation of dwim semantics. There's been tons of patch series
all over drm and related places to get there, once we have a big pile of
implementations and know what the dwim semantics should be. Individually
they're all not much, in aggregate they substantially simplify simple
drivers.

I also think clearer separation between optional optimization hooks and
mandatory core parts is useful in itself.

A new spelling of midlayer ;) I don't see the contradiction with a
driver saying use the default and simplicity. (I know which one the
compiler thinks is simpler ;)

If the compiler overhead is real then I guess it would makes to be
explicit. I don't expect that to be a problem though for a blocking
function.

I disagree on this being a midlayer - you can still overwrite everything
you please to. What it does help is people doing less copypasting (and
assorted bugs), at least in the grand scheme of things. And we do have a
_lot_ more random small drivers than just a few years ago. Reducing the
amount of explicit typing just to get default bahaviour has been an
ongoing theme for a few years now, and your objection here is about the
first that this is not a good idea. So I'm somewhat confused.

I'm just saying I don't see any rationale for this patch.

 "Almost everyone uses dma_fence_default_wait."

Why change?

Making it look simpler on the surface, so that you don't have to think
about things straight away? I understand the appeal, but I do worry
about it just being an illusion. (Cutting and pasting a line saying
.wait = default_wait, doesn't feel that onerous, as you likely cut and
paste the ops anyway, and at the very least you are reminded about some
of the interactions. You could even have default initializers and/or
magic macros to hide the cut and paste; maybe a simple_dma_fence [now
that's a midlayer!] but I haven't looked.)

In really monolithic vtables like drm_driver we do use default
function macros, so you type 1 line, get them all. But dma_fence_ops
is pretty small, and most drivers only implement a few callbacks. Also
note that e.g. the ->release callback already works like that, so this
pattern is there already. I simply extended it to ->wait and
->enable_signaling. Also note that I leave the EXPORT_SYMBOL in place,
you can still wrap dma_fence_default_wait if you wish to do so.

But I just realized that I didn't clean out the optional release
hooks, I guess I should do that too (for the few cases it's not yet
done) and respin.


I kind of agree with Chris here, but also see the practical problem to 
copy the default function in all the implementations.


We had the same problem in TTM and I also don't really like the result 
to always have that "if (some_callback) default(); else some_callback();".


Might be that the run time overhead is negligible, but it doesn't feels 
right from the coding style perspective.


Christian.


-Daniel

[PATCH 0/2] add support for TI SCAN921226H video deserializer

[Jan Luebbe]

This series adds a binding and the corresponding V4L subdev driver for
the TI SCAN921226H video deserializer. Although the device doesn't need
to be configured, it can be controlled via GPIOs to allow multiple
sensors on the same parallel video bus.

Jan Luebbe (2):
  media: dt-bindings: add binding for TI SCAN921226H video deserializer
  media: platform: add driver for TI SCAN921226H video deserializer

 .../bindings/media/ti,scan921226h.txt |  59 +++
 drivers/media/platform/Kconfig|   7 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/scan921226h.c  | 353 ++
 4 files changed, 421 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti,scan921226h.txt
 create mode 100644 drivers/media/platform/scan921226h.c

-- 
2.17.0

[PATCH 2/2] media: platform: add driver for TI SCAN921226H video deserializer

[Jan Luebbe]

Although one could have a working setup with a sensor such as the
MT9V024 connected via LVDS to the deserializer and then via parallel to
the SoC's camera interface even without having a driver for the
deserializer, controlling the deserializer's state is needed when
multiple cameras share the parallel bus. By enabling only one at a time,
a camera can be selected at runtime using mediactl.

This driver will en-/disable the deserializer via GPIOs as needed
depending on the media entity link state.

The current v4l2-compliance doesn't report any warnings or errors.

Signed-off-by: Jan Luebbe 
---
 drivers/media/platform/Kconfig   |   7 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/scan921226h.c | 353 +++
 3 files changed, 362 insertions(+)
 create mode 100644 drivers/media/platform/scan921226h.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8a1b01..f321f895d173 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -384,6 +384,13 @@ config VIDEO_STI_DELTA_DRIVER
 
 endif # VIDEO_STI_DELTA
 
+config VIDEO_SCAN921226H
+   tristate "TI SCAN921226H LVDS deserializer driver"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   help
+ Enables support for the SCAN921226H LVDS deserializer, which is
+ controlled via two GPIOs (output enable and power down).
+
 config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515df4477..45f90189a193 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -53,6 +53,8 @@ obj-y += stm32/
 
 obj-y  += davinci/
 
+obj-$(CONFIG_VIDEO_SCAN921226H)+= scan921226h.o
+
 obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o
 
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
diff --git a/drivers/media/platform/scan921226h.c 
b/drivers/media/platform/scan921226h.c
new file mode 100644
index ..59fcd55ceaa2
--- /dev/null
+++ b/drivers/media/platform/scan921226h.c
@@ -0,0 +1,353 @@
+/*
+ * TI SCAN921226H deserializer driver
+ *
+ * Copyright (C) 2018 Pengutronix, Jan Luebbe 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct video_des {
+   struct v4l2_subdev subdev;
+   struct media_pad pads[2];
+   struct v4l2_mbus_framefmt format_mbus;
+   struct gpio_desc *npwrdn_gpio;
+   struct gpio_desc *enable_gpio;
+   struct mutex lock;
+   int active;
+};
+
+static inline struct video_des *v4l2_subdev_to_video_des(struct v4l2_subdev 
*sd)
+{
+   return container_of(sd, struct video_des, subdev);
+}
+
+static int video_des_link_setup(struct media_entity *entity,
+   const struct media_pad *local,
+   const struct media_pad *remote, u32 flags)
+{
+   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+   struct video_des *vdes = v4l2_subdev_to_video_des(sd);
+
+   /*
+* The deserializer state is determined by the enabled source pad link.
+* Enabling or disabling the sink pad link has no effect.
+*/
+   if (local->flags & MEDIA_PAD_FL_SINK)
+   return 0;
+
+   dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
+   remote->entity->name, remote->index, local->entity->name,
+   local->index, flags & MEDIA_LNK_FL_ENABLED);
+
+   mutex_lock(>lock);
+
+   if (flags & MEDIA_LNK_FL_ENABLED) {
+   dev_dbg(sd->dev, "going active\n");
+   gpiod_set_value_cansleep(vdes->npwrdn_gpio, 1);
+   udelay(10); /* wait for the PLL to lock */
+   gpiod_set_value_cansleep(vdes->enable_gpio, 1);
+   } else {
+   dev_dbg(sd->dev, "going inactive\n");
+   gpiod_set_value_cansleep(vdes->enable_gpio, 0);
+   gpiod_set_value_cansleep(vdes->npwrdn_gpio, 0);
+   }
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static const struct media_entity_operations video_des_ops = {
+   .link_setup = video_des_link_setup,
+   .link_validate = v4l2_subdev_link_validate,
+};
+
+static 

[PATCH 1/2] media: dt-bindings: add binding for TI SCAN921226H video deserializer

[Jan Luebbe]

This deserializer can be used with sensors that directly produce a
10-bit LVDS stream and converts it to a parallel bus.

Controlling it via the optional GPIOs is mainly useful for avoiding
conflicts when another parallel sensor is connected to the same data bus
as the deserializer.

Signed-off-by: Jan Luebbe 
---
 .../bindings/media/ti,scan921226h.txt | 59 +++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti,scan921226h.txt

diff --git a/Documentation/devicetree/bindings/media/ti,scan921226h.txt 
b/Documentation/devicetree/bindings/media/ti,scan921226h.txt
new file mode 100644
index ..4e475672d7bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,scan921226h.txt
@@ -0,0 +1,59 @@
+TI SCAN921226H Video Deserializer
+-
+
+The SCAN921226H receives a LVDS serial data stream with embedded clock and
+converts it to a 10-bit wide parallel data bus and recovers parallel clock.
+Some CMOS sensors such as the ON Semiconductor MT9V024 produce a LVDS signal
+compatible with this deserializer.
+
+Required properties:
+- compatible : should be "ti,scan921226h"
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+- port@0: serial (LVDS) input
+- port@1: parallel output
+
+The device node should contain two 'port' child nodes (one each for input and
+output), in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Properties:
+- enable-gpios: reference to the GPIO connected to the REN (output enable) pin,
+  if any.
+- npwrdn-gpios: reference to the GPIO connected to the nPWRDN pin, if any.
+
+Optionally, #address-cells, #size-cells, and port nodes can be grouped under a
+ports node as described in Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+  csi0_deserializer: csi0_deserializer {
+  compatible = "ti,scan921226h";
+
+  enable-gpios = < 20 GPIO_ACTIVE_HIGH>;
+  npwrdn-gpios = < 24 GPIO_ACTIVE_HIGH>;
+
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  /* serial sink interface */
+  port@0 {
+  reg = <0>;
+
+  des0_in: endpoint {
+  remote-endpoint = <_0_out>;
+  };
+  };
+
+  /* parallel source interface */
+  port@1 {
+  reg = <1>;
+
+  des0_out: endpoint {
+  remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+  bus-width = <8>;
+  hsync-active = <1>;
+  vsync-active = <1>;
+  };
+  };
+  };
-- 
2.17.0

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Lucas Stach]

Am Mittwoch, den 25.04.2018, 13:44 -0400 schrieb Alex Deucher:
> On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig  > wrote:
> > On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote:
> > > > It has a non-coherent transaction mode (which the chipset can opt to
> > > > not implement and still flush), to make sure the AGP horror show
> > > > doesn't happen again and GPU folks are happy with PCIe. That's at
> > > > least my understanding from digging around in amd the last time we had
> > > > coherency issues between intel and amd gpus. GPUs have some bits
> > > > somewhere (in the pagetables, or in the buffer object description
> > > > table created by userspace) to control that stuff.
> > > 
> > > Right.  We have a bit in the GPU page table entries that determines
> > > whether we snoop the CPU's cache or not.
> > 
> > I can see how that works with the GPU on the same SOC or SOC set as the
> > CPU.  But how is that going to work for a GPU that is a plain old PCIe
> > card?  The cache snooping in that case is happening in the PCIe root
> > complex.
> 
> I'm not a pci expert, but as far as I know, the device sends either a
> snooped or non-snooped transaction on the bus.  I think the
> transaction descriptor supports a no snoop attribute.  Our GPUs have
> supported this feature for probably 20 years if not more, going back
> to PCI.  Using non-snooped transactions have lower latency and faster
> throughput compared to snooped transactions.

PCI-X (as in the thing which as all the rage before PCIe) added a
attribute phase to each transaction where the requestor can enable
relaxed ordering and/or no-snoop on a transaction basis. As those are
strictly performance optimizations the root-complex isn't required to
honor those attributes, but implementations that care about performance
 usually will.

Regards,
Lucas

Re: [PATCHv13 05/28] media-request: add media_request_object_find

[Sakari Ailus]

On Thu, May 03, 2018 at 04:52:55PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add media_request_object_find to find a request object inside a
> request based on ops and/or priv values.
> 
> Objects of the same type (vb2 buffer, control handler) will have
> the same ops value. And objects that refer to the same 'parent'
> object (e.g. the v4l2_ctrl_handler that has the current driver
> state) will have the same priv value.
> 
> The caller has to call media_request_object_put() for the returned
> object since this function increments the refcount.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/media-request.c | 25 +
>  include/media/media-request.h | 24 
>  2 files changed, 49 insertions(+)
> 
> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index edc1c3af1959..c7e11e816e27 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -322,6 +322,31 @@ static void media_request_object_release(struct kref 
> *kref)
>   obj->ops->release(obj);
>  }
>  
> +struct media_request_object *
> +media_request_object_find(struct media_request *req,
> +   const struct media_request_object_ops *ops,
> +   void *priv)
> +{
> + struct media_request_object *obj;
> + struct media_request_object *found = NULL;
> + unsigned long flags;
> +
> + if (WARN_ON(!ops || !priv))
> + return NULL;
> +
> + spin_lock_irqsave(>lock, flags);
> + list_for_each_entry(obj, >objects, list) {
> + if (obj->ops == ops && obj->priv == priv) {
> + media_request_object_get(obj);
> + found = obj;
> + break;
> + }
> + }
> + spin_unlock_irqrestore(>lock, flags);
> + return found;
> +}
> +EXPORT_SYMBOL_GPL(media_request_object_find);
> +
>  void media_request_object_put(struct media_request_object *obj)
>  {
>   kref_put(>kref, media_request_object_release);
> diff --git a/include/media/media-request.h b/include/media/media-request.h
> index 997e096d7128..5367b4a2f91c 100644
> --- a/include/media/media-request.h
> +++ b/include/media/media-request.h
> @@ -196,6 +196,22 @@ static inline void media_request_object_get(struct 
> media_request_object *obj)
>   */
>  void media_request_object_put(struct media_request_object *obj);
>  
> +/**
> + * media_request_object_find - Find an object in a request
> + *
> + * @ops: Find an object with this ops value
> + * @priv: Find an object with this priv value
> + *
> + * Both @ops and @priv must be non-NULL.
> + *
> + * Returns NULL if not found or the object pointer. The caller must

I'd describe the successful case first. I.e. "Returns the object pointer or
NULL it not found".

Acked-by: Sakari Ailus 

> + * call media_request_object_put() once it finished using the object.
> + */
> +struct media_request_object *
> +media_request_object_find(struct media_request *req,
> +   const struct media_request_object_ops *ops,
> +   void *priv);
> +
>  /**
>   * media_request_object_init - Initialise a media request object
>   *
> @@ -241,6 +257,14 @@ static inline void media_request_object_put(struct 
> media_request_object *obj)
>  {
>  }
>  
> +static inline struct media_request_object *
> +media_request_object_find(struct media_request *req,
> +   const struct media_request_object_ops *ops,
> +   void *priv)
> +{
> + return NULL;
> +}
> +
>  static inline void media_request_object_init(struct media_request_object 
> *obj)
>  {
>   obj->ops = NULL;

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

Re: [PATCHv13 03/28] media-request: implement media requests

[Sakari Ailus]

Hi Hans,

I've read this patch a large number of times and I think also the details
begin to seem sound. A few comments below.

On Thu, May 03, 2018 at 04:52:53PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add initial media request support:
> 
> 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c
> 2) Add struct media_request to store request objects.
> 3) Add struct media_request_object to represent a request object.
> 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support.
> 
> Basic lifecycle: the application allocates a request, adds
> objects to it, queues the request, polls until it is completed
> and can then read the final values of the objects at the time
> of completion. When it closes the file descriptor the request
> memory will be freed (actually, when the last user of that request
> releases the request).
> 
> Drivers will bind an object to a request (the 'adds objects to it'
> phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is
> validated (req_validate op), then queued (the req_queue op).
> 
> When done with an object it can either be unbound from the request
> (e.g. when the driver has finished with a vb2 buffer) or marked as
> completed (e.g. for controls associated with a buffer). When all
> objects in the request are completed (or unbound), then the request
> fd will signal an exception (poll).
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/Makefile|   3 +-
>  drivers/media/media-device.c  |  14 ++
>  drivers/media/media-request.c | 407 ++
>  include/media/media-device.h  |  16 ++
>  include/media/media-request.h | 244 
>  5 files changed, 683 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/media-request.c
>  create mode 100644 include/media/media-request.h
> 
> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> index 594b462ddf0e..985d35ec6b29 100644
> --- a/drivers/media/Makefile
> +++ b/drivers/media/Makefile
> @@ -3,7 +3,8 @@
>  # Makefile for the kernel multimedia device drivers.
>  #
>  
> -media-objs   := media-device.o media-devnode.o media-entity.o
> +media-objs   := media-device.o media-devnode.o media-entity.o \
> +media-request.o
>  
>  #
>  # I2C drivers should come before other drivers, otherwise they'll fail
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 35e81f7c0d2f..bb6a64acd3f0 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_MEDIA_CONTROLLER
>  
> @@ -366,6 +367,15 @@ static long media_device_get_topology(struct 
> media_device *mdev,
>   return ret;
>  }
>  
> +static long media_device_request_alloc(struct media_device *mdev,
> +struct media_request_alloc *alloc)
> +{
> + if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> + return -ENOTTY;
> +
> + return media_request_alloc(mdev, alloc);
> +}
> +
>  static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int 
> cmd)
>  {
>   /* All media IOCTLs are _IOWR() */
> @@ -414,6 +424,7 @@ static const struct media_ioctl_info ioctl_info[] = {
>   MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(REQUEST_ALLOC, media_device_request_alloc, 0),
>  };
>  
>  static long media_device_ioctl(struct file *filp, unsigned int cmd,
> @@ -686,6 +697,8 @@ void media_device_init(struct media_device *mdev)
>   INIT_LIST_HEAD(>pads);
>   INIT_LIST_HEAD(>links);
>   INIT_LIST_HEAD(>entity_notify);
> +
> + mutex_init(>req_queue_mutex);
>   mutex_init(>graph_mutex);
>   ida_init(>entity_internal_idx);
>  
> @@ -699,6 +712,7 @@ void media_device_cleanup(struct media_device *mdev)
>   mdev->entity_internal_idx_max = 0;
>   media_graph_walk_cleanup(>pm_count_walk);
>   mutex_destroy(>graph_mutex);
> + mutex_destroy(>req_queue_mutex);
>  }
>  EXPORT_SYMBOL_GPL(media_device_cleanup);
>  
> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> new file mode 100644
> index ..c216c4ab628b
> --- /dev/null
> +++ b/drivers/media/media-request.c
> @@ -0,0 +1,407 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Media device request objects
> + *
> + * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
> + * Copyright (C) 2018 Intel Corporation
> + * Copyright (C) 2018 Google, Inc.
> + *
> + * Author: Hans Verkuil 
> + * Author: Sakari Ailus 
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static const 

Re: [PATCHv13 04/28] media-request: add media_request_get_by_fd

[Sakari Ailus]

On Thu, May 03, 2018 at 04:52:54PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add media_request_get_by_fd() to find a request based on the file
> descriptor.
> 
> The caller has to call media_request_put() for the returned
> request since this function increments the refcount.
> 
> Signed-off-by: Hans Verkuil 

Acked-by: Sakari Ailus 

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

[PATCH] media: vsp1: cleanup a false positive warning

[Mauro Carvalho Chehab]

With the new vsp1 code changes introduced by changeset
f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines dynamically"),
smatch complains with:
drivers/media/platform/vsp1/vsp1_drm.c:262 vsp1_du_pipeline_setup_bru() 
error: we previously assumed 'pipe->bru' could be null (see line 180)

This is a false positive, as, if pipe->bru is NULL, the brx
var will be different, with ends by calling a code that will
set pipe->bru to another value.

Yet, cleaning this false positive is as easy as adding an explicit
check if pipe->bru is NULL.

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

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 095dc48aa25a..cb6b60843400 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device 
*vsp1,
brx = >brs->entity;
 
/* Switch BRx if needed. */
-   if (brx != pipe->brx) {
+   if (brx != pipe->brx || !pipe->brx) {
struct vsp1_entity *released_brx = NULL;
 
/* Release our BRx if we have one. */
-- 
2.17.0

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Paul Kocialkowski]

Hi,

On Fri, 2018-05-04 at 11:15 +0200, Maxime Ripard wrote:
> On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote:
> > > > > > +   reg = <0x01c0e000 0x1000>;
> > > > > > +   memory-region = <_memory>;
> > > > > 
> > > > > Since you made the CMA region the default one, you don't need
> > > > > to
> > > > > tie
> > > > > it to that device in particular (and you can drop it being
> > > > > mandatory
> > > > > from your binding as well).
> > > > 
> > > > What if another driver (or the system) claims memory from that
> > > > zone
> > > > and
> > > > that the reserved memory ends up not being available for the VPU
> > > > anymore?
> > > > 
> > > > Acccording to the reserved-memory documentation, the reusable
> > > > property
> > > > (that we need for dmabuf) puts a limitation that the device
> > > > driver
> > > > owning the region must be able to reclaim it back.
> > > > 
> > > > How does that work out if the CMA region is not tied to a driver
> > > > in
> > > > particular?
> > > 
> > > I'm not sure to get what you're saying. You have the property
> > > linux,cma-default in your reserved region, so the behaviour you
> > > described is what you explicitly asked for.
> > 
> > My point is that I don't see how the driver can claim back (part of)
> > the
> > reserved area if the area is not explicitly attached to it.
> > 
> > Or is that mechanism made in a way that all drivers wishing to use
> > the
> > reserved memory area can claim it back from the system, but there is
> > no
> > priority (other than first-come first-served) for which drivers
> > claims
> > it back in case two want to use the same reserved region (in a
> > scenario
> > where there isn't enough memory to allow both drivers)?
> 
> This is indeed what happens. Reusable is to let the system use the
> reserved memory for things like caches that can easily be dropped when
> a driver wants to use the memory in that reserved area. Once that
> memory has been allocated, there's no claiming back, unless that
> memory segment was freed of course.

Thanks for the clarification. So in our case, perhaps the best fit would
be to make that area the default CMA pool so that we can be ensured that
the whole 96 MiB is available for the VPU and that no other consumer of
CMA will use it?

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [PATCHv13 24/28] vim2m: use workqueue

[Sakari Ailus]

Hi Hans,

On Thu, May 03, 2018 at 04:53:14PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> v4l2_ctrl uses mutexes, so we can't setup a ctrl_handler in
> interrupt context. Switch to a workqueue instead.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/platform/vim2m.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
> index 9be4da3b8577..a1b0bb08668d 100644
> --- a/drivers/media/platform/vim2m.c
> +++ b/drivers/media/platform/vim2m.c
> @@ -150,6 +150,7 @@ struct vim2m_dev {
>   spinlock_t  irqlock;
>  
>   struct timer_list   timer;
> + struct work_struct  work_run;
>  
>   struct v4l2_m2m_dev *m2m_dev;
>  };
> @@ -392,9 +393,10 @@ static void device_run(void *priv)
>   schedule_irq(dev, ctx->transtime);
>  }
>  
> -static void device_isr(struct timer_list *t)
> +static void device_work(struct work_struct *w)
>  {
> - struct vim2m_dev *vim2m_dev = from_timer(vim2m_dev, t, timer);
> + struct vim2m_dev *vim2m_dev =
> + container_of(w, struct vim2m_dev, work_run);
>   struct vim2m_ctx *curr_ctx;
>   struct vb2_v4l2_buffer *src_vb, *dst_vb;
>   unsigned long flags;
> @@ -426,6 +428,13 @@ static void device_isr(struct timer_list *t)
>   }
>  }
>  
> +static void device_isr(struct timer_list *t)
> +{
> + struct vim2m_dev *vim2m_dev = from_timer(vim2m_dev, t, timer);
> +
> + schedule_work(_dev->work_run);
> +}
> +
>  /*
>   * video ioctls
>   */
> @@ -806,6 +815,7 @@ static void vim2m_stop_streaming(struct vb2_queue *q)
>   struct vb2_v4l2_buffer *vbuf;
>   unsigned long flags;
>  
> + flush_scheduled_work();
>   for (;;) {
>   if (V4L2_TYPE_IS_OUTPUT(q->type))
>   vbuf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> @@ -1011,6 +1021,7 @@ static int vim2m_probe(struct platform_device *pdev)
>   vfd = >vfd;
>   vfd->lock = >dev_mutex;
>   vfd->v4l2_dev = >v4l2_dev;
> + INIT_WORK(>work_run, device_work);
>  
>  #ifdef CONFIG_MEDIA_CONTROLLER
>   dev->mdev.dev = >dev;

How about just removing the time and using schedule_delayed_work()
instead? That'd be quite a bit more simple.

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

Re: [PATCH] MAINTAINERS & files: Canonize the e-mails I use at files

[Mauro Carvalho Chehab]

Em Fri, 04 May 2018 13:58:39 +0300
Jani Nikula  escreveu:

> On Fri, 04 May 2018, Mauro Carvalho Chehab  wrote:
> > From now on, I'll start using my @kernel.org as my development e-mail.
> >
> > As such, let's remove the entries that point to the old
> > mche...@s-opensource.com at MAINTAINERS file.
> >
> > For the files written with a copyright with mchehab@s-opensource,
> > let's keep Samsung on their names, using mchehab+sams...@kernel.org,
> > in order to keep pointing to my employer, with sponsors the work.
> >
> > For the files written before I join Samsung (on July, 4 2013),
> > let's just use mche...@kernel.org.
> >
> > For bug reports, we can simply point to just kernel.org, as
> > this will reach my mchehab+samsung inbox anyway.  
> 
> I suppose this begs the question, why do we insist on adding our email
> addresses all over the place? On a quick grep, there are at least 40k+
> email addresses in the sources. Do we expect them all to be up-to-date
> too?

That's a good question.

The usual use case is that the e-mail allows people to contact developers
if needed. Such contact could simply due to something like handling SPDX
or other license-related issues or for troubleshooting.

There's also another reason (with IMHO, is more relevant): just the name
may not be enough to uniquely identify the author of some code. While
that might happen on occidental Countries, this is a way more relevant
for Asian Countries. For example, there are very few surnames on
some Countries there[1], and common names are usually... common. So, it
is not hard to find several people with exactly the same name working at
the same company. I've seen e-mails from those people that are things like
john.doe51@some.company, john.doe69@some.company, ...

[1] For example: https://en.wikipedia.org/wiki/List_of_Korean_surnames.

The e-mail is a way to uniquely identify a person. If we remove it,
then we may need to add another thing instead (like parents names,
security number or whatever), with would be weird, IMO. 

As we all use e-mails to uniquely identify contributors submissions,
IMHO, the best is to keep using e-mails. The side effect is that
we should keep those emails updated.

-

In the specific case of this patch, as I'm now just using @kernel.org
everywhere within the Kernel tree, I don't expect needing to change
it in long term.

Thanks,
Mauro

Re: [PATCH 10/28] venus: vdec: call session_continue in insufficient event

[Vikash Garodia]

Hi Stanimir,

On 2018-05-03 17:06, Stanimir Varbanov wrote:

Hi Vikash,

Thanks for the comments!

On  2.05.2018 09:26, Vikash Garodia wrote:

Hello Stanimir,

On 2018-04-24 18:14, Stanimir Varbanov wrote:

Call session_continue for Venus 4xx version even when the event
says that the buffer resources are not sufficient. Leaving a
comment with more information about the workaround.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/vdec.c
b/drivers/media/platform/qcom/venus/vdec.c
index c45452634e7e..91c7384ff9c8 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -873,6 +873,14 @@ static void vdec_event_notify(struct venus_inst
*inst, u32 event,

 dev_dbg(dev, "event not sufficient resources (%ux%u)\n",
 data->width, data->height);
+    /*
+ * Workaround: Even that the firmware send and event for
+ * insufficient buffer resources it is safe to call
+ * session_continue because actually the event says that
+ * the number of capture buffers is lower.
+ */
+    if (IS_V4(core))
+    hfi_session_continue(inst);
 break;
 case HFI_EVENT_RELEASE_BUFFER_REFERENCE:
 venus_helper_release_buf_ref(inst, data->tag);


Insufficient event from video firmware could be sent either,
1. due to insufficient buffer resources
2. due to lower capture buffers

It cannot be assumed that the event received by the host is due to 
lower capture
buffers. Incase the buffer resource is insufficient, let say there is 
a bitstream
resolution switch from 720p to 1080p, capture buffers needs to be 
reallocated.


I agree with you. I will rework this part and call session_continue
only for case #2.


Even if the capture buffers are lower, driver should consider 
reallocation of capture
buffers with required higher count. Without this, it may happen that for 
a given video
frame, the decoded output will not be generated. The fact that the DPB 
buffer count is
same as capture buffers, will be lower than required. Hence the frame 
which needs YUV
reference beyond the DPB count, will get stuck as it cannot be decoded 
due to unavailability

of sufficient DPB buffers.
Say for ex. 10 DPB and capture buffers are allocated. For a given 
bitstream, firmware requested
the count to be 15. Frame 1 to 10 gets decoded and stored in DPB as 
references for future frame
decoding. Now when the 11th frame is queued to firmware, it can be 
decode but cannot be stored
as reference to decode future (12th) frame. Hence 11 frame will get 
stuck and will not be given

back to host driver.



The driver should be sending the V4L2_EVENT_SOURCE_CHANGE to client 
instead of ignoring

the event from firmware.


The v4l2 event is sent always to v4l clients.

regards,
Stan

Re: [PATCH] MAINTAINERS & files: Canonize the e-mails I use at files

[Jani Nikula]

On Fri, 04 May 2018, Mauro Carvalho Chehab  wrote:
> From now on, I'll start using my @kernel.org as my development e-mail.
>
> As such, let's remove the entries that point to the old
> mche...@s-opensource.com at MAINTAINERS file.
>
> For the files written with a copyright with mchehab@s-opensource,
> let's keep Samsung on their names, using mchehab+sams...@kernel.org,
> in order to keep pointing to my employer, with sponsors the work.
>
> For the files written before I join Samsung (on July, 4 2013),
> let's just use mche...@kernel.org.
>
> For bug reports, we can simply point to just kernel.org, as
> this will reach my mchehab+samsung inbox anyway.

I suppose this begs the question, why do we insist on adding our email
addresses all over the place? On a quick grep, there are at least 40k+
email addresses in the sources. Do we expect them all to be up-to-date
too?


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Hello

[Faruk Sakawo]

I have a business to discuss with you, can we talk?


Regards
Faruk Sakawo

Re: [PATCHv13 02/28] uapi/linux/media.h: add request API

[Sakari Ailus]

On Thu, May 03, 2018 at 04:52:52PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Define the public request API.
> 
> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
> and two ioctls that operate on a request in order to queue the
> contents of the request to the driver and to re-initialize the
> request.
> 
> Signed-off-by: Hans Verkuil 

Acked-by: Sakari Ailus 

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

Re: [PATCHv13 01/28] v4l2-device.h: always expose mdev

[Sakari Ailus]

On Thu, May 03, 2018 at 04:52:51PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The mdev field is only present if CONFIG_MEDIA_CONTROLLER is set.
> But since we will need to pass the media_device to vb2 and the
> control framework it is very convenient to just make this field
> available all the time. If CONFIG_MEDIA_CONTROLLER is not set,
> then it will just be NULL.
> 
> Signed-off-by: Hans Verkuil 

Acked-by: Sakari Ailus 

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

[GIT PULL for v4.17-rc4] media fixes and a MAINTAINERS file update with my email

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.17-4


For:

- a trivial one-line fix addressing a PTR_ERR() getting value from a wrong
  var at imx driver;

- a patch changing my e-mail at the Kernel tree to mche...@kernel.org.
  no code changes.

Thanks!
Mauro  


The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:

  Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.17-4

for you to fetch changes up to 3259081991a9398434f6f49468b960f136ac0158:

  MAINTAINERS & files: Canonize the e-mails I use at files (2018-05-04 06:21:06 
-0400)


media fixes for v4.17-rc4


From: Gustavo A. R. Silva (1):
  media: imx-media-csi: Fix inconsistent IS_ERR and PTR_ERR

Mauro Carvalho Chehab (1):
  MAINTAINERS & files: Canonize the e-mails I use at files

 Documentation/doc-guide/parse-headers.rst   |  4 ++--
 Documentation/media/uapi/rc/keytable.c.rst  |  2 +-
 Documentation/media/uapi/v4l/v4l2grab.c.rst |  2 +-
 Documentation/sphinx/parse-headers.pl   |  4 ++--
 .../translations/zh_CN/video4linux/v4l2-framework.txt   |  4 ++--
 MAINTAINERS | 17 -
 drivers/media/i2c/saa7115.c |  2 +-
 drivers/media/i2c/saa711x_regs.h|  2 +-
 drivers/media/i2c/tda7432.c |  2 +-
 drivers/media/i2c/tvp5150.c |  2 +-
 drivers/media/i2c/tvp5150_reg.h |  2 +-
 drivers/media/i2c/tvp7002.c |  2 +-
 drivers/media/i2c/tvp7002_reg.h |  2 +-
 drivers/media/media-devnode.c   |  2 +-
 drivers/media/pci/bt8xx/bttv-audio-hook.c   |  2 +-
 drivers/media/pci/bt8xx/bttv-audio-hook.h   |  2 +-
 drivers/media/pci/bt8xx/bttv-cards.c|  4 ++--
 drivers/media/pci/bt8xx/bttv-driver.c   |  2 +-
 drivers/media/pci/bt8xx/bttv-i2c.c  |  2 +-
 drivers/media/pci/cx23885/cx23885-input.c   |  2 +-
 drivers/media/pci/cx88/cx88-alsa.c  |  4 ++--
 drivers/media/pci/cx88/cx88-blackbird.c |  2 +-
 drivers/media/pci/cx88/cx88-core.c  |  2 +-
 drivers/media/pci/cx88/cx88-i2c.c   |  2 +-
 drivers/media/pci/cx88/cx88-video.c |  2 +-
 drivers/media/radio/radio-aimslab.c |  2 +-
 drivers/media/radio/radio-aztech.c  |  2 +-
 drivers/media/radio/radio-gemtek.c  |  2 +-
 drivers/media/radio/radio-maxiradio.c   |  2 +-
 drivers/media/radio/radio-rtrack2.c |  2 +-
 drivers/media/radio/radio-sf16fmi.c |  2 +-
 drivers/media/radio/radio-terratec.c|  2 +-
 drivers/media/radio/radio-trust.c   |  2 +-
 drivers/media/radio/radio-typhoon.c |  2 +-
 drivers/media/radio/radio-zoltrix.c |  2 +-
 drivers/media/rc/keymaps/rc-avermedia-m135a.c   |  2 +-
 drivers/media/rc/keymaps/rc-encore-enltv-fm53.c |  2 +-
 drivers/media/rc/keymaps/rc-encore-enltv2.c |  2 +-
 drivers/media/rc/keymaps/rc-kaiomy.c|  2 +-
 drivers/media/rc/keymaps/rc-kworld-plus-tv-analog.c |  2 +-
 drivers/media/rc/keymaps/rc-pixelview-new.c |  2 +-
 drivers/media/tuners/tea5761.c  |  4 ++--
 drivers/media/tuners/tea5767.c  |  4 ++--
 drivers/media/tuners/tuner-xc2028-types.h   |  2 +-
 drivers/media/tuners/tuner-xc2028.c |  4 ++--
 drivers/media/tuners/tuner-xc2028.h |  2 +-
 drivers/media/usb/em28xx/em28xx-camera.c|  2 +-
 drivers/media/usb/em28xx/em28xx-cards.c |  2 +-
 drivers/media/usb/em28xx/em28xx-core.c  |  4 ++--
 drivers/media/usb/em28xx/em28xx-dvb.c   |  4 ++--
 drivers/media/usb/em28xx/em28xx-i2c.c   |  2 +-
 drivers/media/usb/em28xx/em28xx-input.c |  2 +-
 drivers/media/usb/em28xx/em28xx-video.c |  4 ++--
 drivers/media/usb/em28xx/em28xx.h   |  2 +-
 drivers/media/usb/gspca/zc3xx-reg.h |  2 +-
 drivers/media/usb/tm6000/tm6000-cards.c |  2 +-
 drivers/media/usb/tm6000/tm6000-core.c  |  2 +-
 drivers/media/usb/tm6000/tm6000-i2c.c   |  2 +-
 drivers/media/usb/tm6000/tm6000-regs.h  |  2 +-
 

[PATCH] MAINTAINERS & files: Canonize the e-mails I use at files

[Mauro Carvalho Chehab]

>From now on, I'll start using my @kernel.org as my development e-mail.

As such, let's remove the entries that point to the old
mche...@s-opensource.com at MAINTAINERS file.

For the files written with a copyright with mchehab@s-opensource,
let's keep Samsung on their names, using mchehab+sams...@kernel.org,
in order to keep pointing to my employer, with sponsors the work.

For the files written before I join Samsung (on July, 4 2013),
let's just use mche...@kernel.org.

For bug reports, we can simply point to just kernel.org, as
this will reach my mchehab+samsung inbox anyway.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Brian Warner 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/doc-guide/parse-headers.rst   |  4 ++--
 Documentation/media/uapi/rc/keytable.c.rst  |  2 +-
 Documentation/media/uapi/v4l/v4l2grab.c.rst |  2 +-
 Documentation/sphinx/parse-headers.pl   |  4 ++--
 .../zh_CN/video4linux/v4l2-framework.txt|  4 ++--
 MAINTAINERS | 17 -
 drivers/media/i2c/saa7115.c |  2 +-
 drivers/media/i2c/saa711x_regs.h|  2 +-
 drivers/media/i2c/tda7432.c |  2 +-
 drivers/media/i2c/tvp5150.c |  2 +-
 drivers/media/i2c/tvp5150_reg.h |  2 +-
 drivers/media/i2c/tvp7002.c |  2 +-
 drivers/media/i2c/tvp7002_reg.h |  2 +-
 drivers/media/media-devnode.c   |  2 +-
 drivers/media/pci/bt8xx/bttv-audio-hook.c   |  2 +-
 drivers/media/pci/bt8xx/bttv-audio-hook.h   |  2 +-
 drivers/media/pci/bt8xx/bttv-cards.c|  4 ++--
 drivers/media/pci/bt8xx/bttv-driver.c   |  2 +-
 drivers/media/pci/bt8xx/bttv-i2c.c  |  2 +-
 drivers/media/pci/cx23885/cx23885-input.c   |  2 +-
 drivers/media/pci/cx88/cx88-alsa.c  |  4 ++--
 drivers/media/pci/cx88/cx88-blackbird.c |  2 +-
 drivers/media/pci/cx88/cx88-core.c  |  2 +-
 drivers/media/pci/cx88/cx88-i2c.c   |  2 +-
 drivers/media/pci/cx88/cx88-video.c |  2 +-
 drivers/media/radio/radio-aimslab.c |  2 +-
 drivers/media/radio/radio-aztech.c  |  2 +-
 drivers/media/radio/radio-gemtek.c  |  2 +-
 drivers/media/radio/radio-maxiradio.c   |  2 +-
 drivers/media/radio/radio-rtrack2.c |  2 +-
 drivers/media/radio/radio-sf16fmi.c |  2 +-
 drivers/media/radio/radio-terratec.c|  2 +-
 drivers/media/radio/radio-trust.c   |  2 +-
 drivers/media/radio/radio-typhoon.c |  2 +-
 drivers/media/radio/radio-zoltrix.c |  2 +-
 drivers/media/rc/keymaps/rc-avermedia-m135a.c   |  2 +-
 drivers/media/rc/keymaps/rc-encore-enltv-fm53.c |  2 +-
 drivers/media/rc/keymaps/rc-encore-enltv2.c |  2 +-
 drivers/media/rc/keymaps/rc-kaiomy.c|  2 +-
 .../media/rc/keymaps/rc-kworld-plus-tv-analog.c |  2 +-
 drivers/media/rc/keymaps/rc-pixelview-new.c |  2 +-
 drivers/media/tuners/tea5761.c  |  4 ++--
 drivers/media/tuners/tea5767.c  |  4 ++--
 drivers/media/tuners/tuner-xc2028-types.h   |  2 +-
 drivers/media/tuners/tuner-xc2028.c |  4 ++--
 drivers/media/tuners/tuner-xc2028.h |  2 +-
 drivers/media/usb/em28xx/em28xx-camera.c|  2 +-
 drivers/media/usb/em28xx/em28xx-cards.c |  2 +-
 drivers/media/usb/em28xx/em28xx-core.c  |  4 ++--
 drivers/media/usb/em28xx/em28xx-dvb.c   |  4 ++--
 drivers/media/usb/em28xx/em28xx-i2c.c   |  2 +-
 drivers/media/usb/em28xx/em28xx-input.c |  2 +-
 drivers/media/usb/em28xx/em28xx-video.c |  4 ++--
 drivers/media/usb/em28xx/em28xx.h   |  2 +-
 drivers/media/usb/gspca/zc3xx-reg.h |  2 +-
 drivers/media/usb/tm6000/tm6000-cards.c |  2 +-
 drivers/media/usb/tm6000/tm6000-core.c  |  2 +-
 drivers/media/usb/tm6000/tm6000-i2c.c   |  2 +-
 drivers/media/usb/tm6000/tm6000-regs.h  |  2 +-
 drivers/media/usb/tm6000/tm6000-usb-isoc.h  |  2 +-
 drivers/media/usb/tm6000/tm6000-video.c |  2 +-
 drivers/media/usb/tm6000/tm6000.h   |  2 +-
 drivers/media/v4l2-core/v4l2-dev.c  |  4 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c|  2 +-
 drivers/media/v4l2-core/videobuf-core.c |  6 +++---
 drivers/media/v4l2-core/videobuf-dma-contig.c   |  2 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c   |  6 +++---
 drivers/media/v4l2-core/videobuf-vmalloc.c  |  4 ++--
 include/media/i2c/tvp7002.h |  2 +-
 include/media/videobuf-core.h   |  4 ++--
 include/media/videobuf-dma-sg.h |  4 ++--
 include/media/videobuf-vmalloc.h|  2 +-
 scripts/extract_xc3028.pl   |  2 +-
 

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

[Loic Poulain]

Hi,

On 3 May 2018 at 17:16, Maxime Ripard  wrote:
> Hi,
>
> On Wed, May 02, 2018 at 11:11:55AM -0700, Sam Bobrowicz wrote:
>> > On Wednesday, 25 April 2018 01:11:19 EEST Sam Bobrowicz wrote:
>> >> FYI, still hard at work on this. Did some more experiments last week
>> >> that seemed to corroborate the clock tree in the spreadsheet. It also
>> >> seems that the output of the P divider cell, SCLK cell and MIPI Rate
>> >> cell in the spreadsheet must have a ratio of 2x:1x:8x (respectively)
>> >> in order for the sensor to work properly on my platform, and that the
>> >> SCLK value must be close to the "rate" variable that you calculate and
>> >> pass to set_mipi_pclk. Unfortunately, I've only got the sensor working
>> >> well for 1080p@15Hz and 720p@30Hz, both with a SCLK of 42MHz (aka
>> >> 84:42:336). I'm running experiments now trying to adjust the htot and
>> >> vtot values to create different required rates, and also to try to get
>> >> faster Mipi rates working. Any information you have on the
>> >> requirements of the htot and vtot values with respect to vact and hact
>> >> values would likely be helpful.
>> >>
>> >> I'm also keeping an eye on the scaler clock, which I think may be
>> >> affecting certain resolutions, but haven't been able to see it make a
>> >> difference yet (see register 0x3824 and 0x460c)
>> >>
>> >> I plan on pushing a set of patches once I get this figured out, we can
>> >> discuss what I should base them on when I get closer to that point.
>> >> I'm new to this process :)
>> >
>> > I'm also interested in getting the ov5640 driver working with MIPI CSI-2.
>> > Studying the datasheet and the driver code, I found the stream on sequence 
>> > to
>> > be a bit weird. In particular the configuration of 
>> > OV5640_REG_IO_MIPI_CTRL00,
>> > OV5640_REG_PAD_OUTPUT00 and OV5640_REG_MIPI_CTRL00 caught my attention.
>> >
>> > OV5640_REG_IO_MIPI_CTRL00 (0x300e) is set to 0x45 in the large array of 
>> > init
>> > mode data and never touched for MIPI CSI-2 (the register is only touched in
>> > ov5640_set_stream_dvp). The value means
>> >
>> > - mipi_lane_mode: 010 is documented as "debug mode", I would have expected 
>> > 000
>> > for one lane or 001 for two lanes.
>>
>> I noticed this too, but it seems that 010 is the correct value for two
>> lane mode. I think this is a typo in the datasheet.
>>
>> >
>> > - MIPI TX PHY power down: 0 is documented as "debug mode" and 1 as "Power 
>> > down
>> > PHY HS TX", so I suppose 0 is correct.
>> >
>> > - MIPI RX PHY power down: 0 is documented as "debug mode" and 1 as "Power 
>> > down
>> > PHY LP RX module", so I suppose 0 is correct. I however wonder why there's 
>> > a
>> > RX PHY, it could be a typo.
>> >
>> > - mipi_en: 1 means MIPI enable, which should be correct.
>> >
>> > - BIT(0) is undocumented.
>> >
>> > OV5640_REG_PAD_OUTPUT00 (0x3019) isn't initialized explicitly and thus 
>> > retains
>> > its default value of 0x00, and is controlled when starting and stopping the
>> > stream where it's set to 0x00 and 0x70 respectively. Bits 6:4 control the
>> > "sleep mode" state of lane 2, lane 1 and clock lane respectively, and 
>> > should
>> > be LP11 in my opinion (that's the PHY stop state). However, setting them to
>> > 0x00 when starting the stream mean that LP00 is selected as the sleep 
>> > state at
>> > stream start, and LP11 when stopping the stream. Maybe "sleep mode" means
>> > LPDT, but I would expect that to be controlled by the idle status bit in
>> > register 0x4800.
>> >
>>
>> I did not need to mess with the accesses to 0x3019 in order to get
>> things working on my system. I'm not sure of this registers actual
>> behavior, but it might affect idling while not streaming (after power
>> on). My pipeline currently only powers the sensor while streaming, so
>> I might be missing some ramifications of this register.
>>
>> > OV5640_REG_MIPI_CTRL00 (0x4800) is set to 0x04 in the large array of init 
>> > mode
>> > data, and BIT(5) is then cleared at stream on time and set at stream off 
>> > time.
>> > This means:
>> >
>> > - Clock lane gate enable: Clock lane is free running
>> > - Line sync enable: Do not send line short packets for each line (I assume
>> > that's LS/LE)
>> > - Lane select: Use lane1 as default data lane.
>> > - Idle status: MIPI bus will be LP11 when no packet to transmit. I would 
>> > have
>> > expected the idle status to correspond to LPDT, and thus be LP00 (as 
>> > opposed
>> > to the stop state that should be LP11, which I believe is named "sleep 
>> > mode"
>> > in the datasheet and controlled in register 0x3019).
>> >
>> > BIT(5) is the clock lane gate enable, so at stream on time the clock is 
>> > set to
>> > free running, and at stream off time to "Gate clock lane when no packet to
>> > transmit". Couldn't we always enable clock gating ?
>>
>> Good question, it might be worth testing. Same as above, I didn't need
>> to mess with this reg either.
>>
>> > Do you have any insight on 

[PATCH] media: renesas-ceu: Set mbus_fmt on subdev operations

[Jacopo Mondi]

The renesas-ceu driver intializes the desired mbus_format at 'complete'
time, inspecting the supported subdevice ones, and tuning some
parameters to produce the requested memory format from what the sensor
can produce. Although, the initially selected mbus_format was not
provided to the subdevice during set_fmt and try_fmt operations,
providing instead a '0' mbus format code.

As long as the sensor defaults to a compatible mbus_format when an
invalid code as '0' is provided, capture operations work correctly. If
the subdevice defaults to an unsupported format (eg. some RGB
permutations) capture does not work properly due to a mismatch on the
expected and received image format on the wire.

Fix that by re-using the initially selected mbus_format code during
set_fmt and try_fmt subdevice operation calls.

Tested by printing out the format selection procedure with ov7670
sensor.

Before this patch:
[0.866001] ov7670_try_fmt_internal -- Looking for mbus_code 0x
[0.870882] ov7670_try_fmt_internal -- Try mbus_code 0x2008
[0.876336] ov7670_try_fmt_internal -- Try mbus_code 0x1002
[0.881387] ov7670_try_fmt_internal -- Try mbus_code 0x1008
[0.886537] ov7670_try_fmt_internal -- Try mbus_code 0x3001
[0.891584] ov7670_try_fmt_internal -- mbus_code defaulted to 0x2008

With this patch applied:
[0.867015] ov7670_try_fmt_internal -- Looking for mbus_code 0x2008
[0.873205] ov7670_try_fmt_internal -- Try mbus_code 0x2008: match

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/renesas-ceu.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
index 6599dba..dec1b35 100644
--- a/drivers/media/platform/renesas-ceu.c
+++ b/drivers/media/platform/renesas-ceu.c
@@ -777,8 +777,15 @@ static int ceu_try_fmt(struct ceu_device *ceudev, struct 
v4l2_format *v4l2_fmt)
const struct ceu_fmt *ceu_fmt;
int ret;

+   /*
+* Set format on sensor sub device: bus format used to produce memory
+* format is selected at initialization time.
+*/
struct v4l2_subdev_format sd_format = {
-   .which = V4L2_SUBDEV_FORMAT_TRY,
+   .which  = V4L2_SUBDEV_FORMAT_TRY,
+   .format = {
+   .code = ceu_sd->mbus_fmt.mbus_code,
+   },
};

switch (pix->pixelformat) {
@@ -800,10 +807,6 @@ static int ceu_try_fmt(struct ceu_device *ceudev, struct 
v4l2_format *v4l2_fmt)
v4l_bound_align_image(>width, 2, CEU_MAX_WIDTH, 4,
  >height, 4, CEU_MAX_HEIGHT, 4, 0);

-   /*
-* Set format on sensor sub device: bus format used to produce memory
-* format is selected at initialization time.
-*/
v4l2_fill_mbus_format_mplane(_format.format, pix);
ret = v4l2_subdev_call(v4l2_sd, pad, set_fmt, _cfg, _format);
if (ret)
@@ -827,8 +830,15 @@ static int ceu_set_fmt(struct ceu_device *ceudev, struct 
v4l2_format *v4l2_fmt)
struct v4l2_subdev *v4l2_sd = ceu_sd->v4l2_sd;
int ret;

+   /*
+* Set format on sensor sub device: bus format used to produce memory
+* format is selected at initialization time.
+*/
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   .format = {
+   .code = ceu_sd->mbus_fmt.mbus_code,
+   },
};

ret = ceu_try_fmt(ceudev, v4l2_fmt);
--
2.7.4

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

[Daniel Vetter]

On Fri, May 4, 2018 at 11:16 AM, Chris Wilson  wrote:
> Quoting Daniel Vetter (2018-05-04 09:57:59)
>> On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote:
>> > Quoting Daniel Vetter (2018-05-04 09:23:01)
>> > > On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote:
>> > > > On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote:
>> > > > > Quoting Daniel Vetter (2018-05-03 15:25:52)
>> > > > > > Almost everyone uses dma_fence_default_wait.
>> > > > > >
>> > > > > > v2: Also remove the BUG_ON(!ops->wait) (Chris).
>> > > > >
>> > > > > I just don't get the rationale for implicit over explicit.
>> > > >
>> > > > Closer approximation of dwim semantics. There's been tons of patch 
>> > > > series
>> > > > all over drm and related places to get there, once we have a big pile 
>> > > > of
>> > > > implementations and know what the dwim semantics should be. 
>> > > > Individually
>> > > > they're all not much, in aggregate they substantially simplify simple
>> > > > drivers.
>> > >
>> > > I also think clearer separation between optional optimization hooks and
>> > > mandatory core parts is useful in itself.
>> >
>> > A new spelling of midlayer ;) I don't see the contradiction with a
>> > driver saying use the default and simplicity. (I know which one the
>> > compiler thinks is simpler ;)
>>
>> If the compiler overhead is real then I guess it would makes to be
>> explicit. I don't expect that to be a problem though for a blocking
>> function.
>>
>> I disagree on this being a midlayer - you can still overwrite everything
>> you please to. What it does help is people doing less copypasting (and
>> assorted bugs), at least in the grand scheme of things. And we do have a
>> _lot_ more random small drivers than just a few years ago. Reducing the
>> amount of explicit typing just to get default bahaviour has been an
>> ongoing theme for a few years now, and your objection here is about the
>> first that this is not a good idea. So I'm somewhat confused.
>
> I'm just saying I don't see any rationale for this patch.
>
> "Almost everyone uses dma_fence_default_wait."
>
> Why change?
>
> Making it look simpler on the surface, so that you don't have to think
> about things straight away? I understand the appeal, but I do worry
> about it just being an illusion. (Cutting and pasting a line saying
> .wait = default_wait, doesn't feel that onerous, as you likely cut and
> paste the ops anyway, and at the very least you are reminded about some
> of the interactions. You could even have default initializers and/or
> magic macros to hide the cut and paste; maybe a simple_dma_fence [now
> that's a midlayer!] but I haven't looked.)

In really monolithic vtables like drm_driver we do use default
function macros, so you type 1 line, get them all. But dma_fence_ops
is pretty small, and most drivers only implement a few callbacks. Also
note that e.g. the ->release callback already works like that, so this
pattern is there already. I simply extended it to ->wait and
->enable_signaling. Also note that I leave the EXPORT_SYMBOL in place,
you can still wrap dma_fence_default_wait if you wish to do so.

But I just realized that I didn't clean out the optional release
hooks, I guess I should do that too (for the few cases it's not yet
done) and respin.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Maxime Ripard]

On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote:
> > > > > + reg = <0x01c0e000 0x1000>;
> > > > > + memory-region = <_memory>;
> > > > 
> > > > Since you made the CMA region the default one, you don't need to
> > > > tie
> > > > it to that device in particular (and you can drop it being
> > > > mandatory
> > > > from your binding as well).
> > > 
> > > What if another driver (or the system) claims memory from that zone
> > > and
> > > that the reserved memory ends up not being available for the VPU
> > > anymore?
> > > 
> > > Acccording to the reserved-memory documentation, the reusable
> > > property
> > > (that we need for dmabuf) puts a limitation that the device driver
> > > owning the region must be able to reclaim it back.
> > > 
> > > How does that work out if the CMA region is not tied to a driver in
> > > particular?
> > 
> > I'm not sure to get what you're saying. You have the property
> > linux,cma-default in your reserved region, so the behaviour you
> > described is what you explicitly asked for.
> 
> My point is that I don't see how the driver can claim back (part of) the
> reserved area if the area is not explicitly attached to it.
> 
> Or is that mechanism made in a way that all drivers wishing to use the
> reserved memory area can claim it back from the system, but there is no
> priority (other than first-come first-served) for which drivers claims
> it back in case two want to use the same reserved region (in a scenario
> where there isn't enough memory to allow both drivers)?

This is indeed what happens. Reusable is to let the system use the
reserved memory for things like caches that can easily be dropped when
a driver wants to use the memory in that reserved area. Once that
memory has been allocated, there's no claiming back, unless that
memory segment was freed of course.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

[Daniel Vetter]

On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-05-04 09:23:01)
> > On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote:
> > > On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote:
> > > > Quoting Daniel Vetter (2018-05-03 15:25:52)
> > > > > Almost everyone uses dma_fence_default_wait.
> > > > > 
> > > > > v2: Also remove the BUG_ON(!ops->wait) (Chris).
> > > > 
> > > > I just don't get the rationale for implicit over explicit.
> > > 
> > > Closer approximation of dwim semantics. There's been tons of patch series
> > > all over drm and related places to get there, once we have a big pile of
> > > implementations and know what the dwim semantics should be. Individually
> > > they're all not much, in aggregate they substantially simplify simple
> > > drivers.
> > 
> > I also think clearer separation between optional optimization hooks and
> > mandatory core parts is useful in itself.
> 
> A new spelling of midlayer ;) I don't see the contradiction with a
> driver saying use the default and simplicity. (I know which one the
> compiler thinks is simpler ;)

If the compiler overhead is real then I guess it would makes to be
explicit. I don't expect that to be a problem though for a blocking
function.

I disagree on this being a midlayer - you can still overwrite everything
you please to. What it does help is people doing less copypasting (and
assorted bugs), at least in the grand scheme of things. And we do have a
_lot_ more random small drivers than just a few years ago. Reducing the
amount of explicit typing just to get default bahaviour has been an
ongoing theme for a few years now, and your objection here is about the
first that this is not a good idea. So I'm somewhat confused.

It's ofc not all that useful when looking only through the i915
perspective, where we overwrite almost everything anyway. But the
ecosystem is a bit bigger than just i915.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Paul Kocialkowski]

On Fri, 2018-05-04 at 10:47 +0200, Paul Kocialkowski wrote:
> > > > Don't you also need to map the SRAM on the A20?
> > > 
> > > That's a good point, there is currently no syscon handle for A20
> > > (and
> > > also A13). Maybe SRAM is muxed to the VE by default so it "just
> > > works"? 

I just checked on the manual and it appears that SRAM Area C1 is muxed
to the VE at reset, so we can probably keep things as-is until the SRAM
driver is ready to handle explicitly muxing that area to the VE.

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

[Paul Kocialkowski]

On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> Stateless video decoding engines require both the MPEG slices and
> associated metadata from the video stream in order to decode frames.
> 
> This introduces definitions for a new pixel format, describing buffers
> with MPEG2 slice data, as well as a control structure for passing the
> frame header (metadata) to drivers.

While working on this, I came accross Hugues Fruchet's series that also
adds similar definitions for parsed MPEG2 metadata:
https://patchwork.kernel.org/patch/9704707/

Since that version made it to a v6, I will take the time to read the
discussion and see what needs to be changed in my proposal, so that we
can avoid discussing the same points over a year later.

This will most likely not make it to the next revision of the driver
series, so I will keep the format/controls definitions in their v2 state
(despite all the useful comments received) and take the time to properly
rework things in a future revision.

Cheers,

Paul

> Signed-off-by: Paul Kocialkowski 
> Signed-off-by: Florent Revest 
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
>  include/uapi/linux/v4l2-controls.h   | 26 ++
>  include/uapi/linux/videodev2.h   |  3 +++
>  4 files changed, 40 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index ba05a8b9a095..fcdc12b9a9e0 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -761,6 +761,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>   case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: re
> turn "Vertical MV Search Range";
>   case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: re
> turn "Repeat Sequence Header";
>   case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:   retu
> rn "Force Key Frame";
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:   retu
> rn "MPEG2 Frame Header";
>  
>   /* VPX controls */
>   case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:r
> eturn "VPX Number of Partitions";
> @@ -1152,6 +1153,9 @@ void v4l2_ctrl_fill(u32 id, const char **name,
> enum v4l2_ctrl_type *type,
>   case V4L2_CID_RDS_TX_ALT_FREQS:
>   *type = V4L2_CTRL_TYPE_U32;
>   break;
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> + *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> + break;
>   default:
>   *type = V4L2_CTRL_TYPE_INTEGER;
>   break;
> @@ -1472,6 +1476,9 @@ static int std_validate(const struct v4l2_ctrl
> *ctrl, u32 idx,
>   return -ERANGE;
>   return 0;
>  
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + return 0;
> +
>   default:
>   return -EINVAL;
>   }
> @@ -2046,6 +2053,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
>   case V4L2_CTRL_TYPE_U32:
>   elem_size = sizeof(u32);
>   break;
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
> + break;
>   default:
>   if (type < V4L2_CTRL_COMPOUND_TYPES)
>   elem_size = sizeof(s32);
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 468c3c65362d..8070203da5d2 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1273,6 +1273,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> *fmt)
>   case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1
> (SMPTE 412M Annex L)"; break;
>   case V4L2_PIX_FMT_VP8:  descr = "VP8";
> break;
>   case V4L2_PIX_FMT_VP9:  descr = "VP9";
> break;
> + case V4L2_PIX_FMT_MPEG2_FRAME:  descr = "MPEG2
> Frame"; break;
>   case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA
> YUV"; break;
>   case V4L2_PIX_FMT_WNVA: descr =
> "WNVA"; break;
>   case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA
> SN9C10X"; break;
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index cbbb750d87d1..8431b2a540c7 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
>  };
>  #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL   (V4L2_CID_MPEG_
> BASE+407)
>  
> +#define
> V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> +
>  /*  Control IDs for VP8 streams
>   *  Although VP8 is not part of MPEG we add these controls to the
> MPEG class
>   *  as that class is already handling other video compression
> standards
> @@ -985,4 +987,28 @@ enum v4l2_detect_md_mode {
>  #define 

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Paul Kocialkowski]

Hi,

On Fri, 2018-05-04 at 10:40 +0200, Maxime Ripard wrote:
> On Fri, May 04, 2018 at 09:49:16AM +0200, Paul Kocialkowski wrote:
> > > > +   reserved-memory {
> > > > +   #address-cells = <1>;
> > > > +   #size-cells = <1>;
> > > > +   ranges;
> > > > +
> > > > +   /* Address must be kept in the lower 256 MiBs
> > > > of
> > > > DRAM for VE. */
> > > > +   ve_memory: cma@4a00 {
> > > > +   compatible = "shared-dma-pool";
> > > > +   reg = <0x4a00 0x600>;
> > > > +   no-map;
> > > 
> > > I'm not sure why no-map is needed.
> > 
> > In fact, having no-map here would lead to reserving the area as
> > cache-
> > coherent instead of contiguous and thus prevented dmabuf support.
> > Replacing it by "resuable" allows proper CMA reservation.
> > 
> > > And I guess we could use alloc-ranges to make sure the region is
> > > in
> > > the proper memory range, instead of hardcoding it.
> > 
> > As far as I could understand from the documentation, "alloc-ranges"
> > is
> > used for dynamic allocation while only "reg" is used for static
> > allocation. We are currently going with static allocation and thus
> > reserve the whole 96 MiB. Is using dynamic allocation instead
> > desirable
> > here?
> 
> I guess we could turn the question backward. Why do we need a static
> allocation? This isn't a buffer that is always allocated on the same
> area, but rather that we have a range available. So our constraint is
> on the range, nothing else.

That makes sense, I will give it a shot with a range then.

> > > > +   reg = <0x01c0e000 0x1000>;
> > > > +   memory-region = <_memory>;
> > > 
> > > Since you made the CMA region the default one, you don't need to
> > > tie
> > > it to that device in particular (and you can drop it being
> > > mandatory
> > > from your binding as well).
> > 
> > What if another driver (or the system) claims memory from that zone
> > and
> > that the reserved memory ends up not being available for the VPU
> > anymore?
> > 
> > Acccording to the reserved-memory documentation, the reusable
> > property
> > (that we need for dmabuf) puts a limitation that the device driver
> > owning the region must be able to reclaim it back.
> > 
> > How does that work out if the CMA region is not tied to a driver in
> > particular?
> 
> I'm not sure to get what you're saying. You have the property
> linux,cma-default in your reserved region, so the behaviour you
> described is what you explicitly asked for.

My point is that I don't see how the driver can claim back (part of) the
reserved area if the area is not explicitly attached to it.

Or is that mechanism made in a way that all drivers wishing to use the
reserved memory area can claim it back from the system, but there is no
priority (other than first-come first-served) for which drivers claims
it back in case two want to use the same reserved region (in a scenario
where there isn't enough memory to allow both drivers)?

> > > > +
> > > > +   clocks = < CLK_AHB_VE>, <
> > > > CLK_VE>,
> > > > +< CLK_DRAM_VE>;
> > > > +   clock-names = "ahb", "mod", "ram";
> > > > +
> > > > +   assigned-clocks = < CLK_VE>;
> > > > +   assigned-clock-rates = <32000>;
> > > 
> > > This should be set from within the driver. If it's something that
> > > you
> > > absolutely needed for the device to operate, you have no guarantee
> > > that the clock rate won't change at any point in time after the
> > > device
> > > probe, so that's not a proper solution.
> > > 
> > > And if it's not needed and can be adjusted depending on the
> > > framerate/codec/resolution, then it shouldn't be in the DT either.
> > 
> > Yes, that makes sense.
> > 
> > > Don't you also need to map the SRAM on the A20?
> > 
> > That's a good point, there is currently no syscon handle for A20
> > (and
> > also A13). Maybe SRAM is muxed to the VE by default so it "just
> > works"? 
> > 
> > I'll investigate on this side, also keeping in mind that the actual
> > solution is to use the SRAM controller driver (but that won't make
> > it to
> > v3).
> 
> The SRAM driver is available on the A20, so you should really use that
> instead of a syscon.

The SRAM driver is indeed available for the A20, but still lacks support
for the VE in particular as far as I can see.

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Maxime Ripard]

On Fri, May 04, 2018 at 09:49:16AM +0200, Paul Kocialkowski wrote:
> > > + reserved-memory {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > +
> > > + /* Address must be kept in the lower 256 MiBs of
> > > DRAM for VE. */
> > > + ve_memory: cma@4a00 {
> > > + compatible = "shared-dma-pool";
> > > + reg = <0x4a00 0x600>;
> > > + no-map;
> > 
> > I'm not sure why no-map is needed.
> 
> In fact, having no-map here would lead to reserving the area as cache-
> coherent instead of contiguous and thus prevented dmabuf support.
> Replacing it by "resuable" allows proper CMA reservation.
> 
> > And I guess we could use alloc-ranges to make sure the region is in
> > the proper memory range, instead of hardcoding it.
> 
> As far as I could understand from the documentation, "alloc-ranges" is
> used for dynamic allocation while only "reg" is used for static
> allocation. We are currently going with static allocation and thus
> reserve the whole 96 MiB. Is using dynamic allocation instead desirable
> here?

I guess we could turn the question backward. Why do we need a static
allocation? This isn't a buffer that is always allocated on the same
area, but rather that we have a range available. So our constraint is
on the range, nothing else.

> > > + reg = <0x01c0e000 0x1000>;
> > > + memory-region = <_memory>;
> > 
> > Since you made the CMA region the default one, you don't need to tie
> > it to that device in particular (and you can drop it being mandatory
> > from your binding as well).
> 
> What if another driver (or the system) claims memory from that zone and
> that the reserved memory ends up not being available for the VPU
> anymore?
> 
> Acccording to the reserved-memory documentation, the reusable property
> (that we need for dmabuf) puts a limitation that the device driver
> owning the region must be able to reclaim it back.
> 
> How does that work out if the CMA region is not tied to a driver in
> particular?

I'm not sure to get what you're saying. You have the property
linux,cma-default in your reserved region, so the behaviour you
described is what you explicitly asked for.

> 
> > > +
> > > + clocks = < CLK_AHB_VE>, < CLK_VE>,
> > > +  < CLK_DRAM_VE>;
> > > + clock-names = "ahb", "mod", "ram";
> > > +
> > > + assigned-clocks = < CLK_VE>;
> > > + assigned-clock-rates = <32000>;
> > 
> > This should be set from within the driver. If it's something that you
> > absolutely needed for the device to operate, you have no guarantee
> > that the clock rate won't change at any point in time after the device
> > probe, so that's not a proper solution.
> > 
> > And if it's not needed and can be adjusted depending on the
> > framerate/codec/resolution, then it shouldn't be in the DT either.
> 
> Yes, that makes sense.
> 
> > Don't you also need to map the SRAM on the A20?
> 
> That's a good point, there is currently no syscon handle for A20 (and
> also A13). Maybe SRAM is muxed to the VE by default so it "just works"? 
> 
> I'll investigate on this side, also keeping in mind that the actual
> solution is to use the SRAM controller driver (but that won't make it to
> v3).

The SRAM driver is available on the A20, so you should really use that
instead of a syscon.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 2/2] media: imx: add support for RGB565_2X8 on parallel bus

[kbuild test robot]

Hi Jan,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc3 next-20180503]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jan-Luebbe/media-imx-add-capture-support-for-RGB565_2X8-on-parallel-bus/20180504-120003
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)


vim +652 drivers/staging/media/imx/imx-media-csi.c

   640  
   641  /* Update the CSI whole sensor and active windows */
   642  static int csi_setup(struct csi_priv *priv)
   643  {
   644  struct v4l2_mbus_framefmt *infmt, *outfmt;
   645  struct v4l2_mbus_config mbus_cfg;
   646  struct v4l2_mbus_framefmt if_fmt;
   647  struct imx_media_pixfmt *outcc;
   648  struct v4l2_rect crop;
   649  
   650  infmt = >format_mbus[CSI_SINK_PAD];
   651  outfmt = >format_mbus[priv->active_output_pad];
 > 652  outcc = priv->cc[priv->active_output_pad];
   653  
   654  /* compose mbus_config from the upstream endpoint */
   655  mbus_cfg.type = priv->upstream_ep.bus_type;
   656  mbus_cfg.flags = (priv->upstream_ep.bus_type == V4L2_MBUS_CSI2) 
?
   657  priv->upstream_ep.bus.mipi_csi2.flags :
   658  priv->upstream_ep.bus.parallel.flags;
   659  
   660  /*
   661   * we need to pass input frame to CSI interface, but
   662   * with translated field type from output format
   663   */
   664  if_fmt = *infmt;
   665  if_fmt.field = outfmt->field;
   666  crop = priv->crop;
   667  
   668  /*
   669   * if cycles is set, we need to handle this over multiple 
cycles as
   670   * generic/bayer data
   671   */
   672  if ((priv->upstream_ep.bus_type != V4L2_MBUS_CSI2) && 
outcc->cycles) {
   673  if_fmt.width *= outcc->cycles;
   674  crop.width *= outcc->cycles;
   675  }
   676  
   677  ipu_csi_set_window(priv->csi, );
   678  
   679  ipu_csi_set_downsize(priv->csi,
   680   priv->crop.width == 2 * 
priv->compose.width,
   681   priv->crop.height == 2 * 
priv->compose.height);
   682  
   683  ipu_csi_init_interface(priv->csi, _cfg, _fmt);
   684  
   685  ipu_csi_set_dest(priv->csi, priv->dest);
   686  
   687  if (priv->dest == IPU_CSI_DEST_IDMAC)
   688  ipu_csi_set_skip_smfc(priv->csi, priv->skip->skip_smfc,
   689priv->skip->max_ratio - 1, 0);
   690  
   691  ipu_csi_dump(priv->csi);
   692  
   693  return 0;
   694  }
   695  

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

Re: [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

[Paul Kocialkowski]

Hi,

On Fri, 2018-04-20 at 09:51 +, Tomasz Figa wrote:
> Hi Paul,
> 
> On Fri, Apr 20, 2018 at 12:46 AM Paul Kocialkowski <
> paul.kocialkow...@bootlin.com> wrote:
> [snip]
> > +struct v4l2_ctrl_mpeg2_frame_hdr {
> > +   __u32 slice_len;
> > +   __u32 slice_pos;
> > +   enum { MPEG1, MPEG2 } type;
> 
> Is enum suitable for UAPI?

As it turns out, it's not :)

> > +
> > +   __u16 width;
> > +   __u16 height;
> > +
> > +   enum { PCT_I = 1, PCT_P, PCT_B, PCT_D } picture_coding_type;
> 
> Ditto.
> 
> > +   __u8 f_code[2][2];
> > +
> > +   __u8 intra_dc_precision;
> > +   __u8 picture_structure;
> > +   __u8 top_field_first;
> > +   __u8 frame_pred_frame_dct;
> > +   __u8 concealment_motion_vectors;
> > +   __u8 q_scale_type;
> > +   __u8 intra_vlc_format;
> > +   __u8 alternate_scan;
> > +
> > +   __u8 backward_ref_index;
> > +   __u8 forward_ref_index;
> > +};
> > +
> >   #endif
> > diff --git a/include/uapi/linux/videodev2.h
> 
> b/include/uapi/linux/videodev2.h
> > index 31b5728b56e9..4b8336f7bcf0 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -635,6 +635,7 @@ struct v4l2_pix_format {
> >   #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L')
> > /*
> 
> SMPTE 421M Annex L compliant stream */
> >   #define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /*
> > VP8 */
> >   #define V4L2_PIX_FMT_VP9  v4l2_fourcc('V', 'P', '9', '0') /*
> > VP9 */
> > +#define V4L2_PIX_FMT_MPEG2_FRAME v4l2_fourcc('M', 'G', '2', 'F') /*
> 
> MPEG2 frame */
> 
> >   /*  Vendor-specific formats   */
> >   #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /*
> > cpia1
> 
> YUV */
> > @@ -1586,6 +1587,7 @@ struct v4l2_ext_control {
> >  __u8 __user *p_u8;
> >  __u16 __user *p_u16;
> >  __u32 __user *p_u32;
> > +   struct v4l2_ctrl_mpeg2_frame_hdr __user
> 
> *p_mpeg2_frame_hdr;
> >  void __user *ptr;
> >  };
> >   } __attribute__ ((packed));
> > @@ -1631,6 +1633,7 @@ enum v4l2_ctrl_type {
> >  V4L2_CTRL_TYPE_U8= 0x0100,
> >  V4L2_CTRL_TYPE_U16   = 0x0101,
> >  V4L2_CTRL_TYPE_U32   = 0x0102,
> > +   V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,
> 
> Why 0x0109?

Good catch. I see no reason in particular, so I'll probably make it
0x0103 eventually.

Cheers and thanks for the review!

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

[Paul Kocialkowski]

Hi,

On Fri, 2018-04-20 at 15:57 +0200, Hans Verkuil wrote:
> On 04/19/18 17:45, Paul Kocialkowski wrote:
> > Stateless video decoding engines require both the MPEG slices and
> > associated metadata from the video stream in order to decode frames.
> > 
> > This introduces definitions for a new pixel format, describing
> > buffers
> > with MPEG2 slice data, as well as a control structure for passing
> > the
> > frame header (metadata) to drivers.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > Signed-off-by: Florent Revest 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
> >  drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
> >  include/uapi/linux/v4l2-controls.h   | 26
> > ++
> >  include/uapi/linux/videodev2.h   |  3 +++
> >  4 files changed, 40 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index ba05a8b9a095..fcdc12b9a9e0 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -761,6 +761,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: 
> > return "Vertical MV Search Range";
> > case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: 
> > return "Repeat Sequence Header";
> > case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:   re
> > turn "Force Key Frame";
> > +   case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:   re
> > turn "MPEG2 Frame Header";
> >  
> > /* VPX controls */
> > case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:
> > return "VPX Number of Partitions";
> > @@ -1152,6 +1153,9 @@ void v4l2_ctrl_fill(u32 id, const char **name,
> > enum v4l2_ctrl_type *type,
> > case V4L2_CID_RDS_TX_ALT_FREQS:
> > *type = V4L2_CTRL_TYPE_U32;
> > break;
> > +   case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> > +   *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> > +   break;
> > default:
> > *type = V4L2_CTRL_TYPE_INTEGER;
> > break;
> > @@ -1472,6 +1476,9 @@ static int std_validate(const struct v4l2_ctrl
> > *ctrl, u32 idx,
> > return -ERANGE;
> > return 0;
> >  
> > +   case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > +   return 0;
> > +
> > default:
> > return -EINVAL;
> > }
> > @@ -2046,6 +2053,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> > v4l2_ctrl_handler *hdl,
> > case V4L2_CTRL_TYPE_U32:
> > elem_size = sizeof(u32);
> > break;
> > +   case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > +   elem_size = sizeof(struct
> > v4l2_ctrl_mpeg2_frame_hdr);
> > +   break;
> > default:
> > if (type < V4L2_CTRL_COMPOUND_TYPES)
> > elem_size = sizeof(s32);
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 468c3c65362d..8070203da5d2 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1273,6 +1273,7 @@ static void v4l_fill_fmtdesc(struct
> > v4l2_fmtdesc *fmt)
> > case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1 
> > (SMPTE 412M Annex L)"; break;
> > case V4L2_PIX_FMT_VP8:  descr =
> > "VP8"; break;
> > case V4L2_PIX_FMT_VP9:  descr =
> > "VP9"; break;
> > +   case V4L2_PIX_FMT_MPEG2_FRAME:  descr =
> > "MPEG2 Frame"; break;
> > case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA
> > YUV"; break;
> > case V4L2_PIX_FMT_WNVA: descr =
> > "WNVA"; break;
> > case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA
> > SN9C10X"; break;
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index cbbb750d87d1..8431b2a540c7 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
> >  };
> >  #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPE
> > G_BASE+407)
> >  
> > +#define
> > V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> > +
> >  /*  Control IDs for VP8 streams
> >   *  Although VP8 is not part of MPEG we add these controls to the
> > MPEG class
> >   *  as that class is already handling other video compression
> > standards
> > @@ -985,4 +987,28 @@ enum v4l2_detect_md_mode {
> >  #define V4L2_CID_DETECT_MD_THRESHOLD_GRID  (V4L2_CID_DETECT_C
> > LASS_BASE + 3)
> >  #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DET
> > ECT_CLASS_BASE + 4)
> >  
> > +struct v4l2_ctrl_mpeg2_frame_hdr {
> > +   __u32 slice_len;
> > +   __u32 slice_pos;
> > +   enum { MPEG1, MPEG2 } type;
> > +
> > +   __u16 width;
> > +   __u16 height;
> > +
> > +   enum { PCT_I = 1, PCT_P, PCT_B, PCT_D }
> > picture_coding_type;
> 
> As someone else already 

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

[Daniel Vetter]

On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote:
> On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2018-05-03 15:25:52)
> > > Almost everyone uses dma_fence_default_wait.
> > > 
> > > v2: Also remove the BUG_ON(!ops->wait) (Chris).
> > 
> > I just don't get the rationale for implicit over explicit.
> 
> Closer approximation of dwim semantics. There's been tons of patch series
> all over drm and related places to get there, once we have a big pile of
> implementations and know what the dwim semantics should be. Individually
> they're all not much, in aggregate they substantially simplify simple
> drivers.

I also think clearer separation between optional optimization hooks and
mandatory core parts is useful in itself.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

[Paul Kocialkowski]

Hi,

On Tue, 2018-04-24 at 12:01 +0300, Sakari Ailus wrote:
> Hi Paul,
> 
> On Thu, Apr 19, 2018 at 05:45:31PM +0200, Paul Kocialkowski wrote:
> > Stateless video decoding engines require both the MPEG slices and
> > associated metadata from the video stream in order to decode frames.
> > 
> > This introduces definitions for a new pixel format, describing
> > buffers
> > with MPEG2 slice data, as well as a control structure for passing
> > the
> > frame header (metadata) to drivers.
> 
> What's the typical relationship between MPEG2 slice data and the
> header?
> 
> Are the two always used together, do they originate from the same
> source, for instance? I have to admit I'm not very familiar with
> MPEG...

Yes, the header is closely related to the slice data, as it expresses
the metadata required for properly decoding the slice data. Both are
extracted from the MPEG bitstream and there is dedicated metadata for
each new set of slices that is decoded to a single frame.

> > Signed-off-by: Paul Kocialkowski 
> > Signed-off-by: Florent Revest 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
> >  drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
> >  include/uapi/linux/v4l2-controls.h   | 26
> > ++
> >  include/uapi/linux/videodev2.h   |  3 +++
> >  4 files changed, 40 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index ba05a8b9a095..fcdc12b9a9e0 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -761,6 +761,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: 
> > return "Vertical MV Search Range";
> > case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: 
> > return "Repeat Sequence Header";
> > case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:   re
> > turn "Force Key Frame";
> > +   case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:   re
> > turn "MPEG2 Frame Header";
> >  
> > /* VPX controls */
> > case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:
> > return "VPX Number of Partitions";
> > @@ -1152,6 +1153,9 @@ void v4l2_ctrl_fill(u32 id, const char **name,
> > enum v4l2_ctrl_type *type,
> > case V4L2_CID_RDS_TX_ALT_FREQS:
> > *type = V4L2_CTRL_TYPE_U32;
> > break;
> > +   case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> > +   *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> > +   break;
> > default:
> > *type = V4L2_CTRL_TYPE_INTEGER;
> > break;
> > @@ -1472,6 +1476,9 @@ static int std_validate(const struct v4l2_ctrl
> > *ctrl, u32 idx,
> > return -ERANGE;
> > return 0;
> >  
> > +   case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > +   return 0;
> > +
> > default:
> > return -EINVAL;
> > }
> > @@ -2046,6 +2053,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> > v4l2_ctrl_handler *hdl,
> > case V4L2_CTRL_TYPE_U32:
> > elem_size = sizeof(u32);
> > break;
> > +   case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > +   elem_size = sizeof(struct
> > v4l2_ctrl_mpeg2_frame_hdr);
> > +   break;
> > default:
> > if (type < V4L2_CTRL_COMPOUND_TYPES)
> > elem_size = sizeof(s32);
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 468c3c65362d..8070203da5d2 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1273,6 +1273,7 @@ static void v4l_fill_fmtdesc(struct
> > v4l2_fmtdesc *fmt)
> > case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1 
> > (SMPTE 412M Annex L)"; break;
> > case V4L2_PIX_FMT_VP8:  descr =
> > "VP8"; break;
> > case V4L2_PIX_FMT_VP9:  descr =
> > "VP9"; break;
> > +   case V4L2_PIX_FMT_MPEG2_FRAME:  descr =
> > "MPEG2 Frame"; break;
> > case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA
> > YUV"; break;
> > case V4L2_PIX_FMT_WNVA: descr =
> > "WNVA"; break;
> > case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA
> > SN9C10X"; break;
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index cbbb750d87d1..8431b2a540c7 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
> >  };
> >  #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPE
> > G_BASE+407)
> >  
> > +#define
> > V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> > +
> >  /*  Control IDs for VP8 streams
> >   *  Although VP8 is not part of MPEG we add these controls to the
> > MPEG class
> >   *  as that class is already handling other video compression
> > 

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

[Daniel Vetter]

On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-05-03 15:25:52)
> > Almost everyone uses dma_fence_default_wait.
> > 
> > v2: Also remove the BUG_ON(!ops->wait) (Chris).
> 
> I just don't get the rationale for implicit over explicit.

Closer approximation of dwim semantics. There's been tons of patch series
all over drm and related places to get there, once we have a big pile of
implementations and know what the dwim semantics should be. Individually
they're all not much, in aggregate they substantially simplify simple
drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

[Maxime Ripard]

On Fri, May 04, 2018 at 09:56:20AM +0200, Paul Kocialkowski wrote:
> > > I agree that the term VPU is more commonly associated with video
> > > decoding, while video engine could mean a number of things.
> > > 
> > > The reason I went with "video-engine" here (while still presenting
> > > the
> > > driver as a VPU driver) is that Video Engine is the term used in
> > > Allwinner's litterature. Other nodes in Allwinner device-trees
> > > generally
> > > stick to these terms (for instance, we have "display-engine" nodes).
> > > This also makes it easier to find the matching parts in the
> > > documentation.
> > 
> > 'video-codec' is what is defined in the DT spec.
> 
> Is that an actively-enforced guideline or a suggestion? I'd like to keep
> video-engine just to stick with the technical documentation wording and
> my personal taste is also to prefer vpu over video-codec (in terms of
> clarity/straightforwardness) as a second choice.
> 
> Still, if the choice isn't up to me, we can go with video-codec (or
> vpu).

The unit-name is supposed to reflect the class of the device, and
nothing else. If there's already a pre-existing class name defined for
these kind of devices, then there's no point in choosing something
else.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

[Chris Wilson]

Quoting Daniel Vetter (2018-05-03 15:25:52)
> Almost everyone uses dma_fence_default_wait.
> 
> v2: Also remove the BUG_ON(!ops->wait) (Chris).

I just don't get the rationale for implicit over explicit.
-Chris