[GIT PULL FOR v4.12] cec kernel config fixes

[Hans Verkuil]

From the cover letter of the patch series:

While working on drm CEC drivers I realized that the correct config
setup is a pain. The problem is that the CEC subsystem is really independent
of the media subsystem: both media and drm drivers can use it.

So this patch series moves the core CEC kernel config options outside the
"Multimedia support" menu and drivers that want to use CEC should select
CEC_CORE. This also ensures that the cec framework will be correctly build
as either a module or a built-in.

The only missing piece is that drm drivers that use cec-notifier.h need to
add a 'select CEC_CORE if CEC_NOTIFIER' to their Kconfig. That would allow
the removal of the ugly 'IS_REACHABLE' construct in cec-notifier.h.

But that can be done for 4.13.

Enabling the RC integration is still part of the MEDIA_CEC_SUPPORT menu,
since it obviously relies on the media rc core.

The second patch renames MEDIA_CEC_NOTIFIER to CEC_NOTIFIER since
this too is not part of the media subsystem and is instead selected by
drivers that want to use it.

The last patch drops the MEDIA_CEC_DEBUG kernel config option: instead
just rely on DEBUG_FS. There really is no need for this additional option,
and in fact it would require enabled the media subsystem just to enable
the CEC debugfs support when used by a drm driver.

I want to get this in for 4.12 while there are no drm drivers yet that
integrate CEC support.

Regards,

Hans

The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030:

  [media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update() 
(2017-05-19 07:12:05 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git cec-config

for you to fetch changes up to c3e855ff8f8b5a4a210c5f3b6b2b3de93e9a491a:

  cec: drop MEDIA_CEC_DEBUG (2017-05-28 11:36:04 +0200)


Hans Verkuil (3):
  cec: select CEC_CORE instead of depend on it
  cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER
  cec: drop MEDIA_CEC_DEBUG

 drivers/media/Kconfig|  6 ++
 drivers/media/Makefile   |  4 ++--
 drivers/media/cec/Kconfig| 14 --
 drivers/media/cec/Makefile   |  2 +-
 drivers/media/cec/cec-adap.c |  2 +-
 drivers/media/cec/cec-core.c |  8 
 drivers/media/i2c/Kconfig|  9 ++---
 drivers/media/platform/Kconfig   | 10 ++
 drivers/media/platform/vivid/Kconfig |  3 ++-
 drivers/media/usb/pulse8-cec/Kconfig |  3 ++-
 drivers/media/usb/rainshadow-cec/Kconfig |  3 ++-
 include/media/cec-notifier.h |  2 +-
 include/media/cec.h  |  4 ++--
 13 files changed, 35 insertions(+), 35 deletions(-)

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:   Mon May 29 05:00:31 CEST 2017
media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030
media_build git hash:   c8dfc17d6d049d79497c78737625f6ea3b08c456
v4l-utils git hash: d16a17abd1d8d7885ca2f44fb295035278baa89c
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9.26-i686: ERRORS
linux-4.10.14-i686: ERRORS
linux-4.11-i686: ERRORS
linux-4.12-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9.26-x86_64: ERRORS
linux-4.10.14-x86_64: ERRORS
linux-4.11-x86_64: ERRORS
linux-4.12-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v3 1/1] [media] i2c: add support for OV13858 sensor

[Tomasz Figa]

Hi Hyungwoo,

On Mon, May 29, 2017 at 8:26 AM, Yang, Hyungwoo  wrote:
>
> Hi Sakari,
>
> Here's my comments.
>
> -Hyungwoo
>
>
> -Original Message-
>> From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>> Sent: Saturday, May 27, 2017 1:31 PM
>> To: Yang, Hyungwoo 
>> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian 
>> Xu ; Hsu, Cedric ; 
>> tf...@chromium.org
>> Subject: Re: [PATCH v3 1/1] [media] i2c: add support for OV13858 sensor
>>
>> Hi Hyungwoo,
>>
>> Thanks for the update. A few comments below.
>>
[snip]
>> > +/* Update VTS that meets expected vertical blanking */ static int
>> > +ov13858_update_vblank(struct ov13858 *ov13858,
>> > +struct v4l2_ctrl *ctrl)
>> > +{
>> > +   return ov13858_write_reg(
>> > +   ov13858, OV13858_REG_VTS,
>> > +   OV13858_REG_VALUE_16BIT,
>> > +   ov13858->cur_mode->height + ov13858->vblank->val); }
>> > +
>> > +/* Update analog gain */
>> > +static int ov13858_update_analog_gain(struct ov13858 *ov13858,
>> > + struct v4l2_ctrl *ctrl)
>> > +{
>> > +   return ov13858_write_reg(ov13858, OV13858_REG_ANALOG_GAIN,
>> > +OV13858_REG_VALUE_16BIT, ctrl->val);
>>
>> I think I'd move what the four above functions do to ov13858_set_ctrl() 
>> unless they're used in more than one location.
>
> Why ? Personally I like this. Since there  wouldn't be any difference in 
> generated machine code, I want to keep this if there's no strict rule on this.

Personally I wouldn't probably care about this, but I see one
advantage of Sakari's suggestion.

Namely, it improves code readability, because there is less
indirection and the person reading ov13858_set_ctrl() instantly knows
that all it does is directly writing the control value to hardware
registers. Otherwise, with the indirection in current version, until
you read ov13858_update_analog_gain() (or such), you don't know
whether it does some extra processing, power management or whatnot.

If ov13858_update_analog_gain() did more than just a simple register
write, it would indeed make sense to separate it, as it's intuitive
that a separate function means some more complicated work. (And vice
versa, it's counter-intuitive to have a function that is only there to
call a register accessor.)

>
>>
>> > +}
>> > +
>> > +static int ov13858_set_ctrl(struct v4l2_ctrl *ctrl) {
>> > +   struct ov13858 *ov13858 = container_of(ctrl->handler,
>> > +  struct ov13858, ctrl_handler);
>> > +   struct i2c_client *client = v4l2_get_subdevdata(>sd);
>> > +   int ret;
>> > +
>> > +   /* Propagate change of current control to all related controls */
>> > +   switch (ctrl->id) {
>> > +   case V4L2_CID_VBLANK:
>> > +   ov13858_update_exposure_limits(ov13858);
>> > +   break;
>> > +   };
>> > +
>> > +   /*
>> > +* Applying V4L2 control value only happens
>> > +* when power is up for streaming
>> > +*/
>> > +   if (pm_runtime_get_if_in_use(>dev) <= 0)
>> > +   return 0;
>> > +
>> > +   ret = 0;
>> > +   switch (ctrl->id) {
>> > +   case V4L2_CID_ANALOGUE_GAIN:
>> > +   ret = ov13858_update_analog_gain(ov13858, ctrl);
>> > +   break;
>> > +   case V4L2_CID_EXPOSURE:
>> > +   ret = ov13858_update_exposure(ov13858, ctrl);
>> > +   break;
>> > +   case V4L2_CID_VBLANK:
>> > +   ret = ov13858_update_vblank(ov13858, ctrl);
>> > +   break;
>> > +   default:
>> > +   dev_info(>dev,
>> > +"ctrl(id:0x%x,val:0x%x) is not handled\n",
>> > +ctrl->id, ctrl->val);
>> > +   break;
>> > +   };
>> > +
>> > +   pm_runtime_put(>dev);
>> > +
>> > +   return ret;
>> > +}
>> > +
> :
> :
>> > +/*
>> > + * Prepare streaming by writing default values and customized values.
>> > + * This should be called with ov13858->mutex acquired.
>> > + */
>> > +static int ov13858_prepare_streaming(struct ov13858 *ov13858)
>> > +{
>> > +   struct i2c_client *client = v4l2_get_subdevdata(>sd);
>> > +   const struct ov13858_reg_list *reg_list;
>> > +   int ret, link_freq_index;
>> > +
>> > +   /* Get out of from software reset */
>> > +   ret = ov13858_write_reg(ov13858, OV13858_REG_SOFTWARE_RST,
>> > +   OV13858_REG_VALUE_08BIT, OV13858_SOFTWARE_RST);
>> > +   if (ret) {
>> > +   dev_err(>dev, "%s failed to set powerup registers\n",
>> > +   __func__);
>> > +   return ret;
>> > +   }
>> > +
>> > +   /* Setup PLL */
>> > +   link_freq_index = ov13858->cur_mode->link_freq_index;
>> > +   reg_list = _freq_configs[link_freq_index].reg_list;
>> > +   ret = ov13858_write_reg_list(ov13858, reg_list);
>> > +   if (ret) {
>> > +   dev_err(>dev, "%s failed to set plls\n", __func__);
>> 

Re: [PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

[Kieran Bingham]

Hi Wolfram

Thankyou for the fixup

On 28/05/17 18:30, Wolfram Sang wrote:
> It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.
> 
> Signed-off-by: Wolfram Sang 

Acked-by: Kieran Bingham 


Mauro,

I'll leave this for you to pick up when you're ready.

Thanks

Kieran

> ---
> I suggest this trivial patch should be picked individually per susbsystem.
> 
>  drivers/media/platform/rcar_fdp1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar_fdp1.c 
> b/drivers/media/platform/rcar_fdp1.c
> index 42f25d241edd7c..0da0eba9202cdd 100644
> --- a/drivers/media/platform/rcar_fdp1.c
> +++ b/drivers/media/platform/rcar_fdp1.c
> @@ -1,5 +1,5 @@
>  /*
> - * Renesas RCar Fine Display Processor
> + * Renesas R-Car Fine Display Processor
>   *
>   * Video format converter and frame deinterlacer device.
>   *
> 

RE: [PATCH v3 1/1] [media] i2c: add support for OV13858 sensor

[Yang, Hyungwoo]

Hi Sakari,

Here's my comments.

-Hyungwoo


-Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi] 
> Sent: Saturday, May 27, 2017 1:31 PM
> To: Yang, Hyungwoo 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian Xu 
> ; Hsu, Cedric ; 
> tf...@chromium.org
> Subject: Re: [PATCH v3 1/1] [media] i2c: add support for OV13858 sensor
> 
> Hi Hyungwoo,
> 
> Thanks for the update. A few comments below.
> 
> > +
> > +/* Mode : resolution and related config */
> > +struct ov13858_mode 
> > +{
> > +   /* Frame width */
> > +   u32 width;
> > +   /* Frame height */
> > +   u32 height;
> > +
> > +   /* V-timing */
> > +   u32 vts;
> 
> Aren't the three fields here unused?

?? Yes, they are used. 
:
:
:
> 
> > +/* Mode configs */
> > +static const struct ov13858_mode supported_modes[] = {
> > +   {
> > +   .width = 4224,
> > +   .height = 3136,
> > +   .vts = OV13858_VTS_30FPS,
> > +   .reg_list = {
> > +   .num_of_regs = ARRAY_SIZE(mode_4224x3136_regs),
> > +   .regs = mode_4224x3136_regs,
> > +   },
> > +   .link_freq_index = OV13858_LINK_FREQ_INDEX_0,
> > +   },
> > +   {
> > +   .width = 2112,
> > +   .height = 1568,
> > +   .vts = OV13858_VTS_30FPS,
> > +   .reg_list = {
> > +   .num_of_regs = ARRAY_SIZE(mode_2112x1568_regs),
> > +   .regs = mode_2112x1568_regs,
> > +   },
> > +   .link_freq_index = OV13858_LINK_FREQ_INDEX_1,
> > +   },
> > +   {
> > +   .width = 2112,
> > +   .height = 1188,
> > +   .vts = OV13858_VTS_30FPS,
> > +   .reg_list = {
> > +   .num_of_regs = ARRAY_SIZE(mode_2112x1188_regs),
> > +   .regs = mode_2112x1188_regs,
> > +   },
> > +   .link_freq_index = OV13858_LINK_FREQ_INDEX_1,
> > +   },
> > +   {
> > +   .width = 1056,
> > +   .height = 784,
> > +   .vts = OV13858_VTS_30FPS,
> > +   .reg_list = {
> > +   .num_of_regs = ARRAY_SIZE(mode_1056x784_regs),
> > +   .regs = mode_1056x784_regs,
> > +   },
> > +   .link_freq_index = OV13858_LINK_FREQ_INDEX_1,
> > +   }
> > +};
> > +
> > +struct ov13858 {
> > +   struct v4l2_subdev sd;
> > +   struct media_pad pad;
> > +
> > +   struct v4l2_ctrl_handler ctrl_handler;
> > +   /* V4L2 Controls */
> > +   struct v4l2_ctrl *link_freq;
> > +   struct v4l2_ctrl *pixel_rate;
> > +   struct v4l2_ctrl *vblank;
> > +   struct v4l2_ctrl *exposure;
> > +
> > +   /* Current mode */
> > +   const struct ov13858_mode *cur_mode;
> > +
> > +   /* Num of skip frames */
> > +   u32 num_of_skip_frames;
> 
> If you always tell the receiver to skip  OV13858_NUM_OF_SKIP_FRAMES frames in 
> the beginning, you could just return this from your g_skip_frames callback.
> 

Oops!!! Yes, you're right. My original version gets some platform dependent 
values including this through fwnode API.
I removed them to make this simple but didn't think much. I'll remove this.

> > +
> > +   /* Mutex for serialized access */
> > +   struct mutex mutex;
> > +
> > +   /* Streaming on/off */
> > +   bool streaming;
> > +};
> > +
> > +#define to_ov13858(_sd)container_of(_sd, struct ov13858, sd)
> > +
> > +/* Read registers up to 4 at a time */ static int 
> > +ov13858_read_reg(struct ov13858 *ov13858, u16 reg, u32 len, u32 *val) 
> > +{
> > +   struct i2c_client *client = v4l2_get_subdevdata(>sd);
> > +   struct i2c_msg msgs[2];
> > +   u8 *data_be_p;
> > +   int ret;
> > +   u32 data_be = 0;
> > +   u16 reg_addr_be = cpu_to_be16(reg);
> > +
> > +   if (len > 4)
> > +   return -EINVAL;
> > +
> > +   data_be_p = (u8 *)_be;
> > +   /* Write register address */
> > +   msgs[0].addr = client->addr;
> > +   msgs[0].flags = 0;
> > +   msgs[0].len = 2;
> > +   msgs[0].buf = (u8 *)_addr_be;
> > +
> > +   /* Read data from register */
> > +   msgs[1].addr = client->addr;
> > +   msgs[1].flags = I2C_M_RD;
> > +   msgs[1].len = len;
> > +   msgs[1].buf = _be_p[4 - len];
> > +
> > +   ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
> > +   if (ret != ARRAY_SIZE(msgs))
> > +   return -EIO;
> > +
> > +   *val = be32_to_cpu(data_be);
> > +
> > +   return 0;
> > +}
> > +
> > +/* Write registers up to 4 at a time */ static int 
> > +ov13858_write_reg(struct ov13858 *ov13858, u16 reg, u32 len, u32 val) 
> > +{
> > +   struct i2c_client *client = v4l2_get_subdevdata(>sd);
> > +   int buf_i, val_i;
> > +   u8 buf[6], *val_p;
> > +
> > +   if (len > 4)
> > +   return -EINVAL;
> > +
> > +   buf[0] = reg >> 8;
> > +   buf[1] = reg & 0xff;
> > +
> > +   buf_i = 2;
> > +   val_p = (u8 *)
> > +   val_i = len - 1;
> > +
> > +   while (val_i >= 0)
> > +   buf[buf_i++] = val_p[val_i--];
> > +

Re: [PATCH 00/19] cxd2841er/ddbridge: support Sony CXD28xx hardware

[Daniel Scheller]

Am Sun,  9 Apr 2017 21:38:09 +0200
schrieb Daniel Scheller :


> Important note: This series depends on the stv0367/ddbridge series
> posted earlier (patches 12 [1] and 13 [2], depending on the I2C
> functions and the TDA18212 attach function).
> 
> This series improves the cxd2841er demodulator driver and adds some
> bits to make it more versatile to be used in more scenarios. Also,
> the ddbridge code is updated to recognize all hardware (PCIe
> cards/bridges and DuoFlex modules) with Sony CXD28xx tuners,
> including the newly introduced MaxA8 eight-tuner C2T2 cards.
> 
> The series has been tested (together with the STV0367 series) on a
> wide variety of cards, including CineCTv7, DuoFlex C(2)T2 modules and
> MaxA8 cards without any issues. Testing was done with TVHeadend, VDR
> and MythTV.
> 
> Note that the i2c_gate_ctrl() flag is needed in this series aswell
> since the i2c_gate_ctrl function needs to be remapped and mutex_lock
> protected for the same reasons as in the STV0367 series.
> 
> Besides printk() warnings, checkpatch.pl doesn't complain.

Ping on this series aswell.

Abylay, would you please mind taking a look at the cxd2841er changes
and check if you're fine with them?

Regards,
Daniel

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

Am Sun, 7 May 2017 17:42:12 +0200
schrieb Daniel Scheller :

> Am Wed, 12 Apr 2017 21:23:27 +0200
> schrieb Daniel Scheller :
> 
> > Am Wed, 29 Mar 2017 18:43:00 +0200
> > schrieb Daniel Scheller :
> >   
> > > From: Daniel Scheller 
> > > 
> > > Third iteration of the DD CineCTv6/FlexCT support patches with
> > > mostly all things cleaned up that popped up so far. Obsoletes V1
> > > and V2 series.
> > > 
> > > These patches enhance the functionality of dvb-frontends/stv0367
> > > to work with Digital Devices hardware driven by the ST STV0367
> > > demodulator chip and adds probe & attach bits to ddbridge to make
> > > use of them, effectively enabling full support for CineCTv6 PCIe
> > > bridges and (older) DuoFlex CT addon modules.
> > 
> > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like
> > to get this upstreamed.  
> 
> Don't want to sound impatient, but V1 nears nine weeks, so: Second
> Ping.

Friendly third time Ping on this - Really, I'd like to have this
merged so those quite aging (but still fine) DD CineCTv6 boards
finally are supported without having to install out-of-tree drivers
which even break the V4L-DVB subsystem...

Thanks & regards,
Daniel

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Daniel Scheller]

Am Sun, 28 May 2017 21:06:33 +0200
schrieb Karl Wallin :

All,

> In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from:
> "ret = cdev_device_add(>cdev, >dev);" to:
> "ret = device_add(>dev);"
> and row 186 from:
> "cdev_device_del(>cdev, >dev);" to:
> "device_del(>dev);"

Until the upstream media_build repository gets the neccessary backport
patch treatment, you can apply [1] and [2] to media_build which should
fix all build issues.

Best regards,
Daniel

[1]
https://github.com/herrnst/media_build/commit/4766a716c629707d58d625c6cdfd8c395fd6ed61
[2]
https://github.com/herrnst/media_build/commit/01507a9c32a301c8fc021dcaf1b943799ff3da51

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Thomas Kaiser]

On 28.05.2017 21:33, Karl Wallin wrote:

Thanks for such a quick reply :)

Of course *facepalm* should have thought of that "./build" downloads
everything again and of course replaces my modified "cec-core.c".
I ran "make" and ran into new problems:


Ok so using logic I should do the same changes in
"/home/ubuntu/media_build/v4l/media-devnode.c":
In ""/home/ubuntu/media_build/v4l/media-devnode.c" changed row 257 from:
"ret = cdev_device_add(>cdev, >dev);" to:
"ret = device_add(>dev);"
and row 293 from:
"cdev_device_del(>cdev, >dev);" to:
"device_del(>dev);"
and then run "make"

However it fails again :(




   CC [M]  /home/ubuntu/media_build/v4l/serial_ir.o
/home/ubuntu/media_build/v4l/serial_ir.c:837:21: error: expected ')'
before 'int'
  module_param_hw(io, int, ioport, 0444);
  ^~~
/home/ubuntu/media_build/v4l/serial_ir.c:841:25: error: expected ')'
before 'ulong'
  module_param_hw(iommap, ulong, other, 0444);
  ^
/home/ubuntu/media_build/v4l/serial_ir.c:849:26: error: expected ')'
before 'int'
  module_param_hw(ioshift, int, other, 0444);
   ^~~
/home/ubuntu/media_build/v4l/serial_ir.c:852:22: error: expected ')'
before 'int'
  module_param_hw(irq, int, irq, 0444);
   ^~~
/home/ubuntu/media_build/v4l/serial_ir.c:855:28: error: expected ')'
before 'bool'
  module_param_hw(share_irq, bool, other, 0444);
 ^~~~
scripts/Makefile.build:301: recipe for target
'/home/ubuntu/media_build/v4l/serial_ir.o' failed
make[3]: *** [/home/ubuntu/media_build/v4l/serial_ir.o] Error 1
Makefile:1524: recipe for target '_module_/home/ubuntu/media_build/v4l' failed
make[2]: *** [_module_/home/ubuntu/media_build/v4l] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-4.10.0-21-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/ubuntu/media_build/v4l'
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 2

So I'm guessing that "/home/ubuntu/media_build/v4l/serial_ir.c" needs
to be modified since it expects a ")" before the integer (numerical)
value?

/Karl


Hi Karl

I compiled only the ddbridge driver. So I did not have to compile these files 
you have problems with. Therefor I don't know what is going on here, sorry.

Thomas

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Alan Cox]

> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
> a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
> as such passing the subdev->dev pointer would be simply wrong. AFAICT the
> v1p8 / v2p8 gpio code is the only caller passing in a NULL pointer and
> as said since thisv1p8 / v2p8 gpio code is only for some special evaluation
> boards, silencing the error when these variables are not present actually
> is the right thing to do.

Unfortunately I don't think it is constrained to RVPs. As with all
developer hacks on code that isn't subject to public review at the time
they escape into the wild 8(

Agreed though. The patch makes sense if you don't want to print anything.

> > which if my understanding of the subdevices is correct should pass the
> > right valid device field from the atomisp.
> > 
> > Please also cc me if you are proposing patches this driver - and also
> > linux-media.  
> 
> Sorry about that, I messed up my git send-email foo and send this to
> a wrong set of addresses (and also added v5 in the subject which should
> not be there) I did send out a fresh-copy with the full 7 patch patch-set
> directly after CTRL+c-ing this wrong send-email (which only got the
> first 3 patches send).

So I discovered just afterwards 8)

Alan

Re: [PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

[Alan Cox]

On Mon, 29 May 2017 02:06:41 +0800
Chen Guanqiao  wrote:

> Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings.
> 
> Signed-off-by: Chen Guanqiao 
> ---

Reviewed-by: Alan Cox 

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Thomas Kaiser]

On 28.05.2017 21:06, Karl Wallin wrote:

Hi Thomas,

Thanks for the help (and to Vincent as well) :)

In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from:
"ret = cdev_device_add(>cdev, >dev);" to:
"ret = device_add(>dev);"
and row 186 from:
"cdev_device_del(>cdev, >dev);" to:
"device_del(>dev);"

Even if I do that when I try to build it again (using ./build) it
seems to reload / revert the cec-core.c to the original file since I
still get these errors even though I saved the changes in Notepadqq:
"/home/ubuntu/media_build/v4l/cec-core.c:142:8: error: implicit
declaration of function 'cdev_device_add'
[-Werror=implicit-function-declaration]
   ret = cdev_device_add(>cdev, >dev);"
and
"/home/ubuntu/media_build/v4l/cec-core.c:186:2: error: implicit
declaration of function 'cdev_device_del'
[-Werror=implicit-function-declaration]
   cdev_device_del(>cdev, >dev);"

I am probably missing something here since it worked for you, would be
grateful for your help :)

/Karl
Med vänlig hälsning / Best Regards - Karl Wallin



Hi Karl

The build downloads the latest source and overwrites your change (I think?)

I used "make" to compile.

After your have run the build script. Do the changes as you have described above. Run 
"make" to compile and "sudo make install" to install. This should do the trick.

Thomas

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Karl Wallin]

Thanks for such a quick reply :)

Of course *facepalm* should have thought of that "./build" downloads
everything again and of course replaces my modified "cec-core.c".
I ran "make" and ran into new problems:

"Make" log:
ubuntu@nuc-d54250wyk:~/media_build$ make
make -C /home/ubuntu/media_build/v4l
make[1]: Entering directory '/home/ubuntu/media_build/v4l'
creating symbolic links...
make -C firmware prep
make[2]: Entering directory '/home/ubuntu/media_build/v4l/firmware'
make[2]: Leaving directory '/home/ubuntu/media_build/v4l/firmware'
make -C firmware
make[2]: Entering directory '/home/ubuntu/media_build/v4l/firmware'
make[2]: Nothing to be done for 'default'.
make[2]: Leaving directory '/home/ubuntu/media_build/v4l/firmware'
Kernel build directory is /lib/modules/4.10.0-21-generic/build
make -C ../linux apply_patches
make[2]: Entering directory '/home/ubuntu/media_build/linux'
Patches for 4.10.0-21-generic already applied.
make[2]: Leaving directory '/home/ubuntu/media_build/linux'
make -C /lib/modules/4.10.0-21-generic/build
SUBDIRS=/home/ubuntu/media_build/v4l  modules
make[2]: Entering directory '/usr/src/linux-headers-4.10.0-21-generic'
  CC [M]  /home/ubuntu/media_build/v4l/cec-core.o
  CC [M]  /home/ubuntu/media_build/v4l/cec-adap.o
  CC [M]  /home/ubuntu/media_build/v4l/cec-api.o
  CC [M]  /home/ubuntu/media_build/v4l/cec-edid.o
  CC [M]  /home/ubuntu/media_build/v4l/cec-notifier.o
  LD [M]  /home/ubuntu/media_build/v4l/cec.o
  CC [M]  /home/ubuntu/media_build/v4l/msp3400-driver.o
  CC [M]  /home/ubuntu/media_build/v4l/msp3400-kthreads.o
  LD [M]  /home/ubuntu/media_build/v4l/msp3400.o
  CC [M]  /home/ubuntu/media_build/v4l/smiapp-core.o
  CC [M]  /home/ubuntu/media_build/v4l/smiapp-regs.o
  CC [M]  /home/ubuntu/media_build/v4l/smiapp-quirk.o
  CC [M]  /home/ubuntu/media_build/v4l/smiapp-limits.o
  LD [M]  /home/ubuntu/media_build/v4l/smiapp.o
  CC [M]  /home/ubuntu/media_build/v4l/et8ek8_mode.o
  CC [M]  /home/ubuntu/media_build/v4l/et8ek8_driver.o
/home/ubuntu/media_build/v4l/et8ek8_driver.c: In function
'et8ek8_i2c_buffered_write_regs':
/home/ubuntu/media_build/v4l/et8ek8_driver.c:256:1: warning: the frame
size of 1104 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^
  LD [M]  /home/ubuntu/media_build/v4l/et8ek8.o
  CC [M]  /home/ubuntu/media_build/v4l/cx25840-core.o
  CC [M]  /home/ubuntu/media_build/v4l/cx25840-audio.o
  CC [M]  /home/ubuntu/media_build/v4l/cx25840-firmware.o
  CC [M]  /home/ubuntu/media_build/v4l/cx25840-vbi.o
  CC [M]  /home/ubuntu/media_build/v4l/cx25840-ir.o
  LD [M]  /home/ubuntu/media_build/v4l/cx25840.o
  CC [M]  /home/ubuntu/media_build/v4l/m5mols_core.o
  CC [M]  /home/ubuntu/media_build/v4l/m5mols_controls.o
  CC [M]  /home/ubuntu/media_build/v4l/m5mols_capture.o
  LD [M]  /home/ubuntu/media_build/v4l/m5mols.o
  CC [M]  /home/ubuntu/media_build/v4l/imx074.o
  CC [M]  /home/ubuntu/media_build/v4l/mt9m001.o
  CC [M]  /home/ubuntu/media_build/v4l/mt9t031.o
  CC [M]  /home/ubuntu/media_build/v4l/mt9t112.o
  CC [M]  /home/ubuntu/media_build/v4l/mt9v022.o
  CC [M]  /home/ubuntu/media_build/v4l/ov5642.o
  CC [M]  /home/ubuntu/media_build/v4l/ov6650.o
  CC [M]  /home/ubuntu/media_build/v4l/ov772x.o
  CC [M]  /home/ubuntu/media_build/v4l/ov9640.o
  CC [M]  /home/ubuntu/media_build/v4l/ov9740.o
  CC [M]  /home/ubuntu/media_build/v4l/rj54n1cb0c.o
  CC [M]  /home/ubuntu/media_build/v4l/tw9910.o
  CC [M]  /home/ubuntu/media_build/v4l/aptina-pll.o
  CC [M]  /home/ubuntu/media_build/v4l/tvaudio.o
  CC [M]  /home/ubuntu/media_build/v4l/tda7432.o
  CC [M]  /home/ubuntu/media_build/v4l/saa6588.o
  CC [M]  /home/ubuntu/media_build/v4l/tda9840.o
  CC [M]  /home/ubuntu/media_build/v4l/tea6415c.o
  CC [M]  /home/ubuntu/media_build/v4l/tea6420.o
  CC [M]  /home/ubuntu/media_build/v4l/saa7110.o
  CC [M]  /home/ubuntu/media_build/v4l/saa7115.o
  CC [M]  /home/ubuntu/media_build/v4l/saa717x.o
  CC [M]  /home/ubuntu/media_build/v4l/saa7127.o
  CC [M]  /home/ubuntu/media_build/v4l/saa7185.o
  CC [M]  /home/ubuntu/media_build/v4l/saa6752hs.o
  CC [M]  /home/ubuntu/media_build/v4l/ad5820.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7170.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7175.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7180.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7183.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7343.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7393.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7604.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7842.o
  CC [M]  /home/ubuntu/media_build/v4l/ad9389b.o
  CC [M]  /home/ubuntu/media_build/v4l/adv7511.o
  CC [M]  /home/ubuntu/media_build/v4l/vpx3220.o
  CC [M]  /home/ubuntu/media_build/v4l/vs6624.o
  CC [M]  /home/ubuntu/media_build/v4l/bt819.o
  CC [M]  /home/ubuntu/media_build/v4l/bt856.o
  CC [M]  /home/ubuntu/media_build/v4l/bt866.o
  CC [M]  /home/ubuntu/media_build/v4l/ks0127.o
  CC [M]  /home/ubuntu/media_build/v4l/ths7303.o
  CC [M]  /home/ubuntu/media_build/v4l/ths8200.o
  CC [M]  

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Karl Wallin]

Hi Thomas,

Thanks for the help (and to Vincent as well) :)

In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from:
"ret = cdev_device_add(>cdev, >dev);" to:
"ret = device_add(>dev);"
and row 186 from:
"cdev_device_del(>cdev, >dev);" to:
"device_del(>dev);"

Even if I do that when I try to build it again (using ./build) it
seems to reload / revert the cec-core.c to the original file since I
still get these errors even though I saved the changes in Notepadqq:
"/home/ubuntu/media_build/v4l/cec-core.c:142:8: error: implicit
declaration of function 'cdev_device_add'
[-Werror=implicit-function-declaration]
  ret = cdev_device_add(>cdev, >dev);"
and
"/home/ubuntu/media_build/v4l/cec-core.c:186:2: error: implicit
declaration of function 'cdev_device_del'
[-Werror=implicit-function-declaration]
  cdev_device_del(>cdev, >dev);"

I am probably missing something here since it worked for you, would be
grateful for your help :)

/Karl
Med vänlig hälsning / Best Regards - Karl Wallin

karl.wallin...@gmail.com

P.S. Om mitt mail bör vidarebefodras, vänligen gör detta istället för
att återkomma med en email-adress i ett svar till mig. / If my mail
should be forwarded then please forward it instead of replying to me
with an email address. P.S.


2017-05-28 14:28 GMT+02:00 Thomas Kaiser :
> On 27.05.2017 21:28, Karl Wallin wrote:
>>
>> Hi!
>>
>> Sorry if this is something I should have figured out, I am bit
>> experienced with Linux but not at all a pro.
>>
>> Trying to build v4l-dvb on Ubuntu 17.04 (kernel 4.10.0-21-generic) and
>> get build errors.
>>
>> Dependencies are met:
>>
>> make[2]: Entering directory '/usr/src/linux-headers-4.10.0-21-generic'
>>CC [M]  /home/ubuntu/media_build/v4l/cec-core.o
>> /home/ubuntu/media_build/v4l/cec-core.c: In function
>> 'cec_devnode_register':
>> /home/ubuntu/media_build/v4l/cec-core.c:142:8: error: implicit
>> declaration of function 'cdev_device_add'
>> [-Werror=implicit-function-declaration]
>>ret = cdev_device_add(>cdev, >dev);
>>  ^~~
>> /home/ubuntu/media_build/v4l/cec-core.c: In function
>> 'cec_devnode_unregister':
>> /home/ubuntu/media_build/v4l/cec-core.c:186:2: error: implicit
>> declaration of function 'cdev_device_del'
>> [-Werror=implicit-function-declaration]
>>cdev_device_del(>cdev, >dev);
>>^~~
>
>
> Hi Karl
>
> I changed in cec-core.c cdev_device_add(>cdev, >dev) and
> cdev_device_del(>cdev, >dev) to device_add(>dev)
> and device_del(>dev).
>
> I can compile now and the driver runs with kernel 4.10.0-21-generic on
> Ubuntu 17.04.
>
> Thomas
>

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Hans de Goede]

Hi,

On 28-05-17 19:08, Alan Cox wrote:

On Sun, 28 May 2017 14:30:35 +0200
Hans de Goede  wrote:


Do not call dev_warn with a NULL device, this silence the following 2
warnings:

[   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO

We could switch to using pr_warn for dev == NULL instead, but as comments
in the source indicate, the check for these 2 special gmin variables with
a NULL device is a workaround for 2 specific evaluation boards, so
completely silencing the missing warning for these actually is a good
thing.


At which point real missing variables won't get reported so NAK. I think
the right fix is to make the offending callers pass

subdev->dev


The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
as such passing the subdev->dev pointer would be simply wrong. AFAICT the
v1p8 / v2p8 gpio code is the only caller passing in a NULL pointer and
as said since thisv1p8 / v2p8 gpio code is only for some special evaluation
boards, silencing the error when these variables are not present actually
is the right thing to do.


which if my understanding of the subdevices is correct should pass the
right valid device field from the atomisp.

Please also cc me if you are proposing patches this driver - and also
linux-media.


Sorry about that, I messed up my git send-email foo and send this to
a wrong set of addresses (and also added v5 in the subject which should
not be there) I did send out a fresh-copy with the full 7 patch patch-set
directly after CTRL+c-ing this wrong send-email (which only got the
first 3 patches send).

Regards,

Hans

[PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

[Chen Guanqiao]

Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings.

Signed-off-by: Chen Guanqiao 
---
 drivers/staging/media/atomisp/i2c/lm3554.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/lm3554.c 
b/drivers/staging/media/atomisp/i2c/lm3554.c
index dd9c9c37..2b170c07aaba 100644
--- a/drivers/staging/media/atomisp/i2c/lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/lm3554.c
@@ -497,7 +497,7 @@ static const struct v4l2_ctrl_ops ctrl_ops = {
.g_volatile_ctrl = lm3554_g_volatile_ctrl
 };
 
-struct v4l2_ctrl_config lm3554_controls[] = {
+static const struct v4l2_ctrl_config lm3554_controls[] = {
{
 .ops = _ops,
 .id = V4L2_CID_FLASH_TIMEOUT,
@@ -825,7 +825,7 @@ static int lm3554_gpio_uninit(struct i2c_client *client)
return 0;
 }
 
-void *lm3554_platform_data_func(struct i2c_client *client)
+static void *lm3554_platform_data_func(struct i2c_client *client)
 {
static struct lm3554_platform_data platform_data;
 
-- 
2.11.0

[2/7/] staging: atomisp: Do not call dev_warn with a NULL device

[Alan Cox]

>On Sun, May 28, 2017 at 3:31 PM, Hans de Goede 
wrote:
>> Do not call dev_warn with a NULL device, this silence the following 2
>> warnings:
>>
>> [   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
>> [   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO
>>
>> We could switch to using pr_warn for dev == NULL instead, but as comments
>> in the source indicate, the check for these 2 special gmin variables with
>> a NULL device is a workaround for 2 specific evaluation boards, so
>> completely silencing the missing warning for these actually is a good
>> thing.
>
> Perhaps removing all code related explicitly to Gmin is a right thing to do.

That would make the driver somewhat useless because the Android derived
platforms I have seen that you can re-install Linux on that use this as
far as I am aware use the GMIN EFI variables.

Only the Windows platforms do it differently, and they appear to embed
the entire configuration in a machine specific driver for each platform
(at least the supposedly relevant ACPI in my T100TA appears to be copied
from an Intel reference board and bears no relation to the actual
hardware!)

Easy enough to check what a given Android x86 tablet does - plug it into a
powered OTG hub, add a live USB stick and a keyboard, hit the Fn key for
BIOS entry as it boots and boot off USB. You can then check lsacpi and
the EFI variables.

Alan

[GIT PULL FOR v4.13] RC fixes

[Sean Young]

Hi Mauro,

Just minor cleanups and fixes this time round.

Thanks,
Sean

The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030:

  [media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update() 
(2017-05-19 07:12:05 -0300)

are available in the git repository at:

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

for you to fetch changes up to 2ff5552b1cdb5b07a8adc5dee08db17aceaa673a:

  [media] staging: remove todo and replace with lirc_zilog todo (2017-05-27 
10:44:44 +0100)


A Sun (4):
  [media] mceusb: sporadic RX truncation corruption fix
  [media] mceusb: fix inaccurate debug buffer dumps, and misleading debug 
messages
  [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix
  [media] mceusb: TX -EPIPE (urb status = -32) lockup fix

Alex Deryskyba (1):
  [media] rc: meson-ir: switch config to NEC decoding on shutdown

Andi Shyti (1):
  [media] rc: ir-spi: remove unnecessary initialization

David Härdeman (17):
  [media] lirc_dev: remove pointless functions
  [media] lirc_dev: remove unused set_use_inc/set_use_dec
  [media] lirc_dev: remove sampling kthread
  [media] lirc_dev: clarify error handling
  [media] lirc_dev: make fops mandatory
  [media] lirc_dev: merge lirc_register_driver() and lirc_allocate_driver()
  [media] lirc_zilog: remove module parameter minor
  [media] lirc_dev: remove lirc_irctl_init() and lirc_cdev_add()
  [media] lirc_dev: remove superfluous get/put_device() calls
  [media] lirc_dev: remove unused module parameter
  [media] lirc_dev: return POLLHUP and POLLERR when device is gone
  [media] lirc_dev: cleanup includes
  [media] lirc_dev: cleanup header
  [media] rc-core: ati_remote - leave the internals of rc_dev alone
  [media] rc-core: img-ir - leave the internals of rc_dev alone
  [media] rc-core: cx231xx - leave the internals of rc_dev alone
  [media] tm6000: key_addr is unused

Devin Heitmueller (1):
  [media] rc: fix breakage in "make menuconfig" for media_build

Heiner Kallweit (5):
  [media] rc: meson-ir: remove irq from struct meson_ir
  [media] rc: meson-ir: make use of the bitfield macros
  [media] rc: meson-ir: switch to managed rc device allocation / 
registration
  [media] rc: meson-ir: use readl_relaxed in the interrupt handler
  [media] rc: meson-ir: change irq name to to of node name

Jonas Karlman (1):
  [media] rc: meson-ir: store raw event without processing

Ricardo Silva (5):
  [media] lirc_zilog: Fix whitespace style checks
  [media] lirc_zilog: Fix NULL comparisons style
  [media] lirc_zilog: Use __func__ for logging function name
  [media] lirc_zilog: Use sizeof(*p) instead of sizeof(struct P)
  [media] lirc_zilog: Fix unbalanced braces around if/else

Sean Young (5):
  [media] sir_ir: attempt to free already free_irq
  [media] sir_ir: use dev managed resources
  [media] sir_ir: remove init_port and drop_port functions
  [media] sir_ir: remove init_chrdev and init_sir_ir functions
  [media] staging: remove todo and replace with lirc_zilog todo

 drivers/media/rc/Kconfig   |   8 +-
 drivers/media/rc/ati_remote.c  |   3 -
 drivers/media/rc/img-ir/img-ir-hw.c|   4 -
 drivers/media/rc/ir-lirc-codec.c   |  12 --
 drivers/media/rc/ir-spi.c  |   2 +-
 drivers/media/rc/lirc_dev.c| 253 -
 drivers/media/rc/mceusb.c  | 153 +
 drivers/media/rc/meson-ir.c|  91 ++-
 drivers/media/rc/sir_ir.c  |  90 --
 drivers/media/usb/cx231xx/cx231xx-input.c  |   5 +-
 drivers/media/usb/tm6000/tm6000-input.c|   4 -
 drivers/staging/media/lirc/TODO|  47 --
 drivers/staging/media/lirc/TODO.lirc_zilog |  36 
 drivers/staging/media/lirc/lirc_zilog.c| 136 +++-
 include/media/lirc_dev.h   |  32 
 15 files changed, 341 insertions(+), 535 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/TODO.lirc_zilog

[PATCH] [media] rc-core: simplify ir_raw_event_store_edge()

[Sean Young]

There is no need to called ir_raw_event_reset() either after a long
space or on startup. Many rc drivers never do this.

Signed-off-by: Sean Young 
---
 drivers/media/pci/saa7134/saa7134-input.c |  2 +-
 drivers/media/rc/gpio-ir-recv.c   |  6 +++---
 drivers/media/rc/img-ir/img-ir-raw.c  |  4 ++--
 drivers/media/rc/rc-core-priv.h   |  1 -
 drivers/media/rc/rc-ir-raw.c  | 31 +--
 include/media/rc-core.h   |  9 +
 6 files changed, 12 insertions(+), 41 deletions(-)

diff --git a/drivers/media/pci/saa7134/saa7134-input.c 
b/drivers/media/pci/saa7134/saa7134-input.c
index 78849c1..8784bc8 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -1064,7 +1064,7 @@ static int saa7134_raw_decode_irq(struct saa7134_dev *dev)
saa_clearb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN);
saa_setb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN);
space = saa_readl(SAA7134_GPIO_GPSTATUS0 >> 2) & ir->mask_keydown;
-   ir_raw_event_store_edge(dev->remote->dev, space ? IR_SPACE : IR_PULSE);
+   ir_raw_event_store_edge(dev->remote->dev, !space);
 
/*
 * Wait 15 ms from the start of the first IR event before processing
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index b4f773b..09889d0 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -77,7 +77,7 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
struct gpio_rc_dev *gpio_dev = dev_id;
int gval;
int rc = 0;
-   enum raw_event_type type = IR_SPACE;
+   bool pulse = false;
 
gval = gpio_get_value(gpio_dev->gpio_nr);
 
@@ -88,9 +88,9 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
gval = !gval;
 
if (gval == 1)
-   type = IR_PULSE;
+   pulse = true;
 
-   rc = ir_raw_event_store_edge(gpio_dev->rcdev, type);
+   rc = ir_raw_event_store_edge(gpio_dev->rcdev, pulse);
if (rc < 0)
goto err_get_value;
 
diff --git a/drivers/media/rc/img-ir/img-ir-raw.c 
b/drivers/media/rc/img-ir/img-ir-raw.c
index 8d2f8e2..ddb7fb4 100644
--- a/drivers/media/rc/img-ir/img-ir-raw.c
+++ b/drivers/media/rc/img-ir/img-ir-raw.c
@@ -40,9 +40,9 @@ static void img_ir_refresh_raw(struct img_ir_priv *priv, u32 
irq_status)
 
/* report the edge to the IR raw decoders */
if (ir_status) /* low */
-   ir_raw_event_store_edge(rc_dev, IR_SPACE);
+   ir_raw_event_store_edge(rc_dev, false);
else /* high */
-   ir_raw_event_store_edge(rc_dev, IR_PULSE);
+   ir_raw_event_store_edge(rc_dev, true);
ir_raw_event_handle(rc_dev);
 }
 
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 0455b27..d31ad6a 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -41,7 +41,6 @@ struct ir_raw_event_ctrl {
/* fifo for the pulse/space durations */
DECLARE_KFIFO(kfifo, struct ir_raw_event, MAX_IR_EVENT_SIZE);
ktime_t last_event; /* when last event 
occurred */
-   enum raw_event_type last_type;  /* last event type */
struct rc_dev   *dev;   /* pointer to the 
parent rc_dev */
 
/* raw decoder state follows */
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 90f66dc..16ef236 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -88,7 +88,7 @@ EXPORT_SYMBOL_GPL(ir_raw_event_store);
 /**
  * ir_raw_event_store_edge() - notify raw ir decoders of the start of a 
pulse/space
  * @dev:   the struct rc_dev device descriptor
- * @type:  the type of the event that has occurred
+ * @pulse: true for pulse, false for space
  *
  * This routine (which may be called from an interrupt context) is used to
  * store the beginning of an ir pulse or space (or the start/end of ir
@@ -96,43 +96,22 @@ EXPORT_SYMBOL_GPL(ir_raw_event_store);
  * hardware which does not provide durations directly but only interrupts
  * (or similar events) on state change.
  */
-int ir_raw_event_store_edge(struct rc_dev *dev, enum raw_event_type type)
+int ir_raw_event_store_edge(struct rc_dev *dev, bool pulse)
 {
ktime_t now;
-   s64 delta; /* ns */
DEFINE_IR_RAW_EVENT(ev);
int rc = 0;
-   int delay;
 
if (!dev->raw)
return -EINVAL;
 
now = ktime_get();
-   delta = ktime_to_ns(ktime_sub(now, dev->raw->last_event));
-   delay = MS_TO_NS(dev->input_dev->rep[REP_DELAY]);
+   ev.duration = ktime_to_ns(ktime_sub(now, dev->raw->last_event));
+   ev.pulse = pulse;
 
-   /* Check for a long duration since last event 

Re: [PATCH 13/16] lirc_dev: use an ida instead of a hand-rolled array to keep track of minors

[Sean Young]

On Sun, May 28, 2017 at 10:26:59AM +0200, David Härdeman wrote:
> On Mon, May 22, 2017 at 09:09:42PM +0100, Sean Young wrote:
> >On Mon, May 01, 2017 at 06:04:42PM +0200, David Härdeman wrote:
> >> Using the kernel ida facilities, we can avoid a lot of unnecessary code 
> >> and at the same
> >> time get rid of lirc_dev_lock in favour of per-device locks (the irctls 
> >> array was used
> >> throughout lirc_dev so this patch necessarily touches a lot of code).
> >> 
> >> Signed-off-by: David Härdeman 
> >> ---
> >>  drivers/media/rc/ir-lirc-codec.c|9 -
> >>  drivers/media/rc/lirc_dev.c |  258 
> >> ---
> >>  drivers/staging/media/lirc/lirc_zilog.c |   16 +-
> >>  include/media/lirc_dev.h|   14 --
> >>  4 files changed, 115 insertions(+), 182 deletions(-)
> >> 
> >> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> >> b/drivers/media/rc/ir-lirc-codec.c
> >> index a30af91710fe..2c1221a61ea1 100644
> >> --- a/drivers/media/rc/ir-lirc-codec.c
> >> +++ b/drivers/media/rc/ir-lirc-codec.c
> >> @@ -382,7 +382,6 @@ static int ir_lirc_register(struct rc_dev *dev)
> >>  
> >>snprintf(drv->name, sizeof(drv->name), "ir-lirc-codec (%s)",
> >> dev->driver_name);
> >> -  drv->minor = -1;
> >>drv->features = features;
> >>drv->data = >raw->lirc;
> >>drv->rbuf = NULL;
> >> @@ -394,11 +393,9 @@ static int ir_lirc_register(struct rc_dev *dev)
> >>drv->rdev = dev;
> >>drv->owner = THIS_MODULE;
> >>  
> >> -  drv->minor = lirc_register_driver(drv);
> >> -  if (drv->minor < 0) {
> >> -  rc = -ENODEV;
> >> +  rc = lirc_register_driver(drv);
> >> +  if (rc < 0)
> >>goto out;
> >> -  }
> >>  
> >>dev->raw->lirc.drv = drv;
> >>dev->raw->lirc.dev = dev;
> >> @@ -413,7 +410,7 @@ static int ir_lirc_unregister(struct rc_dev *dev)
> >>  {
> >>struct lirc_codec *lirc = >raw->lirc;
> >>  
> >> -  lirc_unregister_driver(lirc->drv->minor);
> >> +  lirc_unregister_driver(lirc->drv);
> >>kfree(lirc->drv);
> >>lirc->drv = NULL;
> >>  
> >> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
> >> index e44e0b23b883..7db7d4c57991 100644
> >> --- a/drivers/media/rc/lirc_dev.c
> >> +++ b/drivers/media/rc/lirc_dev.c
> >> @@ -31,23 +31,35 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  
> >>  #include 
> >>  #include 
> >>  #include 
> >>  
> >>  #define IRCTL_DEV_NAME"BaseRemoteCtl"
> >> -#define NOPLUG-1
> >>  #define LOGHEAD   "lirc_dev (%s[%d]): "
> >>  
> >>  static dev_t lirc_base_dev;
> >>  
> >> +/**
> >> + * struct irctl - lirc per-device structure
> >> + * @d:internal copy of the  lirc_driver for 
> >> the device
> >> + * @dead: if the device has gone away
> >> + * @users:the number of users of the lirc chardev 
> >> (currently limited to 1)
> >> + * @mutex:synchronizes open()/close()/ioctl()/etc calls
> >> + * @buf:  used to store lirc RX data
> >> + * @buf_internal: whether @buf was allocated internally or not
> >> + * @chunk_size:   @buf stores and read() returns data chunks of 
> >> this size
> >> + * @dev:  the  device for the lirc device
> >> + * @cdev: the  device for the lirc chardev
> >> + */
> >>  struct irctl {
> >>struct lirc_driver d;
> >> -  int attached;
> >> -  int open;
> >> +  bool dead;
> >> +  unsigned users;
> >>  
> >> -  struct mutex irctl_lock;
> >> +  struct mutex mutex;
> >>struct lirc_buffer *buf;
> >>bool buf_internal;
> >>unsigned int chunk_size;
> >> @@ -56,9 +68,9 @@ struct irctl {
> >>struct cdev cdev;
> >>  };
> >>  
> >> -static DEFINE_MUTEX(lirc_dev_lock);
> >> -
> >> -static struct irctl *irctls[MAX_IRCTL_DEVICES];
> >> +/* Used to keep track of allocated lirc devices */
> >> +#define LIRC_MAX_DEVICES 256
> >> +static DEFINE_IDA(lirc_ida);
> >>  
> >>  /* Only used for sysfs but defined to void otherwise */
> >>  static struct class *lirc_class;
> >> @@ -72,9 +84,6 @@ static void lirc_release(struct device *ld)
> >>kfree(ir->buf);
> >>}
> >>  
> >> -  mutex_lock(_dev_lock);
> >> -  irctls[ir->d.minor] = NULL;
> >> -  mutex_unlock(_dev_lock);
> >>kfree(ir);
> >>  }
> >>  
> >> @@ -117,7 +126,18 @@ static int lirc_allocate_buffer(struct irctl *ir)
> >>return err;
> >>  }
> >>  
> >> -int lirc_register_driver(struct lirc_driver *d)
> >> +/**
> >> + * lirc_register_driver() - create a new lirc device by registering a 
> >> driver
> >> + * @d: the  lirc_driver to register
> >> + *
> >> + * This function allocates and registers a lirc device for a given
> >> + * _driver. The _driver structure is updated to contain
> >> + * information about the allocated device (minor, buffer, etc).
> >> + *
> >> + * Return: zero on success or a negative error value.
> >> + */
> >> +int
> >> +lirc_register_driver(struct lirc_driver *d)
> >>  {
> >>struct irctl 

Re: [PATCH 03/16] lirc_dev: correct error handling

[Sean Young]

On Sun, May 28, 2017 at 10:23:37AM +0200, David Härdeman wrote:
> On Sun, May 21, 2017 at 09:57:13AM +0100, Sean Young wrote:
> >On Mon, May 01, 2017 at 06:03:51PM +0200, David Härdeman wrote:
> >> If an error is generated, nonseekable_open() shouldn't be called.
> >
> >There is no harm in calling nonseekable_open(), so this commit is
> >misleading.
> 
> I'm not sure why you consider it misleading? If there's an error, the
> logic thing to do is to error out immediately and not do any further
> work?

The commit message says that nonseekable_open() should not be called,
suggesting there is a bug which is not the case.


Sean

Re: [PATCH RESEND2] [media] usbtv: add a new usbid

[icenowy]

在 2017-04-16 14:51，Icenowy Zheng 写道：

A new usbid of UTV007 is found in a newly bought device.

The usbid is 1f71:3301.

The ID on the chip is:
UTV007
A89029.1
1520L18K1

Both video and audio is tested with the modified usbtv driver.

Signed-off-by: Icenowy Zheng 
Acked-by: Lubomir Rintel 


Ping?

I found this patch in Superseded state in patchwork, however it's
not superseded at all -- I didn't send any new version, and I didn't
see this one get merged...

Could someone merge it?


---

Added Lubomir's ACK in the second time of resend.

The old patch may be lost because the old aosc.xyz mail is using 
Yandex's
service -- which is rejected by many mail providers. As part of AOSC 
mailing

system refactor, we got a new mailing system, so that the patch is now
resent.

 drivers/media/usb/usbtv/usbtv-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/usbtv/usbtv-core.c
b/drivers/media/usb/usbtv/usbtv-core.c
index ceb953be0770..cae637845876 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -144,6 +144,7 @@ static void usbtv_disconnect(struct usb_interface 
*intf)


 static struct usb_device_id usbtv_id_table[] = {
{ USB_DEVICE(0x1b71, 0x3002) },
+   { USB_DEVICE(0x1f71, 0x3301) },
{}
 };
 MODULE_DEVICE_TABLE(usb, usbtv_id_table);

Re: [PATCH 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Andy Shevchenko]

On Sun, May 28, 2017 at 3:31 PM, Hans de Goede  wrote:
> Do not call dev_warn with a NULL device, this silence the following 2
> warnings:
>
> [   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
> [   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO
>
> We could switch to using pr_warn for dev == NULL instead, but as comments
> in the source indicate, the check for these 2 special gmin variables with
> a NULL device is a workaround for 2 specific evaluation boards, so
> completely silencing the missing warning for these actually is a good
> thing.

Perhaps removing all code related explicitly to Gmin is a right thing to do.


-- 
With Best Regards,
Andy Shevchenko

[PATCH 7/7] staging: atomisp: Make ov2680 driver less chatty

[Hans de Goede]

There is no reason for all this printk spamming and certainly
not at an error log level.

Signed-off-by: Hans de Goede 
---
 drivers/staging/media/atomisp/i2c/ov2680.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c 
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 6dd466558701..3cabfe54c669 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -1191,9 +1191,8 @@ static int ov2680_detect(struct i2c_client *client)
OV2680_SC_CMMN_SUB_ID, );
revision = (u8) high & 0x0f;
 
-   dev_err(>dev, "sensor_revision id  = 0x%x\n", id);
-   dev_err(>dev, "detect ov2680 success\n");
-   dev_err(>dev, "5##\n");
+   dev_info(>dev, "sensor_revision id = 0x%x\n", id);
+
return 0;
 }
 
@@ -1448,8 +1447,6 @@ static int ov2680_probe(struct i2c_client *client,
void *pdata;
unsigned int i;
 
-   printk("ov2680_probe\n");
-   dev_info(>dev, "ov2680_probe\n");
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
dev_err(>dev, "out of memory\n");
-- 
2.13.0

[PATCH 6/7] staging: atomisp: Ignore errors from second gpio in ov2680 driver

[Hans de Goede]

As the existing comment in the driver indicates the sensor has only 1 pin,
but some boards may have 2 gpios defined and we toggle both as we we don't
know which one is the right one. However if the ACPI resources table
defines only 1 gpio (as expected) the gpio1_ctrl call will always fail,
causing the probing of the driver to file.

This commit ignore the return value of the gpio1_ctrl call, fixing this.

Signed-off-by: Hans de Goede 
---
 drivers/staging/media/atomisp/i2c/ov2680.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c 
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 449aa2aa276f..6dd466558701 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -885,11 +885,12 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (flag) {
ret = dev->platform_data->gpio0_ctrl(sd, 1);
usleep_range(1, 15000);
-   ret |= dev->platform_data->gpio1_ctrl(sd, 1);
+   /* Ignore return from second gpio, it may not be there */
+   dev->platform_data->gpio1_ctrl(sd, 1);
usleep_range(1, 15000);
} else {
-   ret = dev->platform_data->gpio1_ctrl(sd, 0);
-   ret |= dev->platform_data->gpio0_ctrl(sd, 0);
+   dev->platform_data->gpio1_ctrl(sd, 0);
+   ret = dev->platform_data->gpio0_ctrl(sd, 0);
}
return ret;
 }
-- 
2.13.0

[PATCH 1/7] staging: atomisp: Fix calling efivar_entry_get() with unaligned arguments

[Hans de Goede]

efivar_entry_get has certain alignment requirements and the atomisp
platform code was not honoring these, causing an oops by triggering the
WARN_ON in arch/x86/platform/efi/efi_64.c: virt_to_phys_or_null_size().

This commit fixes this by using the members of the efivar struct embedded
in the efivar_entry struct we kzalloc as arguments to efivar_entry_get(),
which is how all the other callers of efivar_entry_get() do this.

Signed-off-by: Hans de Goede 
---
 .../atomisp/platform/intel-mid/atomisp_gmin_platform.c  | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a71126..104fea2f8697 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -623,9 +623,7 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out, size_t *
char var8[CFG_VAR_NAME_MAX];
efi_char16_t var16[CFG_VAR_NAME_MAX];
struct efivar_entry *ev;
-   u32 efiattr_dummy;
int i, j, ret;
-   unsigned long efilen;
 
 if (dev && ACPI_COMPANION(dev))
 dev = _COMPANION(dev)->dev;
@@ -684,15 +682,18 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out, size_t *
return -ENOMEM;
memcpy(>var.VariableName, var16, sizeof(var16));
ev->var.VendorGuid = GMIN_CFG_VAR_EFI_GUID;
+   ev->var.DataSize = *out_len;
 
-   efilen = *out_len;
-   ret = efivar_entry_get(ev, _dummy, , out);
+   ret = efivar_entry_get(ev, >var.Attributes,
+  >var.DataSize, ev->var.Data);
+   if (ret == 0) {
+   memcpy(out, ev->var.Data, ev->var.DataSize);
+   *out_len = ev->var.DataSize;
+   } else {
+   dev_warn(dev, "Failed to find gmin variable %s\n", var8);
+   }
 
kfree(ev);
-   *out_len = efilen;
-
-   if (ret)
-   dev_warn(dev, "Failed to find gmin variable %s\n", var8);
 
return ret;
 }
-- 
2.13.0

[PATCH 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Hans de Goede]

Do not call dev_warn with a NULL device, this silence the following 2
warnings:

[   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO

We could switch to using pr_warn for dev == NULL instead, but as comments
in the source indicate, the check for these 2 special gmin variables with
a NULL device is a workaround for 2 specific evaluation boards, so
completely silencing the missing warning for these actually is a good
thing.

Signed-off-by: Hans de Goede 
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 104fea2f8697..3fea81ea5dbd 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -689,7 +689,7 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out, size_t *
if (ret == 0) {
memcpy(out, ev->var.Data, ev->var.DataSize);
*out_len = ev->var.DataSize;
-   } else {
+   } else if (dev) {
dev_warn(dev, "Failed to find gmin variable %s\n", var8);
}
 
-- 
2.13.0

[PATCH 3/7] staging: atomisp: Set step to 0 for mt9m114 menu control

[Hans de Goede]

menu controls are not allowed to have a step size, set step to 0 to
fix an oops from the WARN_ON in v4l2_ctrl_new_custom() triggering
because of this.

Signed-off-by: Hans de Goede 
---
 drivers/staging/media/atomisp/i2c/mt9m114.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c 
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index ced175c268d1..3fa915313e53 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -1499,7 +1499,7 @@ static struct v4l2_ctrl_config mt9m114_controls[] = {
 .type = V4L2_CTRL_TYPE_MENU,
 .min = 0,
 .max = 3,
-.step = 1,
+.step = 0,
 .def = 1,
 .flags = 0,
 },
-- 
2.13.0

[PATCH 5/7] staging: atomisp: Add OVTI2680 ACPI id to ov2680 driver

[Hans de Goede]

Signed-off-by: Hans de Goede 
---
 drivers/staging/media/atomisp/i2c/ov2680.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c 
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 566091035c64..449aa2aa276f 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -1521,6 +1521,7 @@ static int ov2680_probe(struct i2c_client *client,
 
 static struct acpi_device_id ov2680_acpi_match[] = {
{"XXOV2680"},
+   {"OVTI2680"},
{},
 };
 MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);
-- 
2.13.0

[PATCH 4/7] staging: atomisp: Add INT0310 ACPI id to gc0310 driver

[Hans de Goede]

Signed-off-by: Hans de Goede 
---
 drivers/staging/media/atomisp/i2c/gc0310.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c 
b/drivers/staging/media/atomisp/i2c/gc0310.c
index 1ec616a15086..350fd7fd5b86 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -1455,6 +1455,7 @@ static int gc0310_probe(struct i2c_client *client,
 
 static struct acpi_device_id gc0310_acpi_match[] = {
{"XXGC0310"},
+   {"INT0310"},
{},
 };
 
-- 
2.13.0

Firmware for staging atomisp driver

[Hans de Goede]

Hi All,

I've been trying to get the atomisp driver from staging to work
on a couple of devices I have.

I started with an Asus T100TA after fixing 2 oopses in the sensor
driver there I found out that the BIOS does not allow to put the
ISP in PCI mode and that there is no code to drive it in ACPI
enumerated mode.

So I moved to a generic Insyde T701 tablet which does allow
this. After fixing some more sensor driver issues there I was
ready to actually load the atomisp driver, but I could not
find the exact firmware required, I did find a version which
is close: "irci_stable_candrpv_0415_20150423_1753"
and tried that but that causes the atomisp driver to explode
in a backtrace which contains atomisp_load_firmware() so that
one seems no good.

Can someone help me to get the right firmware ?

The TODO says: "can also be extracted from the upgrade kit"
about the firmware files, but it is not clear to me what /
where the "upgrade kit" is.

More in general it would be a good idea if someone inside Intel
would try to get permission to add the firmware to linux-firmware.

Anyways I will send out the patches I've currently, once I've
the right firmware I will continue working on this.

Regards,

Hans

[PATCH for v4.12 1/3] cec: select CEC_CORE instead of depend on it

[Hans Verkuil]

From: Hans Verkuil 

The CEC framework is used by both drm and media. That makes it tricky
to get the dependencies right.

This patch moves the CEC_CORE and MEDIA_CEC_NOTIFIER config options
out of the media menu and instead drivers that want to use CEC should
select CEC_CORE and MEDIA_CEC_NOTIFIER (if needed).

Signed-off-by: Hans Verkuil 
---
 drivers/media/Kconfig| 6 ++
 drivers/media/Makefile   | 4 ++--
 drivers/media/cec/Kconfig| 8 
 drivers/media/i2c/Kconfig| 9 ++---
 drivers/media/platform/Kconfig   | 6 --
 drivers/media/platform/vivid/Kconfig | 3 ++-
 drivers/media/usb/pulse8-cec/Kconfig | 3 ++-
 drivers/media/usb/rainshadow-cec/Kconfig | 3 ++-
 8 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index b72edd27f880..9ec634e2f2ba 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -2,6 +2,12 @@
 # Multimedia device configuration
 #
 
+config CEC_CORE
+   tristate
+
+config MEDIA_CEC_NOTIFIER
+   bool
+
 menuconfig MEDIA_SUPPORT
tristate "Multimedia support"
depends on HAS_IOMEM
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 523fea3648ad..044503aa8801 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -4,8 +4,6 @@
 
 media-objs := media-device.o media-devnode.o media-entity.o
 
-obj-$(CONFIG_CEC_CORE) += cec/
-
 #
 # I2C drivers should come before other drivers, otherwise they'll fail
 # when compiled as builtin drivers
@@ -26,6 +24,8 @@ obj-$(CONFIG_DVB_CORE)  += dvb-core/
 # There are both core and drivers at RC subtree - merge before drivers
 obj-y += rc/
 
+obj-$(CONFIG_CEC_CORE) += cec/
+
 #
 # Finally, merge the drivers that require the core
 #
diff --git a/drivers/media/cec/Kconfig b/drivers/media/cec/Kconfig
index 488fb908244d..5d5091499ab1 100644
--- a/drivers/media/cec/Kconfig
+++ b/drivers/media/cec/Kconfig
@@ -1,11 +1,3 @@
-config CEC_CORE
-   tristate
-   depends on MEDIA_CEC_SUPPORT
-   default y
-
-config MEDIA_CEC_NOTIFIER
-   bool
-
 config MEDIA_CEC_RC
bool "HDMI CEC RC integration"
depends on CEC_CORE && RC_CORE
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd181c99ce11..aaa9471c7d11 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -220,7 +220,8 @@ config VIDEO_ADV7604
 
 config VIDEO_ADV7604_CEC
bool "Enable Analog Devices ADV7604 CEC support"
-   depends on VIDEO_ADV7604 && CEC_CORE
+   depends on VIDEO_ADV7604
+   select CEC_CORE
---help---
  When selected the adv7604 will support the optional
  HDMI CEC feature.
@@ -240,7 +241,8 @@ config VIDEO_ADV7842
 
 config VIDEO_ADV7842_CEC
bool "Enable Analog Devices ADV7842 CEC support"
-   depends on VIDEO_ADV7842 && CEC_CORE
+   depends on VIDEO_ADV7842
+   select CEC_CORE
---help---
  When selected the adv7842 will support the optional
  HDMI CEC feature.
@@ -478,7 +480,8 @@ config VIDEO_ADV7511
 
 config VIDEO_ADV7511_CEC
bool "Enable Analog Devices ADV7511 CEC support"
-   depends on VIDEO_ADV7511 && CEC_CORE
+   depends on VIDEO_ADV7511
+   select CEC_CORE
---help---
  When selected the adv7511 will support the optional
  HDMI CEC feature.
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee1ca07..017419bef9b1 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -501,7 +501,8 @@ if CEC_PLATFORM_DRIVERS
 
 config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
-   depends on CEC_CORE && (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   select CEC_CORE
select MEDIA_CEC_NOTIFIER
---help---
  This is a driver for Samsung S5P HDMI CEC interface. It uses the
@@ -511,7 +512,8 @@ config VIDEO_SAMSUNG_S5P_CEC
 
 config VIDEO_STI_HDMI_CEC
tristate "STMicroelectronics STiH4xx HDMI CEC driver"
-   depends on CEC_CORE && (ARCH_STI || COMPILE_TEST)
+   depends on ARCH_STI || COMPILE_TEST
+   select CEC_CORE
select MEDIA_CEC_NOTIFIER
---help---
  This is a driver for STIH4xx HDMI CEC interface. It uses the
diff --git a/drivers/media/platform/vivid/Kconfig 
b/drivers/media/platform/vivid/Kconfig
index b36ac19dc6e4..154de92dd809 100644
--- a/drivers/media/platform/vivid/Kconfig
+++ b/drivers/media/platform/vivid/Kconfig
@@ -26,7 +26,8 @@ config VIDEO_VIVID
 
 config VIDEO_VIVID_CEC
bool "Enable CEC emulation support"
-   depends on VIDEO_VIVID && CEC_CORE
+   depends on VIDEO_VIVID
+   select CEC_CORE
---help---
  When selected the vivid module will emulate the optional
  HDMI CEC feature.
diff 

[PATCH for v4.12 0/3] cec: more kernel config cleanups

[Hans Verkuil]

From: Hans Verkuil 

While working on drm CEC drivers I realized that the correct config
setup is a pain. The problem is that the CEC subsystem is really independent
of the media subsystem: both media and drm drivers can use it.

So this patch series moves the core CEC kernel config options outside the
"Multimedia support" menu and drivers that want to use CEC should select
CEC_CORE. This also ensures that the cec framework will be correctly build
as either a module or a built-in.

The only missing piece is that drm drivers that use cec-notifier.h need to
add a 'select CEC_CORE if CEC_NOTIFIER' to their Kconfig. That would allow
the removal of the ugly 'IS_REACHABLE' construct in cec-notifier.h.

But that can be done for 4.13.

Enabling the RC integration is still part of the MEDIA_CEC_SUPPORT menu,
since it obviously relies on the media rc core.

The second patch renames MEDIA_CEC_NOTIFIER to CEC_NOTIFIER since
this too is not part of the media subsystem and is instead selected by
drivers that want to use it.

The last patch drops the MEDIA_CEC_DEBUG kernel config option: instead
just rely on DEBUG_FS. There really is no need for this additional option,
and in fact it would require enabled the media subsystem just to enable
the CEC debugfs support when used by a drm driver.

I want to get this in for 4.12 while there are no drm drivers yet that
integrate CEC support.

Regards,

Hans

Hans Verkuil (3):
  cec: select CEC_CORE instead of depend on it
  cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER
  cec: drop MEDIA_CEC_DEBUG

 drivers/media/Kconfig|  6 ++
 drivers/media/Makefile   |  4 ++--
 drivers/media/cec/Kconfig| 14 --
 drivers/media/cec/Makefile   |  2 +-
 drivers/media/cec/cec-adap.c |  2 +-
 drivers/media/cec/cec-core.c |  8 
 drivers/media/i2c/Kconfig|  9 ++---
 drivers/media/platform/Kconfig   | 10 ++
 drivers/media/platform/vivid/Kconfig |  3 ++-
 drivers/media/usb/pulse8-cec/Kconfig |  3 ++-
 drivers/media/usb/rainshadow-cec/Kconfig |  3 ++-
 include/media/cec-notifier.h |  2 +-
 include/media/cec.h  |  4 ++--
 13 files changed, 35 insertions(+), 35 deletions(-)

-- 
2.11.0

[PATCH for v4.12 3/3] cec: drop MEDIA_CEC_DEBUG

[Hans Verkuil]

From: Hans Verkuil 

Just depend on DEBUG_FS, no need to invent a new kernel config.
Especially since CEC can be enabled by drm without enabling
MEDIA_SUPPORT.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/Kconfig| 6 --
 drivers/media/cec/cec-adap.c | 2 +-
 drivers/media/cec/cec-core.c | 4 ++--
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/media/cec/Kconfig b/drivers/media/cec/Kconfig
index 5d5091499ab1..43428cec3a01 100644
--- a/drivers/media/cec/Kconfig
+++ b/drivers/media/cec/Kconfig
@@ -4,9 +4,3 @@ config MEDIA_CEC_RC
depends on CEC_CORE=m || RC_CORE=y
---help---
  Pass on CEC remote control messages to the RC framework.
-
-config MEDIA_CEC_DEBUG
-   bool "HDMI CEC debugfs interface"
-   depends on CEC_CORE && DEBUG_FS
-   ---help---
- Turns on the DebugFS interface for CEC devices.
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index f5fe01c9da8a..9dfc79800c71 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1864,7 +1864,7 @@ void cec_monitor_all_cnt_dec(struct cec_adapter *adap)
WARN_ON(call_op(adap, adap_monitor_all_enable, 0));
 }
 
-#ifdef CONFIG_MEDIA_CEC_DEBUG
+#ifdef CONFIG_DEBUG_FS
 /*
  * Log the current state of the CEC adapter.
  * Very useful for debugging.
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index feeb4c5afa69..2f87748ba4fc 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -323,7 +323,7 @@ int cec_register_adapter(struct cec_adapter *adap,
}
 
dev_set_drvdata(>devnode.dev, adap);
-#ifdef CONFIG_MEDIA_CEC_DEBUG
+#ifdef CONFIG_DEBUG_FS
if (!top_cec_dir)
return 0;
 
@@ -395,7 +395,7 @@ static int __init cec_devnode_init(void)
return ret;
}
 
-#ifdef CONFIG_MEDIA_CEC_DEBUG
+#ifdef CONFIG_DEBUG_FS
top_cec_dir = debugfs_create_dir("cec", NULL);
if (IS_ERR_OR_NULL(top_cec_dir)) {
pr_warn("cec: Failed to create debugfs cec dir\n");
-- 
2.11.0

[PATCH for v4.12 2/3] cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER

[Hans Verkuil]

From: Hans Verkuil 

This config option is strictly speaking independent of the
media subsystem since it can be used by drm as well.

Besides, it looks odd when drivers select CEC_CORE and
MEDIA_CEC_NOTIFIER, that's inconsistent naming.

Signed-off-by: Hans Verkuil 
---
 drivers/media/Kconfig  | 2 +-
 drivers/media/cec/Makefile | 2 +-
 drivers/media/cec/cec-core.c   | 4 ++--
 drivers/media/platform/Kconfig | 4 ++--
 include/media/cec-notifier.h   | 2 +-
 include/media/cec.h| 4 ++--
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 9ec634e2f2ba..55d9c2b82b7e 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -5,7 +5,7 @@
 config CEC_CORE
tristate
 
-config MEDIA_CEC_NOTIFIER
+config CEC_NOTIFIER
bool
 
 menuconfig MEDIA_SUPPORT
diff --git a/drivers/media/cec/Makefile b/drivers/media/cec/Makefile
index 402a6c62a3e8..eaf408e64669 100644
--- a/drivers/media/cec/Makefile
+++ b/drivers/media/cec/Makefile
@@ -1,6 +1,6 @@
 cec-objs := cec-core.o cec-adap.o cec-api.o cec-edid.o
 
-ifeq ($(CONFIG_MEDIA_CEC_NOTIFIER),y)
+ifeq ($(CONFIG_CEC_NOTIFIER),y)
   cec-objs += cec-notifier.o
 endif
 
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index f9ebff90f8eb..feeb4c5afa69 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -187,7 +187,7 @@ static void cec_devnode_unregister(struct cec_devnode 
*devnode)
put_device(>dev);
 }
 
-#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+#ifdef CONFIG_CEC_NOTIFIER
 static void cec_cec_notify(struct cec_adapter *adap, u16 pa)
 {
cec_s_phys_addr(adap, pa, false);
@@ -355,7 +355,7 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
 #endif
debugfs_remove_recursive(adap->cec_dir);
-#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+#ifdef CONFIG_CEC_NOTIFIER
if (adap->notifier)
cec_notifier_unregister(adap->notifier);
 #endif
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 017419bef9b1..041cb80a26b1 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -503,7 +503,7 @@ config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
select CEC_CORE
-   select MEDIA_CEC_NOTIFIER
+   select CEC_NOTIFIER
---help---
  This is a driver for Samsung S5P HDMI CEC interface. It uses the
  generic CEC framework interface.
@@ -514,7 +514,7 @@ config VIDEO_STI_HDMI_CEC
tristate "STMicroelectronics STiH4xx HDMI CEC driver"
depends on ARCH_STI || COMPILE_TEST
select CEC_CORE
-   select MEDIA_CEC_NOTIFIER
+   select CEC_NOTIFIER
---help---
  This is a driver for STIH4xx HDMI CEC interface. It uses the
  generic CEC framework interface.
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index 71d7ced2c09e..298f996969df 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -29,7 +29,7 @@ struct edid;
 struct cec_adapter;
 struct cec_notifier;
 
-#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_MEDIA_CEC_NOTIFIER)
+#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
 
 /**
  * cec_notifier_get - find or create a new cec_notifier for the given device.
diff --git a/include/media/cec.h b/include/media/cec.h
index b8eb895731d5..bfa88d4d67e1 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -173,7 +173,7 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
 
-#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+#ifdef CONFIG_CEC_NOTIFIER
struct cec_notifier *notifier;
 #endif
 
@@ -300,7 +300,7 @@ u16 cec_phys_addr_for_input(u16 phys_addr, u8 input);
  */
 int cec_phys_addr_validate(u16 phys_addr, u16 *parent, u16 *port);
 
-#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+#ifdef CONFIG_CEC_NOTIFIER
 void cec_register_cec_notifier(struct cec_adapter *adap,
   struct cec_notifier *notifier);
 #endif
-- 
2.11.0

[PATCH 0/7] tree-wide: use proper 'R-Car' product name

[Wolfram Sang]

Small series to get the R-Car product name proper. Based on
renesas-drivers/master, but can be applied to current linus/master as well.
Except for the MMC patch, which depends on mmc/next.

Please apply.

Wolfram Sang (7):
  dmaengine: use proper name for the R-Car SoC
  i2c: use proper name for the R-Car SoC
  iio: use proper name for the R-Car SoC
  mmc: use proper name for the R-Car SoC
  pci: use proper name for the R-Car SoC
  [media] soc_camera: rcar_vin: use proper name for the R-Car SoC
  [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

 Documentation/devicetree/bindings/dma/shdma.txt   | 2 +-
 Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt | 2 +-
 Documentation/devicetree/bindings/media/rcar_vin.txt  | 4 ++--
 Documentation/devicetree/bindings/pci/rcar-pci.txt| 2 +-
 drivers/i2c/busses/i2c-rcar.c | 2 +-
 drivers/media/platform/rcar_fdp1.c| 2 +-
 drivers/mmc/host/renesas_sdhi_core.c  | 2 +-
 include/linux/mfd/tmio.h  | 2 +-
 8 files changed, 9 insertions(+), 9 deletions(-)

-- 
2.11.0

[PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

[Wolfram Sang]

It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.

Signed-off-by: Wolfram Sang 
---
I suggest this trivial patch should be picked individually per susbsystem.

 drivers/media/platform/rcar_fdp1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar_fdp1.c 
b/drivers/media/platform/rcar_fdp1.c
index 42f25d241edd7c..0da0eba9202cdd 100644
--- a/drivers/media/platform/rcar_fdp1.c
+++ b/drivers/media/platform/rcar_fdp1.c
@@ -1,5 +1,5 @@
 /*
- * Renesas RCar Fine Display Processor
+ * Renesas R-Car Fine Display Processor
  *
  * Video format converter and frame deinterlacer device.
  *
-- 
2.11.0

[PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

[Wolfram Sang]

It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.

Signed-off-by: Wolfram Sang 
---
I suggest this trivial patch should be picked individually per susbsystem.

 Documentation/devicetree/bindings/media/rcar_vin.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 25fc933318483d..4af8760b353339 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -1,5 +1,5 @@
-Renesas RCar Video Input driver (rcar_vin)
---
+Renesas R-Car Video Input driver (rcar_vin)
+---
 
 The rcar_vin device provides video input capabilities for the Renesas R-Car
 family of devices.
-- 
2.11.0

Re: [PATCH 5/7] rc-core: ir-raw - leave the internals of rc_dev alone

[David Härdeman]

On Tue, May 23, 2017 at 10:20:27AM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:10:17PM +0200, David Härdeman wrote:
>> Replace the REP_DELAY value with a static value, which makes more sense.
>> Automatic repeat handling in the input layer has no relevance for the drivers
>> idea of "a long time".
>> 
>> Signed-off-by: David Härdeman 
>> ---
>>  drivers/media/rc/rc-ir-raw.c |4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>> 
>> diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
>> index ae7785c4fbe7..967ab9531e0a 100644
>> --- a/drivers/media/rc/rc-ir-raw.c
>> +++ b/drivers/media/rc/rc-ir-raw.c
>> @@ -102,20 +102,18 @@ int ir_raw_event_store_edge(struct rc_dev *dev, enum 
>> raw_event_type type)
>>  s64 delta; /* ns */
>>  DEFINE_IR_RAW_EVENT(ev);
>>  int rc = 0;
>> -int delay;
>>  
>>  if (!dev->raw)
>>  return -EINVAL;
>>  
>>  now = ktime_get();
>>  delta = ktime_to_ns(ktime_sub(now, dev->raw->last_event));
>> -delay = MS_TO_NS(dev->input_dev->rep[REP_DELAY]);
>>  
>>  /* Check for a long duration since last event or if we're
>>   * being called for the first time, note that delta can't
>>   * possibly be negative.
>>   */
>> -if (delta > delay || !dev->raw->last_type)
>> +if (delta > MS_TO_NS(500) || !dev->raw->last_type)
>>  type |= IR_START_EVENT;
>
>So this is just a fail-safe to ensure that the IR decoders are reset after
>a period of IR silence. The decoders should reset themselves anyway if they
>receive a long space, so it's just belt and braces.

Not 100% sure but it also checks for the first call to
ir_raw_event_store_edge()...

>Why is a static value better? At least REP_DELAY can be changed from
>user space.

REP_DELAY serves a completely different purpose. It controls how long a
key should be pressed before the input layer should start generating
soft-repeat events.

The timeout here is related to the IR protocol handling...which is a
quite different matter.

>Maybe we should do away with it.

Maybe...but that'd be a different patch...I think this fix should go in
nevertheless.

-- 
David Härdeman

Re: [PATCH 3/7] rc-core: img-nec-decoder - leave the internals of rc_dev alone

[David Härdeman]

On Mon, May 22, 2017 at 09:40:30PM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:10:06PM +0200, David Härdeman wrote:
>> Obvious fix, leave repeat handling to rc-core
>> 
>> Signed-off-by: David Härdeman 
>> ---
>>  drivers/media/rc/ir-nec-decoder.c |   10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>> 
>> diff --git a/drivers/media/rc/ir-nec-decoder.c 
>> b/drivers/media/rc/ir-nec-decoder.c
>> index 3ce850314dca..75b9137f6faf 100644
>> --- a/drivers/media/rc/ir-nec-decoder.c
>> +++ b/drivers/media/rc/ir-nec-decoder.c
>> @@ -88,13 +88,9 @@ static int ir_nec_decode(struct rc_dev *dev, struct 
>> ir_raw_event ev)
>>  data->state = STATE_BIT_PULSE;
>>  return 0;
>>  } else if (eq_margin(ev.duration, NEC_REPEAT_SPACE, NEC_UNIT / 
>> 2)) {
>> -if (!dev->keypressed) {
>> -IR_dprintk(1, "Discarding last key repeat: 
>> event after key up\n");
>> -} else {
>> -rc_repeat(dev);
>> -IR_dprintk(1, "Repeat last key\n");
>> -data->state = STATE_TRAILER_PULSE;
>> -}
>> +rc_repeat(dev);
>> +IR_dprintk(1, "Repeat last key\n");
>> +data->state = STATE_TRAILER_PULSE;
>
>This is not correct. This means that whenever a nec repeat is received,
>the last scancode is sent to the input device, irrespective of whether
>there has been no IR for hours. The original code is stricter.

I think that'd be an argument for moving the check to rc_repeat().

But, on the other hand, sending an input scancode for each repeat event
seems kind of pointless, doesn't it? If so, it might make more sense to
just remove the input event generation from rc_repeat() altogether...

-- 
David Härdeman

Re: [PATCH 13/16] lirc_dev: use an ida instead of a hand-rolled array to keep track of minors

[David Härdeman]

On Mon, May 22, 2017 at 09:09:42PM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:04:42PM +0200, David Härdeman wrote:
>> Using the kernel ida facilities, we can avoid a lot of unnecessary code and 
>> at the same
>> time get rid of lirc_dev_lock in favour of per-device locks (the irctls 
>> array was used
>> throughout lirc_dev so this patch necessarily touches a lot of code).
>> 
>> Signed-off-by: David Härdeman 
>> ---
>>  drivers/media/rc/ir-lirc-codec.c|9 -
>>  drivers/media/rc/lirc_dev.c |  258 
>> ---
>>  drivers/staging/media/lirc/lirc_zilog.c |   16 +-
>>  include/media/lirc_dev.h|   14 --
>>  4 files changed, 115 insertions(+), 182 deletions(-)
>> 
>> diff --git a/drivers/media/rc/ir-lirc-codec.c 
>> b/drivers/media/rc/ir-lirc-codec.c
>> index a30af91710fe..2c1221a61ea1 100644
>> --- a/drivers/media/rc/ir-lirc-codec.c
>> +++ b/drivers/media/rc/ir-lirc-codec.c
>> @@ -382,7 +382,6 @@ static int ir_lirc_register(struct rc_dev *dev)
>>  
>>  snprintf(drv->name, sizeof(drv->name), "ir-lirc-codec (%s)",
>>   dev->driver_name);
>> -drv->minor = -1;
>>  drv->features = features;
>>  drv->data = >raw->lirc;
>>  drv->rbuf = NULL;
>> @@ -394,11 +393,9 @@ static int ir_lirc_register(struct rc_dev *dev)
>>  drv->rdev = dev;
>>  drv->owner = THIS_MODULE;
>>  
>> -drv->minor = lirc_register_driver(drv);
>> -if (drv->minor < 0) {
>> -rc = -ENODEV;
>> +rc = lirc_register_driver(drv);
>> +if (rc < 0)
>>  goto out;
>> -}
>>  
>>  dev->raw->lirc.drv = drv;
>>  dev->raw->lirc.dev = dev;
>> @@ -413,7 +410,7 @@ static int ir_lirc_unregister(struct rc_dev *dev)
>>  {
>>  struct lirc_codec *lirc = >raw->lirc;
>>  
>> -lirc_unregister_driver(lirc->drv->minor);
>> +lirc_unregister_driver(lirc->drv);
>>  kfree(lirc->drv);
>>  lirc->drv = NULL;
>>  
>> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
>> index e44e0b23b883..7db7d4c57991 100644
>> --- a/drivers/media/rc/lirc_dev.c
>> +++ b/drivers/media/rc/lirc_dev.c
>> @@ -31,23 +31,35 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  #include 
>>  #include 
>>  
>>  #define IRCTL_DEV_NAME  "BaseRemoteCtl"
>> -#define NOPLUG  -1
>>  #define LOGHEAD "lirc_dev (%s[%d]): "
>>  
>>  static dev_t lirc_base_dev;
>>  
>> +/**
>> + * struct irctl - lirc per-device structure
>> + * @d:  internal copy of the  lirc_driver for 
>> the device
>> + * @dead:   if the device has gone away
>> + * @users:  the number of users of the lirc chardev (currently 
>> limited to 1)
>> + * @mutex:  synchronizes open()/close()/ioctl()/etc calls
>> + * @buf:used to store lirc RX data
>> + * @buf_internal:   whether @buf was allocated internally or not
>> + * @chunk_size: @buf stores and read() returns data chunks of 
>> this size
>> + * @dev:the  device for the lirc device
>> + * @cdev:   the  device for the lirc chardev
>> + */
>>  struct irctl {
>>  struct lirc_driver d;
>> -int attached;
>> -int open;
>> +bool dead;
>> +unsigned users;
>>  
>> -struct mutex irctl_lock;
>> +struct mutex mutex;
>>  struct lirc_buffer *buf;
>>  bool buf_internal;
>>  unsigned int chunk_size;
>> @@ -56,9 +68,9 @@ struct irctl {
>>  struct cdev cdev;
>>  };
>>  
>> -static DEFINE_MUTEX(lirc_dev_lock);
>> -
>> -static struct irctl *irctls[MAX_IRCTL_DEVICES];
>> +/* Used to keep track of allocated lirc devices */
>> +#define LIRC_MAX_DEVICES 256
>> +static DEFINE_IDA(lirc_ida);
>>  
>>  /* Only used for sysfs but defined to void otherwise */
>>  static struct class *lirc_class;
>> @@ -72,9 +84,6 @@ static void lirc_release(struct device *ld)
>>  kfree(ir->buf);
>>  }
>>  
>> -mutex_lock(_dev_lock);
>> -irctls[ir->d.minor] = NULL;
>> -mutex_unlock(_dev_lock);
>>  kfree(ir);
>>  }
>>  
>> @@ -117,7 +126,18 @@ static int lirc_allocate_buffer(struct irctl *ir)
>>  return err;
>>  }
>>  
>> -int lirc_register_driver(struct lirc_driver *d)
>> +/**
>> + * lirc_register_driver() - create a new lirc device by registering a driver
>> + * @d: the  lirc_driver to register
>> + *
>> + * This function allocates and registers a lirc device for a given
>> + * _driver. The _driver structure is updated to contain
>> + * information about the allocated device (minor, buffer, etc).
>> + *
>> + * Return: zero on success or a negative error value.
>> + */
>> +int
>> +lirc_register_driver(struct lirc_driver *d)
>>  {
>>  struct irctl *ir;
>>  int minor;
>> @@ -138,12 +158,6 @@ int lirc_register_driver(struct lirc_driver *d)
>>  return -EINVAL;
>>  }
>>  
>> -if (d->minor >= MAX_IRCTL_DEVICES) {
>> -dev_err(d->dev, "minor must be between 0 and %d!\n",
>> -   

Re: [PATCH 03/16] lirc_dev: correct error handling

[David Härdeman]

On Sun, May 21, 2017 at 09:57:13AM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:03:51PM +0200, David Härdeman wrote:
>> If an error is generated, nonseekable_open() shouldn't be called.
>
>There is no harm in calling nonseekable_open(), so this commit is
>misleading.

I'm not sure why you consider it misleading? If there's an error, the
logic thing to do is to error out immediately and not do any further
work?

>> Signed-off-by: David Härdeman 
>> ---
>>  drivers/media/rc/lirc_dev.c |6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
>> index 05f600bd6c67..7f13ed479e1c 100644
>> --- a/drivers/media/rc/lirc_dev.c
>> +++ b/drivers/media/rc/lirc_dev.c
>> @@ -431,7 +431,7 @@ EXPORT_SYMBOL(lirc_unregister_driver);
>>  int lirc_dev_fop_open(struct inode *inode, struct file *file)
>>  {
>>  struct irctl *ir;
>> -int retval = 0;
>> +int retval;
>>  
>>  if (iminor(inode) >= MAX_IRCTL_DEVICES) {
>>  pr_err("open result for %d is -ENODEV\n", iminor(inode));
>> @@ -475,9 +475,11 @@ int lirc_dev_fop_open(struct inode *inode, struct file 
>> *file)
>>  
>>  ir->open++;
>>  
>> -error:
>>  nonseekable_open(inode, file);
>>  
>> +return 0;
>> +
>> +error:
>>  return retval;
>>  }
>>  EXPORT_SYMBOL(lirc_dev_fop_open);

-- 
David Härdeman