Re: [PATCH 00/47] arch-removal: device drivers

[Boris Brezillon]

Hi Arnd,

On Wed, 14 Mar 2018 16:35:13 +0100
Arnd Bergmann  wrote:

> Hi driver maintainers,
> 
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
> 
> These are the device drivers that go along with them. I have already
> picked up the drivers for arch/metag/ into my tree, they were reviewed
> earlier.
> 
> Please let me know if you have any concerns with the patch, or if you
> prefer to pick up the patches in your respective trees.  I created
> the patches with 'git format-patch -D', so they will not apply without
> manually removing those files.
> 
> For anything else, I'd keep the removal patches in my asm-generic tree
> and will send a pull request for 4.17 along with the actual arch removal.
> 
>Arnd
> 
> Arnd Bergmann
>   edac: remove tile driver
>   net: tile: remove ethernet drivers
>   net: adi: remove blackfin ethernet drivers
>   net: 8390: remove m32r specific bits
>   net: remove cris etrax ethernet driver
>   net: smsc: remove m32r specific smc91x configuration
>   raid: remove tile specific raid6 implementation
>   rtc: remove tile driver
>   rtc: remove bfin driver
>   char: remove obsolete ds1302 rtc driver
>   char: remove tile-srom.c
>   char: remove blackfin OTP driver
>   pcmcia: remove m32r drivers
>   pcmcia: remove blackfin driver
>   ASoC: remove blackfin drivers
>   video/logo: remove obsolete logo files
>   fbdev: remove blackfin drivers
>   fbdev: s1d13xxxfb: remove m32r specific hacks
>   crypto: remove blackfin CRC driver
>   media: platform: remove blackfin capture driver
>   media: platform: remove m32r specific arv driver
>   cpufreq: remove blackfin driver
>   cpufreq: remove cris specific drivers
>   gpio: remove etraxfs driver
>   pinctrl: remove adi2/blackfin drivers
>   ata: remove bf54x driver
>   input: keyboard: remove bf54x driver
>   input: misc: remove blackfin rotary driver
>   mmc: remove bfin_sdh driver
>   can: remove bfin_can driver
>   watchdog: remove bfin_wdt driver
>   mtd: maps: remove bfin-async-flash driver
>   mtd: nand: remove bf5xx_nand driver

If you don't mind, I'd like to take the mtd patches through the MTD
tree. As you've probably noticed, nand code has been moved around and
it's easier for me to carry those 2 simple changes in my tree than
creating an immutable branch.

Let me know if this is a problem.

Regards,

Boris

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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Thu Mar 15 05:00:18 CET 2018
media-tree git hash:e68854a2588a923b31eebce348f8020374843f8e
media_build git hash:   2a1900fddab68c7686e6b146ff91e02b32675fae
v4l-utils git hash: 14ce03c18ef67aa7a3d5781f015be855fd43839c
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.0-3994-g45eb2282
smatch version: v0.5.0-3994-g45eb2282
host hardware:  x86_64
host os:4.14.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.98-i686: ERRORS
linux-3.2.98-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-i686: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.53-i686: WARNINGS
linux-3.16.53-x86_64: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.93-i686: WARNINGS
linux-3.18.93-x86_64: WARNINGS
linux-3.19-i686: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.49-i686: WARNINGS
linux-4.1.49-x86_64: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.115-i686: OK
linux-4.4.115-x86_64: OK
linux-4.5.7-i686: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-i686: OK
linux-4.7.5-x86_64: WARNINGS
linux-4.8-i686: OK
linux-4.8-x86_64: WARNINGS
linux-4.9.80-i686: OK
linux-4.9.80-x86_64: OK
linux-4.10.14-i686: OK
linux-4.10.14-x86_64: WARNINGS
linux-4.11-i686: OK
linux-4.11-x86_64: WARNINGS
linux-4.12.1-i686: OK
linux-4.12.1-x86_64: WARNINGS
linux-4.13-i686: OK
linux-4.13-x86_64: OK
linux-4.14.17-i686: OK
linux-4.14.17-x86_64: OK
linux-4.15.2-i686: WARNINGS
linux-4.15.2-x86_64: WARNINGS
linux-4.16-rc1-i686: WARNINGS
linux-4.16-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition

[kbuild test robot]

Hi Wolfgang,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0aa3fdb8b3a6df3c2e3b61dbfe079db9d30e03cd
commit: 6cdeaed3b1420bd2569891be0c4123ff59628e9e media: dvb_usb_pctv452e: 
module refcount changes were unbalanced
date:   3 months ago
config: x86_64-randconfig-a0-03151117 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 6cdeaed3b1420bd2569891be0c4123ff59628e9e
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:0:
   drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach':
>> drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 
>> 'stb0899_attach' being applied to a already existing, static definition
static inline struct dvb_frontend *stb0899_attach(struct stb0899_config 
*config,
   ^~

vim +/stb0899_attach +151 drivers/media/dvb-frontends/stb0899_drv.h

ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  150 
 
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08 @151 
 static inline struct dvb_frontend *stb0899_attach(struct stb0899_config 
*config,
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  152 
  struct i2c_adapter *i2c)
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  153 
 {
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  154 
printk(KERN_WARNING "%s: Driver disabled by Kconfig\n", __func__);
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  155 
return NULL;
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  156 
 }
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  157 
 

:: The code at line 151 was first introduced by commit
:: ae9902da96b4d2d82707706c7fbc93a8e501dde8 V4L/DVB (9417): DVB_ATTACH for 
STB0899, STB6100, TDA8261

:: TO: Manu Abraham 
:: CC: Mauro Carvalho Chehab 

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


.config.gz
Description: application/gzip

RE: [PATCH v8] media: imx258: Add imx258 camera sensor driver

[Yeh, Andy]

Sure will do. Thanks Sakari.

-Original Message-
From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com] 
Sent: Thursday, March 15, 2018 6:31 AM
To: Yeh, Andy 
Cc: linux-media@vger.kernel.org; tf...@chromium.org; Chen, JasonX Z 
; Chiang, AlanX ; Lai, Jim 

Subject: Re: [PATCH v8] media: imx258: Add imx258 camera sensor driver

Hi Andy,

Thanks for the update. Two minor comments below.

On Thu, Mar 15, 2018 at 12:24:19AM +0800, Andy Yeh wrote:
...
> +static int imx258_set_ctrl(struct v4l2_ctrl *ctrl) {
> + struct imx258 *imx258 =
> + container_of(ctrl->handler, struct imx258, ctrl_handler);
> + struct i2c_client *client = v4l2_get_subdevdata(>sd);
> + int ret = 0;
> +
> + /*
> +  * Applying V4L2 control value only happens
> +  * when power is up for streaming
> +  */
> + if (pm_runtime_get_if_in_use(>dev) == 0)
> + return 0;
> +
> + switch (ctrl->id) {
> + case V4L2_CID_ANALOGUE_GAIN:
> + ret = imx258_write_reg(imx258, IMX258_REG_ANALOG_GAIN,
> + IMX258_REG_VALUE_16BIT,
> + ctrl->val);
> + break;
> + case V4L2_CID_EXPOSURE:
> + ret = imx258_write_reg(imx258, IMX258_REG_EXPOSURE,
> + IMX258_REG_VALUE_16BIT,
> + ctrl->val);
> + break;
> + case V4L2_CID_DIGITAL_GAIN:
> + ret = imx258_update_digital_gain(imx258, IMX258_REG_VALUE_16BIT,
> + ctrl->val);
> + break;
> + case V4L2_CID_VBLANK:
> + /*
> +  * Auto Frame Length Line Control is enabled by default.
> +  * Not need control Vblank Register.
> +  */
> + break;
> + default:
> + dev_info(>dev,
> +  "ctrl(id:0x%x,val:0x%x) is not handled\n",
> +  ctrl->id, ctrl->val);

As this is an error, I'd set ret to e.g. -EINVAL here.

> + break;
> + }
> +
> + pm_runtime_put(>dev);
> +
> + return ret;
> +}

...

> +/* Initialize control handlers */
> +static int imx258_init_controls(struct imx258 *imx258) {
> + struct i2c_client *client = v4l2_get_subdevdata(>sd);
> + struct v4l2_ctrl_handler *ctrl_hdlr;
> + s64 exposure_max;
> + s64 vblank_def;
> + s64 vblank_min;
> + s64 pixel_rate_min;
> + s64 pixel_rate_max;
> + int ret;
> +
> + ctrl_hdlr = >ctrl_handler;
> + ret = v4l2_ctrl_handler_init(ctrl_hdlr, 8);
> + if (ret)
> + return ret;
> +
> + mutex_init(>mutex);
> + ctrl_hdlr->lock = >mutex;
> + imx258->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
> + _ctrl_ops,
> + V4L2_CID_LINK_FREQ,
> + ARRAY_SIZE(link_freq_menu_items) - 1,
> + 0,
> + link_freq_menu_items);
> +
> + if (imx258->link_freq)
> + imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]);
> + pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]);
> + /* By default, PIXEL_RATE is read only */
> + imx258->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops,
> + V4L2_CID_PIXEL_RATE,
> + pixel_rate_min, pixel_rate_max,
> + 1, pixel_rate_max);
> +
> +
> + vblank_def = imx258->cur_mode->vts_def - imx258->cur_mode->height;
> + vblank_min = imx258->cur_mode->vts_min - imx258->cur_mode->height;
> + imx258->vblank = v4l2_ctrl_new_std(
> + ctrl_hdlr, _ctrl_ops, V4L2_CID_VBLANK,
> + vblank_min,
> + IMX258_VTS_MAX - imx258->cur_mode->height, 1,
> + vblank_def);
> +
> + imx258->hblank = v4l2_ctrl_new_std(
> + ctrl_hdlr, _ctrl_ops, V4L2_CID_HBLANK,
> + IMX258_PPL_DEFAULT - imx258->cur_mode->width,
> + IMX258_PPL_DEFAULT - imx258->cur_mode->width,
> + 1,
> + IMX258_PPL_DEFAULT - imx258->cur_mode->width);
> +
> + if (!imx258->hblank) {

Could you align handling for NULL hblank control with NULL link_freq above?

> + ret = -EINVAL;
> + goto error;
> + }
> +
> + imx258->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + exposure_max = imx258->cur_mode->vts_def - 8;
> + imx258->exposure = v4l2_ctrl_new_std(
> + ctrl_hdlr, _ctrl_ops,
> + V4L2_CID_EXPOSURE, IMX258_EXPOSURE_MIN,
> + IMX258_EXPOSURE_MAX, 

Re: [PATCH v8] media: imx258: Add imx258 camera sensor driver

[Sakari Ailus]

Hi Andy,

Thanks for the update. Two minor comments below.

On Thu, Mar 15, 2018 at 12:24:19AM +0800, Andy Yeh wrote:
...
> +static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct imx258 *imx258 =
> + container_of(ctrl->handler, struct imx258, ctrl_handler);
> + struct i2c_client *client = v4l2_get_subdevdata(>sd);
> + int ret = 0;
> +
> + /*
> +  * Applying V4L2 control value only happens
> +  * when power is up for streaming
> +  */
> + if (pm_runtime_get_if_in_use(>dev) == 0)
> + return 0;
> +
> + switch (ctrl->id) {
> + case V4L2_CID_ANALOGUE_GAIN:
> + ret = imx258_write_reg(imx258, IMX258_REG_ANALOG_GAIN,
> + IMX258_REG_VALUE_16BIT,
> + ctrl->val);
> + break;
> + case V4L2_CID_EXPOSURE:
> + ret = imx258_write_reg(imx258, IMX258_REG_EXPOSURE,
> + IMX258_REG_VALUE_16BIT,
> + ctrl->val);
> + break;
> + case V4L2_CID_DIGITAL_GAIN:
> + ret = imx258_update_digital_gain(imx258, IMX258_REG_VALUE_16BIT,
> + ctrl->val);
> + break;
> + case V4L2_CID_VBLANK:
> + /*
> +  * Auto Frame Length Line Control is enabled by default.
> +  * Not need control Vblank Register.
> +  */
> + break;
> + default:
> + dev_info(>dev,
> +  "ctrl(id:0x%x,val:0x%x) is not handled\n",
> +  ctrl->id, ctrl->val);

As this is an error, I'd set ret to e.g. -EINVAL here.

> + break;
> + }
> +
> + pm_runtime_put(>dev);
> +
> + return ret;
> +}

...

> +/* Initialize control handlers */
> +static int imx258_init_controls(struct imx258 *imx258)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(>sd);
> + struct v4l2_ctrl_handler *ctrl_hdlr;
> + s64 exposure_max;
> + s64 vblank_def;
> + s64 vblank_min;
> + s64 pixel_rate_min;
> + s64 pixel_rate_max;
> + int ret;
> +
> + ctrl_hdlr = >ctrl_handler;
> + ret = v4l2_ctrl_handler_init(ctrl_hdlr, 8);
> + if (ret)
> + return ret;
> +
> + mutex_init(>mutex);
> + ctrl_hdlr->lock = >mutex;
> + imx258->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
> + _ctrl_ops,
> + V4L2_CID_LINK_FREQ,
> + ARRAY_SIZE(link_freq_menu_items) - 1,
> + 0,
> + link_freq_menu_items);
> +
> + if (imx258->link_freq)
> + imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]);
> + pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]);
> + /* By default, PIXEL_RATE is read only */
> + imx258->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops,
> + V4L2_CID_PIXEL_RATE,
> + pixel_rate_min, pixel_rate_max,
> + 1, pixel_rate_max);
> +
> +
> + vblank_def = imx258->cur_mode->vts_def - imx258->cur_mode->height;
> + vblank_min = imx258->cur_mode->vts_min - imx258->cur_mode->height;
> + imx258->vblank = v4l2_ctrl_new_std(
> + ctrl_hdlr, _ctrl_ops, V4L2_CID_VBLANK,
> + vblank_min,
> + IMX258_VTS_MAX - imx258->cur_mode->height, 1,
> + vblank_def);
> +
> + imx258->hblank = v4l2_ctrl_new_std(
> + ctrl_hdlr, _ctrl_ops, V4L2_CID_HBLANK,
> + IMX258_PPL_DEFAULT - imx258->cur_mode->width,
> + IMX258_PPL_DEFAULT - imx258->cur_mode->width,
> + 1,
> + IMX258_PPL_DEFAULT - imx258->cur_mode->width);
> +
> + if (!imx258->hblank) {

Could you align handling for NULL hblank control with NULL link_freq above?

> + ret = -EINVAL;
> + goto error;
> + }
> +
> + imx258->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + exposure_max = imx258->cur_mode->vts_def - 8;
> + imx258->exposure = v4l2_ctrl_new_std(
> + ctrl_hdlr, _ctrl_ops,
> + V4L2_CID_EXPOSURE, IMX258_EXPOSURE_MIN,
> + IMX258_EXPOSURE_MAX, IMX258_EXPOSURE_STEP,
> + IMX258_EXPOSURE_DEFAULT);
> +
> + v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops, V4L2_CID_ANALOGUE_GAIN,
> + IMX258_ANA_GAIN_MIN, IMX258_ANA_GAIN_MAX,
> + IMX258_ANA_GAIN_STEP, IMX258_ANA_GAIN_DEFAULT);
> +
> + v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops, V4L2_CID_DIGITAL_GAIN,
> + 

Re: [PATCH] [media] ov5645: Move an error code assignment in ov5645_probe()

[Sakari Ailus]

On Wed, Mar 14, 2018 at 10:15:43PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Wed, 14 Mar 2018 22:02:52 +0100
> 
> Move an assignment for a specific error code so that it is stored only once
> in this function implementation.
> 
> This issue was detected by using the Coccinelle software.

How?

> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/media/i2c/ov5645.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
> index d28845f7356f..374576380fd4 100644
> --- a/drivers/media/i2c/ov5645.c
> +++ b/drivers/media/i2c/ov5645.c
> @@ -1284,13 +1284,11 @@ static int ov5645_probe(struct i2c_client *client,
>   ret = ov5645_read_reg(ov5645, OV5645_CHIP_ID_HIGH, _id_high);
>   if (ret < 0 || chip_id_high != OV5645_CHIP_ID_HIGH_BYTE) {
>   dev_err(dev, "could not read ID high\n");
> - ret = -ENODEV;
>   goto power_down;
>   }
>   ret = ov5645_read_reg(ov5645, OV5645_CHIP_ID_LOW, _id_low);
>   if (ret < 0 || chip_id_low != OV5645_CHIP_ID_LOW_BYTE) {
>   dev_err(dev, "could not read ID low\n");
> - ret = -ENODEV;
>   goto power_down;
>   }
>  
> @@ -1300,7 +1298,6 @@ static int ov5645_probe(struct i2c_client *client,
> >aec_pk_manual);
>   if (ret < 0) {
>   dev_err(dev, "could not read AEC/AGC mode\n");
> - ret = -ENODEV;
>   goto power_down;
>   }
>  
> @@ -1308,7 +1305,6 @@ static int ov5645_probe(struct i2c_client *client,
> >timing_tc_reg20);
>   if (ret < 0) {
>   dev_err(dev, "could not read vflip value\n");
> - ret = -ENODEV;
>   goto power_down;
>   }
>  
> @@ -1316,7 +1312,6 @@ static int ov5645_probe(struct i2c_client *client,
> >timing_tc_reg21);
>   if (ret < 0) {
>   dev_err(dev, "could not read hflip value\n");
> - ret = -ENODEV;
>   goto power_down;
>   }
>  
> @@ -1334,6 +1329,7 @@ static int ov5645_probe(struct i2c_client *client,
>  
>  power_down:
>   ov5645_s_power(>sd, false);
> + ret = -ENODEV;

I don't think this is where people would expect you to set the error code
in general. It should rather take place before goto, not after it. That'd
mean another variable, and I'm not convinced the result would improve the
driver.

>  free_entity:
>   media_entity_cleanup(>sd.entity);
>  free_ctrl:

-- 
Regards,

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

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

[kbuild test robot]

Hi Rui,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[cannot apply to next-20180314]
[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/Rui-Miguel-Silva/media-Introduce-Omnivision-OV2680-driver/20180315-020617
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/i2c/ov2680.c: In function 'ov2680_set_fmt':
   drivers/media/i2c/ov2680.c:713:9: error: implicit declaration of function 
'v4l2_find_nearest_size'; did you mean 'v4l2_find_nearest_format'? 
[-Werror=implicit-function-declaration]
 mode = v4l2_find_nearest_size(ov2680_mode_data,
^~
v4l2_find_nearest_format
   drivers/media/i2c/ov2680.c:714:195: error: 'width' undeclared (first use in 
this function)
  ARRAY_SIZE(ov2680_mode_data), width,


  ^
   drivers/media/i2c/ov2680.c:714:195: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/media/i2c/ov2680.c:715:11: error: 'height' undeclared (first use in 
>> this function); did you mean '__iget'?
  height, fmt->width, fmt->height);
  ^~
  __iget
   cc1: some warnings being treated as errors

vim +715 drivers/media/i2c/ov2680.c

   693  
   694  static int ov2680_set_fmt(struct v4l2_subdev *sd,
   695struct v4l2_subdev_pad_config *cfg,
   696struct v4l2_subdev_format *format)
   697  {
   698  struct ov2680_dev *sensor = to_ov2680_dev(sd);
   699  struct v4l2_mbus_framefmt *fmt = >format;
   700  const struct ov2680_mode_info *mode;
   701  int ret = 0;
   702  
   703  if (format->pad != 0)
   704  return -EINVAL;
   705  
   706  mutex_lock(>lock);
   707  
   708  if (sensor->is_streaming) {
   709  ret = -EBUSY;
   710  goto unlock;
   711  }
   712  
 > 713  mode = v4l2_find_nearest_size(ov2680_mode_data,
   714ARRAY_SIZE(ov2680_mode_data), 
width,
 > 715height, fmt->width, fmt->height);
   716  if (!mode) {
   717  ret = -EINVAL;
   718  goto unlock;
   719  }
   720  
   721  if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
   722  fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
   723  
   724  *fmt = format->format;
   725  goto unlock;
   726  }
   727  
   728  fmt->width = mode->width;
   729  fmt->height = mode->height;
   730  fmt->code = sensor->fmt.code;
   731  fmt->colorspace = sensor->fmt.colorspace;
   732  
   733  sensor->current_mode = mode;
   734  sensor->fmt = format->format;
   735  sensor->mode_pending_changes = true;
   736  
   737  unlock:
   738  mutex_unlock(>lock);
   739  
   740  return ret;
   741  }
   742  

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


.config.gz
Description: application/gzip

[PATCH] [media] ov5645: Move an error code assignment in ov5645_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 14 Mar 2018 22:02:52 +0100

Move an assignment for a specific error code so that it is stored only once
in this function implementation.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/i2c/ov5645.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
index d28845f7356f..374576380fd4 100644
--- a/drivers/media/i2c/ov5645.c
+++ b/drivers/media/i2c/ov5645.c
@@ -1284,13 +1284,11 @@ static int ov5645_probe(struct i2c_client *client,
ret = ov5645_read_reg(ov5645, OV5645_CHIP_ID_HIGH, _id_high);
if (ret < 0 || chip_id_high != OV5645_CHIP_ID_HIGH_BYTE) {
dev_err(dev, "could not read ID high\n");
-   ret = -ENODEV;
goto power_down;
}
ret = ov5645_read_reg(ov5645, OV5645_CHIP_ID_LOW, _id_low);
if (ret < 0 || chip_id_low != OV5645_CHIP_ID_LOW_BYTE) {
dev_err(dev, "could not read ID low\n");
-   ret = -ENODEV;
goto power_down;
}
 
@@ -1300,7 +1298,6 @@ static int ov5645_probe(struct i2c_client *client,
  >aec_pk_manual);
if (ret < 0) {
dev_err(dev, "could not read AEC/AGC mode\n");
-   ret = -ENODEV;
goto power_down;
}
 
@@ -1308,7 +1305,6 @@ static int ov5645_probe(struct i2c_client *client,
  >timing_tc_reg20);
if (ret < 0) {
dev_err(dev, "could not read vflip value\n");
-   ret = -ENODEV;
goto power_down;
}
 
@@ -1316,7 +1312,6 @@ static int ov5645_probe(struct i2c_client *client,
  >timing_tc_reg21);
if (ret < 0) {
dev_err(dev, "could not read hflip value\n");
-   ret = -ENODEV;
goto power_down;
}
 
@@ -1334,6 +1329,7 @@ static int ov5645_probe(struct i2c_client *client,
 
 power_down:
ov5645_s_power(>sd, false);
+   ret = -ENODEV;
 free_entity:
media_entity_cleanup(>sd.entity);
 free_ctrl:
-- 
2.16.2

uvc-gadget created with configfs sets all bFrameIndex to 1

[Joel Pepper]

I am currently working on an application for my master thesis that does
transparent inline modification of  frames received from a uvc webcam
which are served to the actual host through a uvc gadget mimicking the
underlying webcam. I recently noticed that the host side v4l2 driver
would only ever request bFrameIndex 1, no matter the requested format.


So I used usbmon to take a closer look (pcap is attached ). Take a look
at the Video Streaming interface descriptor in packet no. 6: All 19
different framesizes have their bFrameIndex set to 1. This makes
requesting any framesize but the actual first one impossible.


I took a quick look at drivers/usb/gadget/function/uvc_configfs.c and
noticed that the bFrameIndex attribute of a frame is set to 1 per
default in "uvcg_frame_make"**, but the attribute is neither made
accessible through configfs nor could I see any mechanism by which the
indices are set automatically.


As I am new to kernel development, I wanted ask for comment first before
I start brewing up a possible patch for this bug. Currently I see three
solutions:

1) Expose bFrameIndex through ConfigFs, to be set by the user

2) Assign an unused bFrameIndex during "uvcg_frame_make"

3) Once framesizes of a format are finalized, iterate through frames and
assign ascending indices


There is also obviously the possibility that I gravely misconfigured my
gadget through configfs, if so please point me in the right direction.


Regards,

Joel



bFrameIndex_bug.pcapng
Description: application/pcapng

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

[kbuild test robot]

Hi Rui,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[cannot apply to next-20180314]
[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/Rui-Miguel-Silva/media-Introduce-Omnivision-OV2680-driver/20180315-020617
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   drivers/media/i2c/ov2680.c: In function 'ov2680_set_fmt':
>> drivers/media/i2c/ov2680.c:713:9: error: implicit declaration of function 
>> 'v4l2_find_nearest_size'; did you mean 'v4l2_find_nearest_format'? 
>> [-Werror=implicit-function-declaration]
 mode = v4l2_find_nearest_size(ov2680_mode_data,
^~
v4l2_find_nearest_format
>> drivers/media/i2c/ov2680.c:714:41: error: 'width' undeclared (first use in 
>> this function)
  ARRAY_SIZE(ov2680_mode_data), width,
^
   drivers/media/i2c/ov2680.c:714:41: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/media/i2c/ov2680.c:715:11: error: 'height' undeclared (first use in 
>> this function); did you mean 'hweight8'?
  height, fmt->width, fmt->height);
  ^~
  hweight8
   cc1: some warnings being treated as errors

vim +713 drivers/media/i2c/ov2680.c

   693  
   694  static int ov2680_set_fmt(struct v4l2_subdev *sd,
   695struct v4l2_subdev_pad_config *cfg,
   696struct v4l2_subdev_format *format)
   697  {
   698  struct ov2680_dev *sensor = to_ov2680_dev(sd);
   699  struct v4l2_mbus_framefmt *fmt = >format;
   700  const struct ov2680_mode_info *mode;
   701  int ret = 0;
   702  
   703  if (format->pad != 0)
   704  return -EINVAL;
   705  
   706  mutex_lock(>lock);
   707  
   708  if (sensor->is_streaming) {
   709  ret = -EBUSY;
   710  goto unlock;
   711  }
   712  
 > 713  mode = v4l2_find_nearest_size(ov2680_mode_data,
 > 714ARRAY_SIZE(ov2680_mode_data), 
 > width,
 > 715height, fmt->width, fmt->height);
   716  if (!mode) {
   717  ret = -EINVAL;
   718  goto unlock;
   719  }
   720  
   721  if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
   722  fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
   723  
   724  *fmt = format->format;
   725  goto unlock;
   726  }
   727  
   728  fmt->width = mode->width;
   729  fmt->height = mode->height;
   730  fmt->code = sensor->fmt.code;
   731  fmt->colorspace = sensor->fmt.colorspace;
   732  
   733  sensor->current_mode = mode;
   734  sensor->fmt = format->format;
   735  sensor->mode_pending_changes = true;
   736  
   737  unlock:
   738  mutex_unlock(>lock);
   739  
   740  return ret;
   741  }
   742  

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


.config.gz
Description: application/gzip

[PATCH v2 1/1] media: mceusb: add IR learning support features (IR carrier frequency measurement and wide-band/short-range receiver)

[A Sun]

patch v2 revisions:
 . Carrier frequency measurement results were consistently low in patch v1.
   Improve measurement accuracy by adjusting IR carrier cycle count
   assuming 1 missed count per IR "on" pulse.
   Adjustments may need to be hardware specific, so future refinements
   may be necessary.
 . Remove unneeded argument "enable" validation in
   mceusb_set_rx_wideband() and mceusb_set_rx_carrier_report().
 . In mceusb_set_rx_carrier_report(), when enabling RX carrier report feature,
   also implicitly enable RX wide-band (short-range) receiver.
   Maintains consistency with winbond-cir, redrat3, ene-cir, IR receivers.
 . Comment revisions and style corrections.
---

Windows Media Center IR transceivers include two IR receivers;
wide-band/short-range and narrow-band/long-range. The short-range
(5cm distance) receiver is for IR learning and has IR carrier
frequency measuring ability.

Add mceusb driver support to select the short range IR receiver
and enable pass through of its IR carrier frequency measurements.

RC and LIRC already support these mceusb driver additions.

Test platform:

Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l 
GNU/Linux
mceusb 1-1.2:1.0: Registered Pinnacle Systems PCTV Remote USB with mce emulator 
interface version 1
mceusb 1-1.2:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x1 active)

Sony TV remote control

ir-ctl from v4l-utils

pi@raspberrypi:~ $ ir-ctl -V
IR raw version 1.12.3
pi@raspberrypi:~ $ ir-ctl -m -r
...
pulse 650
space 550
pulse 650
space 600
pulse 600
space 600
pulse 1200
space 600
pulse 650
space 550
pulse 650
space 600
pulse 600
space 600
pulse 550
carrier 40004
space 16777215
^C
pi@raspberrypi:~ $ exit

Signed-off-by: A Sun 
---
 drivers/media/rc/mceusb.c | 109 ++
 1 file changed, 101 insertions(+), 8 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index a9187b0b4..392d26226 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -42,7 +42,7 @@
 #include 
 #include 
 
-#define DRIVER_VERSION "1.93"
+#define DRIVER_VERSION "1.94"
 #define DRIVER_AUTHOR  "Jarod Wilson "
 #define DRIVER_DESC"Windows Media Center Ed. eHome Infrared Transceiver " \
"device driver"
@@ -427,6 +427,7 @@ struct mceusb_dev {
struct rc_dev *rc;
 
/* optional features we can enable */
+   bool carrier_report_enabled;
bool learning_enabled;
 
/* core device bits */
@@ -475,6 +476,10 @@ struct mceusb_dev {
u8 txports_cabled;  /* bitmask of transmitters with cable */
u8 rxports_active;  /* bitmask of active receive sensors */
 
+   /* receiver carrier frequency detection support */
+   u32 pulse_tunit;/* IR pulse "on" cumulative time units */
+   u32 pulse_count;/* pulse "on" count in measurement interval */
+
/*
 * support for async error handler mceusb_deferred_kevent()
 * where usb_clear_halt(), usb_reset_configuration(),
@@ -956,14 +961,62 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32 
carrier)
 }
 
 /*
+ * Select or deselect the 2nd receiver port.
+ * Second receiver is learning mode, wide-band, short-range receiver.
+ * Only one receiver (long or short range) may be active at a time.
+ */
+static int mceusb_set_rx_wideband(struct rc_dev *dev, int enable)
+{
+   struct mceusb_dev *ir = dev->priv;
+   unsigned char cmdbuf[3] = { MCE_CMD_PORT_IR,
+   MCE_CMD_SETIRRXPORTEN, 0x00 };
+
+   dev_dbg(ir->dev, "select %s-range receive sensor",
+   enable ? "short" : "long");
+   /*
+* cmdbuf[2] is receiver port number
+* port 1 is long range receiver
+* port 2 is short range receiver
+*/
+   cmdbuf[2] = enable ? 2 : 1;
+   mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
+
+   return 0;
+}
+
+/*
+ * Enable/disable receiver carrier frequency pass through reporting.
+ * Only the short-range receiver has carrier frequency measuring capability.
+ * Implicitly select this receiver when enabling carrier frequency reporting.
+ */
+static int mceusb_set_rx_carrier_report(struct rc_dev *dev, int enable)
+{
+   struct mceusb_dev *ir = dev->priv;
+
+   dev_dbg(ir->dev, "%s short-range receiver carrier reporting",
+   enable ? "enable" : "disable");
+   if (enable) {
+   if (!ir->learning_enabled)
+   mceusb_set_rx_wideband(dev, 1);
+   ir->carrier_report_enabled = true;
+   } else {
+   ir->carrier_report_enabled = false;
+   }
+
+   return 0;
+}
+
+/*
  * We don't do anything but print debug spew for many of the command bits
  * we receive from the hardware, but some of them are useful information
  * we want to store so that we can use them.
  */
 static void mceusb_handle_command(struct mceusb_dev 

[PATCH v2 0/1] media: mceusb: add IR learning support features (IR carrier frequency measurement and wide-band/short-range receiver)

[A Sun]

Hi Sean,
Thanks again for your review and notes. I'm forwarding PATCH v2 after this 
note. Please also see my notes below. ..A Sun

On 3/13/2018 6:38 AM, Sean Young wrote:
> Hi,
> 
> On Sun, Mar 11, 2018 at 05:40:28AM -0400, A Sun wrote:
>>

>>
>> Add mceusb driver support to select the short range IR receiver
>> and enable pass through of its IR carrier frequency measurements.
>>
>> RC and LIRC already support these mceusb driver additions.
> 
> That's great, this feature has been missing for a long time. 
> 
> I've tested it with my four mceusb devices, and I get carrier reports with
> all of them. Please see the notes below.
> 
>> Test platform:

>> ...
>> pulse 600
>> space 600
>> pulse 1250
>> space 550
>> pulse 650
>> space 600
>> pulse 550
>> space 600
>> pulse 600
>> space 600
>> pulse 650
>> carrier 38803
> 
> Sony protocol remotes have a 4Hz carrier, and I am getting lower values
> for the carrier with other carrier frequencies as well. Any idea why?
> 

I'm also seeing consistently low Hz results myself. My guess is the mceusb 
hardware may be under counting carrier cycles during IR pulse "on" it sees. I 
see the following data from the receiver for a spurious IR:

[  329.602445] mceusb 1-1.2:1.0: RX carrier frequency 0 Hz (pulse count = 1, 
duration = 2, cycles = 0)

To see a pulse, there must exist a carrier, so the IR carrier cycle count 
should be > 0.

In patch v2, I'm assuming the mceusb hardware misses 1 carrier cycle count for 
every IR on pulse it sees and adjusted the carrier freq calculations 
accordingly. The adjustments needed may turn out to be hardware specific, so 
further refinements may be needed.

Did you see low Hz values for all your four mceusb devices?


>> +/*
>> + * cmdbuf[2] is receiver port number
>> + * port 1 is long range receiver
>> + * port 2 is short range receiver
>> + */
>> +cmdbuf[2] = enable + 1;
> 
> You could do enable ? 2 : 1 here and do away with the check above. Enable
> always is 0 or 1 anyway.
> 
>> +dev_dbg(ir->dev, "select %s-range receive sensor",
>> +enable ? "short" : "long");
>> +mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
>> +
>> +return 0;
>> +}
>> +
>> +/*
>> + * Enable/disable receiver carrier frequency pass through reporting.
>> + * Frequency measurement only works with the short-range receiver.
>> + * The long-range receiver always reports no carrier frequency
>> + * (MCE_RSP_EQIRRXCFCNT, 0, 0) so we always ignore its report.
>> + */
>> +static int mceusb_set_rx_carrier_report(struct rc_dev *dev, int enable)
>> +{
>> +struct mceusb_dev *ir = dev->priv;
>> +
>> +if (enable != 0 && enable != 1)
>> +return -EINVAL;
> 
> This is only called from lirc_dev.c, where the expression is:
> 
>   ret = dev->s_carrier_report(dev, !!val);
> 
> There is no need to check for enable being not 0 or 1.
> 
>> +
>> +dev_dbg(ir->dev, "%s short-range receiver carrier reporting",
>> +enable ? "enable" : "disable");
>> +ir->carrier_report_enabled = (enable == 1);
> 
> Since enable is 0 or 1, there is no need for the enable == 1 expression.
> 
> Note that the other drivers that support carrier reports (winbond-cir,
> redrat3, ene-cir) all enable the wideband receiver when carrier reports
> are turned on. You won't get carrier reports with the narrowband
> receiver, so if the user does:
> 
> ir-ctl -r -m
> 
> Then they will get nothing. It should really be consistent with the other
> drivers and enable wideband implicitly.
> 

I've added to patch v2 to implicitly enable the wide-band receiver when 
enabling carrier reporting. Plus additional revisions from your other comments.

Re: [GIT PULL] HEVC V4L2 controls and s5p-mfc update

[Sylwester Nawrocki]

On 03/12/2018 05:49 PM, Hans Verkuil wrote:
> On 03/12/2018 09:35 AM, Sylwester Nawrocki wrote:
>> On 03/12/2018 05:19 PM, Hans Verkuil wrote:
>>> Does this include this __v4l2_ctrl_modify_range() request:
>>>
>>> https://patchwork.kernel.org/patch/10196605/
>>>
>>> I haven't seen anything for that. I'd like to see that implemented before 
>>> this
>>> is merged, otherwise this typically will never happen.
>> Not yet, I assumed it will come afterwards.
>> I will write the patch myself until end of this week, unless Smitha submits 
>> it earlier.
>>
> OK, in that case I am OK with this pull request. Nice to see HEVC support in!

Hm, I have found some issues in the documentation after those patches.
I will try to fix it and also post the control range update patch.
I have marked the pull request as obsoleted, please ignore it.

-- 
Regards,
Sylwester

[PATCH v4] media/dvb: earth-pt3: use the new i2c binding helper

[tskd08]

From: Akihiro Tsukada 

This patch slightly simplifies the binding code by introducing commit
8f569c0b4e6b ("media: dvb-core: add helper functions for I2C binding").

Signed-off-by: Akihiro Tsukada 
---
Changes since v3
 - earth-pt3: replaced the old helper functions (proposed by patch #27922)
  with the new one (commit:8f569c0b).
 - withdrew the following v3 patches:
   #27923 (tuners/qm1d1c0042),
   #27924 (tuners/mxl301rf),
   #27925 (dvb-frontends/tc90522).
   The new helper functions do not require changes to / apply to
   those demod/tuner i2c drivers.

 drivers/media/pci/pt3/pt3.c | 58 +
 1 file changed, 22 insertions(+), 36 deletions(-)

diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c
index da74828805b..eef4105919b 100644
--- a/drivers/media/pci/pt3/pt3.c
+++ b/drivers/media/pci/pt3/pt3.c
@@ -376,25 +376,23 @@ static int pt3_fe_init(struct pt3_board *pt3)
 
 static int pt3_attach_fe(struct pt3_board *pt3, int i)
 {
-   struct i2c_board_info info;
+   const struct i2c_board_info *info;
struct tc90522_config cfg;
struct i2c_client *cl;
struct dvb_adapter *dvb_adap;
int ret;
 
-   info = adap_conf[i].demod_info;
+   info = _conf[i].demod_info;
cfg = adap_conf[i].demod_cfg;
cfg.tuner_i2c = NULL;
-   info.platform_data = 
 
ret = -ENODEV;
request_module("tc90522");
-   cl = i2c_new_device(>i2c_adap, );
-   if (!cl || !cl->dev.driver)
+   cl = dvb_module_probe("tc90522", info->type, >i2c_adap,
+ info->addr, );
+   if (!cl)
return -ENODEV;
pt3->adaps[i]->i2c_demod = cl;
-   if (!try_module_get(cl->dev.driver->owner))
-   goto err_demod_i2c_unregister_device;
 
if (!strncmp(cl->name, TC90522_I2C_DEV_SAT,
 strlen(TC90522_I2C_DEV_SAT))) {
@@ -402,41 +400,33 @@ static int pt3_attach_fe(struct pt3_board *pt3, int i)
 
tcfg = adap_conf[i].tuner_cfg.qm1d1c0042;
tcfg.fe = cfg.fe;
-   info = adap_conf[i].tuner_info;
-   info.platform_data = 
-   request_module("qm1d1c0042");
-   cl = i2c_new_device(cfg.tuner_i2c, );
+   info = _conf[i].tuner_info;
+   cl = dvb_module_probe("qm1d1c0042", info->type, cfg.tuner_i2c,
+ info->addr, );
} else {
struct mxl301rf_config tcfg;
 
tcfg = adap_conf[i].tuner_cfg.mxl301rf;
tcfg.fe = cfg.fe;
-   info = adap_conf[i].tuner_info;
-   info.platform_data = 
-   request_module("mxl301rf");
-   cl = i2c_new_device(cfg.tuner_i2c, );
+   info = _conf[i].tuner_info;
+   cl = dvb_module_probe("mxl301rf", info->type, cfg.tuner_i2c,
+ info->addr, );
}
-   if (!cl || !cl->dev.driver)
-   goto err_demod_module_put;
+   if (!cl)
+   goto err_demod_module_release;
pt3->adaps[i]->i2c_tuner = cl;
-   if (!try_module_get(cl->dev.driver->owner))
-   goto err_tuner_i2c_unregister_device;
 
dvb_adap = >adaps[one_adapter ? 0 : i]->dvb_adap;
ret = dvb_register_frontend(dvb_adap, cfg.fe);
if (ret < 0)
-   goto err_tuner_module_put;
+   goto err_tuner_module_release;
pt3->adaps[i]->fe = cfg.fe;
return 0;
 
-err_tuner_module_put:
-   module_put(pt3->adaps[i]->i2c_tuner->dev.driver->owner);
-err_tuner_i2c_unregister_device:
-   i2c_unregister_device(pt3->adaps[i]->i2c_tuner);
-err_demod_module_put:
-   module_put(pt3->adaps[i]->i2c_demod->dev.driver->owner);
-err_demod_i2c_unregister_device:
-   i2c_unregister_device(pt3->adaps[i]->i2c_demod);
+err_tuner_module_release:
+   dvb_module_release(pt3->adaps[i]->i2c_tuner);
+err_demod_module_release:
+   dvb_module_release(pt3->adaps[i]->i2c_demod);
 
return ret;
 }
@@ -630,14 +620,10 @@ 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) {
-   module_put(adap->i2c_tuner->dev.driver->owner);
-   i2c_unregister_device(adap->i2c_tuner);
-   }
-   if (adap->i2c_demod) {
-   module_put(adap->i2c_demod->dev.driver->owner);
-   i2c_unregister_device(adap->i2c_demod);
-   }
+   if (adap->i2c_tuner)
+   dvb_module_release(adap->i2c_tuner);
+   if (adap->i2c_demod)
+   dvb_module_release(adap->i2c_demod);
}

Re: [PATCH v3] media: staging/imx: fill vb2_v4l2_buffer sequence entry

[Steve Longerbeam]

Hi Peter,


On 03/14/2018 09:51 AM, Peter Seiderer wrote:

Enables gstreamer v4l2src lost frame detection, e.g:

   0:00:08.685185668  348  0x54f520 WARN  v4l2src 
gstv4l2src.c:970:gst_v4l2src_create: lost frames detected: count = 
141 - ts: 0:00:08.330177332

Signed-off-by: Peter Seiderer 
---
Changes in v2:
   - fill vb2_v4l2_buffer sequence entry in imx-ic-prpencvf too
 (suggested by Steve Longerbeam)

Changes in v3:
   - add changelog (suggested by Greg Kroah-Hartman, Fabio Estevam
 and Dan Carpenter) and patch history
   - use u32 (instead of __u32) (suggested by Dan Carpenter)
   - let sequence counter start with zero,


There's no need to initialize (unsigned) priv->frame_sequence to -1. Just
increment it _after_ the "if (done) {...}" block instead of before.

Steve


  keeping v4l2-compliance
 testing happy (needs additional setting of field to a valid
 value, patch will follow soon)
---
  drivers/staging/media/imx/imx-ic-prpencvf.c | 5 +
  drivers/staging/media/imx/imx-media-csi.c   | 5 +
  2 files changed, 10 insertions(+)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index ae453fd422f0..274683d2d4ba 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -103,6 +103,7 @@ struct prp_priv {
int nfb4eof_irq;
  
  	int stream_count;

+   u32 frame_sequence; /* frame sequence counter */
bool last_eof;  /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
struct completion last_eof_comp;
@@ -208,8 +209,11 @@ static void prp_vb2_buf_done(struct prp_priv *priv, struct 
ipuv3_channel *ch)
struct vb2_buffer *vb;
dma_addr_t phys;
  
+	priv->frame_sequence++;

+
done = priv->active_vb2_buf[priv->ipu_buf_num];
if (done) {
+   done->vbuf.sequence = priv->frame_sequence;
vb = >vbuf.vb2_buf;
vb->timestamp = ktime_get_ns();
vb2_buffer_done(vb, priv->nfb4eof ?
@@ -637,6 +641,7 @@ static int prp_start(struct prp_priv *priv)
  
  	/* init EOF completion waitq */

init_completion(>last_eof_comp);
+   priv->frame_sequence = -1;
priv->last_eof = false;
priv->nfb4eof = false;
  
diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c

index 5a195f80a24d..161a92946a86 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -111,6 +111,7 @@ struct csi_priv {
struct v4l2_ctrl_handler ctrl_hdlr;
  
  	int stream_count; /* streaming counter */

+   u32 frame_sequence; /* frame sequence counter */
bool last_eof;   /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
struct completion last_eof_comp;
@@ -234,8 +235,11 @@ static void csi_vb2_buf_done(struct csi_priv *priv)
struct vb2_buffer *vb;
dma_addr_t phys;
  
+	priv->frame_sequence++;

+
done = priv->active_vb2_buf[priv->ipu_buf_num];
if (done) {
+   done->vbuf.sequence = priv->frame_sequence;
vb = >vbuf.vb2_buf;
vb->timestamp = ktime_get_ns();
vb2_buffer_done(vb, priv->nfb4eof ?
@@ -543,6 +547,7 @@ static int csi_idmac_start(struct csi_priv *priv)
  
  	/* init EOF completion waitq */

init_completion(>last_eof_comp);
+   priv->frame_sequence = -1;
priv->last_eof = false;
priv->nfb4eof = false;
  

[PATCH v3] media: staging/imx: fill vb2_v4l2_buffer sequence entry

[Peter Seiderer]

Enables gstreamer v4l2src lost frame detection, e.g:

  0:00:08.685185668  348  0x54f520 WARN  v4l2src 
gstv4l2src.c:970:gst_v4l2src_create: lost frames detected: count = 
141 - ts: 0:00:08.330177332

Signed-off-by: Peter Seiderer 
---
Changes in v2:
  - fill vb2_v4l2_buffer sequence entry in imx-ic-prpencvf too
(suggested by Steve Longerbeam)

Changes in v3:
  - add changelog (suggested by Greg Kroah-Hartman, Fabio Estevam
and Dan Carpenter) and patch history
  - use u32 (instead of __u32) (suggested by Dan Carpenter)
  - let sequence counter start with zero, keeping v4l2-compliance
testing happy (needs additional setting of field to a valid
value, patch will follow soon)
---
 drivers/staging/media/imx/imx-ic-prpencvf.c | 5 +
 drivers/staging/media/imx/imx-media-csi.c   | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index ae453fd422f0..274683d2d4ba 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -103,6 +103,7 @@ struct prp_priv {
int nfb4eof_irq;
 
int stream_count;
+   u32 frame_sequence; /* frame sequence counter */
bool last_eof;  /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
struct completion last_eof_comp;
@@ -208,8 +209,11 @@ static void prp_vb2_buf_done(struct prp_priv *priv, struct 
ipuv3_channel *ch)
struct vb2_buffer *vb;
dma_addr_t phys;
 
+   priv->frame_sequence++;
+
done = priv->active_vb2_buf[priv->ipu_buf_num];
if (done) {
+   done->vbuf.sequence = priv->frame_sequence;
vb = >vbuf.vb2_buf;
vb->timestamp = ktime_get_ns();
vb2_buffer_done(vb, priv->nfb4eof ?
@@ -637,6 +641,7 @@ static int prp_start(struct prp_priv *priv)
 
/* init EOF completion waitq */
init_completion(>last_eof_comp);
+   priv->frame_sequence = -1;
priv->last_eof = false;
priv->nfb4eof = false;
 
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 5a195f80a24d..161a92946a86 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -111,6 +111,7 @@ struct csi_priv {
struct v4l2_ctrl_handler ctrl_hdlr;
 
int stream_count; /* streaming counter */
+   u32 frame_sequence; /* frame sequence counter */
bool last_eof;   /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
struct completion last_eof_comp;
@@ -234,8 +235,11 @@ static void csi_vb2_buf_done(struct csi_priv *priv)
struct vb2_buffer *vb;
dma_addr_t phys;
 
+   priv->frame_sequence++;
+
done = priv->active_vb2_buf[priv->ipu_buf_num];
if (done) {
+   done->vbuf.sequence = priv->frame_sequence;
vb = >vbuf.vb2_buf;
vb->timestamp = ktime_get_ns();
vb2_buffer_done(vb, priv->nfb4eof ?
@@ -543,6 +547,7 @@ static int csi_idmac_start(struct csi_priv *priv)
 
/* init EOF completion waitq */
init_completion(>last_eof_comp);
+   priv->frame_sequence = -1;
priv->last_eof = false;
priv->nfb4eof = false;
 
-- 
2.16.2

Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming

[Javier Martin]

Hello Philipp,

On 14/03/18 16:11, Philipp Zabel wrote:

Hi Javier,

On Wed, 2018-03-14 at 15:35 +0100, Javier Martin wrote:
[...]

The encoder is running on a different system with an older 4.1.0 kernel.
Altough the firmware version in the code is 3.1.1 as well.

Do you think I should try updating the system in the encoder to kernel
4.15 too and see if that makes any difference?


I don't think that should matter. It'd be more interesting if GOP size
has a significant influence. Does the Problem also appear in I-frame
only streams?



OK, I've performed some tests with several resolutions and gop sizes, 
here is the table with the results:


Always playing 3 streams

| Resolution   |  QP   | GopSize   |  Kind of content |  Result 
|
| 640x368  |  25   |16 |   Waving hands   |   time shifts, 
no DEC_PIC_SUCCESS   |
| 640x368  |  25   |0  |   Waving hands   |   time shifts, 
no DEC_PIC_SUCCESS	|
| 320x192  |  25   |0  |   Waving hands   |   time shifts, 
no DEC_PIC_SUCCESS 	|
| 320x192  |  25   |16 |   Waving hands   |   time shifts, 
no DEC_PIC_SUCCESS 	|
| 1280x720 |  25   |16 |   Waving hands   |   macroblock 
artifacts and lots of DEC_PIC_SUCCESS messages |
| 1280x720 |  25   |0  |   Waving hands   |   Surprisingly 
smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS|


* The issues always happens in the first stream, the other 2 streams are 
fine.

* With GopSize = 0 I can even decode 4 720p streams with no artifacts

It looks like for small resolutions it suffers from time shifts when 
multi-streaming, always affecting the first stream for some reason. In 
this case gop size doesn't seem to make any difference.


For higher resolutions like 720p using GopSize = 0 seems to improve 
things a lot.



Regards,
Javier.

Re: [PATCH 1/3] rcar-vin: remove duplicated check of state in irq handler

[Niklas Söderlund]

Hi Jacopo,

On 2018-03-14 16:17:33 +0100, Jacopo Mondi wrote:
> Hi Niklas, Kieran,
> 
> On Tue, Mar 13, 2018 at 06:56:54PM +0100, Niklas Söderlund wrote:
> > Hi Kieran,
> >
> > Thanks for your feedback.
> >
> > On 2018-03-13 17:42:25 +0100, Kieran Bingham wrote:
> > > Hi Niklas,
> > >
> > > Thanks for the patch series :) - I've been looking forward to seeing this 
> > > one !
> > >
> > > On 10/03/18 01:09, Niklas Söderlund wrote:
> > > > This is an error from when the driver where converted from soc-camera.
> > > > There is absolutely no gain to check the state variable two times to be
> > > > extra sure if the hardware is stopped.
> > >
> > > I'll not say this isn't a redundant check ... but isn't the check against 
> > > two
> > > different states, and thus the remaining check doesn't actually catch the 
> > > case
> > > now where state == STOPPED ?
> >
> > Thanks for noticing this, you are correct. I think I need to refresh my
> > glasses subscription after missing this :-)
> >
> > >
> > > (Perhaps state != RUNNING would be better ?, but I haven't checked the 
> > > rest of
> > > the code)
> >
> > I will respin this in a v2 and either use state != RUNNING or at least
> > combine the two checks to prevent future embarrassing mistakes like
> > this.
> 
> I am sorry I have missed this comment, but I think your patch has some
> merits. Ofc no need to hold on v2 of this series for this, but still I
> think you can re-propose this later (and I didn't get from
> your commit message you were confusing STOPPED/STOPPING).
> 
> In rvin_stop_streaming(), you enter STOPPING state, disable the
> interface cleaning ME bit in VnMC and single/continuous capture mode
> in VnFC, and then poll on CA bit of VnMS until the VIN peripheral has
> not been stopped, at this  point you set interface state to STOPPED.
> 
> As you loop you can still receive interrupts, as you are releasing the
> spinlock when sleeping before testing the ME bit again, so it's fine
> checking for STOPPING state in irq handler.
> It seems to me though, that once you enter STOPPED state, you are sure the
> peripheral has stopped and you should not receive any more interrupt, spurious
> ones apart or when the peripheral fails to stop at all, but things went
> south already at that point.
> 
> Again no need to have this part of this series, but you may want to
> take into consideration this for the future, as with this change you can
> remove the STOPPED state at all from the driver.

You are correct.

This patch was extracted from another series I plan to post after the 
VIN Gen3 beast is done. The aim of that series is to add SEQ_TB/BT 
support to VIN and to do so another state STARTING is needed to handle 
the first few fields. But to avoid growing that series too large I 
thought I could get away with adding this cleanup to this series which 
cleans up the interrupt handler. So this patch will comeback in some 
form when I post that series :-)

But for now I'm happy to drop it as the performance gain with this 
patch-set applied are so nice when running into buffer starved 
situations.

> 
> Thanks
>j
> 
> >
> > >
> > > --
> > > Kieran
> > >
> > >
> > > >
> > > > Signed-off-by: Niklas Söderlund 
> > > > ---
> > > >  drivers/media/platform/rcar-vin/rcar-dma.c | 6 --
> > > >  1 file changed, 6 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> > > > b/drivers/media/platform/rcar-vin/rcar-dma.c
> > > > index 23fdff7a7370842e..b4be75d5009080f7 100644
> > > > --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> > > > +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> > > > @@ -916,12 +916,6 @@ static irqreturn_t rvin_irq(int irq, void *data)
> > > > rvin_ack_interrupt(vin);
> > > > handled = 1;
> > > >
> > > > -   /* Nothing to do if capture status is 'STOPPED' */
> > > > -   if (vin->state == STOPPED) {
> > > > -   vin_dbg(vin, "IRQ while state stopped\n");
> > > > -   goto done;
> > > > -   }
> > > > -
> > > > /* Nothing to do if capture status is 'STOPPING' */
> > > > if (vin->state == STOPPING) {
> > > > vin_dbg(vin, "IRQ while state stopping\n");
> > > >
> >
> > --
> > Regards,
> > Niklas Söderlund



-- 
Regards,
Niklas Söderlund

RE: [PATCH v8] media: imx258: Add imx258 camera sensor driver

[Yeh, Andy]

Still wrong line break...
Please check the list instead. Thanks.
https://patchwork.linuxtv.org/patch/47936/

Regards, Andy

-Original Message-
From: Yeh, Andy 
Sent: Thursday, March 15, 2018 12:24 AM
To: linux-media@vger.kernel.org; tf...@chromium.org
Cc: sakari.ai...@linux.intel.com; Yeh, Andy ; Chen, JasonX 
Z ; Chiang, AlanX ; Lai, Jim 

Subject: [PATCH v8] media: imx258: Add imx258 camera sensor driver

From: Jason Chen 

Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.

Signed-off-by: Andy Yeh 
Signed-off-by: Alan Chiang 
---
since v2:
-- Update the streaming function to remove SW_STANDBY in the beginning.
-- Adjust the delay time from 1ms to 12ms before set stream-on register.
since v3:
-- fix the sd.entity to make code be compiled on the mainline kernel.
since v4:
-- Enabled AG, DG, and Exposure time control correctly.
since v5:
-- Sensor vendor provided a new setting to fix different CLK issue
-- Add one more resolution for 1048x780, used for VGA streaming since v6:
-- improved i2c read/write function to support writing 2 registers
-- modified i2c reg read/write function with a more portable way
-- utilized v4l2_find_nearest_size instead of the local find_best_fit function
-- defined an enum for the link freq entries for explicit indexing since v7:
-- Removed usleep due to sufficient delay implemented in coreboot
-- Added handling for VBLANK control that auto frame-line-control is enabled


 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx258.c | 1299 
 4 files changed, 1318 insertions(+)
 create mode 100644 drivers/media/i2c/imx258.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a339bb5..9f75510 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12646,6 +12646,13 @@ S: Maintained
 F: drivers/ssb/
 F: include/linux/ssb/
 
+SONY IMX258 SENSOR DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx258.c
+
 SONY IMX274 SENSOR DRIVER
 M: Leon Luo 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 
fd01842..bcd4bf1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -565,6 +565,17 @@ config VIDEO_APTINA_PLL  config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX258
+   tristate "Sony IMX258 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Sony
+ IMX258 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx258.
+
 config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API diff --git 
a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 
1b62639..4bf7d00 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX258) += imx258.o
 obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c new file 
mode 100644 index 000..b671ee5
--- /dev/null
+++ b/drivers/media/i2c/imx258.c
@@ -0,0 +1,1299 @@
+// Copyright (C) 2018 Intel Corporation // SPDX-License-Identifier: 
+GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX258_REG_VALUE_08BIT 1
+#define IMX258_REG_VALUE_16BIT 2
+
+#define IMX258_REG_MODE_SELECT 0x0100
+#define IMX258_MODE_STANDBY0x00
+#define IMX258_MODE_STREAMING  0x01
+
+/* Chip ID */
+#define IMX258_REG_CHIP_ID 0x0016
+#define IMX258_CHIP_ID 0x0258
+
+/* V_TIMING internal */
+#define IMX258_REG_VTS 0x0340
+#define IMX258_VTS_30FPS   0x0c98
+#define IMX258_VTS_30FPS_2K0x0638
+#define IMX258_VTS_30FPS_VGA   0x034c
+#define IMX258_VTS_MAX 0x
+
+/*Frame Length Line*/
+#define IMX258_FLL_MIN 0x08a6
+#define IMX258_FLL_MAX 0x
+#define IMX258_FLL_STEP1
+#define IMX258_FLL_DEFAULT 0x0c98
+
+/* HBLANK control - read only */
+#define IMX258_PPL_DEFAULT 5352
+
+/* 

Re: [PATCH v8 10/13] [media] vb2: add out-fence support to QBUF

[Hans Verkuil]

On 03/09/2018 09:49 AM, Gustavo Padovan wrote:
> 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 on the fence_fd field as a

on the -> in the

> return arg for the QBUF call.
> 
> The fence is signaled on buffer_done(), when the job on the buffer is
> finished.
> 
> 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 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 88 
> +
>  drivers/media/common/videobuf2/videobuf2-v4l2.c | 20 +-
>  include/media/videobuf2-core.h  | 25 +++
>  3 files changed, 132 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 5de5e35cfc40..dd18a9f345c7 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 */
> @@ -934,10 +936,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, -EFAULT);

-EFAULT doesn't sound right. -EIO seems more appropriate.

> + 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;
> @@ -1353,6 +1367,62 @@ 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 = vb2_fence_get_timeline_name,
> 

RE: [PATCH v7] media: imx258: Add imx258 camera sensor driver

[Yeh, Andy]

Hi Tomasz,

Thanks for the comments. OKAY as inline.
Please check the Patch V8.

Regards, Andy

-Original Message-
From: Tomasz Figa [mailto:tf...@chromium.org] 
Sent: Monday, March 12, 2018 3:33 PM
To: Yeh, Andy 
Cc: Linux Media Mailing List ; Sakari Ailus 
; Chen, JasonX Z ; 
Chiang, AlanX ; Lai, Jim 
Subject: Re: [PATCH v7] media: imx258: Add imx258 camera sensor driver

Hi Andy,

On Mon, Mar 12, 2018 at 1:01 AM, Andy Yeh  wrote:
>> Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
>> This is a camera sensor using the I2C bus for control and the
>> CSI-2 bus for data.
>>
>> Signed-off-by: Jason Chen 
>> Signed-off-by: Alan Chiang 
>> ---
>> since v2:
>> -- Update the streaming function to remove SW_STANDBY in the beginning.
>> -- Adjust the delay time from 1ms to 12ms before set stream-on register.
>> since v3:
>> -- fix the sd.entity to make code be compiled on the mainline kernel.
>> since v4:
>> -- Enabled AG, DG, and Exposure time control correctly.
>> since v5:
>> -- Sensor vendor provided a new setting to fix different CLK issue
>> -- Add one more resolution for 1048x780, used for VGA streaming since 
>> v6:
>> -- improved i2c read/write function to support writing 2 registers
>> -- modified i2c reg read/write function with a more portable way
>> -- utilized v4l2_find_nearest_size instead of the local find_best_fit 
>> function
>> -- defined an enum for the link freq entries for explicit indexing
>
>Thanks for the patch. Looks almost good now. Just two new comments inline.
>
>[snip]
>> +   /* Set Orientation be 180 degree */
>> +   ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
>> +   IMX258_REG_VALUE_08BIT, 
>> REG_CONFIG_MIRROR_FLIP);
>> +   if (ret) {
>> +   dev_err(>dev, "%s failed to set orientation\n",
>> +   __func__);
>> +   return ret;
>> +   }
>> +
>> +   /* Apply customized values from user */
>> +   ret =  __v4l2_ctrl_handler_setup(imx258->sd.ctrl_handler);
>> +   if (ret)
>> +   return ret;
>> +
>> +   /*
>> +* Per sensor datasheet:
>> +* These are the minimum 12ms delays for accessing the sensor through
>> +* I2C and enabling streaming after lifting the device from reset.
>> +*/
>> +   usleep_range(12000, 13000);
>
>Hmm, the code above already accesses the sensor through I2C. If this works, is 
>this sleep perhaps already done by ACPI code or it is only needed for 
>streaming?
>

Okay.
usleep removed since confirmed sufficient delay implemented in coreboot. Stress 
test passed.

>[snip]
>> +/* Initialize control handlers */
>> +static int imx258_init_controls(struct imx258 *imx258) {
>> +   struct i2c_client *client = v4l2_get_subdevdata(>sd);
>> +   struct v4l2_ctrl_handler *ctrl_hdlr;
>> +   s64 exposure_max;
>> +   s64 vblank_def;
>> +   s64 vblank_min;
>> +   s64 pixel_rate_min;
>> +   s64 pixel_rate_max;
>> +   int ret;
>> +
>> +   ctrl_hdlr = >ctrl_handler;
>> +   ret = v4l2_ctrl_handler_init(ctrl_hdlr, 8);
>> +   if (ret)
>> +   return ret;
>> +
>> +   mutex_init(>mutex);
>> +   ctrl_hdlr->lock = >mutex;
>> +   imx258->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
>> +   _ctrl_ops,
>> +   V4L2_CID_LINK_FREQ,
>> +   ARRAY_SIZE(link_freq_menu_items) - 1,
>> +   0,
>> +   link_freq_menu_items);
>> +
>> +   if (!imx258->link_freq) {
>> +   ret = -EINVAL;
>> +   goto error;
>> +   }
>> +
>> +   imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>
>nit: As discussed earlier with Sakari, I think we agreed on making this, and 
>other controls that need dereferencing here, as follows:
>
>imx258->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
>_ctrl_ops,
>V4L2_CID_LINK_FREQ,
>ARRAY_SIZE(link_freq_menu_items) - 1,
>0,
>link_freq_menu_items);
>if (imx258->link_freq)
>imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>
>The error will be reported at the end of this function, through the check for 
>ctrl_hdlr->error.
>
>
OKAY


Best regards,
Tomasz

[PATCH v8] media: imx258: Add imx258 camera sensor driver

[Andy Yeh]

From: Jason Chen 

Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.

Signed-off-by: Andy Yeh 
Signed-off-by: Alan Chiang 
---
since v2:
-- Update the streaming function to remove SW_STANDBY in the beginning.
-- Adjust the delay time from 1ms to 12ms before set stream-on register.
since v3:
-- fix the sd.entity to make code be compiled on the mainline kernel.
since v4:
-- Enabled AG, DG, and Exposure time control correctly.
since v5:
-- Sensor vendor provided a new setting to fix different CLK issue
-- Add one more resolution for 1048x780, used for VGA streaming
since v6:
-- improved i2c read/write function to support writing 2 registers
-- modified i2c reg read/write function with a more portable way
-- utilized v4l2_find_nearest_size instead of the local find_best_fit function
-- defined an enum for the link freq entries for explicit indexing
since v7:
-- Removed usleep due to sufficient delay implemented in coreboot
-- Added handling for VBLANK control that auto frame-line-control is enabled


 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx258.c | 1299 
 4 files changed, 1318 insertions(+)
 create mode 100644 drivers/media/i2c/imx258.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a339bb5..9f75510 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12646,6 +12646,13 @@ S: Maintained
 F: drivers/ssb/
 F: include/linux/ssb/
 
+SONY IMX258 SENSOR DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx258.c
+
 SONY IMX274 SENSOR DRIVER
 M: Leon Luo 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd01842..bcd4bf1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -565,6 +565,17 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX258
+   tristate "Sony IMX258 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Sony
+ IMX258 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx258.
+
 config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 1b62639..4bf7d00 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX258) += imx258.o
 obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
new file mode 100644
index 000..b671ee5
--- /dev/null
+++ b/drivers/media/i2c/imx258.c
@@ -0,0 +1,1299 @@
+// Copyright (C) 2018 Intel Corporation
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX258_REG_VALUE_08BIT 1
+#define IMX258_REG_VALUE_16BIT 2
+
+#define IMX258_REG_MODE_SELECT 0x0100
+#define IMX258_MODE_STANDBY0x00
+#define IMX258_MODE_STREAMING  0x01
+
+/* Chip ID */
+#define IMX258_REG_CHIP_ID 0x0016
+#define IMX258_CHIP_ID 0x0258
+
+/* V_TIMING internal */
+#define IMX258_REG_VTS 0x0340
+#define IMX258_VTS_30FPS   0x0c98
+#define IMX258_VTS_30FPS_2K0x0638
+#define IMX258_VTS_30FPS_VGA   0x034c
+#define IMX258_VTS_MAX 0x
+
+/*Frame Length Line*/
+#define IMX258_FLL_MIN 0x08a6
+#define IMX258_FLL_MAX 0x
+#define IMX258_FLL_STEP1
+#define IMX258_FLL_DEFAULT 0x0c98
+
+/* HBLANK control - read only */
+#define IMX258_PPL_DEFAULT 5352
+
+/* Exposure control */
+#define IMX258_REG_EXPOSURE0x0202
+#define IMX258_EXPOSURE_MIN4
+#define IMX258_EXPOSURE_STEP   1
+#define IMX258_EXPOSURE_DEFAULT0x640
+#define IMX258_EXPOSURE_MAX65535
+
+/* Analog gain control */
+#define IMX258_REG_ANALOG_GAIN 0x0204
+#define IMX258_ANA_GAIN_MIN0
+#define IMX258_ANA_GAIN_MAX0x1fff
+#define IMX258_ANA_GAIN_STEP   1
+#define IMX258_ANA_GAIN_DEFAULT0x0
+
+/* 

Re: [PATCH v8 12/13] [media] v4l: Add V4L2_CAP_FENCES to drivers

[Hans Verkuil]

On 03/09/2018 09:49 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Drivers that use videobuf2 are capable of using fences and
> should report that to userspace.
> 
> The coding style is following what each drivers was already
> doing.

I think this can be simplified for most drivers: you can set this
flag in the v4l_querycap function if vdev->queue is not NULL or if
m2m_ctx is set in struct v4l2_fh.

I believe all non-m2m drivers that use vb2 set vdev->queue. But not
all m2m drivers will set m2m_ctx, so that will need to be checked.

In other words, this way you only need to modify m2m drivers that
do not set m2m_ctx.

Regards,

Hans

Re: [PATCH v8 13/13] [media] v4l: Document explicit synchronization behavior

[Hans Verkuil]

On 03/13/2018 08:33 PM, Hans Verkuil wrote:
> On 03/09/2018 09:49 AM, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Add section to VIDIOC_QBUF and VIDIOC_QUERY_BUF about it
>>
>> 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 
>> ---
>>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 55 
>> +++-
>>  Documentation/media/uapi/v4l/vidioc-querybuf.rst | 12 --
>>  2 files changed, 63 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
>> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> index 9e448a4aa3aa..371d84966e34 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,59 @@ 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 other will cause ``VIDIOC_QBUF`` to return
>> +with an error.
> 
> This sentence is confusing since it is not clear what 'one' and 'the other' 
> refer
> to. Be specific here. I think it should be 'Setting V4L2_BUF_FLAG_IN_FENCE 
> but not
> fence_fd'.

Ignore this comment.

> 
>  The fence_fd field will be ignored if the
>> +``V4L2_BUF_FLAG_IN_FENCE`` is not set.

Looking at the code, I don't think this is correct. You get an error if 
IN_FENCE is
not set but fence_fd is. Removing this sentence would fix this and the previous
sentence would make a lot more sense.

>> +
>> +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 after will be also block 
>> until
> 
> after -> afterwards
> will be also block -> will also be blocked
> 
>> +that fence signal.
> 
> signal -> signals

What is missing in the documentation is what happens when you mix in-fence 
buffers
and buffers without an in-fence.

Regards,

Hans

Re: [PATCH v8 09/13] [media] vb2: add in-fence support to QBUF

[Hans Verkuil]

On 03/09/2018 09:49 AM, Gustavo Padovan wrote:
> 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 queue to the driver

queue -> queued

> out of the order they were queued from userspace. That means that even if
> it fence signal it must wait all other buffers, ahead of it in the queue,

it fence signal -> its fence signals
wait all -> wait for all

> 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.
> 
> v9:   - rename fence to in_fence in many places
>   - handle fences signalling with error better (Hans Verkuil)
> 
> v8:   - 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

v9? Two v8 entries?

> 
> 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 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 197 
> 
>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  34 +++-
>  drivers/media/v4l2-core/Kconfig |  33 
>  include/media/videobuf2-core.h  |  14 +-
>  4 files changed, 248 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index d3f7bb33a54d..5de5e35cfc40 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];
> @@ -891,20 +892,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 != 

[PATCH 20/47] media: platform: remove blackfin capture driver

[Arnd Bergmann]

The blackfin architecture is getting removed, so the video
capture driver is also obsolete.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/platform/Kconfig |   2 -
 drivers/media/platform/Makefile|   2 -
 drivers/media/platform/blackfin/Kconfig|  16 -
 drivers/media/platform/blackfin/Makefile   |   2 -
 drivers/media/platform/blackfin/bfin_capture.c | 983 -
 drivers/media/platform/blackfin/ppi.c  | 361 -
 include/media/blackfin/bfin_capture.h  |  39 -
 include/media/blackfin/ppi.h   |  94 ---
 8 files changed, 1499 deletions(-)
 delete mode 100644 drivers/media/platform/blackfin/Kconfig
 delete mode 100644 drivers/media/platform/blackfin/Makefile
 delete mode 100644 drivers/media/platform/blackfin/bfin_capture.c
 delete mode 100644 drivers/media/platform/blackfin/ppi.c
 delete mode 100644 include/media/blackfin/bfin_capture.h
 delete mode 100644 include/media/blackfin/ppi.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 5d8fd71fc454..2136702c95fc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -31,8 +31,6 @@ source "drivers/media/platform/davinci/Kconfig"
 
 source "drivers/media/platform/omap/Kconfig"
 
-source "drivers/media/platform/blackfin/Kconfig"
-
 config VIDEO_SH_VOU
tristate "SuperH VOU video output driver"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 85e112122f32..2b07f2e2fca6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -53,8 +53,6 @@ obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC)+= tegra-cec/
 
 obj-y  += stm32/
 
-obj-y   += blackfin/
-
 obj-y  += davinci/
 
 obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o
diff --git a/drivers/media/platform/blackfin/Kconfig 
b/drivers/media/platform/blackfin/Kconfig
deleted file mode 100644
index 68fa90151b8f..
diff --git a/drivers/media/platform/blackfin/Makefile 
b/drivers/media/platform/blackfin/Makefile
deleted file mode 100644
index 30421bc23080..
diff --git a/drivers/media/platform/blackfin/bfin_capture.c 
b/drivers/media/platform/blackfin/bfin_capture.c
deleted file mode 100644
index b7660b1000fd..
diff --git a/drivers/media/platform/blackfin/ppi.c 
b/drivers/media/platform/blackfin/ppi.c
deleted file mode 100644
index d3dc765c1609..
diff --git a/include/media/blackfin/bfin_capture.h 
b/include/media/blackfin/bfin_capture.h
deleted file mode 100644
index a999a3970c69..
diff --git a/include/media/blackfin/ppi.h b/include/media/blackfin/ppi.h
deleted file mode 100644
index 987e49e8f9c9..
-- 
2.9.0

[PATCH 21/47] media: platform: remove m32r specific arv driver

[Arnd Bergmann]

The m32r architecture is getting removed, so this one is no longer needed.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/platform/Kconfig  |  20 -
 drivers/media/platform/Makefile |   2 -
 drivers/media/platform/arv.c| 884 
 3 files changed, 906 deletions(-)
 delete mode 100644 drivers/media/platform/arv.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2136702c95fc..c7a1cf8a1b01 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -52,26 +52,6 @@ config VIDEO_VIU
  Say Y here if you want to enable VIU device on MPC5121e Rev2+.
  In doubt, say N.
 
-config VIDEO_M32R_AR
-   tristate "AR devices"
-   depends on VIDEO_V4L2
-   depends on M32R || COMPILE_TEST
-   ---help---
- This is a video4linux driver for the Renesas AR (Artificial Retina)
- camera module.
-
-config VIDEO_M32R_AR_M64278
-   tristate "AR device with color module M64278(VGA)"
-   depends on PLAT_M32700UT
-   select VIDEO_M32R_AR
-   ---help---
- This is a video4linux driver for the Renesas AR (Artificial
- Retina) with M64278E-800 camera module.
- This module supports VGA(640x480 pixels) resolutions.
-
- To compile this driver as a module, choose M here: the
- module will be called arv.
-
 config VIDEO_MUX
tristate "Video Multiplexer"
select MULTIPLEXER
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 2b07f2e2fca6..932515df4477 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -3,8 +3,6 @@
 # Makefile for the video capture/playback device drivers.
 #
 
-obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
-
 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/arv.c b/drivers/media/platform/arv.c
deleted file mode 100644
index 1e865fea803c..
-- 
2.9.0

[PATCH v2] media: omap3isp: fix unbalanced dma_iommu_mapping

[Suman Anna]

The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware
ARM DMA backend. The current code creates a dma_iommu_mapping and
attaches this to the ISP device, but never detaches the mapping in
either the probe failure paths or the driver remove path resulting
in an unbalanced mapping refcount and a memory leak. Fix this properly.

Reported-by: Pavel Machek 
Signed-off-by: Suman Anna 
Acked-by: Sakari Ailus 
---
v2 Changes:
 - Dropped the error_attach label, and returned directly from the
   first error path (comments from Sakari)
 - Added Sakari's Acked-by
v1: https://patchwork.kernel.org/patch/10276759/

Pavel,
I dropped your Tested-by from v2 since I modified the patch, can you
recheck the new patch again? Thanks.

regards
Suman

 drivers/media/platform/omap3isp/isp.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 8eb000e3d8fd..f2db5128d786 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1945,6 +1945,7 @@ static int isp_initialize_modules(struct isp_device *isp)
 
 static void isp_detach_iommu(struct isp_device *isp)
 {
+   arm_iommu_detach_device(isp->dev);
arm_iommu_release_mapping(isp->mapping);
isp->mapping = NULL;
 }
@@ -1961,8 +1962,7 @@ static int isp_attach_iommu(struct isp_device *isp)
mapping = arm_iommu_create_mapping(_bus_type, SZ_1G, SZ_2G);
if (IS_ERR(mapping)) {
dev_err(isp->dev, "failed to create ARM IOMMU mapping\n");
-   ret = PTR_ERR(mapping);
-   goto error;
+   return PTR_ERR(mapping);
}
 
isp->mapping = mapping;
@@ -1977,7 +1977,8 @@ static int isp_attach_iommu(struct isp_device *isp)
return 0;
 
 error:
-   isp_detach_iommu(isp);
+   arm_iommu_release_mapping(isp->mapping);
+   isp->mapping = NULL;
return ret;
 }
 
-- 
2.16.2

[PATCH 00/47] arch-removal: device drivers

[Arnd Bergmann]

Hi driver maintainers,

I just posted one series with the removal of eight architectures,
see https://lkml.org/lkml/2018/3/14/505 for details, or
https://lwn.net/Articles/748074/ for more background.

These are the device drivers that go along with them. I have already
picked up the drivers for arch/metag/ into my tree, they were reviewed
earlier.

Please let me know if you have any concerns with the patch, or if you
prefer to pick up the patches in your respective trees.  I created
the patches with 'git format-patch -D', so they will not apply without
manually removing those files.

For anything else, I'd keep the removal patches in my asm-generic tree
and will send a pull request for 4.17 along with the actual arch removal.

   Arnd

Arnd Bergmann
  edac: remove tile driver
  net: tile: remove ethernet drivers
  net: adi: remove blackfin ethernet drivers
  net: 8390: remove m32r specific bits
  net: remove cris etrax ethernet driver
  net: smsc: remove m32r specific smc91x configuration
  raid: remove tile specific raid6 implementation
  rtc: remove tile driver
  rtc: remove bfin driver
  char: remove obsolete ds1302 rtc driver
  char: remove tile-srom.c
  char: remove blackfin OTP driver
  pcmcia: remove m32r drivers
  pcmcia: remove blackfin driver
  ASoC: remove blackfin drivers
  video/logo: remove obsolete logo files
  fbdev: remove blackfin drivers
  fbdev: s1d13xxxfb: remove m32r specific hacks
  crypto: remove blackfin CRC driver
  media: platform: remove blackfin capture driver
  media: platform: remove m32r specific arv driver
  cpufreq: remove blackfin driver
  cpufreq: remove cris specific drivers
  gpio: remove etraxfs driver
  pinctrl: remove adi2/blackfin drivers
  ata: remove bf54x driver
  input: keyboard: remove bf54x driver
  input: misc: remove blackfin rotary driver
  mmc: remove bfin_sdh driver
  can: remove bfin_can driver
  watchdog: remove bfin_wdt driver
  mtd: maps: remove bfin-async-flash driver
  mtd: nand: remove bf5xx_nand driver
  spi: remove blackfin related host drivers
  i2c: remove bfin-twi driver
  pwm: remobe pwm-bfin driver
  usb: host: remove tilegx platform glue
  usb: musb: remove blackfin port
  usb: isp1362: remove blackfin arch glue
  serial: remove cris/etrax uart drivers
  serial: remove blackfin drivers
  serial: remove m32r_sio driver
  serial: remove tile uart driver
  tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
  tty: hvc: remove tile driver
  staging: irda: remove bfin_sir driver
  staging: iio: remove iio-trig-bfin-timer driver

 .../devicetree/bindings/gpio/gpio-etraxfs.txt  |   22 -
 .../bindings/serial/axis,etraxfs-uart.txt  |   22 -
 Documentation/watchdog/watchdog-parameters.txt |5 -
 MAINTAINERS|8 -
 drivers/ata/Kconfig|9 -
 drivers/ata/Makefile   |1 -
 drivers/ata/pata_bf54x.c   | 1703 
 drivers/char/Kconfig   |   48 -
 drivers/char/Makefile  |3 -
 drivers/char/bfin-otp.c|  237 --
 drivers/char/ds1302.c  |  357 --
 drivers/char/tile-srom.c   |  475 ---
 drivers/cpufreq/Makefile   |3 -
 drivers/cpufreq/blackfin-cpufreq.c |  217 -
 drivers/cpufreq/cris-artpec3-cpufreq.c |   93 -
 drivers/cpufreq/cris-etraxfs-cpufreq.c |   92 -
 drivers/crypto/Kconfig |7 -
 drivers/crypto/Makefile|1 -
 drivers/crypto/bfin_crc.c  |  753 
 drivers/crypto/bfin_crc.h  |  124 -
 drivers/edac/Kconfig   |8 -
 drivers/edac/Makefile  |2 -
 drivers/edac/tile_edac.c   |  265 --
 drivers/gpio/Kconfig   |9 -
 drivers/gpio/Makefile  |1 -
 drivers/gpio/gpio-etraxfs.c|  475 ---
 drivers/i2c/busses/Kconfig |   18 -
 drivers/i2c/busses/Makefile|1 -
 drivers/i2c/busses/i2c-bfin-twi.c  |  737 
 drivers/input/keyboard/Kconfig |9 -
 drivers/input/keyboard/Makefile|1 -
 drivers/input/keyboard/bf54x-keys.c|  396 --
 drivers/input/misc/Kconfig |9 -
 drivers/input/misc/Makefile|1 -
 drivers/input/misc/bfin_rotary.c   |  294 --
 drivers/media/platform/Kconfig |   22 -
 drivers/media/platform/Makefile|4 -
 drivers/media/platform/arv.c   |  884 
 drivers/media/platform/blackfin/Kconfig|   16 -
 drivers/media/platform/blackfin/Makefile   | 

Re: [PATCH 1/3] rcar-vin: remove duplicated check of state in irq handler

[jacopo mondi]

Hi Niklas, Kieran,

On Tue, Mar 13, 2018 at 06:56:54PM +0100, Niklas Söderlund wrote:
> Hi Kieran,
>
> Thanks for your feedback.
>
> On 2018-03-13 17:42:25 +0100, Kieran Bingham wrote:
> > Hi Niklas,
> >
> > Thanks for the patch series :) - I've been looking forward to seeing this 
> > one !
> >
> > On 10/03/18 01:09, Niklas Söderlund wrote:
> > > This is an error from when the driver where converted from soc-camera.
> > > There is absolutely no gain to check the state variable two times to be
> > > extra sure if the hardware is stopped.
> >
> > I'll not say this isn't a redundant check ... but isn't the check against 
> > two
> > different states, and thus the remaining check doesn't actually catch the 
> > case
> > now where state == STOPPED ?
>
> Thanks for noticing this, you are correct. I think I need to refresh my
> glasses subscription after missing this :-)
>
> >
> > (Perhaps state != RUNNING would be better ?, but I haven't checked the rest 
> > of
> > the code)
>
> I will respin this in a v2 and either use state != RUNNING or at least
> combine the two checks to prevent future embarrassing mistakes like
> this.

I am sorry I have missed this comment, but I think your patch has some
merits. Ofc no need to hold on v2 of this series for this, but still I
think you can re-propose this later (and I didn't get from
your commit message you were confusing STOPPED/STOPPING).

In rvin_stop_streaming(), you enter STOPPING state, disable the
interface cleaning ME bit in VnMC and single/continuous capture mode
in VnFC, and then poll on CA bit of VnMS until the VIN peripheral has
not been stopped, at this  point you set interface state to STOPPED.

As you loop you can still receive interrupts, as you are releasing the
spinlock when sleeping before testing the ME bit again, so it's fine
checking for STOPPING state in irq handler.
It seems to me though, that once you enter STOPPED state, you are sure the
peripheral has stopped and you should not receive any more interrupt, spurious
ones apart or when the peripheral fails to stop at all, but things went
south already at that point.

Again no need to have this part of this series, but you may want to
take into consideration this for the future, as with this change you can
remove the STOPPED state at all from the driver.

Thanks
   j

>
> >
> > --
> > Kieran
> >
> >
> > >
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> > >  drivers/media/platform/rcar-vin/rcar-dma.c | 6 --
> > >  1 file changed, 6 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> > > b/drivers/media/platform/rcar-vin/rcar-dma.c
> > > index 23fdff7a7370842e..b4be75d5009080f7 100644
> > > --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> > > +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> > > @@ -916,12 +916,6 @@ static irqreturn_t rvin_irq(int irq, void *data)
> > >   rvin_ack_interrupt(vin);
> > >   handled = 1;
> > >
> > > - /* Nothing to do if capture status is 'STOPPED' */
> > > - if (vin->state == STOPPED) {
> > > - vin_dbg(vin, "IRQ while state stopped\n");
> > > - goto done;
> > > - }
> > > -
> > >   /* Nothing to do if capture status is 'STOPPING' */
> > >   if (vin->state == STOPPING) {
> > >   vin_dbg(vin, "IRQ while state stopping\n");
> > >
>
> --
> Regards,
> Niklas Söderlund


signature.asc
Description: PGP signature

Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming

[Philipp Zabel]

Hi Javier,

On Wed, 2018-03-14 at 15:35 +0100, Javier Martin wrote:
[...]
> The encoder is running on a different system with an older 4.1.0 kernel. 
> Altough the firmware version in the code is 3.1.1 as well.
> 
> Do you think I should try updating the system in the encoder to kernel 
> 4.15 too and see if that makes any difference?

I don't think that should matter. It'd be more interesting if GOP size
has a significant influence. Does the Problem also appear in I-frame
only streams?

regards
Philipp

Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming

[Javier Martin]

Hello,


On 14/03/18 14:57, Philipp Zabel wrote:

On Wed, 2018-03-14 at 13:05 +0100, Javier Martin wrote:

Sorry everyone about my previous e-mail with all the HTML garbage. Here
is the plain text answer instead.

Hi Philipp,

thanks for your answer.

On 13/03/18 12:20, Philipp Zabel wrote:
  > Hi Javier,
  >
  > On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote:
  >> Hi,
  >> we have an i.MX6 Solo based board running the latest mainline kernel
  >> (4.15.3).
  >>
  >> As part of our development we were measuring the decoding
performance of
  >> the i.MX6 coda chip.
  >>
  >> For that purpose we are feeding the decoder with 640x368 @ 30fps H.264
  >> streams that have been generated by another i.MX6 coda encoder
  >> configured with fixed qp = 25 and gopsize = 16.


Those are the defaults. Is the encoder running on the same system, at
the same time? Or are you decoding a previously encoded stream (multiple
previously encoded streams)?



The encoder is running on a different system with an older 4.1.0 kernel. 
Altough the firmware version in the code is 3.1.1 as well.


Do you think I should try updating the system in the encoder to kernel 
4.15 too and see if that makes any difference?




[...]

I'm currently using 3.1.1 both for encoding and decoding. I think I got
it from the latest BSP provided by NXP. Now that you mention it the
driver is printing these messages at probe time which I had ignored so far:

coda 204.vpu: Firmware code revision: 46056
coda 204.vpu: Initialized CODA960.
coda 204.vpu: Unsupported firmware version: 3.1.1
coda 204.vpu: codec registered as /dev/video[3-4]


That is strange, commit be7f1ab26f42 ("media: coda: mark CODA960
firmware versions 2.3.10 and 3.1.1 as supported") was merged
in v4.14.


You are right, those messages where taken from an old 4.1 kernel and not 
from the latest 4.15 where they don't appear any longer. Sorry for the 
noise.





Do you think I should use an older version instead?


Unfortunately I have no indication that this would help.


Also, do you think it would be worth trying different parameters in the
encoder to see how the decoder responds in those cases?


Possibly. It would be interesting to know if this happens more often for
low resolutions / low quality / static frames than high resolutions /
high quality / high movement.



I can easily prepare a test matrix with several resolutions, QPs and 
content and let you know the results. Although first I'd like to know 
your opinion on whether I should update the encoder to kernel 4.15 too.



Regards,
Javier.

[PATCH v8 05/11] video/hdmi: Reject illegal picture aspect ratios

[Nautiyal, Ankit K]

From: Ville Syrjälä 

AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-media@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Jose Abreu 
---
 drivers/video/hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 111a0ab..38716eb5 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe 
*frame, void *buffer,
if (size < length)
return -ENOSPC;
 
+   if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+   return -EINVAL;
+
memset(buffer, 0, size);
 
ptr[0] = frame->type;
-- 
2.7.4

Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming

[Philipp Zabel]

On Wed, 2018-03-14 at 13:05 +0100, Javier Martin wrote:
> Sorry everyone about my previous e-mail with all the HTML garbage. Here 
> is the plain text answer instead.
> 
> Hi Philipp,
> 
> thanks for your answer.
> 
> On 13/03/18 12:20, Philipp Zabel wrote:
>  > Hi Javier,
>  >
>  > On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote:
>  >> Hi,
>  >> we have an i.MX6 Solo based board running the latest mainline kernel
>  >> (4.15.3).
>  >>
>  >> As part of our development we were measuring the decoding 
> performance of
>  >> the i.MX6 coda chip.
>  >>
>  >> For that purpose we are feeding the decoder with 640x368 @ 30fps H.264
>  >> streams that have been generated by another i.MX6 coda encoder
>  >> configured with fixed qp = 25 and gopsize = 16.

Those are the defaults. Is the encoder running on the same system, at
the same time? Or are you decoding a previously encoded stream (multiple
previously encoded streams)?

[...]
> I'm currently using 3.1.1 both for encoding and decoding. I think I got 
> it from the latest BSP provided by NXP. Now that you mention it the 
> driver is printing these messages at probe time which I had ignored so far:
> 
> coda 204.vpu: Firmware code revision: 46056
> coda 204.vpu: Initialized CODA960.
> coda 204.vpu: Unsupported firmware version: 3.1.1
> coda 204.vpu: codec registered as /dev/video[3-4]

That is strange, commit be7f1ab26f42 ("media: coda: mark CODA960
firmware versions 2.3.10 and 3.1.1 as supported") was merged
in v4.14.

> Do you think I should use an older version instead?

Unfortunately I have no indication that this would help.

> Also, do you think it would be worth trying different parameters in the 
> encoder to see how the decoder responds in those cases?

Possibly. It would be interesting to know if this happens more often for
low resolutions / low quality / static frames than high resolutions /
high quality / high movement.

I fear this may be some interaction between coda context switches and
bitstream reader unit state.

regards
Philipp

Re: [RFCv4,19/21] media: vim2m: add request support

[Paul Kocialkowski]

Hi,

On Tue, 2018-03-13 at 19:24 +0900, Alexandre Courbot wrote:
> On Fri, Mar 9, 2018 at 11:35 PM, Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Thu, 2018-03-08 at 22:48 +0900, Alexandre Courbot wrote:
> > > Hi Paul!
> > > 
> > > Thanks a lot for taking the time to try this! I am also working on
> > > getting it to work with an actual driver, but you apparently found
> > > rough edges that I missed.
> > > 
> > > On Thu, Mar 8, 2018 at 1:37 AM, Paul Kocialkowski
> > >  wrote:
> > > > On Tue, 2018-02-20 at 13:44 +0900, Alexandre Courbot wrote:

[...]

> > > > > +static int vim2m_request_submit(struct media_request *req,
> > > > > + struct media_request_entity_data
> > > > > *_data)
> > > > > +{
> > > > > + struct v4l2_request_entity_data *data;
> > > > > +
> > > > > + data = to_v4l2_entity_data(_data);
> > > > 
> > > > We need to call v4l2_m2m_try_schedule here so that m2m
> > > > scheduling
> > > > can
> > > > happen when only 2 buffers were queued and no other action was
> > > > taken
> > > > from usespace. In that scenario, m2m scheduling currently
> > > > doesn't
> > > > happen.
> > > 
> > > I don't think I understand the sequence of events that results in
> > > v4l2_m2m_try_schedule() not being called. Do you mean something
> > > like:
> > > 
> > > *
> > > * QBUF on output queue with request set
> > > * QBUF on capture queue
> > > * SUBMIT_REQUEST
> > > 
> > > ?
> > > 
> > > The call to vb2_request_submit() right after should trigger
> > > v4l2_m2m_try_schedule(), since the buffers associated to the
> > > request
> > > will enter the vb2 queue and be passed to the m2m framework, which
> > > will then call v4l2_m2m_try_schedule(). Or maybe you are thinking
> > > about a different sequence of events?
> > 
> > This is indeed the sequence of events that I'm seeing, but the
> > scheduling call simply did not happen on vb2_request_submit. I
> > suppose I will need to investigate some more to find out exactly
> > why.
> > 
> > IIRC, the m2m qbuf function is called (and fails to schedule) when
> > the
> > ioctl happens, not when the task is submitted.
> > 
> > This issue is seen with vim2m as well as the rencently-submitted
> > sunxi-
> > cedrus driver (with the in-driver calls to v4l2_m2m_try_schedule
> > removed, obviously). If needs be, I could provide a standalone test
> > program to reproduce it.
> 
> If you have a standalone program that can reproduce this on vim2m,
> then I would like to see it indeed, if only to understand what I have
> missed.

You can find the test file for this use case at:
https://gist.github.com/paulkocialkowski/4cfa350e1bbe8e3bf714480bba83ea72

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

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

[Maxime Ripard]

Hi,

Here is an attempt at supporting the MIPI-CSI2 TX block from Cadence.

This IP block 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.

It is 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.

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 v5:
  - Changed the return type to void for csi2tx_stop
  - Checked for the pad index in get/set_pad_format
  - Made a comment that the DPHY registers are for the DPHY *interface*
register

Changes from v4:
  - After playing a bit with the pad multiplexing patches, found that it
was making much more sense to have the subdev notifiers for the source
subdev rather for the sink that might even be outside of Linux control.
Removed the notifier for now.

Changes from v3:
  - Added a comment about entity links walk concurrency
  - Changed the default resolution to 1280x720
  - Changed usleep_range calls to udelay
  - Reworked the reference counting mechanism to remove a race
condition by adding a mutex instead of an atomic count
  - Changed the entity function to MEDIA_ENT_F_VID_IF_BRIDGE
  - Changed the name of the reg variable in _get_resources to dev_cfg
  - Removed the redundant error message in the devm_ioremap_resource
error path
  - Moved the subdev s_stream call before enabling the TX bridge
  - Changed some int types to unsigned
  - Init'd the pad formats properly
  - Fixed typo in the CSI2TX_LANES_MAX define name
  - Added Sakari Acked-by

Changes from v2:
  - Use SPDX license header
  - Use the lane mapping from DT

Changes from v1:
  - Add a subdev notifier and start our downstream subdevice in
s_stream  
  - Based the decision to enable the stream or not on the link state
instead of whether a format was being set on the pad
  - Put the controller back in reset when stopping the pipeline
  - Clarified the enpoints number in the DT binding
  - Added a default format for the pads
  - Added some missing const
  - Added more explicit comments
  - Rebased on 4.15

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

 .../devicetree/bindings/media/cdns,csi2tx.txt  |  98 
 drivers/media/platform/cadence/Kconfig |  11 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c   | 528 +
 4 files changed, 638 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

-- 
2.14.3

[PATCH v6 1/2] 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: Rob Herring 
Acked-by: Sakari Ailus 
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.14.3

[PATCH v6 2/2] 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.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/cadence/Kconfig   |  11 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c | 528 +++
 3 files changed, 540 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 18f061e5cbd1..83dcf2b1814b 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -14,4 +14,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 99a4086b7448..7fe992273162 100644
--- a/drivers/media/platform/cadence/Makefile
+++ b/drivers/media/platform/cadence/Makefile
@@ -1 +1,2 @@
 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 ..690ca7443569
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2tx.c
@@ -0,0 +1,528 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 TX Controller
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2TX_DEVICE_CONFIG_REG   0x00
+
+#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;
+   struct clk  *p_clk;
+   struct clk  *pixel_clk[CSI2TX_STREAMS_MAX];
+
+   struct v4l2_subdev  subdev;
+   struct media_padpads[CSI2TX_PAD_MAX];
+   struct v4l2_mbus_framefmt   pad_fmts[CSI2TX_PAD_MAX];
+
+   boolhas_internal_dphy;
+   u8  

Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming

[Javier Martin]

Sorry everyone about my previous e-mail with all the HTML garbage. Here 
is the plain text answer instead.


Hi Philipp,

thanks for your answer.

On 13/03/18 12:20, Philipp Zabel wrote:
> Hi Javier,
>
> On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote:
>> Hi,
>> we have an i.MX6 Solo based board running the latest mainline kernel
>> (4.15.3).
>>
>> As part of our development we were measuring the decoding 
performance of

>> the i.MX6 coda chip.
>>
>> For that purpose we are feeding the decoder with 640x368 @ 30fps H.264
>> streams that have been generated by another i.MX6 coda encoder
>> configured with fixed qp = 25 and gopsize = 16.
>>
>> For 1-2 streams it works smoothly. However, when adding the 3rd stream
>> the first decoder instance starts to output these kind of errors:
>>
>> DEC_PIC_SUCCESS = 2097153  -> 0x21
>> DEC_PIC_SUCCESS = 2621441  -> 0x280001
> I think these might be (recoverable?) error flags, but so far I have
> never seen them myself.
> I've had reports of those occurring occasionally with certain streams
> (not encoded by coda, regardless of the number of running decoder
> instances) though.
>
> What is the coda firmware version you are using?

I'm currently using 3.1.1 both for encoding and decoding. I think I got 
it from the latest BSP provided by NXP. Now that you mention it the 
driver is printing these messages at probe time which I had ignored so far:


coda 204.vpu: Firmware code revision: 46056
coda 204.vpu: Initialized CODA960.
coda 204.vpu: Unsupported firmware version: 3.1.1
coda 204.vpu: codec registered as /dev/video[3-4]

Do you think I should use an older version instead?

Also, do you think it would be worth trying different parameters in the 
encoder to see how the decoder responds in those cases?



Regards,
Javier.

does exist a Real time open source Dvb-t multiplexing software

[Federico Allegretti]

Hello everybody.
Surfing google for an open source DVB(t) software multiplexer, i hit this page:
https://www.scara.com/~schirmer/o/mplex13818/

Seems interesting but is ISO 13818 not dvb and refears to a linux DVB
mailing list that is no more active.

Could i write here for questions and doubt?

My need is to have a process that gets multiple AV streams trough LAN,
mux them in a single TS adding the correct tables to identify TV
channels, then output the resulting stream to an ASI board.

Thanks.

Federico
-- 
Open TV Architecture project: http://sourceforge.net/projects/otva/

Messagenet VOIP: 5338759

YouTube Channel: v1p3r's lab

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

Re: [PATCH] media: omap3isp: fix unbalanced dma_iommu_mapping

[Sakari Ailus]

On Tue, Mar 13, 2018 at 10:47:08AM -0500, Suman Anna wrote:
> Hi Sakari,
> 
> On 03/13/2018 06:14 AM, Sakari Ailus wrote:
> > Hi Suman,
> > 
> > Thanks for the patch.
> > 
> > On Mon, Mar 12, 2018 at 11:52:07AM -0500, Suman Anna wrote:
> >> The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware
> >> ARM DMA backend. The current code creates a dma_iommu_mapping and
> >> attaches this to the ISP device, but never detaches the mapping in
> >> either the probe failure paths or the driver remove path resulting
> >> in an unbalanced mapping refcount and a memory leak. Fix this properly.
> >>
> >> Reported-by: Pavel Machek 
> >> Signed-off-by: Suman Anna 
> >> Tested-by: Pavel Machek 
> >> ---
> >> Hi Mauro, Laurent,
> >>
> >> This fixes an issue reported by Pavel and discussed on this
> >> thread,
> >> https://marc.info/?l=linux-omap=152051945803598=2
> >>
> >> Posting this again to the appropriate lists.
> >>
> >> regards
> >> Suman
> >>
> >>  drivers/media/platform/omap3isp/isp.c | 7 +--
> >>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/omap3isp/isp.c 
> >> b/drivers/media/platform/omap3isp/isp.c
> >> index 8eb000e3d8fd..c7d667bfc2af 100644
> >> --- a/drivers/media/platform/omap3isp/isp.c
> >> +++ b/drivers/media/platform/omap3isp/isp.c
> >> @@ -1945,6 +1945,7 @@ static int isp_initialize_modules(struct isp_device 
> >> *isp)
> >>  
> >>  static void isp_detach_iommu(struct isp_device *isp)
> >>  {
> >> +  arm_iommu_detach_device(isp->dev);
> >>arm_iommu_release_mapping(isp->mapping);
> >>isp->mapping = NULL;
> >>  }
> >> @@ -1971,13 +1972,15 @@ static int isp_attach_iommu(struct isp_device *isp)
> >>ret = arm_iommu_attach_device(isp->dev, mapping);
> >>if (ret < 0) {
> >>dev_err(isp->dev, "failed to attach device to VA mapping\n");
> >> -  goto error;
> >> +  goto error_attach;
> > 
> > Instead of changing the label here, could you return immediately where the
> > previous point of error handling is? No need to add another label.
> 
> Yeah, I debated about this while doing the patch, and chose to retain
> the previous common return on the error paths. There are only 2 error
> paths, so didn't want to mix them up. If you still prefer the mixed
> style, I can post a v2.

Yes, please. In general if you only need return a value, a label isn't
needed for that even if goto + labels would be otherwise used for error
handling.

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

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

[Dan Carpenter]

We need a changelog.  How does this affect user space?  What bug does
this fix?

On Tue, Mar 13, 2018 at 09:00:54PM +0100, Peter Seiderer wrote:
> Signed-off-by: Peter Seiderer 
> ---
>  drivers/staging/media/imx/imx-media-csi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index 5a195f80a24d..3a6a645b9dce 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -111,6 +111,7 @@ struct csi_priv {
>   struct v4l2_ctrl_handler ctrl_hdlr;
>  
>   int stream_count; /* streaming counter */
> + __u32 frame_sequence; /* frame sequence counter */

Use u32 because this is not a user space header.

>   bool last_eof;   /* waiting for last EOF at stream off */
>   bool nfb4eof;/* NFB4EOF encountered during streaming */
>   struct completion last_eof_comp;

regards,
dan carpenter

Re: [PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures

[Geert Uytterhoeven]

On Tue, Mar 13, 2018 at 7:05 PM, Kieran Bingham
 wrote:
> The use of the packed attribute can cause a performance penalty for
> all accesses to the struct members, as the compiler will assume that the
> structure has the potential to have an unaligned base.
>
> These structures are all correctly aligned and contain no holes, thus
> the attribute is redundant and negatively impacts performance, so we
> remove the attributes entirely.
>
> Signed-off-by: Kieran Bingham 

Reviewed-by: Geert Uytterhoeven 

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: [RfC PATCH] Add udmabuf misc device

[Gerd Hoffmann]

  Hi,

> Either mlock account (because it's mlocked defacto), and get_user_pages
> won't do that for you.
> 
> Or you write the full-blown userptr implementation, including mmu_notifier
> support (see i915 or amdgpu), but that also requires Christian Königs
> latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr
> buffers is a no-go).

I guess I'll look at mlock accounting for starters then.  Easier for
now, and leaves the door open to switch to userptr later as this should
be transparent to userspace.

> > Known issue:  Driver API isn't complete yet.  Need add some flags, for
> > example to support read-only buffers.
> 
> dma-buf has no concept of read-only. I don't think we can even enforce
> that (not many iommus can enforce this iirc), so pretty much need to
> require r/w memory.

Ah, ok.  Just saw the 'write' arg for get_user_pages_fast and figured we
might support that, but if iommus can't handle that anyway it's
pointless indeed.

> > Cc: David Airlie 
> > Cc: Tomeu Vizoso 
> > Signed-off-by: Gerd Hoffmann 
> 
> btw there's also the hyperdmabuf stuff from the xen folks, but imo their
> solution of forwarding the entire dma-buf api is over the top. This here
> looks _much_ better, pls cc all the hyperdmabuf people on your next
> version.

Fun fact: googling for "hyperdmabuf" found me your mail and nothing else :-o
(Trying "hyper dmabuf" instead worked better then).

Yes, will cc them on the next version.  Not sure it'll help much on xen
though due to the memory management being very different.  Basically xen
owns the memory, not the kernel of the control domain (dom0), so
creating dmabufs for guest memory chunks isn't that simple ...

Also it's not clear whenever they really need guest -> guest exports or
guest -> dom0 exports.

> Overall I like the idea, but too lazy to review.

Cool.  General comments on the idea was all I was looking for for the
moment.  Spare yor review cycles for the next version ;)

> Oh, some kselftests for this stuff would be lovely.

I'll look into it.

thanks,
  Gerd

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

[Greg Kroah-Hartman]

On Tue, Mar 13, 2018 at 09:00:54PM +0100, Peter Seiderer wrote:
> Signed-off-by: Peter Seiderer 
> ---
>  drivers/staging/media/imx/imx-media-csi.c | 5 +
>  1 file changed, 5 insertions(+)

I know I don't take patches with an empty changelog description, but
other maintainers might be much more forgiving... :)