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:   Wed Mar 22 05:00:16 CET 2017
media-tree git hash:700ea5e0e0dd70420a04e703ff264cc133834cba
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: 5fe0692261996876dceedbd47f254691371d4c78
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
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: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
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-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
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: ERRORS
linux-3.12.67-x86_64: ERRORS
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-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH 1/3] staging: media: Replace a bit shift by a use of BIT.

[Arushi Singhal]

This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 .../staging/media/atomisp/pci/atomisp2/atomisp_cmd.c   | 12 ++--
 .../media/atomisp/pci/atomisp2/atomisp_compat_css20.c  |  6 +++---
 .../staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c |  6 +++---
 .../staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c  | 18 +-
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c|  2 +-
 5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 94bc7938f533..63e79a23fe7e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -194,7 +194,7 @@ static int write_target_freq_to_hw(struct atomisp_device 
*isp,
if (isp_sspm1 & ISP_FREQ_VALID_MASK) {
dev_dbg(isp->dev, "clearing ISPSSPM1 valid bit.\n");
intel_mid_msgbus_write32(PUNIT_PORT, ISPSSPM1,
-   isp_sspm1 & ~(1 << ISP_FREQ_VALID_OFFSET));
+   isp_sspm1 & ~(BIT(ISP_FREQ_VALID_OFFSET)));
}
 
ratio = (2 * isp->hpll_freq + new_freq / 2) / new_freq - 1;
@@ -207,7 +207,7 @@ static int write_target_freq_to_hw(struct atomisp_device 
*isp,
intel_mid_msgbus_write32(PUNIT_PORT, ISPSSPM1,
   isp_sspm1
   | ratio << ISP_REQ_FREQ_OFFSET
-  | 1 << ISP_FREQ_VALID_OFFSET
+  | BIT(ISP_FREQ_VALID_OFFSET)
   | guar_ratio << ISP_REQ_GUAR_FREQ_OFFSET);
 
isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT, ISPSSPM1);
@@ -417,10 +417,10 @@ void atomisp_msi_irq_init(struct atomisp_device *isp, 
struct pci_dev *dev)
u16 msg16;
 
pci_read_config_dword(dev, PCI_MSI_CAPID, );
-   msg32 |= 1 << MSI_ENABLE_BIT;
+   msg32 |= BIT(MSI_ENABLE_BIT);
pci_write_config_dword(dev, PCI_MSI_CAPID, msg32);
 
-   msg32 = (1 << INTR_IER) | (1 << INTR_IIR);
+   msg32 = (BIT(INTR_IER)) | (BIT(INTR_IIR));
pci_write_config_dword(dev, PCI_INTERRUPT_CTRL, msg32);
 
pci_read_config_word(dev, PCI_COMMAND, );
@@ -435,7 +435,7 @@ void atomisp_msi_irq_uninit(struct atomisp_device *isp, 
struct pci_dev *dev)
u16 msg16;
 
pci_read_config_dword(dev, PCI_MSI_CAPID, );
-   msg32 &=  ~(1 << MSI_ENABLE_BIT);
+   msg32 &=  ~(BIT(MSI_ENABLE_BIT));
pci_write_config_dword(dev, PCI_MSI_CAPID, msg32);
 
msg32 = 0x0;
@@ -536,7 +536,7 @@ static void clear_irq_reg(struct atomisp_device *isp)
 {
u32 msg_ret;
pci_read_config_dword(isp->pdev, PCI_INTERRUPT_CTRL, _ret);
-   msg_ret |= 1 << INTR_IIR;
+   msg_ret |= BIT(INTR_IIR);
pci_write_config_dword(isp->pdev, PCI_INTERRUPT_CTRL, msg_ret);
 }
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
index 2e20a81091f4..a3acd99a02e9 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
@@ -2017,11 +2017,11 @@ void atomisp_css_input_set_mode(struct 
atomisp_sub_device *asd,

>stream_env[ATOMISP_INPUT_STREAM_GENERAL].stream_config;
s_config->mode = IA_CSS_INPUT_MODE_TPG;
s_config->source.tpg.mode = IA_CSS_TPG_MODE_CHECKERBOARD;
-   s_config->source.tpg.x_mask = (1 << 4) - 1;
+   s_config->source.tpg.x_mask = (BIT(4)) - 1;
s_config->source.tpg.x_delta = -2;
-   s_config->source.tpg.y_mask = (1 << 4) - 1;
+   s_config->source.tpg.y_mask = (BIT(4)) - 1;
s_config->source.tpg.y_delta = 3;
-   s_config->source.tpg.xy_mask = (1 << 8) - 1;
+   s_config->source.tpg.xy_mask = (BIT(8)) - 1;
return;
}
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
index fcfe8d7190b0..44736a39cda5 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
@@ -44,9 +44,9 @@ struct _iunit_debug {
unsigned intdbgopt;
 };
 
-#define OPTION_BIN_LIST(1<<0)
-#define OPTION_BIN_RUN (1<<1)
-#define OPTION_MEM_STAT(1<<2)
+#define OPTION_BIN_LIST(BIT(0))
+#define OPTION_BIN_RUN (BIT(1))
+#define OPTION_MEM_STAT(BIT(2))
 #define OPTION_VALID   

[PATCH 3/3] staging: media: omap4iss: Replace a bit shift by a use of BIT.

[Arushi Singhal]

This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/media/omap4iss/iss_csi2.c| 2 +-
 drivers/staging/media/omap4iss/iss_ipipe.c   | 2 +-
 drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +-
 drivers/staging/media/omap4iss/iss_resizer.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss_csi2.c 
b/drivers/staging/media/omap4iss/iss_csi2.c
index f71d5f2f179f..f6acc541e8a2 100644
--- a/drivers/staging/media/omap4iss/iss_csi2.c
+++ b/drivers/staging/media/omap4iss/iss_csi2.c
@@ -1268,7 +1268,7 @@ static int csi2_init_entities(struct iss_csi2_device 
*csi2, const char *subname)
snprintf(name, sizeof(name), "CSI2%s", subname);
snprintf(sd->name, sizeof(sd->name), "OMAP4 ISS %s", name);
 
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, csi2);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c 
b/drivers/staging/media/omap4iss/iss_ipipe.c
index d38782e8e84c..d86ef8a031f2 100644
--- a/drivers/staging/media/omap4iss/iss_ipipe.c
+++ b/drivers/staging/media/omap4iss/iss_ipipe.c
@@ -508,7 +508,7 @@ static int ipipe_init_entities(struct iss_ipipe_device 
*ipipe)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP IPIPE", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, ipipe);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c 
b/drivers/staging/media/omap4iss/iss_ipipeif.c
index 23de8330731d..cb88b2bd0d82 100644
--- a/drivers/staging/media/omap4iss/iss_ipipeif.c
+++ b/drivers/staging/media/omap4iss/iss_ipipeif.c
@@ -739,7 +739,7 @@ static int ipipeif_init_entities(struct iss_ipipeif_device 
*ipipeif)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP IPIPEIF", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, ipipeif);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_resizer.c 
b/drivers/staging/media/omap4iss/iss_resizer.c
index f1d352c711d5..4bbfa20b3c38 100644
--- a/drivers/staging/media/omap4iss/iss_resizer.c
+++ b/drivers/staging/media/omap4iss/iss_resizer.c
@@ -782,7 +782,7 @@ static int resizer_init_entities(struct iss_resizer_device 
*resizer)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP resizer", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, resizer);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
-- 
2.11.0

[PATCH 2/3] staging: media: davinci_vpfe: Replace a bit shift by a use of BIT.

[Arushi Singhal]

This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_isif.c| 26 +++---
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  6 ++---
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 6a3434cebd79..7eeb53217168 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1815,7 +1815,7 @@ vpfe_ipipe_init(struct vpfe_ipipe_device *ipipe, struct 
platform_device *pdev)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI IPIPE", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for davinci subdevs */
+   sd->grp_id = BIT(16);   /* group ID for davinci subdevs */
v4l2_set_subdevdata(sd, ipipe);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
index 46fd2c7f69c3..c07f028dd6be 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
@@ -1021,7 +1021,7 @@ int vpfe_ipipeif_init(struct vpfe_ipipeif_device *ipipeif,
 
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI IPIPEIF", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for davinci subdevs */
+   sd->grp_id = BIT(16);   /* group ID for davinci subdevs */
 
v4l2_set_subdevdata(sd, ipipeif);
 
diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c 
b/drivers/staging/media/davinci_vpfe/dm365_isif.c
index 569bcdc9ce2f..0d160c1257d2 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_isif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_isif.c
@@ -821,7 +821,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
 
/* Correct whole line or partial */
if (vdfc->corr_whole_line)
-   val |= 1 << ISIF_VDFC_CORR_WHOLE_LN_SHIFT;
+   val |= BIT(ISIF_VDFC_CORR_WHOLE_LN_SHIFT);
 
/* level shift value */
val |= (vdfc->def_level_shift & ISIF_VDFC_LEVEL_SHFT_MASK) <<
@@ -849,7 +849,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
 
val = isif_read(isif->isif_cfg.base_addr, DFCMEMCTL);
/* set DFCMARST and set DFCMWR */
-   val |= 1 << ISIF_DFCMEMCTL_DFCMARST_SHIFT;
+   val |= BIT(ISIF_DFCMEMCTL_DFCMARST_SHIFT);
val |= 1;
isif_write(isif->isif_cfg.base_addr, val, DFCMEMCTL);
 
@@ -880,7 +880,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
}
val = isif_read(isif->isif_cfg.base_addr, DFCMEMCTL);
/* clear DFCMARST and set DFCMWR */
-   val &= ~(1 << ISIF_DFCMEMCTL_DFCMARST_SHIFT);
+   val &= ~(BIT(ISIF_DFCMEMCTL_DFCMARST_SHIFT));
val |= 1;
isif_write(isif->isif_cfg.base_addr, val, DFCMEMCTL);
 
@@ -904,10 +904,10 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
   DM365_ISIF_DFCMWR_MEMORY_WRITE, DFCMEMCTL);
}
/* enable VDFC */
-   isif_merge(isif->isif_cfg.base_addr, (1 << ISIF_VDFC_EN_SHIFT),
-  (1 << ISIF_VDFC_EN_SHIFT), DFCCTL);
+   isif_merge(isif->isif_cfg.base_addr, (BIT(ISIF_VDFC_EN_SHIFT)),
+  (BIT(ISIF_VDFC_EN_SHIFT)), DFCCTL);
 
-   isif_merge(isif->isif_cfg.base_addr, (1 << ISIF_VDFC_EN_SHIFT),
+   isif_merge(isif->isif_cfg.base_addr, (BIT(ISIF_VDFC_EN_SHIFT)),
   (0 << ISIF_VDFC_EN_SHIFT), DFCCTL);
 
isif_write(isif->isif_cfg.base_addr, 0x6, DFCMEMCTL);
@@ -1140,7 +1140,7 @@ static int isif_config_raw(struct v4l2_subdev *sd, int 
mode)
isif_write(isif->isif_cfg.base_addr, val, CGAMMAWD);
/* Configure DPCM compression settings */
if (params->v4l2_pix_fmt == V4L2_PIX_FMT_SGRBG10DPCM8) {
-   val =  1 << ISIF_DPCM_EN_SHIFT;
+   val =  BIT(ISIF_DPCM_EN_SHIFT);
val |= (params->dpcm_predictor &
ISIF_DPCM_PREDICTOR_MASK) << ISIF_DPCM_PREDICTOR_SHIFT;
}
@@ -1893,7 +1893,7 @@ static const struct v4l2_ctrl_config vpfe_isif_crgain = {
.name = "CRGAIN",
.type = V4L2_CTRL_TYPE_INTEGER,
.min = 0,
-   .max = (1 << 12) - 1,
+   .max = (BIT(12)) - 1,
.step = 1,
.def = 0,
 };
@@ -1904,7 +1904,7 @@ static const struct v4l2_ctrl_config vpfe_isif_cgrgain = {
.name = "CGRGAIN",
 

[PATCH 0/3] staging: media: Replace a bit shift.

[Arushi Singhal]

Replace a bit shift by a use of BIT in media driver.

Arushi Singhal (3):
  staging: media: Replace a bit shift by a use of BIT.
  staging: media: davinci_vpfe: Replace a bit shift by a use of BIT.
  staging: media: omap4iss: Replace a bit shift by a use of BIT.

 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 12 +-
 .../atomisp/pci/atomisp2/atomisp_compat_css20.c|  6 ++---
 .../media/atomisp/pci/atomisp2/atomisp_drvfs.c |  6 ++---
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  | 18 +++
 .../media/atomisp/pci/atomisp2/hmm/hmm_bo.c|  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_isif.c| 26 +++---
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  6 ++---
 drivers/staging/media/omap4iss/iss_csi2.c  |  2 +-
 drivers/staging/media/omap4iss/iss_ipipe.c |  2 +-
 drivers/staging/media/omap4iss/iss_ipipeif.c   |  2 +-
 drivers/staging/media/omap4iss/iss_resizer.c   |  2 +-
 13 files changed, 44 insertions(+), 44 deletions(-)

-- 
2.11.0

[PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

[Eddie Youseph]

Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Eddie Youseph 
---
Changes in v2:
- Added changelog

 drivers/staging/media/bcm2048/radio-bcm2048.c | 44 +--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index d605c41..7d33bce 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2020,27 +2020,27 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
return count;   \
 }
 
-DEFINE_SYSFS_PROPERTY(power_state, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(mute, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(audio_route, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(dac_output, unsigned, int, "%u", 0)
-
-DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned, int, "%u", value > 3)
-
-DEFINE_SYSFS_PROPERTY(rds, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_wline, unsigned, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
+
+DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned int, int, "%u", value > 3)
+
+DEFINE_SYSFS_PROPERTY(rds, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_wline, unsigned int, int, "%u", 0)
 property_read(rds_pi, unsigned int, "%x")
 property_str_read(rds_rt, (BCM2048_MAX_RDS_RT + 1))
 property_str_read(rds_ps, (BCM2048_MAX_RDS_PS + 1))
@@ -2052,7 +2052,7 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
 property_read(region_top_frequency, unsigned int, "%u")
 property_signed_read(fm_carrier_error, int, "%d")
 property_signed_read(fm_rssi, int, "%d")
-DEFINE_SYSFS_PROPERTY(region, unsigned, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(region, unsigned int, int, "%u", 0)
 
 static struct device_attribute attrs[] = {
__ATTR(power_state, 0644, bcm2048_power_state_read,
-- 
1.8.3.1

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

[Steve Longerbeam]

On 03/21/2017 04:27 AM, Russell King - ARM Linux wrote:

On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote:

@@ -1173,15 +1196,8 @@ static void csi_try_fmt(struct csi_priv *priv,
incc = imx_media_find_mbus_format(infmt->code,
  CS_SEL_ANY, true);

-   if (sdformat->format.width < priv->crop.width * 3 / 4)
-   sdformat->format.width = priv->crop.width / 2;
-   else
-   sdformat->format.width = priv->crop.width;
-
-   if (sdformat->format.height < priv->crop.height * 3 / 4)
-   sdformat->format.height = priv->crop.height / 2;
-   else
-   sdformat->format.height = priv->crop.height;
+   sdformat->format.width = compose->width;
+   sdformat->format.height = compose->height;

if (incc->bayer) {
sdformat->format.code = infmt->code;


We need to do more in here, because right now setting the source pads
overwrites the colorimetry etc information.  Maybe something like the
below?


I'm thinking, to support propagating the colorimetry params, there
should be a util function

void imx_media_copy_colorimetry(struct v4l2_mbus_framefmt *out,
struct v4l2_mbus_framefmt *in);

that can be used throughout the pipeline, that does exactly what
you add below.


 I'm wondering if it would be a saner approach to copy the
sink format and update the parameters that can be changed, rather than
trying to list all the parameters that shouldn't be changed.


For CSI that is a bit difficult, because the source formats are
hardly related to the sink formats, so so much would have to be
modified after copying the sink format that it would be rather
pointless, except to forward the colorimetry params.

Steve


 What if the format structure gains a new member?

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 1492b92e1970..756204ced53c 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1221,6 +1221,12 @@ static void csi_try_fmt(struct csi_priv *priv,
sdformat->format.field =  (infmt->height == 480) ?
V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
}
+
+   /* copy settings we can't change */
+   sdformat->format.colorspace = infmt->colorspace;
+   sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
+   sdformat->format.quantization = infmt->quantization;
+   sdformat->format.xfer_func = infmt->xfer_func;
break;
case CSI_SINK_PAD:
v4l_bound_align_image(>format.width, MIN_W, MAX_W,

Re: [PATCH 3/4] media: imx-csi: add frame size/interval enumeration

[Steve Longerbeam]

Hi Russell,

On 03/19/2017 03:49 AM, Russell King wrote:

Add frame size and frame interval enumeration to CSI.

CSI can scale the image independently horizontally and vertically by a
factor of two, which enumerates to four different frame sizes.

CSI can also drop frames, resulting in frame rate reduction, so
enumerate the resulting possible output frame rates.



I applied this patch, modified to return a frame size range on the
sink pad. Also, I believe both frame size and frame interval
enumeration should base their decision making on the crop rectangle
at the sink pad, not on the format at the source pads, due to the
crop/compose re-org patch from Philipp.

The updated patch is attached.

Steve

>From ce1772dfe9e0381b2749102e760ed7c49fda5ae2 Mon Sep 17 00:00:00 2001
From: Russell King 
Date: Sun, 19 Mar 2017 10:49:02 +
Subject: [PATCH 36/38] media: imx-csi: add frame size/interval enumeration

Add frame size and frame interval enumeration to CSI.

CSI can downscale the image independently horizontally and vertically by a
factor of two, which enumerates to four different frame sizes at the
output pads. The input pad supports a range of frame sizes.

CSI can also drop frames, resulting in frame rate reduction, so
enumerate the resulting possible output frame rates.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-csi.c | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
index 5f9fa83..55265c1 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1098,6 +1098,66 @@ static int csi_enum_mbus_code(struct v4l2_subdev *sd,
 	return ret;
 }
 
+static int csi_enum_frame_size(struct v4l2_subdev *sd,
+			   struct v4l2_subdev_pad_config *cfg,
+			   struct v4l2_subdev_frame_size_enum *fse)
+{
+	struct csi_priv *priv = v4l2_get_subdevdata(sd);
+	struct v4l2_rect *crop;
+	int ret = 0;
+
+	if (fse->pad >= CSI_NUM_PADS ||
+	fse->index > (fse->pad == CSI_SINK_PAD ? 0 : 3))
+		return -EINVAL;
+
+	mutex_lock(>lock);
+
+	if (fse->pad == CSI_SINK_PAD) {
+		fse->min_width = MIN_W;
+		fse->max_width = MAX_W;
+		fse->min_height = MIN_H;
+		fse->max_height = MAX_H;
+	} else {
+		crop = __csi_get_crop(priv, cfg, fse->which);
+
+		fse->min_width = fse->max_width = fse->index & 1 ?
+			crop->width / 2 : crop->width;
+		fse->min_height = fse->max_height = fse->index & 2 ?
+			crop->height / 2 : crop->height;
+	}
+
+	mutex_unlock(>lock);
+	return ret;
+}
+
+static int csi_enum_frame_interval(struct v4l2_subdev *sd,
+   struct v4l2_subdev_pad_config *cfg,
+   struct v4l2_subdev_frame_interval_enum *fie)
+{
+	struct csi_priv *priv = v4l2_get_subdevdata(sd);
+	struct v4l2_rect *crop;
+	int ret = 0;
+
+	if (fie->pad >= CSI_NUM_PADS ||
+	fie->index >= (fie->pad == CSI_SINK_PAD ? 1 : ARRAY_SIZE(csi_skip)))
+		return -EINVAL;
+
+	mutex_lock(>lock);
+
+	crop = __csi_get_crop(priv, cfg, fie->which);
+
+	if ((fie->width == crop->width || fie->width == crop->width / 2) &&
+	(fie->height == crop->height || fie->height == crop->height / 2)) {
+		fie->interval = priv->frame_interval;
+		csi_apply_skip_interval(_skip[fie->index], >interval);
+	} else {
+		ret = -EINVAL;
+	}
+	mutex_unlock(>lock);
+
+	return ret;
+}
+
 static int csi_get_fmt(struct v4l2_subdev *sd,
 		   struct v4l2_subdev_pad_config *cfg,
 		   struct v4l2_subdev_format *sdformat)
@@ -1562,6 +1622,8 @@ static struct v4l2_subdev_video_ops csi_video_ops = {
 
 static struct v4l2_subdev_pad_ops csi_pad_ops = {
 	.enum_mbus_code = csi_enum_mbus_code,
+	.enum_frame_size = csi_enum_frame_size,
+	.enum_frame_interval = csi_enum_frame_interval,
 	.get_fmt = csi_get_fmt,
 	.set_fmt = csi_set_fmt,
 	.get_selection = csi_get_selection,
-- 
2.7.4

Re: CEC button pass-through

[Eric Nelson]

Hi Hans,

On 03/21/2017 02:29 PM, Hans Verkuil wrote:
> On 03/21/2017 09:03 PM, Eric Nelson wrote:
>> On 03/21/2017 11:46 AM, Hans Verkuil wrote:
>>> On 03/21/2017 07:23 PM, Eric Nelson wrote:
 On 03/21/2017 10:44 AM, Eric Nelson wrote:
> On 03/21/2017 10:05 AM, Hans Verkuil wrote:
>> On 03/21/2017 05:49 PM, Eric Nelson wrote:




 I think this is the culprit:
 cec-uinput: L8: << 10:8e:00

 The 1.3 spec says this about the 8E message:

 "If Menu State indicates activated, TV enters ‘Device Menu Active’
 state and forwards those Remote control commands, shown in
 Table 26, to the initiator. If deactivated, TV enters ‘Device Menu 
 Inactive’
 state and stops forwarding remote control commands".

 In section 13.12.2, it also says this:

 "The TV may initiate a device’s menu by sending a 
 [“Activate”] command. It may subsequently remove the menu by sending
 a  [“Deactivate”] message. The TV may also query a
 devices menu status by sending a  [“Query”]. The
 menu device shall always respond with a  command
 when it receives a ."

>>>
>>> That sounds plausible. When you tested with my CEC framework, did you also
>>> run the cec-follower utility? That emulates a CEC follower.
>>>
>>
>> Yes. I'm running it with no arguments.
>>
>>> Note: you really need to use the --cec-version-1.4 option when configuring
>>> the i.MX6 CEC adapter since support for  is only enabled with
>>> CEC version 1.4. It is no longer supported with 2.0.
>>>
>>
>> I'm not sure what I did in my previous attempt, but I'm now seeing
>> both the arrow and function key sets being received by cec-ctl and
>> cec-follower with --cec-version-1.4.
>>
>> Or not. Removing the --cec-version-1.4 parameter still shows these
>> events, but after a re-boot and re-selection of the proper source
>> on my TV shows that they're no longer coming up with or without
>> the parameter.
>>
>> Further testing showed that by running the older driver and libCEC
>> code, then re-booting into the new kernel (with cec-ctl) shows the
>> messages with or without the flag.
>>
>> In other words, the TV seems to retain some state from the
>> execution of the Pulse8/libCEC code.
>>
>> Is there a way to send a raw message to the television using cec-ctl?
>>
>> Never mind, I found it and after a bunch of messing around,
>> confirmed that I can get the menu keys to be passed from my
>> TV by sending the 0x8e command with a payload of 0x00 to
>> the television:
>>
>> ~/# cec-ctl --custom-command=cmd=0x8e,payload=0x00 --to=0
> 
> Or more elegantly:
> 
> cec-ctl --menu-status=menu-state=activated -t0
> 
> See also: cec-ctl --help-device-menu-control
> 

My first RTFM for this subsystem!

> But cec-follower should receive a menu-request message and reply with
> menu-status(activated).
> 
> If you run cec-ctl -M, do you see the menu-request message arriving and the
> proper reply?
> 

After a re-boot with the CEC input clear on my television, I don't see it
during the initial startup of cec-ctl:

~# cec-ctl --record --cec-version-1.4 -M
Driver Info:
Driver Name : dwhdmi-imx
Adapter Name : dw_hdmi
Capabilities : 0x0016
Logical Addresses
Transmit
Remote Control Support
Driver version : 4.10.0
Available Logical Addresses: 4
Physical Address : 1.0.0.0
Logical Address Mask : 0x0002
CEC Version : 1.4
Vendor ID : 0x000c03 (HDMI)
OSD Name : 'Record'
Logical Addresses : 1 (Allow RC Passthrough)
Logical Address : 1 (Recording Device 1)
Primary Device Type : Record
Logical Address Type : Record

Monitor All mode is not supported, falling back to regular monitoring

Event: State Change: PA: 1.0.0.0, LA mask: 0x0002
Transmitted by Recording Device 1 to all (1 to 15):
CEC_MSG_REPORT_PHYSICAL_ADDR (0x84):
phys-addr: 1.0.0.0
prim-devtype: record (0x01)
Received from TV to Recording Device 1 (0 to 1):
CEC_MSG_GIVE_DEVICE_VENDOR_ID (0x8c)
Transmitted by Recording Device 1 to all (1 to 15):
CEC_MSG_DEVICE_VENDOR_ID (0x87):
vendor-id: 3075 (0x0c03)
Received from TV to Recording Device 1 (0 to 1): CEC_MSG_GIVE_OSD_NAME
(0x46)
Transmitted by Recording Device 1 to TV (1 to 0): CEC_MSG_SET_OSD_NAME
(0x47):
name: Record
Received from TV to Recording Device 1 (0 to 1):
CEC_MSG_VENDOR_COMMAND_WITH_ID:
vendor-id: 240 (0x00f0)
vendor-specific-data: 0x23
Transmitted by Recording Device 1 to TV (1 to 0): CEC_MSG_FEATURE_ABORT
(0x00):
abort-msg: 160 (0xa0)
reason: unrecognized-op (0x00)
Received from TV to Recording Device 1 (0 to 1): CEC_MSG_GET_CEC_VERSION
(0x9f)
Transmitted by Recording Device 1 to TV (1 to 0): CEC_MSG_CEC_VERSION
(0x9e):
cec-version: version-1-4 (0x05)

But when I switch to the CEC source, I do see a set of state queries,
including the MENU_REQUEST
message.

Received from TV to Recording Device 1 (0 to 1):
CEC_MSG_GIVE_DEVICE_POWER_STATUS (0x8f)
Transmitted by Recording Device 1 to TV (1 to 0):
CEC_MSG_REPORT_POWER_STATUS (0x90):
pwr-state: on (0x00)
Received from TV to Recording Device 1 (0 

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

[Steve Longerbeam]

Hi Philipp, Russell,


On 03/20/2017 10:23 AM, Philipp Zabel wrote:

Hi Steve, Russell,



What do you think of this:

--8<--
From 2830aebc404bdfc9d7fc1ec94e5282d0b668e8f6 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Mon, 20 Mar 2017 17:10:21 +0100
Subject: [PATCH] media: imx: csi: add sink selection rectangles

Move the crop rectangle to the sink pad and add a sink compose rectangle
to configure scaling. Also propagate rectangles from sink pad to crop
rectangle, to compose rectangle, and to the source pads both in ACTIVE
and TRY variants of set_fmt/selection, and initialize the default crop
and compose rectangles.




I applied this patch.

I noticed Philipp fixed a bug in the sink->source pad format
propagation. I was only propagating the active runs, and not
the trial runs. I fixed this everywhere in the pipeline, applied
to the "propagate sink pad formats to source pads" patch. Try
runs should now work correctly across the whole pipeline, but
I haven't tested this.

Steve

Re: CEC button pass-through

[Hans Verkuil]

On 03/21/2017 09:03 PM, Eric Nelson wrote:
> Hi Hans,
> 
> On 03/21/2017 11:46 AM, Hans Verkuil wrote:
>> On 03/21/2017 07:23 PM, Eric Nelson wrote:
>>> On 03/21/2017 10:44 AM, Eric Nelson wrote:
 On 03/21/2017 10:05 AM, Hans Verkuil wrote:
> On 03/21/2017 05:49 PM, Eric Nelson wrote:
>>>
>>> 
>>>
> With CEC 2.0 you can set various RC profiles, and (very unlikely) perhaps
> your TV actually understands that.
>
> The default CEC version cec-ctl selects is 2.0.
>
> Note that the CEC framework doesn't do anything with the RC profiles
> at the moment.
>

 I don't have the 2.0 spec, so I'm not sure what messages to look for
 in the logs from libCEC.

 I have a complete log file here, and it shows messages to and from
 the television, though in a pretty verbose form.

 http://pastebin.com/qFrhkNZQ

>>>
>>> I think this is the culprit:
>>> cec-uinput: L8: << 10:8e:00
>>>
>>>
>>> The 1.3 spec says this about the 8E message:
>>>
>>> "If Menu State indicates activated, TV enters ‘Device Menu Active’
>>> state and forwards those Remote control commands, shown in
>>> Table 26, to the initiator. If deactivated, TV enters ‘Device Menu Inactive’
>>> state and stops forwarding remote control commands".
>>>
>>> In section 13.12.2, it also says this:
>>>
>>> "The TV may initiate a device’s menu by sending a 
>>> [“Activate”] command. It may subsequently remove the menu by sending
>>> a  [“Deactivate”] message. The TV may also query a
>>> devices menu status by sending a  [“Query”]. The
>>> menu device shall always respond with a  command
>>> when it receives a ."
>>>
>>
>> That sounds plausible. When you tested with my CEC framework, did you also
>> run the cec-follower utility? That emulates a CEC follower.
>>
> 
> Yes. I'm running it with no arguments.
> 
>> Note: you really need to use the --cec-version-1.4 option when configuring
>> the i.MX6 CEC adapter since support for  is only enabled with
>> CEC version 1.4. It is no longer supported with 2.0.
>>
> 
> I'm not sure what I did in my previous attempt, but I'm now seeing
> both the arrow and function key sets being received by cec-ctl and
> cec-follower with --cec-version-1.4.
> 
> Or not. Removing the --cec-version-1.4 parameter still shows these
> events, but after a re-boot and re-selection of the proper source
> on my TV shows that they're no longer coming up with or without
> the parameter.
> 
> Further testing showed that by running the older driver and libCEC
> code, then re-booting into the new kernel (with cec-ctl) shows the
> messages with or without the flag.
> 
> In other words, the TV seems to retain some state from the
> execution of the Pulse8/libCEC code.
> 
> Is there a way to send a raw message to the television using cec-ctl?
> 
> Never mind, I found it and after a bunch of messing around,
> confirmed that I can get the menu keys to be passed from my
> TV by sending the 0x8e command with a payload of 0x00 to
> the television:
> 
> ~/# cec-ctl --custom-command=cmd=0x8e,payload=0x00 --to=0

Or more elegantly:

cec-ctl --menu-status=menu-state=activated -t0

See also: cec-ctl --help-device-menu-control

But cec-follower should receive a menu-request message and reply with
menu-status(activated).

If you run cec-ctl -M, do you see the menu-request message arriving and the
proper reply?

Again, you must configure the cec adapter with:

cec-ctl --record --cec-version-1.4

otherwise it won't work (I'm not sure that's correct since the TV isn't
CEC 2.0, I'll have to read up on that).

Regards,

Hans

Re: CEC button pass-through

[Eric Nelson]

Hi Hans,

On 03/21/2017 11:46 AM, Hans Verkuil wrote:
> On 03/21/2017 07:23 PM, Eric Nelson wrote:
>> On 03/21/2017 10:44 AM, Eric Nelson wrote:
>>> On 03/21/2017 10:05 AM, Hans Verkuil wrote:
 On 03/21/2017 05:49 PM, Eric Nelson wrote:
>>
>> 
>>
 With CEC 2.0 you can set various RC profiles, and (very unlikely) perhaps
 your TV actually understands that.

 The default CEC version cec-ctl selects is 2.0.

 Note that the CEC framework doesn't do anything with the RC profiles
 at the moment.

>>>
>>> I don't have the 2.0 spec, so I'm not sure what messages to look for
>>> in the logs from libCEC.
>>>
>>> I have a complete log file here, and it shows messages to and from
>>> the television, though in a pretty verbose form.
>>>
>>> http://pastebin.com/qFrhkNZQ
>>>
>>
>> I think this is the culprit:
>> cec-uinput: L8: << 10:8e:00
>>
>>
>> The 1.3 spec says this about the 8E message:
>>
>> "If Menu State indicates activated, TV enters ‘Device Menu Active’
>> state and forwards those Remote control commands, shown in
>> Table 26, to the initiator. If deactivated, TV enters ‘Device Menu Inactive’
>> state and stops forwarding remote control commands".
>>
>> In section 13.12.2, it also says this:
>>
>> "The TV may initiate a device’s menu by sending a 
>> [“Activate”] command. It may subsequently remove the menu by sending
>> a  [“Deactivate”] message. The TV may also query a
>> devices menu status by sending a  [“Query”]. The
>> menu device shall always respond with a  command
>> when it receives a ."
>>
> 
> That sounds plausible. When you tested with my CEC framework, did you also
> run the cec-follower utility? That emulates a CEC follower.
> 

Yes. I'm running it with no arguments.

> Note: you really need to use the --cec-version-1.4 option when configuring
> the i.MX6 CEC adapter since support for  is only enabled with
> CEC version 1.4. It is no longer supported with 2.0.
> 

I'm not sure what I did in my previous attempt, but I'm now seeing
both the arrow and function key sets being received by cec-ctl and
cec-follower with --cec-version-1.4.

Or not. Removing the --cec-version-1.4 parameter still shows these
events, but after a re-boot and re-selection of the proper source
on my TV shows that they're no longer coming up with or without
the parameter.

Further testing showed that by running the older driver and libCEC
code, then re-booting into the new kernel (with cec-ctl) shows the
messages with or without the flag.

In other words, the TV seems to retain some state from the
execution of the Pulse8/libCEC code.

Is there a way to send a raw message to the television using cec-ctl?

Never mind, I found it and after a bunch of messing around,
confirmed that I can get the menu keys to be passed from my
TV by sending the 0x8e command with a payload of 0x00 to
the television:

~/# cec-ctl --custom-command=cmd=0x8e,payload=0x00 --to=0

Thanks for your help with this.

Regards,


Eric

Re: CEC button pass-through

[Hans Verkuil]

On 03/21/2017 07:23 PM, Eric Nelson wrote:
> Hi Hans,
> 
> On 03/21/2017 10:44 AM, Eric Nelson wrote:
>> On 03/21/2017 10:05 AM, Hans Verkuil wrote:
>>> On 03/21/2017 05:49 PM, Eric Nelson wrote:
> 
> 
> 
>>> With CEC 2.0 you can set various RC profiles, and (very unlikely) perhaps
>>> your TV actually understands that.
>>>
>>> The default CEC version cec-ctl selects is 2.0.
>>>
>>> Note that the CEC framework doesn't do anything with the RC profiles
>>> at the moment.
>>>
>>
>> I don't have the 2.0 spec, so I'm not sure what messages to look for
>> in the logs from libCEC.
>>
>> I have a complete log file here, and it shows messages to and from
>> the television, though in a pretty verbose form.
>>
>> http://pastebin.com/qFrhkNZQ
>>
> 
> I think this is the culprit:
> cec-uinput: L8: << 10:8e:00
> 
> 
> The 1.3 spec says this about the 8E message:
> 
> "If Menu State indicates activated, TV enters ‘Device Menu Active’
> state and forwards those Remote control commands, shown in
> Table 26, to the initiator. If deactivated, TV enters ‘Device Menu Inactive’
> state and stops forwarding remote control commands".
> 
> In section 13.12.2, it also says this:
> 
> "The TV may initiate a device’s menu by sending a 
> [“Activate”] command. It may subsequently remove the menu by sending
> a  [“Deactivate”] message. The TV may also query a
> devices menu status by sending a  [“Query”]. The
> menu device shall always respond with a  command
> when it receives a ."
> 

That sounds plausible. When you tested with my CEC framework, did you also
run the cec-follower utility? That emulates a CEC follower.

Note: you really need to use the --cec-version-1.4 option when configuring
the i.MX6 CEC adapter since support for  is only enabled with
CEC version 1.4. It is no longer supported with 2.0.

Regards,

Hans

Re: CEC button pass-through

[Eric Nelson]

Hi Hans,

On 03/21/2017 10:44 AM, Eric Nelson wrote:
> On 03/21/2017 10:05 AM, Hans Verkuil wrote:
>> On 03/21/2017 05:49 PM, Eric Nelson wrote:



>> With CEC 2.0 you can set various RC profiles, and (very unlikely) perhaps
>> your TV actually understands that.
>>
>> The default CEC version cec-ctl selects is 2.0.
>>
>> Note that the CEC framework doesn't do anything with the RC profiles
>> at the moment.
>>
> 
> I don't have the 2.0 spec, so I'm not sure what messages to look for
> in the logs from libCEC.
> 
> I have a complete log file here, and it shows messages to and from
> the television, though in a pretty verbose form.
> 
> http://pastebin.com/qFrhkNZQ
> 

I think this is the culprit:
cec-uinput: L8: << 10:8e:00


The 1.3 spec says this about the 8E message:

"If Menu State indicates activated, TV enters ‘Device Menu Active’
state and forwards those Remote control commands, shown in
Table 26, to the initiator. If deactivated, TV enters ‘Device Menu Inactive’
state and stops forwarding remote control commands".

In section 13.12.2, it also says this:

"The TV may initiate a device’s menu by sending a 
[“Activate”] command. It may subsequently remove the menu by sending
a  [“Deactivate”] message. The TV may also query a
devices menu status by sending a  [“Query”]. The
menu device shall always respond with a  command
when it receives a ."

Re: CEC button pass-through

[Eric Nelson]

Hi Hans,

On 03/21/2017 10:05 AM, Hans Verkuil wrote:
> On 03/21/2017 05:49 PM, Eric Nelson wrote:
>> Hi Hans,
>>
>> Thanks to your work and those of Russell King, I have an i.MX6
>> board up and running with the new CEC API, but I'm having
>> trouble with a couple of sets of remote control keys.
> 
> What is your exact setup? Your i.MX6 is hooked up to a TV? And you
> use the TV's remote control?
> 

Exactly. Custom i.MX6 board with a Samsung television and remote.

>> In particular, the directional keys 0x01-0x04 (Up..Right)
>> and the function keys 0x71-0x74 (F1-F4) don't appear
>> to be forwarded.
>>
>> Running cec-ctl with the "-m" or "-M" options shows that they're
>> simply not being received.
> 
> Other keys appear fine with cec-ctl -M?
> 

Yes. Most keys are working fine.

> Try to select CEC version 1.4 (use option --cec-version-1.4).
> 

Same result. I'm seeing most keys, including number keys:

Received from TV to Recording Device 1 (0 to 1):
CEC_MSG_USER_CONTROL_PRESSED (0x44):
ui-cmd: Number 1 (0x21)
Raw: 01 44 21
Received from TV to Recording Device 1 (0 to 1):
CEC_MSG_USER_CONTROL_RELEASED (0x45)
Raw: 01 45

But nothing from either the arrow or function keys.

> With CEC 2.0 you can set various RC profiles, and (very unlikely) perhaps
> your TV actually understands that.
> 
> The default CEC version cec-ctl selects is 2.0.
> 
> Note that the CEC framework doesn't do anything with the RC profiles
> at the moment.
> 

I don't have the 2.0 spec, so I'm not sure what messages to look for
in the logs from libCEC.

I have a complete log file here, and it shows messages to and from
the television, though in a pretty verbose form.

http://pastebin.com/qFrhkNZQ

>>
>> I'm not sure if I'm missing a flag somewhere to tell my television
>> that we support these keys, or if I'm missing something else.
>>
>> I'm using the --record option at the moment. Using --playback
>> seems to restrict the keys to an even smaller set (seems to
>> block numeric keys).
>>
>> Do you have any guidance about how to trace this?
> 
> cec-ctl -M monitors all messages, so it is weird you don't see them.
> 

Yep. Weird.

Re: CEC button pass-through

[Hans Verkuil]

On 03/21/2017 05:49 PM, Eric Nelson wrote:
> Hi Hans,
> 
> Thanks to your work and those of Russell King, I have an i.MX6
> board up and running with the new CEC API, but I'm having
> trouble with a couple of sets of remote control keys.

What is your exact setup? Your i.MX6 is hooked up to a TV? And you
use the TV's remote control?

> In particular, the directional keys 0x01-0x04 (Up..Right)
> and the function keys 0x71-0x74 (F1-F4) don't appear
> to be forwarded.
> 
> Running cec-ctl with the "-m" or "-M" options shows that they're
> simply not being received.

Other keys appear fine with cec-ctl -M?

Try to select CEC version 1.4 (use option --cec-version-1.4).

With CEC 2.0 you can set various RC profiles, and (very unlikely) perhaps
your TV actually understands that.

The default CEC version cec-ctl selects is 2.0.

Note that the CEC framework doesn't do anything with the RC profiles
at the moment.

> 
> I'm not sure if I'm missing a flag somewhere to tell my television
> that we support these keys, or if I'm missing something else.
> 
> I'm using the --record option at the moment. Using --playback
> seems to restrict the keys to an even smaller set (seems to
> block numeric keys).
> 
> Do you have any guidance about how to trace this?

cec-ctl -M monitors all messages, so it is weird you don't see them.

> I am seeing these keys when using Pulse8/libCEC code and
> the vendor driver and am in a position to trace the messages
> using that setup if it helps.

Regards,

Hans

CEC button pass-through

[Eric Nelson]

Hi Hans,

Thanks to your work and those of Russell King, I have an i.MX6
board up and running with the new CEC API, but I'm having
trouble with a couple of sets of remote control keys.

In particular, the directional keys 0x01-0x04 (Up..Right)
and the function keys 0x71-0x74 (F1-F4) don't appear
to be forwarded.

Running cec-ctl with the "-m" or "-M" options shows that they're
simply not being received.

I'm not sure if I'm missing a flag somewhere to tell my television
that we support these keys, or if I'm missing something else.

I'm using the --record option at the moment. Using --playback
seems to restrict the keys to an even smaller set (seems to
block numeric keys).

Do you have any guidance about how to trace this?

I am seeing these keys when using Pulse8/libCEC code and
the vendor driver and am in a position to trace the messages
using that setup if it helps.

Please advise,


Eric Nelson

[PATCH v4 1/6] drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

[Neil Armstrong]

From: Laurent Pinchart 

In preparation for adding PHY operations to handle RX SENSE and HPD,
group all the PHY interrupt setup code in a single location and extract
it to a separate function.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 50 ++-
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index af93f7a..f82750a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1559,7 +1559,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 }
 
 /* Wait until we are registered to enable interrupts */
-static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
+static void dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
 {
hdmi_writeb(hdmi, HDMI_PHY_I2CM_INT_ADDR_DONE_POL,
HDMI_PHY_I2CM_INT_ADDR);
@@ -1567,15 +1567,6 @@ static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, HDMI_PHY_I2CM_CTLINT_ADDR_NAC_POL |
HDMI_PHY_I2CM_CTLINT_ADDR_ARBITRATION_POL,
HDMI_PHY_I2CM_CTLINT_ADDR);
-
-   /* enable cable hot plug irq */
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
-   return 0;
 }
 
 static void initialize_hdmi_ih_mutes(struct dw_hdmi *hdmi)
@@ -1693,6 +1684,26 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
 }
 
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
+{
+   /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+
+   /* Enable cable hot plug irq. */
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+   /* Clear and unmute interrupts. */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+   HDMI_IH_MUTE_PHY_STAT0);
+}
+
 static enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -2204,29 +2215,14 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
hdmi->ddc = NULL;
}
 
-   /*
-* Configure registers related to HDMI interrupt
-* generation before registering IRQ.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = _hdmi_bridge_funcs;
 #ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
 #endif
 
-   ret = dw_hdmi_fb_registered(hdmi);
-   if (ret)
-   goto err_iahb;
-
-   /* Unmute interrupts */
-   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
-   HDMI_IH_MUTE_PHY_STAT0);
+   dw_hdmi_fb_registered(hdmi);
+   dw_hdmi_phy_setup_hpd(hdmi);
 
memset(, 0, sizeof(pdevinfo));
pdevinfo.parent = dev;
-- 
1.9.1

[PATCH v4 3/6] documentation: media: Add documentation for new RGB and YUV bus formats

[Neil Armstrong]

Add documentation for added Bus Formats to describe RGB and YUV formats used
as input to the Synopsys DesignWare HDMI TX Controller.

Signed-off-by: Neil Armstrong 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 871 +++-
 1 file changed, 857 insertions(+), 14 deletions(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index d6152c9..6e64fd2 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -1258,6 +1258,281 @@ The following tables list existing packed RGB formats.
   - b\ :sub:`2`
   - b\ :sub:`1`
   - b\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB101010-1X30:
+
+  - MEDIA_BUS_FMT_RGB101010_1X30
+  - 0x1018
+  -
+  - 0
+  - 0
+  - r\ :sub:`9`
+  - r\ :sub:`8`
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - g\ :sub:`9`
+  - g\ :sub:`8`
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - b\ :sub:`9`
+  - b\ :sub:`8`
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+
+.. raw:: latex
+
+\endgroup
+
+
+The following table list existing packed 36bit wide RGB formats.
+
+.. tabularcolumns:: 
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-36:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 36bit RGB formats
+:header-rows:  2
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 
2 2 2 2 2 2 2
+
+* - Identifier
+  - Code
+  -
+  - :cspan:`35` Data organization
+* -
+  -
+  - Bit
+  - 35
+  - 34
+  - 33
+  - 32
+  - 31
+  - 30
+  - 29
+  - 28
+  - 27
+  - 26
+  - 25
+  - 24
+  - 23
+  - 22
+  - 21
+  - 20
+  - 19
+  - 18
+  - 17
+  - 16
+  - 15
+  - 14
+  - 13
+  - 12
+  - 11
+  - 10
+  - 9
+  - 8
+  - 7
+  - 6
+  - 5
+  - 4
+  - 3
+  - 2
+  - 1
+  - 0
+* .. _MEDIA-BUS-FMT-RGB121212-1X36:
+
+  - MEDIA_BUS_FMT_RGB121212_1X36
+  - 0x1019
+  -
+  - r\ :sub:`11`
+  - r\ :sub:`10`
+  - r\ :sub:`9`
+  - r\ :sub:`8`
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - g\ :sub:`11`
+  - g\ :sub:`10`
+  - g\ :sub:`9`
+  - g\ :sub:`8`
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - b\ :sub:`11`
+  - b\ :sub:`10`
+  - b\ :sub:`9`
+  - b\ :sub:`8`
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+
+.. raw:: latex
+
+\endgroup
+
+
+The following table list existing packed 48bit wide RGB formats.
+
+.. tabularcolumns:: 
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-48:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 48bit RGB formats
+:header-rows:  2
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
+
+* - Identifier
+  - Code
+  -
+  - :cspan:`47` Data organization
+* -
+  -
+  - Bit
+  - 47
+  - 46
+  - 45
+  - 44
+  - 43
+  - 42
+  - 41
+  - 40
+  - 39
+  - 38
+  - 37
+  - 36
+  - 35
+  - 34
+  - 33
+  - 32
+  - 31
+  - 30
+  - 29
+  - 

[PATCH v4 6/6] drm: bridge: dw-hdmi: Move HPD handling to PHY operations

[Neil Armstrong]

The HDMI TX controller support HPD and RXSENSE signaling from the PHY
via it's STAT0 PHY interface, but some vendor PHYs can manage these
signals independently from the controller, thus these STAT0 handling
should be moved to PHY specific operations and become optional.

The existing STAT0 HPD and RXSENSE handling code is refactored into
a supplementaty set of default PHY operations that are used automatically
when the platform glue doesn't provide its own operations.

Reviewed-by: Jose Abreu 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135 ++
 include/drm/bridge/dw_hdmi.h  |   5 ++
 2 files changed, 86 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index fcb0a27..910d579 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1229,10 +1229,46 @@ static enum drm_connector_status 
dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
connector_status_connected : connector_status_disconnected;
 }
 
+static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+  bool force, bool disabled, bool rxsense)
+{
+   u8 old_mask = hdmi->phy_mask;
+
+   if (force || disabled || !rxsense)
+   hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
+   else
+   hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
+
+   if (old_mask != hdmi->phy_mask)
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+}
+
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+{
+   /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+
+   /* Enable cable hot plug irq. */
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+   /* Clear and unmute interrupts. */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+   HDMI_IH_MUTE_PHY_STAT0);
+}
+
 static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
.init = dw_hdmi_phy_init,
.disable = dw_hdmi_phy_disable,
.read_hpd = dw_hdmi_phy_read_hpd,
+   .update_hpd = dw_hdmi_phy_update_hpd,
+   .setup_hpd = dw_hdmi_phy_setup_hpd,
 };
 
 /* 
-
@@ -1809,35 +1845,10 @@ static void dw_hdmi_update_power(struct dw_hdmi *hdmi)
  */
 static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
 {
-   u8 old_mask = hdmi->phy_mask;
-
-   if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
-   hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
-   else
-   hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
-
-   if (old_mask != hdmi->phy_mask)
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-}
-
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
-{
-   /*
-* Configure the PHY RX SENSE and HPD interrupts polarities and clear
-* any pending interrupt.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
-   /* Enable cable hot plug irq. */
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
-   /* Clear and unmute interrupts. */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
-   HDMI_IH_MUTE_PHY_STAT0);
+   if (hdmi->phy.ops->update_hpd)
+   hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
+ hdmi->force, hdmi->disabled,
+ hdmi->rxsense);
 }
 
 static enum drm_connector_status
@@ -2029,6 +2040,41 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
 }
 
+void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+{
+   mutex_lock(>mutex);
+
+   if (!hdmi->disabled && !hdmi->force) {
+   /*
+* If the RX sense status indicates we're disconnected,
+* clear the software rxsense status.
+*/
+   if (!rx_sense)
+   hdmi->rxsense = false;
+
+   /*
+* Only set the software rxsense status when both
+* rxsense and hpd indicates we're connected.
+

[PATCH v4 2/6] media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller

[Neil Armstrong]

In order to describe the RGB and YUV bus formats used to feed the
Synopsys DesignWare HDMI TX Controller, add missing formats to the
list of Bus Formats.

Documentation for these formats is added in a separate patch.

Reviewed-by: Archit Taneja 
Signed-off-by: Neil Armstrong 
---
 include/uapi/linux/media-bus-format.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 2168759..6c8f31c 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,7 +33,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x1018 */
+/* RGB - next is   0x101b */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -57,8 +57,11 @@
 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA   0x1012
 #define MEDIA_BUS_FMT_ARGB_1X320x100d
 #define MEDIA_BUS_FMT_RGB888_1X32_PADHI0x100f
+#define MEDIA_BUS_FMT_RGB101010_1X30   0x1018
+#define MEDIA_BUS_FMT_RGB121212_1X36   0x1019
+#define MEDIA_BUS_FMT_RGB161616_1X48   0x101a
 
-/* YUV (including grey) - next is  0x2026 */
+/* YUV (including grey) - next is  0x202c */
 #define MEDIA_BUS_FMT_Y8_1X8   0x2001
 #define MEDIA_BUS_FMT_UV8_1X8  0x2015
 #define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
@@ -90,12 +93,18 @@
 #define MEDIA_BUS_FMT_YVYU10_1X20  0x200e
 #define MEDIA_BUS_FMT_VUY8_1X240x2024
 #define MEDIA_BUS_FMT_YUV8_1X240x2025
+#define MEDIA_BUS_FMT_UYYVYY8_1X24 0x2026
 #define MEDIA_BUS_FMT_UYVY12_1X24  0x2020
 #define MEDIA_BUS_FMT_VYUY12_1X24  0x2021
 #define MEDIA_BUS_FMT_YUYV12_1X24  0x2022
 #define MEDIA_BUS_FMT_YVYU12_1X24  0x2023
 #define MEDIA_BUS_FMT_YUV10_1X30   0x2016
+#define MEDIA_BUS_FMT_UYYVYY10_1X300x2027
 #define MEDIA_BUS_FMT_AYUV8_1X32   0x2017
+#define MEDIA_BUS_FMT_UYYVYY12_1X360x2028
+#define MEDIA_BUS_FMT_YUV12_1X36   0x2029
+#define MEDIA_BUS_FMT_YUV16_1X48   0x202a
+#define MEDIA_BUS_FMT_UYYVYY16_1X480x202b
 
 /* Bayer - next is 0x3021 */
 #define MEDIA_BUS_FMT_SBGGR8_1X8   0x3001
-- 
1.9.1

[PATCH v4 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Neil Armstrong]

Some display pipelines can only provide non-RBG input pixels to the HDMI TX
Controller, this patch takes the pixel format from the plat_data if provided.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326 +-
 include/drm/bridge/dw_hdmi.h  |  63 ++
 2 files changed, 294 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f82750a..fcb0a27 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -30,18 +30,15 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "dw-hdmi.h"
 #include "dw-hdmi-audio.h"
 
 #define DDC_SEGMENT_ADDR   0x30
 #define HDMI_EDID_LEN  512
 
-#define RGB0
-#define YCBCR444   1
-#define YCBCR422_16BITS2
-#define YCBCR422_8BITS 3
-#define XVYCC444   4
-
 enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -95,10 +92,10 @@ struct hdmi_vmode {
 };
 
 struct hdmi_data_info {
-   unsigned int enc_in_format;
-   unsigned int enc_out_format;
-   unsigned int enc_color_depth;
-   unsigned int colorimetry;
+   unsigned int enc_in_bus_format;
+   unsigned int enc_out_bus_format;
+   unsigned int enc_in_encoding;
+   unsigned int enc_out_encoding;
unsigned int pix_repet_factor;
unsigned int hdcp_enable;
struct hdmi_vmode video_mode;
@@ -567,6 +564,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
 
+static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_UYYVYY8_1X24:
+   case MEDIA_BUS_FMT_UYYVYY10_1X30:
+   case MEDIA_BUS_FMT_UYYVYY12_1X36:
+   case MEDIA_BUS_FMT_UYYVYY16_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYYVYY8_1X24:
+   return 8;
+
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   case MEDIA_BUS_FMT_UYYVYY10_1X30:
+   return 10;
+
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   case MEDIA_BUS_FMT_UYYVYY12_1X36:
+   return 12;
+
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   case MEDIA_BUS_FMT_UYYVYY16_1X48:
+   return 16;
+
+   default:
+   return 0;
+   }
+}
+
 /*
  * this submodule is responsible for the video data synchronization.
  * for example, for RGB 4:4:4 input, the data map is defined as
@@ -579,37 +662,49 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
int color_format = 0;
u8 val;
 
-   if (hdmi->hdmi_data.enc_in_format == RGB) {
-   if (hdmi->hdmi_data.enc_color_depth == 8)
-   color_format = 0x01;
-   else if (hdmi->hdmi_data.enc_color_depth == 10)
-   color_format = 0x03;
-   else if (hdmi->hdmi_data.enc_color_depth == 12)
-   color_format = 0x05;
-   else if (hdmi->hdmi_data.enc_color_depth == 16)
-   color_format = 0x07;
-   else
-   return;
-   } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) {
-   if (hdmi->hdmi_data.enc_color_depth == 8)
-   color_format = 0x09;
-   else if (hdmi->hdmi_data.enc_color_depth == 10)
-   color_format = 0x0B;
-  

[PATCH v4 0/6] drm: bridge: dw-hdmi: Add support for Custom PHYs

[Neil Armstrong]

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
in combination with a very custom PHY.

Thanks to Laurent Pinchart's changes, the HW report the following :
 Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)

The following differs from common PHY integration as managed in the current
driver :
 - Amlogic PHY is not configured through the internal I2C link
 - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the 
controller
 - Amlogic PHY do not export HPD ands RxSense signals to the controller

And finally, concerning the controller integration :
 - the Controller registers are not flat memory-mapped, and uses an
addr+read/write register pair to write all registers.
 - Inputs only YUV444 pixel data

Most of these uses case are implemented in Laurent Pinchart v5.1 patchset merged
in drm-misc-next branch.

This is why the following patchset implements :
 - Configure the Input format from the plat_data
 - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver

To implement the input format handling, the Synopsys HDMIT TX Controller input
V4L bus formats are used and missing formats + documentation are added.

This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is
also tested on the RK3288 ACT8846 EVB Board.

Changes since v3 at [4] :
 - Fix 4:2:0 bus formats naming
 - Add separate 36bit and 48bit tables for bus formats documentation
 - Added 4:2:0 bus config in hdmi_video_sample
 - Moved dw_hdmi documentation in a "bridge" subdir
 - Rebase on drm-misc-next at 62c58af32c93

Changes since v2 at [3] :
 - Rebase on laurent patch "Extract PHY interrupt setup to a function"
 - Reduce phy operations
 - Switch the V4L bus formats and encodings instead of custom enum

Changes since v1 at [2] :
 - Drop patches submitted by laurent

Changes since RFC at [1] :
 - Regmap fixup for 4bytes register access, tested on RK3288 SoC
 - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops
 - Move HDMI link data into shared header
 - Move Pixel Encoding enum to shared header

[1] 
http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com
[2] 
http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com
[3] 
http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
[4] 
http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com

Laurent Pinchart (1):
  drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

Neil Armstrong (5):
  media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX
Controller
  documentation: media: Add documentation for new RGB and YUV bus
formats
  drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
  drm: bridge: dw-hdmi: Add Documentation on supported input formats
  drm: bridge: dw-hdmi: Move HPD handling to PHY operations

 Documentation/gpu/bridge/dw-hdmi.rst|  15 +
 Documentation/gpu/index.rst |   1 +
 Documentation/media/uapi/v4l/subdev-formats.rst | 871 +++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 469 -
 include/drm/bridge/dw_hdmi.h|  68 ++
 include/uapi/linux/media-bus-format.h   |  13 +-
 6 files changed, 1266 insertions(+), 171 deletions(-)
 create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst

-- 
1.9.1

[PATCH v4 5/6] drm: bridge: dw-hdmi: Add Documentation on supported input formats

[Neil Armstrong]

This patch adds a new DRM documentation entry and links to the input
format table added in the dw_hdmi header.

Signed-off-by: Neil Armstrong 
---
 Documentation/gpu/bridge/dw-hdmi.rst | 15 +++
 Documentation/gpu/index.rst  |  1 +
 2 files changed, 16 insertions(+)
 create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst

diff --git a/Documentation/gpu/bridge/dw-hdmi.rst 
b/Documentation/gpu/bridge/dw-hdmi.rst
new file mode 100644
index 000..486faad
--- /dev/null
+++ b/Documentation/gpu/bridge/dw-hdmi.rst
@@ -0,0 +1,15 @@
+===
+ drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller
+===
+
+Synopsys DesignWare HDMI Controller
+===
+
+This section covers everything related to the Synopsys DesignWare HDMI
+Controller implemented as a DRM bridge.
+
+Supported Input Formats and Encodings
+-
+
+.. kernel-doc:: include/drm/bridge/dw_hdmi.h
+   :doc: Supported input formats and encodings
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index e998ee0..d81c6ff 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide
vc4
vga-switcheroo
vgaarbiter
+   bridge/dw-hdmi
todo
 
 .. only::  subproject and html
-- 
1.9.1

[PATCH 0/3] Handling of reduced FPS in V4L2

[Jose Abreu]

Hi all,

This is a follow up patch from this discussion [1]. It should be
seen more as a starting point to introduce better handling of
time per frame in v4l2. Quoting Hans Verkuil from [1]:

1) "Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set,
then the hw can detect the difference between regular fps
and 1000/1001 fps. Note: this is only valid for timings of
VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set."

2) "Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers
if V4L2_DV_FL_CAN_DETECT_REDUCED_FPS is set."

3) "For standard VIC codes the pixelclock returned by
query_dv_timings is that of the corresponding VIC timing,
not what is measured. This will ensure fixed fps values"

4) "g_parm should calculate the fps based on the v4l2_bt_timings
struct, looking at the REDUCES_FPS flags. For those receivers that
cannot detect the difference, the fps will be 24/30/60 Hz, for
those that can detect the difference g_parm can check if both
V4L2_DV_FL_CAN_DETECT_REDUCED_FPS and V4L2_DV_FL_REDUCED_FPS are
set and reduce the fps by 1000/1001."

---
In terms of implementation:
- Point 1) is done in patch 1/3
- Point 2) and 3) should be done by a HDMI Receiver driver
(I think?).
- Point 4) is done in patch 2/3.
- The patch 3/3 is a simple implementation (which was not
tested) in the cobalt driver
---

[1] https://patchwork.kernel.org/patch/9609441/

Best regards,
Jose Miguel Abreu

Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

Jose Abreu (3):
  [media] videodev2.h: Add new DV flag CAN_DETECT_REDUCED_FPS
  [media] v4l2-dv-timings: Introduce v4l2_calc_timeperframe helper
  [media] cobalt: Use v4l2_calc_timeperframe helper

 drivers/media/pci/cobalt/cobalt-v4l2.c|  9 +--
 drivers/media/v4l2-core/v4l2-dv-timings.c | 39 +++
 include/media/v4l2-dv-timings.h   | 11 +
 include/uapi/linux/videodev2.h|  7 ++
 4 files changed, 64 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH 1/3] [media] videodev2.h: Add new DV flag CAN_DETECT_REDUCED_FPS

[Jose Abreu]

Add a new flag to UAPI for DV timings which, whenever set,
indicates that hardware can detect the difference between
regular FPS and 1000/1001 FPS.

This is specific to HDMI receivers. Also, it is only valid
when V4L2_DV_FL_CAN_REDUCE_FPS is set.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 include/uapi/linux/videodev2.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 45184a2..dd7b426 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1371,6 +1371,13 @@ struct v4l2_bt_timings {
  * InfoFrame).
  */
 #define V4L2_DV_FL_HAS_HDMI_VIC(1 << 8)
+/*
+ * CEA-861 specific: only valid for video receivers.
+ * If set, then HW can detect the difference between regular FPS and
+ * 1000/1001 FPS. Note: This flag is only valid for HDMI VIC codes with
+ * the V4L2_DV_FL_CAN_REDUCE_FPS flag set.
+ */
+#define V4L2_DV_FL_CAN_DETECT_REDUCED_FPS  (1 << 9)
 
 /* A few useful defines to calculate the total blanking and frame sizes */
 #define V4L2_DV_BT_BLANKING_WIDTH(bt) \
-- 
1.9.1

[PATCH 2/3] [media] v4l2-dv-timings: Introduce v4l2_calc_timeperframe helper

[Jose Abreu]

A new helper function was introduced to facilitate the calculation
of time per frame value whenever we have access to the full
v4l2_dv_timings structure.

This should be used only for receivers and only when there is
enough accuracy in the measured pixel clock value as well as in
the horizontal/vertical values.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/media/v4l2-core/v4l2-dv-timings.c | 39 +++
 include/media/v4l2-dv-timings.h   | 11 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 5c8c49d..b7b39c2 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -814,3 +814,42 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8 hor_landscape, 
u8 vert_portrait)
return aspect;
 }
 EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_calc_timeperframe - helper function to calculate timeperframe based
+ * v4l2_dv_timings fields.
+ * @t - Timings for the video mode.
+ *
+ * Calculates the expected timeperframe using the pixel clock value and
+ * horizontal/vertical measures. This means that v4l2_dv_timings structure
+ * must be correctly and fully filled.
+ */
+struct v4l2_fract v4l2_calc_timeperframe(const struct v4l2_dv_timings *t)
+{
+   const struct v4l2_bt_timings *bt = >bt;
+   struct v4l2_fract fps_fract = { 1, 1 };
+   unsigned long n, d;
+   u32 htot, vtot, fps;
+   u64 pclk;
+
+   if (t->type != V4L2_DV_BT_656_1120)
+   return fps_fract;
+
+   htot = V4L2_DV_BT_FRAME_WIDTH(bt);
+   vtot = V4L2_DV_BT_FRAME_HEIGHT(bt);
+   pclk = bt->pixelclock;
+
+   if ((bt->flags & V4L2_DV_FL_CAN_DETECT_REDUCED_FPS) &&
+   (bt->flags & V4L2_DV_FL_REDUCED_FPS))
+   pclk = div_u64(pclk * 1000ULL, 1001);
+
+   fps = (htot * vtot) > 0 ? div_u64((100 * pclk), (htot * vtot)) : 0;
+   if (!fps)
+   return fps_fract;
+
+   rational_best_approximation(fps, 100, fps, 100, , );
+
+   fps_fract.numerator = d;
+   fps_fract.denominator = n;
+   return fps_fract;
+}
+EXPORT_SYMBOL_GPL(v4l2_calc_timeperframe);
diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h
index 61a1889..c1eef08 100644
--- a/include/media/v4l2-dv-timings.h
+++ b/include/media/v4l2-dv-timings.h
@@ -203,6 +203,17 @@ bool v4l2_detect_gtf(unsigned frame_height, unsigned 
hfreq, unsigned vsync,
  */
 struct v4l2_fract v4l2_dv_timings_aspect_ratio(const struct v4l2_dv_timings 
*t);
 
+/**
+ * v4l2_calc_timeperframe - helper function to calculate timeperframe based
+ * v4l2_dv_timings fields.
+ * @t - Timings for the video mode.
+ *
+ * Calculates the expected timeperframe using the pixel clock value and
+ * horizontal/vertical measures. This means that v4l2_dv_timings structure
+ * must be correctly and fully filled.
+ */
+struct v4l2_fract v4l2_calc_timeperframe(const struct v4l2_dv_timings *t);
+
 /*
  * reduce_fps - check if conditions for reduced fps are true.
  * bt - v4l2 timing structure
-- 
1.9.1

[PATCH 3/3] [media] cobalt: Use v4l2_calc_timeperframe helper

[Jose Abreu]

Currently, cobalt driver always returns 60fps in g_parm.
This patch uses the new v4l2_calc_timeperframe helper to
calculate the time per frame value.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/media/pci/cobalt/cobalt-v4l2.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
b/drivers/media/pci/cobalt/cobalt-v4l2.c
index def4a3b..25532ae 100644
--- a/drivers/media/pci/cobalt/cobalt-v4l2.c
+++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
@@ -1076,10 +1076,15 @@ static int cobalt_subscribe_event(struct v4l2_fh *fh,
 
 static int cobalt_g_parm(struct file *file, void *fh, struct v4l2_streamparm 
*a)
 {
+   struct cobalt_stream *s = video_drvdata(file);
+   struct v4l2_fract fps;
+
if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
-   a->parm.capture.timeperframe.numerator = 1;
-   a->parm.capture.timeperframe.denominator = 60;
+
+   fps = v4l2_calc_timeperframe(>timings);
+   a->parm.capture.timeperframe.numerator = fps.numerator;
+   a->parm.capture.timeperframe.denominator = fps.denominator;
a->parm.capture.readbuffers = 3;
return 0;
 }
-- 
1.9.1

Re: [PATCH v5 00/39] i.MX Media Driver

[Russell King - ARM Linux]

On Tue, Mar 21, 2017 at 11:59:02AM +0100, Hans Verkuil wrote:
> Ah, good to hear that -s works with MC. I was not sure about that.
> Thanks for the feedback!

Not soo good on iMX6:

$ v4l2-compliance -d /dev/video10 -s --expbuf-device=/dev/video0
...
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
fail: v4l2-test-input-output.cpp(420): G_INPUT not supported 
for a capture device
test VIDIOC_G/S/ENUMINPUT: FAIL
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
...
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
fail: v4l2-test-controls.cpp(782): subscribe event for control 
'User Controls' failed
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
...
Streaming ioctls:
test read/write: OK (Not Supported)
fail: v4l2-test-buffers.cpp(297): g_field() == V4L2_FIELD_ANY
fail: v4l2-test-buffers.cpp(703): buf.check(q, last_seq)
fail: v4l2-test-buffers.cpp(973): captureBufs(node, q, m2m_q, 
frame_count, false)
test MMAP: FAIL
test USERPTR: OK (Not Supported)
fail: v4l2-test-buffers.cpp(1188): can_stream && ret != EINVAL
test DMABUF: FAIL

(/dev/video0 being CODA).  CODA itself seems to have failures:

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
warn: v4l2-test-formats.cpp(1187): S_PARM is supported for 
buftype 2, but not ENUM_FRAMEINTERVALS
warn: v4l2-test-formats.cpp(1194): S_PARM is supported but 
doesn't report V4L2_CAP_TIMEPERFRAME
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
fail: v4l2-test-formats.cpp(774): fmt_out.g_colorspace() != col
...
Streaming ioctls:
test read/write: OK (Not Supported)
fail: v4l2-test-buffers.cpp(956): q.create_bufs(node, 1, ) 
!= EINVAL
test MMAP: FAIL
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

[Russell King - ARM Linux]

On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote:
> @@ -1173,15 +1196,8 @@ static void csi_try_fmt(struct csi_priv *priv,
>   incc = imx_media_find_mbus_format(infmt->code,
> CS_SEL_ANY, true);
>  
> - if (sdformat->format.width < priv->crop.width * 3 / 4)
> - sdformat->format.width = priv->crop.width / 2;
> - else
> - sdformat->format.width = priv->crop.width;
> -
> - if (sdformat->format.height < priv->crop.height * 3 / 4)
> - sdformat->format.height = priv->crop.height / 2;
> - else
> - sdformat->format.height = priv->crop.height;
> + sdformat->format.width = compose->width;
> + sdformat->format.height = compose->height;
>  
>   if (incc->bayer) {
>   sdformat->format.code = infmt->code;

We need to do more in here, because right now setting the source pads
overwrites the colorimetry etc information.  Maybe something like the
below?  I'm wondering if it would be a saner approach to copy the
sink format and update the parameters that can be changed, rather than
trying to list all the parameters that shouldn't be changed.  What if
the format structure gains a new member?

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 1492b92e1970..756204ced53c 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1221,6 +1221,12 @@ static void csi_try_fmt(struct csi_priv *priv,
sdformat->format.field =  (infmt->height == 480) ?
V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
}
+
+   /* copy settings we can't change */
+   sdformat->format.colorspace = infmt->colorspace;
+   sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
+   sdformat->format.quantization = infmt->quantization;
+   sdformat->format.xfer_func = infmt->xfer_func;
break;
case CSI_SINK_PAD:
v4l_bound_align_image(>format.width, MIN_W, MAX_W,



-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCHv5 00/16] atmel-isi/ov7670/ov2640: convert to standalone drivers

[Sakari Ailus]

Hi Hans,

On Sat, Mar 11, 2017 at 12:23:12PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series converts the soc-camera atmel-isi to a standalone V4L2
> driver.
> 
> The same is done for the ov7670 and ov2640 sensor drivers: the ov7670 was
> used to test the atmel-isi driver. The ov2640 is needed because the em28xx
> driver has a soc_camera include dependency. Both ov7670 and ov2640 sensors
> have been tested with the atmel-isi driver.
> 
> The first 5 patches improve the ov7670 sensor driver, mostly adding modern
> features such as DT support.
> 
> The next three convert the atmel-isi and move it out of soc_camera.
> 
> The following 6 patches convert ov2640 and drop the soc_camera dependency
> in em28xx. I have tested that this works with my 'SpeedLink Vicious And
> Divine Laplace webcam'.
> 
> The last two patches add isi support to the DT: the first for the ov7670
> sensor, the second modifies it for the ov2640 sensor.
> 
> These two final patches are for demonstration purposes only, I do not plan
> on merging them.
> 
> Tested with my sama5d3-Xplained board, the ov2640 sensor and two ov7670
> sensors: one with and one without reset/pwdn pins. Also tested with my
> em28xx-based webcam.
> 
> I'd like to get this in for 4.12. Fingers crossed.

A question on the last two patches --- what's in the commit description
still holds, right? In that case, how about dropping them from the set?
There have been no changes to those patches during review AFAIR.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Pavel Machek]

Hi!

> > Making use of the full potential of the hardware requires using a more
> > expressive interface. 
> 
> That's the core of the problem: most users don't need "full potential
> of the hardware". It is actually worse than that: several boards
> don't allow "full potential" of the SoC capabilities.

Well, in kernel we usually try to support "full hardware" potential.

And we are pretty sure users would like to take still photos, even if
common v4l2 applications can not do it.

> > That's what the kernel interface must provide. If
> > we decide to limit ourselves to a small sub-set of that potential on the
> > level of the kernel interface, we have made a wrong decision. It's as
> > simple as that. This is why the functionality (and which requires taking
> > a lot of policy decisions) belongs to the user space. We cannot have
> > multiple drivers providing multiple kernel interfaces for the same hardware.
> 
> I strongly disagree. Looking only at the hardware capabilities without
> having a solution to provide what the user wants is *wrong*.

Hardware manufacturers already did this kind of research for us. They
don't usually include features noone wants...

> Another case: the cx25821 hardware supports 12 video streams, 
> consuming almost all available bandwidth of an ePCI bus. Each video 
> stream connector can either be configured to be capture or output, in
> runtime. The hardware vendor chose to hardcode the driver to provide
> 8 inputs and 4 outputs. Their decision was based in the fact that
> the driver is already very complex, and it satisfies their customer's 
> needs. The cost/efforts of make the driver to be reconfigured in
> runtime were too high for almost no benefit.

Well, it is okay to provide 'limited' driver -- there's possibility to
fix the driver. But IMO it is not okay to provide 'limited' kernel
interface -- because if you try to fix it, you'll suddenly have
regressions.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v5 00/39] i.MX Media Driver

[Hans Verkuil]

On 03/21/17 11:42, Niklas Söderlund wrote:
> On 2017-03-20 16:57:54 +0100, Hans Verkuil wrote:
>> On 03/20/2017 03:11 PM, Russell King - ARM Linux wrote:
>>> On Mon, Mar 20, 2017 at 02:57:03PM +0100, Hans Verkuil wrote:
 On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote:
> It's what I have - remember, not everyone is happy to constantly replace
> their distro packages with random new stuff.

 This is a compliance test, which is continuously developed in tandem with
 new kernel versions. If you are working with an upstream kernel, then you
 should also use the corresponding v4l2-compliance test. What's the point
 of using an old one?

 I will not support driver developers that use an old version of the
 compliance test, that's a waste of my time.
>>>
>>> The reason that people may _not_ wish to constantly update v4l-utils
>>> is that it changes the libraries installed on their systems.
>>>
>>> So, the solution to that is not to complain about developers not using
>>> the latest version, but instead to de-couple it from the rest of the
>>> package, and provide it as a separate, stand-alone package that doesn't
>>> come with all the extra baggage.
>>>
>>> Now, there's two possible answers to that:
>>>
>>> 1. it depends on the libv4l2 version.  If that's so, then you are
>>>insisting that people constantly move to the latest libv4l2 because
>>>of API changes, and those API changes may upset applications they're
>>>using.  So this isn't really on.
>>>
>>> 2. it doesn't depend on libv4l2 version, in which case there's no reason
>>>for it to be packaged with v4l-utils.
>>
>> Run configure with --disable-v4l2-compliance-libv4l.
>>
>> This avoids linking with libv4l and allows you to build it stand-alone.
>>
>> Perhaps I should invert this option since in most cases you don't want to
>> run v4l2-compliance with libv4l (it's off by default unless you pass the
>> -w option to v4l2-compliance).
>>
>>>
>>> The reality is that v4l2-compliance links with libv4l2, so I'm not sure
>>> which it is.  What I am sure of is that I don't want to upgrade libv4l2
>>> on an ad-hoc basis, potentially causing issues with applications.
>>>
>> To test actual streaming you need to provide the -s option.
>>
>> Note: v4l2-compliance has been developed for 'regular' video devices,
>> not MC devices. It may or may not work with the -s option.
>
> Right, and it exists to verify that the establised v4l2 API is correctly
> implemented.  If the v4l2 API is being offered to user applications,
> then it must be conformant, otherwise it's not offering the v4l2 API.
> (That's very much a definition statement in itself.)
>
> So, are we really going to say MC devices do not offer the v4l2 API to
> userspace, but something that might work?  We've already seen today
> one user say that they're not going to use mainline because of the
> crud surrounding MC.
>

 Actually, my understanding was that he was stuck on the old kernel code.
>>>
>>> Err, sorry, I really don't follow.  Who is "he"?
>>
>> "one user say that they're not going to use mainline because of the
>> crud surrounding MC."
>>
>>>
>>> _I_ was the one who reported the EXPBUF problem.  Your comment makes no
>>> sense.
>>>
 In the case of v4l2-compliance, I never had the time to make it work with
 MC devices. Same for that matter of certain memory to memory devices.

 Just like MC devices these too behave differently. They are partially
 supported in v4l2-compliance, but not fully.
>>>
>>> It seems you saying that the API provided by /dev/video* for a MC device
>>> breaks the v4l2-compliance tests?
>>
>> There may be tests in the compliance suite that do not apply for MC devices
>> and for which I never check. The compliance suite was never written with MC
>> devices in mind, and it certainly hasn't been tested much with such devices.
>>
>> It's only very recent that I even got hardware that has MC support...
>>
>> From what I can tell from the feedback I got it seems to be OKish, but I
>> just can't guarantee that the compliance utility is correct for such devices.
>>
>> In particular I doubt the streaming tests (-s, -f, etc.) will work. The -s
>> test *might* work if the pipeline is configured correctly before running
>> v4l2-compliance. I can't imagine that the -f option would work at all since
>> I would expect pipeline validation errors.
> 
> I successfully use v4l2-compliance with the -s option to test the 
> Renesas R-Car Gen3 driver which uses MC, I first have to setup the 
> pipeline using media-ctl. I have had much use of the tool and it have 
> helped me catch many errors in the rcar-vin driver both on Gen2 (no MC 
> involved) and Gen3. And yes the -f option is only usable on Gen2 where 
> MC is not used.

Ah, good to hear that -s works with MC. I was not sure about that.
Thanks for the feedback!

Regards,

Hans

Re: [PATCH v5 00/39] i.MX Media Driver

[Niklas Söderlund]

On 2017-03-20 16:57:54 +0100, Hans Verkuil wrote:
> On 03/20/2017 03:11 PM, Russell King - ARM Linux wrote:
> > On Mon, Mar 20, 2017 at 02:57:03PM +0100, Hans Verkuil wrote:
> >> On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote:
> >>> It's what I have - remember, not everyone is happy to constantly replace
> >>> their distro packages with random new stuff.
> >>
> >> This is a compliance test, which is continuously developed in tandem with
> >> new kernel versions. If you are working with an upstream kernel, then you
> >> should also use the corresponding v4l2-compliance test. What's the point
> >> of using an old one?
> >>
> >> I will not support driver developers that use an old version of the
> >> compliance test, that's a waste of my time.
> > 
> > The reason that people may _not_ wish to constantly update v4l-utils
> > is that it changes the libraries installed on their systems.
> > 
> > So, the solution to that is not to complain about developers not using
> > the latest version, but instead to de-couple it from the rest of the
> > package, and provide it as a separate, stand-alone package that doesn't
> > come with all the extra baggage.
> > 
> > Now, there's two possible answers to that:
> > 
> > 1. it depends on the libv4l2 version.  If that's so, then you are
> >insisting that people constantly move to the latest libv4l2 because
> >of API changes, and those API changes may upset applications they're
> >using.  So this isn't really on.
> > 
> > 2. it doesn't depend on libv4l2 version, in which case there's no reason
> >for it to be packaged with v4l-utils.
> 
> Run configure with --disable-v4l2-compliance-libv4l.
> 
> This avoids linking with libv4l and allows you to build it stand-alone.
> 
> Perhaps I should invert this option since in most cases you don't want to
> run v4l2-compliance with libv4l (it's off by default unless you pass the
> -w option to v4l2-compliance).
> 
> > 
> > The reality is that v4l2-compliance links with libv4l2, so I'm not sure
> > which it is.  What I am sure of is that I don't want to upgrade libv4l2
> > on an ad-hoc basis, potentially causing issues with applications.
> > 
>  To test actual streaming you need to provide the -s option.
> 
>  Note: v4l2-compliance has been developed for 'regular' video devices,
>  not MC devices. It may or may not work with the -s option.
> >>>
> >>> Right, and it exists to verify that the establised v4l2 API is correctly
> >>> implemented.  If the v4l2 API is being offered to user applications,
> >>> then it must be conformant, otherwise it's not offering the v4l2 API.
> >>> (That's very much a definition statement in itself.)
> >>>
> >>> So, are we really going to say MC devices do not offer the v4l2 API to
> >>> userspace, but something that might work?  We've already seen today
> >>> one user say that they're not going to use mainline because of the
> >>> crud surrounding MC.
> >>>
> >>
> >> Actually, my understanding was that he was stuck on the old kernel code.
> > 
> > Err, sorry, I really don't follow.  Who is "he"?
> 
> "one user say that they're not going to use mainline because of the
> crud surrounding MC."
> 
> > 
> > _I_ was the one who reported the EXPBUF problem.  Your comment makes no
> > sense.
> > 
> >> In the case of v4l2-compliance, I never had the time to make it work with
> >> MC devices. Same for that matter of certain memory to memory devices.
> >>
> >> Just like MC devices these too behave differently. They are partially
> >> supported in v4l2-compliance, but not fully.
> > 
> > It seems you saying that the API provided by /dev/video* for a MC device
> > breaks the v4l2-compliance tests?
> 
> There may be tests in the compliance suite that do not apply for MC devices
> and for which I never check. The compliance suite was never written with MC
> devices in mind, and it certainly hasn't been tested much with such devices.
> 
> It's only very recent that I even got hardware that has MC support...
> 
> From what I can tell from the feedback I got it seems to be OKish, but I
> just can't guarantee that the compliance utility is correct for such devices.
> 
> In particular I doubt the streaming tests (-s, -f, etc.) will work. The -s
> test *might* work if the pipeline is configured correctly before running
> v4l2-compliance. I can't imagine that the -f option would work at all since
> I would expect pipeline validation errors.

I successfully use v4l2-compliance with the -s option to test the 
Renesas R-Car Gen3 driver which uses MC, I first have to setup the 
pipeline using media-ctl. I have had much use of the tool and it have 
helped me catch many errors in the rcar-vin driver both on Gen2 (no MC 
involved) and Gen3. And yes the -f option is only usable on Gen2 where 
MC is not used.

For what it's worth, the first versions of the R-Car Gen3 patches did 
not use MC for anything else then setting up the pipeline, all format 
propagation and communication with subdevice where 

Re: [PATCH v3 2/4] media-ctl: print the configured frame interval

[Philipp Zabel]

On Mon, 2017-02-13 at 12:40 +0100, Philipp Zabel wrote:
> After the pad format, also print the frame interval, if already configured.
> 
> Signed-off-by: Philipp Zabel 
> Acked-by: Sakari Ailus 
> ---
>  utils/media-ctl/media-ctl.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/utils/media-ctl/media-ctl.c b/utils/media-ctl/media-ctl.c
> index 572bcf7..383fbfa 100644
> --- a/utils/media-ctl/media-ctl.c
> +++ b/utils/media-ctl/media-ctl.c
> @@ -79,6 +79,7 @@ static void v4l2_subdev_print_format(struct media_entity 
> *entity,
>   unsigned int pad, enum v4l2_subdev_format_whence which)
>  {
>   struct v4l2_mbus_framefmt format;
> + struct v4l2_fract interval = { 0, 0 };
>   struct v4l2_rect rect;
>   int ret;
>  
> @@ -86,10 +87,17 @@ static void v4l2_subdev_print_format(struct media_entity 
> *entity,
>   if (ret != 0)
>   return;
>  
> + ret = v4l2_subdev_get_frame_interval(entity, , pad);
> + if (ret != 0 && ret != -ENOTTY)

I noticed the documentation says in 8.60.5. Return Value [1]:

  EINVAL
The struct v4l2_subdev_frame_interval pad references a non-existing
pad, or the pad doesn’t support frame intervals.

even though VIDIOC_SUBDEV_G_FRAME_INTERVAL returns ENOTTY (by way of
ENOIOCTLCMD) if .g_frame_interval in the video ops is not implemented.
Is this an error in the spec, an error in the code, or just me
misunderstanding?

Should this line be changed to
if (ret != 0 && ret != -ENOTTY && ret != -EINVAL)
?

[1] 
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-subdev-g-frame-interval.html#return-value

> + return;
> +
>   printf("\t\t[fmt:%s/%ux%u",
>  v4l2_subdev_pixelcode_to_string(format.code),
>  format.width, format.height);
>  
> + if (interval.numerator || interval.denominator)
> + printf("@%u/%u", interval.numerator, interval.denominator);
> +
>   if (format.field)
>   printf(" field:%s", v4l2_subdev_field_to_string(format.field));
>  

regards
Philipp

Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t

[Nicholas A. Bellinger]

Hi Elena,

On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/target/target_core_iblock.c | 12 ++--
>  drivers/target/target_core_iblock.h |  3 ++-
>  2 files changed, 8 insertions(+), 7 deletions(-)

After reading up on this thread, it looks like various subsystem
maintainers are now picking these atomic_t -> refcount_t conversions..

That said, applied to target-pending/for-next and will plan to include
for v4.12-rc1 merge window.

Thanks!

Re: [PATCH 06/24] atomisp: kill another define

[Greg KH]

On Mon, Mar 20, 2017 at 02:39:38PM +, Alan Cox wrote:
> We don't need an ifdef for the sake of 8-12 bytes. This undoes the ifdef 
> added by
> fde469701c7efabebf885e785edf367bfb1a8f3f. Instead turn it into a single const 
> string
> array at a fixed location thereby saving even more memory.
> 
> Signed-off-by: Alan Cox 
> ---
>  .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |   23 
> +---
>  1 file changed, 10 insertions(+), 13 deletions(-)
> 

This patch didn't apply to my tree, can you rebase it and resend?

thanks,

greg k-h