cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sat Apr 21 05:00:22 CEST 2018
media-tree git hash:1d338b86e17d87215cf57b1ad1d13b2afe582d33
media_build git hash:   4fb7a3cc8d0f56c7cddc3b5b29e35aa1159bc8d9
v4l-utils git hash: 9a4acdbe53884e5a433c1295eead61e45b0718e7
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-2-amd64

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

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: Representative Needed.

[PPMC OFFSHORE]

Good day,

  I am seeking your concept with great gratitude to present you as a 
representative to carry out business transactions with a reasonable share upon 
your interest and cooperation to work with us in trust. If interested please 
get back.

Regards
Kingsley

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: cx88 invalid video opcodes when VBI enabled

[Daniel Glöckner]

Hi,

On Wed, Apr 18, 2018 at 08:29:59PM +0200, Daniel Glöckner wrote:
> The VBI instruction queue read pointer points outside the VBI instruction
> queue and into the video y/packed CMDS (to 0x18+0x11*4). The values
> next to the iq rd ptr look ok.
> 
> We only initialize the iq rd ptr to zero in cx88_sram_channel_setup and
> then never touch it again. The hardware takes care of updating it.
> Maybe cx88_sram_channel_setup is sometimes called for channel 24 while the
> VBI risc engine is still running?

for some reason I feel like buffer_queue in cx88-vbi.c should not be
calling cx8800_start_vbi_dma as it is also called a few lines further
down in start_streaming.

Devin, can you check if it helps to remove that line and if VBI still
works afterwards?

Best regards,

  Daniel

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

[Robert Jarzmik]

Wolfram Sang  writes:

> This header only contains platform_data. Move it to the proper directory.
>
> Signed-off-by: Wolfram Sang 
For mach-pxa:
Acked-by: Robert Jarzmik 

Take it through your tree, no problem for the pxa part.

Cheers.

--
Robert

Re: [PATCH] media: s5p-jpeg: don't return a value on a void function

[Jacek Anaszewski]

Hi Mauro,

Thank you for the patch.

On 04/20/2018 09:01 PM, Mauro Carvalho Chehab wrote:
> Building this driver on arm64 gives this warning:
>   drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error: 
> return expression in void function
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c 
> b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
> index 0974b9a7a584..0861842b2dfc 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
> @@ -425,9 +425,9 @@ unsigned int exynos3250_jpeg_get_int_status(void __iomem 
> *regs)
>  }
>  
>  void exynos3250_jpeg_clear_int_status(void __iomem *regs,
> - unsigned int value)
> +   unsigned int value)
>  {
> - return writel(value, regs + EXYNOS3250_JPGINTST);
> + writel(value, regs + EXYNOS3250_JPGINTST);
>  }
>  
>  unsigned int exynos3250_jpeg_operating(void __iomem *regs)
> 

Reviewed-by: Jacek Anaszewski 

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v2 01/12] media: ov5640: Add auto-focus feature

[Maxime Ripard]

On Thu, Apr 19, 2018 at 01:36:39PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
> 
> Thank you for the patch.
> 
> On Monday, 16 April 2018 15:36:50 EEST Maxime Ripard wrote:
> > From: Mylène Josserand 
> > 
> > Add the auto-focus ENABLE/DISABLE feature as V4L2 control.
> > Disabled by default.
> > 
> > Signed-off-by: Mylène Josserand 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/media/i2c/ov5640.c | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > index 852026baa2e7..a33e45f8e2b0 100644
> > --- a/drivers/media/i2c/ov5640.c
> > +++ b/drivers/media/i2c/ov5640.c
> > @@ -82,8 +82,9 @@
> >  #define OV5640_REG_POLARITY_CTRL00 0x4740
> >  #define OV5640_REG_MIPI_CTRL00 0x4800
> >  #define OV5640_REG_DEBUG_MODE  0x4814
> > -#define OV5640_REG_ISP_FORMAT_MUX_CTRL 0x501f
> > +#define OV5640_REG_ISP_CTRL03  0x5003
> >  #define OV5640_REG_PRE_ISP_TEST_SET1   0x503d
> > +#define OV5640_REG_ISP_FORMAT_MUX_CTRL 0x501f
> >  #define OV5640_REG_SDE_CTRL0   0x5580
> >  #define OV5640_REG_SDE_CTRL1   0x5581
> >  #define OV5640_REG_SDE_CTRL3   0x5583
> > @@ -186,6 +187,7 @@ struct ov5640_ctrls {
> > struct v4l2_ctrl *auto_gain;
> > struct v4l2_ctrl *gain;
> > };
> > +   struct v4l2_ctrl *auto_focus;
> > struct v4l2_ctrl *brightness;
> > struct v4l2_ctrl *saturation;
> > struct v4l2_ctrl *contrast;
> > @@ -2155,6 +2157,12 @@ static int ov5640_set_ctrl_test_pattern(struct
> > ov5640_dev *sensor, int value) 0xa4, value ? 0xa4 : 0);
> >  }
> > 
> > +static int ov5640_set_ctrl_focus(struct ov5640_dev *sensor, int value)
> > +{
> > +   return ov5640_mod_reg(sensor, OV5640_REG_ISP_CTRL03,
> > + BIT(1), value ? BIT(1) : 0);
> 
> According to the datasheet, bit 1 in register 0x5003 is "Draw window for AFC 
> enable". The draw window module is further documented as being "used to 
> display a window on top of live video. It is usually used by autofocus to 
> display a focus window". Are you sure the bit controls the autofocus itself ?
> 
> Furthermore, do all 0V5640 camera modules include a VCM ?

Hmmm, double checking in the datasheet, it indeed looks like this is
not what we want here. And I haven't found something to do this. I'll
drop this patch.

Thanks!
Maxime

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

Re: [PATCH v2 02/12] media: ov5640: Add light frequency control

[Maxime Ripard]

Hi Laurent,

On Thu, Apr 19, 2018 at 12:44:18PM +0300, Laurent Pinchart wrote:
> On Monday, 16 April 2018 15:36:51 EEST Maxime Ripard wrote:
> > From: Mylène Josserand 
> > 
> > Add the light frequency control to be able to set the frequency
> > to manual (50Hz or 60Hz) or auto.
> > 
> > Signed-off-by: Mylène Josserand 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/media/i2c/ov5640.c | 24 
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > index a33e45f8e2b0..28122341fc35 100644
> > --- a/drivers/media/i2c/ov5640.c
> > +++ b/drivers/media/i2c/ov5640.c
> > @@ -189,6 +189,7 @@ struct ov5640_ctrls {
> > };
> > struct v4l2_ctrl *auto_focus;
> > struct v4l2_ctrl *brightness;
> > +   struct v4l2_ctrl *light_freq;
> > struct v4l2_ctrl *saturation;
> > struct v4l2_ctrl *contrast;
> > struct v4l2_ctrl *hue;
> > @@ -2163,6 +2164,21 @@ static int ov5640_set_ctrl_focus(struct ov5640_dev
> > *sensor, int value) BIT(1), value ? BIT(1) : 0);
> >  }
> > 
> > +static int ov5640_set_ctl_light_freq(struct ov5640_dev *sensor, int value)
> 
> To stay consistent with the other functions, I propose calling this 
> ov5640_set_ctrl_light_freq().
> 
> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 

Consider it fixed in the next iteration, thanks!
Maxime

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

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

[Mauro Carvalho Chehab]

This driver depends on FB_VIA for lots of things. Provide stubs
for the functions it needs, in order to allow building it with
COMPILE_TEST outside x86 architecture.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e3229f7baed1..abaaed98a044 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -15,7 +15,7 @@ source "drivers/media/platform/marvell-ccic/Kconfig"
 
 config VIDEO_VIA_CAMERA
tristate "VIAFB camera controller support"
-   depends on FB_VIA
+   depends on FB_VIA || COMPILE_TEST
select VIDEOBUF_DMA_SG
select VIDEO_OV7670
help
diff --git a/drivers/media/platform/via-camera.c 
b/drivers/media/platform/via-camera.c
index e9a02639554b..4ab1695b33af 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -27,7 +27,10 @@
 #include 
 #include 
 #include 
+
+#ifdef CONFIG_FB_VIA
 #include 
+#endif
 
 #include "via-camera.h"
 
@@ -1283,6 +1286,11 @@ static bool viacam_serial_is_enabled(void)
struct pci_bus *pbus = pci_find_bus(0, 0);
u8 cbyte;
 
+#ifdef CONFIG_FB_VIA
+   if (!machine_is_olpc())
+   return false;
+#endif
+
if (!pbus)
return false;
pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN,
@@ -1343,7 +1351,7 @@ static int viacam_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   if (machine_is_olpc() && viacam_serial_is_enabled())
+   if (viacam_serial_is_enabled())
return -EBUSY;
 
/*
diff --git a/include/linux/via-core.h b/include/linux/via-core.h
index 9c21cdf3e3b3..ced4419baef8 100644
--- a/include/linux/via-core.h
+++ b/include/linux/via-core.h
@@ -70,8 +70,12 @@ struct viafb_pm_hooks {
void *private;
 };
 
+#ifdef CONFIG_FB_VIA
 void viafb_pm_register(struct viafb_pm_hooks *hooks);
 void viafb_pm_unregister(struct viafb_pm_hooks *hooks);
+#else
+static inline void viafb_pm_register(struct viafb_pm_hooks *hooks) {}
+#endif /* CONFIG_FB_VIA */
 #endif /* CONFIG_PM */
 
 /*
@@ -113,8 +117,13 @@ struct viafb_dev {
  * Interrupt management.
  */
 
+#ifdef CONFIG_FB_VIA
 void viafb_irq_enable(u32 mask);
 void viafb_irq_disable(u32 mask);
+#else
+static inline void viafb_irq_enable(u32 mask) {}
+static inline void viafb_irq_disable(u32 mask) {}
+#endif
 
 /*
  * The global interrupt control register and its bits.
@@ -157,10 +166,18 @@ void viafb_irq_disable(u32 mask);
 /*
  * DMA management.
  */
+#ifdef CONFIG_FB_VIA
 int viafb_request_dma(void);
 void viafb_release_dma(void);
 /* void viafb_dma_copy_out(unsigned int offset, dma_addr_t paddr, int len); */
 int viafb_dma_copy_out_sg(unsigned int offset, struct scatterlist *sg, int 
nsg);
+#else
+static inline int viafb_request_dma(void) { return 0; }
+static inline void viafb_release_dma(void) {}
+static inline int viafb_dma_copy_out_sg(unsigned int offset,
+   struct scatterlist *sg, int nsg)
+{ return 0; }
+#endif
 
 /*
  * DMA Controller registers.
diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
index 8281aea3dd6d..b5a96cf7a874 100644
--- a/include/linux/via-gpio.h
+++ b/include/linux/via-gpio.h
@@ -8,7 +8,11 @@
 #ifndef __VIA_GPIO_H__
 #define __VIA_GPIO_H__
 
+#ifdef CONFIG_FB_VIA
 extern int viafb_gpio_lookup(const char *name);
 extern int viafb_gpio_init(void);
 extern void viafb_gpio_exit(void);
+#else
+static inline int viafb_gpio_lookup(const char *name) { return 0; }
+#endif
 #endif
diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
index 44532e468c05..209bff950e22 100644
--- a/include/linux/via_i2c.h
+++ b/include/linux/via_i2c.h
@@ -32,6 +32,7 @@ struct via_i2c_stuff {
 };
 
 
+#ifdef CONFIG_FB_VIA
 int viafb_i2c_readbyte(u8 adap, u8 slave_addr, u8 index, u8 *pdata);
 int viafb_i2c_writebyte(u8 adap, u8 slave_addr, u8 index, u8 data);
 int viafb_i2c_readbytes(u8 adap, u8 slave_addr, u8 index, u8 *buff, int 
buff_len);
@@ -39,4 +40,9 @@ struct i2c_adapter *viafb_find_i2c_adapter(enum 
viafb_i2c_adap which);
 
 extern int viafb_i2c_init(void);
 extern void viafb_i2c_exit(void);
+#else
+static inline
+struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which)
+{ return NULL; }
+#endif
 #endif /* __VIA_I2C_H__ */

[PATCH] media: s5p-jpeg: don't return a value on a void function

[Mauro Carvalho Chehab]

Building this driver on arm64 gives this warning:
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error: 
return expression in void function

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
index 0974b9a7a584..0861842b2dfc 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
@@ -425,9 +425,9 @@ unsigned int exynos3250_jpeg_get_int_status(void __iomem 
*regs)
 }
 
 void exynos3250_jpeg_clear_int_status(void __iomem *regs,
-   unsigned int value)
+ unsigned int value)
 {
-   return writel(value, regs + EXYNOS3250_JPGINTST);
+   writel(value, regs + EXYNOS3250_JPGINTST);
 }
 
 unsigned int exynos3250_jpeg_operating(void __iomem *regs)
-- 
2.14.3

Re: [PATCH 2/3] media: ov5640: add PIXEL_RATE and LINK_FREQ controls

[Maxime Ripard]

On Fri, Apr 20, 2018 at 04:29:42PM +0200, Daniel Mack wrote:
> Hi,
> 
> On Friday, April 20, 2018 04:15 PM, Maxime Ripard wrote:
> > On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:
> 
> >>  struct ov5640_ctrls {
> >>struct v4l2_ctrl_handler handler;
> >> +  struct {
> >> +  struct v4l2_ctrl *link_freq;
> >> +  struct v4l2_ctrl *pixel_rate;
> >> +  };
> >>struct {
> >>struct v4l2_ctrl *auto_exp;
> >>struct v4l2_ctrl *exposure;
> >> @@ -732,6 +752,8 @@ static const struct ov5640_mode_info 
> >> ov5640_mode_init_data = {
> >>.dn_mode= SUBSAMPLING,
> >>.width  = 640,
> >>.height = 480,
> >> +  .pixel_rate = 2776,
> >> +  .link_freq_idx  = OV5640_LINK_FREQ_111,
> > 
> > I'm not sure where this is coming from, but on a parallel sensor I
> > have a quite different pixel rate.
> 
> Ah, interesting. What exactly do you mean by 'parallel'? What kind of
> module is that, and what are your pixel rates?

An RGB bus, or MIPI-DPI, or basically a pixel clock + 1 line for each
bit. The sensor can operate using both that bus and a MIPI-CSI2 one.

You have the list of pixel rates in the patch I've linked before:
https://patchwork.linuxtv.org/patch/48710/

There's one pixel sent per clock cycle, so the pixel rate is the same
than the clock rate.

Maxime

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

[PATCH 1/1] media: nec-decoder: remove trailer_space state

[Vladislav Zhurba]

From: Daniel Fu 

Remove STATE_TRAILER_SPACE from state machine.
Causing 2 issue:
- can not decode the keycode, if it didn't following with
  another keycode/repeat code
- will generate one more code in current logic.
  i.e. key_right + repeat code + key_left + repeat code.
  expect: key_right, key_left.
  Result: key_right, key_right, key_right.
  Reason: when receive repeat code of key_right, state machine will
  stay in STATE_TRAILER_SPACE state, then wait for a new interrupt,
  if an interrupt came after keyup_timer, then will generate another
  fake key.

According to the NEC protocol, it don't need a trailer space. Remove it.

Signed-off-by: Daniel Fu 
Signed-off-by: Vladislav Zhurba 
---
 drivers/media/rc/ir-nec-decoder.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/media/rc/ir-nec-decoder.c 
b/drivers/media/rc/ir-nec-decoder.c
index 21647b809e6f..760b66affd1a 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -128,16 +128,6 @@ static int ir_nec_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
if (!eq_margin(ev.duration, NEC_TRAILER_PULSE, NEC_UNIT / 2))
break;
 
-   data->state = STATE_TRAILER_SPACE;
-   return 0;
-
-   case STATE_TRAILER_SPACE:
-   if (ev.pulse)
-   break;
-
-   if (!geq_margin(ev.duration, NEC_TRAILER_SPACE, NEC_UNIT / 2))
-   break;
-
if (data->count == NEC_NBITS) {
address = bitrev8((data->bits >> 24) & 0xff);
not_address = bitrev8((data->bits >> 16) & 0xff);
-- 
2.16.2

[PATCH 1/1] media: rc: Add NVIDIA IR keymapping

[Vladislav Zhurba]

From: Jun Yan 

Add keymap with NEC and SONY12 protocol for NVIDIA IR

Signed-off-by: Jun Yan 
Signed-off-by: marting 
Signed-off-by: Daniel Fu 
Signed-off-by: Vladislav Zhurba 
---
 drivers/media/rc/keymaps/Makefile|  2 +
 drivers/media/rc/keymaps/rc-nvidia-nec.c | 66 
 drivers/media/rc/keymaps/rc-nvidia.c | 66 
 include/media/rc-map.h   |  2 +
 4 files changed, 136 insertions(+)
 create mode 100644 drivers/media/rc/keymaps/rc-nvidia-nec.c
 create mode 100644 drivers/media/rc/keymaps/rc-nvidia.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index d6b913a3032d..1d08500462fd 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -75,6 +75,8 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-nec-terratec-cinergy-xs.o \
rc-norwood.o \
rc-npgtech.o \
+   rc-nvidia.o \
+   rc-nvidia-nec.o \
rc-pctv-sedna.o \
rc-pinnacle-color.o \
rc-pinnacle-grey.o \
diff --git a/drivers/media/rc/keymaps/rc-nvidia-nec.c 
b/drivers/media/rc/keymaps/rc-nvidia-nec.c
new file mode 100644
index ..c910a2a683f6
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-nvidia-nec.c
@@ -0,0 +1,66 @@
+/* Keytable for NVIDIA Remote Controller
+ *
+ * Copyright (c) 2014-2018, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+#include 
+#include 
+
+static struct rc_map_table foster_table[] = {
+   { 0x807e12, KEY_VOLUMEUP },
+   { 0x807e15, KEY_VOLUMEDOWN },
+   { 0x807e0c, KEY_UP },
+   { 0x807e0e, KEY_DOWN },
+   { 0x807e0b, KEY_LEFT },
+   { 0x807e0d, KEY_RIGHT },
+   { 0x807e09, KEY_HOMEPAGE },
+   { 0x807e06, KEY_POWER },
+   { 0x807e03, KEY_SELECT },
+   { 0x807e02, KEY_BACK },
+   { 0x807e14, KEY_MUTE },
+   { 0x807e20, KEY_PLAYPAUSE },
+   { 0x807e11, KEY_PLAYCD },
+   { 0x807e08, KEY_PAUSECD },
+   { 0x807e07, KEY_STOP },
+   { 0x807e0f, KEY_FASTFORWARD },
+   { 0x807e0a, KEY_REWIND },
+   { 0x807e41, KEY_SLEEP },
+   { 0x807e45, KEY_WAKEUP },
+};
+
+static struct rc_map_list nvidia_map = {
+   .map = {
+   .scan = foster_table,
+   .size = ARRAY_SIZE(foster_table),
+   .rc_type = RC_TYPE_NEC,
+   .name = RC_MAP_NVIDIA_NEC,
+   }
+};
+
+static int __init init_rc_map_nvidia(void)
+{
+   return rc_map_register(_map);
+}
+
+static void __exit exit_rc_map_nvidia(void)
+{
+   rc_map_unregister(_map);
+}
+
+module_init(init_rc_map_nvidia);
+module_exit(exit_rc_map_nvidia);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Daniel Fu ");
diff --git a/drivers/media/rc/keymaps/rc-nvidia.c 
b/drivers/media/rc/keymaps/rc-nvidia.c
new file mode 100644
index ..9767d85a6c9e
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-nvidia.c
@@ -0,0 +1,66 @@
+/* Keytable for NVIDIA Remote Controller
+ *
+ * Copyright (c) 2014-2018, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+#include 
+#include 
+
+static struct rc_map_table foster_table[] = {
+   { 0x10009, KEY_0 },
+   { 0x1, KEY_1 },
+   { 0x10001, KEY_2 },
+   { 0x10002, KEY_3 },
+   { 0x10003, KEY_4 },
+   { 0x10004, KEY_5 },
+   { 0x10005, KEY_6 },
+   { 0x10006, KEY_7 },
+   { 0x10007, KEY_8 },
+   { 0x10008, KEY_9 },
+   { 0x10012, KEY_VOLUMEUP },
+   { 0x10013, KEY_VOLUMEDOWN },
+   { 0x10010, KEY_CHANNELUP },
+   { 

[PATCH 0/1] Add two IR keymaps for NVIDIA devices

[Vladislav Zhurba]

Adds two IR keymaps for NVIDIA devices.
The RC types are SONY12 and NEC.

Jun Yan (1):
  media: rc: Add NVIDIA IR keymapping

 drivers/media/rc/keymaps/Makefile|  2 +
 drivers/media/rc/keymaps/rc-nvidia-nec.c | 66 
 drivers/media/rc/keymaps/rc-nvidia.c | 66 
 include/media/rc-map.h   |  2 +
 4 files changed, 136 insertions(+)
 create mode 100644 drivers/media/rc/keymaps/rc-nvidia-nec.c
 create mode 100644 drivers/media/rc/keymaps/rc-nvidia.c

-- 
2.17.0

[PATCH 4/7] media: ipu3: allow building it with COMPILE_TEST on non-x86 archs

[Mauro Carvalho Chehab]

Despite depending on ACPI, this driver builds fine on non-x86
archtecture with COMPILE_TEST, as it doesn't depend on
ACPI-specific functions/structs.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/intel/ipu3/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe277d2..45cf99a512e4 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -2,10 +2,9 @@ config VIDEO_IPU3_CIO2
tristate "Intel ipu3-cio2 driver"
depends on VIDEO_V4L2 && PCI
depends on VIDEO_V4L2_SUBDEV_API
-   depends on X86 || COMPILE_TEST
+   depends on (X86 && ACPI) || COMPILE_TEST
depends on MEDIA_CONTROLLER
depends on HAS_DMA
-   depends on ACPI
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
 
-- 
2.14.3

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

[Mauro Carvalho Chehab]

Add stubs for omapfb_dss.h, in the case it is included by
some driver when CONFIG_FB_OMAP2 is not defined, with can
happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/video/omapfb_dss.h | 54 --
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index 1d38901d599d..e9775144ff3b 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -774,6 +774,12 @@ struct omap_dss_driver {
const struct hdmi_avi_infoframe *avi);
 };
 
+#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
+
+typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
+
+#ifdef CONFIG_FB_OMAP2
+
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
@@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device 
*dssdev);
 
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev);
 void omap_dss_put_device(struct omap_dss_device *dssdev);
-#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
int (*match)(struct omap_dss_device *dssdev, void *data));
@@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct 
omap_dss_device *dssdev);
 void omapdss_default_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
 
-typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 
@@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node 
*parent);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
+#else
+
+static inline enum omapdss_version omapdss_get_version(void)
+{ return OMAPDSS_VER_UNKNOWN; };
+
+static inline bool omapdss_is_initialized(void)
+{ return false; };
+
+static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
+ void *arg, u32 mask)
+{ return 0; };
+
+static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
+   void *arg, u32 mask)
+{ return 0; };
+
+static inline struct omap_dss_device
+*omap_dss_get_device(struct omap_dss_device *dssdev)
+{ return NULL; };
+
+static inline struct omap_dss_device
+*omap_dss_get_next_device(struct omap_dss_device *from)
+{return NULL; };
+
+static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
+
+static inline int omapdss_compat_init(void)
+{ return 0; };
+
+static inline void omapdss_compat_uninit(void) {};
+
+static inline int omap_dss_get_num_overlay_managers(void)
+{ return 0; };
+
+static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int 
num)
+{ return NULL; };
+
+static inline int omap_dss_get_num_overlays(void)
+{ return 0; };
+
+static inline struct omap_overlay *omap_dss_get_overlay(int num)
+{ return NULL; };
+
+
+#endif /* FB_OMAP2 */
+
 
 #endif /* __OMAPFB_DSS_H */
-- 
2.14.3

[PATCH 0/7] Enable most media drivers to build on ARM

[Mauro Carvalho Chehab]

Right now, all media drivers build successfully with COMPILE_TEST on x86,
on both i386 and x86_64. Yet, several drivers there don't build on other
archs.

I don't need myself to build all drivers outside x86, but others could
find it useful. It also relps spreading COMPILE_TEST builds, with sounds
a good idea, as more developers may be seeing issues and submiting 
us patches.

So, this patch series makes most of them to be built elsewhere (tested
only with ARM with allyesconfig). The only two media drivers that don't build 
on such conditions are:

1) media/staging/atomisp: it uses several ACPI bits that no other media
driver requires (including Intel IPU3);

2) radio-miropcm20: This device depnds on ISA_DMA_API, with is available only
for a few non-Intel architectures.

In other words, the following symbols aren't enabled with allyesconfig:

INTEL_ATOMISP VIDEO_ATOMISP
VIDEO_ATOMISP_MSRLIST_HELPER VIDEO_ATOMISP_MT9M114
VIDEO_ATOMISP_GC0310  VIDEO_ATOMISP_GC2235 
VIDEO_ATOMISP_OV2722 VIDEO_ATOMISP_OV5693
VIDEO_ATOMISP_OV2680 VIDEO_ATOMISP_LM3554
RADIO_MIROPCM20

All patches in this series are available at:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=compile_test_v7

Mauro Carvalho Chehab (7):
  asm-generic, media: allow COMPILE_TEST with virt_to_bus
  media: meye: allow building it with COMPILE_TEST on non-x86
  media: rc: allow build pnp-dependent drivers with COMPILE_TEST
  media: ipu3: allow building it with COMPILE_TEST on non-x86 archs
  omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
  media: omap2: allow building it with COMPILE_TEST && DRM_OMAP
  media: via-camera: allow build on non-x86 archs with COMPILE_TEST

 drivers/media/pci/intel/ipu3/Kconfig |  3 +-
 drivers/media/pci/meye/Kconfig   |  3 +-
 drivers/media/pci/sta2x11/Kconfig|  4 +--
 drivers/media/pci/zoran/Kconfig  |  3 +-
 drivers/media/platform/Kconfig   |  2 +-
 drivers/media/platform/omap/Kconfig  |  3 +-
 drivers/media/platform/via-camera.c  | 10 ++-
 drivers/media/rc/Kconfig | 10 +++
 include/asm-generic/io.h |  2 +-
 include/linux/sony-laptop.h  |  4 +++
 include/linux/via-core.h | 17 
 include/linux/via-gpio.h |  4 +++
 include/linux/via_i2c.h  |  5 
 include/video/omapfb_dss.h   | 54 ++--
 14 files changed, 107 insertions(+), 17 deletions(-)

-- 
2.14.3

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

[Mauro Carvalho Chehab]

This driver depends on FB_VIA for lots of things. Provide stubs
for the functions it needs, in order to allow building it with
COMPILE_TEST outside x86 architecture.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig  |  2 +-
 drivers/media/platform/via-camera.c | 10 +-
 include/linux/via-core.h| 17 +
 include/linux/via-gpio.h|  4 
 include/linux/via_i2c.h |  5 +
 5 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e3229f7baed1..abaaed98a044 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -15,7 +15,7 @@ source "drivers/media/platform/marvell-ccic/Kconfig"
 
 config VIDEO_VIA_CAMERA
tristate "VIAFB camera controller support"
-   depends on FB_VIA
+   depends on FB_VIA || COMPILE_TEST
select VIDEOBUF_DMA_SG
select VIDEO_OV7670
help
diff --git a/drivers/media/platform/via-camera.c 
b/drivers/media/platform/via-camera.c
index e9a02639554b..4ab1695b33af 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -27,7 +27,10 @@
 #include 
 #include 
 #include 
+
+#ifdef CONFIG_FB_VIA
 #include 
+#endif
 
 #include "via-camera.h"
 
@@ -1283,6 +1286,11 @@ static bool viacam_serial_is_enabled(void)
struct pci_bus *pbus = pci_find_bus(0, 0);
u8 cbyte;
 
+#ifdef CONFIG_FB_VIA
+   if (!machine_is_olpc())
+   return false;
+#endif
+
if (!pbus)
return false;
pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN,
@@ -1343,7 +1351,7 @@ static int viacam_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   if (machine_is_olpc() && viacam_serial_is_enabled())
+   if (viacam_serial_is_enabled())
return -EBUSY;
 
/*
diff --git a/include/linux/via-core.h b/include/linux/via-core.h
index 9c21cdf3e3b3..7aaee6a82392 100644
--- a/include/linux/via-core.h
+++ b/include/linux/via-core.h
@@ -70,8 +70,12 @@ struct viafb_pm_hooks {
void *private;
 };
 
+#ifdef CONFIG_FB_VIA
 void viafb_pm_register(struct viafb_pm_hooks *hooks);
 void viafb_pm_unregister(struct viafb_pm_hooks *hooks);
+#else
+void viafb_pm_register(struct viafb_pm_hooks *hooks) {}
+#endif /* CONFIG_FB_VIA */
 #endif /* CONFIG_PM */
 
 /*
@@ -113,8 +117,13 @@ struct viafb_dev {
  * Interrupt management.
  */
 
+#ifdef CONFIG_FB_VIA
 void viafb_irq_enable(u32 mask);
 void viafb_irq_disable(u32 mask);
+#else
+static inline void viafb_irq_enable(u32 mask) {}
+static inline void viafb_irq_disable(u32 mask) {}
+#endif
 
 /*
  * The global interrupt control register and its bits.
@@ -157,10 +166,18 @@ void viafb_irq_disable(u32 mask);
 /*
  * DMA management.
  */
+#ifdef CONFIG_FB_VIA
 int viafb_request_dma(void);
 void viafb_release_dma(void);
 /* void viafb_dma_copy_out(unsigned int offset, dma_addr_t paddr, int len); */
 int viafb_dma_copy_out_sg(unsigned int offset, struct scatterlist *sg, int 
nsg);
+#else
+static inline int viafb_request_dma(void) { return 0; }
+static inline void viafb_release_dma(void) {}
+static inline int viafb_dma_copy_out_sg(unsigned int offset,
+   struct scatterlist *sg, int nsg)
+{ return 0; }
+#endif
 
 /*
  * DMA Controller registers.
diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
index 8281aea3dd6d..b5a96cf7a874 100644
--- a/include/linux/via-gpio.h
+++ b/include/linux/via-gpio.h
@@ -8,7 +8,11 @@
 #ifndef __VIA_GPIO_H__
 #define __VIA_GPIO_H__
 
+#ifdef CONFIG_FB_VIA
 extern int viafb_gpio_lookup(const char *name);
 extern int viafb_gpio_init(void);
 extern void viafb_gpio_exit(void);
+#else
+static inline int viafb_gpio_lookup(const char *name) { return 0; }
+#endif
 #endif
diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
index 44532e468c05..61ae0e7e4576 100644
--- a/include/linux/via_i2c.h
+++ b/include/linux/via_i2c.h
@@ -32,6 +32,7 @@ struct via_i2c_stuff {
 };
 
 
+#ifdef CONFIG_FB_VIA
 int viafb_i2c_readbyte(u8 adap, u8 slave_addr, u8 index, u8 *pdata);
 int viafb_i2c_writebyte(u8 adap, u8 slave_addr, u8 index, u8 data);
 int viafb_i2c_readbytes(u8 adap, u8 slave_addr, u8 index, u8 *buff, int 
buff_len);
@@ -39,4 +40,8 @@ struct i2c_adapter *viafb_find_i2c_adapter(enum 
viafb_i2c_adap which);
 
 extern int viafb_i2c_init(void);
 extern void viafb_i2c_exit(void);
+#else
+struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which)
+{ return NULL; }
+#endif
 #endif /* __VIA_I2C_H__ */
-- 
2.14.3

[PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[Mauro Carvalho Chehab]

The virt_to_bus/bus_to_virt macros are arch-specific. Some
archs don't support it. Yet, as it is interesting to allow
doing compilation tests on non-ia32/ia64 archs, provide a
fallback for such archs.

While here, enable COMPILE_TEST for two media drivers that
depends on it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/sta2x11/Kconfig | 4 ++--
 drivers/media/pci/zoran/Kconfig   | 3 ++-
 include/asm-generic/io.h  | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index 7af3f1cbcea8..fb4b4c8ac430 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,10 +1,10 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
-   depends on STA2X11 || COMPILE_TEST
+   depends on (STA2X11 && VIRT_TO_BUS) || COMPILE_TEST
depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
-   depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
+   depends on PCI && VIDEO_V4L2
depends on VIDEO_V4L2_SUBDEV_API
depends on I2C
help
diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
index 39ec35bd21a5..5d2678a9e310 100644
--- a/drivers/media/pci/zoran/Kconfig
+++ b/drivers/media/pci/zoran/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_ZORAN
tristate "Zoran ZR36057/36067 Video For Linux"
-   depends on PCI && I2C_ALGOBIT && VIDEO_V4L2 && VIRT_TO_BUS
+   depends on PCI && I2C_ALGOBIT && VIDEO_V4L2
+   depends on VIRT_TO_BUS || COMPILE_TEST
depends on !ALPHA
help
  Say Y for support for MJPEG capture cards based on the Zoran
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 66d1d45fa2e1..f448129ad15c 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -1068,7 +1068,7 @@ static inline void unxlate_dev_mem_ptr(phys_addr_t phys, 
void *addr)
 }
 #endif
 
-#ifdef CONFIG_VIRT_TO_BUS
+#if defined(CONFIG_VIRT_TO_BUS) || defined(CONFIG_COMPILE_TEST)
 #ifndef virt_to_bus
 static inline unsigned long virt_to_bus(void *address)
 {
-- 
2.14.3

[PATCH 3/7] media: rc: allow build pnp-dependent drivers with COMPILE_TEST

[Mauro Carvalho Chehab]

The pnp header already provide enough stub to build those
drivers with COMPILE_TEST on non-x86 archs.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/rc/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index eb2c3b6eca7f..9a3b66c6700c 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -149,7 +149,7 @@ config RC_ATI_REMOTE
 
 config IR_ENE
tristate "ENE eHome Receiver/Transceiver (pnp id: ENE0100/ENE02xxx)"
-   depends on PNP
+   depends on PNP || COMPILE_TEST
depends on RC_CORE
---help---
   Say Y here to enable support for integrated infrared receiver
@@ -210,7 +210,7 @@ config IR_MCEUSB
 
 config IR_ITE_CIR
tristate "ITE Tech Inc. IT8712/IT8512 Consumer Infrared Transceiver"
-   depends on PNP
+   depends on PNP || COMPILE_TEST
depends on RC_CORE
---help---
   Say Y here to enable support for integrated infrared receivers
@@ -223,7 +223,7 @@ config IR_ITE_CIR
 
 config IR_FINTEK
tristate "Fintek Consumer Infrared Transceiver"
-   depends on PNP
+   depends on PNP || COMPILE_TEST
depends on RC_CORE
---help---
   Say Y here to enable support for integrated infrared receiver
@@ -257,7 +257,7 @@ config IR_MTK
 
 config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
-   depends on PNP
+   depends on PNP || COMPILE_TEST
depends on RC_CORE
---help---
   Say Y here to enable support for integrated infrared receiver
@@ -305,7 +305,7 @@ config IR_STREAMZAP
 
 config IR_WINBOND_CIR
tristate "Winbond IR remote control"
-   depends on X86 && PNP
+   depends on (X86 && PNP) || COMPILE_TEST
depends on RC_CORE
select NEW_LEDS
select LEDS_CLASS
-- 
2.14.3

[PATCH 6/7] media: omap2: allow building it with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Now that FB_OMAP has stubs, the omap2 media drivers can be
built on ARM with COMPILE_TEST && DRM_OMAP.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/omap/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap/Kconfig 
b/drivers/media/platform/omap/Kconfig
index 27343376f557..a414bcbb9b08 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -5,7 +5,8 @@ config VIDEO_OMAP2_VOUT_VRFB
 
 config VIDEO_OMAP2_VOUT
tristate "OMAP2/OMAP3 V4L2-Display driver"
-   depends on MMU && FB_OMAP2
+   depends on MMU
+   depends on FB_OMAP2 || COMPILE_TEST
depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
select VIDEOBUF_GEN
select VIDEOBUF_DMA_CONTIG
-- 
2.14.3

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

[Mauro Carvalho Chehab]

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

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

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

Re: [PATCH v3 03/13] media: v4l2: async: Add v4l2_async_notifier_add_subdev

[Steve Longerbeam]

Hi Sakari,


On 04/20/2018 05:24 AM, Sakari Ailus wrote:

Hi Steve,

Thanks for the patchset.

On Tue, Mar 20, 2018 at 05:37:19PM -0700, Steve Longerbeam wrote:

v4l2_async_notifier_add_subdev() adds an asd to the notifier. It checks
that the asd's match_type is valid and that no other equivalent asd's
have already been added to this notifier's asd list, or to other
registered notifier's waiting or done lists, and increments num_subdevs.

v4l2_async_notifier_add_subdev() does not make use of the notifier subdevs
array, otherwise it would have to re-allocate the array every time the
function was called. In place of the subdevs array, the function adds
the asd to a new master asd_list. The function will return error with a
WARN() if it is ever called with the subdevs array allocated.

In v4l2_async_notifier_has_async_subdev(), __v4l2_async_notifier_register(),
and v4l2_async_notifier_cleanup(), alternatively operate on the subdevs
array or a non-empty notifier->asd_list.

I do agree with the approach, but this patch leaves the remaining users of
the subdevs array in the notifier intact. Could you rework them to use the
v4l2_async_notifier_add_subdev() as well?

There seem to be just a few of them --- exynos4-is and rcar_drif.


I count more than a few :)

% cd drivers/media && grep -l -r --include "*.[ch]" 
'notifier[\.\-]>*subdevs[   ]*='

v4l2-core/v4l2-async.c
platform/pxa_camera.c
platform/ti-vpe/cal.c
platform/exynos4-is/media-dev.c
platform/qcom/camss-8x16/camss.c
platform/soc_camera/soc_camera.c
platform/atmel/atmel-isi.c
platform/atmel/atmel-isc.c
platform/stm32/stm32-dcmi.c
platform/davinci/vpif_capture.c
platform/davinci/vpif_display.c
platform/renesas-ceu.c
platform/am437x/am437x-vpfe.c
platform/xilinx/xilinx-vipp.c
platform/rcar_drif.c


So not including v4l2-core, the list is:

pxa_camera
ti-vpe
exynos4-is
qcom
soc_camera
atmel
stm32
davinci
renesas-ceu
am437x
xilinx
rcar_drif


Given such a large list of the users of the notifier->subdevs array,
I think this should be done is two steps: submit this patchset first,
that keeps the backward compatibility, and then a subsequent patchset
that converts all drivers to use v4l2_async_notifier_add_subdev(), at
which point the subdevs array can be removed from struct 
v4l2_async_notifier.


Or, do you still think this should be done all at once? I could add a
large patch to this patchset that does the conversion and removes
the subdevs array.

Steve





Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- add a NULL asd pointer check to v4l2_async_notifier_asd_valid().
Changes since v1:
- none
---
  drivers/media/v4l2-core/v4l2-async.c | 206 +++
  include/media/v4l2-async.h   |  22 
  2 files changed, 184 insertions(+), 44 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index b59bbac..7b7f7e2 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -366,16 +366,26 @@ static bool v4l2_async_notifier_has_async_subdev(
struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd,
unsigned int this_index)
  {
+   struct v4l2_async_subdev *asd_y;
unsigned int j;
  
  	lockdep_assert_held(_lock);
  
  	/* Check that an asd is not being added more than once. */

-   for (j = 0; j < this_index; j++) {
-   struct v4l2_async_subdev *asd_y = notifier->subdevs[j];
-
-   if (asd_equal(asd, asd_y))
-   return true;
+   if (notifier->subdevs) {
+   for (j = 0; j < this_index; j++) {
+   asd_y = notifier->subdevs[j];
+   if (asd_equal(asd, asd_y))
+   return true;
+   }
+   } else {
+   j = 0;
+   list_for_each_entry(asd_y, >asd_list, asd_list) {
+   if (j++ >= this_index)
+   break;
+   if (asd_equal(asd, asd_y))
+   return true;
+   }
}
  
  	/* Check that an asd does not exist in other notifiers. */

@@ -386,10 +396,46 @@ static bool v4l2_async_notifier_has_async_subdev(
return false;
  }
  
-static int __v4l2_async_notifier_register(struct v4l2_async_notifier *notifier)

+static int v4l2_async_notifier_asd_valid(struct v4l2_async_notifier *notifier,
+struct v4l2_async_subdev *asd,
+unsigned int this_index)
  {
struct device *dev =
notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL;
+
+   if (!asd)
+   return -EINVAL;
+
+   switch (asd->match_type) {
+   case V4L2_ASYNC_MATCH_CUSTOM:
+   case V4L2_ASYNC_MATCH_DEVNAME:
+   case V4L2_ASYNC_MATCH_I2C:
+   case V4L2_ASYNC_MATCH_FWNODE:
+   if 

Re: linux-next: Tree for Apr 20 (media/platform/marvell-ccic/)

[Randy Dunlap]

On 04/19/18 23:11, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20180419:
> 
> I have added a patch to the arm-current tree to fix build problems
> discovered overnight.
> 
> Non-merge commits (relative to Linus' tree): 1278
>  1324 files changed, 47025 insertions(+), 20625 deletions(-)
> 
> 
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log
> files in the Next directory.  Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig. And finally, a simple boot test of the powerpc
> pseries_le_defconfig kernel in qemu (with and without kvm enabled).
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 258 trees (counting Linus' and 44 trees of bug
> fix patches pending for the current merge release).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
> 
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
> 

on x86_64 (randconfig):

drivers/media/platform/marvell-ccic/mcam-core.o: In function `mccic_register':
mcam-core.c:(.text+0x1ce0): undefined reference to `__this_module'
drivers/media/platform/marvell-ccic/mcam-core.o:(.rodata+0x0): undefined 
reference to `__this_module'
drivers/media/platform/marvell-ccic/mcam-core.o:(__param+0x8): undefined 
reference to `__this_module'
drivers/media/platform/marvell-ccic/mcam-core.o:(__param+0x30): undefined 
reference to `__this_module'
drivers/media/platform/marvell-ccic/mcam-core.o:(__param+0x58): undefined 
reference to `__this_module'
drivers/media/platform/marvell-ccic/mcam-core.o:(__param+0x80): more undefined 
references to `__this_module' follow


Full randconfig file is attached.


-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.17.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_KASAN_SHADOW_OFFSET=0xdc00
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y

Re: [PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS

[Mark Brown]

On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:

> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.

Would it not make sense to try to apply everything en masse rather than
delaying?  I'm happy to apply the subsystem stuff but if it gets things
done quicker or more efficiently I'm also happy to have the lot merged
as one series.


signature.asc
Description: PGP signature

Re: [PATCH v3 06/13] media: platform: video-mux: Register a subdev notifier

[Steve Longerbeam]

Hi Hans,


On 04/20/2018 05:28 AM, Hans Verkuil wrote:

On 03/21/18 01:37, Steve Longerbeam wrote:

Parse neighbor remote devices on the video muxes input ports, add them to a
subdev notifier, and register the subdev notifier for the video mux, by
calling v4l2_async_register_fwnode_subdev().

Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- none
Changes since v1:
- add #include  for kcalloc() declaration.
---
  drivers/media/platform/video-mux.c | 36 +++-
  1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
index ee89ad7..b93b0af 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -21,8 +21,10 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
+#include 
  #include 
  
  struct video_mux {

@@ -193,6 +195,38 @@ static const struct v4l2_subdev_ops video_mux_subdev_ops = 
{
.video = _mux_subdev_video_ops,
  };
  
+static int video_mux_parse_endpoint(struct device *dev,

+   struct v4l2_fwnode_endpoint *vep,
+   struct v4l2_async_subdev *asd)
+{
+   /*
+* it's not an error if remote is missing on a video-mux
+* input port, return -ENOTCONN to skip this endpoint with
+* no error.
+*/
+   return fwnode_device_is_available(asd->match.fwnode) ? 0 : -ENOTCONN;
+}
+
+static int video_mux_async_register(struct video_mux *vmux,
+   unsigned int num_pads)
+{
+   unsigned int i, *ports;
+   int ret;
+
+   ports = kcalloc(num_pads - 1, sizeof(*ports), GFP_KERNEL);
+   if (!ports)
+   return -ENOMEM;
+   for (i = 0; i < num_pads - 1; i++)
+   ports[i] = i;
+
+   ret = v4l2_async_register_fwnode_subdev(
+   >subdev, sizeof(struct v4l2_async_subdev),
+   ports, num_pads - 1, video_mux_parse_endpoint);
+
+   kfree(ports);
+   return ret;
+}
+
  static int video_mux_probe(struct platform_device *pdev)
  {
struct device_node *np = pdev->dev.of_node;
@@ -258,7 +292,7 @@ static int video_mux_probe(struct platform_device *pdev)
  
  	vmux->subdev.entity.ops = _mux_ops;
  
-	return v4l2_async_register_subdev(>subdev);

+   return video_mux_async_register(vmux, num_pads);

I would prefer to change the last argument to 'num_pads - 1' and drop the ' - 1'
part in the video_mux_async_register() function. Perhaps renaming the num_pads
argument there to num_input_pads.


Yes makes sense. I will do that.

Steve

Re: [PATCH v3 02/13] media: v4l2: async: Allow searching for asd of any type

[Steve Longerbeam]

Hi Hans,


On 04/20/2018 05:22 AM, Hans Verkuil wrote:

On 03/21/18 01:37, Steve Longerbeam wrote:

Generalize v4l2_async_notifier_fwnode_has_async_subdev() to allow
searching for any type of async subdev, not just fwnodes. Rename to
v4l2_async_notifier_has_async_subdev() and pass it an asd pointer.

TODO: support asd compare with CUSTOM match type in asd_equal().

Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- code optimization in asd_equal(), and remove unneeded braces,
   suggested by Sakari Ailus.
Changes since v1:
- none
---
  drivers/media/v4l2-core/v4l2-async.c | 76 ++--
  1 file changed, 46 insertions(+), 30 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 2b08d03..b59bbac 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -124,6 +124,34 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
return NULL;
  }
  
+/* Compare two asd's for equivalence */

+static bool asd_equal(struct v4l2_async_subdev *asd_x,
+ struct v4l2_async_subdev *asd_y)
+{
+   if (asd_x->match_type != asd_y->match_type)
+   return false;
+
+   switch (asd_x->match_type) {
+   case V4L2_ASYNC_MATCH_DEVNAME:
+   return strcmp(asd_x->match.device_name,
+ asd_y->match.device_name) == 0;
+   case V4L2_ASYNC_MATCH_I2C:
+   return asd_x->match.i2c.adapter_id ==
+   asd_y->match.i2c.adapter_id &&
+   asd_x->match.i2c.address ==
+   asd_y->match.i2c.address;
+   case V4L2_ASYNC_MATCH_FWNODE:
+   return asd_x->match.fwnode == asd_y->match.fwnode;
+   case V4L2_ASYNC_MATCH_CUSTOM:
+   /* TODO */

This TODO suggests that this is needed for some driver(s) and that it
will be implemented later, but it seems more that nobody actually needs
this. If that's the case, then I'd just drop this case altogether.

Or do I misunderstand this comment?


No you are correct, I thought maybe this could be implemented
later. There are no platforms that make use of V4L2_ASYNC_MATCH_CUSTOM.
If you don't think there ever will be, I will just drop this.


Steve


+   return false;
+   default:
+   break;
+   }
+
+   return false;
+}
+
  /* Find the sub-device notifier registered by a sub-device driver. */
  static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
struct v4l2_subdev *sd)
@@ -308,29 +336,22 @@ static void v4l2_async_notifier_unbind_all_subdevs(
notifier->parent = NULL;
  }
  
-/* See if an fwnode can be found in a notifier's lists. */

-static bool __v4l2_async_notifier_fwnode_has_async_subdev(
-   struct v4l2_async_notifier *notifier, struct fwnode_handle *fwnode)
+/* See if an async sub-device can be found in a notifier's lists. */
+static bool __v4l2_async_notifier_has_async_subdev(
+   struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd)
  {
-   struct v4l2_async_subdev *asd;
+   struct v4l2_async_subdev *asd_y;
struct v4l2_subdev *sd;
  
-	list_for_each_entry(asd, >waiting, list) {

-   if (asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
-   continue;
-
-   if (asd->match.fwnode == fwnode)
+   list_for_each_entry(asd_y, >waiting, list)
+   if (asd_equal(asd, asd_y))
return true;
-   }
  
  	list_for_each_entry(sd, >done, async_list) {

if (WARN_ON(!sd->asd))
continue;
  
-		if (sd->asd->match_type != V4L2_ASYNC_MATCH_FWNODE)

-   continue;
-
-   if (sd->asd->match.fwnode == fwnode)
+   if (asd_equal(asd, sd->asd))
return true;
}
  
@@ -338,32 +359,28 @@ static bool __v4l2_async_notifier_fwnode_has_async_subdev(

  }
  
  /*

- * Find out whether an async sub-device was set up for an fwnode already or
+ * Find out whether an async sub-device was set up already or
   * whether it exists in a given notifier before @this_index.
   */
-static bool v4l2_async_notifier_fwnode_has_async_subdev(
-   struct v4l2_async_notifier *notifier, struct fwnode_handle *fwnode,
+static bool v4l2_async_notifier_has_async_subdev(
+   struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd,
unsigned int this_index)
  {
unsigned int j;
  
  	lockdep_assert_held(_lock);
  
-	/* Check that an fwnode is not being added more than once. */

+   /* Check that an asd is not being added more than once. */
for (j = 0; j < this_index; j++) {
-   struct v4l2_async_subdev *asd = notifier->subdevs[this_index];
-   struct v4l2_async_subdev *other_asd = notifier->subdevs[j];
+   struct v4l2_async_subdev *asd_y = 

Re: [PATCH v2 10/10] media: ov772x: avoid accessing registers under power saving mode

[Akinobu Mita]

2018-04-18 21:55 GMT+09:00 jacopo mondi :
>> @@ -898,8 +922,20 @@ static int ov772x_s_power(struct v4l2_subdev *sd, int 
>> on)
>>   /* If the power count is modified from 0 to != 0 or from != 0 to 0,
>>* update the power state.
>>*/
>> - if (priv->power_count == !on)
>> - ret = on ? ov772x_power_on(priv) : ov772x_power_off(priv);
>> + if (priv->power_count == !on) {
>> + if (on) {
>> + ret = ov772x_power_on(priv);
>> + /* Restore the controls */
>> + if (!ret)
>> + ret = ov772x_set_params(priv, priv->cfmt,
>> + priv->win);
>> + /* Restore the format and the frame rate */
>> + if (!ret)
>> + ret = __v4l2_ctrl_handler_setup(>hdl);
>
> frame interval is not listed in the sensor control list, it won't be
> restored if I'm not wrong...

The above two comments were swapped wrongly.  The ov772x_set_params()
actually restores the format, the frame rate.  It restores COM3,
COM8, and BDBASE registers, too.  So calling __v4l2_ctrl_handler_setup()
here is not needed.

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

[Russell King - ARM Linux]

On Fri, Apr 20, 2018 at 05:48:12PM +0200, Hans Verkuil wrote:
> On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote:
> > Hi Hans,
> > 
> > Any comments?
> 
> I have been traveling and haven't had time to look at this. Next week will
> be busy as well, but I expect to be able to look at it the week after that.

Well, that doesn't work because I won't be reading mail that week,
and I'll probably simply ignore the excessive backlog when I do
start reading mail again.

> I remember from the previous series that I couldn't test it with my BeagleBone
> Black board (the calibration gpio had to switch from in to out but it wasn't 
> allowed
> since it had an associated irq). That's still a problem?
> 
> I didn't see any changes in that area when I did a quick scan.

Correct, and unless you wish me to do the work for you (in which case
you can pay me) nothing is going to change on that front!  Seriously,
please do not expect me to add support for platforms I don't have
access to.  I'm just a volunteer for this, probably the same as you.

I don't think we ended up with an answer for that problem.  I don't
see that dropping the requested interrupt, using the GPIO, and then
re-requesting the interrupt is an option - how do we handle a failure
to re-request the interrupt?  Do we just ignore the error, or let DRM
stop working properly?

In any case, I don't have a working HDMI CEC-compliant setup anymore,
(no TV, just a HDMI monitor now) so I would rather _not_ change the
driver from its known-to-be-working state.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

[Hans Verkuil]

On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote:
> Hi Hans,
> 
> Any comments?

I have been traveling and haven't had time to look at this. Next week will
be busy as well, but I expect to be able to look at it the week after that.

I remember from the previous series that I couldn't test it with my BeagleBone
Black board (the calibration gpio had to switch from in to out but it wasn't 
allowed
since it had an associated irq). That's still a problem?

I didn't see any changes in that area when I did a quick scan.

Regards,

Hans

> 
> Thanks.
> 
> On Mon, Apr 09, 2018 at 01:16:32PM +0100, Russell King wrote:
>> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
>> but is also integrated into HDMI transceivers such as the TDA9989 and
>> TDA19989.
>>
>> The TDA9950 contains a command processor which handles retransmissions
>> and the low level bus protocol.  The driver just has to read and write
>> the messages, and handle error conditions.
>>
>> Signed-off-by: Russell King 
>> ---
>>  drivers/gpu/drm/i2c/Kconfig   |   5 +
>>  drivers/gpu/drm/i2c/Makefile  |   1 +
>>  drivers/gpu/drm/i2c/tda9950.c | 509 
>> ++
>>  include/linux/platform_data/tda9950.h |  16 ++
>>  4 files changed, 531 insertions(+)
>>  create mode 100644 drivers/gpu/drm/i2c/tda9950.c
>>  create mode 100644 include/linux/platform_data/tda9950.h
>>
>> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
>> index a6c92beb410a..3a232f5ff0a1 100644
>> --- a/drivers/gpu/drm/i2c/Kconfig
>> +++ b/drivers/gpu/drm/i2c/Kconfig
>> @@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
>>  help
>>Support for NXP Semiconductors TDA998X HDMI encoders.
>>  
>> +config DRM_I2C_NXP_TDA9950
>> +tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
>> +select CEC_NOTIFIER
>> +select CEC_CORE
>> +
>>  endmenu
>> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
>> index b20100c18ffb..a962f6f08568 100644
>> --- a/drivers/gpu/drm/i2c/Makefile
>> +++ b/drivers/gpu/drm/i2c/Makefile
>> @@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
>>  
>>  tda998x-y := tda998x_drv.o
>>  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
>> +obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
>> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
>> new file mode 100644
>> index ..3f7396caad48
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i2c/tda9950.c
>> @@ -0,0 +1,509 @@
>> +/*
>> + *  TDA9950 Consumer Electronics Control driver
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * The NXP TDA9950 implements the HDMI Consumer Electronics Control
>> + * interface.  The host interface is similar to a mailbox: the data
>> + * registers starting at REG_CDR0 are written to send a command to the
>> + * internal CPU, and replies are read from these registers.
>> + *
>> + * As the data registers represent a mailbox, they must be accessed
>> + * as a single I2C transaction.  See the TDA9950 data sheet for details.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +enum {
>> +REG_CSR = 0x00,
>> +CSR_BUSY = BIT(7),
>> +CSR_INT  = BIT(6),
>> +CSR_ERR  = BIT(5),
>> +
>> +REG_CER = 0x01,
>> +
>> +REG_CVR = 0x02,
>> +
>> +REG_CCR = 0x03,
>> +CCR_RESET = BIT(7),
>> +CCR_ON= BIT(6),
>> +
>> +REG_ACKH = 0x04,
>> +REG_ACKL = 0x05,
>> +
>> +REG_CCONR = 0x06,
>> +CCONR_ENABLE_ERROR = BIT(4),
>> +CCONR_RETRY_MASK = 7,
>> +
>> +REG_CDR0 = 0x07,
>> +
>> +CDR1_REQ = 0x00,
>> +CDR1_CNF = 0x01,
>> +CDR1_IND = 0x81,
>> +CDR1_ERR = 0x82,
>> +CDR1_IER = 0x83,
>> +
>> +CDR2_CNF_SUCCESS= 0x00,
>> +CDR2_CNF_OFF_STATE  = 0x80,
>> +CDR2_CNF_BAD_REQ= 0x81,
>> +CDR2_CNF_CEC_ACCESS = 0x82,
>> +CDR2_CNF_ARB_ERROR  = 0x83,
>> +CDR2_CNF_BAD_TIMING = 0x84,
>> +CDR2_CNF_NACK_ADDR  = 0x85,
>> +CDR2_CNF_NACK_DATA  = 0x86,
>> +};
>> +
>> +struct tda9950_priv {
>> +struct i2c_client *client;
>> +struct device *hdmi;
>> +struct cec_adapter *adap;
>> +struct tda9950_glue *glue;
>> +u16 addresses;
>> +struct cec_msg rx_msg;
>> +struct cec_notifier *notify;
>> +bool open;
>> +};
>> +
>> +static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, 
>> int cnt)
>> +{
>> +struct i2c_msg msg;
>> +u8 buf[cnt + 1];
>> +int ret;
>> +
>> +buf[0] = addr;
>> +memcpy(buf + 1, p, cnt);
>> +
>> +msg.addr = client->addr;
>> +msg.flags = 0;
>> +msg.len = cnt + 1;
>> +msg.buf = buf;
>> +
>> +dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
>> +
>> +ret = 

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

[Russell King - ARM Linux]

Hi Hans,

Any comments?

Thanks.

On Mon, Apr 09, 2018 at 01:16:32PM +0100, Russell King wrote:
> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
> but is also integrated into HDMI transceivers such as the TDA9989 and
> TDA19989.
> 
> The TDA9950 contains a command processor which handles retransmissions
> and the low level bus protocol.  The driver just has to read and write
> the messages, and handle error conditions.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/Kconfig   |   5 +
>  drivers/gpu/drm/i2c/Makefile  |   1 +
>  drivers/gpu/drm/i2c/tda9950.c | 509 
> ++
>  include/linux/platform_data/tda9950.h |  16 ++
>  4 files changed, 531 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/tda9950.c
>  create mode 100644 include/linux/platform_data/tda9950.h
> 
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index a6c92beb410a..3a232f5ff0a1 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
>   help
> Support for NXP Semiconductors TDA998X HDMI encoders.
>  
> +config DRM_I2C_NXP_TDA9950
> + tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
> + select CEC_NOTIFIER
> + select CEC_CORE
> +
>  endmenu
> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
> index b20100c18ffb..a962f6f08568 100644
> --- a/drivers/gpu/drm/i2c/Makefile
> +++ b/drivers/gpu/drm/i2c/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
>  
>  tda998x-y := tda998x_drv.o
>  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
> +obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
> new file mode 100644
> index ..3f7396caad48
> --- /dev/null
> +++ b/drivers/gpu/drm/i2c/tda9950.c
> @@ -0,0 +1,509 @@
> +/*
> + *  TDA9950 Consumer Electronics Control driver
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * The NXP TDA9950 implements the HDMI Consumer Electronics Control
> + * interface.  The host interface is similar to a mailbox: the data
> + * registers starting at REG_CDR0 are written to send a command to the
> + * internal CPU, and replies are read from these registers.
> + *
> + * As the data registers represent a mailbox, they must be accessed
> + * as a single I2C transaction.  See the TDA9950 data sheet for details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + REG_CSR = 0x00,
> + CSR_BUSY = BIT(7),
> + CSR_INT  = BIT(6),
> + CSR_ERR  = BIT(5),
> +
> + REG_CER = 0x01,
> +
> + REG_CVR = 0x02,
> +
> + REG_CCR = 0x03,
> + CCR_RESET = BIT(7),
> + CCR_ON= BIT(6),
> +
> + REG_ACKH = 0x04,
> + REG_ACKL = 0x05,
> +
> + REG_CCONR = 0x06,
> + CCONR_ENABLE_ERROR = BIT(4),
> + CCONR_RETRY_MASK = 7,
> +
> + REG_CDR0 = 0x07,
> +
> + CDR1_REQ = 0x00,
> + CDR1_CNF = 0x01,
> + CDR1_IND = 0x81,
> + CDR1_ERR = 0x82,
> + CDR1_IER = 0x83,
> +
> + CDR2_CNF_SUCCESS= 0x00,
> + CDR2_CNF_OFF_STATE  = 0x80,
> + CDR2_CNF_BAD_REQ= 0x81,
> + CDR2_CNF_CEC_ACCESS = 0x82,
> + CDR2_CNF_ARB_ERROR  = 0x83,
> + CDR2_CNF_BAD_TIMING = 0x84,
> + CDR2_CNF_NACK_ADDR  = 0x85,
> + CDR2_CNF_NACK_DATA  = 0x86,
> +};
> +
> +struct tda9950_priv {
> + struct i2c_client *client;
> + struct device *hdmi;
> + struct cec_adapter *adap;
> + struct tda9950_glue *glue;
> + u16 addresses;
> + struct cec_msg rx_msg;
> + struct cec_notifier *notify;
> + bool open;
> +};
> +
> +static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, 
> int cnt)
> +{
> + struct i2c_msg msg;
> + u8 buf[cnt + 1];
> + int ret;
> +
> + buf[0] = addr;
> + memcpy(buf + 1, p, cnt);
> +
> + msg.addr = client->addr;
> + msg.flags = 0;
> + msg.len = cnt + 1;
> + msg.buf = buf;
> +
> + dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
> +
> + ret = i2c_transfer(client->adapter, , 1);
> + if (ret < 0)
> + dev_err(>dev, "Error %d writing to cec:0x%x\n", ret, 
> addr);
> + return ret < 0 ? ret : 0;
> +}
> +
> +static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
> +{
> + tda9950_write_range(client, addr, , 1);
> +}
> +
> +static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int 
> cnt)
> +{
> + struct i2c_msg msg[2];
> + int ret;
> +
> + msg[0].addr = client->addr;
> + msg[0].flags = 0;
> + msg[0].len = 1;
> + msg[0].buf = 
> + msg[1].addr = client->addr;
> + msg[1].flags = I2C_M_RD;
> + 

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

[Daniel Vetter]

On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > > num_resources) which does the handling common to all drivers.
> > > A structure that contains
> > > 
> > > {page,offset,len} + {dma_addr+dma_len}
> > > 
> > > is not a good container for storing
> > > 
> > > {virt addr, dma_addr, len}
> > > 
> > > no matter what interface you build arond it.
> > 
> > Why not? I mean at least for my use case we actually don't need the virtual
> > address.
> 
> If you don't need the virtual address you need scatterlist even list.
> 
> > What we need is {dma_addr+dma_len} in a consistent interface which can come
> > from both {page,offset,len} as well as {resource, len}.
> 
> Ok.
> 
> > What I actually don't need is separate handling for system memory and
> > resources, but that would we get exactly when we don't use sg_table.
> 
> At the very lowest level they will need to be handled differently for
> many architectures, the questions is at what point we'll do the
> branching out.

Having at least struct page also in that list with (dma_addr_t, lenght)
pairs has a bunch of benefits for drivers in unifying buffer handling
code. You just pass that one single list around, use the dma_addr_t side
for gpu access (generally bashing it into gpu ptes). And the struct page
(if present) for cpu access, using kmap or vm_insert_*. We generally
ignore virt, if we do need a full mapping then we construct a vmap for
that buffer of our own.

If (and that would be serious amounts of work all over the tree, with lots
of drivers) we come up with a new struct for gpu buffers, then I'd also
add "force page alignement for everything" to the requirements list.
That's another mismatch we have, since gpu buffer objects (and dma-buf)
are always full pages. That mismatch motived the addition of the
page-oriented sg iterators.

So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best,
with struct page * being optional (if it's a resource, or something else
that the kernel core mm isn't aware of). But that only has benefits if we
really roll it out everywhere, in all the subsystems and drivers, since if
we don't we've made the struct pages ** <-> sgt conversion fun only worse
by adding a 3 representation of gpu buffer object backing storage.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

[Sergei Shtylyov]

On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:

> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
> 
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check.
> 
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
> 
> Signed-off-by: Geert Uytterhoeven 
[...]

Acked-by: Sergei Shtylyov 

MBR, Sergei

Re: [PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

On Thursday, April 05, 2018 04:29:42 PM Mauro Carvalho Chehab wrote:
> This driver builds cleanly with COMPILE_TEST, and it is
> needed in order to allow building drivers/media omap2
> driver.
> 
> So, change the logic there to allow building it.
> 
> Signed-off-by: Mauro Carvalho Chehab 

This change has broken build on OF=n && COMPILE_TEST=y configs:

https://patchwork.kernel.org/patch/10352465/

[ This is not a problem when compiling for OMAP2 because it depends
  on ARM Multiplatform support which (indirectly) selects OF. ]

Also I would really prefer that people won't merge fbdev related
patches without my ACK and I see this patch in -next coming from
one of your trees..

> ---
>  drivers/video/fbdev/omap2/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/omap2/Kconfig 
> b/drivers/video/fbdev/omap2/Kconfig
> index 0921c4de8407..82008699d253 100644
> --- a/drivers/video/fbdev/omap2/Kconfig
> +++ b/drivers/video/fbdev/omap2/Kconfig
> @@ -1,4 +1,4 @@
> -if ARCH_OMAP2PLUS
> +if ARCH_OMAP2PLUS || COMPILE_TEST
>  
>  source "drivers/video/fbdev/omap2/omapfb/Kconfig"

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

Re: [PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS

[Sergei Shtylyov]

On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:

> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is ARCH_RENESAS a more appropriate platform dependency than the legacy

   "ARCH_RENESAS is", no?

> ARCH_SHMOBILE, hence use the former.
> 
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.
> 
> Signed-off-by: Geert Uytterhoeven 
[...]

MBR, Sergei

Re: [PATCH 2/3] media: ov5640: add PIXEL_RATE and LINK_FREQ controls

[Daniel Mack]

Hi,

On Friday, April 20, 2018 04:15 PM, Maxime Ripard wrote:
> On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:

>>  struct ov5640_ctrls {
>>  struct v4l2_ctrl_handler handler;
>> +struct {
>> +struct v4l2_ctrl *link_freq;
>> +struct v4l2_ctrl *pixel_rate;
>> +};
>>  struct {
>>  struct v4l2_ctrl *auto_exp;
>>  struct v4l2_ctrl *exposure;
>> @@ -732,6 +752,8 @@ static const struct ov5640_mode_info 
>> ov5640_mode_init_data = {
>>  .dn_mode= SUBSAMPLING,
>>  .width  = 640,
>>  .height = 480,
>> +.pixel_rate = 2776,
>> +.link_freq_idx  = OV5640_LINK_FREQ_111,
> 
> I'm not sure where this is coming from, but on a parallel sensor I
> have a quite different pixel rate.

Ah, interesting. What exactly do you mean by 'parallel'? What kind of
module is that, and what are your pixel rates?

> I have a serie ongoing that tries to deal with this, hopefully in
> order to get rid of all the clock setup done in the initialiasation
> array.
> 
> See https://patchwork.linuxtv.org/patch/48710/ for the patch and
> https://www.spinics.net/lists/linux-media/msg132201.html for a
> discussion on what the clock tree might look like on a MIPI-CSI bus.

Okay, nice. Even better if this patch isn't needed in the end.


Thanks!
Daniel

Re: [PATCH 2/3] media: ov5640: add PIXEL_RATE and LINK_FREQ controls

[Maxime Ripard]

Hi,

On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:
> Add v4l2 controls to report the pixel and MIPI link rates of each mode.
> The camss camera subsystem needs them to set up the correct hardware
> clocks.
> 
> Tested on msm8016 based hardware.
> 
> Signed-off-by: Daniel Mack 
> ---
>  drivers/media/i2c/ov5640.c | 77 
> ++
>  1 file changed, 77 insertions(+)
> 
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 96f1564abdf5..78669ed386cd 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -91,6 +91,20 @@
>  #define OV5640_REG_SDE_CTRL5 0x5585
>  #define OV5640_REG_AVG_READOUT   0x56a1
>  
> +#define OV5640_LINK_FREQ_111 0
> +#define OV5640_LINK_FREQ_166 1
> +#define OV5640_LINK_FREQ_222 2
> +#define OV5640_LINK_FREQ_333 3
> +#define OV5640_LINK_FREQ_666 4
> +
> +static const s64 link_freq_menu_items[] = {
> + 11106,
> + 16660,
> + 22213,
> + 33220,
> + 66640,
> +};
> +
>  enum ov5640_mode_id {
>   OV5640_MODE_QCIF_176_144 = 0,
>   OV5640_MODE_QVGA_320_240,
> @@ -167,12 +181,18 @@ struct ov5640_mode_info {
>   enum ov5640_downsize_mode dn_mode;
>   u32 width;
>   u32 height;
> + u32 pixel_rate;
> + u32 link_freq_idx;
>   const struct reg_value *reg_data;
>   u32 reg_data_size;
>  };
>  
>  struct ov5640_ctrls {
>   struct v4l2_ctrl_handler handler;
> + struct {
> + struct v4l2_ctrl *link_freq;
> + struct v4l2_ctrl *pixel_rate;
> + };
>   struct {
>   struct v4l2_ctrl *auto_exp;
>   struct v4l2_ctrl *exposure;
> @@ -732,6 +752,8 @@ static const struct ov5640_mode_info 
> ov5640_mode_init_data = {
>   .dn_mode= SUBSAMPLING,
>   .width  = 640,
>   .height = 480,
> + .pixel_rate = 2776,
> + .link_freq_idx  = OV5640_LINK_FREQ_111,

I'm not sure where this is coming from, but on a parallel sensor I
have a quite different pixel rate.

I have a serie ongoing that tries to deal with this, hopefully in
order to get rid of all the clock setup done in the initialiasation
array.

See https://patchwork.linuxtv.org/patch/48710/ for the patch and
https://www.spinics.net/lists/linux-media/msg132201.html for a
discussion on what the clock tree might look like on a MIPI-CSI bus.

Feel free to step in the discussion.
Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH 3/3] media: ov5640: add support for xclk frequency control

[Maxime Ripard]

Hi,

On Fri, Apr 20, 2018 at 11:44:19AM +0200, Daniel Mack wrote:
> Allow setting the xclk rate via an optional 'clock-frequency' property in
> the device tree node.
> 
> Signed-off-by: Daniel Mack 
> ---
>  Documentation/devicetree/bindings/media/i2c/ov5640.txt |  2 ++
>  drivers/media/i2c/ov5640.c | 10 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
> index 8e36da0d8406..584bbc944978 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
> @@ -13,6 +13,8 @@ Optional Properties:
>  This is an active low signal to the OV5640.
>  - powerdown-gpios: reference to the GPIO connected to the powerdown pin,
>  if any. This is an active high signal to the OV5640.
> +- clock-frequency: frequency to set on the xclk input clock. The clock
> +is left untouched if this property is missing.

This can be done through assigned-clocks, right?

>  The device node must contain one 'port' child node for its digital output
>  video port, in accordance with the video interface bindings defined in
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 78669ed386cd..2d94d6dbda5d 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -2685,6 +2685,7 @@ static int ov5640_probe(struct i2c_client *client,
>   struct fwnode_handle *endpoint;
>   struct ov5640_dev *sensor;
>   struct v4l2_mbus_framefmt *fmt;
> + u32 freq;
>   int ret;
>  
>   sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
> @@ -2731,6 +2732,15 @@ static int ov5640_probe(struct i2c_client *client,
>   return PTR_ERR(sensor->xclk);
>   }
>  
> + ret = of_property_read_u32(dev->of_node, "clock-frequency", );
> + if (ret == 0) {
> + ret = clk_set_rate(sensor->xclk, freq);
> + if (ret) {
> + dev_err(dev, "could not set xclk frequency\n");
> + return ret;
> + }
> + }
> +

I'm wondering what the use case for that would be. The clock rate is
subject to various changes depending on the resolution and framerate
used, so that's very likely to change. Wouldn't we be better off to
simply try to change the rate at runtime, depending on those factors?

Maxime

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


signature.asc
Description: PGP signature

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

[Hans Verkuil]

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

Re: [PATCH v2 06/10] media: v4l: Add definition for Allwinner's MB32-tiled NV12 format

[Hans Verkuil]

On 04/19/18 17:45, Paul Kocialkowski wrote:
> This introduces support for Allwinner's MB32-tiled NV12 format, where
> each plane is divided into macroblocks of 32x32 pixels. Hence, the size
> of each plane has to be aligned to 32 bytes. The pixels inside each
> macroblock are coded as they would be if the macroblock was a single
> plane, line after line.
> 
> The MB32-tiled NV12 format is used by the video engine on Allwinner
> platforms: it is the default format for decoded frames (and the only one
> available in the oldest supported platforms).
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  include/uapi/linux/videodev2.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4b8336f7bcf0..43993a116e2b 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -669,6 +669,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 
> 16-bit */
>  #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
> compressed block mode  */
>  #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel 
> Planar Greyscale 10-bit and Depth 16-bit */
> +#define V4L2_PIX_FMT_MB32_NV12 v4l2_fourcc('M', 'N', '1', '2') /* Allwinner 
> NV12 in 32x32 macroblocks */
>  
>  /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits 
> unused */
>  #define V4L2_PIX_FMT_IPU3_SBGGR10v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 
> packed 10-bit BGGR bayer */
> 

Add an entry for this to v4l_fill_fmtdesc() in v4l2-ioctl.c.

It also needs to be documented in the spec.

Regards,

Hans

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

[Hans Verkuil]

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

As someone else already mentioned (I believe): avoid enums. Use __u16
instead.

> + __u8 f_code[2][2];
> +
> + __u8 intra_dc_precision;
> + __u8 picture_structure;
> + __u8 top_field_first;
> + __u8 frame_pred_frame_dct;
> + __u8 

Re: [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling

[Hans Verkuil]

On 04/19/18 17:41, Paul Kocialkowski wrote:
> When using the request API in the context of a m2m driver, the
> operations that come with a m2m run scheduling call in their
> (m2m-specific) ioctl handler are delayed until the request is queued
> (for instance, this includes queuing buffers and streamon).
> 
> Thus, the m2m run scheduling calls are not called in due time since the
> request AP's internal plumbing will (rightfully) use the relevant core
> functions directly instead of the ioctl handler.
> 
> This ends up in a situation where nothing happens if there is no
> run-scheduling ioctl called after queuing the request.
> 
> In order to circumvent the issue, a new media operation is introduced,
> called at the time of handling the media request queue ioctl. It gives
> m2m drivers a chance to schedule a m2m device run at that time.
> 
> The existing req_queue operation cannot be used for this purpose, since
> it is called with the request queue mutex held, that is eventually needed
> in the device_run call to apply relevant controls.

I'll need to think about this a bit more. I understand the problem so something
needs to be done. I would like to avoid adding yet another op, though.

Regards,

Hans

> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/media-request.c | 3 +++
>  include/media/media-device.h  | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index 415f7e31019d..28ac5ccfe6a2 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -157,6 +157,9 @@ static long media_request_ioctl_queue(struct 
> media_request *req)
>   media_request_get(req);
>   }
>  
> + if (mdev->ops->req_complete)
> + mdev->ops->req_complete(req);
> +
>   return ret;
>  }
>  
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 07e323c57202..c7dcf2079cc9 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -55,6 +55,7 @@ struct media_entity_notify {
>   * @req_alloc: Allocate a request
>   * @req_free: Free a request
>   * @req_queue: Queue a request
> + * @req_complete: Complete a request
>   */
>  struct media_device_ops {
>   int (*link_notify)(struct media_link *link, u32 flags,
> @@ -62,6 +63,7 @@ struct media_device_ops {
>   struct media_request *(*req_alloc)(struct media_device *mdev);
>   void (*req_free)(struct media_request *req);
>   int (*req_queue)(struct media_request *req);
> + void (*req_complete)(struct media_request *req);
>  };
>  
>  /**
> 

Re: [PATCH v2 03/10] videobuf2-core: Add helper to get buffer private data from media request

[Hans Verkuil]

On 04/19/18 17:41, Paul Kocialkowski wrote:
> When calling media operation driver callbacks related to media requests,
> only a pointer to the request itself is provided, which is insufficient
> to retrieve the driver's context. Since the driver context is usually
> set as vb2 queue private data and given that the core can determine
> which objects attached to the request are buffers, it is possible to
> extract the associated private data for the first buffer found.
> 
> This is required in order to access the current m2m context from m2m
> drivers' private data in the context of media request operation
> callbacks. More specifically, this allows scheduling m2m device runs
> from the newly-introduced request complete operation.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 15 +++
>  include/media/videobuf2-core.h  |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 13c9d9e243dd..6fa46bfc620f 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -1351,6 +1351,21 @@ bool vb2_core_request_has_buffers(struct media_request 
> *req)
>  }
>  EXPORT_SYMBOL_GPL(vb2_core_request_has_buffers);
>  
> +void *vb2_core_request_find_buffer_priv(struct media_request *req)
> +{
> + struct media_request_object *obj;
> + struct vb2_buffer *vb;
> +
> + obj = media_request_object_find(req, _core_req_ops, NULL);

This increases the object refcount but it is never decreased here.

> + if (!obj)
> + return NULL;
> +
> + vb = container_of(obj, struct vb2_buffer, req_obj);
> +
> + return vb2_get_drv_priv(vb->vb2_queue);

You need to add a media_request_object_put(obj); before returning here.

Regards,

Hans

> +}
> +EXPORT_SYMBOL_GPL(vb2_core_request_find_buffer_priv);
> +
>  int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb,
>struct media_request *req)
>  {
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 032bd1bec555..65c0cf6afb55 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -1153,4 +1153,5 @@ int vb2_verify_memory_type(struct vb2_queue *q,
>   enum vb2_memory memory, unsigned int type);
>  
>  bool vb2_core_request_has_buffers(struct media_request *req);
> +void *vb2_core_request_find_buffer_priv(struct media_request *req);
>  #endif /* _MEDIA_VIDEOBUF2_CORE_H */
> 

Re: [PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS

[Arnd Bergmann]

On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven
 wrote:
> Hi all,
>
> Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
> ARM SoCs.  This patch series completes the conversion, by:
>   1. Updating dependencies for drivers that weren't converted yet,
>   2. Removing the ARCH_SHMOBILE Kconfig symbols on ARM and ARM64.
>
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.

This all looks fine to me.

Acked-by: Arnd Bergmann 

  Arnd

Re: [PATCH v2 01/10] media: v4l2-ctrls: Add missing v4l2 ctrl unlock

[Hans Verkuil]

On 04/19/18 17:41, Paul Kocialkowski wrote:
> This adds a missing v4l2_ctrl_unlock call that is required to avoid
> deadlocks.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index f67e9f5531fa..ba05a8b9a095 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -3614,10 +3614,12 @@ void v4l2_ctrl_request_complete(struct media_request 
> *req,
>   continue;
>  
>   v4l2_ctrl_lock(ctrl);
> +
>   if (ref->req)
>   ptr_to_ptr(ctrl, ref->req->p_req, ref->p_req);
>   else
>   ptr_to_ptr(ctrl, ctrl->p_cur, ref->p_req);
> +
>   v4l2_ctrl_unlock(ctrl);
>   }
>  
> @@ -3677,8 +3679,11 @@ void v4l2_ctrl_request_setup(struct media_request *req,
>   }
>   }
>   }
> - if (!have_new_data)
> +
> + if (!have_new_data) {
> + v4l2_ctrl_unlock(master);
>   continue;
> + }

Oops! Thanks for finding this. I'll fold this into the relevant patch in my 
tree.

>  
>   for (i = 0; i < master->ncontrols; i++) {
>   if (master->cluster[i]) {
> 

Regards,

Hans

[PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol

[Geert Uytterhoeven]

All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
platform dependencies.  Hence finish the conversion from ARCH_SHMOBILE
to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").

Signed-off-by: Geert Uytterhoeven 
---
This depends on the previous patches in this series, hence the RFC.

JFTR, after this, the following symbols for drivers supporting only
Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
  - CONFIG_KEYBOARD_SH_KEYSC,
  - CONFIG_VIDEO_SH_VOU,
  - CONFIG_VIDEO_SH_MOBILE_CEU,
  - CONFIG_DRM_SHMOBILE[*],
  - CONFIG_FB_SH_MOBILE_MERAM.
(changes for a shmobile_defconfig .config)

[*] CONFIG_DRM_SHMOBILE has a dependency on ARM, but it was never wired
up.  From the use of sh_mobile_meram, I guess it was meant for
SH-Mobile AP4 on Mackerel or AP4EVB, which are long gone.
So the only remaining upstream platforms that could make use of it
are legacy SuperH SH-Mobile SoCs?
---
 arch/arm/mach-shmobile/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 96672da02f5f17b9..d892c5b52b6f5627 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -1,6 +1,3 @@
-config ARCH_SHMOBILE
-   bool
-
 config PM_RMOBILE
bool
select PM
@@ -30,7 +27,6 @@ menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
-   select ARCH_SHMOBILE
select ARM_GIC
select GPIOLIB
select HAVE_ARM_SCU if SMP
-- 
2.7.4

[PATCH/RFC 8/8] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

[Geert Uytterhoeven]

The Kconfig symbol for Renesas 64-bit ARM SoCs has always been
ARCH_RENESAS, with ARCH_SHMOBILE being selected to reuse drivers shared
with Renesas 32-bit ARM and/or Renesas SuperH SH-Mobile SoCs.

Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
32-bit SoCs.  Now all drivers for Renesas ARM SoCs have gained proper
ARCH_RENESAS platform dependencies, there is no longer a need to select
ARCH_SHMOBILE.

With ARCH_SHMOBILE gone, move the ARCH_RENESAS section up, to restore
alphabetical sort order.

Signed-off-by: Geert Uytterhoeven 
---
This depends on the driver patches in this series, hence the RFC.

JFTR, after this, the following symbols for drivers supporting only
Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
  - CONFIG_KEYBOARD_SH_KEYSC,
  - CONFIG_VIDEO_SH_VOU,
  - CONFIG_VIDEO_RENESAS_CEU,
  - CONFIG_FB_SH_MOBILE_MERAM.
(changes for a renesas_defconfig .config)
---
 arch/arm64/Kconfig.platforms | 42 +++---
 1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3a776..49d8ed1ab84766dd 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -145,31 +145,8 @@ config ARCH_REALTEK
  This enables support for the ARMv8 based Realtek chipsets,
  like the RTD1295.
 
-config ARCH_ROCKCHIP
-   bool "Rockchip Platforms"
-   select ARCH_HAS_RESET_CONTROLLER
-   select GPIOLIB
-   select PINCTRL
-   select PINCTRL_ROCKCHIP
-   select ROCKCHIP_TIMER
-   help
- This enables support for the ARMv8 based Rockchip chipsets,
- like the RK3368.
-
-config ARCH_SEATTLE
-   bool "AMD Seattle SoC Family"
-   help
- This enables support for AMD Seattle SOC Family
-
-config ARCH_SHMOBILE
-   bool
-
-config ARCH_SYNQUACER
-   bool "Socionext SynQuacer SoC Family"
-
 config ARCH_RENESAS
bool "Renesas SoC Platforms"
-   select ARCH_SHMOBILE
select PINCTRL
select PM
select PM_GENERIC_DOMAINS
@@ -220,6 +197,25 @@ config ARCH_R8A77995
help
  This enables support for the Renesas R-Car D3 SoC.
 
+config ARCH_ROCKCHIP
+   bool "Rockchip Platforms"
+   select ARCH_HAS_RESET_CONTROLLER
+   select GPIOLIB
+   select PINCTRL
+   select PINCTRL_ROCKCHIP
+   select ROCKCHIP_TIMER
+   help
+ This enables support for the ARMv8 based Rockchip chipsets,
+ like the RK3368.
+
+config ARCH_SEATTLE
+   bool "AMD Seattle SoC Family"
+   help
+ This enables support for AMD Seattle SOC Family
+
+config ARCH_SYNQUACER
+   bool "Socionext SynQuacer SoC Family"
+
 config ARCH_STRATIX10
bool "Altera's Stratix 10 SoCFPGA Family"
help
-- 
2.7.4

[PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS

[Geert Uytterhoeven]

Hi all,

Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
ARM SoCs.  This patch series completes the conversion, by:
  1. Updating dependencies for drivers that weren't converted yet,
  2. Removing the ARCH_SHMOBILE Kconfig symbols on ARM and ARM64.

The first 6 patches can be applied independently by subsystem
maintainers.
The last two patches depend on the first 6 patches, and are thus marked
RFC.

Thanks for your comments!

Geert Uytterhoeven (8):
  arm: shmobile: Change platform dependency to ARCH_RENESAS
  dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS
  [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
  sh_eth: Change platform check to CONFIG_ARCH_RENESAS
  staging: emxx_udc: Change platform dependency to ARCH_RENESAS
  ASoC: sh: Update menu title and platform dependency
  [RFC] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol
  [RFC] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

 arch/arm/Kconfig  |  2 +-
 arch/arm/Makefile |  2 +-
 arch/arm/mach-shmobile/Kconfig|  4 ---
 arch/arm64/Kconfig.platforms  | 42 +
 drivers/dma/sh/shdmac.c   | 50 +++
 drivers/media/platform/Kconfig|  2 +-
 drivers/net/ethernet/renesas/sh_eth.h |  2 +-
 drivers/staging/emxx_udc/Kconfig  |  2 +-
 sound/soc/sh/Kconfig  |  4 +--
 9 files changed, 47 insertions(+), 63 deletions(-)

-- 
2.7.4

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

[PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS

[Geert Uytterhoeven]

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency than the legacy
ARCH_SHMOBILE, hence use the former.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/Kconfig  | 2 +-
 arch/arm/Makefile | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f8e7f4b88fdd03..2d34c0a44877e85b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1467,7 +1467,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
int
default 2048 if ARCH_SOCFPGA
-   default 1024 if ARCH_BRCMSTB || ARCH_SHMOBILE || ARCH_TEGRA || \
+   default 1024 if ARCH_BRCMSTB || ARCH_RENESAS || ARCH_TEGRA || \
ARCH_ZYNQ
default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || \
SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e4e537f27339f7a1..a92f5a876d96839d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -212,7 +212,7 @@ machine-$(CONFIG_ARCH_S3C24XX)  += s3c24xx
 machine-$(CONFIG_ARCH_S3C64XX) += s3c64xx
 machine-$(CONFIG_ARCH_S5PV210) += s5pv210
 machine-$(CONFIG_ARCH_SA1100)  += sa1100
-machine-$(CONFIG_ARCH_SHMOBILE)+= shmobile
+machine-$(CONFIG_ARCH_RENESAS) += shmobile
 machine-$(CONFIG_ARCH_SIRF)+= prima2
 machine-$(CONFIG_ARCH_SOCFPGA) += socfpga
 machine-$(CONFIG_ARCH_STI) += sti
-- 
2.7.4

[PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

[Geert Uytterhoeven]

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.

Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/net/ethernet/renesas/sh_eth.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/renesas/sh_eth.h 
b/drivers/net/ethernet/renesas/sh_eth.h
index a5b792ce2ae7d046..1bf930d4a1e52c18 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -163,7 +163,7 @@ enum {
 };
 
 /* Driver's parameters */
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_RENESAS)
 #define SH_ETH_RX_ALIGN32
 #else
 #define SH_ETH_RX_ALIGN2
-- 
2.7.4

[PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS

[Geert Uytterhoeven]

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.

Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check, just like before support for Renesas ARM SoCs was added.

Instead of blindly changing all the #ifdefs, switch the main code block
in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
remaining #ifdefs.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/dma/sh/shdmac.c | 50 +
 1 file changed, 21 insertions(+), 29 deletions(-)

diff --git a/drivers/dma/sh/shdmac.c b/drivers/dma/sh/shdmac.c
index 516f5487cc44cf96..8fcaae482ce0949a 100644
--- a/drivers/dma/sh/shdmac.c
+++ b/drivers/dma/sh/shdmac.c
@@ -440,7 +440,6 @@ static bool sh_dmae_reset(struct sh_dmae_device *shdev)
return ret;
 }
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
 static irqreturn_t sh_dmae_err(int irq, void *data)
 {
struct sh_dmae_device *shdev = data;
@@ -451,7 +450,6 @@ static irqreturn_t sh_dmae_err(int irq, void *data)
sh_dmae_reset(shdev);
return IRQ_HANDLED;
 }
-#endif
 
 static bool sh_dmae_desc_completed(struct shdma_chan *schan,
   struct shdma_desc *sdesc)
@@ -683,11 +681,8 @@ static int sh_dmae_probe(struct platform_device *pdev)
const struct sh_dmae_pdata *pdata;
unsigned long chan_flag[SH_DMAE_MAX_CHANNELS] = {};
int chan_irq[SH_DMAE_MAX_CHANNELS];
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
unsigned long irqflags = 0;
-   int errirq;
-#endif
-   int err, i, irq_cnt = 0, irqres = 0, irq_cap = 0;
+   int err, errirq, i, irq_cnt = 0, irqres = 0, irq_cap = 0;
struct sh_dmae_device *shdev;
struct dma_device *dma_dev;
struct resource *chan, *dmars, *errirq_res, *chanirq_res;
@@ -789,33 +784,32 @@ static int sh_dmae_probe(struct platform_device *pdev)
if (err)
goto rst_err;
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
-   chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
+   if (IS_ENABLED(CONFIG_CPU_SH4) || IS_ENABLED(CONFIG_ARCH_RENESAS)) {
+   chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
 
-   if (!chanirq_res)
-   chanirq_res = errirq_res;
-   else
-   irqres++;
+   if (!chanirq_res)
+   chanirq_res = errirq_res;
+   else
+   irqres++;
 
-   if (chanirq_res == errirq_res ||
-   (errirq_res->flags & IORESOURCE_BITS) == IORESOURCE_IRQ_SHAREABLE)
-   irqflags = IRQF_SHARED;
+   if (chanirq_res == errirq_res ||
+   (errirq_res->flags & IORESOURCE_BITS) == 
IORESOURCE_IRQ_SHAREABLE)
+   irqflags = IRQF_SHARED;
 
-   errirq = errirq_res->start;
+   errirq = errirq_res->start;
 
-   err = devm_request_irq(>dev, errirq, sh_dmae_err, irqflags,
-  "DMAC Address Error", shdev);
-   if (err) {
-   dev_err(>dev,
-   "DMA failed requesting irq #%d, error %d\n",
-   errirq, err);
-   goto eirq_err;
+   err = devm_request_irq(>dev, errirq, sh_dmae_err,
+  irqflags, "DMAC Address Error", shdev);
+   if (err) {
+   dev_err(>dev,
+   "DMA failed requesting irq #%d, error %d\n",
+   errirq, err);
+   goto eirq_err;
+   }
+   } else {
+   chanirq_res = errirq_res;
}
 
-#else
-   chanirq_res = errirq_res;
-#endif /* CONFIG_CPU_SH4 || CONFIG_ARCH_SHMOBILE */
-
if (chanirq_res->start == chanirq_res->end &&
!platform_get_resource(pdev, IORESOURCE_IRQ, 1)) {
/* Special case - all multiplexed */
@@ -881,9 +875,7 @@ static int sh_dmae_probe(struct platform_device *pdev)
 chan_probe_err:
sh_dmae_chan_remove(shdev);
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
 eirq_err:
-#endif
 rst_err:
spin_lock_irq(_dmae_lock);
list_del_rcu(>node);
-- 
2.7.4

[PATCH 5/8] staging: emxx_udc: Change platform dependency to ARCH_RENESAS

[Geert Uytterhoeven]

Emma Mobile is a Renesas ARM SoC.  Since commit 9b5ba0df4ea4f940 ("ARM:
shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
platform dependency than the legacy ARCH_SHMOBILE, hence use the
former.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/staging/emxx_udc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/emxx_udc/Kconfig b/drivers/staging/emxx_udc/Kconfig
index d7577096fb25ae7a..e50e722183648c55 100644
--- a/drivers/staging/emxx_udc/Kconfig
+++ b/drivers/staging/emxx_udc/Kconfig
@@ -1,6 +1,6 @@
 config USB_EMXX
tristate "EMXX USB Function Device Controller"
-   depends on USB_GADGET && (ARCH_SHMOBILE || (ARM && COMPILE_TEST))
+   depends on USB_GADGET && (ARCH_RENESAS || (ARM && COMPILE_TEST))
help
   The Emma Mobile series of SoCs from Renesas Electronics and
   former NEC Electronics include USB Function hardware.
-- 
2.7.4

[PATCH 6/8] ASoC: sh: Update menu title and platform dependency

[Geert Uytterhoeven]

Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as
both SuperH and ARM SoCs are supported.

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM
SoCs than the legacy ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the SUPERH
dependency.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven 
---
 sound/soc/sh/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig
index 1aa5cd77ca24a06f..c1b7fb91e3063f2b 100644
--- a/sound/soc/sh/Kconfig
+++ b/sound/soc/sh/Kconfig
@@ -1,5 +1,5 @@
-menu "SoC Audio support for SuperH"
-   depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
+menu "SoC Audio support for Renesas SoCs"
+   depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
 
 config SND_SOC_PCM_SH7760
tristate "SoC Audio support for Renesas SH7760"
-- 
2.7.4

[PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

[Geert Uytterhoeven]

The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
only.  Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
than the legacy ARCH_SHMOBILE, hence use the former.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f9235e8f8e962d2e..7ad4725f9d1f9627 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -396,7 +396,7 @@ config VIDEO_SH_VEU
 config VIDEO_RENESAS_FDP1
tristate "Renesas Fine Display Processor"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
-- 
2.7.4

Re: [PATCH] media: cx231xx: Add support for AverMedia DVD EZMaker 7

[Hans Verkuil]

On 04/13/18 08:59, Kai Heng Feng wrote:
> Hi,
> 
>> On Mar 26, 2018, at 2:06 PM, Kai-Heng Feng   
>> wrote:
>>
>> User reports AverMedia DVD EZMaker 7 can be driven by VIDEO_GRABBER.
>> Add the device to the id_table to make it work.
> 
> *Gentle ping*
> I am hoping this patch can get merged in v4.17.

I posted a pull request for 4.17 for this.

Regards,

Hans

> 
> Kai-Heng
> 
>>
>> BugLink: https://bugs.launchpad.net/bugs/1620762
>> Signed-off-by: Kai-Heng Feng 
>> ---
>>  drivers/media/usb/cx231xx/cx231xx-cards.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c  
>> b/drivers/media/usb/cx231xx/cx231xx-cards.c
>> index f9ec7fedcd5b..da01c5125acb 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
>> @@ -945,6 +945,9 @@ struct usb_device_id cx231xx_id_table[] = {
>>   .driver_info = CX231XX_BOARD_CNXT_RDE_250},
>>  {USB_DEVICE(0x0572, 0x58A0),
>>   .driver_info = CX231XX_BOARD_CNXT_RDU_250},
>> +/* AverMedia DVD EZMaker 7 */
>> +{USB_DEVICE(0x07ca, 0xc039),
>> + .driver_info = CX231XX_BOARD_CNXT_VIDEO_GRABBER},
>>  {USB_DEVICE(0x2040, 0xb110),
>>   .driver_info = CX231XX_BOARD_HAUPPAUGE_USB2_FM_PAL},
>>  {USB_DEVICE(0x2040, 0xb111),
>> -- 
>> 2.15.1

[GIT PULL FOR v4.18] tegra-vde, video-i2c and usbtv patches

[Hans Verkuil]

The following changes since commit 1d338b86e17d87215cf57b1ad1d13b2afe582d33:

  media: v4l2-compat-ioctl32: better document the code (2018-04-20 08:24:13 
-0400)

are available in the git repository at:

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

for you to fetch changes up to 548ea201716e4f81920f520e47d072f4615164d2:

  usbtv: Use the constant for supported standards (2018-04-20 14:53:18 +0200)


Dmitry Osipenko (5):
  media: staging: tegra-vde: Align bitstream size to 16K
  media: staging: tegra-vde: Silence some of checkpatch warnings
  media: staging: tegra-vde: Correct minimum size of U/V planes
  media: staging: tegra-vde: Do not handle spurious interrupts
  media: staging: tegra-vde: Correct included header

Hugo Grostabussiat (6):
  usbtv: Use same decoder sequence as Windows driver
  usbtv: Add SECAM support
  usbtv: Use V4L2 defines to select capture resolution
  usbtv: Keep norm parameter specific
  usbtv: Enforce standard for color decoding
  usbtv: Use the constant for supported standards

Matt Ranostay (2):
  media: dt-bindings: Add bindings for panasonic,amg88xx
  media: video-i2c: add video-i2c driver

 Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt |  19 ++
 MAINTAINERS   |   6 +
 drivers/media/i2c/Kconfig |  13 +
 drivers/media/i2c/Makefile|   1 +
 drivers/media/i2c/video-i2c.c | 564 
++
 drivers/media/usb/usbtv/usbtv-video.c | 115 
+++--
 drivers/media/usb/usbtv/usbtv.h   |   2 +-
 drivers/staging/media/tegra-vde/tegra-vde.c   |  63 ++---
 8 files changed, 737 insertions(+), 46 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt
 create mode 100644 drivers/media/i2c/video-i2c.c

Re: [PATCH v7 2/2] uvcvideo: handle control pipe protocol STALLs

[Guennadi Liakhovetski]

Hi Laurent,

I've addressed those your comments, that I had no questions for, but I'm 
waiting for your replies to my clarification requests to finalise and post 
the next revision of the patches.

Thanks
Guennadi

On Wed, 11 Apr 2018, Guennadi Liakhovetski wrote:

> Hi Laurent,
> 
> First just answers to your questions:
> 
> On Sat, 7 Apr 2018, Laurent Pinchart wrote:
> 
> > Hi Guennadi,
> > 
> > Thank you for the patch.
> > 
> > On Friday, 23 March 2018 11:24:01 EEST Laurent Pinchart wrote:
> > > From: Guennadi Liakhovetski 
> > > 
> > > When a command ends up in a STALL on the control pipe, use the Request
> > > Error Code control to provide a more precise error information to the
> > > user.
> > 
> > This is the kind of change that I believe is completely right, but that 
> > nonetheless worries me. All the years I've spent working with UVC webcams 
> > taught me that lots of cameras have buggy firmware, and that any change in 
> > how 
> > the host driver issues requests can have dire consequences for users. This 
> > is 
> > especially true when the host driver issues a request that was never issued 
> > before.
> > 
> > The UVC specification also doesn't clearly tell whether the request error 
> > code 
> > control is mandatory for a device to implement. My interpretation of the 
> > specification is that it is, but it would have been nice for the 
> > specification 
> > to be explicit on this topic. Have you encountered devices that don't 
> > implement this control ?
> 
> No, I haven't. But I haven't explicitly tested too many either. This patch 
> would only issue that control if a STALL condition is detected, and 
> normally that doesn't happen.
> 
> > This being said, I don't claim that would be a reason not to use the 
> > request 
> > error code control as proposed by this patch, but I would feel less worried 
> > if 
> > I knew whether the Windows driver used that control as well. If it does 
> > there's a high chance that cameras will implement it correctly, while if it 
> > doesn't we will most certainly hit bugs with several cameras. I was thus 
> > wondering if in the course of your UVC developments you would have happened 
> > to 
> > find out whether this control is used by Windows.
> 
> No, sorry, I never tried to analyse the behaviour of the Windows UVC 
> driver.
> 
> > I would also like to know a bit more about the purpose of this patch. 
> > Logging 
> > the error code is certainly useful for diagnosis purpose. Have you also 
> > found 
> > it useful to report different errors back to userspace ? If so, could you 
> > explain your use cases ?
> 
> Yes, with this patch the user-space can with certainty identify the reason 
> of a stall, specifically you would know, when the camera is in a "not 
> ready" state. With the previous patch in this series the driver shouldn't 
> be sending a second SET_CUR command to the same control, before the first 
> one has completed, but on some cameras different controls can also be 
> interrelated. In such a case trying to set a different control, while a 
> previous one is still being processed, can also cause a STALL with a "Not 
> ready" error state.
> 
> > > Signed-off-by: Guennadi Liakhovetski 
> > > ---
> > >  drivers/media/usb/uvc/uvc_video.c | 59 
> > > 
> > >  1 file changed, 53 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/media/usb/uvc/uvc_video.c
> > > b/drivers/media/usb/uvc/uvc_video.c index aa0082fe5833..eb9e04a59427 
> > > 100644
> > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > @@ -34,15 +34,59 @@ static int __uvc_query_ctrl(struct uvc_device *dev, u8
> > > query, u8 unit, u8 intfnum, u8 cs, void *data, u16 size,
> > >   int timeout)
> > >  {
> > > - u8 type = USB_TYPE_CLASS | USB_RECIP_INTERFACE;
> > > + u8 type = USB_TYPE_CLASS | USB_RECIP_INTERFACE, tmp, error;
> > 
> > Would you mind declaring one variable per line to match the style of the 
> > rest 
> > of the driver ?
> 
> In fact I would, but well... ;-)
> 
> > >   unsigned int pipe;
> > > + int ret;
> > > 
> > >   pipe = (query & 0x80) ? usb_rcvctrlpipe(dev->udev, 0)
> > > : usb_sndctrlpipe(dev->udev, 0);
> > > 
> > >   type |= (query & 0x80) ? USB_DIR_IN : USB_DIR_OUT;
> > > 
> > > - return usb_control_msg(dev->udev, pipe, query, type, cs << 8,
> > > + ret = usb_control_msg(dev->udev, pipe, query, type, cs << 8,
> > >   unit << 8 | intfnum, data, size, timeout);
> > > +
> > 
> > Nitpicking, you can remove the blank line here.
> > 
> > > + if (ret != -EPIPE)
> > > + return ret;
> > > +
> > > + tmp = *(u8 *)data;
> > > +
> > > + pipe = usb_rcvctrlpipe(dev->udev, 0);
> > > + type = USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN;
> > > + ret = usb_control_msg(dev->udev, pipe, UVC_GET_CUR, type,
> > > +   

Re: [PATCH 3/4] sound, media: allow building ISA drivers it with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Fri, 20 Apr 2018 14:58:15 +0200
Takashi Iwai  escreveu:

> On Fri, 20 Apr 2018 14:51:29 +0200,
> Mauro Carvalho Chehab wrote:
> > 
> > Em Fri, 20 Apr 2018 14:37:46 +0200
> > Takashi Iwai  escreveu:
> >   
> > > On Fri, 20 Apr 2018 14:32:15 +0200,
> > > Mauro Carvalho Chehab wrote:  
> > > > 
> > > > All sound drivers that don't depend on PNP can be safelly
> > > > build with COMPILE_TEST, as ISA provides function stubs to
> > > > be used for such purposes.
> > > > 
> > > > As a side effect, with this change, the radio-miropcm20
> > > > can now be built outside i386 with COMPILE_TEST.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > ---
> > > >  drivers/media/radio/Kconfig | 3 ++-
> > > >  sound/isa/Kconfig   | 9 +
> > > >  2 files changed, 7 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> > > > index d363726e9eb1..8fa403c7149e 100644
> > > > --- a/drivers/media/radio/Kconfig
> > > > +++ b/drivers/media/radio/Kconfig
> > > > @@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
> > > >  
> > > >  config RADIO_MIROPCM20
> > > > tristate "miroSOUND PCM20 radio"
> > > > -   depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
> > > > +   depends on ISA || COMPILE_TEST
> > > > +   depends on ISA_DMA_API && VIDEO_V4L2 && SND
> > > > select SND_ISA
> > > > select SND_MIRO
> > > > ---help---
> > > > diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
> > > > index cb54d9c0a77f..d2a6cdd0395c 100644
> > > > --- a/sound/isa/Kconfig
> > > > +++ b/sound/isa/Kconfig
> > > > @@ -20,7 +20,8 @@ config SND_SB16_DSP
> > > >  
> > > >  menuconfig SND_ISA
> > > > bool "ISA sound devices"
> > > > -   depends on ISA && ISA_DMA_API
> > > > +   depends on ISA || COMPILE_TEST
> > > > +   depends on ISA_DMA_API
> > > > default y
> > > > help
> > > >   Support for sound devices connected via the ISA bus.
> > > > @@ -38,7 +39,7 @@ config SND_ADLIB
> > > >  
> > > >  config SND_AD1816A
> > > > tristate "Analog Devices SoundPort AD1816A"
> > > > -   depends on PNP
> > > > +   depends on PNP && ISA
> > > > select ISAPNP
> > > > select SND_OPL3_LIB
> > > > select SND_MPU401_UART
> > > 
> > > Just from curiosity: what's the reason for this explicit CONFIG_ISA
> > > dependency?  What error did you get?  
> > 
> > Kconfig complains with "select ISAPNP":
> > 
> > WARNING: unmet direct dependencies detected for ISAPNP
> >   Depends on [n]: PNP [=y] && ISA [=n]
> >   Selected by [y]:
> >   - SND_AD1816A [=y] && SOUND [=y] && !UML && SND [=y] && SND_ISA [=y] && 
> > PNP [=y]
> > 
> > Because it is declared as:
> > 
> > config ISAPNP
> > bool "ISA Plug and Play support"
> > depends on ISA  
> 
> I see.  Then it'd be better to put this explanations in the changelog
> as well.

Added. See enclosed.

> 
> > I could have tried to change ISAPNP to depends on ISA || COMPILE_TEST,
> > but I suspect that would touch on yet another subsystem and has
> > the potential to point to other things that need changes, as
> > a lot more drivers will be selected.
> > 
> > Anyway, after a quick look at include/linux/isapnp.h, I suspect
> > that this can work.
> > 
> > I'll run some tests here.  
> 
> At least a dumb stub is there, so let's hope we can widen the test
> coverage :)

Yes, that's the idea :-)

Right now, for every patch I receive, I build media drivers for i386
(I just made all of them build on i386), but I'm considering doing such
builds on x86_64 instead, as it also enables compat32 code.

Thanks,
Mauro

[PATCH v2] sound, media: allow building ISA drivers it with COMPILE_TEST

All sound drivers that don't depend on PNP can be safelly
build with COMPILE_TEST, as ISA provides function stubs to
be used for such purposes.

As a side effect, with this change, the radio-miropcm20
can now be built outside i386 with COMPILE_TEST.

It should be noticed that ISAPNP currently depends on ISA.
So, on drivers that depend on it, we need to add an
explicit dependency on ISA, at least until another patch
removes it.

Signed-off-by: Mauro Carvalho Chehab 

---

v2: only patch description changed, with the addition of a note
about ISA explicit dependency on 3 drivers.


diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index d363726e9eb1..8fa403c7149e 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
 
 config RADIO_MIROPCM20
tristate "miroSOUND PCM20 radio"
-   depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
+   depends on ISA || COMPILE_TEST
+   depends on ISA_DMA_API && VIDEO_V4L2 && SND
select SND_ISA
select SND_MIRO
---help---
diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
index cb54d9c0a77f..d2a6cdd0395c 

Re: [PATCH] sound, isapnp: allow building more drivers with COMPILE_TEST

[Takashi Iwai]

On Fri, 20 Apr 2018 14:58:55 +0200,
Mauro Carvalho Chehab wrote:
> 
> Drivers that depend on ISAPNP currently can't be built with
> COMPILE_TEST. However, looking at isapnp.h, there are already
> stubs there to allow drivers to include it even when isa
> PNP is not supported.
> 
> So, remove such dependencies when COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Takashi Iwai 


thanks,

Takashi


> ---
>  drivers/pnp/isapnp/Kconfig | 2 +-
>  sound/isa/Kconfig  | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pnp/isapnp/Kconfig b/drivers/pnp/isapnp/Kconfig
> index f1ef36673ad4..a1af146d2d90 100644
> --- a/drivers/pnp/isapnp/Kconfig
> +++ b/drivers/pnp/isapnp/Kconfig
> @@ -3,7 +3,7 @@
>  #
>  config ISAPNP
>   bool "ISA Plug and Play support"
> - depends on ISA
> + depends on ISA || COMPILE_TEST
>   help
> Say Y here if you would like support for ISA Plug and Play devices.
> Some information is in .
> diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
> index d2a6cdd0395c..43b35a873d78 100644
> --- a/sound/isa/Kconfig
> +++ b/sound/isa/Kconfig
> @@ -39,7 +39,7 @@ config SND_ADLIB
>  
>  config SND_AD1816A
>   tristate "Analog Devices SoundPort AD1816A"
> - depends on PNP && ISA
> + depends on PNP
>   select ISAPNP
>   select SND_OPL3_LIB
>   select SND_MPU401_UART
> @@ -67,7 +67,7 @@ config SND_AD1848
>  
>  config SND_ALS100
>   tristate "Diamond Tech. DT-019x and Avance Logic ALSxxx"
> - depends on PNP && ISA
> + depends on PNP
>   select ISAPNP
>   select SND_OPL3_LIB
>   select SND_MPU401_UART
> @@ -108,7 +108,7 @@ config SND_AZT2316
>  
>  config SND_AZT2320
>   tristate "Aztech Systems AZT2320"
> - depends on PNP && ISA
> + depends on PNP
>   select ISAPNP
>   select SND_OPL3_LIB
>   select SND_MPU401_UART
> -- 
> 2.14.3
> 
> 

Re: [PATCH 3/4] sound, media: allow building ISA drivers it with COMPILE_TEST

[Takashi Iwai]

On Fri, 20 Apr 2018 15:01:22 +0200,
Mauro Carvalho Chehab wrote:
> 
> Em Fri, 20 Apr 2018 09:51:29 -0300
> Mauro Carvalho Chehab  escreveu:
> 
> > Em Fri, 20 Apr 2018 14:37:46 +0200
> > Takashi Iwai  escreveu:
> > 
> > > On Fri, 20 Apr 2018 14:32:15 +0200,
> > > Mauro Carvalho Chehab wrote:  
> > > > 
> > > > All sound drivers that don't depend on PNP can be safelly
> > > > build with COMPILE_TEST, as ISA provides function stubs to
> > > > be used for such purposes.
> > > > 
> > > > As a side effect, with this change, the radio-miropcm20
> > > > can now be built outside i386 with COMPILE_TEST.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > ---
> > > >  drivers/media/radio/Kconfig | 3 ++-
> > > >  sound/isa/Kconfig   | 9 +
> > > >  2 files changed, 7 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> > > > index d363726e9eb1..8fa403c7149e 100644
> > > > --- a/drivers/media/radio/Kconfig
> > > > +++ b/drivers/media/radio/Kconfig
> > > > @@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
> > > >  
> > > >  config RADIO_MIROPCM20
> > > > tristate "miroSOUND PCM20 radio"
> > > > -   depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
> > > > +   depends on ISA || COMPILE_TEST
> > > > +   depends on ISA_DMA_API && VIDEO_V4L2 && SND
> > > > select SND_ISA
> > > > select SND_MIRO
> > > > ---help---
> > > > diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
> > > > index cb54d9c0a77f..d2a6cdd0395c 100644
> > > > --- a/sound/isa/Kconfig
> > > > +++ b/sound/isa/Kconfig
> > > > @@ -20,7 +20,8 @@ config SND_SB16_DSP
> > > >  
> > > >  menuconfig SND_ISA
> > > > bool "ISA sound devices"
> > > > -   depends on ISA && ISA_DMA_API
> > > > +   depends on ISA || COMPILE_TEST
> > > > +   depends on ISA_DMA_API
> > > > default y
> > > > help
> > > >   Support for sound devices connected via the ISA bus.
> > > > @@ -38,7 +39,7 @@ config SND_ADLIB
> > > >  
> > > >  config SND_AD1816A
> > > > tristate "Analog Devices SoundPort AD1816A"
> > > > -   depends on PNP
> > > > +   depends on PNP && ISA
> > > > select ISAPNP
> > > > select SND_OPL3_LIB
> > > > select SND_MPU401_UART
> > > 
> > > Just from curiosity: what's the reason for this explicit CONFIG_ISA
> > > dependency?  What error did you get?  
> > 
> > Kconfig complains with "select ISAPNP":
> > 
> > WARNING: unmet direct dependencies detected for ISAPNP
> >   Depends on [n]: PNP [=y] && ISA [=n]
> >   Selected by [y]:
> >   - SND_AD1816A [=y] && SOUND [=y] && !UML && SND [=y] && SND_ISA [=y] && 
> > PNP [=y]
> > 
> > Because it is declared as:
> > 
> > config ISAPNP
> > bool "ISA Plug and Play support"
> > depends on ISA
> > 
> > I could have tried to change ISAPNP to depends on ISA || COMPILE_TEST,
> > but I suspect that would touch on yet another subsystem and has
> > the potential to point to other things that need changes, as
> > a lot more drivers will be selected.
> > 
> > Anyway, after a quick look at include/linux/isapnp.h, I suspect
> > that this can work.
> > 
> > I'll run some tests here.
> 
> Yes, removing the ISAPNP dependency if COMPILE_TEST is trivial too.
> 
> Just sent a separate patch to be applied after this one with such
> removal.
> 
> I opted to make it as a separate patch as, if the drivers there
> fail to build on some weird architecture, we won't need to discard
> this one.

OK, then feel free to take my ack:
  Acked-by: Takashi Iwai 

But still it'd be better to mention about the CONFIG_ISA change, even
though it'll be removed again after the ISAPNP COMIPLE_TEST patch.


thanks,

Takashi

Re: [PATCH 3/4] sound, media: allow building ISA drivers it with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Fri, 20 Apr 2018 09:51:29 -0300
Mauro Carvalho Chehab  escreveu:

> Em Fri, 20 Apr 2018 14:37:46 +0200
> Takashi Iwai  escreveu:
> 
> > On Fri, 20 Apr 2018 14:32:15 +0200,
> > Mauro Carvalho Chehab wrote:  
> > > 
> > > All sound drivers that don't depend on PNP can be safelly
> > > build with COMPILE_TEST, as ISA provides function stubs to
> > > be used for such purposes.
> > > 
> > > As a side effect, with this change, the radio-miropcm20
> > > can now be built outside i386 with COMPILE_TEST.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > ---
> > >  drivers/media/radio/Kconfig | 3 ++-
> > >  sound/isa/Kconfig   | 9 +
> > >  2 files changed, 7 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> > > index d363726e9eb1..8fa403c7149e 100644
> > > --- a/drivers/media/radio/Kconfig
> > > +++ b/drivers/media/radio/Kconfig
> > > @@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
> > >  
> > >  config RADIO_MIROPCM20
> > >   tristate "miroSOUND PCM20 radio"
> > > - depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
> > > + depends on ISA || COMPILE_TEST
> > > + depends on ISA_DMA_API && VIDEO_V4L2 && SND
> > >   select SND_ISA
> > >   select SND_MIRO
> > >   ---help---
> > > diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
> > > index cb54d9c0a77f..d2a6cdd0395c 100644
> > > --- a/sound/isa/Kconfig
> > > +++ b/sound/isa/Kconfig
> > > @@ -20,7 +20,8 @@ config SND_SB16_DSP
> > >  
> > >  menuconfig SND_ISA
> > >   bool "ISA sound devices"
> > > - depends on ISA && ISA_DMA_API
> > > + depends on ISA || COMPILE_TEST
> > > + depends on ISA_DMA_API
> > >   default y
> > >   help
> > > Support for sound devices connected via the ISA bus.
> > > @@ -38,7 +39,7 @@ config SND_ADLIB
> > >  
> > >  config SND_AD1816A
> > >   tristate "Analog Devices SoundPort AD1816A"
> > > - depends on PNP
> > > + depends on PNP && ISA
> > >   select ISAPNP
> > >   select SND_OPL3_LIB
> > >   select SND_MPU401_UART
> > 
> > Just from curiosity: what's the reason for this explicit CONFIG_ISA
> > dependency?  What error did you get?  
> 
> Kconfig complains with "select ISAPNP":
> 
> WARNING: unmet direct dependencies detected for ISAPNP
>   Depends on [n]: PNP [=y] && ISA [=n]
>   Selected by [y]:
>   - SND_AD1816A [=y] && SOUND [=y] && !UML && SND [=y] && SND_ISA [=y] && PNP 
> [=y]
> 
> Because it is declared as:
> 
> config ISAPNP
>   bool "ISA Plug and Play support"
> depends on ISA
> 
> I could have tried to change ISAPNP to depends on ISA || COMPILE_TEST,
> but I suspect that would touch on yet another subsystem and has
> the potential to point to other things that need changes, as
> a lot more drivers will be selected.
> 
> Anyway, after a quick look at include/linux/isapnp.h, I suspect
> that this can work.
> 
> I'll run some tests here.

Yes, removing the ISAPNP dependency if COMPILE_TEST is trivial too.

Just sent a separate patch to be applied after this one with such
removal.

I opted to make it as a separate patch as, if the drivers there
fail to build on some weird architecture, we won't need to discard
this one.

Thanks,
Mauro

[PATCH] sound, isapnp: allow building more drivers with COMPILE_TEST

[Mauro Carvalho Chehab]

Drivers that depend on ISAPNP currently can't be built with
COMPILE_TEST. However, looking at isapnp.h, there are already
stubs there to allow drivers to include it even when isa
PNP is not supported.

So, remove such dependencies when COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/pnp/isapnp/Kconfig | 2 +-
 sound/isa/Kconfig  | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pnp/isapnp/Kconfig b/drivers/pnp/isapnp/Kconfig
index f1ef36673ad4..a1af146d2d90 100644
--- a/drivers/pnp/isapnp/Kconfig
+++ b/drivers/pnp/isapnp/Kconfig
@@ -3,7 +3,7 @@
 #
 config ISAPNP
bool "ISA Plug and Play support"
-   depends on ISA
+   depends on ISA || COMPILE_TEST
help
  Say Y here if you would like support for ISA Plug and Play devices.
  Some information is in .
diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
index d2a6cdd0395c..43b35a873d78 100644
--- a/sound/isa/Kconfig
+++ b/sound/isa/Kconfig
@@ -39,7 +39,7 @@ config SND_ADLIB
 
 config SND_AD1816A
tristate "Analog Devices SoundPort AD1816A"
-   depends on PNP && ISA
+   depends on PNP
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -67,7 +67,7 @@ config SND_AD1848
 
 config SND_ALS100
tristate "Diamond Tech. DT-019x and Avance Logic ALSxxx"
-   depends on PNP && ISA
+   depends on PNP
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -108,7 +108,7 @@ config SND_AZT2316
 
 config SND_AZT2320
tristate "Aztech Systems AZT2320"
-   depends on PNP && ISA
+   depends on PNP
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
-- 
2.14.3

Re: [PATCH 3/4] sound, media: allow building ISA drivers it with COMPILE_TEST

[Takashi Iwai]

On Fri, 20 Apr 2018 14:51:29 +0200,
Mauro Carvalho Chehab wrote:
> 
> Em Fri, 20 Apr 2018 14:37:46 +0200
> Takashi Iwai  escreveu:
> 
> > On Fri, 20 Apr 2018 14:32:15 +0200,
> > Mauro Carvalho Chehab wrote:
> > > 
> > > All sound drivers that don't depend on PNP can be safelly
> > > build with COMPILE_TEST, as ISA provides function stubs to
> > > be used for such purposes.
> > > 
> > > As a side effect, with this change, the radio-miropcm20
> > > can now be built outside i386 with COMPILE_TEST.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > ---
> > >  drivers/media/radio/Kconfig | 3 ++-
> > >  sound/isa/Kconfig   | 9 +
> > >  2 files changed, 7 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> > > index d363726e9eb1..8fa403c7149e 100644
> > > --- a/drivers/media/radio/Kconfig
> > > +++ b/drivers/media/radio/Kconfig
> > > @@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
> > >  
> > >  config RADIO_MIROPCM20
> > >   tristate "miroSOUND PCM20 radio"
> > > - depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
> > > + depends on ISA || COMPILE_TEST
> > > + depends on ISA_DMA_API && VIDEO_V4L2 && SND
> > >   select SND_ISA
> > >   select SND_MIRO
> > >   ---help---
> > > diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
> > > index cb54d9c0a77f..d2a6cdd0395c 100644
> > > --- a/sound/isa/Kconfig
> > > +++ b/sound/isa/Kconfig
> > > @@ -20,7 +20,8 @@ config SND_SB16_DSP
> > >  
> > >  menuconfig SND_ISA
> > >   bool "ISA sound devices"
> > > - depends on ISA && ISA_DMA_API
> > > + depends on ISA || COMPILE_TEST
> > > + depends on ISA_DMA_API
> > >   default y
> > >   help
> > > Support for sound devices connected via the ISA bus.
> > > @@ -38,7 +39,7 @@ config SND_ADLIB
> > >  
> > >  config SND_AD1816A
> > >   tristate "Analog Devices SoundPort AD1816A"
> > > - depends on PNP
> > > + depends on PNP && ISA
> > >   select ISAPNP
> > >   select SND_OPL3_LIB
> > >   select SND_MPU401_UART  
> > 
> > Just from curiosity: what's the reason for this explicit CONFIG_ISA
> > dependency?  What error did you get?
> 
> Kconfig complains with "select ISAPNP":
> 
> WARNING: unmet direct dependencies detected for ISAPNP
>   Depends on [n]: PNP [=y] && ISA [=n]
>   Selected by [y]:
>   - SND_AD1816A [=y] && SOUND [=y] && !UML && SND [=y] && SND_ISA [=y] && PNP 
> [=y]
> 
> Because it is declared as:
> 
> config ISAPNP
>   bool "ISA Plug and Play support"
> depends on ISA

I see.  Then it'd be better to put this explanations in the changelog
as well.

> I could have tried to change ISAPNP to depends on ISA || COMPILE_TEST,
> but I suspect that would touch on yet another subsystem and has
> the potential to point to other things that need changes, as
> a lot more drivers will be selected.
> 
> Anyway, after a quick look at include/linux/isapnp.h, I suspect
> that this can work.
> 
> I'll run some tests here.

At least a dumb stub is there, so let's hope we can widen the test
coverage :)


thanks,

Takashi

Re: [PATCH 3/4] sound, media: allow building ISA drivers it with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Fri, 20 Apr 2018 14:37:46 +0200
Takashi Iwai  escreveu:

> On Fri, 20 Apr 2018 14:32:15 +0200,
> Mauro Carvalho Chehab wrote:
> > 
> > All sound drivers that don't depend on PNP can be safelly
> > build with COMPILE_TEST, as ISA provides function stubs to
> > be used for such purposes.
> > 
> > As a side effect, with this change, the radio-miropcm20
> > can now be built outside i386 with COMPILE_TEST.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/radio/Kconfig | 3 ++-
> >  sound/isa/Kconfig   | 9 +
> >  2 files changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> > index d363726e9eb1..8fa403c7149e 100644
> > --- a/drivers/media/radio/Kconfig
> > +++ b/drivers/media/radio/Kconfig
> > @@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
> >  
> >  config RADIO_MIROPCM20
> > tristate "miroSOUND PCM20 radio"
> > -   depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
> > +   depends on ISA || COMPILE_TEST
> > +   depends on ISA_DMA_API && VIDEO_V4L2 && SND
> > select SND_ISA
> > select SND_MIRO
> > ---help---
> > diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
> > index cb54d9c0a77f..d2a6cdd0395c 100644
> > --- a/sound/isa/Kconfig
> > +++ b/sound/isa/Kconfig
> > @@ -20,7 +20,8 @@ config SND_SB16_DSP
> >  
> >  menuconfig SND_ISA
> > bool "ISA sound devices"
> > -   depends on ISA && ISA_DMA_API
> > +   depends on ISA || COMPILE_TEST
> > +   depends on ISA_DMA_API
> > default y
> > help
> >   Support for sound devices connected via the ISA bus.
> > @@ -38,7 +39,7 @@ config SND_ADLIB
> >  
> >  config SND_AD1816A
> > tristate "Analog Devices SoundPort AD1816A"
> > -   depends on PNP
> > +   depends on PNP && ISA
> > select ISAPNP
> > select SND_OPL3_LIB
> > select SND_MPU401_UART  
> 
> Just from curiosity: what's the reason for this explicit CONFIG_ISA
> dependency?  What error did you get?

Kconfig complains with "select ISAPNP":

WARNING: unmet direct dependencies detected for ISAPNP
  Depends on [n]: PNP [=y] && ISA [=n]
  Selected by [y]:
  - SND_AD1816A [=y] && SOUND [=y] && !UML && SND [=y] && SND_ISA [=y] && PNP 
[=y]

Because it is declared as:

config ISAPNP
bool "ISA Plug and Play support"
depends on ISA

I could have tried to change ISAPNP to depends on ISA || COMPILE_TEST,
but I suspect that would touch on yet another subsystem and has
the potential to point to other things that need changes, as
a lot more drivers will be selected.

Anyway, after a quick look at include/linux/isapnp.h, I suspect
that this can work.

I'll run some tests here.

Thanks,
Mauro

Re: [PATCH v8 2/2] media: video-i2c: add video-i2c driver

[Hans Verkuil]

On 04/18/18 12:30, Sakari Ailus wrote:
> On Wed, Apr 18, 2018 at 01:46:08AM -0700, Matt Ranostay wrote:
> 
> ...
> 
>> On Wed, Apr 18, 2018 at 1:03 AM, Sakari Ailus  wrote:
 + if (vid_cap_buf) {
 + struct vb2_buffer *vb2_buf = 
 _cap_buf->vb.vb2_buf;
 + void *vbuf = vb2_plane_vaddr(vb2_buf, 0);
 + int ret = data->chip->xfer(data, vbuf);
>>>
>>> As the assignment in variable declaration does more than just initialise a
>>> variable, it'd be nice to make the assignment separately from the variable
>>> declaration.
>>
>> Guessing you mean it is that initialization here is getting pushed and
>> popped off the stack if the data isn't in a register?
> 
> No, just that functionality is placed where variables are declared. The
> code is easier to read if you separate the two. I.e.
> 
> int ret;
> 
> ret = ...->xfer();

Matt, I'm making a pull request for this v8. I've split up this line myself,
so no need to post a v9.

Regards,

Hans

> 
>>
>>>
 +
 + vb2_buf->timestamp = ktime_get_ns();
 + vid_cap_buf->vb.sequence = data->sequence++;
 + vb2_buffer_done(vb2_buf, ret ?
 + VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 + }
 +
 + schedule_delay = delay - (jiffies - start_jiffies);
 +
 + if (time_after(jiffies, start_jiffies + delay))
 + schedule_delay = delay;
 +
 + schedule_timeout_interruptible(schedule_delay);
 + } while (!kthread_should_stop());
 +
 + return 0;
 +}
> 

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

[Christoph Hellwig]

On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > num_resources) which does the handling common to all drivers.
> > A structure that contains
> > 
> > {page,offset,len} + {dma_addr+dma_len}
> > 
> > is not a good container for storing
> > 
> > {virt addr, dma_addr, len}
> > 
> > no matter what interface you build arond it.
> 
> Why not? I mean at least for my use case we actually don't need the virtual
> address.

If you don't need the virtual address you need scatterlist even list.

> What we need is {dma_addr+dma_len} in a consistent interface which can come
> from both {page,offset,len} as well as {resource, len}.

Ok.

> What I actually don't need is separate handling for system memory and
> resources, but that would we get exactly when we don't use sg_table.

At the very lowest level they will need to be handled differently for
many architectures, the questions is at what point we'll do the
branching out.

Re: [PATCH 3/4] sound, media: allow building ISA drivers it with COMPILE_TEST

[Takashi Iwai]

On Fri, 20 Apr 2018 14:32:15 +0200,
Mauro Carvalho Chehab wrote:
> 
> All sound drivers that don't depend on PNP can be safelly
> build with COMPILE_TEST, as ISA provides function stubs to
> be used for such purposes.
> 
> As a side effect, with this change, the radio-miropcm20
> can now be built outside i386 with COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/radio/Kconfig | 3 ++-
>  sound/isa/Kconfig   | 9 +
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> index d363726e9eb1..8fa403c7149e 100644
> --- a/drivers/media/radio/Kconfig
> +++ b/drivers/media/radio/Kconfig
> @@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
>  
>  config RADIO_MIROPCM20
>   tristate "miroSOUND PCM20 radio"
> - depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
> + depends on ISA || COMPILE_TEST
> + depends on ISA_DMA_API && VIDEO_V4L2 && SND
>   select SND_ISA
>   select SND_MIRO
>   ---help---
> diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
> index cb54d9c0a77f..d2a6cdd0395c 100644
> --- a/sound/isa/Kconfig
> +++ b/sound/isa/Kconfig
> @@ -20,7 +20,8 @@ config SND_SB16_DSP
>  
>  menuconfig SND_ISA
>   bool "ISA sound devices"
> - depends on ISA && ISA_DMA_API
> + depends on ISA || COMPILE_TEST
> + depends on ISA_DMA_API
>   default y
>   help
> Support for sound devices connected via the ISA bus.
> @@ -38,7 +39,7 @@ config SND_ADLIB
>  
>  config SND_AD1816A
>   tristate "Analog Devices SoundPort AD1816A"
> - depends on PNP
> + depends on PNP && ISA
>   select ISAPNP
>   select SND_OPL3_LIB
>   select SND_MPU401_UART

Just from curiosity: what's the reason for this explicit CONFIG_ISA
dependency?  What error did you get?


thanks,

Takashi

> @@ -66,7 +67,7 @@ config SND_AD1848
>  
>  config SND_ALS100
>   tristate "Diamond Tech. DT-019x and Avance Logic ALSxxx"
> - depends on PNP
> + depends on PNP && ISA
>   select ISAPNP
>   select SND_OPL3_LIB
>   select SND_MPU401_UART
> @@ -107,7 +108,7 @@ config SND_AZT2316
>  
>  config SND_AZT2320
>   tristate "Aztech Systems AZT2320"
> - depends on PNP
> + depends on PNP && ISA
>   select ISAPNP
>   select SND_OPL3_LIB
>   select SND_MPU401_UART
> -- 
> 2.14.3
> 
> 

[PATCH 3/4] sound, media: allow building ISA drivers it with COMPILE_TEST

[Mauro Carvalho Chehab]

All sound drivers that don't depend on PNP can be safelly
build with COMPILE_TEST, as ISA provides function stubs to
be used for such purposes.

As a side effect, with this change, the radio-miropcm20
can now be built outside i386 with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/radio/Kconfig | 3 ++-
 sound/isa/Kconfig   | 9 +
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index d363726e9eb1..8fa403c7149e 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -372,7 +372,8 @@ config RADIO_GEMTEK_PROBE
 
 config RADIO_MIROPCM20
tristate "miroSOUND PCM20 radio"
-   depends on ISA && ISA_DMA_API && VIDEO_V4L2 && SND
+   depends on ISA || COMPILE_TEST
+   depends on ISA_DMA_API && VIDEO_V4L2 && SND
select SND_ISA
select SND_MIRO
---help---
diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
index cb54d9c0a77f..d2a6cdd0395c 100644
--- a/sound/isa/Kconfig
+++ b/sound/isa/Kconfig
@@ -20,7 +20,8 @@ config SND_SB16_DSP
 
 menuconfig SND_ISA
bool "ISA sound devices"
-   depends on ISA && ISA_DMA_API
+   depends on ISA || COMPILE_TEST
+   depends on ISA_DMA_API
default y
help
  Support for sound devices connected via the ISA bus.
@@ -38,7 +39,7 @@ config SND_ADLIB
 
 config SND_AD1816A
tristate "Analog Devices SoundPort AD1816A"
-   depends on PNP
+   depends on PNP && ISA
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -66,7 +67,7 @@ config SND_AD1848
 
 config SND_ALS100
tristate "Diamond Tech. DT-019x and Avance Logic ALSxxx"
-   depends on PNP
+   depends on PNP && ISA
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -107,7 +108,7 @@ config SND_AZT2316
 
 config SND_AZT2320
tristate "Aztech Systems AZT2320"
-   depends on PNP
+   depends on PNP && ISA
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
-- 
2.14.3

[PATCH 0/4] More COMPILE_TEST patches to build all media drivers on x86_64

[Mauro Carvalho Chehab]

While now all media drivers build with COMPILE_TEST on i386, there are still
a few of them that don't build on x86_64.

Making them compiling there is just a matter of touching Kconfig files.

While here, fix smatch warnings when building the siano driver on big endian
architectures.

Mauro Carvalho Chehab (4):
  media: radio: allow building ISA drivers with COMPILE_TEST
  media: sta2x11_vip: allow build with COMPILE_TEST
  sound, media: allow building ISA drivers it with COMPILE_TEST
  media: siano: get rid of __le32/__le16 cast warnings

 drivers/media/common/siano/smsendian.c | 14 ++--
 drivers/media/pci/sta2x11/Kconfig  |  2 +-
 drivers/media/radio/Kconfig| 41 +-
 sound/isa/Kconfig  |  9 
 4 files changed, 39 insertions(+), 27 deletions(-)

-- 
2.14.3

[PATCH 4/4] media: siano: get rid of __le32/__le16 cast warnings

[Mauro Carvalho Chehab]

Those are all false-positives that appear with smatch when building for
arm:

  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted 
__le32
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted 
__le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted 
__le16

Get rid of them by adding explicit forced casts.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/common/siano/smsendian.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/common/siano/smsendian.c 
b/drivers/media/common/siano/smsendian.c
index bfe831c10b1c..b95a631f23f9 100644
--- a/drivers/media/common/siano/smsendian.c
+++ b/drivers/media/common/siano/smsendian.c
@@ -35,7 +35,7 @@ void smsendian_handle_tx_message(void *buffer)
switch (msg->x_msg_header.msg_type) {
case MSG_SMS_DATA_DOWNLOAD_REQ:
{
-   msg->msg_data[0] = le32_to_cpu(msg->msg_data[0]);
+   msg->msg_data[0] = le32_to_cpu((__force 
__le32)(msg->msg_data[0]));
break;
}
 
@@ -44,7 +44,7 @@ void smsendian_handle_tx_message(void *buffer)
sizeof(struct sms_msg_hdr))/4;
 
for (i = 0; i < msg_words; i++)
-   msg->msg_data[i] = le32_to_cpu(msg->msg_data[i]);
+   msg->msg_data[i] = le32_to_cpu((__force 
__le32)msg->msg_data[i]);
 
break;
}
@@ -64,7 +64,7 @@ void smsendian_handle_rx_message(void *buffer)
{
struct sms_version_res *ver =
(struct sms_version_res *) msg;
-   ver->chip_model = le16_to_cpu(ver->chip_model);
+   ver->chip_model = le16_to_cpu((__force __le16)ver->chip_model);
break;
}
 
@@ -81,7 +81,7 @@ void smsendian_handle_rx_message(void *buffer)
sizeof(struct sms_msg_hdr))/4;
 
for (i = 0; i < msg_words; i++)
-   msg->msg_data[i] = le32_to_cpu(msg->msg_data[i]);
+   msg->msg_data[i] = le32_to_cpu((__force 
__le32)msg->msg_data[i]);
 
break;
}
@@ -95,9 +95,9 @@ void smsendian_handle_message_header(void *msg)
 #ifdef __BIG_ENDIAN
struct sms_msg_hdr *phdr = (struct sms_msg_hdr *)msg;

[PATCH 2/4] media: sta2x11_vip: allow build with COMPILE_TEST

[Mauro Carvalho Chehab]

This driver doesn't use any weird API. So, allow building it
with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/sta2x11/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index e03587b1af71..7af3f1cbcea8 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,6 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
-   depends on STA2X11
+   depends on STA2X11 || COMPILE_TEST
depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
-- 
2.14.3

[PATCH 1/4] media: radio: allow building ISA drivers with COMPILE_TEST

[Mauro Carvalho Chehab]

Several radio devices only build on i386, because they depend
on ISA. Allow them to build on other archs by adding a
COMPILE_TEST check.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/radio/Kconfig | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 2ed539f9eb87..d363726e9eb1 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -231,7 +231,7 @@ source "drivers/media/radio/wl128x/Kconfig"
 
 menuconfig V4L_RADIO_ISA_DRIVERS
bool "ISA radio devices"
-   depends on ISA
+   depends on ISA || COMPILE_TEST
default n
---help---
  Say Y here to enable support for these ISA drivers.
@@ -239,12 +239,13 @@ menuconfig V4L_RADIO_ISA_DRIVERS
 if V4L_RADIO_ISA_DRIVERS
 
 config RADIO_ISA
-   depends on ISA
+   depends on ISA || COMPILE_TEST
tristate
 
 config RADIO_CADET
tristate "ADS Cadet AM/FM Tuner"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
---help---
  Choose Y here if you have one of these AM/FM radio cards, and then
  fill in the port address below.
@@ -254,8 +255,8 @@ config RADIO_CADET
 
 config RADIO_RTRACK
tristate "AIMSlab RadioTrack (aka RadioReveal) support"
-   depends on ISA && VIDEO_V4L2
-   select RADIO_ISA
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
---help---
  Choose Y here if you have one of these FM radio cards, and then fill
  in the port address below.
@@ -285,7 +286,8 @@ config RADIO_RTRACK_PORT
 
 config RADIO_RTRACK2
tristate "AIMSlab RadioTrack II support"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_ISA
---help---
  Choose Y here if you have this FM radio card, and then fill in the
@@ -308,7 +310,8 @@ config RADIO_RTRACK2_PORT
 
 config RADIO_AZTECH
tristate "Aztech/Packard Bell Radio"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_ISA
---help---
  Choose Y here if you have one of these FM radio cards, and then fill
@@ -328,7 +331,8 @@ config RADIO_AZTECH_PORT
 
 config RADIO_GEMTEK
tristate "GemTek Radio card (or compatible) support"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_ISA
---help---
  Choose Y here if you have this FM radio card, and then fill in the
@@ -382,7 +386,8 @@ config RADIO_MIROPCM20
 
 config RADIO_SF16FMI
tristate "SF16-FMI/SF16-FMP/SF16-FMD Radio"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
---help---
  Choose Y here if you have one of these FM radio cards.
 
@@ -391,7 +396,8 @@ config RADIO_SF16FMI
 
 config RADIO_SF16FMR2
tristate "SF16-FMR2/SF16-FMD2 Radio"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_TEA575X
---help---
  Choose Y here if you have one of these FM radio cards.
@@ -401,7 +407,8 @@ config RADIO_SF16FMR2
 
 config RADIO_TERRATEC
tristate "TerraTec ActiveRadio ISA Standalone"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_ISA
---help---
  Choose Y here if you have this FM radio card.
@@ -415,7 +422,8 @@ config RADIO_TERRATEC
 
 config RADIO_TRUST
tristate "Trust FM radio card"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_ISA
help
  This is a driver for the Trust FM radio cards. Say Y if you have
@@ -438,7 +446,8 @@ config RADIO_TRUST_PORT
 
 config RADIO_TYPHOON
tristate "Typhoon Radio (a.k.a. EcoRadio)"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_ISA
---help---
  Choose Y here if you have one of these FM radio cards, and then fill
@@ -472,7 +481,8 @@ config RADIO_TYPHOON_MUTEFREQ
 
 config RADIO_ZOLTRIX
tristate "Zoltrix Radio"
-   depends on ISA && VIDEO_V4L2
+   depends on ISA || COMPILE_TEST
+   depends on VIDEO_V4L2
select RADIO_ISA
---help---
  Choose Y here if you have one of these FM radio cards, and then fill
-- 
2.14.3

Re: [PATCH v3 06/13] media: platform: video-mux: Register a subdev notifier

[Hans Verkuil]

On 03/21/18 01:37, Steve Longerbeam wrote:
> Parse neighbor remote devices on the video muxes input ports, add them to a
> subdev notifier, and register the subdev notifier for the video mux, by
> calling v4l2_async_register_fwnode_subdev().
> 
> Signed-off-by: Steve Longerbeam 
> ---
> Changes since v2:
> - none
> Changes since v1:
> - add #include  for kcalloc() declaration.
> ---
>  drivers/media/platform/video-mux.c | 36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/video-mux.c 
> b/drivers/media/platform/video-mux.c
> index ee89ad7..b93b0af 100644
> --- a/drivers/media/platform/video-mux.c
> +++ b/drivers/media/platform/video-mux.c
> @@ -21,8 +21,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct video_mux {
> @@ -193,6 +195,38 @@ static const struct v4l2_subdev_ops video_mux_subdev_ops 
> = {
>   .video = _mux_subdev_video_ops,
>  };
>  
> +static int video_mux_parse_endpoint(struct device *dev,
> + struct v4l2_fwnode_endpoint *vep,
> + struct v4l2_async_subdev *asd)
> +{
> + /*
> +  * it's not an error if remote is missing on a video-mux
> +  * input port, return -ENOTCONN to skip this endpoint with
> +  * no error.
> +  */
> + return fwnode_device_is_available(asd->match.fwnode) ? 0 : -ENOTCONN;
> +}
> +
> +static int video_mux_async_register(struct video_mux *vmux,
> + unsigned int num_pads)
> +{
> + unsigned int i, *ports;
> + int ret;
> +
> + ports = kcalloc(num_pads - 1, sizeof(*ports), GFP_KERNEL);
> + if (!ports)
> + return -ENOMEM;
> + for (i = 0; i < num_pads - 1; i++)
> + ports[i] = i;
> +
> + ret = v4l2_async_register_fwnode_subdev(
> + >subdev, sizeof(struct v4l2_async_subdev),
> + ports, num_pads - 1, video_mux_parse_endpoint);
> +
> + kfree(ports);
> + return ret;
> +}
> +
>  static int video_mux_probe(struct platform_device *pdev)
>  {
>   struct device_node *np = pdev->dev.of_node;
> @@ -258,7 +292,7 @@ static int video_mux_probe(struct platform_device *pdev)
>  
>   vmux->subdev.entity.ops = _mux_ops;
>  
> - return v4l2_async_register_subdev(>subdev);
> + return video_mux_async_register(vmux, num_pads);

I would prefer to change the last argument to 'num_pads - 1' and drop the ' - 1'
part in the video_mux_async_register() function. Perhaps renaming the num_pads
argument there to num_input_pads.

Regards,

Hans

>  }
>  
>  static int video_mux_remove(struct platform_device *pdev)
> 

Re: [PATCH v3 03/13] media: v4l2: async: Add v4l2_async_notifier_add_subdev

[Sakari Ailus]

Hi Steve,

Thanks for the patchset.

On Tue, Mar 20, 2018 at 05:37:19PM -0700, Steve Longerbeam wrote:
> v4l2_async_notifier_add_subdev() adds an asd to the notifier. It checks
> that the asd's match_type is valid and that no other equivalent asd's
> have already been added to this notifier's asd list, or to other
> registered notifier's waiting or done lists, and increments num_subdevs.
> 
> v4l2_async_notifier_add_subdev() does not make use of the notifier subdevs
> array, otherwise it would have to re-allocate the array every time the
> function was called. In place of the subdevs array, the function adds
> the asd to a new master asd_list. The function will return error with a
> WARN() if it is ever called with the subdevs array allocated.
> 
> In v4l2_async_notifier_has_async_subdev(), __v4l2_async_notifier_register(),
> and v4l2_async_notifier_cleanup(), alternatively operate on the subdevs
> array or a non-empty notifier->asd_list.

I do agree with the approach, but this patch leaves the remaining users of
the subdevs array in the notifier intact. Could you rework them to use the
v4l2_async_notifier_add_subdev() as well?

There seem to be just a few of them --- exynos4-is and rcar_drif.

> 
> Signed-off-by: Steve Longerbeam 
> ---
> Changes since v2:
> - add a NULL asd pointer check to v4l2_async_notifier_asd_valid().
> Changes since v1:
> - none
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 206 
> +++
>  include/media/v4l2-async.h   |  22 
>  2 files changed, 184 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index b59bbac..7b7f7e2 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -366,16 +366,26 @@ static bool v4l2_async_notifier_has_async_subdev(
>   struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd,
>   unsigned int this_index)
>  {
> + struct v4l2_async_subdev *asd_y;
>   unsigned int j;
>  
>   lockdep_assert_held(_lock);
>  
>   /* Check that an asd is not being added more than once. */
> - for (j = 0; j < this_index; j++) {
> - struct v4l2_async_subdev *asd_y = notifier->subdevs[j];
> -
> - if (asd_equal(asd, asd_y))
> - return true;
> + if (notifier->subdevs) {
> + for (j = 0; j < this_index; j++) {
> + asd_y = notifier->subdevs[j];
> + if (asd_equal(asd, asd_y))
> + return true;
> + }
> + } else {
> + j = 0;
> + list_for_each_entry(asd_y, >asd_list, asd_list) {
> + if (j++ >= this_index)
> + break;
> + if (asd_equal(asd, asd_y))
> + return true;
> + }
>   }
>  
>   /* Check that an asd does not exist in other notifiers. */
> @@ -386,10 +396,46 @@ static bool v4l2_async_notifier_has_async_subdev(
>   return false;
>  }
>  
> -static int __v4l2_async_notifier_register(struct v4l2_async_notifier 
> *notifier)
> +static int v4l2_async_notifier_asd_valid(struct v4l2_async_notifier 
> *notifier,
> +  struct v4l2_async_subdev *asd,
> +  unsigned int this_index)
>  {
>   struct device *dev =
>   notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL;
> +
> + if (!asd)
> + return -EINVAL;
> +
> + switch (asd->match_type) {
> + case V4L2_ASYNC_MATCH_CUSTOM:
> + case V4L2_ASYNC_MATCH_DEVNAME:
> + case V4L2_ASYNC_MATCH_I2C:
> + case V4L2_ASYNC_MATCH_FWNODE:
> + if (v4l2_async_notifier_has_async_subdev(notifier, asd,
> +  this_index))
> + return -EEXIST;
> + break;
> + default:
> + dev_err(dev, "Invalid match type %u on %p\n",
> + asd->match_type, asd);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static void __v4l2_async_notifier_init(struct v4l2_async_notifier *notifier)
> +{
> + lockdep_assert_held(_lock);
> +
> + INIT_LIST_HEAD(>asd_list);
> + INIT_LIST_HEAD(>waiting);
> + INIT_LIST_HEAD(>done);
> + notifier->lists_initialized = true;
> +}
> +
> +static int __v4l2_async_notifier_register(struct v4l2_async_notifier 
> *notifier)
> +{
>   struct v4l2_async_subdev *asd;
>   int ret;
>   int i;
> @@ -397,34 +443,40 @@ static int __v4l2_async_notifier_register(struct 
> v4l2_async_notifier *notifier)
>   if (notifier->num_subdevs > V4L2_MAX_SUBDEVS)
>   return -EINVAL;
>  
> - INIT_LIST_HEAD(>waiting);
> - INIT_LIST_HEAD(>done);
> -
>   mutex_lock(_lock);
>  
> - for (i = 0; i < notifier->num_subdevs; i++) {
> - asd 

Re: [PATCH v3 02/13] media: v4l2: async: Allow searching for asd of any type

[Hans Verkuil]

On 03/21/18 01:37, Steve Longerbeam wrote:
> Generalize v4l2_async_notifier_fwnode_has_async_subdev() to allow
> searching for any type of async subdev, not just fwnodes. Rename to
> v4l2_async_notifier_has_async_subdev() and pass it an asd pointer.
> 
> TODO: support asd compare with CUSTOM match type in asd_equal().
> 
> Signed-off-by: Steve Longerbeam 
> ---
> Changes since v2:
> - code optimization in asd_equal(), and remove unneeded braces,
>   suggested by Sakari Ailus.
> Changes since v1:
> - none
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 76 
> ++--
>  1 file changed, 46 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 2b08d03..b59bbac 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -124,6 +124,34 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
>   return NULL;
>  }
>  
> +/* Compare two asd's for equivalence */
> +static bool asd_equal(struct v4l2_async_subdev *asd_x,
> +   struct v4l2_async_subdev *asd_y)
> +{
> + if (asd_x->match_type != asd_y->match_type)
> + return false;
> +
> + switch (asd_x->match_type) {
> + case V4L2_ASYNC_MATCH_DEVNAME:
> + return strcmp(asd_x->match.device_name,
> +   asd_y->match.device_name) == 0;
> + case V4L2_ASYNC_MATCH_I2C:
> + return asd_x->match.i2c.adapter_id ==
> + asd_y->match.i2c.adapter_id &&
> + asd_x->match.i2c.address ==
> + asd_y->match.i2c.address;
> + case V4L2_ASYNC_MATCH_FWNODE:
> + return asd_x->match.fwnode == asd_y->match.fwnode;
> + case V4L2_ASYNC_MATCH_CUSTOM:
> + /* TODO */

This TODO suggests that this is needed for some driver(s) and that it
will be implemented later, but it seems more that nobody actually needs
this. If that's the case, then I'd just drop this case altogether.

Or do I misunderstand this comment?

Regards,

Hans

> + return false;
> + default:
> + break;
> + }
> +
> + return false;
> +}
> +
>  /* Find the sub-device notifier registered by a sub-device driver. */
>  static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
>   struct v4l2_subdev *sd)
> @@ -308,29 +336,22 @@ static void v4l2_async_notifier_unbind_all_subdevs(
>   notifier->parent = NULL;
>  }
>  
> -/* See if an fwnode can be found in a notifier's lists. */
> -static bool __v4l2_async_notifier_fwnode_has_async_subdev(
> - struct v4l2_async_notifier *notifier, struct fwnode_handle *fwnode)
> +/* See if an async sub-device can be found in a notifier's lists. */
> +static bool __v4l2_async_notifier_has_async_subdev(
> + struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd)
>  {
> - struct v4l2_async_subdev *asd;
> + struct v4l2_async_subdev *asd_y;
>   struct v4l2_subdev *sd;
>  
> - list_for_each_entry(asd, >waiting, list) {
> - if (asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
> - continue;
> -
> - if (asd->match.fwnode == fwnode)
> + list_for_each_entry(asd_y, >waiting, list)
> + if (asd_equal(asd, asd_y))
>   return true;
> - }
>  
>   list_for_each_entry(sd, >done, async_list) {
>   if (WARN_ON(!sd->asd))
>   continue;
>  
> - if (sd->asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
> - continue;
> -
> - if (sd->asd->match.fwnode == fwnode)
> + if (asd_equal(asd, sd->asd))
>   return true;
>   }
>  
> @@ -338,32 +359,28 @@ static bool 
> __v4l2_async_notifier_fwnode_has_async_subdev(
>  }
>  
>  /*
> - * Find out whether an async sub-device was set up for an fwnode already or
> + * Find out whether an async sub-device was set up already or
>   * whether it exists in a given notifier before @this_index.
>   */
> -static bool v4l2_async_notifier_fwnode_has_async_subdev(
> - struct v4l2_async_notifier *notifier, struct fwnode_handle *fwnode,
> +static bool v4l2_async_notifier_has_async_subdev(
> + struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd,
>   unsigned int this_index)
>  {
>   unsigned int j;
>  
>   lockdep_assert_held(_lock);
>  
> - /* Check that an fwnode is not being added more than once. */
> + /* Check that an asd is not being added more than once. */
>   for (j = 0; j < this_index; j++) {
> - struct v4l2_async_subdev *asd = notifier->subdevs[this_index];
> - struct v4l2_async_subdev *other_asd = notifier->subdevs[j];
> + struct v4l2_async_subdev *asd_y = notifier->subdevs[j];
>  
> - if (other_asd->match_type == V4L2_ASYNC_MATCH_FWNODE &&
> - 

Re: [PATCH v3 01/13] media: v4l2-fwnode: ignore endpoints that have no remote port parent

[Hans Verkuil]

On 03/21/18 01:37, Steve Longerbeam wrote:
> Documentation/devicetree/bindings/media/video-interfaces.txt states that
> the 'remote-endpoint' property is optional.
> 
> So v4l2_async_notifier_fwnode_parse_endpoint() should not return error
> if the endpoint has no remote port parent. Just ignore the endpoint,
> skip adding an asd to the notifier and return 0.
> __v4l2_async_notifier_parse_fwnode_endpoints() will then continue
> parsing the remaining port endpoints of the device.
> 
> Signed-off-by: Steve Longerbeam 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
> Changes since v2:
> - none
> Changes since v1:
> - don't pass an empty endpoint to the parse_endpoint callback,
>   v4l2_async_notifier_fwnode_parse_endpoint() now just ignores them
>   and returns success. The current users of
>   v4l2_async_notifier_parse_fwnode_endpoints() (omap3isp, rcar-vin,
>   intel-ipu3) no longer need modification.
> ---
>  drivers/media/v4l2-core/v4l2-fwnode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index d630640..b8afbac 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -363,7 +363,7 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
>   fwnode_graph_get_remote_port_parent(endpoint);
>   if (!asd->match.fwnode) {
>   dev_warn(dev, "bad remote port parent\n");
> - ret = -EINVAL;
> + ret = -ENOTCONN;
>   goto out_err;
>   }
>  
> 

Re: [PATCH v2 4/4] media: v4l2-compat-ioctl32: better document the code

[Hans Verkuil]

On 04/20/18 13:44, Mauro Carvalho Chehab wrote:
> Em Fri, 20 Apr 2018 13:16:00 +0200
> Hans Verkuil  escreveu:
> 
> Thanks for the review!
> 
>>> +/**
>>> + * do_video_ioctl() - Ancillary function with handles a compat32 ioctl call
>>> + *
>>> + * @file: pointer to  file with the file handler
>>> + * @cmd: ioctl to be called
>>> + * @arg: arguments passed from/to the ioctl handler
>>> + *
>>> + * This function is called when a 32 bits application calls a V4L2 ioctl
>>> + * and the Kernel is compiled with 64 bits.  
>>
>> Kernel -> kernel
> 
> Actually, in this case, "the Kernel" is referring to the "Linux Kernel",
> with is a particular, unique kernel. So, it should be on uppercase.

I'm fairly certain that's not how it works, but a native speaker should
pitch in on this. Anyway, it's not important :-)

Regards,

Hans

> 
> The remaining notes are OK. I'm enclosing the following diff and
> resending this patch with it folded in a few.
> 
> Thanks,
> Mauro
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index c460fbcbc035..9611c3aae8ca 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -26,7 +26,7 @@
>   * assign_in_user() - Copy from one __user var to another one
>   *
>   * @to: __user var where data will be stored
> - * @from: __user var were data will be retrieved.
> + * @from: __user var where data will be retrieved.
>   *
>   * As this code very often needs to allocate userspace memory, it is easier
>   * to have a macro that will do both get_user() and put_user() at once.
> @@ -46,12 +46,12 @@
>   *   pointer with userspace data that is not tagged with __user.
>   *
>   * @__x: var where data will be stored
> - * @__ptr: var were data will be retrieved.
> + * @__ptr: var where data will be retrieved.
>   *
> - * Sometimes, we need to declare a pointer without __user, because it
> + * Sometimes we need to declare a pointer without __user because it
>   * comes from a pointer struct field that will be retrieved from userspace
>   * by the 64-bit native ioctl handler. This function ensures that the
> - * @__ptr will be casted to __user before calling get_user(), in order to
> + * @__ptr will be cast to __user before calling get_user() in order to
>   * avoid warnings with static code analyzers like smatch.
>   */
>  #define get_user_cast(__x, __ptr)\
> @@ -60,16 +60,15 @@
>  })
>  
>  /**
> - * put_user_force() - Stores at the contents of a kernelspace local var
> + * put_user_force() - Stores the contents of a kernelspace local var
>   * into an userspace pointer, removing any __user cast.
>   *
>   * @__x: var where data will be stored
> - * @__ptr: var were data will be retrieved.
> + * @__ptr: var where data will be retrieved.
>   *
> - * As the compat32 code now handles with 32-bits and 64-bits __user
> - * structs, sometimes we need to remove the __user atributes from some data,
> - * by passing __force macro. This function ensures that the
> - * @__ptr will be casted with __force before calling put_user(), in order to
> + * Sometimes we need to remove the __user attribute from some data,
> + * by passing the __force macro. This function ensures that the
> + * @__ptr will be cast with __force before calling put_user(), in order to
>   * avoid warnings with static code analyzers like smatch.
>   */
>  #define put_user_force(__x, __ptr)   \
> @@ -81,7 +80,7 @@
>   * assign_in_user_cast() - Copy from one __user var to another one
>   *
>   * @to: __user var where data will be stored
> - * @from: var were data will be retrieved that needs to be cast to __user.
> + * @from: var where data will be retrieved that needs to be cast to __user.
>   *
>   * As this code very often needs to allocate userspace memory, it is easier
>   * to have a macro that will do both get_user_cast() and put_user() at once.
> @@ -1086,11 +1085,11 @@ static int put_v4l2_edid32(struct v4l2_edid __user 
> *p64,
>  }
>  
>  /*
> - * List of ioctl's that require 32-bits/64-bits conversion
> + * List of ioctls that require 32-bits/64-bits conversion
>   *
>   * The V4L2 ioctls that aren't listed there don't have pointer arguments
>   * and the struct size is identical for both 32 and 64 bits versions, so
> - * don't need translations.
> + * they don't need translations.
>   */
>  
>  #define VIDIOC_G_FMT32   _IOWR('V',  4, struct v4l2_format32)
> @@ -1125,8 +1124,8 @@ static int put_v4l2_edid32(struct v4l2_edid __user *p64,
>   *   for calling the native 64-bits version of an ioctl.
>   *
>   * @size:size of the structure itself to be allocated.
> - * @aux_space:   extra size needed to store "extra" data, e. g. space for
> - *   other __user data that comes pointed by fields inside the
> + * @aux_space:   extra size needed to store "extra" data, 

Re: [PATCH v2] media: v4l2-compat-ioctl32: better document the code

[Hans Verkuil]

On 04/20/18 13:45, Mauro Carvalho Chehab wrote:
> This file does a lot of non-trivial struff. Document it using
> kernel-doc markups where needed and improve the comments inside
> do_video_ioctl().
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 165 
> +-
>  1 file changed, 159 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index d2f0268427c2..9611c3aae8ca 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -22,7 +22,18 @@
>  #include 
>  #include 
>  
> -/* Use the same argument order as copy_in_user */
> +/**
> + * assign_in_user() - Copy from one __user var to another one
> + *
> + * @to: __user var where data will be stored
> + * @from: __user var where data will be retrieved.
> + *
> + * As this code very often needs to allocate userspace memory, it is easier
> + * to have a macro that will do both get_user() and put_user() at once.
> + *
> + * This function complements the macros defined at asm-generic/uaccess.h.
> + * It uses the same argument order as copy_in_user()
> + */
>  #define assign_in_user(to, from) \
>  ({   \
>   typeof(*from) __assign_tmp; \
> @@ -30,16 +41,56 @@
>   get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
>  })
>  
> +/**
> + * get_user_cast() - Stores at a kernelspace local var the contents from a
> + *   pointer with userspace data that is not tagged with __user.
> + *
> + * @__x: var where data will be stored
> + * @__ptr: var where data will be retrieved.
> + *
> + * Sometimes we need to declare a pointer without __user because it
> + * comes from a pointer struct field that will be retrieved from userspace
> + * by the 64-bit native ioctl handler. This function ensures that the
> + * @__ptr will be cast to __user before calling get_user() in order to
> + * avoid warnings with static code analyzers like smatch.
> + */
>  #define get_user_cast(__x, __ptr)\
>  ({   \
>   get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
>  })
>  
> +/**
> + * put_user_force() - Stores the contents of a kernelspace local var
> + * into an userspace pointer, removing any __user cast.
> + *
> + * @__x: var where data will be stored
> + * @__ptr: var where data will be retrieved.
> + *
> + * Sometimes we need to remove the __user attribute from some data,
> + * by passing the __force macro. This function ensures that the
> + * @__ptr will be cast with __force before calling put_user(), in order to
> + * avoid warnings with static code analyzers like smatch.
> + */
>  #define put_user_force(__x, __ptr)   \
>  ({   \
>   put_user((typeof(*__x) __force *)(__x), __ptr); \
>  })
>  
> +/**
> + * assign_in_user_cast() - Copy from one __user var to another one
> + *
> + * @to: __user var where data will be stored
> + * @from: var where data will be retrieved that needs to be cast to __user.
> + *
> + * As this code very often needs to allocate userspace memory, it is easier
> + * to have a macro that will do both get_user_cast() and put_user() at once.
> + *
> + * This function should be used instead of assign_in_user() when the @from
> + * variable was not declared as __user. See get_user_cast() for more details.
> + *
> + * This function complements the macros defined at asm-generic/uaccess.h.
> + * It uses the same argument order as copy_in_user()
> + */
>  #define assign_in_user_cast(to, from)
> \
>  ({   \
>   typeof(*from) __assign_tmp; \
> @@ -47,7 +98,16 @@
>   get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
>  })
>  
> -
> +/**
> + * native_ioctl - Ancillary function that calls the native 64 bits ioctl
> + * handler.
> + *
> + * @file: pointer to  file with the file handler
> + * @cmd: ioctl to be called
> + * @arg: arguments passed from/to the ioctl handler
> + *
> + * This function calls the native ioctl handler at v4l2-dev, e. g. 
> v4l2_ioctl()
> + */
>  static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
> arg)
>  {
>   long ret = -ENOIOCTLCMD;
> @@ -59,6 +119,21 @@ static long native_ioctl(struct file *file, unsigned int 
> cmd, unsigned long arg)
>  }
>  
>  
> +/*
> + * Per-ioctl data copy handlers.
> + *
> + * Those come in pairs, with a 

[PATCH v2] media: v4l2-compat-ioctl32: better document the code

[Mauro Carvalho Chehab]

This file does a lot of non-trivial struff. Document it using
kernel-doc markups where needed and improve the comments inside
do_video_ioctl().

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 165 +-
 1 file changed, 159 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index d2f0268427c2..9611c3aae8ca 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -22,7 +22,18 @@
 #include 
 #include 
 
-/* Use the same argument order as copy_in_user */
+/**
+ * assign_in_user() - Copy from one __user var to another one
+ *
+ * @to: __user var where data will be stored
+ * @from: __user var where data will be retrieved.
+ *
+ * As this code very often needs to allocate userspace memory, it is easier
+ * to have a macro that will do both get_user() and put_user() at once.
+ *
+ * This function complements the macros defined at asm-generic/uaccess.h.
+ * It uses the same argument order as copy_in_user()
+ */
 #define assign_in_user(to, from)   \
 ({ \
typeof(*from) __assign_tmp; \
@@ -30,16 +41,56 @@
get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
 })
 
+/**
+ * get_user_cast() - Stores at a kernelspace local var the contents from a
+ * pointer with userspace data that is not tagged with __user.
+ *
+ * @__x: var where data will be stored
+ * @__ptr: var where data will be retrieved.
+ *
+ * Sometimes we need to declare a pointer without __user because it
+ * comes from a pointer struct field that will be retrieved from userspace
+ * by the 64-bit native ioctl handler. This function ensures that the
+ * @__ptr will be cast to __user before calling get_user() in order to
+ * avoid warnings with static code analyzers like smatch.
+ */
 #define get_user_cast(__x, __ptr)  \
 ({ \
get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
 })
 
+/**
+ * put_user_force() - Stores the contents of a kernelspace local var
+ *   into an userspace pointer, removing any __user cast.
+ *
+ * @__x: var where data will be stored
+ * @__ptr: var where data will be retrieved.
+ *
+ * Sometimes we need to remove the __user attribute from some data,
+ * by passing the __force macro. This function ensures that the
+ * @__ptr will be cast with __force before calling put_user(), in order to
+ * avoid warnings with static code analyzers like smatch.
+ */
 #define put_user_force(__x, __ptr) \
 ({ \
put_user((typeof(*__x) __force *)(__x), __ptr); \
 })
 
+/**
+ * assign_in_user_cast() - Copy from one __user var to another one
+ *
+ * @to: __user var where data will be stored
+ * @from: var where data will be retrieved that needs to be cast to __user.
+ *
+ * As this code very often needs to allocate userspace memory, it is easier
+ * to have a macro that will do both get_user_cast() and put_user() at once.
+ *
+ * This function should be used instead of assign_in_user() when the @from
+ * variable was not declared as __user. See get_user_cast() for more details.
+ *
+ * This function complements the macros defined at asm-generic/uaccess.h.
+ * It uses the same argument order as copy_in_user()
+ */
 #define assign_in_user_cast(to, from)  \
 ({ \
typeof(*from) __assign_tmp; \
@@ -47,7 +98,16 @@
get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
 })
 
-
+/**
+ * native_ioctl - Ancillary function that calls the native 64 bits ioctl
+ * handler.
+ *
+ * @file: pointer to  file with the file handler
+ * @cmd: ioctl to be called
+ * @arg: arguments passed from/to the ioctl handler
+ *
+ * This function calls the native ioctl handler at v4l2-dev, e. g. v4l2_ioctl()
+ */
 static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
arg)
 {
long ret = -ENOIOCTLCMD;
@@ -59,6 +119,21 @@ static long native_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
 }
 
 
+/*
+ * Per-ioctl data copy handlers.
+ *
+ * Those come in pairs, with a get_v4l2_foo() and a put_v4l2_foo() routine,
+ * where "v4l2_foo" is the name of the V4L2 struct.
+ *
+ * They basically get two __user pointers, one with a 32-bits struct that
+ * came from the userspace call and a 64-bits struct, also allocated as
+ * userspace, but filled internally by do_video_ioctl().
+ *
+ * For ioctls that have pointers 

Re: [PATCH v2 4/4] media: v4l2-compat-ioctl32: better document the code

[Mauro Carvalho Chehab]

Em Fri, 20 Apr 2018 13:16:00 +0200
Hans Verkuil  escreveu:

Thanks for the review!

> > +/**
> > + * do_video_ioctl() - Ancillary function with handles a compat32 ioctl call
> > + *
> > + * @file: pointer to  file with the file handler
> > + * @cmd: ioctl to be called
> > + * @arg: arguments passed from/to the ioctl handler
> > + *
> > + * This function is called when a 32 bits application calls a V4L2 ioctl
> > + * and the Kernel is compiled with 64 bits.  
> 
> Kernel -> kernel

Actually, in this case, "the Kernel" is referring to the "Linux Kernel",
with is a particular, unique kernel. So, it should be on uppercase.

The remaining notes are OK. I'm enclosing the following diff and
resending this patch with it folded in a few.

Thanks,
Mauro

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index c460fbcbc035..9611c3aae8ca 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -26,7 +26,7 @@
  * assign_in_user() - Copy from one __user var to another one
  *
  * @to: __user var where data will be stored
- * @from: __user var were data will be retrieved.
+ * @from: __user var where data will be retrieved.
  *
  * As this code very often needs to allocate userspace memory, it is easier
  * to have a macro that will do both get_user() and put_user() at once.
@@ -46,12 +46,12 @@
  * pointer with userspace data that is not tagged with __user.
  *
  * @__x: var where data will be stored
- * @__ptr: var were data will be retrieved.
+ * @__ptr: var where data will be retrieved.
  *
- * Sometimes, we need to declare a pointer without __user, because it
+ * Sometimes we need to declare a pointer without __user because it
  * comes from a pointer struct field that will be retrieved from userspace
  * by the 64-bit native ioctl handler. This function ensures that the
- * @__ptr will be casted to __user before calling get_user(), in order to
+ * @__ptr will be cast to __user before calling get_user() in order to
  * avoid warnings with static code analyzers like smatch.
  */
 #define get_user_cast(__x, __ptr)  \
@@ -60,16 +60,15 @@
 })
 
 /**
- * put_user_force() - Stores at the contents of a kernelspace local var
+ * put_user_force() - Stores the contents of a kernelspace local var
  *   into an userspace pointer, removing any __user cast.
  *
  * @__x: var where data will be stored
- * @__ptr: var were data will be retrieved.
+ * @__ptr: var where data will be retrieved.
  *
- * As the compat32 code now handles with 32-bits and 64-bits __user
- * structs, sometimes we need to remove the __user atributes from some data,
- * by passing __force macro. This function ensures that the
- * @__ptr will be casted with __force before calling put_user(), in order to
+ * Sometimes we need to remove the __user attribute from some data,
+ * by passing the __force macro. This function ensures that the
+ * @__ptr will be cast with __force before calling put_user(), in order to
  * avoid warnings with static code analyzers like smatch.
  */
 #define put_user_force(__x, __ptr) \
@@ -81,7 +80,7 @@
  * assign_in_user_cast() - Copy from one __user var to another one
  *
  * @to: __user var where data will be stored
- * @from: var were data will be retrieved that needs to be cast to __user.
+ * @from: var where data will be retrieved that needs to be cast to __user.
  *
  * As this code very often needs to allocate userspace memory, it is easier
  * to have a macro that will do both get_user_cast() and put_user() at once.
@@ -1086,11 +1085,11 @@ static int put_v4l2_edid32(struct v4l2_edid __user *p64,
 }
 
 /*
- * List of ioctl's that require 32-bits/64-bits conversion
+ * List of ioctls that require 32-bits/64-bits conversion
  *
  * The V4L2 ioctls that aren't listed there don't have pointer arguments
  * and the struct size is identical for both 32 and 64 bits versions, so
- * don't need translations.
+ * they don't need translations.
  */
 
 #define VIDIOC_G_FMT32 _IOWR('V',  4, struct v4l2_format32)
@@ -1125,8 +1124,8 @@ static int put_v4l2_edid32(struct v4l2_edid __user *p64,
  * for calling the native 64-bits version of an ioctl.
  *
  * @size:  size of the structure itself to be allocated.
- * @aux_space: extra size needed to store "extra" data, e. g. space for
- * other __user data that comes pointed by fields inside the
+ * @aux_space: extra size needed to store "extra" data, e.g. space for
+ * other __user data that is pointed to fields inside the
  * structure.
  * @new_p64:   pointer to a pointer to be filled with the allocated struct.
  *
@@ -1160,7 +1159,7 @@ static int alloc_userspace(unsigned int size, u32 
aux_space,
  * not private to some specific driver.
  *
  * It converts a 32-bits struct into a 64 bits one, calls the native 

Re: [PATCH v2 4/4] media: v4l2-compat-ioctl32: better document the code

[Hans Verkuil]

Hi Mauro,

A bunch of typo, grammar and style fixes below. Looks good otherwise.

On 04/19/18 18:33, Mauro Carvalho Chehab wrote:
> This file does a lot of non-trivial struff. Document it using
> kernel-doc markups where needed and improve the comments inside
> do_video_ioctl().
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 166 
> +-
>  1 file changed, 160 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index d2f0268427c2..777ed179af5f 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -22,7 +22,18 @@
>  #include 
>  #include 
>  
> -/* Use the same argument order as copy_in_user */
> +/**
> + * assign_in_user() - Copy from one __user var to another one
> + *
> + * @to: __user var where data will be stored
> + * @from: __user var were data will be retrieved.

were -> where

> + *
> + * As this code very often needs to allocate userspace memory, it is easier
> + * to have a macro that will do both get_user() and put_user() at once.
> + *
> + * This function complements the macros defined at asm-generic/uaccess.h.
> + * It uses the same argument order as copy_in_user()
> + */
>  #define assign_in_user(to, from) \
>  ({   \
>   typeof(*from) __assign_tmp; \
> @@ -30,16 +41,57 @@
>   get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
>  })
>  
> +/**
> + * get_user_cast() - Stores at a kernelspace local var the contents from a
> + *   pointer with userspace data that is not tagged with __user.
> + *
> + * @__x: var where data will be stored
> + * @ptr: var were data will be retrieved.

were -> where

> + *
> + * Sometimes, we need to declare a pointer without __user, because it

The two commas in this sentence can be dropped.

> + * comes from a pointer struct field that will be retrieved from userspace
> + * by the 64-bit native ioctl handler. This function ensures that the
> + * @ptr will be casted to __user before calling get_user(), in order to

casted -> cast

The comma can be dropped.

> + * avoid warnings with static code analyzers like smatch.
> + */
>  #define get_user_cast(__x, __ptr)\
>  ({   \
>   get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
>  })
>  
> +/**
> + * put_user_force() - Stores at the contents of a kernelspace local var

s/at//

> + * into an userspace pointer, removing any __user cast.
> + *
> + * @__x: var where data will be stored
> + * @ptr: var were data will be retrieved.

were -> where

> + *
> + * As the compat32 code now handles with 32-bits and 64-bits __user

I don't understand this first line. Perhaps this line up to the comma
below should just be dropped? And instead start with 'Sometimes we need to...'.

> + * structs, sometimes we need to remove the __user atributes from some data,

atributes -> attribute

> + * by passing __force macro. This function ensures that the

'by passing the __force macro'

> + * @ptr will be casted with __force before calling put_user(), in order to

casted -> cast

> + * avoid warnings with static code analyzers like smatch.
> + */
>  #define put_user_force(__x, __ptr)   \
>  ({   \
>   put_user((typeof(*__x) __force *)(__x), __ptr); \
>  })
>  
> +/**
> + * assign_in_user_cast() - Copy from one __user var to another one
> + *
> + * @to: __user var where data will be stored
> + * @from: var were data will be retrieved that needs to be cast to __user.

were -> where

> + *
> + * As this code very often needs to allocate userspace memory, it is easier
> + * to have a macro that will do both get_user_cast() and put_user() at once.
> + *
> + * This function should be used instead of assign_in_user() when the @from
> + * variable was not declared as __user. See get_user_cast() for more details.
> + *
> + * This function complements the macros defined at asm-generic/uaccess.h.
> + * It uses the same argument order as copy_in_user()
> + */
>  #define assign_in_user_cast(to, from)
> \
>  ({   \
>   typeof(*from) __assign_tmp; \
> @@ -47,7 +99,16 @@
>   get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
>  })
>  
> -
> +/**
> + * native_ioctl - Ancillary function that calls the native 64 bits ioctl
> + * handler.
> + *
> + * @file: pointer to  file with the file handler
> + * @cmd: ioctl to be called
> + * 

Re: [PATCH v2 3/4] media: v4l2-compat-ioctl32: simplify casts

[Hans Verkuil]

On 04/19/18 18:33, Mauro Carvalho Chehab wrote:
> Making the cast right for get_user/put_user is not trivial, as
> it needs to ensure that the types are the correct ones.
> 
> Improve it by using macros.
> 
> Tested with vivid with:
>   $ sudo modprobe vivid no_error_inj=1
>   $ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a 
> -s10 > 64bits && diff -U0 32bits 64bits
>   --- 32bits  2018-04-17 11:18:29.141240772 -0300
>   +++ 64bits  2018-04-17 11:18:40.635282341 -0300
>   @@ -1 +1 @@
>   -v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 
> bits
>   +v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 
> bits
> 
> Using the latest version of v4l-utils with this patch applied:
>   https://patchwork.linuxtv.org/patch/48746/
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 36 
> +++
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 680b64c1d69a..d2f0268427c2 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -30,6 +30,24 @@
>   get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
>  })
>  
> +#define get_user_cast(__x, __ptr)\
> +({   \
> + get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
> +})
> +
> +#define put_user_force(__x, __ptr)   \
> +({   \
> + put_user((typeof(*__x) __force *)(__x), __ptr); \
> +})
> +
> +#define assign_in_user_cast(to, from)
> \
> +({   \
> + typeof(*from) __assign_tmp; \
> + \
> + get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
> +})
> +
> +
>  static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
> arg)
>  {
>   long ret = -ENOIOCTLCMD;
> @@ -543,8 +561,7 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user 
> *p64,
>   return -EFAULT;
>  
>   uplane = aux_buf;
> - if (put_user((__force struct v4l2_plane *)uplane,
> -  >m.planes))
> + if (put_user_force(uplane, >m.planes))
>   return -EFAULT;
>  
>   while (num_planes--) {
> @@ -682,7 +699,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
> __user *p64,
>  
>   if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
>   get_user(tmp, >base) ||
> - put_user((void __force *)compat_ptr(tmp), >base) ||
> + put_user_force(compat_ptr(tmp), >base) ||
>   assign_in_user(>capability, >capability) ||
>   assign_in_user(>flags, >flags) ||
>   copy_in_user(>fmt, >fmt, sizeof(p64->fmt)))
> @@ -831,8 +848,7 @@ static int get_v4l2_ext_controls32(struct file *file,
>   if (aux_space < count * sizeof(*kcontrols))
>   return -EFAULT;
>   kcontrols = aux_buf;
> - if (put_user((__force struct v4l2_ext_control *)kcontrols,
> -  >controls))
> + if (put_user_force(kcontrols, >controls))
>   return -EFAULT;
>  
>   for (n = 0; n < count; n++) {
> @@ -898,10 +914,9 @@ static int put_v4l2_ext_controls32(struct file *file,
>   unsigned int size = sizeof(*ucontrols);
>   u32 id;
>  
> - if (get_user(id, (unsigned int __user *)>id) ||
> + if (get_user_cast(id, >id) ||
>   put_user(id, >id) ||
> - assign_in_user(>size,
> -(unsigned int __user *)>size) ||
> + assign_in_user_cast(>size, >size) ||
>   copy_in_user(>reserved2,
>(void __user *)>reserved2,
>sizeof(ucontrols->reserved2)))
> @@ -970,10 +985,9 @@ static int get_v4l2_edid32(struct v4l2_edid __user *p64,
>   if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
>   assign_in_user(>pad, >pad) ||
>   assign_in_user(>start_block, >start_block) ||
> - assign_in_user(>blocks,
> -(u32 __user *)>blocks) ||
> + assign_in_user_cast(>blocks, >blocks) ||
>   get_user(tmp, >edid) ||
> - put_user((void __force *)compat_ptr(tmp), >edid) ||
> + put_user_force(compat_ptr(tmp), >edid) ||
>   copy_in_user(p64->reserved, 

Re: [PATCH v2 1/4] media: v4l2-compat-ioctl32: fix several __user annotations

[Hans Verkuil]

On 04/19/18 18:33, Mauro Carvalho Chehab wrote:
> Smatch report several issues with bad __user annotations:
> 
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:got void *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:expected void 
> const volatile [noderef] *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:got struct 
> v4l2_plane [noderef] **
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:got void 
> *[assigned] base
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect 
> type in assignment (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:expected struct 
> v4l2_ext_control [noderef] *kcontrols
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:got struct 
> v4l2_ext_control *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect 
> type in assignment (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:expected unsigned 
> char [usertype] *__pu_val
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:got void [noderef] 
> *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:got void 
> *[assigned] edid
> 
> Fix them.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 51 
> ++-
>  1 file changed, 35 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index d03a44d89649..51c7c5ab15ef 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -443,8 +443,8 @@ static int put_v4l2_plane32(struct v4l2_plane __user *up,
>   return -EFAULT;
>   break;
>   case V4L2_MEMORY_USERPTR:
> - if (get_user(p, >m.userptr) ||
> - put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
> + if (get_user(p, >m.userptr)||
> + put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
>>m.userptr))
>   return -EFAULT;
>   break;
> @@ -587,7 +587,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> *kp,
>   u32 length;
>   enum v4l2_memory memory;
>   struct v4l2_plane32 __user *uplane32;
> - struct v4l2_plane __user *uplane;
> + struct v4l2_plane *uplane;
>   compat_caddr_t p;
>   int ret;
>  
> @@ -617,15 +617,22 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> *kp,
>  
>   if (num_planes == 0)
>   return 0;
> -
> - if (get_user(uplane, ((__force struct v4l2_plane __user 
> **)>m.planes)))
> + /* We need to define uplane without __user, even though
> +  * it does point to data in userspace here. The reason is
> +  * that v4l2-ioctl.c copies it from userspace to kernelspace,
> +  * so its definition in videodev2.h doesn't have a
> +  * __user markup. Defining uplane with __user causes
> +  * smatch warnings, so instead declare it without __user
> +  * and cast it as a userspace pointer to put_v4l2_plane32().
> +  */
> + if (get_user(uplane, >m.planes))
>   return -EFAULT;
>   if (get_user(p, >m.planes))
>   return -EFAULT;
>   uplane32 = compat_ptr(p);
>  
>   while (num_planes--) {
> - ret = put_v4l2_plane32(uplane, uplane32, memory);
> + ret = put_v4l2_plane32((void __user *)uplane, uplane32, 
> memory);
>   if (ret)
>   return ret;
>   ++uplane;
> @@ -675,7 +682,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
> __user *kp,
>  
>   if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
>   get_user(tmp, >base) ||
> - put_user((__force void *)compat_ptr(tmp), >base) ||
> 

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

[Christian König]

Am 20.04.2018 um 12:17 schrieb Christoph Hellwig:

On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:

Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into  dma-buf", but that doesn't render the interface a bad idea.

Completely agree on that.

What we need is an sg_alloc_table_from_resources(dev, resources,
num_resources) which does the handling common to all drivers.

A structure that contains

{page,offset,len} + {dma_addr+dma_len}

is not a good container for storing

{virt addr, dma_addr, len}

no matter what interface you build arond it.


Why not? I mean at least for my use case we actually don't need the 
virtual address.


What we need is {dma_addr+dma_len} in a consistent interface which can 
come from both {page,offset,len} as well as {resource, len}.


What I actually don't need is separate handling for system memory and 
resources, but that would we get exactly when we don't use sg_table.


Christian.


And that is discounting
all the problems around mapping coherent allocations for other devices,
or the iommu merging problem we are having another thread on.

So let's come up with a better high level interface first, and then
worrty about how to implement it in the low-level dma-mapping interface
second.  Especially given that my consolidation of the dma_map_ops
implementation is in full stream and there shoudn't be all that many
to bother with.

So first question:  Do you actually care about having multiple
pairs of the above, or instead of all chunks just deal with a single
of the above?  In that case we really should not need that many
new interfaces as dma_map_resource will be all you need anyway.


Christian.


-Daniel

---end quoted text---

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

[Christoph Hellwig]

On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
> > Yes there's a bit a layering violation insofar that drivers really
> > shouldn't each have their own copy of "how do I convert a piece of dma
> > memory into  dma-buf", but that doesn't render the interface a bad idea.
> 
> Completely agree on that.
> 
> What we need is an sg_alloc_table_from_resources(dev, resources,
> num_resources) which does the handling common to all drivers.

A structure that contains

{page,offset,len} + {dma_addr+dma_len}

is not a good container for storing

{virt addr, dma_addr, len}

no matter what interface you build arond it.  And that is discounting
all the problems around mapping coherent allocations for other devices,
or the iommu merging problem we are having another thread on.

So let's come up with a better high level interface first, and then
worrty about how to implement it in the low-level dma-mapping interface
second.  Especially given that my consolidation of the dma_map_ops
implementation is in full stream and there shoudn't be all that many
to bother with.

So first question:  Do you actually care about having multiple
pairs of the above, or instead of all chunks just deal with a single
of the above?  In that case we really should not need that many
new interfaces as dma_map_resource will be all you need anyway.

> 
> Christian.
> 
> > -Daniel
> 
---end quoted text---

[PATCH] media: vpbe_venc: potential uninitialized variable in ven_sub_dev_init()

[Dan Carpenter]

Smatch complains that "venc" could be unintialized.  There a couple
error paths where it looks like maybe that could happen.  I don't know
if it's really a bug, but it's reasonable to set "venc" to NULL and
silence the warning.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/platform/davinci/vpbe_venc.c 
b/drivers/media/platform/davinci/vpbe_venc.c
index 5c255de3b3f8..ba157827192c 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -606,7 +606,7 @@ static int venc_device_get(struct device *dev, void *data)
 struct v4l2_subdev *venc_sub_dev_init(struct v4l2_device *v4l2_dev,
const char *venc_name)
 {
-   struct venc_state *venc;
+   struct venc_state *venc = NULL;
 
bus_for_each_dev(_bus_type, NULL, ,
venc_device_get);

[PATCH] media: davinci_vpfe: fix some potential overflows

[Dan Carpenter]

We check "lutdpc->dpc_size" in ipipe_validate_lutdpc_params() but if
it's invalid then we would have corrupted memory already when we do
the memcpy() before calling it.

We don't ever check "gamma->tbl_size" but we should since they come from
the user.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 95942768639c..068be224 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -82,6 +82,8 @@ static int ipipe_set_lutdpc_params(struct vpfe_ipipe_device 
*ipipe, void *param)
lutdpc->en = dpc_param->en;
lutdpc->repl_white = dpc_param->repl_white;
lutdpc->dpc_size = dpc_param->dpc_size;
+   if (dpc_param->dpc_size > LUT_DPC_MAX_SIZE)
+   return -EINVAL;
memcpy(>table, _param->table,
   (dpc_param->dpc_size * sizeof(struct vpfe_ipipe_lutdpc_entry)));
if (ipipe_validate_lutdpc_params(lutdpc) < 0)
@@ -591,7 +593,7 @@ ipipe_validate_gamma_entry(struct vpfe_ipipe_gamma_entry 
*table, int size)
 static int
 ipipe_validate_gamma_params(struct vpfe_ipipe_gamma *gamma, struct device *dev)
 {
-   int table_size;
+   unsigned int table_size;
int err;
 
if (gamma->bypass_r > 1 ||
@@ -603,6 +605,8 @@ ipipe_validate_gamma_params(struct vpfe_ipipe_gamma *gamma, 
struct device *dev)
return 0;
 
table_size = gamma->tbl_size;
+   if (table_size > VPFE_IPIPE_MAX_SIZE_GAMMA)
+   return -EINVAL;
if (!gamma->bypass_r) {
err = ipipe_validate_gamma_entry(gamma->table_r, table_size);
if (err) {

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

[Tomasz Figa]

Hi Paul,

On Fri, Apr 20, 2018 at 12:46 AM Paul Kocialkowski <
paul.kocialkow...@bootlin.com> wrote:
[snip]
> +struct v4l2_ctrl_mpeg2_frame_hdr {
> +   __u32 slice_len;
> +   __u32 slice_pos;
> +   enum { MPEG1, MPEG2 } type;

Is enum suitable for UAPI?

> +
> +   __u16 width;
> +   __u16 height;
> +
> +   enum { PCT_I = 1, PCT_P, PCT_B, PCT_D } picture_coding_type;

Ditto.

> +   __u8 f_code[2][2];
> +
> +   __u8 intra_dc_precision;
> +   __u8 picture_structure;
> +   __u8 top_field_first;
> +   __u8 frame_pred_frame_dct;
> +   __u8 concealment_motion_vectors;
> +   __u8 q_scale_type;
> +   __u8 intra_vlc_format;
> +   __u8 alternate_scan;
> +
> +   __u8 backward_ref_index;
> +   __u8 forward_ref_index;
> +};
> +
>   #endif
> diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h
> index 31b5728b56e9..4b8336f7bcf0 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -635,6 +635,7 @@ struct v4l2_pix_format {
>   #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /*
SMPTE 421M Annex L compliant stream */
>   #define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
>   #define V4L2_PIX_FMT_VP9  v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> +#define V4L2_PIX_FMT_MPEG2_FRAME v4l2_fourcc('M', 'G', '2', 'F') /*
MPEG2 frame */

>   /*  Vendor-specific formats   */
>   #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1
YUV */
> @@ -1586,6 +1587,7 @@ struct v4l2_ext_control {
>  __u8 __user *p_u8;
>  __u16 __user *p_u16;
>  __u32 __user *p_u32;
> +   struct v4l2_ctrl_mpeg2_frame_hdr __user
*p_mpeg2_frame_hdr;
>  void __user *ptr;
>  };
>   } __attribute__ ((packed));
> @@ -1631,6 +1633,7 @@ enum v4l2_ctrl_type {
>  V4L2_CTRL_TYPE_U8= 0x0100,
>  V4L2_CTRL_TYPE_U16   = 0x0101,
>  V4L2_CTRL_TYPE_U32   = 0x0102,
> +   V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,

Why 0x0109?

Best regards,
Tomasz

[PATCH 1/3] media: ov5640: initialize mode data structs by name

[Daniel Mack]

This patch initializes the members of struct ov5640_mode_info by name for
better readability. This makes later additions to this struct easier.

No functional change intended.

Signed-off-by: Daniel Mack 
---
 drivers/media/i2c/ov5640.c | 207 +
 1 file changed, 152 insertions(+), 55 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 852026baa2e7..96f1564abdf5 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -728,67 +728,164 @@ static const struct reg_value 
ov5640_setting_15fps_QSXGA_2592_1944[] = {
 
 /* power-on sensor init reg table */
 static const struct ov5640_mode_info ov5640_mode_init_data = {
-   0, SUBSAMPLING, 640, 480, ov5640_init_setting_30fps_VGA,
-   ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
+   .id = 0,
+   .dn_mode= SUBSAMPLING,
+   .width  = 640,
+   .height = 480,
+   .reg_data   = ov5640_init_setting_30fps_VGA,
+   .reg_data_size  = ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
 };
 
 static const struct ov5640_mode_info
 ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = {
+{
+   {
+   .id = OV5640_MODE_QCIF_176_144,
+   .dn_mode= SUBSAMPLING,
+   .width  = 176,
+   .height = 144,
+   .reg_data   = ov5640_setting_15fps_QCIF_176_144,
+   .reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144),
+   },
+   {
+   .id = OV5640_MODE_QVGA_320_240,
+   .dn_mode= SUBSAMPLING,
+   .width  = 320,
+   .height = 240,
+   .reg_data   = ov5640_setting_15fps_QVGA_320_240,
+   .reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240),
+   },
{
-   {OV5640_MODE_QCIF_176_144, SUBSAMPLING, 176, 144,
-ov5640_setting_15fps_QCIF_176_144,
-ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
-   {OV5640_MODE_QVGA_320_240, SUBSAMPLING, 320,  240,
-ov5640_setting_15fps_QVGA_320_240,
-ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
-   {OV5640_MODE_VGA_640_480, SUBSAMPLING, 640,  480,
-ov5640_setting_15fps_VGA_640_480,
-ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
-   {OV5640_MODE_NTSC_720_480, SUBSAMPLING, 720, 480,
-ov5640_setting_15fps_NTSC_720_480,
-ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
-   {OV5640_MODE_PAL_720_576, SUBSAMPLING, 720, 576,
-ov5640_setting_15fps_PAL_720_576,
-ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)},
-   {OV5640_MODE_XGA_1024_768, SUBSAMPLING, 1024, 768,
-ov5640_setting_15fps_XGA_1024_768,
-ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)},
-   {OV5640_MODE_720P_1280_720, SUBSAMPLING, 1280, 720,
-ov5640_setting_15fps_720P_1280_720,
-ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)},
-   {OV5640_MODE_1080P_1920_1080, SCALING, 1920, 1080,
-ov5640_setting_15fps_1080P_1920_1080,
-ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)},
-   {OV5640_MODE_QSXGA_2592_1944, SCALING, 2592, 1944,
-ov5640_setting_15fps_QSXGA_2592_1944,
-ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)},
-   }, {
-   {OV5640_MODE_QCIF_176_144, SUBSAMPLING, 176, 144,
-ov5640_setting_30fps_QCIF_176_144,
-ARRAY_SIZE(ov5640_setting_30fps_QCIF_176_144)},
-   {OV5640_MODE_QVGA_320_240, SUBSAMPLING, 320,  240,
-ov5640_setting_30fps_QVGA_320_240,
-ARRAY_SIZE(ov5640_setting_30fps_QVGA_320_240)},
-   {OV5640_MODE_VGA_640_480, SUBSAMPLING, 640,  480,
-ov5640_setting_30fps_VGA_640_480,
-ARRAY_SIZE(ov5640_setting_30fps_VGA_640_480)},
-   {OV5640_MODE_NTSC_720_480, SUBSAMPLING, 720, 480,
-ov5640_setting_30fps_NTSC_720_480,
-ARRAY_SIZE(ov5640_setting_30fps_NTSC_720_480)},
-   {OV5640_MODE_PAL_720_576, SUBSAMPLING, 720, 576,
-ov5640_setting_30fps_PAL_720_576,
-ARRAY_SIZE(ov5640_setting_30fps_PAL_720_576)},
-   {OV5640_MODE_XGA_1024_768, SUBSAMPLING, 1024, 768,
-ov5640_setting_30fps_XGA_1024_768,
-ARRAY_SIZE(ov5640_setting_30fps_XGA_1024_768)},
-   {OV5640_MODE_720P_1280_720, SUBSAMPLING, 1280, 720,
-ov5640_setting_30fps_720P_1280_720,
-ARRAY_SIZE(ov5640_setting_30fps_720P_1280_720)},
-   {OV5640_MODE_1080P_1920_1080, SCALING, 1920, 1080,
-

[PATCH 3/3] media: ov5640: add support for xclk frequency control

[Daniel Mack]

Allow setting the xclk rate via an optional 'clock-frequency' property in
the device tree node.

Signed-off-by: Daniel Mack 
---
 Documentation/devicetree/bindings/media/i2c/ov5640.txt |  2 ++
 drivers/media/i2c/ov5640.c | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
index 8e36da0d8406..584bbc944978 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -13,6 +13,8 @@ Optional Properties:
   This is an active low signal to the OV5640.
 - powerdown-gpios: reference to the GPIO connected to the powerdown pin,
   if any. This is an active high signal to the OV5640.
+- clock-frequency: frequency to set on the xclk input clock. The clock
+  is left untouched if this property is missing.
 
 The device node must contain one 'port' child node for its digital output
 video port, in accordance with the video interface bindings defined in
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 78669ed386cd..2d94d6dbda5d 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2685,6 +2685,7 @@ static int ov5640_probe(struct i2c_client *client,
struct fwnode_handle *endpoint;
struct ov5640_dev *sensor;
struct v4l2_mbus_framefmt *fmt;
+   u32 freq;
int ret;
 
sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
@@ -2731,6 +2732,15 @@ static int ov5640_probe(struct i2c_client *client,
return PTR_ERR(sensor->xclk);
}
 
+   ret = of_property_read_u32(dev->of_node, "clock-frequency", );
+   if (ret == 0) {
+   ret = clk_set_rate(sensor->xclk, freq);
+   if (ret) {
+   dev_err(dev, "could not set xclk frequency\n");
+   return ret;
+   }
+   }
+
sensor->xclk_freq = clk_get_rate(sensor->xclk);
if (sensor->xclk_freq < OV5640_XCLK_MIN ||
sensor->xclk_freq > OV5640_XCLK_MAX) {
-- 
2.14.3

[PATCH 2/3] media: ov5640: add PIXEL_RATE and LINK_FREQ controls

[Daniel Mack]

Add v4l2 controls to report the pixel and MIPI link rates of each mode.
The camss camera subsystem needs them to set up the correct hardware
clocks.

Tested on msm8016 based hardware.

Signed-off-by: Daniel Mack 
---
 drivers/media/i2c/ov5640.c | 77 ++
 1 file changed, 77 insertions(+)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 96f1564abdf5..78669ed386cd 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -91,6 +91,20 @@
 #define OV5640_REG_SDE_CTRL5   0x5585
 #define OV5640_REG_AVG_READOUT 0x56a1
 
+#define OV5640_LINK_FREQ_111   0
+#define OV5640_LINK_FREQ_166   1
+#define OV5640_LINK_FREQ_222   2
+#define OV5640_LINK_FREQ_333   3
+#define OV5640_LINK_FREQ_666   4
+
+static const s64 link_freq_menu_items[] = {
+   11106,
+   16660,
+   22213,
+   33220,
+   66640,
+};
+
 enum ov5640_mode_id {
OV5640_MODE_QCIF_176_144 = 0,
OV5640_MODE_QVGA_320_240,
@@ -167,12 +181,18 @@ struct ov5640_mode_info {
enum ov5640_downsize_mode dn_mode;
u32 width;
u32 height;
+   u32 pixel_rate;
+   u32 link_freq_idx;
const struct reg_value *reg_data;
u32 reg_data_size;
 };
 
 struct ov5640_ctrls {
struct v4l2_ctrl_handler handler;
+   struct {
+   struct v4l2_ctrl *link_freq;
+   struct v4l2_ctrl *pixel_rate;
+   };
struct {
struct v4l2_ctrl *auto_exp;
struct v4l2_ctrl *exposure;
@@ -732,6 +752,8 @@ static const struct ov5640_mode_info ov5640_mode_init_data 
= {
.dn_mode= SUBSAMPLING,
.width  = 640,
.height = 480,
+   .pixel_rate = 2776,
+   .link_freq_idx  = OV5640_LINK_FREQ_111,
.reg_data   = ov5640_init_setting_30fps_VGA,
.reg_data_size  = ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
 };
@@ -744,6 +766,8 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = 
{
.dn_mode= SUBSAMPLING,
.width  = 176,
.height = 144,
+   .pixel_rate = 2776,
+   .link_freq_idx  = OV5640_LINK_FREQ_111,
.reg_data   = ov5640_setting_15fps_QCIF_176_144,
.reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144),
},
@@ -752,6 +776,8 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = 
{
.dn_mode= SUBSAMPLING,
.width  = 320,
.height = 240,
+   .pixel_rate = 2776,
+   .link_freq_idx  = OV5640_LINK_FREQ_111,
.reg_data   = ov5640_setting_15fps_QVGA_320_240,
.reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240),
},
@@ -760,6 +786,8 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = 
{
.dn_mode= SUBSAMPLING,
.width  = 640,
.height = 480,
+   .pixel_rate = 2776,
+   .link_freq_idx  = OV5640_LINK_FREQ_111,
.reg_data   = ov5640_setting_15fps_VGA_640_480,
.reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)
},
@@ -768,6 +796,8 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = 
{
.dn_mode= SUBSAMPLING,
.width  = 720,
.height = 480,
+   .pixel_rate = 2776,
+   .link_freq_idx  = OV5640_LINK_FREQ_111,
.reg_data   = ov5640_setting_15fps_NTSC_720_480,
.reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480),
},
@@ -776,6 +806,8 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = 
{
.dn_mode= SUBSAMPLING,
.width  = 720,
.height = 576,
+   .pixel_rate = 2776,
+   .link_freq_idx  = OV5640_LINK_FREQ_111,
.reg_data   = ov5640_setting_15fps_PAL_720_576,
.reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576),
},
@@ -784,6 +816,8 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = 
{
.dn_mode= SUBSAMPLING,
.width  = 1024,
.height = 768,
+   .pixel_rate = 2776,
+   .link_freq_idx  = OV5640_LINK_FREQ_111,
.reg_data   = ov5640_setting_15fps_XGA_1024_768,
.reg_data_size  = ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768),
},
@@ -792,6 +826,8 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = 
{
.dn_mode= SUBSAMPLING,
.width  = 1280,

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

[Christian König]

Am 20.04.2018 um 09:13 schrieb Daniel Vetter:

On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:

We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.

Of course we'll never feed such a strange sg table to a driver which
doesn't understand it, but allowing sg_page == NULL works perfectly
fine. At least for gpu drivers.

For GPU drivers on x86 with no dma coherency problems, sure.  But not
all the world is x86.  We already have problems due to dmabugs use
of the awkward get_sgtable interface (see the common on
arm_dma_get_sgtable that I fully agree with), and doing this for memory
that doesn't have a struct page at all will make things even worse.

x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches
tends to be too expensive, so there's pci-e support and chipset support to
forgo it. Plus drivers flushing caches themselves.

The dma_get_sgtable thing is indeed fun, right solution would probably be
to push the dma-buf export down into the dma layer. The comment for
arm_dma_get_sgtable is also not a realy concern, because dma-buf also
abstracts away the flushing (or well is supposed to), so there really
shouldn't be anyone calling the streaming apis on the returned sg table.
That's why dma-buf gives you an sg table that's mapped already.


If that's not acceptable then I guess we could go over the entire tree
and frob all the gpu related code to switch over to a new struct
sg_table_might_not_be_struct_page_backed, including all the other
functions we added over the past few years to iterate over sg tables.
But seems slightly silly, given that sg tables seem to do exactly what
we need.

It isn't silly.  We will have to do some surgery like that anyway
because the current APIs don't work.  So relax, sit back and come up
with an API that solves the existing issues and serves us well in
the future.

So we should just implement a copy of sg table for dma-buf, since I still
think it does exactly what we need for gpus?

Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into  dma-buf", but that doesn't render the interface a bad idea.


Completely agree on that.

What we need is an sg_alloc_table_from_resources(dev, resources, 
num_resources) which does the handling common to all drivers.


Christian.


-Daniel

[GIT FIXES FOR v4.17] New board, two fixes

[Hans Verkuil]

Hi Mauro,

Three patches for 4.17: two are fixes, one add a new cx231xx board.

Regards,

Hans

The following changes since commit 42a182282ea2426d56b2d63be634ee419194c45c:

  media: si470x: fix a typo at the Makefile causing build issues (2018-04-18 
15:21:41 -0400)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.17g

for you to fetch changes up to 219744bbe295ed0369f1b1fa789ea46704cffd82:

  media: rcar-vin: Fix image alignment for setting pre clipping (2018-04-20 
10:14:08 +0200)


Colin Ian King (1):
  media: cec: set ev rather than v with CEC_PIN_EVENT_FL_DROPPED bit

Kai-Heng Feng (1):
  media: cx231xx: Add support for AverMedia DVD EZMaker 7

Koji Matsuoka (1):
  media: rcar-vin: Fix image alignment for setting pre clipping

 drivers/media/cec/cec-pin.c | 2 +-
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 ++--
 drivers/media/usb/cx231xx/cx231xx-cards.c   | 3 +++
 3 files changed, 6 insertions(+), 3 deletions(-)

[PATCH] cec-gpio: use GPIOD_OUT_HIGH_OPEN_DRAIN

[Hans Verkuil]

This driver needs a pull up output GPIO, but devm_gpiod_get() is called
with GPIOD_IN. This apparently works fine for the RPi3 where the DT
correctly specifies a pull up GPIO, but on the i.MX6 it also needs to
be specified with devm_gpiod_get().

Signed-off-by: Hans Verkuil 
Reported-by: Henrik Mau 
---
 drivers/media/platform/cec-gpio/cec-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c 
b/drivers/media/platform/cec-gpio/cec-gpio.c
index f1f28cf5c751..69f8242209c2 100644
--- a/drivers/media/platform/cec-gpio/cec-gpio.c
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -158,7 +158,7 @@ static int cec_gpio_probe(struct platform_device *pdev)

cec->dev = dev;

-   cec->cec_gpio = devm_gpiod_get(dev, "cec", GPIOD_IN);
+   cec->cec_gpio = devm_gpiod_get(dev, "cec", GPIOD_OUT_HIGH_OPEN_DRAIN);
if (IS_ERR(cec->cec_gpio))
return PTR_ERR(cec->cec_gpio);
cec->cec_irq = gpiod_to_irq(cec->cec_gpio);
-- 
2.14.1

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

[Lee Jones]

On Thu, 19 Apr 2018, Wolfram Sang wrote:

> This header only contains platform_data. Move it to the proper directory.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  MAINTAINERS  | 2 +-
>  arch/arm/mach-ks8695/board-acs5k.c   | 2 +-
>  arch/arm/mach-omap1/board-htcherald.c| 2 +-
>  arch/arm/mach-pxa/palmz72.c  | 2 +-
>  arch/arm/mach-pxa/viper.c| 2 +-
>  arch/arm/mach-sa1100/simpad.c| 2 +-
>  arch/mips/alchemy/board-gpr.c| 2 +-
>  drivers/i2c/busses/i2c-gpio.c| 2 +-
>  drivers/media/platform/marvell-ccic/mmp-driver.c | 2 +-
>  drivers/mfd/sm501.c  | 2 +-
>  include/linux/{ => platform_data}/i2c-gpio.h | 0
>  11 files changed, 10 insertions(+), 10 deletions(-)
>  rename include/linux/{ => platform_data}/i2c-gpio.h (100%)

Acked-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[GIT PULL v2 FOR v4.18] rc changes

[Sean Young]

Hi Mauro,

These patches include the low latency changes, which do make IR more
responsive. These patches could breaks things in subtle ways, so it
would be great to have these changes in early in the cycle.

Thanks,
Sean

The following changes since commit 8b8fcf32502694971fb7f166030361212cb2f9e6:

  media: ddbridge: don't uselessly check for dma in start/stop functions 
(2018-04-17 05:52:43 -0400)

are available in the Git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.18a

for you to fetch changes up to d0ae74e455d6a5328a1ea601b926c5c66e0c7fd0:

  media: rc: mtk-cir: use of_device_get_match_data() (2018-04-19 23:28:22 +0100)


Andi Shyti (1):
  media: rc: ir-spi: update Andi's e-mail

Ryder Lee (1):
  media: rc: mtk-cir: use of_device_get_match_data()

Sean Young (12):
  media: rc: report receiver and transmitter type on device register
  media: rc: set timeout to smallest value required by enabled protocols
  media: rc: add ioctl to get the current timeout
  media: rc: per-protocol repeat period and minimum keyup timer
  media: rc: mce_kbd decoder: low timeout values cause double keydowns
  media: rc: mce_kbd protocol encodes two scancodes
  media: rc: mce_kbd decoder: fix stuck keys
  media: rc: mce_kbd decoder: remove superfluous call to input_sync
  media: rc: mce_kbd decoder: fix race condition
  media: rc: mceusb: IR of length 0 means IR timeout, not reset
  media: rc: mceusb: allow the timeout to be configurable
  media: cx88: enable IR transmitter on HVR-1300

 Documentation/media/uapi/rc/lirc-dev-intro.rst |  2 +-
 Documentation/media/uapi/rc/lirc-func.rst  |  1 +
 .../media/uapi/rc/lirc-set-rec-timeout.rst | 14 +++--
 drivers/media/cec/cec-core.c   |  2 +-
 drivers/media/pci/cx88/cx88-input.c|  5 +-
 drivers/media/rc/ir-imon-decoder.c |  1 +
 drivers/media/rc/ir-jvc-decoder.c  |  1 +
 drivers/media/rc/ir-mce_kbd-decoder.c  | 58 +++---
 drivers/media/rc/ir-nec-decoder.c  |  1 +
 drivers/media/rc/ir-rc5-decoder.c  |  1 +
 drivers/media/rc/ir-rc6-decoder.c  |  1 +
 drivers/media/rc/ir-sanyo-decoder.c|  1 +
 drivers/media/rc/ir-sharp-decoder.c|  1 +
 drivers/media/rc/ir-sony-decoder.c |  1 +
 drivers/media/rc/ir-spi.c  |  4 +-
 drivers/media/rc/ir-xmp-decoder.c  |  1 +
 drivers/media/rc/lirc_dev.c| 31 +-
 drivers/media/rc/mceusb.c  | 29 -
 drivers/media/rc/mtk-cir.c |  4 +-
 drivers/media/rc/rc-core-priv.h|  3 +
 drivers/media/rc/rc-ir-raw.c   | 31 +-
 drivers/media/rc/rc-main.c | 68 +++---
 include/uapi/linux/lirc.h  |  6 ++
 23 files changed, 194 insertions(+), 73 deletions(-)

Re: [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling

[Alexandre Courbot]

On Fri, Apr 20, 2018 at 12:43 AM Paul Kocialkowski <
paul.kocialkow...@bootlin.com> wrote:

> When using the request API in the context of a m2m driver, the
> operations that come with a m2m run scheduling call in their
> (m2m-specific) ioctl handler are delayed until the request is queued
> (for instance, this includes queuing buffers and streamon).

> Thus, the m2m run scheduling calls are not called in due time since the
> request AP's internal plumbing will (rightfully) use the relevant core
> functions directly instead of the ioctl handler.

> This ends up in a situation where nothing happens if there is no
> run-scheduling ioctl called after queuing the request.

> In order to circumvent the issue, a new media operation is introduced,
> called at the time of handling the media request queue ioctl. It gives
> m2m drivers a chance to schedule a m2m device run at that time.

> The existing req_queue operation cannot be used for this purpose, since
> it is called with the request queue mutex held, that is eventually needed
> in the device_run call to apply relevant controls.

> Signed-off-by: Paul Kocialkowski 
> ---
>   drivers/media/media-request.c | 3 +++
>   include/media/media-device.h  | 2 ++
>   2 files changed, 5 insertions(+)

> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index 415f7e31019d..28ac5ccfe6a2 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -157,6 +157,9 @@ static long media_request_ioctl_queue(struct
media_request *req)
>  media_request_get(req);
>  }

> +   if (mdev->ops->req_complete)
> +   mdev->ops->req_complete(req);
> +
>  return ret;
>   }

> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 07e323c57202..c7dcf2079cc9 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -55,6 +55,7 @@ struct media_entity_notify {
>* @req_alloc: Allocate a request
>* @req_free: Free a request
>* @req_queue: Queue a request
> + * @req_complete: Complete a request
>*/
>   struct media_device_ops {
>  int (*link_notify)(struct media_link *link, u32 flags,
> @@ -62,6 +63,7 @@ struct media_device_ops {
>  struct media_request *(*req_alloc)(struct media_device *mdev);
>  void (*req_free)(struct media_request *req);
>  int (*req_queue)(struct media_request *req);
> +   void (*req_complete)(struct media_request *req);

This is called *before* the request is actually run, isn't it? In that
case, wouldn't something like "req_schedule" be less confusing?
req_complete implies that the request is already completed.

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

[Maxime Ripard]

On Thu, Apr 19, 2018 at 05:45:35PM +0200, Paul Kocialkowski wrote:
> This adds nodes for the Video Engine and the associated reserved memory
> for the Allwinner A20. Up to 96 MiB of memory are dedicated to the VPU.
> 
> The VPU can only map the first 256 MiB of DRAM, so the reserved memory
> pool has to be located in that area. Following Allwinner's decision in
> downstream software, the last 96 MiB of the first 256 MiB of RAM are
> reserved for this purpose.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index bd0cd3204273..cb6d82065dcf 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -163,6 +163,20 @@
>   reg = <0x4000 0x8000>;
>   };
>  
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
> + ve_memory: cma@4a00 {
> + compatible = "shared-dma-pool";
> + reg = <0x4a00 0x600>;
> + no-map;

I'm not sure why no-map is needed.

And I guess we could use alloc-ranges to make sure the region is in
the proper memory range, instead of hardcoding it.

> + linux,cma-default;
> + };
> + };
> +
>   timer {
>   compatible = "arm,armv7-timer";
>   interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> @@ -451,6 +465,23 @@
>   };
>   };
>  
> + ve: video-engine@1c0e000 {
> + compatible = "allwinner,sun4i-a10-video-engine";

We should have an A20-specific compatible here, at least, so that we
can deal with any quirk we might find down the road.

> + reg = <0x01c0e000 0x1000>;
> + memory-region = <_memory>;

Since you made the CMA region the default one, you don't need to tie
it to that device in particular (and you can drop it being mandatory
from your binding as well).

> +
> + clocks = < CLK_AHB_VE>, < CLK_VE>,
> +  < CLK_DRAM_VE>;
> + clock-names = "ahb", "mod", "ram";
> +
> + assigned-clocks = < CLK_VE>;
> + assigned-clock-rates = <32000>;

This should be set from within the driver. If it's something that you
absolutely needed for the device to operate, you have no guarantee
that the clock rate won't change at any point in time after the device
probe, so that's not a proper solution.

And if it's not needed and can be adjusted depending on the
framerate/codec/resolution, then it shouldn't be in the DT either.

Don't you also need to map the SRAM on the A20?

Maxime

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


signature.asc
Description: PGP signature

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

[Paul Kocialkowski]

Hi and thanks for the review,

On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote:
> Hi Paul, Philipp,
> 
> On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel 
> wrote:
> 
> > Hi Paul,
> > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > > This adds a device-tree binding document that specifies the
> > > properties
> > > used by the Sunxi-Cedurs VPU driver, as well as examples.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  .../devicetree/bindings/media/sunxi-cedrus.txt | 50
> 
> ++
> > >  1 file changed, 50 insertions(+)
> > >  create mode 100644
> 
> Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/sunxi-
> > > cedrus.txt
> 
> b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > new file mode 100644
> > > index ..71ad3f9c3352
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > @@ -0,0 +1,50 @@
> > > +Device-tree bindings for the VPU found in Allwinner SoCs,
> > > referred to
> 
> as the
> > > +Video Engine (VE) in Allwinner literature.
> > > +
> > > +The VPU can only access the first 256 MiB of DRAM, that are DMA-
> > > mapped
> 
> starting
> > > +from the DRAM base. This requires specific memory allocation and
> 
> handling.
> 
> And no IOMMU? Brings back memories.

Exactly, no IOMMU so we don't have much choice but cope with that
hardware limitation...

> > > +
> > > +Required properties:
> > > +- compatible : "allwinner,sun4i-a10-video-engine";
> > > +- memory-region : DMA pool for buffers allocation;
> > > +- clocks : list of clock specifiers, corresponding to
> 
> entries in
> > > +  the clock-names property;
> > > +- clock-names: should contain "ahb", "mod" and
> > > "ram"
> 
> entries;
> > > +- assigned-clocks   : list of clocks assigned to the VE;
> > > +- assigned-clocks-rates : list of clock rates for the clocks
> > > assigned
> 
> to the VE;
> > > +- resets : phandle for reset;
> > > +- interrupts : should contain VE interrupt number;
> > > +- reg: should contain register base and
> > > length
> 
> of VE.
> > > +
> > > +Example:
> > > +
> > > +reserved-memory {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > +
> > > + /* Address must be kept in the lower 256 MiBs of DRAM for
> > > VE. */
> > > + ve_memory: cma@4a00 {
> > > + compatible = "shared-dma-pool";
> > > + reg = <0x4a00 0x600>;
> > > + no-map;
> > > + linux,cma-default;
> > > + };
> > > +};
> > > +
> > > +video-engine@1c0e000 {
> > This is not really required by any specification, and not as common
> > as
> > gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
> > somewhat-common practice?
> 
> AFAIR the name is supposed to be somewhat readable for someone that
> doesn't know the hardware. To me, "video-engine" sounds more obvious
> than "vpu", but we actually use "codec" already, in case of MFC and
> JPEG codec on Exynos. If encode/decode is the only functionality of
> this block, I'd personally go with "codec". If it can do other things,
> e.g. scaling/rotation without encode/decode, I'd probably call it
> "video-processor".

I agree that the term VPU is more commonly associated with video
decoding, while video engine could mean a number of things.

The reason I went with "video-engine" here (while still presenting the
driver as a VPU driver) is that Video Engine is the term used in
Allwinner's litterature. Other nodes in Allwinner device-trees generally
stick to these terms (for instance, we have "display-engine" nodes).
This also makes it easier to find the matching parts in the
documentation.

Cheers,

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

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

Re: [PATCH v2 01/10] media: v4l2-ctrls: Add missing v4l2 ctrl unlock

[Maxime Ripard]

On Thu, Apr 19, 2018 at 05:41:15PM +0200, Paul Kocialkowski wrote:
> This adds a missing v4l2_ctrl_unlock call that is required to avoid
> deadlocks.

Maybe you can explain what the deadlock scenario is?

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index f67e9f5531fa..ba05a8b9a095 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -3614,10 +3614,12 @@ void v4l2_ctrl_request_complete(struct media_request 
> *req,
>   continue;
>  
>   v4l2_ctrl_lock(ctrl);
> +
>   if (ref->req)
>   ptr_to_ptr(ctrl, ref->req->p_req, ref->p_req);
>   else
>   ptr_to_ptr(ctrl, ctrl->p_cur, ref->p_req);
> +

I'm not sure that this is relevant in this patch.

Maxime

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


signature.asc
Description: PGP signature

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

[Daniel Vetter]

On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> > We've broken that assumption in i915 years ago. Not struct page backed
> > gpu memory is very real.
> > 
> > Of course we'll never feed such a strange sg table to a driver which
> > doesn't understand it, but allowing sg_page == NULL works perfectly
> > fine. At least for gpu drivers.
> 
> For GPU drivers on x86 with no dma coherency problems, sure.  But not
> all the world is x86.  We already have problems due to dmabugs use
> of the awkward get_sgtable interface (see the common on
> arm_dma_get_sgtable that I fully agree with), and doing this for memory
> that doesn't have a struct page at all will make things even worse.

x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches
tends to be too expensive, so there's pci-e support and chipset support to
forgo it. Plus drivers flushing caches themselves.

The dma_get_sgtable thing is indeed fun, right solution would probably be
to push the dma-buf export down into the dma layer. The comment for
arm_dma_get_sgtable is also not a realy concern, because dma-buf also
abstracts away the flushing (or well is supposed to), so there really
shouldn't be anyone calling the streaming apis on the returned sg table.
That's why dma-buf gives you an sg table that's mapped already.

> > If that's not acceptable then I guess we could go over the entire tree
> > and frob all the gpu related code to switch over to a new struct
> > sg_table_might_not_be_struct_page_backed, including all the other
> > functions we added over the past few years to iterate over sg tables.
> > But seems slightly silly, given that sg tables seem to do exactly what
> > we need.
> 
> It isn't silly.  We will have to do some surgery like that anyway
> because the current APIs don't work.  So relax, sit back and come up
> with an API that solves the existing issues and serves us well in
> the future.

So we should just implement a copy of sg table for dma-buf, since I still
think it does exactly what we need for gpus?

Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into  dma-buf", but that doesn't render the interface a bad idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch