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:   Tue Oct 10 05:00:14 CEST 2017
media-tree git hash:c1301077213d4dca34f01fc372b64d3c4a49a437
media_build git hash:   4f1031979bd1ff205f19f88c85f387d6e5408f5e
v4l-utils git hash: 01c04f7c8ad1a91af33e20621eba9200f447737e
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.12.0-164

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-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.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: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-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: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
apps: OK
spec-git: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCHv3 0/2] drm/bridge/adv7511: add CEC support

[Archit Taneja]

On 10/07/2017 04:16 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.



queued to drm-misc-next.

Thanks,
Archit


Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S

Regards,

Hans

Changes since v2:
- A small rewording of the 'clocks' property description in the bindings
   as per Sergei's comment.

Changes since v1:
- Incorporate Archit's comments:
use defines for irq masks
combine the adv7511/33 regmap_configs
adv7511_cec_init now handles dt parsing & CEC registration
- Use the new (4.14) CEC_CAP_DEFAULTS define

Hans Verkuil (2):
   dt-bindings: adi,adv7511.txt: document cec clock
   drm: adv7511/33: add HDMI CEC support

  .../bindings/display/bridge/adi,adv7511.txt|   4 +
  drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  43 ++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 337 +
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 116 ++-
  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  38 +--
  7 files changed, 489 insertions(+), 58 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 4/5] media: atmel-isc: Remove unnecessary member

[Wenyou Yang]

Remove the memeber *config from the isc_subdev_entity struct,
the member is useless afterward.

Signed-off-by: Wenyou Yang 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/media/platform/atmel/atmel-isc.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index a44a66ad2c02..29780fcdfc8b 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -83,7 +83,6 @@ struct isc_subdev_entity {
struct v4l2_subdev  *sd;
struct v4l2_async_subdev*asd;
struct v4l2_async_notifier  notifier;
-   struct v4l2_subdev_pad_config   *config;
 
u32 pfe_cfg0;
 
@@ -1000,6 +999,7 @@ static int isc_try_fmt(struct isc_device *isc, struct 
v4l2_format *f,
 {
struct isc_format *isc_fmt;
struct v4l2_pix_format *pixfmt = >fmt.pix;
+   struct v4l2_subdev_pad_config pad_cfg;
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_TRY,
};
@@ -1030,7 +1030,7 @@ static int isc_try_fmt(struct isc_device *isc, struct 
v4l2_format *f,
 
v4l2_fill_mbus_format(, pixfmt, mbus_code);
ret = v4l2_subdev_call(isc->current_subdev->sd, pad, set_fmt,
-  isc->current_subdev->config, );
+  _cfg, );
if (ret < 0)
return ret;
 
@@ -1495,8 +1495,6 @@ static void isc_async_unbind(struct v4l2_async_notifier 
*notifier,
  struct isc_device, v4l2_dev);
cancel_work_sync(>awb_work);
video_unregister_device(>video_dev);
-   if (isc->current_subdev->config)
-   v4l2_subdev_free_pad_config(isc->current_subdev->config);
v4l2_ctrl_handler_free(>ctrls.handler);
 }
 
@@ -1648,10 +1646,6 @@ static int isc_async_complete(struct v4l2_async_notifier 
*notifier)
INIT_LIST_HEAD(>dma_queue);
spin_lock_init(>dma_queue_lock);
 
-   sd_entity->config = v4l2_subdev_alloc_pad_config(sd_entity->sd);
-   if (!sd_entity->config)
-   return -ENOMEM;
-
ret = isc_formats_init(isc);
if (ret < 0) {
v4l2_err(>v4l2_dev,
-- 
2.13.0

[PATCH v4 5/5] media: atmel-isc: Rework the format list

[Wenyou Yang]

To improve the readability of code, split the format array into two,
one for the format description, other for the register configuration.
Meanwhile, add the flag member to indicate the format can be achieved
from the sensor or be produced by the controller, and rename members
related to the register configuration.

Also add more formats support: GREY, ARGB444, ARGB555 and ARGB32.

Signed-off-by: Wenyou Yang 
---

Changes in v4: None
Changes in v3:
 - Add a new flag for Raw Bayer format to remove MAX_RAW_FMT_INDEX define.
 - Add the comments for define of the format flag.
 - Rebase media_tree/master.

Changes in v2:
 - Add the new patch to remove the unnecessary member from
   isc_subdev_entity struct.
 - Rebase on the patch set,
[PATCH 0/6] [media] Atmel: Adjustments for seven function 
implementations
https://www.mail-archive.com/linux-media@vger.kernel.org/msg118342.html

 drivers/media/platform/atmel/atmel-isc.c | 530 ---
 1 file changed, 411 insertions(+), 119 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 29780fcdfc8b..2c40a7886542 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -89,34 +89,63 @@ struct isc_subdev_entity {
struct list_head list;
 };
 
+/* Indicate the format is generated by the sensor */
+#define FMT_FLAG_FROM_SENSOR   BIT(0)
+/* Indicate the format is produced by ISC itself */
+#define FMT_FLAG_FROM_CONTROLLER   BIT(1)
+/* Indicate a Raw Bayer format */
+#define FMT_FLAG_RAW_FORMATBIT(2)
+
+#define FMT_FLAG_RAW_FROM_SENSOR   (FMT_FLAG_FROM_SENSOR | \
+FMT_FLAG_RAW_FORMAT)
+
 /*
  * struct isc_format - ISC media bus format information
  * @fourcc:Fourcc code for this format
  * @mbus_code: V4L2 media bus format code.
+ * flags:  Indicate format from sensor or converted by controller
  * @bpp:   Bits per pixel (when stored in memory)
- * @reg_bps:   reg value for bits per sample
  * (when transferred over a bus)
- * @pipeline:  pipeline switch
  * @sd_support:Subdev supports this format
  * @isc_support:   ISC can convert raw format to this format
  */
+
 struct isc_format {
u32 fourcc;
u32 mbus_code;
+   u32 flags;
u8  bpp;
 
-   u32 reg_bps;
-   u32 reg_bay_cfg;
-   u32 reg_rlp_mode;
-   u32 reg_dcfg_imode;
-   u32 reg_dctrl_dview;
-
-   u32 pipeline;
-
boolsd_support;
boolisc_support;
 };
 
+/* Pipeline bitmap */
+#define WB_ENABLE  BIT(0)
+#define CFA_ENABLE BIT(1)
+#define CC_ENABLE  BIT(2)
+#define GAM_ENABLE BIT(3)
+#define GAM_BENABLEBIT(4)
+#define GAM_GENABLEBIT(5)
+#define GAM_RENABLEBIT(6)
+#define CSC_ENABLE BIT(7)
+#define CBC_ENABLE BIT(8)
+#define SUB422_ENABLE  BIT(9)
+#define SUB420_ENABLE  BIT(10)
+
+#define GAM_ENABLES(GAM_RENABLE | GAM_GENABLE | GAM_BENABLE | GAM_ENABLE)
+
+struct fmt_config {
+   u32 fourcc;
+
+   u32 pfe_cfg0_bps;
+   u32 cfa_baycfg;
+   u32 rlp_cfg_mode;
+   u32 dcfg_imode;
+   u32 dctrl_dview;
+
+   u32 bits_pipeline;
+};
 
 #define HIST_ENTRIES   512
 #define HIST_BAYER (ISC_HIS_CFG_MODE_B + 1)
@@ -181,80 +210,320 @@ struct isc_device {
struct list_headsubdev_entities;
 };
 
-#define RAW_FMT_IND_START0
-#define RAW_FMT_IND_END  11
-#define ISC_FMT_IND_START12
-#define ISC_FMT_IND_END  14
-
-static struct isc_format isc_formats[] = {
-   { V4L2_PIX_FMT_SBGGR8, MEDIA_BUS_FMT_SBGGR8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGBRG8, MEDIA_BUS_FMT_SGBRG8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGRBG8, MEDIA_BUS_FMT_SGRBG8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GRGR, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SRGGB8, MEDIA_BUS_FMT_SRGGB8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_RGRG, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-
-   { V4L2_PIX_FMT_SBGGR10, MEDIA_BUS_FMT_SBGGR10_1X10, 16,
- ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGBRG10, MEDIA_BUS_FMT_SGBRG10_1X10, 16,
- 

[PATCH v4 3/5] media: atmel-isc: Enable the clocks during probe

[Wenyou Yang]

To meet the relationship, enable the HCLOCK and ispck during the
device probe, "isc_pck frequency is less than or equal to isc_ispck,
and isc_ispck is greater than or equal to HCLOCK."
Meanwhile, call the pm_runtime_enable() in the right place.

Signed-off-by: Wenyou Yang 
---

Changes in v4:
 - Move pm_runtime_enable() call from the complete callback to the
   end of probe.
 - Call pm_runtime_get_sync() and pm_runtime_put_sync() in
   ->is_enabled() callbacks.
 - Call clk_disable_unprepare() in ->remove callback.

Changes in v3: None
Changes in v2: None

 drivers/media/platform/atmel/atmel-isc.c | 34 
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 5f8228fc9c8d..a44a66ad2c02 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -389,8 +389,14 @@ static int isc_clk_is_enabled(struct clk_hw *hw)
struct isc_clk *isc_clk = to_isc_clk(hw);
u32 status;
 
+   if (isc_clk->id == ISC_MCK)
+   pm_runtime_get_sync(isc_clk->dev);
+
regmap_read(isc_clk->regmap, ISC_CLKSR, );
 
+   if (isc_clk->id == ISC_MCK)
+   pm_runtime_put_sync(isc_clk->dev);
+
return status & ISC_CLK(isc_clk->id) ? 1 : 0;
 }
 
@@ -1866,25 +1872,37 @@ static int atmel_isc_probe(struct platform_device *pdev)
return ret;
}
 
+   ret = clk_prepare_enable(isc->hclock);
+   if (ret) {
+   dev_err(dev, "failed to enable hclock: %d\n", ret);
+   return ret;
+   }
+
ret = isc_clk_init(isc);
if (ret) {
dev_err(dev, "failed to init isc clock: %d\n", ret);
-   goto clean_isc_clk;
+   goto unprepare_hclk;
}
 
isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
 
+   ret = clk_prepare_enable(isc->ispck);
+   if (ret) {
+   dev_err(dev, "failed to enable ispck: %d\n", ret);
+   goto unprepare_hclk;
+   }
+
/* ispck should be greater or equal to hclock */
ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
if (ret) {
dev_err(dev, "failed to set ispck rate: %d\n", ret);
-   goto clean_isc_clk;
+   goto unprepare_clk;
}
 
ret = v4l2_device_register(dev, >v4l2_dev);
if (ret) {
dev_err(dev, "unable to register v4l2 device.\n");
-   goto clean_isc_clk;
+   goto unprepare_clk;
}
 
ret = isc_parse_dt(dev, isc);
@@ -1917,7 +1935,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
break;
}
 
+   pm_runtime_set_active(dev);
pm_runtime_enable(dev);
+   pm_request_idle(dev);
 
return 0;
 
@@ -1927,7 +1947,11 @@ static int atmel_isc_probe(struct platform_device *pdev)
 unregister_v4l2_device:
v4l2_device_unregister(>v4l2_dev);
 
-clean_isc_clk:
+unprepare_clk:
+   clk_disable_unprepare(isc->ispck);
+unprepare_hclk:
+   clk_disable_unprepare(isc->hclock);
+
isc_clk_cleanup(isc);
 
return ret;
@@ -1938,6 +1962,8 @@ static int atmel_isc_remove(struct platform_device *pdev)
struct isc_device *isc = platform_get_drvdata(pdev);
 
pm_runtime_disable(>dev);
+   clk_disable_unprepare(isc->ispck);
+   clk_disable_unprepare(isc->hclock);
 
isc_subdev_cleanup(isc);
 
-- 
2.13.0

[PATCH v4 2/5] media: atmel-isc: Add prepare and unprepare ops

[Wenyou Yang]

A software write operation to the ISC_CLKEN or ISC_CLKDIS register
requires double clock domain synchronization and is not permitted
when the ISC_SR.SIP is asserted. So add the .prepare and .unprepare
ops to make sure the ISC_CLKSR.SIP is unasserted before the write
operation to the ISC_CLKEN or ISC_CLKDIS register.

Signed-off-by: Wenyou Yang 
---

Changes in v4:
 - Call pm_runtime_get_sync() and pm_runtime_put_sync() in ->prepare
   and ->unprepare callback.

Changes in v3: None
Changes in v2: None

 drivers/media/platform/atmel/atmel-isc-regs.h |  1 +
 drivers/media/platform/atmel/atmel-isc.c  | 40 +++
 2 files changed, 41 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h 
b/drivers/media/platform/atmel/atmel-isc-regs.h
index 6936ac467609..93e58fcf1d5f 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -42,6 +42,7 @@
 
 /* ISC Clock Status Register */
 #define ISC_CLKSR   0x0020
+#define ISC_CLKSR_SIP  BIT(31)
 
 #define ISC_CLK(n) BIT(n)
 
diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 991f962b7023..5f8228fc9c8d 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -308,6 +308,44 @@ module_param(sensor_preferred, uint, 0644);
 MODULE_PARM_DESC(sensor_preferred,
 "Sensor is preferred to output the specified format (1-on 
0-off), default 1");
 
+static int isc_wait_clk_stable(struct clk_hw *hw)
+{
+   struct isc_clk *isc_clk = to_isc_clk(hw);
+   struct regmap *regmap = isc_clk->regmap;
+   unsigned long timeout = jiffies + usecs_to_jiffies(1000);
+   unsigned int status;
+
+   while (time_before(jiffies, timeout)) {
+   regmap_read(regmap, ISC_CLKSR, );
+   if (!(status & ISC_CLKSR_SIP))
+   return 0;
+
+   usleep_range(10, 250);
+   }
+
+   return -ETIMEDOUT;
+}
+
+static int isc_clk_prepare(struct clk_hw *hw)
+{
+   struct isc_clk *isc_clk = to_isc_clk(hw);
+
+   if (isc_clk->id == ISC_MCK)
+   pm_runtime_get_sync(isc_clk->dev);
+
+   return isc_wait_clk_stable(hw);
+}
+
+static void isc_clk_unprepare(struct clk_hw *hw)
+{
+   struct isc_clk *isc_clk = to_isc_clk(hw);
+
+   isc_wait_clk_stable(hw);
+
+   if (isc_clk->id == ISC_MCK)
+   pm_runtime_put_sync(isc_clk->dev);
+}
+
 static int isc_clk_enable(struct clk_hw *hw)
 {
struct isc_clk *isc_clk = to_isc_clk(hw);
@@ -459,6 +497,8 @@ static int isc_clk_set_rate(struct clk_hw *hw,
 }
 
 static const struct clk_ops isc_clk_ops = {
+   .prepare= isc_clk_prepare,
+   .unprepare  = isc_clk_unprepare,
.enable = isc_clk_enable,
.disable= isc_clk_disable,
.is_enabled = isc_clk_is_enabled,
-- 
2.13.0

[PATCH v4 1/5] media: atmel-isc: Add spin lock for clock enable ops

[Wenyou Yang]

Add the spin lock for the clock enable and disable operations.

Signed-off-by: Wenyou Yang 
---

Changes in v4: None
Changes in v3:
 - Fix the wrong used spinlock.
 - s/_/- on the subject.

Changes in v2: None

 drivers/media/platform/atmel/atmel-isc.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 2f8e345d297e..991f962b7023 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -65,6 +65,7 @@ struct isc_clk {
struct clk_hw   hw;
struct clk  *clk;
struct regmap   *regmap;
+   spinlock_t  lock;
u8  id;
u8  parent_id;
u32 div;
@@ -312,26 +313,37 @@ static int isc_clk_enable(struct clk_hw *hw)
struct isc_clk *isc_clk = to_isc_clk(hw);
u32 id = isc_clk->id;
struct regmap *regmap = isc_clk->regmap;
+   unsigned long flags;
+   unsigned int status;
 
dev_dbg(isc_clk->dev, "ISC CLK: %s, div = %d, parent id = %d\n",
__func__, isc_clk->div, isc_clk->parent_id);
 
+   spin_lock_irqsave(_clk->lock, flags);
regmap_update_bits(regmap, ISC_CLKCFG,
   ISC_CLKCFG_DIV_MASK(id) | ISC_CLKCFG_SEL_MASK(id),
   (isc_clk->div << ISC_CLKCFG_DIV_SHIFT(id)) |
   (isc_clk->parent_id << ISC_CLKCFG_SEL_SHIFT(id)));
 
regmap_write(regmap, ISC_CLKEN, ISC_CLK(id));
+   spin_unlock_irqrestore(_clk->lock, flags);
 
-   return 0;
+   regmap_read(regmap, ISC_CLKSR, );
+   if (status & ISC_CLK(id))
+   return 0;
+   else
+   return -EINVAL;
 }
 
 static void isc_clk_disable(struct clk_hw *hw)
 {
struct isc_clk *isc_clk = to_isc_clk(hw);
u32 id = isc_clk->id;
+   unsigned long flags;
 
+   spin_lock_irqsave(_clk->lock, flags);
regmap_write(isc_clk->regmap, ISC_CLKDIS, ISC_CLK(id));
+   spin_unlock_irqrestore(_clk->lock, flags);
 }
 
 static int isc_clk_is_enabled(struct clk_hw *hw)
@@ -492,6 +504,7 @@ static int isc_clk_register(struct isc_device *isc, 
unsigned int id)
isc_clk->regmap = regmap;
isc_clk->id = id;
isc_clk->dev= isc->dev;
+   spin_lock_init(_clk->lock);
 
isc_clk->clk = clk_register(isc->dev, _clk->hw);
if (IS_ERR(isc_clk->clk)) {
-- 
2.13.0

[PATCH v4 0/5] media: atmel-isc: Rework the format list and clock provider

[Wenyou Yang]

To improve the readability of code, rework the format list table,
split the format array into two. Meanwhile, fix the issue of the
clock provider operation and the pm runtime support.

Changes in v4:
 - Call pm_runtime_get_sync() and pm_runtime_put_sync() in ->prepare
   and ->unprepare callback.
 - Move pm_runtime_enable() call from the complete callback to the
   end of probe.
 - Call pm_runtime_get_sync() and pm_runtime_put_sync() in
   ->is_enabled() callbacks.
 - Call clk_disable_unprepare() in ->remove callback.

Changes in v3:
 - Fix the wrong used spinlock.
 - s/_/- on the subject.
 - Add a new flag for Raw Bayer format to remove MAX_RAW_FMT_INDEX define.
 - Add the comments for define of the format flag.
 - Rebase media_tree/master.

Changes in v2:
 - Add the new patch to remove the unnecessary member from
   isc_subdev_entity struct.
 - Rebase on the patch set,
[PATCH 0/6] [media] Atmel: Adjustments for seven function 
implementations
https://www.mail-archive.com/linux-media@vger.kernel.org/msg118342.html

Wenyou Yang (5):
  media: atmel-isc: Add spin lock for clock enable ops
  media: atmel-isc: Add prepare and unprepare ops
  media: atmel-isc: Enable the clocks during probe
  media: atmel-isc: Remove unnecessary member
  media: atmel-isc: Rework the format list

 drivers/media/platform/atmel/atmel-isc-regs.h |   1 +
 drivers/media/platform/atmel/atmel-isc.c  | 629 --
 2 files changed, 498 insertions(+), 132 deletions(-)

-- 
2.13.0

Re: [PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

[Nicolas Dufresne]

I confirm this works properly now. This was tested with GStreamer with
the following command:

  gst-launch-1.0 videotestsrc ! v4l2vp8enc ! v4l2vp8dec ! kmssink

And the following patch, which is work in progress to implement
data_offset.

  
https://gitlab.collabora.com/nicolas/gst-plugins-good/commit/aaedee9a37e396657568a70fc0110375e14fb4fa

Le lundi 09 octobre 2017 à 15:24 +0300, Stanimir Varbanov a écrit :
> This fixes wrongly filled bytesused field of v4l2_plane structure
> by include data_offset in the plane, Also fill data_offset and
> bytesused for capture type of buffers only.
> 
> Signed-off-by: Stanimir Varbanov 

Tested-by: Nicolas Dufresne 

> ---
>  drivers/media/platform/qcom/venus/venc.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/venc.c 
> b/drivers/media/platform/qcom/venus/venc.c
> index 6f123a387cf9..9445ad492966 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -963,15 +963,16 @@ static void venc_buf_done(struct venus_inst *inst, 
> unsigned int buf_type,
>   if (!vbuf)
>   return;
>  
> - vb = >vb2_buf;
> - vb->planes[0].bytesused = bytesused;
> - vb->planes[0].data_offset = data_offset;
> -
>   vbuf->flags = flags;
>  
>   if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + vb = >vb2_buf;
> + vb2_set_plane_payload(vb, 0, bytesused + data_offset);
> + vb->planes[0].data_offset = data_offset;
>   vb->timestamp = timestamp_us * NSEC_PER_USEC;
>   vbuf->sequence = inst->sequence_cap++;
> +
> + WARN_ON(vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0));
>   } else {
>   vbuf->sequence = inst->sequence_out++;
>   }

Re: [PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

[Stanimir Varbanov]

Hans,

On  9.10.2017 15:31, Hans Verkuil wrote:

On 09/10/17 14:24, Stanimir Varbanov wrote:

This fixes wrongly filled bytesused field of v4l2_plane structure
by include data_offset in the plane, Also fill data_offset and
bytesused for capture type of buffers only.

Signed-off-by: Stanimir Varbanov 
---
  drivers/media/platform/qcom/venus/venc.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 6f123a387cf9..9445ad492966 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -963,15 +963,16 @@ static void venc_buf_done(struct venus_inst *inst, 
unsigned int buf_type,
if (!vbuf)
return;
  
-	vb = >vb2_buf;

-   vb->planes[0].bytesused = bytesused;
-   vb->planes[0].data_offset = data_offset;
-
vbuf->flags = flags;
  
  	if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {

+   vb = >vb2_buf;
+   vb2_set_plane_payload(vb, 0, bytesused + data_offset);
+   vb->planes[0].data_offset = data_offset;
vb->timestamp = timestamp_us * NSEC_PER_USEC;
vbuf->sequence = inst->sequence_cap++;
+
+   WARN_ON(vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0));


It's good to have this, but this really should never happen. Because if it is,
then you'll have a memory overwrite. I hope the DMA engine will prevent this? >
Just wondering how this works.

The patch looks good otherwise, but that WARN_ON is a bit scary.


Infact it is not so scary as it looks like, the IOMMU will catch this 
and generate a fault. So most probably we will never come to the WARN, 
thus the warning is pointless so will delete it.


regards,
Stan

Re: [PATCH 16/24] media: v4l2-subdev: document remaining undocumented functions

[Sakari Ailus]

On Mon, Oct 09, 2017 at 07:19:22AM -0300, Mauro Carvalho Chehab wrote:
> There are several undocumented v4l2-subdev functions that are
> part of kAPI. Document them.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/v4l2-subdev.h | 70 
> +
>  1 file changed, 65 insertions(+), 5 deletions(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 35c4476c56ee..e215732eed45 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -868,6 +868,13 @@ struct v4l2_subdev {
>   struct v4l2_subdev_platform_data *pdata;
>  };
>  
> +
> +/**
> + * media_entity_to_v4l2_subdev - Returns a  v4l2_subdev from
> + * the  media_entity embedded on it.

I'd add that "calling this macro with NULL argument safely returns NULL".

> + *
> + * @ent: pointer to  media_entity.
> + */
>  #define media_entity_to_v4l2_subdev(ent) \
>  ({   \
>   typeof(ent) __me_sd_ent = (ent);\
> @@ -877,14 +884,20 @@ struct v4l2_subdev {
>   NULL;   \
>  })
>  
> +/**
> + * vdev_to_v4l2_subdev - Returns a  v4l2_subdev from
> + * the  video_device embedded on it.
> + *
> + * @vdev: pointer to  video_device
> + */
>  #define vdev_to_v4l2_subdev(vdev) \
>   ((struct v4l2_subdev *)video_get_drvdata(vdev))
>  
>  /**
>   * struct v4l2_subdev_fh - Used for storing subdev information per file 
> handle
>   *
> - * @vfh: pointer to struct v4l2_fh
> - * @pad: pointer to v4l2_subdev_pad_config
> + * @vfh: pointer to  v4l2_fh
> + * @pad: pointer to  v4l2_subdev_pad_config
>   */
>  struct v4l2_subdev_fh {
>   struct v4l2_fh vfh;
> @@ -893,10 +906,25 @@ struct v4l2_subdev_fh {
>  #endif
>  };
>  
> +/**
> + * to_v4l2_subdev_fh - Returns a  v4l2_subdev_fh from
> + * the  v4l2_fh embedded on it.

s/on/in/

> + *
> + * @fh: pointer to  v4l2_fh
> + */
>  #define to_v4l2_subdev_fh(fh)\
>   container_of(fh, struct v4l2_subdev_fh, vfh)
>  
>  #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
> +
> +/**
> + * v4l2_subdev_get_try_format - ancillary routine to call
> + *v4l2_subdev_pad_config->try_fmt
> + *
> + * @sd: pointer to  v4l2_subdev
> + * @cfg: pointer to  v4l2_subdev_pad_config array.
> + * @pad: index of the pad a the @cfg array.

s/a /in /

The same for the other instances.

> + */
>  static inline struct v4l2_mbus_framefmt
>  *v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
>   struct v4l2_subdev_pad_config *cfg,
> @@ -906,6 +934,14 @@ static inline struct v4l2_mbus_framefmt
>   return [pad].try_fmt;
>  }
>  
> +/**
> + * v4l2_subdev_get_try_crop - ancillary routine to call
> + *v4l2_subdev_pad_config->try_crop
> + *
> + * @sd: pointer to  v4l2_subdev
> + * @cfg: pointer to  v4l2_subdev_pad_config array.
> + * @pad: index of the pad a the @cfg array.
> + */
>  static inline struct v4l2_rect
>  *v4l2_subdev_get_try_crop(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> @@ -915,6 +951,14 @@ static inline struct v4l2_rect
>   return [pad].try_crop;
>  }
>  
> +/**
> + * v4l2_subdev_get_try_crop - ancillary routine to call
> + *v4l2_subdev_pad_config->try_compose
> + *
> + * @sd: pointer to  v4l2_subdev
> + * @cfg: pointer to  v4l2_subdev_pad_config array.
> + * @pad: index of the pad a the @cfg array.
> + */
>  static inline struct v4l2_rect
>  *v4l2_subdev_get_try_compose(struct v4l2_subdev *sd,
>struct v4l2_subdev_pad_config *cfg,
> @@ -1030,9 +1074,17 @@ void v4l2_subdev_free_pad_config(struct 
> v4l2_subdev_pad_config *cfg);
>  void v4l2_subdev_init(struct v4l2_subdev *sd,
> const struct v4l2_subdev_ops *ops);
>  
> -/*
> - * Call an ops of a v4l2_subdev, doing the right checks against
> - * NULL pointers.
> +/**
> + * v4l2_subdev_call - call an ops of a v4l2_subdev, doing the right checks

s/ops/operation/ ?

> + *   against NULL pointers.

We already say in struct v4l2_subdev_ops documentation that the individual
ops may be NULL. I think that should be enough.

> + *
> + * @sd: pointer to the  v4l2_subdev
> + * @o: name of the element at  v4l2_subdev_ops that contains @f.
> + * Each element there groups a set of callbacks functions.
> + * @f: callback function that will be called if @cond matches.
> + * The callback functions are defined in groups, according to
> + * each element at  v4l2_subdev_ops.
> + * @args...: arguments for @f.
>   *
>   * Example: err = v4l2_subdev_call(sd, video, s_std, norm);
>   */
> @@ -1048,6 +1100,14 @@ void v4l2_subdev_init(struct v4l2_subdev *sd,
>   __result;   \
>   })
>  
> +/**
> + * v4l2_subdev_has_op - Checks if a subdev defines a certain ops.

s/ops/operation/ (or 

Re: [PATCH 17/24] media: v4l2-subdev: fix a typo

[Sakari Ailus]

On Mon, Oct 09, 2017 at 07:19:23AM -0300, Mauro Carvalho Chehab wrote:
> ownner -> owner
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/v4l2-subdev.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index e215732eed45..345da052618c 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -814,7 +814,7 @@ struct v4l2_subdev_platform_data {
>   * @list: List of sub-devices
>   * @owner: The owner is the same as the driver's  device owner.
>   * @owner_v4l2_dev: true if the >owner matches the owner of 
> @v4l2_dev->dev
> - *   ownner. Initialized by v4l2_device_register_subdev().
> + *   owner. Initialized by v4l2_device_register_subdev().
>   * @flags: subdev flags, as defined by  v4l2_subdev_flags.
>   *
>   * @v4l2_dev: pointer to struct _device

Acked-by: Sakari Ailus 

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

Re: [PATCH 10/24] media: v4l2-subdev: use kernel-doc markups to document subdev flags

[Sakari Ailus]

Hi Mauro,

On Mon, Oct 09, 2017 at 07:19:16AM -0300, Mauro Carvalho Chehab wrote:
> Right now, those are documented together with the subdev struct,
> instead of together with the definitions.
> 
> Convert the definitions to an enum, use BIT() macros and document
> it at its right place.
> 
> Signed-off-by: Mauro Carvalho Chehab 

For patches 10--14:

Acked-by: Sakari Ailus 

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

Re: [PATCH 15/24] media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro

[Sakari Ailus]

Hi Mauro,

On Mon, Oct 09, 2017 at 07:19:21AM -0300, Mauro Carvalho Chehab wrote:
> The __V4L2_SUBDEV_MK_GET_TRY() macro is used to define
> 3 functions that have the same arguments. The code of those
> functions is simple enough to just declare them, de-obfuscating
> the code.
> 
> While here, replace BUG_ON() by WARN_ON() as there's no reason
> why to panic the Kernel if this fails.

BUG_ON() might actually be a better idea as this will lead to memory
corruption. I presume it's not been hit often.

That said, I, too, favour WARN_ON() in this case. In case pad exceeds the
number of pads, then zero could be used, for instance. The only real
problem comes if there were no pads to begin with. The callers of these
functions also don't expect to receive NULL. Another option would be to
define a static, dummy variable for the purpose that would be at least safe
to access. Or we could just use the dummy entry whenever the pad isn't
valid.

This will make the functions more complex and I might just keep the
original macro. Even grep works on it nowadays.

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/v4l2-subdev.h | 37 +
>  1 file changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 1f34045f07ce..35c4476c56ee 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -897,19 +897,32 @@ struct v4l2_subdev_fh {
>   container_of(fh, struct v4l2_subdev_fh, vfh)
>  
>  #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
> -#define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)
> \
> - static inline struct rtype *\
> - fun_name(struct v4l2_subdev *sd,\
> -  struct v4l2_subdev_pad_config *cfg,\
> -  unsigned int pad)  \
> - {   \
> - BUG_ON(pad >= sd->entity.num_pads); \
> - return [pad].field_name;\
> - }
> +static inline struct v4l2_mbus_framefmt
> +*v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + unsigned int pad)
> +{
> + WARN_ON(pad >= sd->entity.num_pads);
> + return [pad].try_fmt;
> +}
>  
> -__V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, v4l2_subdev_get_try_format, 
> try_fmt)
> -__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_crop, try_crop)
> -__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_compose, try_compose)
> +static inline struct v4l2_rect
> +*v4l2_subdev_get_try_crop(struct v4l2_subdev *sd,
> +   struct v4l2_subdev_pad_config *cfg,
> +   unsigned int pad)
> +{
> + WARN_ON(pad >= sd->entity.num_pads);
> + return [pad].try_crop;
> +}
> +
> +static inline struct v4l2_rect
> +*v4l2_subdev_get_try_compose(struct v4l2_subdev *sd,
> +  struct v4l2_subdev_pad_config *cfg,
> +  unsigned int pad)
> +{
> + WARN_ON(pad >= sd->entity.num_pads);
> + return [pad].try_compose;
> +}
>  #endif
>  
>  extern const struct v4l2_file_operations v4l2_subdev_fops;

-- 
Kind regards,

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

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Laurent Pinchart]

Hi Sylwester,

On Monday, 9 October 2017 19:44:52 EEST Sylwester Nawrocki wrote:
> On 10/09/2017 04:18 PM, Sakari Ailus wrote:
> > Sure, how about this at the end of the current commit message:
> > 
> > If there is a need to support removing the clock provider in the future,
> > this should be implemented in the clock framework instead, not in V4L2.
> 
> I find it a little bit misleading, there is already support for removing
> the clock provider, only any clock references for consumers became then
> stale.  Perhaps:
> 
> "If there is a need to support the clock provider unregister/register
> cycle while keeping the clock references in the consumers in the future,
> this should be implemented in the clock framework instead, not in V4L2."
> 
> ? That said, I doubt this issue is going to be entirely solved solely
> in the clock framework, as it is a more general problem of resource
> dependencies.  It could be related to other resources, like regulator
> or GPIO.  It has been discussed for a long time now and it will likely
> take time until a general solution is available.

I discussed this issue with Mike Turquette during LPC, and he believed we 
could fix it in the clock framework by adding support for "un-orphaning" a 
clock. This remains to be proven by a real implementation, but could work for 
our use case.

I agree with you that similar problems exist for other resources such as 
regulators and GPIOs, but to my knowledge we have no system that requires V4L2 
reprobing due to regulator or GPIO dependencies.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] [media] ov5645: I2C address change

[Laurent Pinchart]

Hi Todor,

On Monday, 9 October 2017 19:18:17 EEST Todor Tomov wrote:
> On  9.10.2017 15:52, Laurent Pinchart wrote:
> > On Monday, 9 October 2017 12:34:26 EEST Sakari Ailus wrote:
> >> On Mon, Oct 09, 2017 at 11:36:01AM +0300, Todor Tomov wrote:
> >>> On  4.10.2017 13:47, Laurent Pinchart wrote:
>  CC'ing the I2C mainling list and the I2C maintainer.
>  
>  On Wednesday, 4 October 2017 13:30:08 EEST Sakari Ailus wrote:
> > On Mon, Oct 02, 2017 at 04:28:45PM +0300, Todor Tomov wrote:
> >> As soon as the sensor is powered on, change the I2C address to the
> >> one specified in DT. This allows to use multiple physical sensors
> >> connected to the same I2C bus.
> >> 
> >> Signed-off-by: Todor Tomov 
> > 
> > The smiapp driver does something similar and I understand Laurent
> > might be interested in such functionality as well.
> > 
> > It'd be nice to handle this through the I²C framework instead and to
> > define how the information is specified through DT. That way it could
> > be made generic, to work with more devices than just this one.
> > 
> > What do you think?
> >>> 
> >>> Thank you for this suggestion.
> >>> 
> >>> The way I have done it is to put the new I2C address in the DT and the
> >>> driver programs the change using the original I2C address. The original
> >>> I2C address is hardcoded in the driver. So maybe we can extend the DT
> >>> binding and the I2C framework so that both addresses come from the DT
> >>> and avoid hiding the original I2C address in the driver. This sounds
> >>> good to me.
> >> 
> >> Agreed.
> >> 
> >> In this case the address is known but in general that's not the case it's
> >> not that simple. There are register compatible devices that have
> >> different addresses even if they're the same devices.
> >> 
> >> It might be a good idea to make this explicit.
> > 
> > Yes, in the general case we need to specify the original address in DT, as
> > the chip could have a non-fixed boot-up I2C address.
> > 
> > In many cases the value of the new I2C address doesn't matter much, as
> > long as it's unique on the bus. I was thinking about implementing a
> > dynamic allocator for I2C addresses, but after discussing it with Wolfram
> > we concluded that it would probably not be a good idea. There could be
> > other I2C devices on the bus that Linux isn't aware of, in which case the
> > dynamic allocator could create address conflicts. Specifying the new
> > address in DT is likely a better idea, even if it could feel a bit more
> > of system configuration information than a pure hardware description.
> > 
> >>> Then changing the address could be device specific and also this must be
> >>> done right after power on so that there are no address conflicts. So I
> >>> don't think that we can support this through the I2C framework only, the
> >>> drivers that we want to do that will have to be expanded with this
> >>> functionality. Or do you have any other idea?
> >> 
> >> Yes, how the address is changed is always hardware specific. This would
> >> be most conveniently done in driver's probe or PM runtime_resume
> >> functions.
> > 
> > This patch modifies client->addr directly, which I don't think is a good
> > idea. I'd prefer making the I2C core aware of the address change through
> > an explicit API call. This would allow catching I2C adress conflicts for
> > instance.
> > 
> >> It could be as simple as providing an adapter specific mutex to serialise
> >> address changes on the bus so that no two address changes are taking
> >> place at the same time. Which is essentially the impliementation you had,
> >> only the mutex would be for the I²C adapter, not the driver. An helper
> >> functions for acquiring and releasing the mutex.
> > 
> > Why do you need to serialize address changes ?
> 
> Correct me if I'm wrong, but if you power on more than one device with the
> same I2C address and issue a command to change it, then all devices will
> recognize this command as addressed to them. The only solution (which I know
> about) to avoid this is to serialize the power on and address change (as a
> whole!) for these devices.

Yes, that's correct. It can be even worse than that, sometimes only one of the 
two devices with the same address can be reconfigured, which means that 
powering that device requires powering up the other device and changing its 
address first, otherwise the second device can't be used as long as the first 
one is power on (this happened for real in a Nokia platform).

> I think it would be better to move the mutex out of the driver - to avoid
> all client drivers which will change I2C address to add a global variable
> mutex for this. We just have to find a better place for it :)

The biggest issue I see is that there's no C code that has knowledge of the 
whole platform. It's hard to describe this in DT in a generic way, board files 
were clearly useful for this kind 

Re: [PATCH v2 21/25] media: lirc: introduce LIRC_SET_POLL_MODE

[Sean Young]

On Mon, Oct 09, 2017 at 12:50:19PM +0200, Hans Verkuil wrote:
> On 05/10/17 10:45, Sean Young wrote:
> > If you want to poll for both decoded scancodes and raw IR, then this
> > ioctl will help you.
> 
> I don't get the point of this. You can be in one mode at a time anyway,
> so why not just poll for the current mode?

Well, you might want to poll for the current mode and another mode. Actually,
I think the ioctl should be called LIRC_SET_POLL_MODES to clarify that.

So say if I want to poll for raw IR (LIRC_MODE_MODE2) and decoded scancodes
(LIRC_MODE_SCANCODES), then without this ioctl, I would have to poll one
for a period, then switch modes, poll for the other, switch modes, ad
infinitum.

> 
> > 
> > int fd = open("/dev/lirc0", O_RDONLY | O_NONBLOCK);
> > 
> > for (;;) {
> > unsigned mode = LIRC_MODE_SCANCODE | LIRC_MODE_MODE2;
> > ioctl(fd, LIRC_SET_POLL_MODE, );
> > poll(&((struct pollfd){ .fd = fd, .events = POLLIN }), 1, -1);
> > mode = LIRC_MODE_SCANCODE;
> > ioctl(fd, LIRC_SET_REC_MODE, );
> 
> Hold on, in a comment below I read that rec_mode stands for 'recording mode'.
> Is that right, or should it be 'receive mode'?

You're right, I've confused myself! Lirc calls it record and sometimes
receive.

> > struct lirc_scancode sc;
> > if (read(fd, , sizeof(sc)) == sizeof(sc)) {
> > printf("scancode protocol:%d scancode:%llx\n",
> > sc.rc_proto, sc.scancode);
> > }
> > mode = LIRC_MODE_MODE2;
> > ioctl(fd, LIRC_SET_REC_MODE, );
> > unsigned sample;
> > if (read(fd, , sizeof(sample)) == sizeof(sample)) {
> > if (LIRC_IS_SPACE(sample))
> > printf("space %u\n", LIRC_VAL(sample)));
> > if (LIRC_IS_PULSE(sample))
> > printf("pulse %u\n", LIRC_VAL(sample)));
> > }
> > }
> > 
> > Note that LIRC_SET_REC_MODE will also affect the poll mode, so you
> > must set it again before calling poll.
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  Documentation/media/uapi/rc/lirc-func.rst  |  1 +
> >  Documentation/media/uapi/rc/lirc-set-poll-mode.rst | 45 
> > ++
> >  drivers/media/rc/ir-lirc-codec.c   | 19 +++--
> >  drivers/media/rc/lirc_dev.c|  1 +
> >  include/media/rc-core.h|  3 ++
> >  5 files changed, 65 insertions(+), 4 deletions(-)
> >  create mode 100644 Documentation/media/uapi/rc/lirc-set-poll-mode.rst
> > 
> > diff --git a/Documentation/media/uapi/rc/lirc-func.rst 
> > b/Documentation/media/uapi/rc/lirc-func.rst
> > index ddb4620de294..a09fb03f6722 100644
> > --- a/Documentation/media/uapi/rc/lirc-func.rst
> > +++ b/Documentation/media/uapi/rc/lirc-func.rst
> > @@ -25,3 +25,4 @@ LIRC Function Reference
> >  lirc-set-rec-timeout-reports
> >  lirc-set-measure-carrier-mode
> >  lirc-set-wideband-receiver
> > +lirc-set-poll-mode
> > diff --git a/Documentation/media/uapi/rc/lirc-set-poll-mode.rst 
> > b/Documentation/media/uapi/rc/lirc-set-poll-mode.rst
> > new file mode 100644
> > index ..ce5043e8acba
> > --- /dev/null
> > +++ b/Documentation/media/uapi/rc/lirc-set-poll-mode.rst
> > @@ -0,0 +1,45 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _lirc_set_poll_mode:
> > +
> > +**
> > +ioctls LIRC_SET_POLL_MODE
> > +**
> > +
> > +Name
> > +
> > +
> > +LIRC_SET_POLL_MODE - Set LIRC modes to use for poll
> > +
> > +Synopsis
> > +
> > +
> > +.. c:function:: int ioctl( int fd, LIRC_SET_POLL_MODE, __u32 modes)
> > +   :name: LIRC_SET_POLL_MODE
> > +
> > +Arguments
> > +=
> > +
> > +``fd``
> > +File descriptor returned by open().
> > +
> > +``modes``
> > +Bitmask with enabled poll lirc modes
> > +
> > +Description
> > +===
> > +
> > +Set lirc modes for which read readiness is reported by poll. Only
> > +:ref:`LIRC_MODE_MODE2 ` and
> > +:ref:`LIRC_MODE_SCANCODE ` are supported. Poll
> > +can report read readiness for both modes if you bitwise or them together.
> > +Use :ref:`lirc_get_features` to find out which modes the driver supports.
> > +
> > +Note that using :ref:`lirc_set_rec_mode` resets the poll mode.
> > +
> > +Return Value
> > +
> > +
> > +On success 0 is returned, on error -1 and the ``errno`` variable is set
> > +appropriately. The generic error codes are described at the
> > +:ref:`Generic Error Codes ` chapter.
> > diff --git a/drivers/media/rc/ir-lirc-codec.c 
> > b/drivers/media/rc/ir-lirc-codec.c
> > index 2544ddc078ca..1f1811c080af 100644
> > --- a/drivers/media/rc/ir-lirc-codec.c
> > +++ b/drivers/media/rc/ir-lirc-codec.c
> > @@ -353,6 +353,17 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
> > int cmd,
> > return -EINVAL;
> >  
> > dev->rec_mode = val;
> > +   dev->poll_mode = val;
> > +   return 0;
> > +
> > 

Re: usb/media/imon: null-ptr-deref in imon_probe

[arvindY]

Hi Andrey,

I have added NULL check for usb_ifnum_to_if() and send a patch.
Please re-test it.

~arvind

On Monday 09 October 2017 11:20 PM, Andrey Konovalov wrote:

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1497 Comm: kworker/1:1 Not tainted
4.14.0-rc4-43418-g43a3f84d2109-dirty #380
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006a5618c0 task.stack: 880068bc8000
RIP: 0010:imon_probe+0x231/0x3f10 drivers/media/rc/imon.c:2519
RSP: 0018:880068bce2d8 EFLAGS: 00010206
RAX:  RBX: 8800627dd500 RCX: 0027
RDX: dc00 RSI:  RDI: 0138
RBP: 880068bce5e8 R08: 88006a5618c0 R09: 84b380fc
R10: 880068bce2c8 R11: 11000d4ac5b3 R12: 88006183
R13: 880061830008 R14: 883fa200 R15: 883fa080
FS:  () GS:88006c50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 206cbffc CR3: 61085000 CR4: 06e0
Call Trace:
  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
  really_probe drivers/base/dd.c:413
  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
  device_add+0xd0b/0x1660 drivers/base/core.c:1835
  usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
  really_probe drivers/base/dd.c:413
  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
  device_add+0xd0b/0x1660 drivers/base/core.c:1835
  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
  hub_port_connect drivers/usb/core/hub.c:4903
  hub_port_connect_change drivers/usb/core/hub.c:5009
  port_event drivers/usb/core/hub.c:5115
  hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
  process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
  kthread+0x3a1/0x470 kernel/kthread.c:231
  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: ff e8 a4 81 cb 01 31 f6 48 89 df e8 2a cc 65 ff 0f ae f0 48 8d
b8 38 01 00 00 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <80>
3c 11 00 0f 85 e8 31 00 00 48 8b 98 38 01 00 00 0f ae f0 44
RIP: imon_probe+0x231/0x3f10 RSP: 880068bce2d8
---[ end trace 07febd2eebe02f84 ]---

[PATCH] media: imon: Fix null-ptr-deref in imon_probe

[Arvind Yadav]

It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.

Signed-off-by: Arvind Yadav 
---
This bug report by Andrey Konovalov usb/media/imon: null-ptr-deref
in imon_probe

 drivers/media/rc/imon.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 7b3f31c..0c46155 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2517,6 +2517,11 @@ static int imon_probe(struct usb_interface *interface,
mutex_lock(_lock);
 
first_if = usb_ifnum_to_if(usbdev, 0);
+   if (!first_if) {
+   ret = -ENODEV;
+   goto fail;
+   }
+
first_if_ctx = usb_get_intfdata(first_if);
 
if (ifnum == 0) {
-- 
2.7.4

usb/media/imon: null-ptr-deref in imon_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1497 Comm: kworker/1:1 Not tainted
4.14.0-rc4-43418-g43a3f84d2109-dirty #380
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006a5618c0 task.stack: 880068bc8000
RIP: 0010:imon_probe+0x231/0x3f10 drivers/media/rc/imon.c:2519
RSP: 0018:880068bce2d8 EFLAGS: 00010206
RAX:  RBX: 8800627dd500 RCX: 0027
RDX: dc00 RSI:  RDI: 0138
RBP: 880068bce5e8 R08: 88006a5618c0 R09: 84b380fc
R10: 880068bce2c8 R11: 11000d4ac5b3 R12: 88006183
R13: 880061830008 R14: 883fa200 R15: 883fa080
FS:  () GS:88006c50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 206cbffc CR3: 61085000 CR4: 06e0
Call Trace:
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: ff e8 a4 81 cb 01 31 f6 48 89 df e8 2a cc 65 ff 0f ae f0 48 8d
b8 38 01 00 00 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <80>
3c 11 00 0f 85 e8 31 00 00 48 8b 98 38 01 00 00 0f ae f0 44
RIP: imon_probe+0x231/0x3f10 RSP: 880068bce2d8
---[ end trace 07febd2eebe02f84 ]---

usb/media/imon: global-out-of-bounds in imon_probe/imon_init_intf0

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

It seems that imon_ir_raw doesn't have the .key_table initializer,
which causes out-of-bounds access when iterating over the key table.

==
BUG: KASAN: global-out-of-bounds in imon_probe+0x3ade/0x3f00
Read of size 8 at addr 871c5468 by task kworker/1:1/1494

CPU: 1 PID: 1494 Comm: kworker/1:1 Not tainted
4.14.0-rc4-43418-g43a3f84d2109-dirty #391
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x1d9/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 imon_init_intf0 drivers/media/rc/imon.c:2142
 imon_probe+0x3ade/0x3f00 drivers/media/rc/imon.c:2523
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

The buggy address belongs to the variable:
 imon_ir_raw+0x8/0x40

Memory state around the buggy address:
 871c5300: fa fa fa fa 00 03 fa fa fa fa fa fa 00 fa fa fa
 871c5380: fa fa fa fa 06 fa fa fa fa fa fa fa 00 00 06 fa
>871c5400: fa fa fa fa 00 04 fa fa fa fa fa fa 00 fa fa fa
  ^
 871c5480: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
 871c5500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==

Re: [PATCH v2 20/25] media: lirc: document LIRC_MODE_SCANCODE

[Sean Young]

On Mon, Oct 09, 2017 at 12:27:16PM +0200, Hans Verkuil wrote:
> On 05/10/17 10:45, Sean Young wrote:
> > Lirc supports a new mode which requires documentation.
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  Documentation/media/lirc.h.rst.exceptions  | 26 
> > ++
> >  Documentation/media/uapi/rc/lirc-dev-intro.rst | 26 
> > ++
> >  Documentation/media/uapi/rc/lirc-get-features.rst  | 16 +
> >  Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |  5 +++--
> >  Documentation/media/uapi/rc/lirc-get-send-mode.rst |  3 ++-
> >  Documentation/media/uapi/rc/lirc-read.rst  | 14 
> >  Documentation/media/uapi/rc/lirc-write.rst | 16 ++---
> >  7 files changed, 96 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/media/lirc.h.rst.exceptions 
> > b/Documentation/media/lirc.h.rst.exceptions
> > index 63ba1d341905..c6e3a35d2c4e 100644
> > --- a/Documentation/media/lirc.h.rst.exceptions
> > +++ b/Documentation/media/lirc.h.rst.exceptions
> > @@ -32,6 +32,32 @@ ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
> >  
> >  ignore ioctl LIRC_GET_LENGTH
> >  
> > +# rc protocols
> > +
> > +ignore symbol RC_PROTO_UNKNOWN
> > +ignore symbol RC_PROTO_OTHER
> > +ignore symbol RC_PROTO_RC5
> > +ignore symbol RC_PROTO_RC5X_20
> > +ignore symbol RC_PROTO_RC5_SZ
> > +ignore symbol RC_PROTO_JVC
> > +ignore symbol RC_PROTO_SONY12
> > +ignore symbol RC_PROTO_SONY15
> > +ignore symbol RC_PROTO_SONY20
> > +ignore symbol RC_PROTO_NEC
> > +ignore symbol RC_PROTO_NECX
> > +ignore symbol RC_PROTO_NEC32
> > +ignore symbol RC_PROTO_SANYO
> > +ignore symbol RC_PROTO_MCIR2_KBD
> > +ignore symbol RC_PROTO_MCIR2_MSE
> > +ignore symbol RC_PROTO_RC6_0
> > +ignore symbol RC_PROTO_RC6_6A_20
> > +ignore symbol RC_PROTO_RC6_6A_24
> > +ignore symbol RC_PROTO_RC6_6A_32
> > +ignore symbol RC_PROTO_RC6_MCE
> > +ignore symbol RC_PROTO_SHARP
> > +ignore symbol RC_PROTO_XMP
> > +ignore symbol RC_PROTO_CEC
> > +
> >  # Undocumented macros
> >  
> >  ignore define PULSE_BIT
> > diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
> > b/Documentation/media/uapi/rc/lirc-dev-intro.rst
> > index a3fa3c1ef169..70c82b2879ff 100644
> > --- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
> > +++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
> > @@ -36,6 +36,32 @@ LIRC modes
> >  LIRC supports some modes of receiving and sending IR codes, as shown
> >  on the following table.
> 
> A general note: I don't think it is defined anywhere in the documentation what
> 'LIRC' stands for. Might be useful to add :-)

Good point, will do.
> 
> >  
> > +.. _lirc-mode-scancode:
> > +.. _lirc-scancode-flag-toggle:
> > +.. _lirc-scancode-flag-repeat:
> > +
> > +``LIRC_MODE_SCANCODE``
> > +
> > +This mode is for both sending and receiving IR.
> > +
> > +For transmitting (aka sending), create a ``struct lirc_scancode`` with
> > +the desired scancode set in the ``scancode`` member, ``rc_proto`` set
> > +the IR protocol, and all other members set to 0. Write this struct to
> > +the lirc device.
> > +
> > +For receiving, you read ``struct lirc_scancode`` from the lirc device,
> > +with ``scancode`` set to the received scancode in the IR protocol
> > +``rc_proto``. The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set
> > +if the toggle bit is set in protocols that support it (e.g. rc-5 and 
> > rc-6),
> 
> Is the meaning of 'toggle' defined anywhere? I'm not sure what it means 
> myself.

The nec protocol just sends the scancode, no key up/key down event. So it not
possible to tell whether the user is pressing a button or press-release-press
button. The rc-5 and rc-6 protocols therefore include a toggle-bit, which
flips if the user press-release-press the button. Note that keyup event is
simply absence of any IR.

Anyway, good point, I'll add it.

> 
> > +or ``LIRC_SCANCODE_FLAG_REPEAT`` for when a repeat is received for 
> > protocols
> > +that support it (e.g. nec).
> > +
> > +The ``timestamp`` field is filled with the time nanoseconds
> > +(in ``CLOCK_MONOTONIC``) when the scancode was decoded.
> > +
> > +An ``enum rc_proto`` in the :ref:`lirc_header` lists all the supported
> > +IR protocols.
> > +
> >  .. _lirc-mode-mode2:
> >  
> >  ``LIRC_MODE_MODE2``
> > diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
> > b/Documentation/media/uapi/rc/lirc-get-features.rst
> > index 50c2c26d8e89..3ee44067de63 100644
> > --- a/Documentation/media/uapi/rc/lirc-get-features.rst
> > +++ b/Documentation/media/uapi/rc/lirc-get-features.rst
> > @@ -64,6 +64,14 @@ LIRC features
> >  
> >  Unused. Kept just to avoid breaking uAPI.
> >  
> > +.. _LIRC-CAN-REC-SCANCODE:
> > +
> > +``LIRC_CAN_REC_SCANCODE``
> 
> Wouldn't LIRC_CAN_RECEIVE_SCANCODE be better?
> 
> I misread 'REC' as 'record' :-)

Unfortunately some lirc parts itself refers to record as well.

> I thought about using RCV as the 

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Sylwester Nawrocki]

Hi Sakari,

On 10/09/2017 04:18 PM, Sakari Ailus wrote:
> Sure, how about this at the end of the current commit message:
> 
> If there is a need to support removing the clock provider in the future,
> this should be implemented in the clock framework instead, not in V4L2.

I find it a little bit misleading, there is already support for removing
the clock provider, only any clock references for consumers became then
stale.  Perhaps:

"If there is a need to support the clock provider unregister/register 
cycle while keeping the clock references in the consumers in the future, 
this should be implemented in the clock framework instead, not in V4L2."

? That said, I doubt this issue is going to be entirely solved solely 
in the clock framework, as it is a more general problem of resource 
dependencies.  It could be related to other resources, like regulator
or GPIO.  It has been discussed for a long time now and it will likely 
take time until a general solution is available.

--
Thanks, 
Sylwester

Re: [PATCH v2 10/25] media: lirc: validate scancode for transmit

[Sean Young]

On Mon, Oct 09, 2017 at 11:20:52AM +0200, Hans Verkuil wrote:
> On 05/10/17 10:45, Sean Young wrote:
> > Ensure we reject an attempt to transmit invalid scancodes.
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  drivers/media/rc/ir-lirc-codec.c |  3 +++
> >  drivers/media/rc/rc-core-priv.h  |  1 +
> >  drivers/media/rc/rc-main.c   | 53 
> > +---
> >  3 files changed, 37 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/media/rc/ir-lirc-codec.c 
> > b/drivers/media/rc/ir-lirc-codec.c
> > index 94561d8b0c0b..863d975d40fb 100644
> > --- a/drivers/media/rc/ir-lirc-codec.c
> > +++ b/drivers/media/rc/ir-lirc-codec.c
> > @@ -122,6 +122,9 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> > const char __user *buf,
> > scan.timestamp)
> > return -EINVAL;
> >  
> > +   if (!rc_validate_scancode(scan.rc_proto, scan.scancode))
> > +   return -EINVAL;
> > +
> > if (dev->tx_scancode) {
> > ret = dev->tx_scancode(dev, );
> > return ret < 0 ? ret : n;
> > diff --git a/drivers/media/rc/rc-core-priv.h 
> > b/drivers/media/rc/rc-core-priv.h
> > index 21e515d34f64..a064c401fa38 100644
> > --- a/drivers/media/rc/rc-core-priv.h
> > +++ b/drivers/media/rc/rc-core-priv.h
> > @@ -160,6 +160,7 @@ static inline bool is_timing_event(struct ir_raw_event 
> > ev)
> >  #define TO_STR(is_pulse)   ((is_pulse) ? "pulse" : "space")
> >  
> >  /* functions for IR encoders */
> > +bool rc_validate_scancode(enum rc_proto proto, u32 scancode);
> >  
> >  static inline void init_ir_raw_event_duration(struct ir_raw_event *ev,
> >   unsigned int pulse,
> > diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> > index 758c14b90a87..38393f13822f 100644
> > --- a/drivers/media/rc/rc-main.c
> > +++ b/drivers/media/rc/rc-main.c
> > @@ -776,6 +776,37 @@ void rc_keydown_notimeout(struct rc_dev *dev, enum 
> > rc_proto protocol,
> >  EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
> >  
> >  /**
> > + * rc_validate_scancode() - checks that a scancode is valid for a protocol
> > + * @proto: protocol
> > + * @scancode:  scancode
> > + */
> > +bool rc_validate_scancode(enum rc_proto proto, u32 scancode)
> 
> The scancode in struct lirc_scancode is a u64. Shouldn't this be a u64 as 
> well?

The scancode in struct lirc_scancode is 64 bit to make it future-proof
(there are IR protocols with > 32 bits). However none are currently
supported.

So, that needs documenting.

> > +{
> > +   switch (proto) {
> > +   case RC_PROTO_NECX:
> > +   if scancode >> 16) ^ ~(scancode >> 8)) & 0xff) == 0)
> > +   return false;
> > +   break;
> > +   case RC_PROTO_NEC32:
> > +   if scancode >> 24) ^ ~(scancode >> 16)) & 0xff) == 0)
> > +   return false;
> > +   break;
> > +   case RC_PROTO_RC6_MCE:
> > +   if ((scancode & 0x) != 0x800f)
> > +   return false;
> > +   break;
> > +   case RC_PROTO_RC6_6A_32:
> > +   if ((scancode & 0x) == 0x800f)
> > +   return false;
> 
> I think that some comments explaining what is tested here would be useful.
> 
> This can be done in a separate patch, or done here.

Yes, you are right. 
> 
> Regards,
> 
>   Hans
> 
> > +   break;
> > +   default:
> > +   break;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> > +/**
> >   * rc_validate_filter() - checks that the scancode and mask are valid and
> >   *   provides sensible defaults
> >   * @dev:   the struct rc_dev descriptor of the device
> > @@ -793,26 +824,8 @@ static int rc_validate_filter(struct rc_dev *dev,
> >  
> > mask = protocols[protocol].scancode_bits;
> >  
> > -   switch (protocol) {
> > -   case RC_PROTO_NECX:
> > -   if s >> 16) ^ ~(s >> 8)) & 0xff) == 0)
> > -   return -EINVAL;
> > -   break;
> > -   case RC_PROTO_NEC32:
> > -   if s >> 24) ^ ~(s >> 16)) & 0xff) == 0)
> > -   return -EINVAL;
> > -   break;
> > -   case RC_PROTO_RC6_MCE:
> > -   if ((s & 0x) != 0x800f)
> > -   return -EINVAL;
> > -   break;
> > -   case RC_PROTO_RC6_6A_32:
> > -   if ((s & 0x) == 0x800f)
> > -   return -EINVAL;
> > -   break;
> > -   default:
> > -   break;
> > -   }
> > +   if (!rc_validate_scancode(protocol, s))
> > +   return -EINVAL;
> >  
> > filter->data &= mask;
> > filter->mask &= mask;
> > 

Re: [PATCH] [media] ov5645: I2C address change

[Todor Tomov]

Hi Laurent :)

On  9.10.2017 15:52, Laurent Pinchart wrote:
> Hello,
> 
> On Monday, 9 October 2017 12:34:26 EEST Sakari Ailus wrote:
>> On Mon, Oct 09, 2017 at 11:36:01AM +0300, Todor Tomov wrote:
>>> On  4.10.2017 13:47, Laurent Pinchart wrote:
 CC'ing the I2C mainling list and the I2C maintainer.

 On Wednesday, 4 October 2017 13:30:08 EEST Sakari Ailus wrote:
> On Mon, Oct 02, 2017 at 04:28:45PM +0300, Todor Tomov wrote:
>> As soon as the sensor is powered on, change the I2C address to the one
>> specified in DT. This allows to use multiple physical sensors
>> connected to the same I2C bus.
>>
>> Signed-off-by: Todor Tomov 
>
> The smiapp driver does something similar and I understand Laurent might
> be interested in such functionality as well.
>
> It'd be nice to handle this through the I²C framework instead and to
> define how the information is specified through DT. That way it could
> be made generic, to work with more devices than just this one.
>
> What do you think?
>>>
>>> Thank you for this suggestion.
>>>
>>> The way I have done it is to put the new I2C address in the DT and the
>>> driver programs the change using the original I2C address. The original
>>> I2C address is hardcoded in the driver. So maybe we can extend the DT
>>> binding and the I2C framework so that both addresses come from the DT and
>>> avoid hiding the original I2C address in the driver. This sounds good to
>>> me.
>>
>> Agreed.
>>
>> In this case the address is known but in general that's not the case it's
>> not that simple. There are register compatible devices that have different
>> addresses even if they're the same devices.
>>
>> It might be a good idea to make this explicit.
> 
> Yes, in the general case we need to specify the original address in DT, as 
> the 
> chip could have a non-fixed boot-up I2C address.
> 
> In many cases the value of the new I2C address doesn't matter much, as long 
> as 
> it's unique on the bus. I was thinking about implementing a dynamic allocator 
> for I2C addresses, but after discussing it with Wolfram we concluded that it 
> would probably not be a good idea. There could be other I2C devices on the 
> bus 
> that Linux isn't aware of, in which case the dynamic allocator could create 
> address conflicts. Specifying the new address in DT is likely a better idea, 
> even if it could feel a bit more of system configuration information than a 
> pure hardware description.
> 
>>> Then changing the address could be device specific and also this must be
>>> done right after power on so that there are no address conflicts. So I
>>> don't think that we can support this through the I2C framework only, the
>>> drivers that we want to do that will have to be expanded with this
>>> functionality. Or do you have any other idea?
>>
>> Yes, how the address is changed is always hardware specific. This would be
>> most conveniently done in driver's probe or PM runtime_resume functions.
> 
> This patch modifies client->addr directly, which I don't think is a good 
> idea. 
> I'd prefer making the I2C core aware of the address change through an 
> explicit 
> API call. This would allow catching I2C adress conflicts for instance.
> 
>> It could be as simple as providing an adapter specific mutex to serialise
>> address changes on the bus so that no two address changes are taking place
>> at the same time. Which is essentially the impliementation you had, only
>> the mutex would be for the I²C adapter, not the driver. An helper functions
>> for acquiring and releasing the mutex.
> 
> Why do you need to serialize address changes ?

Correct me if I'm wrong, but if you power on more than one device with the
same I2C address and issue a command to change it, then all devices will
recognize this command as addressed to them. The only solution (which I know
about) to avoid this is to serialize the power on and address change (as a 
whole!)
for these devices.

I think it would be better to move the mutex out of the driver - to avoid all
client drivers which will change I2C address to add a global variable mutex 
for this. We just have to find a better place for it :)

> 
>> I wonder what others think.
> 

-- 
Best regards,
Todor Tomov

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Mauro Carvalho Chehab]

Em Mon, 9 Oct 2017 16:20:08 +0200
Hans Verkuil  escreveu:

> On 09/10/17 16:18, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > On Mon, Oct 09, 2017 at 04:08:47PM +0200, Hans Verkuil wrote:  
> >> On 09/10/17 16:06, Sakari Ailus wrote:  
> >>> Hi Mauro,
> >>>
> >>> On Mon, Oct 09, 2017 at 08:22:39AM -0300, Mauro Carvalho Chehab wrote:  
>  Em Thu,  5 Oct 2017 00:50:20 +0300
>  Sakari Ailus  escreveu:
>   
> > Remove V4L2 async re-probing support. The re-probing support has been
> > there to support cases where the sub-devices require resources provided 
> > by
> > the main driver's hardware to function, such as clocks.
> >
> > Reprobing has allowed unbinding and again binding the main driver 
> > without
> > explicilty unbinding the sub-device drivers. This is certainly not a
> > common need, and the responsibility will be the user's going forward.
> >
> > An alternative could have been to introduce notifier specific locks.
> > Considering the complexity of the re-probing and that it isn't really a
> > solution to a problem but a workaround, remove re-probing instead.  
> 
>  If the re-probing isn't using anywhere, that sounds a nice cleanup.
>  Did you check if this won't break any driver (like soc_camera)?  
> >>>
> >>> That was discussed earlier in the review; Laurent asked the same question.
> >>>
> >>> Re-probing never was a proper solution to any problem; it was just a hack
> >>> to avoid unbinding the sensor if the bridge driver was unbound, no more: 
> >>> it
> >>> can't be generalised to support more complex use cases. Mind you, this is
> >>> on devices that aren't actually removable.
> >>>
> >>> I've briefly discussed this with Laurent; the proper solution would need 
> >>> to
> >>> be implemented in the clock framework instead. There, the existing clocks
> >>> obtained by drivers could be re-activated when the driver for them comes
> >>> back.
> >>>
> >>> My proposal is that if there's real a need to address this, then it could
> >>> be solved in the clock framework.  
> >>
> >> Can you add this information to the commit log?
> >>
> >> I think that would be very helpful in the future.  
> > 
> > Sure, how about this at the end of the current commit message:
> > 
> > If there is a need to support removing the clock provider in the future,
> > this should be implemented in the clock framework instead, not in V4L2.  
> 
> Yes, that sounds good.

Works for me too.

Regards,
Mauro

Re: [PATCH v2 01/25] media: lirc: implement scancode sending

[Hans Verkuil]

On 09/10/17 17:11, Sean Young wrote:
> On Mon, Oct 09, 2017 at 11:14:28AM +0200, Hans Verkuil wrote:
>> On 05/10/17 10:45, Sean Young wrote:
> -snip-
>>> +/*
>>> + * struct lirc_scancode - decoded scancode with protocol for use with
>>> + * LIRC_MODE_SCANCODE
>>> + *
>>> + * @timestamp: Timestamp in nanoseconds using CLOCK_MONOTONIC when IR
>>> + * was decoded.
>>> + * @flags: should be 0 for transmit. When receiving scancodes,
>>> + * LIRC_SCANCODE_FLAG_TOGGLE or LIRC_SCANCODE_FLAG_REPEAT can be set
>>> + * depending on the protocol
>>> + * @target: target for transmit. Unused, set to 0.
>>> + * @source: source for receive. Unused, set to 0.
>>> + * @unused: set to 0.
>>> + * @rc_proto: see enum rc_proto
>>> + * @scancode: the scancode received or to be sent
>>> + */
>>> +struct lirc_scancode {
>>> +   __u64   timestamp;
>>> +   __u32   flags;
>>> +   __u8target;
>>> +   __u8source;
>>> +   __u8unused;
>>> +   __u8rc_proto;
>>> +   __u64   scancode;
>>
>> I'm thinking how this will be implemented using CEC. Some RC commands take 
>> arguments
>> (up to 4 bytes for the 0x67 (Tune Function) code), so how will they be 
>> handled?
>>
>> See CEC table 6 in the HDMI 1.4 spec.
>>
>> Should they be part of the scancode, or would it be better to add a '__u8 
>> args[8];'
>> field?
>>
>> I've no idea what makes sense, it's a weird corner case.
> 
> I've given it some more thought.
> 
> For cec remote control passthrough, you have the tv with the IR receiver (A),
> which then transmits CEC_MSG_USER_CONTROL_PRESSED and
> CEC_MSG_USER_CONTROL_RELEASED cec messages to the correct target, with
> arguments. Then on the target (B), it reads those commands and should execute
> them as if it received them itself.
> 
> First of all (B) is already implemented in cec using rc-core. If RC
> passthrough is enabled, then cec will pass those keycodes to rc-core (which
> end up in an input device).
> 
> So the problem we are trying to solve here is (A). How I would see this
> implemented is:
> 
> 1) A physical IR receiver exists which has an rc-core driver and a /dev/lircN
>device. This is configured using ir-keytable to map to regular input events
> 
> 2) A process receives input events, and decides that a particular key/command
>is not for itself (e.g. tell top set box to tune), so it knows what the
>target cec address is and the tune arguments, so it fills out a 
>cec_msg with the target, CEC_MSG_USER_CONTROL_PRESSED, 0x67, arguments,
>and then transmits it using the ioctl CEC_TRANSMIT, followed by
>another CEC_MSG_USER_CONTROL_RELEASED cec_msg sent using ioctl 
> CEC_TRANSMIT.
> 
> In this way of viewing things, an rc-core device is either cec or lirc, and
> thus rc-core lirc devices have a /dev/lircN and rc-core cec devices have a
> /dev/cecN.
> 
> So, the alternative which is being proposed is that a cec device has both
> a /dev/cecN and a /dev/lircN. In this case step 2) would look like:
> 
> 2) A process receives input events, and decides that a particular key/command
>is not for itself (e.g. tell top set box to tune), so it knows what the
>target cec address is and the tune arguments, so it fills in a 
>lirc_scancode with the target, CEC_MSG_USER_CONTROL_PRESSED, 0x67, 
> arguments,
>and then transmits it using write() to the /dev/lircN device, which
>then passes it on to cec_transmit() in drivers/media/cec/cec-api.c
>(without having a cec_fh), and then another lirc_scancode is
>filled in CEC_MSG_USER_CONTROL_RELEASED and sent.
> 
> Now, I think that this has a number of problems:
> 
>  - It's a lot of API for simply doing a CEC_TRANSMIT
> 
>  - and another chardev for a cec device (i.e. /dev/lircN).
> 
>  - lirc scancode tx deals with scancodes, for cec rc passthrough it isn't
>really scancodes.
> 
>  - Wiring this up is not going to be pretty or easy.
> 
>  - The lirc chardev has no other function other than sending
>CEC_MSG_USER_CONTROL_PRESSED and CEC_MSG_USER_CONTROL_RELEASED cec 
> messages.
>  
> So what I am proposing is that we don't use lirc for sending rc passthrough
> messages for cec.
> 
> I hope this makes sense and where not, please *do* tell me exactly where I
> am wrong. I think that I missed something about the scancode tx idea.

You are right, it makes no sense. Let's forget about this.

Regards,

Hans

> 
>>
>>> +};
>>> +
>>> +#define LIRC_SCANCODE_FLAG_TOGGLE  1
>>> +#define LIRC_SCANCODE_FLAG_REPEAT  2
>>
>> These flags need documentation.
> 
> They do, fair point.
> 
> Thanks,
> 
> Sean
> 

Re: [PATCH v2 01/25] media: lirc: implement scancode sending

[Sean Young]

On Mon, Oct 09, 2017 at 11:14:28AM +0200, Hans Verkuil wrote:
> On 05/10/17 10:45, Sean Young wrote:
-snip-
> > +/*
> > + * struct lirc_scancode - decoded scancode with protocol for use with
> > + * LIRC_MODE_SCANCODE
> > + *
> > + * @timestamp: Timestamp in nanoseconds using CLOCK_MONOTONIC when IR
> > + * was decoded.
> > + * @flags: should be 0 for transmit. When receiving scancodes,
> > + * LIRC_SCANCODE_FLAG_TOGGLE or LIRC_SCANCODE_FLAG_REPEAT can be set
> > + * depending on the protocol
> > + * @target: target for transmit. Unused, set to 0.
> > + * @source: source for receive. Unused, set to 0.
> > + * @unused: set to 0.
> > + * @rc_proto: see enum rc_proto
> > + * @scancode: the scancode received or to be sent
> > + */
> > +struct lirc_scancode {
> > +   __u64   timestamp;
> > +   __u32   flags;
> > +   __u8target;
> > +   __u8source;
> > +   __u8unused;
> > +   __u8rc_proto;
> > +   __u64   scancode;
> 
> I'm thinking how this will be implemented using CEC. Some RC commands take 
> arguments
> (up to 4 bytes for the 0x67 (Tune Function) code), so how will they be 
> handled?
> 
> See CEC table 6 in the HDMI 1.4 spec.
> 
> Should they be part of the scancode, or would it be better to add a '__u8 
> args[8];'
> field?
> 
> I've no idea what makes sense, it's a weird corner case.

I've given it some more thought.

For cec remote control passthrough, you have the tv with the IR receiver (A),
which then transmits CEC_MSG_USER_CONTROL_PRESSED and
CEC_MSG_USER_CONTROL_RELEASED cec messages to the correct target, with
arguments. Then on the target (B), it reads those commands and should execute
them as if it received them itself.

First of all (B) is already implemented in cec using rc-core. If RC
passthrough is enabled, then cec will pass those keycodes to rc-core (which
end up in an input device).

So the problem we are trying to solve here is (A). How I would see this
implemented is:

1) A physical IR receiver exists which has an rc-core driver and a /dev/lircN
   device. This is configured using ir-keytable to map to regular input events

2) A process receives input events, and decides that a particular key/command
   is not for itself (e.g. tell top set box to tune), so it knows what the
   target cec address is and the tune arguments, so it fills out a 
   cec_msg with the target, CEC_MSG_USER_CONTROL_PRESSED, 0x67, arguments,
   and then transmits it using the ioctl CEC_TRANSMIT, followed by
   another CEC_MSG_USER_CONTROL_RELEASED cec_msg sent using ioctl CEC_TRANSMIT.

In this way of viewing things, an rc-core device is either cec or lirc, and
thus rc-core lirc devices have a /dev/lircN and rc-core cec devices have a
/dev/cecN.

So, the alternative which is being proposed is that a cec device has both
a /dev/cecN and a /dev/lircN. In this case step 2) would look like:

2) A process receives input events, and decides that a particular key/command
   is not for itself (e.g. tell top set box to tune), so it knows what the
   target cec address is and the tune arguments, so it fills in a 
   lirc_scancode with the target, CEC_MSG_USER_CONTROL_PRESSED, 0x67, arguments,
   and then transmits it using write() to the /dev/lircN device, which
   then passes it on to cec_transmit() in drivers/media/cec/cec-api.c
   (without having a cec_fh), and then another lirc_scancode is
   filled in CEC_MSG_USER_CONTROL_RELEASED and sent.

Now, I think that this has a number of problems:

 - It's a lot of API for simply doing a CEC_TRANSMIT

 - and another chardev for a cec device (i.e. /dev/lircN).

 - lirc scancode tx deals with scancodes, for cec rc passthrough it isn't
   really scancodes.

 - Wiring this up is not going to be pretty or easy.

 - The lirc chardev has no other function other than sending
   CEC_MSG_USER_CONTROL_PRESSED and CEC_MSG_USER_CONTROL_RELEASED cec messages.
 
So what I am proposing is that we don't use lirc for sending rc passthrough
messages for cec.

I hope this makes sense and where not, please *do* tell me exactly where I
am wrong. I think that I missed something about the scancode tx idea.

> 
> > +};
> > +
> > +#define LIRC_SCANCODE_FLAG_TOGGLE  1
> > +#define LIRC_SCANCODE_FLAG_REPEAT  2
> 
> These flags need documentation.

They do, fair point.

Thanks,

Sean

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Hans Verkuil]

On 09/10/17 16:18, Sakari Ailus wrote:
> Hi Hans,
> 
> On Mon, Oct 09, 2017 at 04:08:47PM +0200, Hans Verkuil wrote:
>> On 09/10/17 16:06, Sakari Ailus wrote:
>>> Hi Mauro,
>>>
>>> On Mon, Oct 09, 2017 at 08:22:39AM -0300, Mauro Carvalho Chehab wrote:
 Em Thu,  5 Oct 2017 00:50:20 +0300
 Sakari Ailus  escreveu:

> Remove V4L2 async re-probing support. The re-probing support has been
> there to support cases where the sub-devices require resources provided by
> the main driver's hardware to function, such as clocks.
>
> Reprobing has allowed unbinding and again binding the main driver without
> explicilty unbinding the sub-device drivers. This is certainly not a
> common need, and the responsibility will be the user's going forward.
>
> An alternative could have been to introduce notifier specific locks.
> Considering the complexity of the re-probing and that it isn't really a
> solution to a problem but a workaround, remove re-probing instead.

 If the re-probing isn't using anywhere, that sounds a nice cleanup.
 Did you check if this won't break any driver (like soc_camera)?
>>>
>>> That was discussed earlier in the review; Laurent asked the same question.
>>>
>>> Re-probing never was a proper solution to any problem; it was just a hack
>>> to avoid unbinding the sensor if the bridge driver was unbound, no more: it
>>> can't be generalised to support more complex use cases. Mind you, this is
>>> on devices that aren't actually removable.
>>>
>>> I've briefly discussed this with Laurent; the proper solution would need to
>>> be implemented in the clock framework instead. There, the existing clocks
>>> obtained by drivers could be re-activated when the driver for them comes
>>> back.
>>>
>>> My proposal is that if there's real a need to address this, then it could
>>> be solved in the clock framework.
>>
>> Can you add this information to the commit log?
>>
>> I think that would be very helpful in the future.
> 
> Sure, how about this at the end of the current commit message:
> 
> If there is a need to support removing the clock provider in the future,
> this should be implemented in the clock framework instead, not in V4L2.

Yes, that sounds good.

Regards,

Hans

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Sakari Ailus]

Hi Hans,

On Mon, Oct 09, 2017 at 04:08:47PM +0200, Hans Verkuil wrote:
> On 09/10/17 16:06, Sakari Ailus wrote:
> > Hi Mauro,
> > 
> > On Mon, Oct 09, 2017 at 08:22:39AM -0300, Mauro Carvalho Chehab wrote:
> >> Em Thu,  5 Oct 2017 00:50:20 +0300
> >> Sakari Ailus  escreveu:
> >>
> >>> Remove V4L2 async re-probing support. The re-probing support has been
> >>> there to support cases where the sub-devices require resources provided by
> >>> the main driver's hardware to function, such as clocks.
> >>>
> >>> Reprobing has allowed unbinding and again binding the main driver without
> >>> explicilty unbinding the sub-device drivers. This is certainly not a
> >>> common need, and the responsibility will be the user's going forward.
> >>>
> >>> An alternative could have been to introduce notifier specific locks.
> >>> Considering the complexity of the re-probing and that it isn't really a
> >>> solution to a problem but a workaround, remove re-probing instead.
> >>
> >> If the re-probing isn't using anywhere, that sounds a nice cleanup.
> >> Did you check if this won't break any driver (like soc_camera)?
> > 
> > That was discussed earlier in the review; Laurent asked the same question.
> > 
> > Re-probing never was a proper solution to any problem; it was just a hack
> > to avoid unbinding the sensor if the bridge driver was unbound, no more: it
> > can't be generalised to support more complex use cases. Mind you, this is
> > on devices that aren't actually removable.
> > 
> > I've briefly discussed this with Laurent; the proper solution would need to
> > be implemented in the clock framework instead. There, the existing clocks
> > obtained by drivers could be re-activated when the driver for them comes
> > back.
> > 
> > My proposal is that if there's real a need to address this, then it could
> > be solved in the clock framework.
> 
> Can you add this information to the commit log?
> 
> I think that would be very helpful in the future.

Sure, how about this at the end of the current commit message:

If there is a need to support removing the clock provider in the future,
this should be implemented in the clock framework instead, not in V4L2.

-- 
Regards,

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

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Hans Verkuil]

On 09/10/17 16:06, Sakari Ailus wrote:
> Hi Mauro,
> 
> On Mon, Oct 09, 2017 at 08:22:39AM -0300, Mauro Carvalho Chehab wrote:
>> Em Thu,  5 Oct 2017 00:50:20 +0300
>> Sakari Ailus  escreveu:
>>
>>> Remove V4L2 async re-probing support. The re-probing support has been
>>> there to support cases where the sub-devices require resources provided by
>>> the main driver's hardware to function, such as clocks.
>>>
>>> Reprobing has allowed unbinding and again binding the main driver without
>>> explicilty unbinding the sub-device drivers. This is certainly not a
>>> common need, and the responsibility will be the user's going forward.
>>>
>>> An alternative could have been to introduce notifier specific locks.
>>> Considering the complexity of the re-probing and that it isn't really a
>>> solution to a problem but a workaround, remove re-probing instead.
>>
>> If the re-probing isn't using anywhere, that sounds a nice cleanup.
>> Did you check if this won't break any driver (like soc_camera)?
> 
> That was discussed earlier in the review; Laurent asked the same question.
> 
> Re-probing never was a proper solution to any problem; it was just a hack
> to avoid unbinding the sensor if the bridge driver was unbound, no more: it
> can't be generalised to support more complex use cases. Mind you, this is
> on devices that aren't actually removable.
> 
> I've briefly discussed this with Laurent; the proper solution would need to
> be implemented in the clock framework instead. There, the existing clocks
> obtained by drivers could be re-activated when the driver for them comes
> back.
> 
> My proposal is that if there's real a need to address this, then it could
> be solved in the clock framework.

Can you add this information to the commit log?

I think that would be very helpful in the future.

Regards,

Hans

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Sakari Ailus]

Hi Mauro,

On Mon, Oct 09, 2017 at 08:22:39AM -0300, Mauro Carvalho Chehab wrote:
> Em Thu,  5 Oct 2017 00:50:20 +0300
> Sakari Ailus  escreveu:
> 
> > Remove V4L2 async re-probing support. The re-probing support has been
> > there to support cases where the sub-devices require resources provided by
> > the main driver's hardware to function, such as clocks.
> > 
> > Reprobing has allowed unbinding and again binding the main driver without
> > explicilty unbinding the sub-device drivers. This is certainly not a
> > common need, and the responsibility will be the user's going forward.
> > 
> > An alternative could have been to introduce notifier specific locks.
> > Considering the complexity of the re-probing and that it isn't really a
> > solution to a problem but a workaround, remove re-probing instead.
> 
> If the re-probing isn't using anywhere, that sounds a nice cleanup.
> Did you check if this won't break any driver (like soc_camera)?

That was discussed earlier in the review; Laurent asked the same question.

Re-probing never was a proper solution to any problem; it was just a hack
to avoid unbinding the sensor if the bridge driver was unbound, no more: it
can't be generalised to support more complex use cases. Mind you, this is
on devices that aren't actually removable.

I've briefly discussed this with Laurent; the proper solution would need to
be implemented in the clock framework instead. There, the existing clocks
obtained by drivers could be re-activated when the driver for them comes
back.

My proposal is that if there's real a need to address this, then it could
be solved in the clock framework.

-- 
Kind regards,

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

Re: [PATCH 05/24] media: v4l2-dev: convert VFL_TYPE_* into an enum

[Mike Isely]

Acked-By: Mike Isely 

On Mon, 9 Oct 2017, Mauro Carvalho Chehab wrote:

> Using enums makes easier to document, as it can use kernel-doc
> markups. It also allows cross-referencing, with increases the
> kAPI readability.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/kapi/v4l2-dev.rst | 17 ++---
>  drivers/media/pci/cx88/cx88-blackbird.c   |  3 +-
>  drivers/media/pci/cx88/cx88-video.c   | 10 +++---
>  drivers/media/pci/cx88/cx88.h |  4 +--
>  drivers/media/pci/saa7134/saa7134-video.c |  2 ++
>  drivers/media/usb/cx231xx/cx231xx-video.c |  2 ++
>  drivers/media/usb/pvrusb2/pvrusb2-v4l2.c  |  2 ++
>  drivers/media/usb/tm6000/tm6000-video.c   |  2 ++
>  drivers/media/v4l2-core/v4l2-dev.c| 10 +++---
>  include/media/v4l2-dev.h  | 59 
> +--
>  include/media/v4l2-mediabus.h | 30 
>  11 files changed, 98 insertions(+), 43 deletions(-)
> 
> diff --git a/Documentation/media/kapi/v4l2-dev.rst 
> b/Documentation/media/kapi/v4l2-dev.rst
> index b29aa616c267..7bb0505b60f1 100644
> --- a/Documentation/media/kapi/v4l2-dev.rst
> +++ b/Documentation/media/kapi/v4l2-dev.rst
> @@ -196,11 +196,18 @@ device.
>  Which device is registered depends on the type argument. The following
>  types exist:
>  
> -- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices
> -- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed 
> captions, teletext)
> -- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners
> -- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners
> -- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors
> +==    
> ==
> +:c:type:`vfl_devnode_type` Device nameUsage
> +==    
> ==
> +``VFL_TYPE_GRABBER``   ``/dev/videoX``   for video input/output 
> devices
> +``VFL_TYPE_VBI``   ``/dev/vbiX`` for vertical blank data 
> (i.e.
> +  closed captions, teletext)
> +``VFL_TYPE_RADIO`` ``/dev/radioX``   for radio tuners
> +``VFL_TYPE_SUBDEV````/dev/v4l-subdevX``  for V4L2 subdevices
> +``VFL_TYPE_SDR``   ``/dev/swradioX`` for Software Defined Radio
> +  (SDR) tuners
> +``VFL_TYPE_TOUCH`` ``/dev/v4l-touchX``   for touch sensors
> +==    
> ==
>  
>  The last argument gives you a certain amount of control over the device
>  device node number used (i.e. the X in ``videoX``). Normally you will pass -1
> diff --git a/drivers/media/pci/cx88/cx88-blackbird.c 
> b/drivers/media/pci/cx88/cx88-blackbird.c
> index e3101f04941c..0e0952e60795 100644
> --- a/drivers/media/pci/cx88/cx88-blackbird.c
> +++ b/drivers/media/pci/cx88/cx88-blackbird.c
> @@ -805,8 +805,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
>  
>   strcpy(cap->driver, "cx88_blackbird");
>   sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
> - cx88_querycap(file, core, cap);
> - return 0;
> + return cx88_querycap(file, core, cap);
>  }
>  
>  static int vidioc_enum_fmt_vid_cap(struct file *file, void  *priv,
> diff --git a/drivers/media/pci/cx88/cx88-video.c 
> b/drivers/media/pci/cx88/cx88-video.c
> index 7d25ecd4404b..9be682cdb644 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -806,8 +806,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
> *priv,
>   return 0;
>  }
>  
> -void cx88_querycap(struct file *file, struct cx88_core *core,
> -struct v4l2_capability *cap)
> +int cx88_querycap(struct file *file, struct cx88_core *core,
> +   struct v4l2_capability *cap)
>  {
>   struct video_device *vdev = video_devdata(file);
>  
> @@ -825,11 +825,14 @@ void cx88_querycap(struct file *file, struct cx88_core 
> *core,
>   case VFL_TYPE_VBI:
>   cap->device_caps |= V4L2_CAP_VBI_CAPTURE;
>   break;
> + default:
> + return -EINVAL;
>   }
>   cap->capabilities = cap->device_caps | V4L2_CAP_VIDEO_CAPTURE |
>   V4L2_CAP_VBI_CAPTURE | V4L2_CAP_DEVICE_CAPS;
>   if (core->board.radio.type == CX88_RADIO)
>   cap->capabilities |= V4L2_CAP_RADIO;
> + return 0;
>  }
>  EXPORT_SYMBOL(cx88_querycap);
>  
> @@ -841,8 +844,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
>  
>   strcpy(cap->driver, "cx8800");
>   sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
> - cx88_querycap(file, core, cap);
> - return 0;
> + return cx88_querycap(file, core, cap);
>  }
>  
>  static int vidioc_enum_fmt_vid_cap(struct file *file, void  

Re: [PATCH v3 00/17] kernel-doc: add supported to document nested structs/

[Mauro Carvalho Chehab]

Em Sun, 8 Oct 2017 12:07:29 +0200
Markus Heiser  escreveu:

> > Am 07.10.2017 um 18:34 schrieb Jonathan Corbet :
> > 
> > On Wed,  4 Oct 2017 08:48:38 -0300
> > Mauro Carvalho Chehab  wrote:
> >   
> >> Right now, it is not possible to document nested struct and nested unions.
> >> kernel-doc simply ignore them.
> >> 
> >> Add support to document them.  
> > 
> > So I've finally found some time to actually look at these; sorry for being
> > so absent from the discussion.  I plead $EXCUSES...

Thanks for looking into it!

> > 
> > Some overall impressions:
> > 
> > - Seems like something we want.
> > - I love hacking all the cruft out of kernel-doc; I've been meaning to
> >  do that for a bit.
> > - It would sure be nice to restore proper man-page generation rather than
> >  documenting a hack with a perl script.  Someday.
> > 
> > I have one real complaint, though: with these patches applied, a "make
> > htmldocs" generates about 5500 (!) more warnings than it did before.  Over
> > the last couple of months, I put a bit of focused time into reducing
> > warnings, and managed to get rid of 20-30 of them.  Now I feel despondent.

Yeah, I know the feeling...

> > 
> > I really don't want to add that much noise to the docs build; I think it
> > will defeat any hope of cleaning up the warnings we already have.  I
> > wonder if we could suppress warnings about nested structs by default, and
> > add a flag or envar to turn them back on for those who want them?  
> 
> This is what I vote for: +1
> 
> > In truth, now that I look, the real problem is that the warnings are
> > repeated many times - as in, like 100 times:
> >   
> >> ./include/net/cfg80211.h:4115: warning: Function parameter or member 
> >> 'wext.ibss' not described in 'wireless_dev'
> >> ./include/net/cfg80211.h:4115: warning: Function parameter or member 
> >> 'wext.ibss' not described in 'wireless_dev'  
> > <107 instances deleted...>  
> >> ./include/net/cfg80211.h:4115: warning: Function parameter or member 
> >> 'wext.ibss' not described in 'wireless_dev'  
> > 
> > That's not something that used to happen, and is certainly not helpful.
> > Figuring that out would help a lot.  Can I get you to take a look at
> > what's going on here?  
> 
> Hi Jon, if you grep for 
> 
>  .. kernel-doc:: include/net/cfg80211.h
> 
> e.g. by:  grep cfg80211.h Documentation/driver-api/80211/cfg80211.rst | wc -l
> you will see, that this directive is used 110 times in one reST file. If you
> have 5 warnings about the kernel-doc markup in include/net/cfg80211.h you will
> get 550 warnings about kernel-doc markup just for just one source code file.
> 
> This is because the kernel-doc parser is an external process which is called
> (in this example) 110 times for one reST file and one source code file. If 
> include/net/cfg80211.h is referred in other reST files, we got accordingly
> more and more warnings .. thats really noise. 

I guess the solution here is simple: if any output selection argument
is passed (-export, -internal, -function, -nofunction), only report
warnings for things that match the output criteria. 

Not sure how easy is to implement that. I'll take a look.

> So what I see is, that a major part of such noise is self made, it was one 
> major
> goal when I started with the python implementation: run kernel-doc parser in 
> the 
> Sphinx process, cache the results and use it in all reST files where it is 
> required
> from a kernel-doc directive.
> 
> Since there is also a man page solution in the py- version I vote to merge the
> py-version into the kernel (ATM man is similar to what we had in DocBook and
> it is expandable). If you want to have a preview of the result, try this 
> patch:
> 
>  https://return42.github.io/linuxdoc/linux.html
> 
> The only drawback of the py version I see is, that Mauro prefers perl and I do
> not want to lose him as an contributer to the kernel-doc parser. IMO he is an
> experienced C programmer with an excellent regexpr knowledge. This is, what is
> needed for this job. May be we can motivate him to give python one more try,
> this is what I hope.
> 
> The py version includes all patches we had to the perl version, but I also
> know, that you are not 100% compliant with the coding style, this could
> all be fixed in a RFC round. Excuse me if I annoying with this solution;
> IMO it contains what we need, if we really want to make a step forward.

I can probably submit regex patches, no matter if it is perl or python.

I actually submitted several patches patchwork, in the past, and I'm doing
lately some contributions to Solaar, with is written in python, in order
to fix support for my mice.

The thing is that it takes me more time to write code in Python, as I
never had the time to study the language. So, I learned what I needed
there by coding.

Thanks,
Mauro

Re: [PATCH v11 1/4] rockchip/rga: v4l2 m2m support

[Heiko Stübner]

Hi Hans,

Am Montag, 9. Oktober 2017, 14:48:13 CEST schrieb Hans Verkuil:
> On 09/10/17 11:04, Jacob Chen wrote:
> > Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> > accelerates 2D graphics operations, such as point/line drawing, image
> > scaling, rotation, BitBLT, alpha blending and image blur/sharpness
> > 
> > The driver supports various operations from the rendering pipeline.
> > 
> >  - copy
> >  - fast solid color fill
> >  - rotation
> >  - flip
> >  - alpha blending
> > 
> > The code in rga-hw.c is used to configure regs according to operations
> > The code in rga-buf.c is used to create private mmu table for RGA.
> > 
> > Signed-off-by: Jacob Chen 
> 
> I ran checkpatch --strict on this patch and I found a few small issues:
> 
> WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code
> rather than BUG() or BUG_ON() #1222: FILE:
> drivers/media/platform/rockchip/rga/rga.c:89:
> +   BUG_ON(!ctx);
> 
> WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code
> rather than BUG() or BUG_ON() #1229: FILE:
> drivers/media/platform/rockchip/rga/rga.c:96:
> +   BUG_ON(!src);
> 
> WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code
> rather than BUG() or BUG_ON() #1230: FILE:
> drivers/media/platform/rockchip/rga/rga.c:97:
> +   BUG_ON(!dst);
> 
> I think you can use WARN_ON here and just return.
> 
> CHECK: struct mutex definition without comment
> #2235: FILE: drivers/media/platform/rockchip/rga/rga.h:84:
> +   struct mutex mutex;
> 
> CHECK: spinlock_t definition without comment
> #2236: FILE: drivers/media/platform/rockchip/rga/rga.h:85:
> +   spinlock_t ctrl_lock;
> 
> These two fields need a comment describing what the locks protect.
> 
> Also move patch 4/4 to the beginning of the patch series. The bindings
> patch should come before the driver.
> 
> If I have a v12 with these issues fixed and a MAINTAINERS patch, then
> I'll take it on Friday.
> 
> Do you want me to take the dts patches or will they go through another tree?

I'd prefer for me to pick up the dts patches ("ARM: dts" and "arm64: dts:"), 
as otherwise we always get conflicts and confusion :-)

I'm monitoring this series, so after you pick the binding + driver, I can
just pick the other two.


Thanks
Heiko

Re: [PATCH] [media] ov5645: I2C address change

[Laurent Pinchart]

Hello,

On Monday, 9 October 2017 12:34:26 EEST Sakari Ailus wrote:
> On Mon, Oct 09, 2017 at 11:36:01AM +0300, Todor Tomov wrote:
> > On  4.10.2017 13:47, Laurent Pinchart wrote:
> >> CC'ing the I2C mainling list and the I2C maintainer.
> >> 
> >> On Wednesday, 4 October 2017 13:30:08 EEST Sakari Ailus wrote:
> >>> On Mon, Oct 02, 2017 at 04:28:45PM +0300, Todor Tomov wrote:
>  As soon as the sensor is powered on, change the I2C address to the one
>  specified in DT. This allows to use multiple physical sensors
>  connected to the same I2C bus.
>  
>  Signed-off-by: Todor Tomov 
> >>> 
> >>> The smiapp driver does something similar and I understand Laurent might
> >>> be interested in such functionality as well.
> >>> 
> >>> It'd be nice to handle this through the I²C framework instead and to
> >>> define how the information is specified through DT. That way it could
> >>> be made generic, to work with more devices than just this one.
> >>> 
> >>> What do you think?
> > 
> > Thank you for this suggestion.
> > 
> > The way I have done it is to put the new I2C address in the DT and the
> > driver programs the change using the original I2C address. The original
> > I2C address is hardcoded in the driver. So maybe we can extend the DT
> > binding and the I2C framework so that both addresses come from the DT and
> > avoid hiding the original I2C address in the driver. This sounds good to
> > me.
> 
> Agreed.
> 
> In this case the address is known but in general that's not the case it's
> not that simple. There are register compatible devices that have different
> addresses even if they're the same devices.
> 
> It might be a good idea to make this explicit.

Yes, in the general case we need to specify the original address in DT, as the 
chip could have a non-fixed boot-up I2C address.

In many cases the value of the new I2C address doesn't matter much, as long as 
it's unique on the bus. I was thinking about implementing a dynamic allocator 
for I2C addresses, but after discussing it with Wolfram we concluded that it 
would probably not be a good idea. There could be other I2C devices on the bus 
that Linux isn't aware of, in which case the dynamic allocator could create 
address conflicts. Specifying the new address in DT is likely a better idea, 
even if it could feel a bit more of system configuration information than a 
pure hardware description.

> > Then changing the address could be device specific and also this must be
> > done right after power on so that there are no address conflicts. So I
> > don't think that we can support this through the I2C framework only, the
> > drivers that we want to do that will have to be expanded with this
> > functionality. Or do you have any other idea?
> 
> Yes, how the address is changed is always hardware specific. This would be
> most conveniently done in driver's probe or PM runtime_resume functions.

This patch modifies client->addr directly, which I don't think is a good idea. 
I'd prefer making the I2C core aware of the address change through an explicit 
API call. This would allow catching I2C adress conflicts for instance.

> It could be as simple as providing an adapter specific mutex to serialise
> address changes on the bus so that no two address changes are taking place
> at the same time. Which is essentially the impliementation you had, only
> the mutex would be for the I²C adapter, not the driver. An helper functions
> for acquiring and releasing the mutex.

Why do you need to serialize address changes ?

> I wonder what others think.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v11 1/4] rockchip/rga: v4l2 m2m support

[Hans Verkuil]

On 09/10/17 11:04, Jacob Chen wrote:
> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> accelerates 2D graphics operations, such as point/line drawing, image
> scaling, rotation, BitBLT, alpha blending and image blur/sharpness
> 
> The driver supports various operations from the rendering pipeline.
>  - copy
>  - fast solid color fill
>  - rotation
>  - flip
>  - alpha blending
> 
> The code in rga-hw.c is used to configure regs according to operations
> The code in rga-buf.c is used to create private mmu table for RGA.
> 
> Signed-off-by: Jacob Chen 

I ran checkpatch --strict on this patch and I found a few small issues:

WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
#1222: FILE: drivers/media/platform/rockchip/rga/rga.c:89:
+   BUG_ON(!ctx);

WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
#1229: FILE: drivers/media/platform/rockchip/rga/rga.c:96:
+   BUG_ON(!src);

WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
#1230: FILE: drivers/media/platform/rockchip/rga/rga.c:97:
+   BUG_ON(!dst);

I think you can use WARN_ON here and just return.

CHECK: struct mutex definition without comment
#2235: FILE: drivers/media/platform/rockchip/rga/rga.h:84:
+   struct mutex mutex;

CHECK: spinlock_t definition without comment
#2236: FILE: drivers/media/platform/rockchip/rga/rga.h:85:
+   spinlock_t ctrl_lock;

These two fields need a comment describing what the locks protect.

Also move patch 4/4 to the beginning of the patch series. The bindings
patch should come before the driver.

If I have a v12 with these issues fixed and a MAINTAINERS patch, then
I'll take it on Friday.

Do you want me to take the dts patches or will they go through another tree?

Regards,

Hans

Re: [PATCH v11 0/4] Add Rockchip RGA V4l2 support

[Hans Verkuil]

Hi Jacob,

A patch adding an entry to MAINTAINERS is still missing.

Just post a separate patch for that.

Regards,

Hans

On 09/10/17 11:04, Jacob Chen wrote:
> change in V11:
> - fix compile warning
> 
> change in V10:
> - move to rockchip/rga
> - changes according to comments
> - some style changes
> 
> change in V9:
> - remove protduff things
> - test with the latest v4l2-compliance
> 
> change in V8:
> - remove protduff things
> 
> change in V6,V7:
> - correct warning in checkpatch.pl
> 
> change in V5:
> - v4l2-compliance: handle invalid pxielformat
> - v4l2-compliance: add subscribe_event
> - add colorspace support
> 
> change in V4:
> - document the controls.
> - change according to Hans's comments
> 
> change in V3:
> - rename the controls.
> - add pm_runtime support.
> - enable node by default.
> - correct spelling in documents.
> 
> change in V2:
> - generalize the controls.
> - map buffers (10-50 us) in every cmd-run rather than in buffer-import to 
> avoid get_free_pages failed on
> actively used systems.
> - remove status in dt-bindings examples.
> 
> Jacob Chen (4):
>   rockchip/rga: v4l2 m2m support
>   ARM: dts: rockchip: add RGA device node for RK3288
>   arm64: dts: rockchip: add RGA device node for RK3399
>   dt-bindings: Document the Rockchip RGA bindings
> 
>  .../devicetree/bindings/media/rockchip-rga.txt |   33 +
>  arch/arm/boot/dts/rk3288.dtsi  |   11 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   11 +
>  drivers/media/platform/Kconfig |   15 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/rockchip/rga/Makefile   |3 +
>  drivers/media/platform/rockchip/rga/rga-buf.c  |  154 +++
>  drivers/media/platform/rockchip/rga/rga-hw.c   |  421 
>  drivers/media/platform/rockchip/rga/rga-hw.h   |  437 +
>  drivers/media/platform/rockchip/rga/rga.c  | 1012 
> 
>  drivers/media/platform/rockchip/rga/rga.h  |  123 +++
>  11 files changed,  insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
>  create mode 100644 drivers/media/platform/rockchip/rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip/rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip/rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip/rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip/rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip/rga/rga.h
> 

Re: [PATCH 00/24] V4L2 kAPI cleanups and documentation improvements part 2

[Mauro Carvalho Chehab]

Em Mon,  9 Oct 2017 07:19:06 -0300
Mauro Carvalho Chehab  escreveu:

> That's the second part of my V4L2 kAPI documentation improvements.
> It is meant to reduce the gap between the kAPI media headers
> and documentation, at least with regards to kernel-doc markups.
> 
> We should likely write more things at the ReST files under Documentation/
> to better describe some of those APIs (VB2 being likely the first candidate),
> but at least let's be sure that all V4L2 bits have kernel-doc markups.

Forgot to mention: 

This series, together with the part1 one is on this tree:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=v4l-docs-part2-v1

As I may not have time to address the remaining kAPI bits for
a while, let me document what kAPIs at include/media main dir
are still out of sync:

- cec-pin.h: struct cec_pin;
- cec.h: several structs;
- media-device.h, media-devnode.h: a couple of defines;
- rc-core.h: ancillary functions;
- soc-camera.h, v4l2-clk.h, videobuf-*.h - probably not
  worth the efforts, as those are obsolete kAPI;
- v4l2-common.h: print macros. IMHO, we should try to get
  rid of them, and use dev_foo() everywhere;
- v4l2-fwnode.h: In this specific case, Sakari has a patch
  series addressing it, moving existing documentation from
  v4l2-fwnode.c;
- v4l2-mem2mem.h: v4l2 ioctl helpers aren't documented;
- videobuf2-*.h: This series contain several documentation
  improvements there for VB2 core and V4L2, with are the
  most important ones - as they're used by the drivers.
  The other headers are either undocumented or barely
  documented.

PS.: It should be noticed that there are other files under
 include/media and inside their sub-directories that aren't
 part of the media kAPI, but are driver-specific stuff,
 like, for example, imx.h, vsp1.h and i2c/ subdir.


Thanks,
Mauro

Re: [PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

[Hans Verkuil]

On 09/10/17 14:24, Stanimir Varbanov wrote:
> This fixes wrongly filled bytesused field of v4l2_plane structure
> by include data_offset in the plane, Also fill data_offset and
> bytesused for capture type of buffers only.
> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/platform/qcom/venus/venc.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/venc.c 
> b/drivers/media/platform/qcom/venus/venc.c
> index 6f123a387cf9..9445ad492966 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -963,15 +963,16 @@ static void venc_buf_done(struct venus_inst *inst, 
> unsigned int buf_type,
>   if (!vbuf)
>   return;
>  
> - vb = >vb2_buf;
> - vb->planes[0].bytesused = bytesused;
> - vb->planes[0].data_offset = data_offset;
> -
>   vbuf->flags = flags;
>  
>   if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + vb = >vb2_buf;
> + vb2_set_plane_payload(vb, 0, bytesused + data_offset);
> + vb->planes[0].data_offset = data_offset;
>   vb->timestamp = timestamp_us * NSEC_PER_USEC;
>   vbuf->sequence = inst->sequence_cap++;
> +
> + WARN_ON(vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0));

It's good to have this, but this really should never happen. Because if it is,
then you'll have a memory overwrite. I hope the DMA engine will prevent this?

Just wondering how this works.

The patch looks good otherwise, but that WARN_ON is a bit scary.

Regards,

Hans

>   } else {
>   vbuf->sequence = inst->sequence_out++;
>   }
> 

[PATCH 1/2] media: venus: fix wrong size on dma_free

[Stanimir Varbanov]

This change will fix an issue with dma_free size found with
DMA API debug enabled.

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

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
index 1caae8feaa36..734ce11b0ed0 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -344,7 +344,7 @@ static int venus_alloc(struct venus_hfi_device *hdev, 
struct mem_desc *desc,
desc->attrs = DMA_ATTR_WRITE_COMBINE;
desc->size = ALIGN(size, SZ_4K);
 
-   desc->kva = dma_alloc_attrs(dev, size, >da, GFP_KERNEL,
+   desc->kva = dma_alloc_attrs(dev, desc->size, >da, GFP_KERNEL,
desc->attrs);
if (!desc->kva)
return -ENOMEM;
@@ -710,10 +710,8 @@ static int venus_interface_queues_init(struct 
venus_hfi_device *hdev)
if (ret)
return ret;
 
-   hdev->ifaceq_table.kva = desc.kva;
-   hdev->ifaceq_table.da = desc.da;
-   hdev->ifaceq_table.size = IFACEQ_TABLE_SIZE;
-   offset = hdev->ifaceq_table.size;
+   hdev->ifaceq_table = desc;
+   offset = IFACEQ_TABLE_SIZE;
 
for (i = 0; i < IFACEQ_NUM; i++) {
queue = >queues[i];
@@ -755,9 +753,7 @@ static int venus_interface_queues_init(struct 
venus_hfi_device *hdev)
if (ret) {
hdev->sfr.da = 0;
} else {
-   hdev->sfr.da = desc.da;
-   hdev->sfr.kva = desc.kva;
-   hdev->sfr.size = ALIGNED_SFR_SIZE;
+   hdev->sfr = desc;
sfr = hdev->sfr.kva;
sfr->buf_size = ALIGNED_SFR_SIZE;
}
-- 
2.11.0

[PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

[Stanimir Varbanov]

This fixes wrongly filled bytesused field of v4l2_plane structure
by include data_offset in the plane, Also fill data_offset and
bytesused for capture type of buffers only.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/venc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 6f123a387cf9..9445ad492966 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -963,15 +963,16 @@ static void venc_buf_done(struct venus_inst *inst, 
unsigned int buf_type,
if (!vbuf)
return;
 
-   vb = >vb2_buf;
-   vb->planes[0].bytesused = bytesused;
-   vb->planes[0].data_offset = data_offset;
-
vbuf->flags = flags;
 
if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+   vb = >vb2_buf;
+   vb2_set_plane_payload(vb, 0, bytesused + data_offset);
+   vb->planes[0].data_offset = data_offset;
vb->timestamp = timestamp_us * NSEC_PER_USEC;
vbuf->sequence = inst->sequence_cap++;
+
+   WARN_ON(vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0));
} else {
vbuf->sequence = inst->sequence_out++;
}
-- 
2.11.0

Re: [PATCH v14 20/28] v4l: fwnode: Add a helper function to obtain device / integer references

[Hans Verkuil]

Hi Sakari,

My reply here is also valid for v15.

On 26/09/17 13:30, Sakari Ailus wrote:
> Hi Hans,
> 
> Thanks for the review.
> 
> On Tue, Sep 26, 2017 at 10:47:40AM +0200, Hans Verkuil wrote:
>> On 26/09/17 00:25, Sakari Ailus wrote:
>>> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
>>> the device's own fwnode, it will follow child fwnodes with the given
>>> property-value pair and return the resulting fwnode.
>>>
>>> Signed-off-by: Sakari Ailus 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-fwnode.c | 201 
>>> ++
>>>  1 file changed, 201 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
>>> b/drivers/media/v4l2-core/v4l2-fwnode.c
>>> index f739dfd16cf7..f93049c361e4 100644
>>> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
>>> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
>>> @@ -578,6 +578,207 @@ static int v4l2_fwnode_reference_parse(
>>> return ret;
>>>  }
>>>  
>>> +/*
>>> + * v4l2_fwnode_reference_get_int_prop - parse a reference with integer
>>> + * arguments
>>> + * @dev: struct device pointer
>>> + * @notifier: notifier for @dev
>>> + * @prop: the name of the property
>>> + * @index: the index of the reference to get
>>> + * @props: the array of integer property names
>>> + * @nprops: the number of integer property names in @nprops
>>> + *
>>> + * Find fwnodes referred to by a property @prop, then under that
>>> + * iteratively, @nprops times, follow each child node which has a
>>> + * property in @props array at a given child index the value of which
>>> + * matches the integer argument at an index.
>>
>> "at an index". Still makes no sense to me. Which index?
> 
> How about this:
> 
> First find an fwnode referred to by the reference at @index in @prop.
> 
> Then under that fwnode, @nprops times, for each property in @props,
> iteratively follow child nodes starting from fwnode such that they have the
> property in @props array at the index of the child node distance from the

distance? You mean 'instance'?

> root node and the value of that property matching with the integer argument of
> the reference, at the same index.

You've completely lost me. About halfway through this sentence my brain crashed 
:-)

> 
>>
>>> + *
>>> + * For example, if this function was called with arguments and values
>>> + * @dev corresponding to device "SEN", @prop == "flash-leds", @index
>>> + * == 1, @props == { "led" }, @nprops == 1, with the ASL snippet below
>>> + * it would return the node marked with THISONE. The @dev argument in
>>> + * the ASL below.
>>
>> I know I asked for this before, but can you change the example to one where
>> nprops = 2? I think that will help understanding this.
> 
> I could do that but then the example no longer corresponds to any actual
> case that exists at the moment. LED nodes will use a single integer
> argument and lens-focus nodes none.

So? The example is here to understand the code and it doesn't have to be
related to actual hardware for a mainlined driver.

If you really don't want to do this here, then put the example in the commit
log. I don't see any reason why you can't put it here, though.

I think that once I see an 'nprops = 2' example I can rephrase that
brain-crash sentence for you...

BTW, where are the ACPI 'bindings' defined anyway? For DT they are in the
bindings directory, but where does ACPI define such things? Just curious.

Regards,

Hans

> 
>>
>>> + *
>>> + * Device (LED)
>>> + * {
>>> + * Name (_DSD, Package () {
>>> + * ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>>> + * Package () {
>>> + * Package () { "led0", "LED0" },
>>> + * Package () { "led1", "LED1" },
>>> + * }
>>> + * })
>>> + * Name (LED0, Package () {
>>> + * ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>> + * Package () {
>>> + * Package () { "led", 0 },
>>> + * }
>>> + * })
>>> + * Name (LED1, Package () {
>>> + * // THISONE
>>> + * ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>> + * Package () {
>>> + * Package () { "led", 1 },
>>> + * }
>>> + * })
>>> + * }
>>> + *
>>> + * Device (SEN)
>>> + * {
>>> + * Name (_DSD, Package () {
>>> + * ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>> + * Package () {
>>> + * Package () {
>>> + * "flash-leds",
>>> + * Package () { ^LED, 0, ^LED, 1 },
>>> + * }
>>> + * }
>>> + * })
>>> + * }
>>> + *
>>> + * where
>>> + *
>>> + * LED LED driver device
>>> + * LED0First LED
>>> + * LED1Second LED
>>> + * 

[GIT PULL FOR v4.15] RC fixes

[Sean Young]

Hi Mauro,

Here is the new tango driver and some fixes to ensure drivers which depend
on device tree, only build if device tree is enabled (or test compile). 

Please note that MAINTAINERS already has an entry for tango, which matches
the new driver.

Thanks,
Sean

The following changes since commit c1301077213d4dca34f01fc372b64d3c4a49a437:

  [media] media: rc: fix gpio-ir-receiver build failure (2017-10-05 10:16:21 
-0300)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.15b

for you to fetch changes up to d4218fbb8c47457c172a60ccc7f0baec7ce1f6f6:

  media: rc: ir-spi needs OF (2017-10-09 11:27:29 +0100)


David Härdeman (1):
  media: lirc_dev: remove min_timeout and max_timeout

Mans Rullgard (1):
  media: rc: Add driver for tango HW IR decoder

Marc Gonzalez (2):
  media: rc: Add tango keymap
  media: dt: bindings: Add binding for tango HW IR decoder

Sean Young (6):
  media: rc: nec decoder should not send both repeat and keycode
  media: rc: gpio-ir-tx does not work without devicetree or gpiolib
  media: rc: pwm-ir-tx needs OF
  media: rc: hix5hd2 drivers needs OF
  media: rc: check for integer overflow
  media: rc: ir-spi needs OF

 .../devicetree/bindings/media/tango-ir.txt |  21 ++
 drivers/media/rc/Kconfig   |  14 +
 drivers/media/rc/Makefile  |   1 +
 drivers/media/rc/ir-lirc-codec.c   |   9 +-
 drivers/media/rc/ir-nec-decoder.c  |  29 ++-
 drivers/media/rc/keymaps/Makefile  |   1 +
 drivers/media/rc/keymaps/rc-tango.c|  92 +++
 drivers/media/rc/lirc_dev.c|  18 --
 drivers/media/rc/tango-ir.c| 281 +
 include/media/lirc_dev.h   |   6 -
 include/media/rc-map.h |   1 +
 11 files changed, 434 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/tango-ir.txt
 create mode 100644 drivers/media/rc/keymaps/rc-tango.c
 create mode 100644 drivers/media/rc/tango-ir.c

Re: [PATCH v15 04/32] v4l: async: Fix notifier complete callback error handling

[Hans Verkuil]

On 04/10/17 23:50, Sakari Ailus wrote:
> The notifier complete callback may return an error. This error code was
> simply returned to the caller but never handled properly.
> 
> Move calling the complete callback function to the caller from
> v4l2_async_test_notify and undo the work that was done either in async
> sub-device or async notifier registration.
> 
> Reported-by: Russell King 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 78 
> +++-
>  1 file changed, 60 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index ca281438a0ae..4924481451ca 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -122,9 +122,6 @@ static int v4l2_async_test_notify(struct 
> v4l2_async_notifier *notifier,
>   /* Move from the global subdevice list to notifier's done */
>   list_move(>async_list, >done);
>  
> - if (list_empty(>waiting) && notifier->complete)
> - return notifier->complete(notifier);
> -
>   return 0;
>  }
>  
> @@ -136,11 +133,27 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
>   sd->asd = NULL;
>  }
>  
> +static void v4l2_async_notifier_unbind_all_subdevs(
> + struct v4l2_async_notifier *notifier)
> +{
> + struct v4l2_subdev *sd, *tmp;
> +
> + list_for_each_entry_safe(sd, tmp, >done, async_list) {
> + if (notifier->unbind)
> + notifier->unbind(notifier, sd, sd->asd);
> +
> + v4l2_async_cleanup(sd);
> +
> + list_move(>async_list, _list);
> + }
> +}
> +
>  int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
>struct v4l2_async_notifier *notifier)
>  {
>   struct v4l2_subdev *sd, *tmp;
>   struct v4l2_async_subdev *asd;
> + int ret;
>   int i;
>  
>   if (!v4l2_dev || !notifier->num_subdevs ||
> @@ -185,19 +198,30 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   }
>   }
>  
> + if (list_empty(>waiting) && notifier->complete) {
> + ret = notifier->complete(notifier);
> + if (ret)
> + goto err_complete;
> + }
> +
>   /* Keep also completed notifiers on the list */
>   list_add(>list, _list);
>  
>   mutex_unlock(_lock);
>  
>   return 0;
> +
> +err_complete:
> + v4l2_async_notifier_unbind_all_subdevs(notifier);
> +
> + mutex_unlock(_lock);
> +
> + return ret;
>  }
>  EXPORT_SYMBOL(v4l2_async_notifier_register);
>  
>  void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
>  {
> - struct v4l2_subdev *sd, *tmp;
> -
>   if (!notifier->v4l2_dev)
>   return;
>  
> @@ -205,14 +229,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>  
>   list_del(>list);
>  
> - list_for_each_entry_safe(sd, tmp, >done, async_list) {
> - if (notifier->unbind)
> - notifier->unbind(notifier, sd, sd->asd);
> -
> - v4l2_async_cleanup(sd);
> -
> - list_move(>async_list, _list);
> - }
> + v4l2_async_notifier_unbind_all_subdevs(notifier);
>  
>   mutex_unlock(_lock);
>  
> @@ -223,6 +240,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>  int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>  {
>   struct v4l2_async_notifier *notifier;
> + int ret;
>  
>   /*
>* No reference taken. The reference is held by the device
> @@ -238,19 +256,43 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>  
>   list_for_each_entry(notifier, _list, list) {
>   struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier, 
> sd);
> - if (asd) {
> - int ret = v4l2_async_test_notify(notifier, sd, asd);
> - mutex_unlock(_lock);
> - return ret;
> - }
> + int ret;
> +
> + if (!asd)
> + continue;
> +
> + ret = v4l2_async_test_notify(notifier, sd, asd);
> + if (ret)
> + goto err_unlock;
> +
> + if (!list_empty(>waiting) || !notifier->complete)
> + goto out_unlock;
> +
> + ret = notifier->complete(notifier);
> + if (ret)
> + goto err_cleanup;
> +
> + goto out_unlock;
>   }
>  
>   /* None matched, wait for hot-plugging */
>   list_add(>async_list, _list);
>  
> +out_unlock:
>   mutex_unlock(_lock);
>  
>   return 0;
> +
> +err_cleanup:
> + if (notifier->unbind)
> + notifier->unbind(notifier, sd, sd->asd);
> +
> + v4l2_async_cleanup(sd);

I'm trying to understand this. Who will unbind all subdevs in this case?

And in the general case: if 

Re: [PATCH v15 05/32] v4l: async: Correctly serialise async sub-device unregistration

[Hans Verkuil]

On 04/10/17 23:50, Sakari Ailus wrote:
> The check whether an async sub-device is bound to a notifier was performed
> without list_lock held, making it possible for another process to
> unbind the async sub-device before the sub-device unregistration function
> proceeds to take the lock.
> 
> Fix this by first acquiring the lock and then proceeding with the check.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

> ---
>  drivers/media/v4l2-core/v4l2-async.c | 18 +++---
>  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 4924481451ca..cde2cf2ab4b0 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -298,20 +298,16 @@ EXPORT_SYMBOL(v4l2_async_register_subdev);
>  
>  void v4l2_async_unregister_subdev(struct v4l2_subdev *sd)
>  {
> - struct v4l2_async_notifier *notifier = sd->notifier;
> -
> - if (!sd->asd) {
> - if (!list_empty(>async_list))
> - v4l2_async_cleanup(sd);
> - return;
> - }
> -
>   mutex_lock(_lock);
>  
> - list_add(>asd->list, >waiting);
> + if (sd->asd) {
> + struct v4l2_async_notifier *notifier = sd->notifier;
>  
> - if (notifier->unbind)
> - notifier->unbind(notifier, sd, sd->asd);
> + list_add(>asd->list, >waiting);
> +
> + if (notifier->unbind)
> + notifier->unbind(notifier, sd, sd->asd);
> + }
>  
>   v4l2_async_cleanup(sd);
>  
> 

Re: [PATCH v15 07/32] v4l: async: Add V4L2 async documentation to the documentation build

[Mauro Carvalho Chehab]

Em Thu,  5 Oct 2017 00:50:26 +0300
Sakari Ailus  escreveu:

> The V4L2 async wasn't part of the documentation build. Fix this.
> 
> Signed-off-by: Sakari Ailus 
> Reviewed-by: Niklas Söderlund 
> Acked-by: Hans Verkuil 
> Reviewed-by: Laurent Pinchart 

Reviewed-by: Mauro Carvalho Chehab 

It doesn't make sense to keep rebasing this patch or to delay
merging it: just add it at the next git pull request you send me,
as this is actually independent of the rest :-)


> ---
>  Documentation/media/kapi/v4l2-async.rst | 3 +++
>  Documentation/media/kapi/v4l2-core.rst  | 1 +
>  2 files changed, 4 insertions(+)
>  create mode 100644 Documentation/media/kapi/v4l2-async.rst
> 
> diff --git a/Documentation/media/kapi/v4l2-async.rst 
> b/Documentation/media/kapi/v4l2-async.rst
> new file mode 100644
> index ..523ff9eb09a0
> --- /dev/null
> +++ b/Documentation/media/kapi/v4l2-async.rst
> @@ -0,0 +1,3 @@
> +V4L2 async kAPI
> +^^^
> +.. kernel-doc:: include/media/v4l2-async.h
> diff --git a/Documentation/media/kapi/v4l2-core.rst 
> b/Documentation/media/kapi/v4l2-core.rst
> index c7434f38fd9c..5cf292037a48 100644
> --- a/Documentation/media/kapi/v4l2-core.rst
> +++ b/Documentation/media/kapi/v4l2-core.rst
> @@ -19,6 +19,7 @@ Video4Linux devices
>  v4l2-mc
>  v4l2-mediabus
>  v4l2-mem2mem
> +v4l2-async
>  v4l2-fwnode
>  v4l2-rect
>  v4l2-tuner



Thanks,
Mauro

Re: [PATCH v15 03/32] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

[Hans Verkuil]

On 04/10/17 23:50, Sakari Ailus wrote:
> From: Niklas Söderlund 
> 
> The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it to
> notifier->unbind() have no effect and leaves the notifier confused. Call

have -> has

> the unbind() callback prior to cleaning up the subdevice to avoid this.
> 
> Signed-off-by: Niklas Söderlund 
> Signed-off-by: Sakari Ailus 

After fixing this small typo:

Acked-by: Hans Verkuil 

> ---
>  drivers/media/v4l2-core/v4l2-async.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 21c748bf3a7b..ca281438a0ae 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -206,11 +206,11 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   list_del(>list);
>  
>   list_for_each_entry_safe(sd, tmp, >done, async_list) {
> - v4l2_async_cleanup(sd);
> -
>   if (notifier->unbind)
>   notifier->unbind(notifier, sd, sd->asd);
>  
> + v4l2_async_cleanup(sd);
> +
>   list_move(>async_list, _list);
>   }
>  
> @@ -268,11 +268,11 @@ void v4l2_async_unregister_subdev(struct v4l2_subdev 
> *sd)
>  
>   list_add(>asd->list, >waiting);
>  
> - v4l2_async_cleanup(sd);
> -
>   if (notifier->unbind)
>   notifier->unbind(notifier, sd, sd->asd);
>  
> + v4l2_async_cleanup(sd);
> +
>   mutex_unlock(_lock);
>  }
>  EXPORT_SYMBOL(v4l2_async_unregister_subdev);
> 

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Mauro Carvalho Chehab]

Em Thu,  5 Oct 2017 00:50:20 +0300
Sakari Ailus  escreveu:

> Remove V4L2 async re-probing support. The re-probing support has been
> there to support cases where the sub-devices require resources provided by
> the main driver's hardware to function, such as clocks.
> 
> Reprobing has allowed unbinding and again binding the main driver without
> explicilty unbinding the sub-device drivers. This is certainly not a
> common need, and the responsibility will be the user's going forward.
> 
> An alternative could have been to introduce notifier specific locks.
> Considering the complexity of the re-probing and that it isn't really a
> solution to a problem but a workaround, remove re-probing instead.

If the re-probing isn't using anywhere, that sounds a nice cleanup.
Did you check if this won't break any driver (like soc_camera)?

If not, then Acked-by: Mauro Carvalho Chehab 

> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 
> Acked-by: Laurent Pinchart 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 54 
> +---
>  1 file changed, 1 insertion(+), 53 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index d741a8e0fdac..60a1a50b9537 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -198,78 +198,26 @@ EXPORT_SYMBOL(v4l2_async_notifier_register);
>  void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
>  {
>   struct v4l2_subdev *sd, *tmp;
> - unsigned int notif_n_subdev = notifier->num_subdevs;
> - unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> - struct device **dev;
> - int i = 0;
>  
>   if (!notifier->v4l2_dev)
>   return;
>  
> - dev = kvmalloc_array(n_subdev, sizeof(*dev), GFP_KERNEL);
> - if (!dev) {
> - dev_err(notifier->v4l2_dev->dev,
> - "Failed to allocate device cache!\n");
> - }
> -
>   mutex_lock(_lock);
>  
>   list_del(>list);
>  
>   list_for_each_entry_safe(sd, tmp, >done, async_list) {
> - struct device *d;
> -
> - d = get_device(sd->dev);
> -
>   v4l2_async_cleanup(sd);
>  
> - /* If we handled USB devices, we'd have to lock the parent too 
> */
> - device_release_driver(d);
> -
>   if (notifier->unbind)
>   notifier->unbind(notifier, sd, sd->asd);
>  
> - /*
> -  * Store device at the device cache, in order to call
> -  * put_device() on the final step
> -  */
> - if (dev)
> - dev[i++] = d;
> - else
> - put_device(d);
> + list_move(>async_list, _list);
>   }
>  
>   mutex_unlock(_lock);
>  
> - /*
> -  * Call device_attach() to reprobe devices
> -  *
> -  * NOTE: If dev allocation fails, i is 0, and the whole loop won't be
> -  * executed.
> -  */
> - while (i--) {
> - struct device *d = dev[i];
> -
> - if (d && device_attach(d) < 0) {
> - const char *name = "(none)";
> - int lock = device_trylock(d);
> -
> - if (lock && d->driver)
> - name = d->driver->name;
> - dev_err(d, "Failed to re-probe to %s\n", name);
> - if (lock)
> - device_unlock(d);
> - }
> - put_device(d);
> - }
> - kvfree(dev);
> -
>   notifier->v4l2_dev = NULL;
> -
> - /*
> -  * Don't care about the waiting list, it is initialised and populated
> -  * upon notifier registration.
> -  */
>  }
>  EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>  



Thanks,
Mauro

Re: [PATCH v15 02/32] v4l: async: Don't set sd->dev NULL in v4l2_async_cleanup

[Hans Verkuil]

On 04/10/17 23:50, Sakari Ailus wrote:
> v4l2_async_cleanup() is called when the async sub-device is unbound from
> the media device. As the pointer is set by the driver registering the
> async sub-device, leave the pointer as set by the driver.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

> ---
>  drivers/media/v4l2-core/v4l2-async.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 60a1a50b9537..21c748bf3a7b 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -134,7 +134,6 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
>   /* Subdevice driver will reprobe and put the subdev back onto the list 
> */
>   list_del_init(>async_list);
>   sd->asd = NULL;
> - sd->dev = NULL;
>  }
>  
>  int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> 

Re: [PATCH 03/24] media: v4l2-mediabus: use BIT() macro for flags

[Sakari Ailus]

On Mon, Oct 09, 2017 at 07:19:09AM -0300, Mauro Carvalho Chehab wrote:
> Instead of using (1 << n) for bits, use the BIT() macro,
> as it makes them better documented.

I wouldn't say this makes a difference from documentation point of view.

Anyway,

Acked-by: Sakari Ailus 

> 
> Signed-off-by: Mauro Carvalho Chehab 

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

Re: [PATCH 02/24] media: v4l2-flash-led-class.h: add kernel-doc to two ancillary funcs

[Sakari Ailus]

Hi Mauro,

Thanks for the patch.

On Mon, Oct 09, 2017 at 07:19:08AM -0300, Mauro Carvalho Chehab wrote:
> There are two ancillary functions at v4l2-flash-led-class.h
> that aren't documented.
> 
> Document them.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/v4l2-flash-led-class.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/media/v4l2-flash-led-class.h 
> b/include/media/v4l2-flash-led-class.h
> index 5c1d50f78e12..39a5daa977aa 100644
> --- a/include/media/v4l2-flash-led-class.h
> +++ b/include/media/v4l2-flash-led-class.h
> @@ -91,12 +91,24 @@ struct v4l2_flash {
>   struct v4l2_ctrl **ctrls;
>  };
>  
> +/**
> + * v4l2_subdev_to_v4l2_flash - Returns a _flash from the

v4l2_flash -> struct v4l2_flash ?

Same below. With these,

Acked-by: Sakari Ailus 

> + *  v4l2_subdev embedded on it.
> + *
> + * @sd: pointer to  v4l2_subdev
> + */
>  static inline struct v4l2_flash *v4l2_subdev_to_v4l2_flash(
>   struct v4l2_subdev *sd)
>  {
>   return container_of(sd, struct v4l2_flash, sd);
>  }
>  
> +/**
> + * v4l2_ctrl_to_v4l2_flash - Returns a _flash from the
> + *  v4l2_ctrl embedded on it.
> + *
> + * @c: pointer to  v4l2_ctrl
> + */
>  static inline struct v4l2_flash *v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
>  {
>   return container_of(c->handler, struct v4l2_flash, hdl);

-- 
Regards,

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

Re: [PATCH 01/24] media: v4l2-dev.h: add kernel-doc to two macros

[Sakari Ailus]

Hi Mauro,

On Mon, Oct 09, 2017 at 07:19:07AM -0300, Mauro Carvalho Chehab wrote:
> There are two macros at v4l2-dev.h that aren't documented.
> 
> Document them, for completeness.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/v4l2-dev.h | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index e657614521e3..de1a1453cfd9 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -260,9 +260,21 @@ struct video_device
>   struct mutex *lock;
>  };
>  
> -#define media_entity_to_video_device(__e) \
> - container_of(__e, struct video_device, entity)
> -/* dev to video-device */
> +/**
> + * media_entity_to_video_device - Returns a  video_device from
> + *   the  media_entity embedded on it.
> + *
> + * @entity: pointer to  media_entity
> + */
> +#define media_entity_to_video_device(entity) \
> + container_of(entity, struct video_device, entity)
> +
> +/**
> + * media_entity_to_video_device - Returns a  video_device from

-> to_video_device

With that,

Acked-by: Sakari Ailus 

> + *   the  device embedded on it.
> + *
> + * @cd: pointer to  device
> + */
>  #define to_video_device(cd) container_of(cd, struct video_device, dev)
>  
>  /**

-- 
Regards,

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

Re: [PATCH 09/24] media: v4l2-dev: document video_device flags

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> Convert #defines to enums and add kernel-doc markups for V4L2
> video_device flags.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  include/media/v4l2-dev.h | 25 ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index 87dac58c7799..33a5256232f8 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -61,12 +61,22 @@ struct video_device;
>  struct v4l2_device;
>  struct v4l2_ctrl_handler;
>  
> -/* Flag to mark the video_device struct as registered.
> -   Drivers can clear this flag if they want to block all future
> -   device access. It is cleared by video_unregister_device. */
> -#define V4L2_FL_REGISTERED   (0)
> -/* file->private_data points to struct v4l2_fh */
> -#define V4L2_FL_USES_V4L2_FH (1)
> +/**
> + * enum v4l2_video_device_flags - Flags used by  video_device
> + *
> + * @V4L2_FL_REGISTERED:
> + *   indicates that a  video_device is registered.
> + *   Drivers can clear this flag if they want to block all future
> + *   device access. It is cleared by video_unregister_device.
> + * @V4L2_FL_USES_V4L2_FH:
> + *   indicates that file->private_data points to  v4l2_fh.
> + *   This flag is set by the core when v4l2_fh_init() is called.
> + *   All new drivers should use it.
> + */
> +enum v4l2_video_device_flags {
> + V4L2_FL_REGISTERED  = 0,
> + V4L2_FL_USES_V4L2_FH= 1,
> +};
>  
>  /* Priority helper functions */
>  
> @@ -214,7 +224,8 @@ struct v4l2_file_operations {
>   * @vfl_dir: V4L receiver, transmitter or m2m
>   * @minor: device node 'minor'. It is set to -1 if the registration failed
>   * @num: number of the video device node
> - * @flags: video device flags. Use bitops to set/clear/test flags
> + * @flags: video device flags. Use bitops to set/clear/test flags.
> + *  Contains a set of  v4l2_video_device_flags.
>   * @index: attribute to differentiate multiple indices on one physical device
>   * @fh_lock: Lock for all v4l2_fhs
>   * @fh_list: List of  v4l2_fh
> 

Re: [PATCH 07/24] media: get rid of i2c-addr.h

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> In the past, the same I2C address were used on multiple places.
> After I2C rebinding changes, this is no longer needed. So, we
> can just get rid of this header, placing the I2C address where
> they belong, e. g. either at bttv driver or at tvtuner.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Huh, I thought this header was nuked a long time ago...

Regards,

Hans

> ---
>  drivers/media/i2c/tda7432.c |  1 -
>  drivers/media/i2c/tvaudio.c |  2 --
>  drivers/media/pci/bt8xx/bttv-cards.c|  7 +++
>  drivers/media/pci/bt8xx/bttv.h  |  1 -
>  drivers/media/usb/em28xx/em28xx-cards.c |  1 -
>  drivers/media/usb/tm6000/tm6000-cards.c |  1 -
>  include/media/i2c-addr.h| 35 
> -
>  include/media/i2c/tvaudio.h | 17 +++-
>  8 files changed, 23 insertions(+), 42 deletions(-)
>  delete mode 100644 include/media/i2c-addr.h
> 
> diff --git a/drivers/media/i2c/tda7432.c b/drivers/media/i2c/tda7432.c
> index d87168adee45..1c5c61d829d6 100644
> --- a/drivers/media/i2c/tda7432.c
> +++ b/drivers/media/i2c/tda7432.c
> @@ -36,7 +36,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #ifndef VIDEO_AUDIO_BALANCE
>  # define VIDEO_AUDIO_BALANCE 32
> diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
> index ce86534450ac..92718a9ff5ea 100644
> --- a/drivers/media/i2c/tvaudio.c
> +++ b/drivers/media/i2c/tvaudio.c
> @@ -40,8 +40,6 @@
>  #include 
>  #include 
>  
> -#include 
> -
>  /* -- */
>  /* insmod args*/
>  
> diff --git a/drivers/media/pci/bt8xx/bttv-cards.c 
> b/drivers/media/pci/bt8xx/bttv-cards.c
> index 5cc42b426715..7dcf509e66d9 100644
> --- a/drivers/media/pci/bt8xx/bttv-cards.c
> +++ b/drivers/media/pci/bt8xx/bttv-cards.c
> @@ -141,6 +141,13 @@ MODULE_PARM_DESC(audiodev, "specify audio device:\n"
>  MODULE_PARM_DESC(saa6588, "if 1, then load the saa6588 RDS module, default 
> (0) is to use the card definition.");
>  MODULE_PARM_DESC(no_overlay, "allow override overlay default (0 disables, 1 
> enables) [some VIA/SIS chipsets are known to have problem with overlay]");
>  
> +
> +/* I2C addresses list */
> +#define I2C_ADDR_TDA7432 0x8a
> +#define I2C_ADDR_MSP3400 0x80
> +#define I2C_ADDR_MSP3400_ALT 0x88
> +
> +
>  /* --- */
>  /* list of card IDs for bt878+ cards   */
>  
> diff --git a/drivers/media/pci/bt8xx/bttv.h b/drivers/media/pci/bt8xx/bttv.h
> index 91301c3cad1e..faea9aeff711 100644
> --- a/drivers/media/pci/bt8xx/bttv.h
> +++ b/drivers/media/pci/bt8xx/bttv.h
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  /* -- */
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 4c57fd7929cb..34e16f6ab4ac 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -36,7 +36,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
> b/drivers/media/usb/tm6000/tm6000-cards.c
> index 2537643a1808..b4df9181c54b 100644
> --- a/drivers/media/usb/tm6000/tm6000-cards.c
> +++ b/drivers/media/usb/tm6000/tm6000-cards.c
> @@ -23,7 +23,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include "tm6000.h"
> diff --git a/include/media/i2c-addr.h b/include/media/i2c-addr.h
> deleted file mode 100644
> index fba0457b74c4..
> --- a/include/media/i2c-addr.h
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -/*
> - *   V4L I2C address list
> - *
> - *
> - *   Copyright (C) 2006 Mauro Carvalho Chehab 
> - *   Based on a previous mapping by
> - *   Ralph Metzler (r...@thp.uni-koeln.de)
> - *   Gerd Knorr 
> - *
> - */
> -
> -/* bttv address list */
> -#define I2C_ADDR_TDA7432 0x8a
> -#define I2C_ADDR_TDA8425 0x82
> -#define I2C_ADDR_TDA9840 0x84
> -#define I2C_ADDR_TDA9874 0xb0 /* also used by 9875 */
> -#define I2C_ADDR_TDA9875 0xb0
> -#define I2C_ADDR_MSP3400 0x80
> -#define I2C_ADDR_MSP3400_ALT 0x88
> -#define I2C_ADDR_TEA6300 0x80 /* also used by 6320 */
> -
> -/*
> - * i2c bus addresses for the chips supported by tvaudio.c
> - */
> -
> -#define I2C_ADDR_TDA8425 0x82
> -#define I2C_ADDR_TDA9840 0x84 /* also used by TA8874Z */
> -#define I2C_ADDR_TDA985x_L   0xb4 /* also used by 9873 */
> -#define I2C_ADDR_TDA985x_H   0xb6
> -#define I2C_ADDR_TDA9874 0xb0 /* also used by 9875 */
> -
> -#define I2C_ADDR_TEA6300 0x80 /* 

Re: [PATCH 08/24] media: v4l2-dev: document VFL_DIR_* direction defines

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> The V4L_DIR_* direction flags document the direction for a
> V4L2 device node. Convert them to enum and document.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  include/media/v4l2-dev.h | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index f182b47dfd71..87dac58c7799 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -40,11 +40,21 @@ enum vfl_devnode_type {
>  };
>  #define VFL_TYPE_MAX VFL_TYPE_TOUCH
>  
> -/* Is this a receiver, transmitter or mem-to-mem? */
> -/* Ignored for VFL_TYPE_SUBDEV. */
> -#define VFL_DIR_RX   0
> -#define VFL_DIR_TX   1
> -#define VFL_DIR_M2M  2
> +/**
> + * enum  vfl_direction - Identifies if a  video_device corresponds
> + *   to a receiver, a transmitter or a mem-to-mem device.
> + *
> + * @VFL_DIR_RX:  device is a receiver.
> + * @VFL_DIR_TX:  device is a transmitter.
> + * @VFL_DIR_M2M: device is a memory to memory device.
> + *
> + * Note: Ignored if  vfl_devnode_type is %VFL_TYPE_SUBDEV.
> + */
> +enum vfl_devnode_direction {
> + VFL_DIR_RX,
> + VFL_DIR_TX,
> + VFL_DIR_M2M,
> +};
>  
>  struct v4l2_ioctl_callbacks;
>  struct video_device;
> @@ -249,7 +259,7 @@ struct video_device
>   /* device info */
>   char name[32];
>   enum vfl_devnode_type vfl_type;
> - int vfl_dir;
> + enum vfl_devnode_direction vfl_dir;
>   int minor;
>   u16 num;
>   unsigned long flags;
> 

Re: [PATCH 06/24] media: i2c-addr.h: get rid of now unused defines

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> Some of the previously used I2C addresses there aren't used
> anymore. So, get rid of them.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  include/media/i2c-addr.h | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/include/media/i2c-addr.h b/include/media/i2c-addr.h
> index 5d0f56054d26..fba0457b74c4 100644
> --- a/include/media/i2c-addr.h
> +++ b/include/media/i2c-addr.h
> @@ -10,21 +10,14 @@
>   */
>  
>  /* bttv address list */
> -#define I2C_ADDR_TSA5522 0xc2
>  #define I2C_ADDR_TDA7432 0x8a
>  #define I2C_ADDR_TDA8425 0x82
>  #define I2C_ADDR_TDA9840 0x84
> -#define I2C_ADDR_TDA9850 0xb6 /* also used by 9855,9873 */
>  #define I2C_ADDR_TDA9874 0xb0 /* also used by 9875 */
>  #define I2C_ADDR_TDA9875 0xb0
> -#define I2C_ADDR_HAUPEE  0xa0
> -#define I2C_ADDR_STBEE   0xae
> -#define I2C_ADDR_VHX 0xc0
>  #define I2C_ADDR_MSP3400 0x80
>  #define I2C_ADDR_MSP3400_ALT 0x88
>  #define I2C_ADDR_TEA6300 0x80 /* also used by 6320 */
> -#define I2C_ADDR_DPL3518 0x84
> -#define I2C_ADDR_TDA9887 0x86
>  
>  /*
>   * i2c bus addresses for the chips supported by tvaudio.c
> 

Re: [PATCH 05/24] media: v4l2-dev: convert VFL_TYPE_* into an enum

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> Using enums makes easier to document, as it can use kernel-doc
> markups. It also allows cross-referencing, with increases the
> kAPI readability.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  Documentation/media/kapi/v4l2-dev.rst | 17 ++---
>  drivers/media/pci/cx88/cx88-blackbird.c   |  3 +-
>  drivers/media/pci/cx88/cx88-video.c   | 10 +++---
>  drivers/media/pci/cx88/cx88.h |  4 +--
>  drivers/media/pci/saa7134/saa7134-video.c |  2 ++
>  drivers/media/usb/cx231xx/cx231xx-video.c |  2 ++
>  drivers/media/usb/pvrusb2/pvrusb2-v4l2.c  |  2 ++
>  drivers/media/usb/tm6000/tm6000-video.c   |  2 ++
>  drivers/media/v4l2-core/v4l2-dev.c| 10 +++---
>  include/media/v4l2-dev.h  | 59 
> +--
>  include/media/v4l2-mediabus.h | 30 
>  11 files changed, 98 insertions(+), 43 deletions(-)
> 
> diff --git a/Documentation/media/kapi/v4l2-dev.rst 
> b/Documentation/media/kapi/v4l2-dev.rst
> index b29aa616c267..7bb0505b60f1 100644
> --- a/Documentation/media/kapi/v4l2-dev.rst
> +++ b/Documentation/media/kapi/v4l2-dev.rst
> @@ -196,11 +196,18 @@ device.
>  Which device is registered depends on the type argument. The following
>  types exist:
>  
> -- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices
> -- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed 
> captions, teletext)
> -- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners
> -- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners
> -- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors
> +==    
> ==
> +:c:type:`vfl_devnode_type` Device nameUsage
> +==    
> ==
> +``VFL_TYPE_GRABBER``   ``/dev/videoX``   for video input/output 
> devices
> +``VFL_TYPE_VBI``   ``/dev/vbiX`` for vertical blank data 
> (i.e.
> +  closed captions, teletext)
> +``VFL_TYPE_RADIO`` ``/dev/radioX``   for radio tuners
> +``VFL_TYPE_SUBDEV````/dev/v4l-subdevX``  for V4L2 subdevices
> +``VFL_TYPE_SDR``   ``/dev/swradioX`` for Software Defined Radio
> +  (SDR) tuners
> +``VFL_TYPE_TOUCH`` ``/dev/v4l-touchX``   for touch sensors
> +==    
> ==
>  
>  The last argument gives you a certain amount of control over the device
>  device node number used (i.e. the X in ``videoX``). Normally you will pass -1
> diff --git a/drivers/media/pci/cx88/cx88-blackbird.c 
> b/drivers/media/pci/cx88/cx88-blackbird.c
> index e3101f04941c..0e0952e60795 100644
> --- a/drivers/media/pci/cx88/cx88-blackbird.c
> +++ b/drivers/media/pci/cx88/cx88-blackbird.c
> @@ -805,8 +805,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
>  
>   strcpy(cap->driver, "cx88_blackbird");
>   sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
> - cx88_querycap(file, core, cap);
> - return 0;
> + return cx88_querycap(file, core, cap);
>  }
>  
>  static int vidioc_enum_fmt_vid_cap(struct file *file, void  *priv,
> diff --git a/drivers/media/pci/cx88/cx88-video.c 
> b/drivers/media/pci/cx88/cx88-video.c
> index 7d25ecd4404b..9be682cdb644 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -806,8 +806,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
> *priv,
>   return 0;
>  }
>  
> -void cx88_querycap(struct file *file, struct cx88_core *core,
> -struct v4l2_capability *cap)
> +int cx88_querycap(struct file *file, struct cx88_core *core,
> +   struct v4l2_capability *cap)
>  {
>   struct video_device *vdev = video_devdata(file);
>  
> @@ -825,11 +825,14 @@ void cx88_querycap(struct file *file, struct cx88_core 
> *core,
>   case VFL_TYPE_VBI:
>   cap->device_caps |= V4L2_CAP_VBI_CAPTURE;
>   break;
> + default:
> + return -EINVAL;
>   }
>   cap->capabilities = cap->device_caps | V4L2_CAP_VIDEO_CAPTURE |
>   V4L2_CAP_VBI_CAPTURE | V4L2_CAP_DEVICE_CAPS;
>   if (core->board.radio.type == CX88_RADIO)
>   cap->capabilities |= V4L2_CAP_RADIO;
> + return 0;
>  }
>  EXPORT_SYMBOL(cx88_querycap);
>  
> @@ -841,8 +844,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
>  
>   strcpy(cap->driver, "cx8800");
>   sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
> - cx88_querycap(file, core, cap);
> - return 0;
> + return cx88_querycap(file, core, cap);
>  }
>  
>  static int 

Re: [PATCH 04/24] media: v4l2-mediabus: convert flags to enums and document them

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> There is a mess with media bus flags: there are two sets of
> flags, one used by parallel and ITU-R BT.656 outputs,
> and another one for CSI2.
> 
> Depending on the type, the same bit has different meanings.
> 
> That's very confusing, and counter-intuitive. So, split them
> into two sets of flags, inside an enum.
> 
> This way, it becomes clearer that there are two separate sets
> of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
> need a different set of flags.
> 
> As a side effect, enums can be documented via kernel-docs,
> so there will be an improvement at flags documentation.
> 
> Unfortunately, soc_camera and pxa_camera do a mess with
> the flags, using either one set of flags without proper
> checks about the type. That could be fixed, but, as both drivers
> are obsolete and in the process of cleanings, I opted to just
> keep the behavior, using an unsigned int inside those two
> drivers.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Nice cleanup.

Regards,

Hans

Re: [PATCH v2 21/25] media: lirc: introduce LIRC_SET_POLL_MODE

[Hans Verkuil]

On 05/10/17 10:45, Sean Young wrote:
> If you want to poll for both decoded scancodes and raw IR, then this
> ioctl will help you.

I don't get the point of this. You can be in one mode at a time anyway,
so why not just poll for the current mode?

> 
> int fd = open("/dev/lirc0", O_RDONLY | O_NONBLOCK);
> 
> for (;;) {
>   unsigned mode = LIRC_MODE_SCANCODE | LIRC_MODE_MODE2;
>   ioctl(fd, LIRC_SET_POLL_MODE, );
>   poll(&((struct pollfd){ .fd = fd, .events = POLLIN }), 1, -1);
>   mode = LIRC_MODE_SCANCODE;
>   ioctl(fd, LIRC_SET_REC_MODE, );

Hold on, in a comment below I read that rec_mode stands for 'recording mode'.
Is that right, or should it be 'receive mode'?

>   struct lirc_scancode sc;
>   if (read(fd, , sizeof(sc)) == sizeof(sc)) {
>   printf("scancode protocol:%d scancode:%llx\n",
>   sc.rc_proto, sc.scancode);
>   }
>   mode = LIRC_MODE_MODE2;
>   ioctl(fd, LIRC_SET_REC_MODE, );
>   unsigned sample;
>   if (read(fd, , sizeof(sample)) == sizeof(sample)) {
>   if (LIRC_IS_SPACE(sample))
>   printf("space %u\n", LIRC_VAL(sample)));
>   if (LIRC_IS_PULSE(sample))
>   printf("pulse %u\n", LIRC_VAL(sample)));
>   }
> }
> 
> Note that LIRC_SET_REC_MODE will also affect the poll mode, so you
> must set it again before calling poll.
> 
> Signed-off-by: Sean Young 
> ---
>  Documentation/media/uapi/rc/lirc-func.rst  |  1 +
>  Documentation/media/uapi/rc/lirc-set-poll-mode.rst | 45 
> ++
>  drivers/media/rc/ir-lirc-codec.c   | 19 +++--
>  drivers/media/rc/lirc_dev.c|  1 +
>  include/media/rc-core.h|  3 ++
>  5 files changed, 65 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/media/uapi/rc/lirc-set-poll-mode.rst
> 
> diff --git a/Documentation/media/uapi/rc/lirc-func.rst 
> b/Documentation/media/uapi/rc/lirc-func.rst
> index ddb4620de294..a09fb03f6722 100644
> --- a/Documentation/media/uapi/rc/lirc-func.rst
> +++ b/Documentation/media/uapi/rc/lirc-func.rst
> @@ -25,3 +25,4 @@ LIRC Function Reference
>  lirc-set-rec-timeout-reports
>  lirc-set-measure-carrier-mode
>  lirc-set-wideband-receiver
> +lirc-set-poll-mode
> diff --git a/Documentation/media/uapi/rc/lirc-set-poll-mode.rst 
> b/Documentation/media/uapi/rc/lirc-set-poll-mode.rst
> new file mode 100644
> index ..ce5043e8acba
> --- /dev/null
> +++ b/Documentation/media/uapi/rc/lirc-set-poll-mode.rst
> @@ -0,0 +1,45 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _lirc_set_poll_mode:
> +
> +**
> +ioctls LIRC_SET_POLL_MODE
> +**
> +
> +Name
> +
> +
> +LIRC_SET_POLL_MODE - Set LIRC modes to use for poll
> +
> +Synopsis
> +
> +
> +.. c:function:: int ioctl( int fd, LIRC_SET_POLL_MODE, __u32 modes)
> + :name: LIRC_SET_POLL_MODE
> +
> +Arguments
> +=
> +
> +``fd``
> +File descriptor returned by open().
> +
> +``modes``
> +Bitmask with enabled poll lirc modes
> +
> +Description
> +===
> +
> +Set lirc modes for which read readiness is reported by poll. Only
> +:ref:`LIRC_MODE_MODE2 ` and
> +:ref:`LIRC_MODE_SCANCODE ` are supported. Poll
> +can report read readiness for both modes if you bitwise or them together.
> +Use :ref:`lirc_get_features` to find out which modes the driver supports.
> +
> +Note that using :ref:`lirc_set_rec_mode` resets the poll mode.
> +
> +Return Value
> +
> +
> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> +appropriately. The generic error codes are described at the
> +:ref:`Generic Error Codes ` chapter.
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index 2544ddc078ca..1f1811c080af 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -353,6 +353,17 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
> int cmd,
>   return -EINVAL;
>  
>   dev->rec_mode = val;
> + dev->poll_mode = val;
> + return 0;
> +
> + case LIRC_SET_POLL_MODE:
> + if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
> + return -ENOTTY;
> +
> + if (val & ~(LIRC_MODE_MODE2 | LIRC_MODE_SCANCODE))
> + return -EINVAL;
> +
> + dev->poll_mode = val;
>   return 0;
>  
>   case LIRC_GET_SEND_MODE:
> @@ -495,13 +506,13 @@ static unsigned int ir_lirc_poll(struct file *file,
>   if (!rcdev->registered) {
>   events = POLLHUP | POLLERR;
>   } else if (rcdev->driver_type != RC_DRIVER_IR_RAW_TX) {
> - if (rcdev->rec_mode == LIRC_MODE_SCANCODE &&
> + if ((rcdev->poll_mode & LIRC_MODE_SCANCODE) &&
>   

Re: [PATCH] media: v4l2-tpg: use __u16 instead of int for struct tpg_rbg_color16

[Hans Verkuil]

On 09/10/17 12:23, Mauro Carvalho Chehab wrote:
> Despite the struct says "color16", it was actually using 32 bits
> for each color. Fix it.
> 
> Suggested-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
> 
> Should come after this patch series:
> V4L2 kAPI cleanups and documentation improvements part 2
> 
> 
>  include/media/tpg/v4l2-tpg.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/media/tpg/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
> index bc0b38440719..823fadede7bf 100644
> --- a/include/media/tpg/v4l2-tpg.h
> +++ b/include/media/tpg/v4l2-tpg.h
> @@ -32,7 +32,7 @@ struct tpg_rbg_color8 {
>  };
>  
>  struct tpg_rbg_color16 {
> - int r, g, b;
> + __u16 r, g, b;
>  };
>  
>  enum tpg_color {
> 

Re: [PATCH 24/24] media: v4l2-tpg.h: rename color structs

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> The color structs right now are just "color" and "color16".
> That may lead into conflicts, and don't define precisely what
> they meant. As those are used by two drivers (vivid and vimc),
> this is even on a somewhat public header!
> 
> So rename them to:
>   color ->  tpg_rbg_color8
>   color16 ->  tpg_rbg_color16
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c | 6 +++---
>  include/media/tpg/v4l2-tpg.h| 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
> index 95b26f6a0d54..43180204fab2 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
> @@ -39,7 +39,7 @@
>  #include 
>  
>  /* sRGB colors with range [0-255] */
> -const struct color tpg_colors[TPG_COLOR_MAX] = {
> +const struct tpg_rbg_color8 tpg_colors[TPG_COLOR_MAX] = {
>   /*
>* Colors to test colorspace conversion: converting these colors
>* to other colorspaces will never lead to out-of-gamut colors.
> @@ -597,7 +597,7 @@ const unsigned short tpg_linear_to_rec709[255 * 16 + 1] = 
> {
>  };
>  
>  /* Generated table */
> -const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 
> 1][V4L2_XFER_FUNC_SMPTE2084 + 1][TPG_COLOR_CSC_BLACK + 1] = {
> +const struct tpg_rbg_color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 
> 1][V4L2_XFER_FUNC_SMPTE2084 + 1][TPG_COLOR_CSC_BLACK + 1] = {
>   [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_709][0] = { 2939, 2939, 2939 
> },
>   [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_709][1] = { 2953, 2963, 586 
> },
>   [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_709][2] = { 0, 2967, 2937 },
> @@ -1392,7 +1392,7 @@ int main(int argc, char **argv)
>   printf("\n};\n\n");
>  
>   printf("/* Generated table */\n");
> - printf("const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 
> 1][V4L2_XFER_FUNC_SMPTE2084 + 1][TPG_COLOR_CSC_BLACK + 1] = {\n");
> + printf("const struct tpg_rbg_color16 
> tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1][V4L2_XFER_FUNC_SMPTE2084 + 
> 1][TPG_COLOR_CSC_BLACK + 1] = {\n");
>   for (c = 0; c <= V4L2_COLORSPACE_DCI_P3; c++) {
>   for (x = 1; x <= V4L2_XFER_FUNC_SMPTE2084; x++) {
>   for (i = 0; i <= TPG_COLOR_CSC_BLACK; i++) {
> diff --git a/include/media/tpg/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
> index 028d81182011..bc0b38440719 100644
> --- a/include/media/tpg/v4l2-tpg.h
> +++ b/include/media/tpg/v4l2-tpg.h
> @@ -27,11 +27,11 @@
>  #include 
>  #include 
>  
> -struct color {
> +struct tpg_rbg_color8 {
>   unsigned char r, g, b;
>  };
>  
> -struct color16 {
> +struct tpg_rbg_color16 {
>   int r, g, b;
>  };
>  
> @@ -65,10 +65,10 @@ enum tpg_color {
>   TPG_COLOR_MAX = TPG_COLOR_RAMP + 256
>  };
>  
> -extern const struct color tpg_colors[TPG_COLOR_MAX];
> +extern const struct tpg_rbg_color8 tpg_colors[TPG_COLOR_MAX];
>  extern const unsigned short tpg_rec709_to_linear[255 * 16 + 1];
>  extern const unsigned short tpg_linear_to_rec709[255 * 16 + 1];
> -extern const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1]
> +extern const struct tpg_rbg_color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 
> 1]
> [V4L2_XFER_FUNC_SMPTE2084 + 1]
> [TPG_COLOR_CSC_BLACK + 1];
>  enum tpg_pattern {
> 

Re: [PATCH 23/24] media: v4l2-tpg*.h: move headers to include/media/tpg and merge them

[Hans Verkuil]

On 09/10/17 12:19, Mauro Carvalho Chehab wrote:
> The v4l2-tpg*.h headers are meant to be used only internally by
> vivid and vimc. There's no sense keeping them together with the
> V4L2 kAPI headers. Also, one header includes the other as they're
> meant to be used together. So, merge them.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c |  2 +-
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   |  2 +-
>  drivers/media/platform/vimc/vimc-sensor.c   |  2 +-
>  drivers/media/platform/vivid/vivid-core.h   |  2 +-
>  include/media/{ => tpg}/v4l2-tpg.h  | 45 +++-
>  include/media/v4l2-tpg-colors.h | 68 
> -
>  6 files changed, 48 insertions(+), 73 deletions(-)
>  rename include/media/{ => tpg}/v4l2-tpg.h (93%)
>  delete mode 100644 include/media/v4l2-tpg-colors.h
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
> index 5b5f95c38fe1..95b26f6a0d54 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
> @@ -36,7 +36,7 @@
>   */
>  
>  #include 
> -#include 
> +#include 
>  
>  /* sRGB colors with range [0-255] */
>  const struct color tpg_colors[TPG_COLOR_MAX] = {
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index a772976cfe26..f218b336a3ac 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -21,7 +21,7 @@
>   */
>  
>  #include 
> -#include 
> +#include 
>  
>  /* Must remain in sync with enum tpg_pattern */
>  const char * const tpg_pattern_strings[] = {
> diff --git a/drivers/media/platform/vimc/vimc-sensor.c 
> b/drivers/media/platform/vimc/vimc-sensor.c
> index 02e68c8fc02b..8d2691817aa5 100644
> --- a/drivers/media/platform/vimc/vimc-sensor.c
> +++ b/drivers/media/platform/vimc/vimc-sensor.c
> @@ -23,7 +23,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "vimc-common.h"
>  
> diff --git a/drivers/media/platform/vivid/vivid-core.h 
> b/drivers/media/platform/vivid/vivid-core.h
> index 5cdf95bdc4d1..36802947a4b0 100644
> --- a/drivers/media/platform/vivid/vivid-core.h
> +++ b/drivers/media/platform/vivid/vivid-core.h
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include "vivid-rds-gen.h"
>  #include "vivid-vbi-gen.h"
>  
> diff --git a/include/media/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
> similarity index 93%
> rename from include/media/v4l2-tpg.h
> rename to include/media/tpg/v4l2-tpg.h
> index 13e49d85cae3..028d81182011 100644
> --- a/include/media/v4l2-tpg.h
> +++ b/include/media/tpg/v4l2-tpg.h
> @@ -26,8 +26,51 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
> +struct color {
> + unsigned char r, g, b;
> +};
> +
> +struct color16 {
> + int r, g, b;
> +};
> +
> +enum tpg_color {
> + TPG_COLOR_CSC_WHITE,
> + TPG_COLOR_CSC_YELLOW,
> + TPG_COLOR_CSC_CYAN,
> + TPG_COLOR_CSC_GREEN,
> + TPG_COLOR_CSC_MAGENTA,
> + TPG_COLOR_CSC_RED,
> + TPG_COLOR_CSC_BLUE,
> + TPG_COLOR_CSC_BLACK,
> + TPG_COLOR_75_YELLOW,
> + TPG_COLOR_75_CYAN,
> + TPG_COLOR_75_GREEN,
> + TPG_COLOR_75_MAGENTA,
> + TPG_COLOR_75_RED,
> + TPG_COLOR_75_BLUE,
> + TPG_COLOR_100_WHITE,
> + TPG_COLOR_100_YELLOW,
> + TPG_COLOR_100_CYAN,
> + TPG_COLOR_100_GREEN,
> + TPG_COLOR_100_MAGENTA,
> + TPG_COLOR_100_RED,
> + TPG_COLOR_100_BLUE,
> + TPG_COLOR_100_BLACK,
> + TPG_COLOR_TEXTFG,
> + TPG_COLOR_TEXTBG,
> + TPG_COLOR_RANDOM,
> + TPG_COLOR_RAMP,
> + TPG_COLOR_MAX = TPG_COLOR_RAMP + 256
> +};
> +
> +extern const struct color tpg_colors[TPG_COLOR_MAX];
> +extern const unsigned short tpg_rec709_to_linear[255 * 16 + 1];
> +extern const unsigned short tpg_linear_to_rec709[255 * 16 + 1];
> +extern const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1]
> +   [V4L2_XFER_FUNC_SMPTE2084 + 1]
> +   [TPG_COLOR_CSC_BLACK + 1];
>  enum tpg_pattern {
>   TPG_PAT_75_COLORBAR,
>   TPG_PAT_100_COLORBAR,
> diff --git a/include/media/v4l2-tpg-colors.h b/include/media/v4l2-tpg-colors.h
> deleted file mode 100644
> index 2a88d1fae0cd..
> --- a/include/media/v4l2-tpg-colors.h
> +++ /dev/null
> @@ -1,68 +0,0 @@
> -/*
> - * v4l2-tpg-colors.h - Color definitions for the test pattern generator
> - *
> - * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
> - *
> - * This program is free software; you may redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; version 2 of the 

Re: [PATCH v2 20/25] media: lirc: document LIRC_MODE_SCANCODE

[Hans Verkuil]

On 05/10/17 10:45, Sean Young wrote:
> Lirc supports a new mode which requires documentation.
> 
> Signed-off-by: Sean Young 
> ---
>  Documentation/media/lirc.h.rst.exceptions  | 26 
> ++
>  Documentation/media/uapi/rc/lirc-dev-intro.rst | 26 
> ++
>  Documentation/media/uapi/rc/lirc-get-features.rst  | 16 +
>  Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |  5 +++--
>  Documentation/media/uapi/rc/lirc-get-send-mode.rst |  3 ++-
>  Documentation/media/uapi/rc/lirc-read.rst  | 14 
>  Documentation/media/uapi/rc/lirc-write.rst | 16 ++---
>  7 files changed, 96 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/media/lirc.h.rst.exceptions 
> b/Documentation/media/lirc.h.rst.exceptions
> index 63ba1d341905..c6e3a35d2c4e 100644
> --- a/Documentation/media/lirc.h.rst.exceptions
> +++ b/Documentation/media/lirc.h.rst.exceptions
> @@ -32,6 +32,32 @@ ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
>  
>  ignore ioctl LIRC_GET_LENGTH
>  
> +# rc protocols
> +
> +ignore symbol RC_PROTO_UNKNOWN
> +ignore symbol RC_PROTO_OTHER
> +ignore symbol RC_PROTO_RC5
> +ignore symbol RC_PROTO_RC5X_20
> +ignore symbol RC_PROTO_RC5_SZ
> +ignore symbol RC_PROTO_JVC
> +ignore symbol RC_PROTO_SONY12
> +ignore symbol RC_PROTO_SONY15
> +ignore symbol RC_PROTO_SONY20
> +ignore symbol RC_PROTO_NEC
> +ignore symbol RC_PROTO_NECX
> +ignore symbol RC_PROTO_NEC32
> +ignore symbol RC_PROTO_SANYO
> +ignore symbol RC_PROTO_MCIR2_KBD
> +ignore symbol RC_PROTO_MCIR2_MSE
> +ignore symbol RC_PROTO_RC6_0
> +ignore symbol RC_PROTO_RC6_6A_20
> +ignore symbol RC_PROTO_RC6_6A_24
> +ignore symbol RC_PROTO_RC6_6A_32
> +ignore symbol RC_PROTO_RC6_MCE
> +ignore symbol RC_PROTO_SHARP
> +ignore symbol RC_PROTO_XMP
> +ignore symbol RC_PROTO_CEC
> +
>  # Undocumented macros
>  
>  ignore define PULSE_BIT
> diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
> b/Documentation/media/uapi/rc/lirc-dev-intro.rst
> index a3fa3c1ef169..70c82b2879ff 100644
> --- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
> +++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
> @@ -36,6 +36,32 @@ LIRC modes
>  LIRC supports some modes of receiving and sending IR codes, as shown
>  on the following table.

A general note: I don't think it is defined anywhere in the documentation what
'LIRC' stands for. Might be useful to add :-)

>  
> +.. _lirc-mode-scancode:
> +.. _lirc-scancode-flag-toggle:
> +.. _lirc-scancode-flag-repeat:
> +
> +``LIRC_MODE_SCANCODE``
> +
> +This mode is for both sending and receiving IR.
> +
> +For transmitting (aka sending), create a ``struct lirc_scancode`` with
> +the desired scancode set in the ``scancode`` member, ``rc_proto`` set
> +the IR protocol, and all other members set to 0. Write this struct to
> +the lirc device.
> +
> +For receiving, you read ``struct lirc_scancode`` from the lirc device,
> +with ``scancode`` set to the received scancode in the IR protocol
> +``rc_proto``. The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set
> +if the toggle bit is set in protocols that support it (e.g. rc-5 and 
> rc-6),

Is the meaning of 'toggle' defined anywhere? I'm not sure what it means myself.

> +or ``LIRC_SCANCODE_FLAG_REPEAT`` for when a repeat is received for 
> protocols
> +that support it (e.g. nec).
> +
> +The ``timestamp`` field is filled with the time nanoseconds
> +(in ``CLOCK_MONOTONIC``) when the scancode was decoded.
> +
> +An ``enum rc_proto`` in the :ref:`lirc_header` lists all the supported
> +IR protocols.
> +
>  .. _lirc-mode-mode2:
>  
>  ``LIRC_MODE_MODE2``
> diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
> b/Documentation/media/uapi/rc/lirc-get-features.rst
> index 50c2c26d8e89..3ee44067de63 100644
> --- a/Documentation/media/uapi/rc/lirc-get-features.rst
> +++ b/Documentation/media/uapi/rc/lirc-get-features.rst
> @@ -64,6 +64,14 @@ LIRC features
>  
>  Unused. Kept just to avoid breaking uAPI.
>  
> +.. _LIRC-CAN-REC-SCANCODE:
> +
> +``LIRC_CAN_REC_SCANCODE``

Wouldn't LIRC_CAN_RECEIVE_SCANCODE be better?

I misread 'REC' as 'record' :-)

I thought about using RCV as the abbreviation, but REC is used elsewhere
already (rec_mode).

> +
> +The driver is capable of receiving using
> +:ref:`LIRC_MODE_SCANCODE `.
> +
> +
>  .. _LIRC-CAN-SET-SEND-CARRIER:
>  
>  ``LIRC_CAN_SET_SEND_CARRIER``
> @@ -171,6 +179,14 @@ LIRC features
>  
>  Unused. Kept just to avoid breaking uAPI.
>  
> +.. _LIRC-CAN-SEND-SCANCODE:
> +
> +``LIRC_CAN_SEND_SCANCODE``
> +
> +The driver supports sending (also called as IR blasting or IR TX) using
> +:ref:`LIRC_MODE_SCANCODE `.
> +
> +
>  Return Value
>  
>  
> diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst 
> b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> index b89de9add921..92c543e1815e 100644
> --- 

[PATCH] media: v4l2-tpg: use __u16 instead of int for struct tpg_rbg_color16

[Mauro Carvalho Chehab]

Despite the struct says "color16", it was actually using 32 bits
for each color. Fix it.

Suggested-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
---

Should come after this patch series:
V4L2 kAPI cleanups and documentation improvements part 2


 include/media/tpg/v4l2-tpg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/media/tpg/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
index bc0b38440719..823fadede7bf 100644
--- a/include/media/tpg/v4l2-tpg.h
+++ b/include/media/tpg/v4l2-tpg.h
@@ -32,7 +32,7 @@ struct tpg_rbg_color8 {
 };
 
 struct tpg_rbg_color16 {
-   int r, g, b;
+   __u16 r, g, b;
 };
 
 enum tpg_color {
-- 
2.13.6

[PATCH 10/24] media: v4l2-subdev: use kernel-doc markups to document subdev flags

[Mauro Carvalho Chehab]

Right now, those are documented together with the subdev struct,
instead of together with the definitions.

Convert the definitions to an enum, use BIT() macros and document
it at its right place.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index e83872078376..6286c69a12ba 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -18,6 +18,7 @@
 #define _V4L2_SUBDEV_H
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -734,14 +735,23 @@ struct v4l2_subdev_internal_ops {
 
 #define V4L2_SUBDEV_NAME_SIZE 32
 
-/* Set this flag if this subdev is a i2c device. */
-#define V4L2_SUBDEV_FL_IS_I2C  (1U << 0)
-/* Set this flag if this subdev is a spi device. */
-#define V4L2_SUBDEV_FL_IS_SPI  (1U << 1)
-/* Set this flag if this subdev needs a device node. */
-#define V4L2_SUBDEV_FL_HAS_DEVNODE (1U << 2)
-/* Set this flag if this subdev generates events. */
-#define V4L2_SUBDEV_FL_HAS_EVENTS  (1U << 3)
+/**
+ * enum v4l2_subdev_flags - flags used to describe a sub-device
+ * at  v4l2_subdev.
+ *
+ * @V4L2_SUBDEV_FL_IS_I2C: set this flag if this subdev is an I2C device;
+ * @V4L2_SUBDEV_FL_IS_SPI: set this flag if this subdev is a SPI device;
+ * @V4L2_SUBDEV_FL_HAS_DEVNODE: set this flag if this subdev needs
+ * a device node;
+ * @V4L2_SUBDEV_FL_HAS_EVENTS: set this flag if this subdev
+ *generates events.
+ */
+enum v4l2_subdev_flags {
+   V4L2_SUBDEV_FL_IS_I2C   = BIT(0),
+   V4L2_SUBDEV_FL_IS_SPI   = BIT(1),
+   V4L2_SUBDEV_FL_HAS_DEVNODE  = BIT(2),
+   V4L2_SUBDEV_FL_HAS_EVENTS   = BIT(3),
+};
 
 struct regulator_bulk_data;
 
@@ -767,13 +777,7 @@ struct v4l2_subdev_platform_data {
  * @owner: The owner is the same as the driver's  device owner.
  * @owner_v4l2_dev: true if the >owner matches the owner of @v4l2_dev->dev
  * ownner. Initialized by v4l2_device_register_subdev().
- * @flags: subdev flags. Can be:
- *   %V4L2_SUBDEV_FL_IS_I2C - Set this flag if this subdev is a i2c device;
- *   %V4L2_SUBDEV_FL_IS_SPI - Set this flag if this subdev is a spi device;
- *   %V4L2_SUBDEV_FL_HAS_DEVNODE - Set this flag if this subdev needs a
- *   device node;
- *   %V4L2_SUBDEV_FL_HAS_EVENTS -  Set this flag if this subdev generates
- *   events.
+ * @flags: subdev flags, as defined by  v4l2_subdev_flags.
  *
  * @v4l2_dev: pointer to struct _device
  * @ops: pointer to struct _subdev_ops
@@ -808,7 +812,7 @@ struct v4l2_subdev {
struct list_head list;
struct module *owner;
bool owner_v4l2_dev;
-   u32 flags;
+   enum v4l2_subdev_flags flags;
struct v4l2_device *v4l2_dev;
const struct v4l2_subdev_ops *ops;
const struct v4l2_subdev_internal_ops *internal_ops;
-- 
2.13.6

[PATCH 18/24] media: vb2-core: use bitops for bits

[Mauro Carvalho Chehab]

Use the existing macros to identify vb2_io_modes bits.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/videobuf2-core.h | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 5f4df060affb..0308d8439049 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define VB2_MAX_FRAME  (32)
 #define VB2_MAX_PLANES (8)
@@ -191,11 +192,11 @@ struct vb2_plane {
  * @VB2_DMABUF:driver supports DMABUF with streaming API
  */
 enum vb2_io_modes {
-   VB2_MMAP= (1 << 0),
-   VB2_USERPTR = (1 << 1),
-   VB2_READ= (1 << 2),
-   VB2_WRITE   = (1 << 3),
-   VB2_DMABUF  = (1 << 4),
+   VB2_MMAP= BIT(0),
+   VB2_USERPTR = BIT(1),
+   VB2_READ= BIT(2),
+   VB2_WRITE   = BIT(3),
+   VB2_DMABUF  = BIT(4),
 };
 
 /**
-- 
2.13.6

[PATCH 08/24] media: v4l2-dev: document VFL_DIR_* direction defines

[Mauro Carvalho Chehab]

The V4L_DIR_* direction flags document the direction for a
V4L2 device node. Convert them to enum and document.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-dev.h | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index f182b47dfd71..87dac58c7799 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -40,11 +40,21 @@ enum vfl_devnode_type {
 };
 #define VFL_TYPE_MAX VFL_TYPE_TOUCH
 
-/* Is this a receiver, transmitter or mem-to-mem? */
-/* Ignored for VFL_TYPE_SUBDEV. */
-#define VFL_DIR_RX 0
-#define VFL_DIR_TX 1
-#define VFL_DIR_M2M2
+/**
+ * enum  vfl_direction - Identifies if a  video_device corresponds
+ * to a receiver, a transmitter or a mem-to-mem device.
+ *
+ * @VFL_DIR_RX:device is a receiver.
+ * @VFL_DIR_TX:device is a transmitter.
+ * @VFL_DIR_M2M:   device is a memory to memory device.
+ *
+ * Note: Ignored if  vfl_devnode_type is %VFL_TYPE_SUBDEV.
+ */
+enum vfl_devnode_direction {
+   VFL_DIR_RX,
+   VFL_DIR_TX,
+   VFL_DIR_M2M,
+};
 
 struct v4l2_ioctl_callbacks;
 struct video_device;
@@ -249,7 +259,7 @@ struct video_device
/* device info */
char name[32];
enum vfl_devnode_type vfl_type;
-   int vfl_dir;
+   enum vfl_devnode_direction vfl_dir;
int minor;
u16 num;
unsigned long flags;
-- 
2.13.6

[PATCH 01/24] media: v4l2-dev.h: add kernel-doc to two macros

[Mauro Carvalho Chehab]

There are two macros at v4l2-dev.h that aren't documented.

Document them, for completeness.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-dev.h | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index e657614521e3..de1a1453cfd9 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -260,9 +260,21 @@ struct video_device
struct mutex *lock;
 };
 
-#define media_entity_to_video_device(__e) \
-   container_of(__e, struct video_device, entity)
-/* dev to video-device */
+/**
+ * media_entity_to_video_device - Returns a  video_device from
+ * the  media_entity embedded on it.
+ *
+ * @entity: pointer to  media_entity
+ */
+#define media_entity_to_video_device(entity) \
+   container_of(entity, struct video_device, entity)
+
+/**
+ * media_entity_to_video_device - Returns a  video_device from
+ * the  device embedded on it.
+ *
+ * @cd: pointer to  device
+ */
 #define to_video_device(cd) container_of(cd, struct video_device, dev)
 
 /**
-- 
2.13.6

[PATCH 15/24] media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro

[Mauro Carvalho Chehab]

The __V4L2_SUBDEV_MK_GET_TRY() macro is used to define
3 functions that have the same arguments. The code of those
functions is simple enough to just declare them, de-obfuscating
the code.

While here, replace BUG_ON() by WARN_ON() as there's no reason
why to panic the Kernel if this fails.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1f34045f07ce..35c4476c56ee 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -897,19 +897,32 @@ struct v4l2_subdev_fh {
container_of(fh, struct v4l2_subdev_fh, vfh)
 
 #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
-#define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)  \
-   static inline struct rtype *\
-   fun_name(struct v4l2_subdev *sd,\
-struct v4l2_subdev_pad_config *cfg,\
-unsigned int pad)  \
-   {   \
-   BUG_ON(pad >= sd->entity.num_pads); \
-   return [pad].field_name;\
-   }
+static inline struct v4l2_mbus_framefmt
+*v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
+   struct v4l2_subdev_pad_config *cfg,
+   unsigned int pad)
+{
+   WARN_ON(pad >= sd->entity.num_pads);
+   return [pad].try_fmt;
+}
 
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, v4l2_subdev_get_try_format, 
try_fmt)
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_crop, try_crop)
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_compose, try_compose)
+static inline struct v4l2_rect
+*v4l2_subdev_get_try_crop(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad)
+{
+   WARN_ON(pad >= sd->entity.num_pads);
+   return [pad].try_crop;
+}
+
+static inline struct v4l2_rect
+*v4l2_subdev_get_try_compose(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg,
+unsigned int pad)
+{
+   WARN_ON(pad >= sd->entity.num_pads);
+   return [pad].try_compose;
+}
 #endif
 
 extern const struct v4l2_file_operations v4l2_subdev_fops;
-- 
2.13.6

[PATCH 24/24] media: v4l2-tpg.h: rename color structs

[Mauro Carvalho Chehab]

The color structs right now are just "color" and "color16".
That may lead into conflicts, and don't define precisely what
they meant. As those are used by two drivers (vivid and vimc),
this is even on a somewhat public header!

So rename them to:
color ->  tpg_rbg_color8
color16 ->  tpg_rbg_color16

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c | 6 +++---
 include/media/tpg/v4l2-tpg.h| 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
index 95b26f6a0d54..43180204fab2 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
@@ -39,7 +39,7 @@
 #include 
 
 /* sRGB colors with range [0-255] */
-const struct color tpg_colors[TPG_COLOR_MAX] = {
+const struct tpg_rbg_color8 tpg_colors[TPG_COLOR_MAX] = {
/*
 * Colors to test colorspace conversion: converting these colors
 * to other colorspaces will never lead to out-of-gamut colors.
@@ -597,7 +597,7 @@ const unsigned short tpg_linear_to_rec709[255 * 16 + 1] = {
 };
 
 /* Generated table */
-const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 
1][V4L2_XFER_FUNC_SMPTE2084 + 1][TPG_COLOR_CSC_BLACK + 1] = {
+const struct tpg_rbg_color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 
1][V4L2_XFER_FUNC_SMPTE2084 + 1][TPG_COLOR_CSC_BLACK + 1] = {
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_709][0] = { 2939, 2939, 2939 
},
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_709][1] = { 2953, 2963, 586 
},
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_709][2] = { 0, 2967, 2937 },
@@ -1392,7 +1392,7 @@ int main(int argc, char **argv)
printf("\n};\n\n");
 
printf("/* Generated table */\n");
-   printf("const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 
1][V4L2_XFER_FUNC_SMPTE2084 + 1][TPG_COLOR_CSC_BLACK + 1] = {\n");
+   printf("const struct tpg_rbg_color16 
tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1][V4L2_XFER_FUNC_SMPTE2084 + 
1][TPG_COLOR_CSC_BLACK + 1] = {\n");
for (c = 0; c <= V4L2_COLORSPACE_DCI_P3; c++) {
for (x = 1; x <= V4L2_XFER_FUNC_SMPTE2084; x++) {
for (i = 0; i <= TPG_COLOR_CSC_BLACK; i++) {
diff --git a/include/media/tpg/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
index 028d81182011..bc0b38440719 100644
--- a/include/media/tpg/v4l2-tpg.h
+++ b/include/media/tpg/v4l2-tpg.h
@@ -27,11 +27,11 @@
 #include 
 #include 
 
-struct color {
+struct tpg_rbg_color8 {
unsigned char r, g, b;
 };
 
-struct color16 {
+struct tpg_rbg_color16 {
int r, g, b;
 };
 
@@ -65,10 +65,10 @@ enum tpg_color {
TPG_COLOR_MAX = TPG_COLOR_RAMP + 256
 };
 
-extern const struct color tpg_colors[TPG_COLOR_MAX];
+extern const struct tpg_rbg_color8 tpg_colors[TPG_COLOR_MAX];
 extern const unsigned short tpg_rec709_to_linear[255 * 16 + 1];
 extern const unsigned short tpg_linear_to_rec709[255 * 16 + 1];
-extern const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1]
+extern const struct tpg_rbg_color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1]
  [V4L2_XFER_FUNC_SMPTE2084 + 1]
  [TPG_COLOR_CSC_BLACK + 1];
 enum tpg_pattern {
-- 
2.13.6

[PATCH 20/24] media: vb2-core: document remaining functions

[Mauro Carvalho Chehab]

There are several VB2 core functions that aren't documented.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/videobuf2-core.h | 54 +-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index e145f1475ffe..ce795cd0a7cc 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -786,7 +786,28 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, 
void *pb);
 int vb2_core_dqbuf(struct vb2_queue *q, unsigned int *pindex, void *pb,
   bool nonblocking);
 
+/**
+ * vb2_core_streamon() - Implements VB2 stream ON logic
+ *
+ * @q: pointer to  vb2_queue with videobuf2 queue
+ * @type:  type of the queue to be started.
+ * For V4L2, this is defined by  v4l2_buf_type type.
+ *
+ * Should be called from _ioctl_ops->vidioc_streamon ioctl handler of
+ * a driver.
+ */
 int vb2_core_streamon(struct vb2_queue *q, unsigned int type);
+
+/**
+ * vb2_core_streamoff() - Implements VB2 stream OFF logic
+ *
+ * @q: pointer to  vb2_queue with videobuf2 queue
+ * @type:  type of the queue to be started.
+ * For V4L2, this is defined by  v4l2_buf_type type.
+ *
+ * Should be called from _ioctl_ops->vidioc_streamon ioctl handler of
+ * a driver.
+ */
 int vb2_core_streamoff(struct vb2_queue *q, unsigned int type);
 
 /**
@@ -874,6 +895,21 @@ void vb2_queue_error(struct vb2_queue *q);
 int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma);
 
 #ifndef CONFIG_MMU
+/**
+ * vb2_get_unmapped_area - map video buffers into application address space.
+ * @q: pointer to  vb2_queue with videobuf2 queue.
+ * @addr:  memory address.
+ * @len:   buffer size.
+ * @pgoff: page offset.
+ * @flags: memory flags.
+ *
+ * This function is used in noMMU platforms to propose address mapping
+ * for a given buffer. It's intended to be used as a handler for the
+ * _operations->get_unmapped_area operation.
+ *
+ * This is called by the mmap() syscall routines will call this
+ * to get a proposed address for the mapping, when ``!CONFIG_MMU``.
+ */
 unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
unsigned long addr,
unsigned long len,
@@ -882,7 +918,7 @@ unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
 #endif
 
 /**
- * vb2_core_poll() - implements poll userspace operation.
+ * vb2_core_poll() - implements poll syscall() logic.
  * @q: pointer to  vb2_queue with videobuf2 queue.
  * @file:   file argument passed to the poll
  * file operation handler.
@@ -902,8 +938,24 @@ unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
 unsigned int vb2_core_poll(struct vb2_queue *q, struct file *file,
   poll_table *wait);
 
+/**
+ * vb2_read() - implements read() syscall logic.
+ * @q: pointer to  vb2_queue with videobuf2 queue.
+ * @data:  pointed to target userspace buffer
+ * @count: number of bytes to read
+ * @ppos:  file handle position tracking pointer
+ * @nonblock:  mode selector (1 means blocking calls, 0 means nonblocking)
+ */
 size_t vb2_read(struct vb2_queue *q, char __user *data, size_t count,
loff_t *ppos, int nonblock);
+/**
+ * vb2_read() - implements write() syscall logic.
+ * @q: pointer to  vb2_queue with videobuf2 queue.
+ * @data:  pointed to target userspace buffer
+ * @count: number of bytes to write
+ * @ppos:  file handle position tracking pointer
+ * @nonblock:  mode selector (1 means blocking calls, 0 means nonblocking)
+ */
 size_t vb2_write(struct vb2_queue *q, const char __user *data, size_t count,
loff_t *ppos, int nonblock);
 
-- 
2.13.6

[PATCH 17/24] media: v4l2-subdev: fix a typo

[Mauro Carvalho Chehab]

ownner -> owner

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index e215732eed45..345da052618c 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -814,7 +814,7 @@ struct v4l2_subdev_platform_data {
  * @list: List of sub-devices
  * @owner: The owner is the same as the driver's  device owner.
  * @owner_v4l2_dev: true if the >owner matches the owner of @v4l2_dev->dev
- * ownner. Initialized by v4l2_device_register_subdev().
+ * owner. Initialized by v4l2_device_register_subdev().
  * @flags: subdev flags, as defined by  v4l2_subdev_flags.
  *
  * @v4l2_dev: pointer to struct _device
-- 
2.13.6

[PATCH 23/24] media: v4l2-tpg*.h: move headers to include/media/tpg and merge them

[Mauro Carvalho Chehab]

The v4l2-tpg*.h headers are meant to be used only internally by
vivid and vimc. There's no sense keeping them together with the
V4L2 kAPI headers. Also, one header includes the other as they're
meant to be used together. So, merge them.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c |  2 +-
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   |  2 +-
 drivers/media/platform/vimc/vimc-sensor.c   |  2 +-
 drivers/media/platform/vivid/vivid-core.h   |  2 +-
 include/media/{ => tpg}/v4l2-tpg.h  | 45 +++-
 include/media/v4l2-tpg-colors.h | 68 -
 6 files changed, 48 insertions(+), 73 deletions(-)
 rename include/media/{ => tpg}/v4l2-tpg.h (93%)
 delete mode 100644 include/media/v4l2-tpg-colors.h

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
index 5b5f95c38fe1..95b26f6a0d54 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
@@ -36,7 +36,7 @@
  */
 
 #include 
-#include 
+#include 
 
 /* sRGB colors with range [0-255] */
 const struct color tpg_colors[TPG_COLOR_MAX] = {
diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index a772976cfe26..f218b336a3ac 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -21,7 +21,7 @@
  */
 
 #include 
-#include 
+#include 
 
 /* Must remain in sync with enum tpg_pattern */
 const char * const tpg_pattern_strings[] = {
diff --git a/drivers/media/platform/vimc/vimc-sensor.c 
b/drivers/media/platform/vimc/vimc-sensor.c
index 02e68c8fc02b..8d2691817aa5 100644
--- a/drivers/media/platform/vimc/vimc-sensor.c
+++ b/drivers/media/platform/vimc/vimc-sensor.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "vimc-common.h"
 
diff --git a/drivers/media/platform/vivid/vivid-core.h 
b/drivers/media/platform/vivid/vivid-core.h
index 5cdf95bdc4d1..36802947a4b0 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include "vivid-rds-gen.h"
 #include "vivid-vbi-gen.h"
 
diff --git a/include/media/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
similarity index 93%
rename from include/media/v4l2-tpg.h
rename to include/media/tpg/v4l2-tpg.h
index 13e49d85cae3..028d81182011 100644
--- a/include/media/v4l2-tpg.h
+++ b/include/media/tpg/v4l2-tpg.h
@@ -26,8 +26,51 @@
 #include 
 #include 
 #include 
-#include 
 
+struct color {
+   unsigned char r, g, b;
+};
+
+struct color16 {
+   int r, g, b;
+};
+
+enum tpg_color {
+   TPG_COLOR_CSC_WHITE,
+   TPG_COLOR_CSC_YELLOW,
+   TPG_COLOR_CSC_CYAN,
+   TPG_COLOR_CSC_GREEN,
+   TPG_COLOR_CSC_MAGENTA,
+   TPG_COLOR_CSC_RED,
+   TPG_COLOR_CSC_BLUE,
+   TPG_COLOR_CSC_BLACK,
+   TPG_COLOR_75_YELLOW,
+   TPG_COLOR_75_CYAN,
+   TPG_COLOR_75_GREEN,
+   TPG_COLOR_75_MAGENTA,
+   TPG_COLOR_75_RED,
+   TPG_COLOR_75_BLUE,
+   TPG_COLOR_100_WHITE,
+   TPG_COLOR_100_YELLOW,
+   TPG_COLOR_100_CYAN,
+   TPG_COLOR_100_GREEN,
+   TPG_COLOR_100_MAGENTA,
+   TPG_COLOR_100_RED,
+   TPG_COLOR_100_BLUE,
+   TPG_COLOR_100_BLACK,
+   TPG_COLOR_TEXTFG,
+   TPG_COLOR_TEXTBG,
+   TPG_COLOR_RANDOM,
+   TPG_COLOR_RAMP,
+   TPG_COLOR_MAX = TPG_COLOR_RAMP + 256
+};
+
+extern const struct color tpg_colors[TPG_COLOR_MAX];
+extern const unsigned short tpg_rec709_to_linear[255 * 16 + 1];
+extern const unsigned short tpg_linear_to_rec709[255 * 16 + 1];
+extern const struct color16 tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1]
+ [V4L2_XFER_FUNC_SMPTE2084 + 1]
+ [TPG_COLOR_CSC_BLACK + 1];
 enum tpg_pattern {
TPG_PAT_75_COLORBAR,
TPG_PAT_100_COLORBAR,
diff --git a/include/media/v4l2-tpg-colors.h b/include/media/v4l2-tpg-colors.h
deleted file mode 100644
index 2a88d1fae0cd..
--- a/include/media/v4l2-tpg-colors.h
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * v4l2-tpg-colors.h - Color definitions for the test pattern generator
- *
- * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
- *
- * This program is free software; you may redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- 

[PATCH 07/24] media: get rid of i2c-addr.h

[Mauro Carvalho Chehab]

In the past, the same I2C address were used on multiple places.
After I2C rebinding changes, this is no longer needed. So, we
can just get rid of this header, placing the I2C address where
they belong, e. g. either at bttv driver or at tvtuner.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/tda7432.c |  1 -
 drivers/media/i2c/tvaudio.c |  2 --
 drivers/media/pci/bt8xx/bttv-cards.c|  7 +++
 drivers/media/pci/bt8xx/bttv.h  |  1 -
 drivers/media/usb/em28xx/em28xx-cards.c |  1 -
 drivers/media/usb/tm6000/tm6000-cards.c |  1 -
 include/media/i2c-addr.h| 35 -
 include/media/i2c/tvaudio.h | 17 +++-
 8 files changed, 23 insertions(+), 42 deletions(-)
 delete mode 100644 include/media/i2c-addr.h

diff --git a/drivers/media/i2c/tda7432.c b/drivers/media/i2c/tda7432.c
index d87168adee45..1c5c61d829d6 100644
--- a/drivers/media/i2c/tda7432.c
+++ b/drivers/media/i2c/tda7432.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #ifndef VIDEO_AUDIO_BALANCE
 # define VIDEO_AUDIO_BALANCE 32
diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
index ce86534450ac..92718a9ff5ea 100644
--- a/drivers/media/i2c/tvaudio.c
+++ b/drivers/media/i2c/tvaudio.c
@@ -40,8 +40,6 @@
 #include 
 #include 
 
-#include 
-
 /* -- */
 /* insmod args*/
 
diff --git a/drivers/media/pci/bt8xx/bttv-cards.c 
b/drivers/media/pci/bt8xx/bttv-cards.c
index 5cc42b426715..7dcf509e66d9 100644
--- a/drivers/media/pci/bt8xx/bttv-cards.c
+++ b/drivers/media/pci/bt8xx/bttv-cards.c
@@ -141,6 +141,13 @@ MODULE_PARM_DESC(audiodev, "specify audio device:\n"
 MODULE_PARM_DESC(saa6588, "if 1, then load the saa6588 RDS module, default (0) 
is to use the card definition.");
 MODULE_PARM_DESC(no_overlay, "allow override overlay default (0 disables, 1 
enables) [some VIA/SIS chipsets are known to have problem with overlay]");
 
+
+/* I2C addresses list */
+#define I2C_ADDR_TDA7432   0x8a
+#define I2C_ADDR_MSP3400   0x80
+#define I2C_ADDR_MSP3400_ALT   0x88
+
+
 /* --- */
 /* list of card IDs for bt878+ cards   */
 
diff --git a/drivers/media/pci/bt8xx/bttv.h b/drivers/media/pci/bt8xx/bttv.h
index 91301c3cad1e..faea9aeff711 100644
--- a/drivers/media/pci/bt8xx/bttv.h
+++ b/drivers/media/pci/bt8xx/bttv.h
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* -- */
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 4c57fd7929cb..34e16f6ab4ac 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index 2537643a1808..b4df9181c54b 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "tm6000.h"
diff --git a/include/media/i2c-addr.h b/include/media/i2c-addr.h
deleted file mode 100644
index fba0457b74c4..
--- a/include/media/i2c-addr.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * V4L I2C address list
- *
- *
- * Copyright (C) 2006 Mauro Carvalho Chehab 
- * Based on a previous mapping by
- * Ralph Metzler (r...@thp.uni-koeln.de)
- * Gerd Knorr 
- *
- */
-
-/* bttv address list */
-#define I2C_ADDR_TDA7432   0x8a
-#define I2C_ADDR_TDA8425   0x82
-#define I2C_ADDR_TDA9840   0x84
-#define I2C_ADDR_TDA9874   0xb0 /* also used by 9875 */
-#define I2C_ADDR_TDA9875   0xb0
-#define I2C_ADDR_MSP3400   0x80
-#define I2C_ADDR_MSP3400_ALT   0x88
-#define I2C_ADDR_TEA6300   0x80 /* also used by 6320 */
-
-/*
- * i2c bus addresses for the chips supported by tvaudio.c
- */
-
-#define I2C_ADDR_TDA8425   0x82
-#define I2C_ADDR_TDA9840   0x84 /* also used by TA8874Z */
-#define I2C_ADDR_TDA985x_L 0xb4 /* also used by 9873 */
-#define I2C_ADDR_TDA985x_H 0xb6
-#define I2C_ADDR_TDA9874   0xb0 /* also used by 9875 */
-
-#define I2C_ADDR_TEA6300   0x80 /* also used by 6320 */
-#define I2C_ADDR_TEA6420   0x98
-
-#define I2C_ADDR_PIC16C54  0x96 /* PV951 */
diff --git a/include/media/i2c/tvaudio.h b/include/media/i2c/tvaudio.h
index 1ac8184693f8..f13e1a386364 100644
--- a/include/media/i2c/tvaudio.h
+++ b/include/media/i2c/tvaudio.h
@@ -21,7 +21,22 @@
 #ifndef _TVAUDIO_H
 #define _TVAUDIO_H
 
-#include 
+/*
+ * i2c bus addresses for the chips supported by 

[PATCH 13/24] media: v4l2-subdev: better document IO pin configuration flags

[Mauro Carvalho Chehab]

Convert V4L2_SUBDEV_IO_PIN_* to enums, use BIT() and document
via kernel-doc.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index c43e3d650fe6..249604bbd3cb 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -109,22 +109,31 @@ struct v4l2_decode_vbi_line {
  * not yet implemented) since ops provide proper type-checking.
  */
 
-/* Subdevice external IO pin configuration */
-#define V4L2_SUBDEV_IO_PIN_DISABLE (1 << 0) /* ENABLE assumed */
-#define V4L2_SUBDEV_IO_PIN_OUTPUT  (1 << 1)
-#define V4L2_SUBDEV_IO_PIN_INPUT   (1 << 2)
-#define V4L2_SUBDEV_IO_PIN_SET_VALUE   (1 << 3) /* Set output value */
-#define V4L2_SUBDEV_IO_PIN_ACTIVE_LOW  (1 << 4) /* ACTIVE HIGH assumed */
+/**
+ * enum v4l2_subdev_io_pin_flags - Subdevice external IO pin configuration
+ * flags
+ *
+ * @V4L2_SUBDEV_IO_PIN_DISABLE: disables a pin config. ENABLE assumed.
+ * @V4L2_SUBDEV_IO_PIN_OUTPUT: set it if pin is an output.
+ * @V4L2_SUBDEV_IO_PIN_INPUT: set it if pin is an input.
+ * @V4L2_SUBDEV_IO_PIN_SET_VALUE: to set the output value via
+ *v4l2_subdev_io_pin_config->value.
+ * @V4L2_SUBDEV_IO_PIN_ACTIVE_LOW: pin active is bit 0.
+ *Otherwise, ACTIVE HIGH is assumed.
+ */
+enum v4l2_subdev_io_pin_flags {
+   V4L2_SUBDEV_IO_PIN_DISABLE  = BIT(0),
+   V4L2_SUBDEV_IO_PIN_OUTPUT   = BIT(1),
+   V4L2_SUBDEV_IO_PIN_INPUT= BIT(2),
+   V4L2_SUBDEV_IO_PIN_SET_VALUE= BIT(3),
+   V4L2_SUBDEV_IO_PIN_ACTIVE_LOW   = BIT(4),
+};
 
 /**
  * struct v4l2_subdev_io_pin_config - Subdevice external IO pin configuration
  *
- * @flags: bitmask with flags for this pin's config:
- *%V4L2_SUBDEV_IO_PIN_DISABLE - disables a pin config,
- *%V4L2_SUBDEV_IO_PIN_OUTPUT - if pin is an output,
- *%V4L2_SUBDEV_IO_PIN_INPUT - if pin is an input,
- *%V4L2_SUBDEV_IO_PIN_SET_VALUE - to set the output value via @value
- *and %V4L2_SUBDEV_IO_PIN_ACTIVE_LOW - if active is 0.
+ * @flags: bitmask with flags for this pin's config, as defined by
+ * v4l2_subdev_io_pin_flags.
  * @pin: Chip external IO pin to configure
  * @function: Internal signal pad/function to route to IO pin
  * @value: Initial value for pin - e.g. GPIO output value
-- 
2.13.6

[PATCH 00/24] V4L2 kAPI cleanups and documentation improvements part 2

[Mauro Carvalho Chehab]

That's the second part of my V4L2 kAPI documentation improvements.
It is meant to reduce the gap between the kAPI media headers
and documentation, at least with regards to kernel-doc markups.

We should likely write more things at the ReST files under Documentation/
to better describe some of those APIs (VB2 being likely the first candidate),
but at least let's be sure that all V4L2 bits have kernel-doc markups.

Mauro Carvalho Chehab (24):
  media: v4l2-dev.h: add kernel-doc to two macros
  media: v4l2-flash-led-class.h: add kernel-doc to two ancillary funcs
  media: v4l2-mediabus: use BIT() macro for flags
  media: v4l2-mediabus: convert flags to enums and document them
  media: v4l2-dev: convert VFL_TYPE_* into an enum
  media: i2c-addr.h: get rid of now unused defines
  media: get rid of i2c-addr.h
  media: v4l2-dev: document VFL_DIR_* direction defines
  media: v4l2-dev: document video_device flags
  media: v4l2-subdev: use kernel-doc markups to document subdev flags
  media: v4l2-subdev: create cross-references for ioctls
  media: v4l2-subdev: fix description of tuner.s_radio ops
  media: v4l2-subdev: better document IO pin configuration flags
  media: v4l2-subdev: convert frame description to enum
  media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro
  media: v4l2-subdev: document remaining undocumented functions
  media: v4l2-subdev: fix a typo
  media: vb2-core: use bitops for bits
  media: vb2-core: Improve kernel-doc markups
  media: vb2-core: document remaining functions
  media: vb2-core: fix descriptions for VB2-only functions
  media: vb2: add cross references at memops and v4l2 kernel-doc markups
  media: v4l2-tpg*.h: move headers to include/media/tpg and merge them
  media: v4l2-tpg.h: rename color structs

 Documentation/media/kapi/v4l2-dev.rst  |  17 +-
 drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c|   8 +-
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  |   2 +-
 drivers/media/i2c/adv7180.c|  10 +-
 drivers/media/i2c/ml86v7667.c  |   5 +-
 drivers/media/i2c/mt9m111.c|   8 +-
 drivers/media/i2c/ov6650.c |  19 +-
 drivers/media/i2c/soc_camera/imx074.c  |   6 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  10 +-
 drivers/media/i2c/soc_camera/mt9t031.c |  11 +-
 drivers/media/i2c/soc_camera/mt9t112.c |  11 +-
 drivers/media/i2c/soc_camera/mt9v022.c |  16 +-
 drivers/media/i2c/soc_camera/ov5642.c  |   5 +-
 drivers/media/i2c/soc_camera/ov772x.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9640.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9740.c  |  10 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  12 +-
 drivers/media/i2c/soc_camera/tw9910.c  |  13 +-
 drivers/media/i2c/tc358743.c   |  10 +-
 drivers/media/i2c/tda7432.c|   1 -
 drivers/media/i2c/tvaudio.c|   2 -
 drivers/media/i2c/tvp5150.c|   6 +-
 drivers/media/pci/bt8xx/bttv-cards.c   |   7 +
 drivers/media/pci/bt8xx/bttv.h |   1 -
 drivers/media/pci/cx88/cx88-blackbird.c|   3 +-
 drivers/media/pci/cx88/cx88-video.c|  10 +-
 drivers/media/pci/cx88/cx88.h  |   4 +-
 drivers/media/pci/saa7134/saa7134-video.c  |   2 +
 drivers/media/platform/pxa_camera.c|   8 +-
 drivers/media/platform/rcar-vin/rcar-core.c|   4 +-
 drivers/media/platform/rcar-vin/rcar-dma.c |   4 +-
 .../platform/soc_camera/sh_mobile_ceu_camera.c |   2 +-
 drivers/media/platform/soc_camera/soc_camera.c |   3 +-
 .../platform/soc_camera/soc_camera_platform.c  |   2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c   |   2 +-
 drivers/media/platform/vimc/vimc-sensor.c  |   2 +-
 drivers/media/platform/vivid/vivid-core.h  |   2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c  |   2 +
 drivers/media/usb/em28xx/em28xx-cards.c|   1 -
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c   |   2 +
 drivers/media/usb/tm6000/tm6000-cards.c|   1 -
 drivers/media/usb/tm6000/tm6000-video.c|   2 +
 drivers/media/v4l2-core/v4l2-dev.c |  10 +-
 drivers/media/v4l2-core/v4l2-fwnode.c  |   5 +-
 include/media/i2c-addr.h   |  42 --
 include/media/i2c/tvaudio.h|  17 +-
 include/media/{ => tpg}/v4l2-tpg.h |  45 +-
 include/media/v4l2-dev.h   | 124 --
 include/media/v4l2-flash-led-class.h   |  12 +
 include/media/v4l2-fwnode.h|   4 +-
 include/media/v4l2-mediabus.h  | 176 ++--
 include/media/v4l2-subdev.h| 293 +
 include/media/v4l2-tpg-colors.h   

[PATCH 12/24] media: v4l2-subdev: fix description of tuner.s_radio ops

[Mauro Carvalho Chehab]

The description there is completely broken and it mentions
an ioctl that doesn't exist.

Fix it.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b299cf63972b..c43e3d650fe6 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -216,7 +216,10 @@ struct v4l2_subdev_core_ops {
  * struct v4l2_subdev_tuner_ops - Callbacks used when v4l device was opened
  * in radio mode.
  *
- * @s_radio: callback for VIDIOC_S_RADIO() ioctl handler code.
+ * @s_radio: callback that switches the tuner to radio mode.
+ *  drivers should explicitly call it when a tuner ops should
+ *  operate on radio mode, before being able to handle it.
+ *  Used on devices that have both AM/FM radio receiver and TV.
  *
  * @s_frequency: callback for VIDIOC_S_FREQUENCY() ioctl handler code.
  *
@@ -239,6 +242,22 @@ struct v4l2_subdev_core_ops {
  * @s_type_addr: sets tuner type and its I2C addr.
  *
  * @s_config: sets tda9887 specific stuff, like port1, port2 and qss
+ *
+ * .. note::
+ *
+ * On devices that have both AM/FM and TV, it is up to the driver
+ * to explicitly call s_radio when the tuner should be switched to
+ * radio mode, before handling other  v4l2_subdev_tuner_ops
+ * that would require it. An example of such usage is::
+ *
+ *   static void s_frequency(void *priv, const struct v4l2_frequency *f)
+ *   {
+ * ...
+ * if (f.type == V4L2_TUNER_RADIO)
+ * v4l2_device_call_all(v4l2_dev, 0, tuner, s_radio);
+ * ...
+ * v4l2_device_call_all(v4l2_dev, 0, tuner, s_frequency);
+ *   }
  */
 struct v4l2_subdev_tuner_ops {
int (*s_radio)(struct v4l2_subdev *sd);
-- 
2.13.6

[PATCH 11/24] media: v4l2-subdev: create cross-references for ioctls

[Mauro Carvalho Chehab]

When generating Sphinx output, create cross-references for the
callbacks for each ioctl.

While here, fix a few wrong names for ioctls.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 65 -
 1 file changed, 34 insertions(+), 31 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 6286c69a12ba..b299cf63972b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -141,7 +141,7 @@ struct v4l2_subdev_io_pin_config {
 /**
  * struct v4l2_subdev_core_ops - Define core ops callbacks for subdevs
  *
- * @log_status: callback for %VIDIOC_LOG_STATUS ioctl handler code.
+ * @log_status: callback for VIDIOC_LOG_STATUS() ioctl handler code.
  *
  * @s_io_pin_config: configure one or more chip I/O pins for chips that
  * multiplex different internal signal pads out to IO pins.  This function
@@ -169,9 +169,9 @@ struct v4l2_subdev_io_pin_config {
  * @compat_ioctl32: called when a 32 bits application uses a 64 bits Kernel,
  * in order to fix data passed from/to userspace.
  *
- * @g_register: callback for %VIDIOC_G_REGISTER ioctl handler code.
+ * @g_register: callback for VIDIOC_DBG_G_REGISTER() ioctl handler code.
  *
- * @s_register: callback for %VIDIOC_G_REGISTER ioctl handler code.
+ * @s_register: callback for VIDIOC_DBG_S_REGISTER() ioctl handler code.
  *
  * @s_power: puts subdevice in power saving mode (on == 0) or normal operation
  * mode (on == 1).
@@ -216,25 +216,25 @@ struct v4l2_subdev_core_ops {
  * struct v4l2_subdev_tuner_ops - Callbacks used when v4l device was opened
  * in radio mode.
  *
- * @s_radio: callback for %VIDIOC_S_RADIO ioctl handler code.
+ * @s_radio: callback for VIDIOC_S_RADIO() ioctl handler code.
  *
- * @s_frequency: callback for %VIDIOC_S_FREQUENCY ioctl handler code.
+ * @s_frequency: callback for VIDIOC_S_FREQUENCY() ioctl handler code.
  *
- * @g_frequency: callback for %VIDIOC_G_FREQUENCY ioctl handler code.
+ * @g_frequency: callback for VIDIOC_G_FREQUENCY() ioctl handler code.
  *  freq->type must be filled in. Normally done by video_ioctl2()
  *  or the bridge driver.
  *
- * @enum_freq_bands: callback for %VIDIOC_ENUM_FREQ_BANDS ioctl handler code.
+ * @enum_freq_bands: callback for VIDIOC_ENUM_FREQ_BANDS() ioctl handler code.
  *
- * @g_tuner: callback for %VIDIOC_G_TUNER ioctl handler code.
+ * @g_tuner: callback for VIDIOC_G_TUNER() ioctl handler code.
  *
- * @s_tuner: callback for %VIDIOC_S_TUNER ioctl handler code. @vt->type must be
+ * @s_tuner: callback for VIDIOC_S_TUNER() ioctl handler code. @vt->type must 
be
  *  filled in. Normally done by video_ioctl2 or the
  *  bridge driver.
  *
- * @g_modulator: callback for %VIDIOC_G_MODULATOR ioctl handler code.
+ * @g_modulator: callback for VIDIOC_G_MODULATOR() ioctl handler code.
  *
- * @s_modulator: callback for %VIDIOC_S_MODULATOR ioctl handler code.
+ * @s_modulator: callback for VIDIOC_S_MODULATOR() ioctl handler code.
  *
  * @s_type_addr: sets tuner type and its I2C addr.
  *
@@ -333,9 +333,9 @@ struct v4l2_mbus_frame_desc {
  * regarding clock frequency dividers, etc. If not used, then set flags
  * to 0. If the frequency is not supported, then -EINVAL is returned.
  *
- * @g_std: callback for %VIDIOC_G_STD ioctl handler code.
+ * @g_std: callback for VIDIOC_G_STD() ioctl handler code.
  *
- * @s_std: callback for %VIDIOC_S_STD ioctl handler code.
+ * @s_std: callback for VIDIOC_S_STD() ioctl handler code.
  *
  * @s_std_output: set v4l2_std_id for video OUTPUT devices. This is ignored by
  * video input devices.
@@ -343,7 +343,7 @@ struct v4l2_mbus_frame_desc {
  * @g_std_output: get current standard for video OUTPUT devices. This is 
ignored
  * by video input devices.
  *
- * @querystd: callback for %VIDIOC_QUERYSTD ioctl handler code.
+ * @querystd: callback for VIDIOC_QUERYSTD() ioctl handler code.
  *
  * @g_tvnorms: get _std_id with all standards supported by the video
  * CAPTURE device. This is ignored by video output devices.
@@ -359,13 +359,15 @@ struct v4l2_mbus_frame_desc {
  *
  * @g_pixelaspect: callback to return the pixelaspect ratio.
  *
- * @g_parm: callback for %VIDIOC_G_PARM ioctl handler code.
+ * @g_parm: callback for VIDIOC_G_PARM() ioctl handler code.
  *
- * @s_parm: callback for %VIDIOC_S_PARM ioctl handler code.
+ * @s_parm: callback for VIDIOC_S_PARM() ioctl handler code.
  *
- * @g_frame_interval: callback for %VIDIOC_G_FRAMEINTERVAL ioctl handler code.
+ * @g_frame_interval: callback for VIDIOC_SUBDEV_G_FRAME_INTERVAL()
+ *   ioctl handler code.
  *
- * @s_frame_interval: callback for %VIDIOC_S_FRAMEINTERVAL ioctl handler code.
+ * @s_frame_interval: callback for VIDIOC_SUBDEV_S_FRAME_INTERVAL()
+ *   ioctl handler code.
  *
  * @s_dv_timings: Set custom dv timings in the sub device. This is used
  * 

[PATCH 03/24] media: v4l2-mediabus: use BIT() macro for flags

[Mauro Carvalho Chehab]

Instead of using (1 << n) for bits, use the BIT() macro,
as it makes them better documented.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-mediabus.h | 50 ++-
 1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 93f8afcb7a22..e5281e1086c4 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -12,6 +12,8 @@
 #define V4L2_MEDIABUS_H
 
 #include 
+#include 
+
 
 /* Parallel flags */
 /*
@@ -20,44 +22,44 @@
  * horizontal and vertical synchronisation. In "Slave mode" the host is
  * providing these signals to the slave.
  */
-#define V4L2_MBUS_MASTER   (1 << 0)
-#define V4L2_MBUS_SLAVE(1 << 1)
+#define V4L2_MBUS_MASTER   BIT(0)
+#define V4L2_MBUS_SLAVEBIT(1)
 /*
  * Signal polarity flags
  * Note: in BT.656 mode HSYNC, FIELD, and VSYNC are unused
  * V4L2_MBUS_[HV]SYNC* flags should be also used for specifying
  * configuration of hardware that uses [HV]REF signals
  */
-#define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 << 2)
-#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 << 3)
-#define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 << 4)
-#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 << 5)
-#define V4L2_MBUS_PCLK_SAMPLE_RISING   (1 << 6)
-#define V4L2_MBUS_PCLK_SAMPLE_FALLING  (1 << 7)
-#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 << 8)
-#define V4L2_MBUS_DATA_ACTIVE_LOW  (1 << 9)
+#define V4L2_MBUS_HSYNC_ACTIVE_HIGHBIT(2)
+#define V4L2_MBUS_HSYNC_ACTIVE_LOW BIT(3)
+#define V4L2_MBUS_VSYNC_ACTIVE_HIGHBIT(4)
+#define V4L2_MBUS_VSYNC_ACTIVE_LOW BIT(5)
+#define V4L2_MBUS_PCLK_SAMPLE_RISING   BIT(6)
+#define V4L2_MBUS_PCLK_SAMPLE_FALLING  BIT(7)
+#define V4L2_MBUS_DATA_ACTIVE_HIGH BIT(8)
+#define V4L2_MBUS_DATA_ACTIVE_LOW  BIT(9)
 /* FIELD = 0/1 - Field1 (odd)/Field2 (even) */
-#define V4L2_MBUS_FIELD_EVEN_HIGH  (1 << 10)
+#define V4L2_MBUS_FIELD_EVEN_HIGH  BIT(10)
 /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */
-#define V4L2_MBUS_FIELD_EVEN_LOW   (1 << 11)
+#define V4L2_MBUS_FIELD_EVEN_LOW   BIT(11)
 /* Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively. 
*/
-#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1 << 12)
-#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 << 13)
+#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGHBIT(12)
+#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW BIT(13)
 
 /* Serial flags */
 /* How many lanes the client can use */
-#define V4L2_MBUS_CSI2_1_LANE  (1 << 0)
-#define V4L2_MBUS_CSI2_2_LANE  (1 << 1)
-#define V4L2_MBUS_CSI2_3_LANE  (1 << 2)
-#define V4L2_MBUS_CSI2_4_LANE  (1 << 3)
+#define V4L2_MBUS_CSI2_1_LANE  BIT(0)
+#define V4L2_MBUS_CSI2_2_LANE  BIT(1)
+#define V4L2_MBUS_CSI2_3_LANE  BIT(2)
+#define V4L2_MBUS_CSI2_4_LANE  BIT(3)
 /* On which channels it can send video data */
-#define V4L2_MBUS_CSI2_CHANNEL_0   (1 << 4)
-#define V4L2_MBUS_CSI2_CHANNEL_1   (1 << 5)
-#define V4L2_MBUS_CSI2_CHANNEL_2   (1 << 6)
-#define V4L2_MBUS_CSI2_CHANNEL_3   (1 << 7)
+#define V4L2_MBUS_CSI2_CHANNEL_0   BIT(4)
+#define V4L2_MBUS_CSI2_CHANNEL_1   BIT(5)
+#define V4L2_MBUS_CSI2_CHANNEL_2   BIT(6)
+#define V4L2_MBUS_CSI2_CHANNEL_3   BIT(7)
 /* Does it support only continuous or also non-continuous clock mode */
-#define V4L2_MBUS_CSI2_CONTINUOUS_CLOCK(1 << 8)
-#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK (1 << 9)
+#define V4L2_MBUS_CSI2_CONTINUOUS_CLOCKBIT(8)
+#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK BIT(9)
 
 #define V4L2_MBUS_CSI2_LANES   (V4L2_MBUS_CSI2_1_LANE | 
V4L2_MBUS_CSI2_2_LANE | \
 V4L2_MBUS_CSI2_3_LANE | 
V4L2_MBUS_CSI2_4_LANE)
-- 
2.13.6

[PATCH 21/24] media: vb2-core: fix descriptions for VB2-only functions

[Mauro Carvalho Chehab]

When we split VB2 into an independent streaming module and
a V4L2 one, some vb2-core functions started to have a wrong
description: they're meant to be used only by the API-specific
parts of VB2, like vb2-v4l2, as the functions that V4L2 drivers
should use are all under videobuf2-v4l2.h.

Correct their descriptions.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/videobuf2-core.h | 86 ++
 1 file changed, 46 insertions(+), 40 deletions(-)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index ce795cd0a7cc..3165f0f9a85f 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -651,12 +651,14 @@ int vb2_wait_for_all_buffers(struct vb2_queue *q);
  * @index: id number of the buffer.
  * @pb:buffer struct passed from userspace.
  *
- * Should be called from _ioctl_ops->vidioc_querybuf ioctl handler
- * in driver.
+ * Videbuf2 core helper to implement QUERYBUF operation. It is called
+ * internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
  *
  * The passed buffer should have been verified.
  *
  * This function fills the relevant information for the userspace.
+ *
+ * Return: returns zero on success; an error code otherwise.
  */
 void vb2_core_querybuf(struct vb2_queue *q, unsigned int index, void *pb);
 
@@ -666,27 +668,26 @@ void vb2_core_querybuf(struct vb2_queue *q, unsigned int 
index, void *pb);
  * @memory:memory type, as defined by  vb2_memory.
  * @count: requested buffer count.
  *
- * Should be called from _ioctl_ops->vidioc_reqbufs ioctl
- * handler of a driver.
+ * Videbuf2 core helper to implement REQBUF operation. It is called
+ * internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
  *
  * This function:
  *
- * #) verifies streaming parameters passed from the userspace,
- * #) sets up the queue,
+ * #) verifies streaming parameters passed from the userspace;
+ * #) sets up the queue;
  * #) negotiates number of buffers and planes per buffer with the driver
- *to be used during streaming,
+ *to be used during streaming;
  * #) allocates internal buffer structures ( vb2_buffer), according to
- *the agreed parameters,
+ *the agreed parameters;
  * #) for MMAP memory type, allocates actual video memory, using the
- *memory handling/allocation routines provided during queue initialization
+ *memory handling/allocation routines provided during queue initialization.
  *
  * If req->count is 0, all the memory will be freed instead.
  *
  * If the queue has been allocated previously by a previous vb2_core_reqbufs()
  * call and the queue is not busy, memory will be reallocated.
  *
- * The return values from this function are intended to be directly returned
- * from _ioctl_ops->vidioc_reqbufs handler in driver.
+ * Return: returns zero on success; an error code otherwise.
  */
 int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
unsigned int *count);
@@ -699,17 +700,16 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
memory,
  * @requested_planes: number of planes requested.
  * @requested_sizes: array with the size of the planes.
  *
- * Should be called from _ioctl_ops->vidioc_create_bufs ioctl handler
- * of a driver.
+ * Videbuf2 core helper to implement CREATE_BUFS operation. It is called
+ * internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
  *
  * This function:
  *
- * #) verifies parameter sanity
- * #) calls the _ops->queue_setup queue operation
- * #) performs any necessary memory allocations
+ * #) verifies parameter sanity;
+ * #) calls the _ops->queue_setup queue operation;
+ * #) performs any necessary memory allocations.
  *
- * Return: the return values from this function are intended to be directly
- * returned from _ioctl_ops->vidioc_create_bufs handler in driver.
+ * Return: returns zero on success; an error code otherwise.
  */
 int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
 unsigned int *count, unsigned int requested_planes,
@@ -723,16 +723,16 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
  * @pb:buffer structure passed from userspace to
  * _ioctl_ops->vidioc_prepare_buf handler in driver.
  *
- * Should be called from _ioctl_ops->vidioc_prepare_buf ioctl handler
- * of a driver.
+ * Videbuf2 core helper to implement PREPARE_BUF operation. It is called
+ * internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
  *
  * The passed buffer should have been verified.
  *
- * This function calls buf_prepare callback in the driver (if provided),
- * in which driver-specific buffer initialization can be performed,
+ * This function calls vb2_ops->buf_prepare callback in the driver
+ * (if provided), in which driver-specific buffer initialization can
+ * be performed.
  *
- * The 

[PATCH 22/24] media: vb2: add cross references at memops and v4l2 kernel-doc markups

[Mauro Carvalho Chehab]

Add cross-references where needed and add periods at the end of
each kernel-doc paragraph, in order to make it coherent with other
VB2 descriptions.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/videobuf2-memops.h |   8 +--
 include/media/videobuf2-v4l2.h   | 112 +--
 2 files changed, 63 insertions(+), 57 deletions(-)

diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index a6ed091b79ce..4b5b84f93538 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -19,11 +19,11 @@
 #include 
 
 /**
- * struct vb2_vmarea_handler - common vma refcount tracking handler
+ * struct vb2_vmarea_handler - common vma refcount tracking handler.
  *
- * @refcount:  pointer to refcount entry in the buffer
- * @put:   callback to function that decreases buffer refcount
- * @arg:   argument for @put callback
+ * @refcount:  pointer to _t entry in the buffer.
+ * @put:   callback to function that decreases buffer refcount.
+ * @arg:   argument for @put callback.
  */
 struct vb2_vmarea_handler {
refcount_t  *refcount;
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 036127c54bbf..d38829a9dab3 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -24,16 +24,17 @@
 #endif
 
 /**
- * struct vb2_v4l2_buffer - video buffer information for v4l2
+ * struct vb2_v4l2_buffer - video buffer information for v4l2.
  *
- * @vb2_buf:   video buffer 2
- * @flags: buffer informational flags
- * @field: enum v4l2_field; field order of the image in the buffer
- * @timecode:  frame timecode
- * @sequence:  sequence count of this frame
+ * @vb2_buf:   embedded struct _buffer.
+ * @flags: buffer informational flags.
+ * @field: field order of the image in the buffer, as defined by
+ *  v4l2_field.
+ * @timecode:  frame timecode.
+ * @sequence:  sequence count of this frame.
  *
  * Should contain enough information to be able to cover all the fields
- * of struct v4l2_buffer at videodev2.h
+ * of  v4l2_buffer at ``videodev2.h``.
  */
 struct vb2_v4l2_buffer {
struct vb2_buffer   vb2_buf;
@@ -56,9 +57,9 @@ int vb2_querybuf(struct vb2_queue *q, struct v4l2_buffer *b);
  * vb2_reqbufs() - Wrapper for vb2_core_reqbufs() that also verifies
  * the memory and type values.
  *
- * @q: videobuf2 queue
- * @req:   struct passed from userspace to vidioc_reqbufs handler
- * in driver
+ * @q: pointer to  vb2_queue with videobuf2 queue.
+ * @req:v4l2_requestbuffers passed from userspace to
+ * _ioctl_ops->vidioc_reqbufs handler in driver.
  */
 int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req);
 
@@ -66,94 +67,99 @@ int vb2_reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req);
  * vb2_create_bufs() - Wrapper for vb2_core_create_bufs() that also verifies
  * the memory and type values.
  *
- * @q: videobuf2 queue
- * @create:creation parameters, passed from userspace to vidioc_create_bufs
- * handler in driver
+ * @q: pointer to  vb2_queue with videobuf2 queue.
+ * @create:creation parameters, passed from userspace to
+ * _ioctl_ops->vidioc_create_bufs handler in driver
  */
 int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create);
 
 /**
  * vb2_prepare_buf() - Pass ownership of a buffer from userspace to the kernel
  *
- * @q: videobuf2 queue
- * @b: buffer structure passed from userspace to vidioc_prepare_buf
- * handler in driver
+ * @q: pointer to  vb2_queue with videobuf2 queue.
+ * @b: buffer structure passed from userspace to
+ * _ioctl_ops->vidioc_prepare_buf handler in driver
+ *
+ * Should be called from _ioctl_ops->vidioc_prepare_buf ioctl handler
+ * of a driver.
  *
- * Should be called from vidioc_prepare_buf ioctl handler of a driver.
  * This function:
  *
  * #) verifies the passed buffer,
- * #) calls buf_prepare callback in the driver (if provided), in which
- *driver-specific buffer initialization can be performed.
+ * #) calls _ops->buf_prepare callback in the driver (if provided),
+ *in which driver-specific buffer initialization can be performed.
  *
  * The return values from this function are intended to be directly returned
- * from vidioc_prepare_buf handler in driver.
+ * from _ioctl_ops->vidioc_prepare_buf handler in driver.
  */
 int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b);
 
 /**
  * vb2_qbuf() - Queue a buffer from userspace
- * @q: videobuf2 queue
- * @b: buffer structure passed from userspace to VIDIOC_QBUF() handler
- * in driver
+ * @q: pointer to  vb2_queue with videobuf2 queue.
+ * @b: buffer structure passed from userspace to
+ * _ioctl_ops->vidioc_qbuf handler in 

[PATCH 06/24] media: i2c-addr.h: get rid of now unused defines

[Mauro Carvalho Chehab]

Some of the previously used I2C addresses there aren't used
anymore. So, get rid of them.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/i2c-addr.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/include/media/i2c-addr.h b/include/media/i2c-addr.h
index 5d0f56054d26..fba0457b74c4 100644
--- a/include/media/i2c-addr.h
+++ b/include/media/i2c-addr.h
@@ -10,21 +10,14 @@
  */
 
 /* bttv address list */
-#define I2C_ADDR_TSA5522   0xc2
 #define I2C_ADDR_TDA7432   0x8a
 #define I2C_ADDR_TDA8425   0x82
 #define I2C_ADDR_TDA9840   0x84
-#define I2C_ADDR_TDA9850   0xb6 /* also used by 9855,9873 */
 #define I2C_ADDR_TDA9874   0xb0 /* also used by 9875 */
 #define I2C_ADDR_TDA9875   0xb0
-#define I2C_ADDR_HAUPEE0xa0
-#define I2C_ADDR_STBEE 0xae
-#define I2C_ADDR_VHX   0xc0
 #define I2C_ADDR_MSP3400   0x80
 #define I2C_ADDR_MSP3400_ALT   0x88
 #define I2C_ADDR_TEA6300   0x80 /* also used by 6320 */
-#define I2C_ADDR_DPL3518   0x84
-#define I2C_ADDR_TDA9887   0x86
 
 /*
  * i2c bus addresses for the chips supported by tvaudio.c
-- 
2.13.6

[PATCH 19/24] media: vb2-core: Improve kernel-doc markups

[Mauro Carvalho Chehab]

There are several issues on the current markups:
- lack of cross-references;
- wrong cross-references;
- lack of a period of the end of several phrases;
- Some descriptions can be enhanced.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/videobuf2-core.h | 376 ++---
 1 file changed, 204 insertions(+), 172 deletions(-)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 0308d8439049..e145f1475ffe 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -46,7 +46,7 @@ struct vb2_fileio_data;
 struct vb2_threadio_data;
 
 /**
- * struct vb2_mem_ops - memory handling/memory allocator operations
+ * struct vb2_mem_ops - memory handling/memory allocator operations.
  * @alloc: allocate video memory and, optionally, allocator private data,
  * return ERR_PTR() on failure or a pointer to allocator private,
  * per-buffer data on success; the returned private structure
@@ -146,27 +146,28 @@ struct vb2_mem_ops {
 };
 
 /**
- * struct vb2_plane - plane information
- * @mem_priv:  private data with this plane
- * @dbuf:  dma_buf - shared buffer object
+ * struct vb2_plane - plane information.
+ * @mem_priv:  private data with this plane.
+ * @dbuf:  dma_buf - shared buffer object.
  * @dbuf_mapped:   flag to show whether dbuf is mapped or not
- * @bytesused: number of bytes occupied by data in the plane (payload)
- * @length:size of this plane (NOT the payload) in bytes
+ * @bytesused: number of bytes occupied by data in the plane (payload).
+ * @length:size of this plane (NOT the payload) in bytes.
  * @min_length:minimum required size of this plane (NOT the payload) 
in bytes.
  * @length is always greater or equal to @min_length.
- * @m: Union with memtype-specific data
+ * @m: Union with memtype-specific data.
  * @m.offset:  when memory in the associated struct vb2_buffer is
  * %VB2_MEMORY_MMAP, equals the offset from the start of
  * the device memory for this plane (or is a "cookie" that
- * should be passed to mmap() called on the video node)
+ * should be passed to mmap() called on the video node).
  * @m.userptr: when memory is %VB2_MEMORY_USERPTR, a userspace pointer
- * pointing to this plane
+ * pointing to this plane.
  * @m.fd:  when memory is %VB2_MEMORY_DMABUF, a userspace file
- * descriptor associated with this plane
+ * descriptor associated with this plane.
  * @data_offset:   offset in the plane to the start of data; usually 0,
- * unless there is a header in front of the data
+ * unless there is a header in front of the data.
+ *
  * Should contain enough information to be able to cover all the fields
- * of  v4l2_plane at videodev2.h
+ * of  v4l2_plane at videodev2.h.
  */
 struct vb2_plane {
void*mem_priv;
@@ -184,12 +185,12 @@ struct vb2_plane {
 };
 
 /**
- * enum vb2_io_modes - queue access methods
- * @VB2_MMAP:  driver supports MMAP with streaming API
- * @VB2_USERPTR:   driver supports USERPTR with streaming API
- * @VB2_READ:  driver supports read() style access
- * @VB2_WRITE: driver supports write() style access
- * @VB2_DMABUF:driver supports DMABUF with streaming API
+ * enum vb2_io_modes - queue access methods.
+ * @VB2_MMAP:  driver supports MMAP with streaming API.
+ * @VB2_USERPTR:   driver supports USERPTR with streaming API.
+ * @VB2_READ:  driver supports read() style access.
+ * @VB2_WRITE: driver supports write() style access.
+ * @VB2_DMABUF:driver supports DMABUF with streaming API.
  */
 enum vb2_io_modes {
VB2_MMAP= BIT(0),
@@ -200,19 +201,19 @@ enum vb2_io_modes {
 };
 
 /**
- * enum vb2_buffer_state - current video buffer state
- * @VB2_BUF_STATE_DEQUEUED:buffer under userspace control
- * @VB2_BUF_STATE_PREPARING:   buffer is being prepared in videobuf
- * @VB2_BUF_STATE_PREPARED:buffer prepared in videobuf and by the driver
- * @VB2_BUF_STATE_QUEUED:  buffer queued in videobuf, but not in driver
- * @VB2_BUF_STATE_REQUEUEING:  re-queue a buffer to the driver
+ * enum vb2_buffer_state - current video buffer state.
+ * @VB2_BUF_STATE_DEQUEUED:buffer under userspace control.
+ * @VB2_BUF_STATE_PREPARING:   buffer is being prepared in videobuf.
+ * @VB2_BUF_STATE_PREPARED:buffer prepared in videobuf and by the driver.
+ * @VB2_BUF_STATE_QUEUED:  buffer queued in videobuf, but not in driver.
+ * @VB2_BUF_STATE_REQUEUEING:  re-queue a buffer to the driver.
  * @VB2_BUF_STATE_ACTIVE:  buffer queued in driver and possibly used
- * in a hardware operation
+ * in a hardware operation.
  * @VB2_BUF_STATE_DONE:

[PATCH 04/24] media: v4l2-mediabus: convert flags to enums and document them

[Mauro Carvalho Chehab]

There is a mess with media bus flags: there are two sets of
flags, one used by parallel and ITU-R BT.656 outputs,
and another one for CSI2.

Depending on the type, the same bit has different meanings.

That's very confusing, and counter-intuitive. So, split them
into two sets of flags, inside an enum.

This way, it becomes clearer that there are two separate sets
of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
need a different set of flags.

As a side effect, enums can be documented via kernel-docs,
so there will be an improvement at flags documentation.

Unfortunately, soc_camera and pxa_camera do a mess with
the flags, using either one set of flags without proper
checks about the type. That could be fixed, but, as both drivers
are obsolete and in the process of cleanings, I opted to just
keep the behavior, using an unsigned int inside those two
drivers.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/adv7180.c|  10 +-
 drivers/media/i2c/ml86v7667.c  |   5 +-
 drivers/media/i2c/mt9m111.c|   8 +-
 drivers/media/i2c/ov6650.c |  19 +--
 drivers/media/i2c/soc_camera/imx074.c  |   6 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  10 +-
 drivers/media/i2c/soc_camera/mt9t031.c |  11 +-
 drivers/media/i2c/soc_camera/mt9t112.c |  11 +-
 drivers/media/i2c/soc_camera/mt9v022.c |  16 ++-
 drivers/media/i2c/soc_camera/ov5642.c  |   5 +-
 drivers/media/i2c/soc_camera/ov772x.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9640.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9740.c  |  10 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  12 +-
 drivers/media/i2c/soc_camera/tw9910.c  |  13 +-
 drivers/media/i2c/tc358743.c   |  10 +-
 drivers/media/i2c/tvp5150.c|   6 +-
 drivers/media/platform/pxa_camera.c|   8 +-
 drivers/media/platform/rcar-vin/rcar-core.c|   4 +-
 drivers/media/platform/rcar-vin/rcar-dma.c |   4 +-
 .../platform/soc_camera/sh_mobile_ceu_camera.c |   2 +-
 drivers/media/platform/soc_camera/soc_camera.c |   3 +-
 .../platform/soc_camera/soc_camera_platform.c  |   2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c   |   2 +-
 drivers/media/v4l2-core/v4l2-fwnode.c  |   5 +-
 include/media/v4l2-fwnode.h|   4 +-
 include/media/v4l2-mediabus.h  | 144 ++---
 27 files changed, 217 insertions(+), 133 deletions(-)

diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 3df28f2f9b38..c220504049de 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -743,16 +743,16 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
 
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
cfg->type = V4L2_MBUS_CSI2;
-   cfg->flags = V4L2_MBUS_CSI2_1_LANE |
-   V4L2_MBUS_CSI2_CHANNEL_0 |
-   V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+   cfg->csi2_flags = V4L2_MBUS_CSI2_1_LANE
+ | V4L2_MBUS_CSI2_CHANNEL_0
+ | V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
} else {
/*
 * The ADV7180 sensor supports BT.601/656 output modes.
 * The BT.656 is default and not yet configurable by s/w.
 */
-   cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
-V4L2_MBUS_DATA_ACTIVE_HIGH;
+   cfg->pb_flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
+   | V4L2_MBUS_DATA_ACTIVE_HIGH;
cfg->type = V4L2_MBUS_BT656;
}
 
diff --git a/drivers/media/i2c/ml86v7667.c b/drivers/media/i2c/ml86v7667.c
index 57ef901edb06..a25114d0c31f 100644
--- a/drivers/media/i2c/ml86v7667.c
+++ b/drivers/media/i2c/ml86v7667.c
@@ -226,8 +226,9 @@ static int ml86v7667_fill_fmt(struct v4l2_subdev *sd,
 static int ml86v7667_g_mbus_config(struct v4l2_subdev *sd,
   struct v4l2_mbus_config *cfg)
 {
-   cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
-V4L2_MBUS_DATA_ACTIVE_HIGH;
+   cfg->pb_flags = V4L2_MBUS_MASTER
+   | V4L2_MBUS_PCLK_SAMPLE_RISING
+   | V4L2_MBUS_DATA_ACTIVE_HIGH;
cfg->type = V4L2_MBUS_BT656;
 
return 0;
diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
index 99b992e46702..53c406f87aa7 100644
--- a/drivers/media/i2c/mt9m111.c
+++ b/drivers/media/i2c/mt9m111.c
@@ -857,9 +857,11 @@ static int mt9m111_enum_mbus_code(struct v4l2_subdev *sd,
 static int mt9m111_g_mbus_config(struct v4l2_subdev *sd,

[PATCH 02/24] media: v4l2-flash-led-class.h: add kernel-doc to two ancillary funcs

[Mauro Carvalho Chehab]

There are two ancillary functions at v4l2-flash-led-class.h
that aren't documented.

Document them.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-flash-led-class.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/media/v4l2-flash-led-class.h 
b/include/media/v4l2-flash-led-class.h
index 5c1d50f78e12..39a5daa977aa 100644
--- a/include/media/v4l2-flash-led-class.h
+++ b/include/media/v4l2-flash-led-class.h
@@ -91,12 +91,24 @@ struct v4l2_flash {
struct v4l2_ctrl **ctrls;
 };
 
+/**
+ * v4l2_subdev_to_v4l2_flash - Returns a _flash from the
+ *  v4l2_subdev embedded on it.
+ *
+ * @sd: pointer to  v4l2_subdev
+ */
 static inline struct v4l2_flash *v4l2_subdev_to_v4l2_flash(
struct v4l2_subdev *sd)
 {
return container_of(sd, struct v4l2_flash, sd);
 }
 
+/**
+ * v4l2_ctrl_to_v4l2_flash - Returns a _flash from the
+ *  v4l2_ctrl embedded on it.
+ *
+ * @c: pointer to  v4l2_ctrl
+ */
 static inline struct v4l2_flash *v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
 {
return container_of(c->handler, struct v4l2_flash, hdl);
-- 
2.13.6

[PATCH 14/24] media: v4l2-subdev: convert frame description to enum

[Mauro Carvalho Chehab]

As kernel-doc doesn't support documenting #define values,
and using enum makes easier to identify where the values
are used, convert V4L2_MBUS_FRAME_DESC_FL_* to enum, and
use BIT() macro.

While here, fix the description at v4l2_mbus_frame_desc_entry,
in order to match what's described for
V4L2_MBUS_FRAME_DESC_FL_LEN_MAX.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 249604bbd3cb..1f34045f07ce 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -314,25 +314,32 @@ struct v4l2_subdev_audio_ops {
int (*s_stream)(struct v4l2_subdev *sd, int enable);
 };
 
-/* Indicates the @length field specifies maximum data length. */
-#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX(1U << 0)
-/*
- * Indicates that the format does not have line offsets, i.e. the
- * receiver should use 1D DMA.
+/**
+ * enum v4l2_mbus_frame_desc_entry - media bus frame description flags
+ *
+ * @V4L2_MBUS_FRAME_DESC_FL_LEN_MAX:
+ * Indicates that  v4l2_mbus_frame_desc_entry->length field
+ * specifies maximum data length.
+ * @V4L2_MBUS_FRAME_DESC_FL_BLOB:
+ * Indicates that the format does not have line offsets, i.e.
+ * the receiver should use 1D DMA.
  */
-#define V4L2_MBUS_FRAME_DESC_FL_BLOB   (1U << 1)
+enum v4l2_mbus_frame_desc_flags {
+   V4L2_MBUS_FRAME_DESC_FL_LEN_MAX = BIT(0),
+   V4L2_MBUS_FRAME_DESC_FL_BLOB= BIT(1),
+};
 
 /**
  * struct v4l2_mbus_frame_desc_entry - media bus frame description structure
  *
- * @flags: bitmask flags: %V4L2_MBUS_FRAME_DESC_FL_LEN_MAX and
- *   %V4L2_MBUS_FRAME_DESC_FL_BLOB.
- * @pixelcode: media bus pixel code, valid if FRAME_DESC_FL_BLOB is not set
- * @length: number of octets per frame, valid if V4L2_MBUS_FRAME_DESC_FL_BLOB
- * is set
+ * @flags: bitmask flags, as defined by  v4l2_mbus_frame_desc_flags.
+ * @pixelcode: media bus pixel code, valid if @flags
+ * %FRAME_DESC_FL_BLOB is not set.
+ * @length:number of octets per frame, valid if @flags
+ * %V4L2_MBUS_FRAME_DESC_FL_LEN_MAX is set.
  */
 struct v4l2_mbus_frame_desc_entry {
-   u16 flags;
+   enum v4l2_mbus_frame_desc_flags flags;
u32 pixelcode;
u32 length;
 };
-- 
2.13.6

[PATCH 05/24] media: v4l2-dev: convert VFL_TYPE_* into an enum

[Mauro Carvalho Chehab]

Using enums makes easier to document, as it can use kernel-doc
markups. It also allows cross-referencing, with increases the
kAPI readability.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/kapi/v4l2-dev.rst | 17 ++---
 drivers/media/pci/cx88/cx88-blackbird.c   |  3 +-
 drivers/media/pci/cx88/cx88-video.c   | 10 +++---
 drivers/media/pci/cx88/cx88.h |  4 +--
 drivers/media/pci/saa7134/saa7134-video.c |  2 ++
 drivers/media/usb/cx231xx/cx231xx-video.c |  2 ++
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c  |  2 ++
 drivers/media/usb/tm6000/tm6000-video.c   |  2 ++
 drivers/media/v4l2-core/v4l2-dev.c| 10 +++---
 include/media/v4l2-dev.h  | 59 +--
 include/media/v4l2-mediabus.h | 30 
 11 files changed, 98 insertions(+), 43 deletions(-)

diff --git a/Documentation/media/kapi/v4l2-dev.rst 
b/Documentation/media/kapi/v4l2-dev.rst
index b29aa616c267..7bb0505b60f1 100644
--- a/Documentation/media/kapi/v4l2-dev.rst
+++ b/Documentation/media/kapi/v4l2-dev.rst
@@ -196,11 +196,18 @@ device.
 Which device is registered depends on the type argument. The following
 types exist:
 
-- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices
-- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed 
captions, teletext)
-- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners
-- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners
-- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors
+==  
==
+:c:type:`vfl_devnode_type` Device name  Usage
+==  
==
+``VFL_TYPE_GRABBER``   ``/dev/videoX``   for video input/output devices
+``VFL_TYPE_VBI``   ``/dev/vbiX`` for vertical blank data (i.e.
+closed captions, teletext)
+``VFL_TYPE_RADIO`` ``/dev/radioX``   for radio tuners
+``VFL_TYPE_SUBDEV````/dev/v4l-subdevX``  for V4L2 subdevices
+``VFL_TYPE_SDR``   ``/dev/swradioX`` for Software Defined Radio
+(SDR) tuners
+``VFL_TYPE_TOUCH`` ``/dev/v4l-touchX``   for touch sensors
+==  
==
 
 The last argument gives you a certain amount of control over the device
 device node number used (i.e. the X in ``videoX``). Normally you will pass -1
diff --git a/drivers/media/pci/cx88/cx88-blackbird.c 
b/drivers/media/pci/cx88/cx88-blackbird.c
index e3101f04941c..0e0952e60795 100644
--- a/drivers/media/pci/cx88/cx88-blackbird.c
+++ b/drivers/media/pci/cx88/cx88-blackbird.c
@@ -805,8 +805,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
 
strcpy(cap->driver, "cx88_blackbird");
sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
-   cx88_querycap(file, core, cap);
-   return 0;
+   return cx88_querycap(file, core, cap);
 }
 
 static int vidioc_enum_fmt_vid_cap(struct file *file, void  *priv,
diff --git a/drivers/media/pci/cx88/cx88-video.c 
b/drivers/media/pci/cx88/cx88-video.c
index 7d25ecd4404b..9be682cdb644 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -806,8 +806,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
return 0;
 }
 
-void cx88_querycap(struct file *file, struct cx88_core *core,
-  struct v4l2_capability *cap)
+int cx88_querycap(struct file *file, struct cx88_core *core,
+ struct v4l2_capability *cap)
 {
struct video_device *vdev = video_devdata(file);
 
@@ -825,11 +825,14 @@ void cx88_querycap(struct file *file, struct cx88_core 
*core,
case VFL_TYPE_VBI:
cap->device_caps |= V4L2_CAP_VBI_CAPTURE;
break;
+   default:
+   return -EINVAL;
}
cap->capabilities = cap->device_caps | V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_VBI_CAPTURE | V4L2_CAP_DEVICE_CAPS;
if (core->board.radio.type == CX88_RADIO)
cap->capabilities |= V4L2_CAP_RADIO;
+   return 0;
 }
 EXPORT_SYMBOL(cx88_querycap);
 
@@ -841,8 +844,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
 
strcpy(cap->driver, "cx8800");
sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
-   cx88_querycap(file, core, cap);
-   return 0;
+   return cx88_querycap(file, core, cap);
 }
 
 static int vidioc_enum_fmt_vid_cap(struct file *file, void  *priv,
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 6777926f20f2..07a33f02fef4 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -734,7 +734,7 @@ int cx8802_start_dma(struct cx8802_dev*dev,
 int 

[PATCH 16/24] media: v4l2-subdev: document remaining undocumented functions

[Mauro Carvalho Chehab]

There are several undocumented v4l2-subdev functions that are
part of kAPI. Document them.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 70 +
 1 file changed, 65 insertions(+), 5 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 35c4476c56ee..e215732eed45 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -868,6 +868,13 @@ struct v4l2_subdev {
struct v4l2_subdev_platform_data *pdata;
 };
 
+
+/**
+ * media_entity_to_v4l2_subdev - Returns a  v4l2_subdev from
+ * the  media_entity embedded on it.
+ *
+ * @ent: pointer to  media_entity.
+ */
 #define media_entity_to_v4l2_subdev(ent)   \
 ({ \
typeof(ent) __me_sd_ent = (ent);\
@@ -877,14 +884,20 @@ struct v4l2_subdev {
NULL;   \
 })
 
+/**
+ * vdev_to_v4l2_subdev - Returns a  v4l2_subdev from
+ * the  video_device embedded on it.
+ *
+ * @vdev: pointer to  video_device
+ */
 #define vdev_to_v4l2_subdev(vdev) \
((struct v4l2_subdev *)video_get_drvdata(vdev))
 
 /**
  * struct v4l2_subdev_fh - Used for storing subdev information per file handle
  *
- * @vfh: pointer to struct v4l2_fh
- * @pad: pointer to v4l2_subdev_pad_config
+ * @vfh: pointer to  v4l2_fh
+ * @pad: pointer to  v4l2_subdev_pad_config
  */
 struct v4l2_subdev_fh {
struct v4l2_fh vfh;
@@ -893,10 +906,25 @@ struct v4l2_subdev_fh {
 #endif
 };
 
+/**
+ * to_v4l2_subdev_fh - Returns a  v4l2_subdev_fh from
+ * the  v4l2_fh embedded on it.
+ *
+ * @fh: pointer to  v4l2_fh
+ */
 #define to_v4l2_subdev_fh(fh)  \
container_of(fh, struct v4l2_subdev_fh, vfh)
 
 #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
+
+/**
+ * v4l2_subdev_get_try_format - ancillary routine to call
+ *  v4l2_subdev_pad_config->try_fmt
+ *
+ * @sd: pointer to  v4l2_subdev
+ * @cfg: pointer to  v4l2_subdev_pad_config array.
+ * @pad: index of the pad a the @cfg array.
+ */
 static inline struct v4l2_mbus_framefmt
 *v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
@@ -906,6 +934,14 @@ static inline struct v4l2_mbus_framefmt
return [pad].try_fmt;
 }
 
+/**
+ * v4l2_subdev_get_try_crop - ancillary routine to call
+ *  v4l2_subdev_pad_config->try_crop
+ *
+ * @sd: pointer to  v4l2_subdev
+ * @cfg: pointer to  v4l2_subdev_pad_config array.
+ * @pad: index of the pad a the @cfg array.
+ */
 static inline struct v4l2_rect
 *v4l2_subdev_get_try_crop(struct v4l2_subdev *sd,
  struct v4l2_subdev_pad_config *cfg,
@@ -915,6 +951,14 @@ static inline struct v4l2_rect
return [pad].try_crop;
 }
 
+/**
+ * v4l2_subdev_get_try_crop - ancillary routine to call
+ *  v4l2_subdev_pad_config->try_compose
+ *
+ * @sd: pointer to  v4l2_subdev
+ * @cfg: pointer to  v4l2_subdev_pad_config array.
+ * @pad: index of the pad a the @cfg array.
+ */
 static inline struct v4l2_rect
 *v4l2_subdev_get_try_compose(struct v4l2_subdev *sd,
 struct v4l2_subdev_pad_config *cfg,
@@ -1030,9 +1074,17 @@ void v4l2_subdev_free_pad_config(struct 
v4l2_subdev_pad_config *cfg);
 void v4l2_subdev_init(struct v4l2_subdev *sd,
  const struct v4l2_subdev_ops *ops);
 
-/*
- * Call an ops of a v4l2_subdev, doing the right checks against
- * NULL pointers.
+/**
+ * v4l2_subdev_call - call an ops of a v4l2_subdev, doing the right checks
+ * against NULL pointers.
+ *
+ * @sd: pointer to the  v4l2_subdev
+ * @o: name of the element at  v4l2_subdev_ops that contains @f.
+ * Each element there groups a set of callbacks functions.
+ * @f: callback function that will be called if @cond matches.
+ * The callback functions are defined in groups, according to
+ * each element at  v4l2_subdev_ops.
+ * @args...: arguments for @f.
  *
  * Example: err = v4l2_subdev_call(sd, video, s_std, norm);
  */
@@ -1048,6 +1100,14 @@ void v4l2_subdev_init(struct v4l2_subdev *sd,
__result;   \
})
 
+/**
+ * v4l2_subdev_has_op - Checks if a subdev defines a certain ops.
+ *
+ * @sd: pointer to the  v4l2_subdev
+ * @o: name of the element at  v4l2_subdev_ops that contains @f.
+ * Each element there groups a set of callbacks functions.
+ * @f: callback function to be checked for its existence.
+ */
 #define v4l2_subdev_has_op(sd, o, f) \
((sd)->ops->o && (sd)->ops->o->f)
 
-- 
2.13.6

[PATCH 09/24] media: v4l2-dev: document video_device flags

[Mauro Carvalho Chehab]

Convert #defines to enums and add kernel-doc markups for V4L2
video_device flags.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-dev.h | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 87dac58c7799..33a5256232f8 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -61,12 +61,22 @@ struct video_device;
 struct v4l2_device;
 struct v4l2_ctrl_handler;
 
-/* Flag to mark the video_device struct as registered.
-   Drivers can clear this flag if they want to block all future
-   device access. It is cleared by video_unregister_device. */
-#define V4L2_FL_REGISTERED (0)
-/* file->private_data points to struct v4l2_fh */
-#define V4L2_FL_USES_V4L2_FH   (1)
+/**
+ * enum v4l2_video_device_flags - Flags used by  video_device
+ *
+ * @V4L2_FL_REGISTERED:
+ * indicates that a  video_device is registered.
+ * Drivers can clear this flag if they want to block all future
+ * device access. It is cleared by video_unregister_device.
+ * @V4L2_FL_USES_V4L2_FH:
+ * indicates that file->private_data points to  v4l2_fh.
+ * This flag is set by the core when v4l2_fh_init() is called.
+ * All new drivers should use it.
+ */
+enum v4l2_video_device_flags {
+   V4L2_FL_REGISTERED  = 0,
+   V4L2_FL_USES_V4L2_FH= 1,
+};
 
 /* Priority helper functions */
 
@@ -214,7 +224,8 @@ struct v4l2_file_operations {
  * @vfl_dir: V4L receiver, transmitter or m2m
  * @minor: device node 'minor'. It is set to -1 if the registration failed
  * @num: number of the video device node
- * @flags: video device flags. Use bitops to set/clear/test flags
+ * @flags: video device flags. Use bitops to set/clear/test flags.
+ *Contains a set of  v4l2_video_device_flags.
  * @index: attribute to differentiate multiple indices on one physical device
  * @fh_lock: Lock for all v4l2_fhs
  * @fh_list: List of  v4l2_fh
-- 
2.13.6

Re: [PATCH v3 3/5] media: atmel-isc: Enable the clocks during probe

[Yang, Wenyou]

Hi Sakari,

On 2017/10/9 15:58, Sakari Ailus wrote:

Hi
Wenyou,

On Mon, Oct 09, 2017 at 01:49:44PM +0800, Yang, Wenyou wrote:

Hi Sakari,

Sorry for late answer, because I was in vacation last week.

On 2017/9/29 5:25, Sakari Ailus wrote:

Hi Wenyou,

On Thu, Sep 28, 2017 at 04:18:26PM +0800, Wenyou Yang wrote:

To meet the relationship, enable the HCLOCK and ispck during the
device probe, "isc_pck frequency is less than or equal to isc_ispck,
and isc_ispck is greater than or equal to HCLOCK."
Meanwhile, call the pm_runtime_enable() in the right place.

Signed-off-by: Wenyou Yang 
---

Changes in v3: None
Changes in v2: None

   drivers/media/platform/atmel/atmel-isc.c | 31 +--
   1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 0b15dc1a3a0b..f092c95587c1 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1594,6 +1594,7 @@ static int isc_async_complete(struct v4l2_async_notifier 
*notifier)
struct isc_subdev_entity *sd_entity;
struct video_device *vdev = >video_dev;
struct vb2_queue *q = >vb2_vidq;
+   struct device *dev = isc->dev;
int ret;
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
@@ -1677,6 +1678,10 @@ static int isc_async_complete(struct v4l2_async_notifier 
*notifier)
return ret;
}
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+   pm_request_idle(dev);

Remember that the driver's async complete function could never get called.

What would be the reason to move it here?

The ISC provides the clock for the sensor, namely, it is the clock provider
for the external sensor.
So it keeps active to make the sensor probe successfully.
Otherwise, the sensor, such as 0v7670 fails to probe due to the failure to
clk_enable().

You'll still need to balance the get and put calls.

complete callback is not necessarily called at all or could be called
multiple times. Instead, you should probably do pm_runtime_get_sync() when
the clock is enabled and put when it's disabled.

I will send v4 to update it.

Thank you for your advice.

Best Regards,
Wenyou Yang

Re: [PATCH v2 18/25] media: lirc: implement reading scancode

[Hans Verkuil]

On 05/10/17 10:45, Sean Young wrote:
> This implements LIRC_MODE_SCANCODE reading from the lirc device. The
> scancode can be read from the input device too, but with this interface
> you get the rc protocol, toggle and repeat status in addition too just

too -> to

Regards,

Hans

> the scancode.
> 
> int main()
> {
>   int fd, mode, rc;
>   fd = open("/dev/lirc0", O_RDWR);
> 
>   mode = LIRC_MODE_SCANCODE;
>   if (ioctl(fd, LIRC_SET_REC_MODE, )) {
>   // kernel too old or lirc does not support transmit
>   }
>   struct lirc_scancode scancode;
>   while (read(fd, , sizeof(scancode)) == sizeof(scancode)) {
>   printf("protocol:%d scancode:0x%x toggle:%d repeat:%d\n",
>   scancode.rc_proto, scancode.scancode,
>   !!(scancode.flags & LIRC_SCANCODE_FLAG_TOGGLE),
>   !!(scancode.flags & LIRC_SCANCODE_FLAG_REPEAT));
>   }
>   close(fd);
> }
> 
> Note that the translated KEY_* is not included, that information is
> published to the input device.

Re: [PATCH 07/19] lirc_dev: remove kmalloc in lirc_dev_fop_read()

[David Härdeman]

October 4, 2017 6:57 PM, "Mauro Carvalho Chehab"  
wrote:

> Em Sun, 25 Jun 2017 14:31:50 +0200
> David Härdeman  escreveu:
> 
>> lirc_zilog uses a chunk_size of 2 and ir-lirc-codec uses sizeof(int).
>> 
>> Therefore, using stack memory should be perfectly fine.
>> 
>> Signed-off-by: David Härdeman 
>> ---
>> drivers/media/rc/lirc_dev.c | 8 +---
>> 1 file changed, 1 insertion(+), 7 deletions(-)
>> 
>> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
>> index 1773a2934484..92048d945ba7 100644
>> --- a/drivers/media/rc/lirc_dev.c
>> +++ b/drivers/media/rc/lirc_dev.c
>> @@ -376,7 +376,7 @@ ssize_t lirc_dev_fop_read(struct file *file,
>> loff_t *ppos)
>> {
>> struct irctl *ir = file->private_data;
>> - unsigned char *buf;
>> + unsigned char buf[ir->buf->chunk_size];
> 
> No. We don't do dynamic buffer allocation on stak at the Kernel,
> as this could cause the Linux stack to overflow without notice.

While the general policy is to avoid large stack allocations (in order to not 
overflow the 4K stack), I'm not aware of a general ban on *any* stack 
allocations - that sounds like an overly dogmatic approach. If such a generic 
ban exists, could you please point me to some kind of discussion/message to 
that effect?

The commit message clearly explained what kind of stack allocations we're 
talking about here (i.e. sizeof(int) is the maximum), so the stack allocation 
is clearly not able to cause stack overflows. And once the last lirc driver is 
gone, this can be changed to a simple int (which would also be allocated on 
stack).

Regards,
David

Re: [PATCH] [media] ov5645: I2C address change

[Sakari Ailus]

Hi Todor,

On Mon, Oct 09, 2017 at 11:36:01AM +0300, Todor Tomov wrote:
> Hi Sakari,
> 
> On  4.10.2017 13:47, Laurent Pinchart wrote:
> > CC'ing the I2C mainling list and the I2C maintainer.
> > 
> > On Wednesday, 4 October 2017 13:30:08 EEST Sakari Ailus wrote:
> >> Hi Todor,
> >>
> >> On Mon, Oct 02, 2017 at 04:28:45PM +0300, Todor Tomov wrote:
> >>> As soon as the sensor is powered on, change the I2C address to the one
> >>> specified in DT. This allows to use multiple physical sensors connected
> >>> to the same I2C bus.
> >>>
> >>> Signed-off-by: Todor Tomov 
> >>
> >> The smiapp driver does something similar and I understand Laurent might be
> >> interested in such functionality as well.
> >>
> >> It'd be nice to handle this through the I²C framework instead and to define
> >> how the information is specified through DT. That way it could be made
> >> generic, to work with more devices than just this one.
> >>
> >> What do you think?
> 
> Thank you for this suggestion.
> 
> The way I have done it is to put the new I2C address in the DT and the driver
> programs the change using the original I2C address. The original I2C address
> is hardcoded in the driver. So maybe we can extend the DT binding and the I2C
> framework so that both addresses come from the DT and avoid hiding the
> original I2C address in the driver. This sounds good to me.

Agreed.

In this case the address is known but in general that's not the case it's
not that simple. There are register compatible devices that have different
addresses even if they're the same devices.

It might be a good idea to make this explicit.

> 
> Then changing the address could be device specific and also this must be done
> right after power on so that there are no address conflicts. So I don't think
> that we can support this through the I2C framework only, the drivers that we
> want to do that will have to be expanded with this functionality. Or do you
> have any other idea?

Yes, how the address is changed is always hardware specific. This would be
most conveniently done in driver's probe or PM runtime_resume functions.

It could be as simple as providing an adapter specific mutex to serialise
address changes on the bus so that no two address changes are taking place
at the same time. Which is essentially the impliementation you had, only
the mutex would be for the I²C adapter, not the driver. An helper functions
for acquiring and releasing the mutex.

I wonder what others think.

-- 
Regards,

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

Re: [PATCH v2 10/25] media: lirc: validate scancode for transmit

[Hans Verkuil]

On 05/10/17 10:45, Sean Young wrote:
> Ensure we reject an attempt to transmit invalid scancodes.
> 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/ir-lirc-codec.c |  3 +++
>  drivers/media/rc/rc-core-priv.h  |  1 +
>  drivers/media/rc/rc-main.c   | 53 
> +---
>  3 files changed, 37 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index 94561d8b0c0b..863d975d40fb 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -122,6 +122,9 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   scan.timestamp)
>   return -EINVAL;
>  
> + if (!rc_validate_scancode(scan.rc_proto, scan.scancode))
> + return -EINVAL;
> +
>   if (dev->tx_scancode) {
>   ret = dev->tx_scancode(dev, );
>   return ret < 0 ? ret : n;
> diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
> index 21e515d34f64..a064c401fa38 100644
> --- a/drivers/media/rc/rc-core-priv.h
> +++ b/drivers/media/rc/rc-core-priv.h
> @@ -160,6 +160,7 @@ static inline bool is_timing_event(struct ir_raw_event ev)
>  #define TO_STR(is_pulse) ((is_pulse) ? "pulse" : "space")
>  
>  /* functions for IR encoders */
> +bool rc_validate_scancode(enum rc_proto proto, u32 scancode);
>  
>  static inline void init_ir_raw_event_duration(struct ir_raw_event *ev,
> unsigned int pulse,
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 758c14b90a87..38393f13822f 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -776,6 +776,37 @@ void rc_keydown_notimeout(struct rc_dev *dev, enum 
> rc_proto protocol,
>  EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
>  
>  /**
> + * rc_validate_scancode() - checks that a scancode is valid for a protocol
> + * @proto:   protocol
> + * @scancode:scancode
> + */
> +bool rc_validate_scancode(enum rc_proto proto, u32 scancode)

The scancode in struct lirc_scancode is a u64. Shouldn't this be a u64 as well?

> +{
> + switch (proto) {
> + case RC_PROTO_NECX:
> + if scancode >> 16) ^ ~(scancode >> 8)) & 0xff) == 0)
> + return false;
> + break;
> + case RC_PROTO_NEC32:
> + if scancode >> 24) ^ ~(scancode >> 16)) & 0xff) == 0)
> + return false;
> + break;
> + case RC_PROTO_RC6_MCE:
> + if ((scancode & 0x) != 0x800f)
> + return false;
> + break;
> + case RC_PROTO_RC6_6A_32:
> + if ((scancode & 0x) == 0x800f)
> + return false;

I think that some comments explaining what is tested here would be useful.

This can be done in a separate patch, or done here.

Regards,

Hans

> + break;
> + default:
> + break;
> + }
> +
> + return true;
> +}
> +
> +/**
>   * rc_validate_filter() - checks that the scancode and mask are valid and
>   * provides sensible defaults
>   * @dev: the struct rc_dev descriptor of the device
> @@ -793,26 +824,8 @@ static int rc_validate_filter(struct rc_dev *dev,
>  
>   mask = protocols[protocol].scancode_bits;
>  
> - switch (protocol) {
> - case RC_PROTO_NECX:
> - if s >> 16) ^ ~(s >> 8)) & 0xff) == 0)
> - return -EINVAL;
> - break;
> - case RC_PROTO_NEC32:
> - if s >> 24) ^ ~(s >> 16)) & 0xff) == 0)
> - return -EINVAL;
> - break;
> - case RC_PROTO_RC6_MCE:
> - if ((s & 0x) != 0x800f)
> - return -EINVAL;
> - break;
> - case RC_PROTO_RC6_6A_32:
> - if ((s & 0x) == 0x800f)
> - return -EINVAL;
> - break;
> - default:
> - break;
> - }
> + if (!rc_validate_scancode(protocol, s))
> + return -EINVAL;
>  
>   filter->data &= mask;
>   filter->mask &= mask;
> 

Re: [PATCH v2 01/25] media: lirc: implement scancode sending

[Hans Verkuil]

On 05/10/17 10:45, Sean Young wrote:
> This introduces a new lirc mode: scancode. Any device which can send raw IR
> can now also send scancodes.
> 
> int main()
> {
>   int mode, fd = open("/dev/lirc0", O_RDWR);
> 
> mode = LIRC_MODE_SCANCODE;
>   if (ioctl(fd, LIRC_SET_SEND_MODE, )) {
>   // kernel too old or lirc does not support transmit
>   }
>   struct lirc_scancode scancode = {
>   .scancode = 0x1e3d,
>   .rc_proto = RC_PROTO_RC5,
>   };
>   write(fd, , sizeof(scancode));
>   close(fd);
> }
> 
> The other fields of lirc_scancode must be set to 0.
> 
> Note that toggle (rc5, rc6) and repeats (nec) are not implemented. Nor is
> there a method for holding down a key for a period.
> 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/ir-lirc-codec.c | 101 
> ---
>  drivers/media/rc/rc-core-priv.h  |   2 +-
>  include/media/rc-map.h   |  54 +
>  include/uapi/linux/lirc.h|  93 +++
>  4 files changed, 169 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index bd046c41a53a..ef0b8df88613 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -107,7 +107,8 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>  {
>   struct lirc_codec *lirc;
>   struct rc_dev *dev;
> - unsigned int *txbuf; /* buffer with values to transmit */
> + unsigned int *txbuf = NULL;
> + struct ir_raw_event *raw = NULL;
>   ssize_t ret = -EINVAL;
>   size_t count;
>   ktime_t start;
> @@ -121,16 +122,51 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   if (!lirc)
>   return -EFAULT;
>  
> - if (n < sizeof(unsigned) || n % sizeof(unsigned))
> - return -EINVAL;
> + if (lirc->send_mode == LIRC_MODE_SCANCODE) {
> + struct lirc_scancode scan;
>  
> - count = n / sizeof(unsigned);
> - if (count > LIRCBUF_SIZE || count % 2 == 0)
> - return -EINVAL;
> + if (n != sizeof(scan))
> + return -EINVAL;
>  
> - txbuf = memdup_user(buf, n);
> - if (IS_ERR(txbuf))
> - return PTR_ERR(txbuf);
> + if (copy_from_user(, buf, sizeof(scan)))
> + return -EFAULT;
> +
> + if (scan.flags || scan.source || scan.target || scan.unused ||
> + scan.timestamp)
> + return -EINVAL;
> +
> + raw = kmalloc_array(LIRCBUF_SIZE, sizeof(*raw), GFP_KERNEL);
> + if (!raw)
> + return -ENOMEM;
> +
> + ret = ir_raw_encode_scancode(scan.rc_proto, scan.scancode,
> +  raw, LIRCBUF_SIZE);
> + if (ret < 0)
> + goto out;
> +
> + count = ret;
> +
> + txbuf = kmalloc_array(count, sizeof(unsigned int), GFP_KERNEL);
> + if (!txbuf) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + for (i = 0; i < count; i++)
> + /* Convert from NS to US */
> + txbuf[i] = DIV_ROUND_UP(raw[i].duration, 1000);
> + } else {
> + if (n < sizeof(unsigned int) || n % sizeof(unsigned int))
> + return -EINVAL;
> +
> + count = n / sizeof(unsigned int);
> + if (count > LIRCBUF_SIZE || count % 2 == 0)
> + return -EINVAL;
> +
> + txbuf = memdup_user(buf, n);
> + if (IS_ERR(txbuf))
> + return PTR_ERR(txbuf);
> + }
>  
>   dev = lirc->dev;
>   if (!dev) {
> @@ -156,24 +192,31 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   if (ret < 0)
>   goto out;
>  
> - for (duration = i = 0; i < ret; i++)
> - duration += txbuf[i];
> -
> - ret *= sizeof(unsigned int);
> -
> - /*
> -  * The lircd gap calculation expects the write function to
> -  * wait for the actual IR signal to be transmitted before
> -  * returning.
> -  */
> - towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
> - if (towait > 0) {
> - set_current_state(TASK_INTERRUPTIBLE);
> - schedule_timeout(usecs_to_jiffies(towait));
> + if (lirc->send_mode == LIRC_MODE_SCANCODE) {
> + ret = n;
> + } else {
> + for (duration = i = 0; i < ret; i++)
> + duration += txbuf[i];
> +
> +
> + ret *= sizeof(unsigned int);
> +
> + /*
> +  * The lircd gap calculation expects the write function to
> +  * wait for the actual IR signal to be transmitted before

[PATCH v11 0/4] Add Rockchip RGA V4l2 support

[Jacob Chen]

change in V11:
- fix compile warning

change in V10:
- move to rockchip/rga
- changes according to comments
- some style changes

change in V9:
- remove protduff things
- test with the latest v4l2-compliance

change in V8:
- remove protduff things

change in V6,V7:
- correct warning in checkpatch.pl

change in V5:
- v4l2-compliance: handle invalid pxielformat
- v4l2-compliance: add subscribe_event
- add colorspace support

change in V4:
- document the controls.
- change according to Hans's comments

change in V3:
- rename the controls.
- add pm_runtime support.
- enable node by default.
- correct spelling in documents.

change in V2:
- generalize the controls.
- map buffers (10-50 us) in every cmd-run rather than in buffer-import to avoid 
get_free_pages failed on
actively used systems.
- remove status in dt-bindings examples.

Jacob Chen (4):
  rockchip/rga: v4l2 m2m support
  ARM: dts: rockchip: add RGA device node for RK3288
  arm64: dts: rockchip: add RGA device node for RK3399
  dt-bindings: Document the Rockchip RGA bindings

 .../devicetree/bindings/media/rockchip-rga.txt |   33 +
 arch/arm/boot/dts/rk3288.dtsi  |   11 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   11 +
 drivers/media/platform/Kconfig |   15 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/rockchip/rga/Makefile   |3 +
 drivers/media/platform/rockchip/rga/rga-buf.c  |  154 +++
 drivers/media/platform/rockchip/rga/rga-hw.c   |  421 
 drivers/media/platform/rockchip/rga/rga-hw.h   |  437 +
 drivers/media/platform/rockchip/rga/rga.c  | 1012 
 drivers/media/platform/rockchip/rga/rga.h  |  123 +++
 11 files changed,  insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
 create mode 100644 drivers/media/platform/rockchip/rga/Makefile
 create mode 100644 drivers/media/platform/rockchip/rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip/rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip/rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip/rga/rga.c
 create mode 100644 drivers/media/platform/rockchip/rga/rga.h

-- 
2.14.1

[PATCH v11 4/4] dt-bindings: Document the Rockchip RGA bindings

[Jacob Chen]

Add DT bindings documentation for Rockchip RGA

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/rockchip-rga.txt | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt

diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt 
b/Documentation/devicetree/bindings/media/rockchip-rga.txt
new file mode 100644
index ..fd5276abfad6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
@@ -0,0 +1,33 @@
+device-tree bindings for rockchip 2D raster graphic acceleration controller 
(RGA)
+
+RGA is a standalone 2D raster graphic acceleration unit. It accelerates 2D
+graphics operations, such as point/line drawing, image scaling, rotation,
+BitBLT, alpha blending and image blur/sharpness.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-rga";
+   "rockchip,rk3399-rga";
+
+- interrupts: RGA interrupt specifier.
+
+- clocks: phandle to RGA sclk/hclk/aclk clocks
+
+- clock-names: should be "aclk", "hclk" and "sclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: should be "core", "axi" and "ahb"
+
+Example:
+SoC-specific DT entry:
+   rga: rga@ff68 {
+   compatible = "rockchip,rk3399-rga";
+   reg = <0xff68 0x1>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
+   clock-names = "aclk", "hclk", "sclk";
+
+   resets = < SRST_RGA_CORE>, < SRST_A_RGA>, < 
SRST_H_RGA>;
+   reset-names = "core, "axi", "ahb";
+   };
-- 
2.14.1

[PATCH v11 2/4] ARM: dts: rockchip: add RGA device node for RK3288

[Jacob Chen]

This patch add the RGA dt config of rk3288 SoC.

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index a0a0b08bff74..8c6dfc0abc42 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -972,6 +972,17 @@
status = "disabled";
};
 
+   rga: rga@ff92 {
+   compatible = "rockchip,rk3288-rga";
+   reg = <0x0 0xff92 0x0 0x180>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA>;
+   clock-names = "aclk", "hclk", "sclk";
+   power-domains = < RK3288_PD_VIO>;
+   resets = < SRST_RGA_CORE>, < SRST_RGA_AXI>, < 
SRST_RGA_AHB>;
+   reset-names = "core", "axi", "ahb";
+   };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0x0 0xff93 0x0 0x19c>;
-- 
2.14.1

[PATCH v11 3/4] arm64: dts: rockchip: add RGA device node for RK3399

[Jacob Chen]

This patch add the RGA dt config of RK3399 SoC.

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d79e9b3265b9..a3fab6af5a17 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1204,6 +1204,17 @@
status = "disabled";
};
 
+   rga: rga@ff68 {
+   compatible = "rockchip,rk3399-rga";
+   reg = <0x0 0xff68 0x0 0x1>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
+   clock-names = "aclk", "hclk", "sclk";
+   resets = < SRST_RGA_CORE>, < SRST_A_RGA>, < 
SRST_H_RGA>;
+   reset-names = "core", "axi", "ahb";
+   power-domains = < RK3399_PD_RGA>;
+   };
+
efuse0: efuse@ff69 {
compatible = "rockchip,rk3399-efuse";
reg = <0x0 0xff69 0x0 0x80>;
-- 
2.14.1