Re: drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:18: error: too many arguments to function 'horus3a_attach'

2015-09-21 Thread Javier Martinez Canillas
Hello,

On Sun, Sep 20, 2015 at 10:56 AM, kbuild test robot
 wrote:
> Hi Kozlov,
>
> FYI, the error/warning still remains. You may either fix it or ask me to 
> silently ignore in future.
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   99bc7215bc60f6cd414cf1b85cd9d52cc596cccb
> commit: 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e [media] netup_unidvb: NetUP 
> Universal DVB-S/S2/T/T2/C PCI-E card driver
> date:   6 weeks ago
> config: i386-randconfig-b0-09201649 (attached as .config)
> reproduce:
>   git checkout 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e
>   # save the attached .config to linux build tree
>   make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from 
> drivers/media/pci/netup_unidvb/netup_unidvb_core.c:34:0:
>drivers/media/dvb-frontends/horus3a.h:51:13: warning: 'struct 
> cxd2820r_config' declared inside parameter list
>  struct i2c_adapter *i2c)
>

I had already posted a patch to fix this issue about a week ago:

https://patchwork.linuxtv.org/patch/31401/

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: drivers/media/dvb-frontends/lnbh25.h:46:15: error: unknown type name 'dvb_frontend'

2015-09-21 Thread Javier Martinez Canillas
Hello,

On Sun, Sep 20, 2015 at 5:17 AM, kbuild test robot
 wrote:
> Hi Kozlov,
>
> FYI, the error/warning still remains. You may either fix it or ask me to 
> silently ignore in future.
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   133bb59585140747fd3938002670cb395f40dc76
> commit: 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e [media] netup_unidvb: NetUP 
> Universal DVB-S/S2/T/T2/C PCI-E card driver
> date:   6 weeks ago
> config: x86_64-randconfig-h0-09201020 (attached as .config)
> reproduce:
>   git checkout 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e
>   # save the attached .config to linux build tree
>   make ARCH=x86_64
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from 
> drivers/media/pci/netup_unidvb/netup_unidvb_core.c:36:0:
>>> drivers/media/dvb-frontends/lnbh25.h:46:15: error: unknown type name 
>>> 'dvb_frontend'
> static inline dvb_frontend *lnbh25_attach(
>   ^
>
> vim +/dvb_frontend +46 drivers/media/dvb-frontends/lnbh25.h
>
> e025273b Kozlov Sergey 2015-07-28  40  #if IS_REACHABLE(CONFIG_DVB_LNBH25)
> e025273b Kozlov Sergey 2015-07-28  41  struct dvb_frontend *lnbh25_attach(
> e025273b Kozlov Sergey 2015-07-28  42   struct dvb_frontend *fe,
> e025273b Kozlov Sergey 2015-07-28  43   struct lnbh25_config *cfg,
> e025273b Kozlov Sergey 2015-07-28  44   struct i2c_adapter *i2c);
> e025273b Kozlov Sergey 2015-07-28  45  #else
> e025273b Kozlov Sergey 2015-07-28 @46  static inline dvb_frontend 
> *lnbh25_attach(
> e025273b Kozlov Sergey 2015-07-28  47   struct dvb_frontend *fe,
> e025273b Kozlov Sergey 2015-07-28  48   struct lnbh25_config *cfg,
> e025273b Kozlov Sergey 2015-07-28  49   struct i2c_adapter *i2c)
>
> :: The code at line 46 was first introduced by commit
> :: e025273b86fb4a6440192b809e05332777c3faa5 [media] lnbh25: LNBH25 SEC 
> controller driver
>
> :: TO: Kozlov Sergey 
> :: CC: Mauro Carvalho Chehab 
>

I had already posted a patch to fix this issue about a week ago:

https://patchwork.linuxtv.org/patch/31402/

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/5] media: atmel-isi: support RGB565 output when sensor output YUV formats

2015-09-21 Thread Josh Wu
This patch enable Atmel ISI preview path to convert the YUV to RGB format.

Signed-off-by: Josh Wu 
---

 drivers/media/platform/soc_camera/atmel-isi.c | 38 ---
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index e87d354..e33a16a 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -201,13 +201,20 @@ static bool is_supported(struct soc_camera_device *icd,
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
+   /* RGB */
+   case V4L2_PIX_FMT_RGB565:
return true;
-   /* RGB, TODO */
default:
return false;
}
 }
 
+static bool is_output_rgb(const struct soc_mbus_pixelfmt *host_fmt)
+{
+   return host_fmt->fourcc == V4L2_PIX_FMT_RGB565 ||
+   host_fmt->fourcc == V4L2_PIX_FMT_RGB32;
+}
+
 static irqreturn_t atmel_isi_handle_streaming(struct atmel_isi *isi)
 {
if (isi->active) {
@@ -467,6 +474,8 @@ static int start_streaming(struct vb2_queue *vq, unsigned 
int count)
struct atmel_isi *isi = ici->priv;
int ret;
 
+   isi->enable_preview_path = is_output_rgb(icd->current_fmt->host_fmt);
+
pm_runtime_get_sync(ici->v4l2_dev.dev);
 
/* Reset ISI */
@@ -688,6 +697,14 @@ static const struct soc_mbus_pixelfmt isi_camera_formats[] 
= {
.order  = SOC_MBUS_ORDER_LE,
.layout = SOC_MBUS_LAYOUT_PACKED,
},
+   {
+   .fourcc = V4L2_PIX_FMT_RGB565,
+   .name   = "RGB565",
+   .bits_per_sample= 8,
+   .packing= SOC_MBUS_PACKING_2X8_PADHI,
+   .order  = SOC_MBUS_ORDER_LE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
+   },
 };
 
 /* This will be corrected as we get more formats */
@@ -744,7 +761,7 @@ static int isi_camera_get_formats(struct soc_camera_device 
*icd,
  struct soc_camera_format_xlate *xlate)
 {
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
-   int formats = 0, ret;
+   int formats = 0, ret, i, n;
/* sensor format */
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
@@ -778,13 +795,16 @@ static int isi_camera_get_formats(struct 
soc_camera_device *icd,
case MEDIA_BUS_FMT_VYUY8_2X8:
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_YVYU8_2X8:
-   formats++;
-   if (xlate) {
-   xlate->host_fmt = _camera_formats[0];
-   xlate->code = code.code;
-   xlate++;
-   dev_dbg(icd->parent, "Providing format %s using code 
%d\n",
-   isi_camera_formats[0].name, code.code);
+   n = ARRAY_SIZE(isi_camera_formats);
+   formats += n;
+   for (i = 0; i < n; i++) {
+   if (xlate) {
+   xlate->host_fmt = _camera_formats[i];
+   xlate->code = code.code;
+   dev_dbg(icd->parent, "Providing format %s using 
code %d\n",
+   isi_camera_formats[0].name, code.code);
+   xlate++;
+   }
}
break;
default:
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/5] media: atmel-isi: correct yuv swap according to different sensor outputs

2015-09-21 Thread Josh Wu
we need to configure the YCC_SWAP bits in ISI_CFG2 according to current
sensor output and Atmel ISI output format.

Current there are two cases Atmel ISI supported:
  1. Atmel ISI outputs YUYV format.
 This case we need to setup YCC_SWAP according to sensor output
 format.
  2. Atmel ISI output a pass-through formats, which means no swap.
 Just setup YCC_SWAP as default with no swap.

Signed-off-by: Josh Wu 
---

 drivers/media/platform/soc_camera/atmel-isi.c | 43 ---
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index 45e304a..df64294 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -103,13 +103,41 @@ static u32 isi_readl(struct atmel_isi *isi, u32 reg)
return readl(isi->regs + reg);
 }
 
+static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
+   const struct soc_camera_format_xlate *xlate)
+{
+   /* By default, no swap for the codec path of Atmel ISI. So codec
+   * output is same as sensor's output.
+   * For instance, if sensor's output is YUYV, then codec outputs YUYV.
+   * And if sensor's output is UYVY, then codec outputs UYVY.
+   */
+   u32 cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_DEFAULT;
+
+   if (xlate->host_fmt->fourcc == V4L2_PIX_FMT_YUYV) {
+   /* all convert to YUYV */
+   switch (xlate->code) {
+   case MEDIA_BUS_FMT_VYUY8_2X8:
+   cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_MODE_3;
+   break;
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_MODE_2;
+   break;
+   case MEDIA_BUS_FMT_YVYU8_2X8:
+   cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_MODE_1;
+   break;
+   }
+   }
+
+   return cfg2_yuv_swap;
+}
+
 static void configure_geometry(struct atmel_isi *isi, u32 width,
-   u32 height, u32 code)
+   u32 height, const struct soc_camera_format_xlate *xlate)
 {
u32 cfg2;
 
/* According to sensor's output format to set cfg2 */
-   switch (code) {
+   switch (xlate->code) {
default:
/* Grey */
case MEDIA_BUS_FMT_Y8_1X8:
@@ -117,16 +145,11 @@ static void configure_geometry(struct atmel_isi *isi, u32 
width,
break;
/* YUV */
case MEDIA_BUS_FMT_VYUY8_2X8:
-   cfg2 = ISI_CFG2_YCC_SWAP_MODE_3 | ISI_CFG2_COL_SPACE_YCbCr;
-   break;
case MEDIA_BUS_FMT_UYVY8_2X8:
-   cfg2 = ISI_CFG2_YCC_SWAP_MODE_2 | ISI_CFG2_COL_SPACE_YCbCr;
-   break;
case MEDIA_BUS_FMT_YVYU8_2X8:
-   cfg2 = ISI_CFG2_YCC_SWAP_MODE_1 | ISI_CFG2_COL_SPACE_YCbCr;
-   break;
case MEDIA_BUS_FMT_YUYV8_2X8:
-   cfg2 = ISI_CFG2_YCC_SWAP_DEFAULT | ISI_CFG2_COL_SPACE_YCbCr;
+   cfg2 = ISI_CFG2_COL_SPACE_YCbCr |
+   setup_cfg2_yuv_swap(isi, xlate);
break;
/* RGB, TODO */
}
@@ -407,7 +430,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned 
int count)
isi_writel(isi, ISI_INTDIS, (u32)~0UL);
 
configure_geometry(isi, icd->user_width, icd->user_height,
-   icd->current_fmt->code);
+   icd->current_fmt);
 
spin_lock_irq(>lock);
/* Clear any pending interrupt */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/5] media: atmel-isi: enable preview path to output RGB565 format

2015-09-21 Thread Josh Wu
This series will enable preview path support in atmel-isi. Which can
make atmel-isi convert the YUV format (from sensor) to RGB565 format.


Josh Wu (5):
  media: atmel-isi: correct yuv swap according to different sensor
outputs
  media: atmel-isi: prepare for the support of preview path
  media: atmel-isi: add code to setup correct resolution for preview
path
  media: atmel-isi: setup YCC_SWAP correctly when using preview path
  media: atmel-isi: support RGB565 output when sensor output YUV formats

 drivers/media/platform/soc_camera/atmel-isi.c | 181 --
 drivers/media/platform/soc_camera/atmel-isi.h |  10 ++
 2 files changed, 148 insertions(+), 43 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/5] media: atmel-isi: setup YCC_SWAP correctly when using preview path

2015-09-21 Thread Josh Wu
The preview path only can convert UYVY format to RGB data.

To make preview path work correctly, we need to set up YCC_SWAP
according to sensor output and convert them to UYVY.

Signed-off-by: Josh Wu 
---

 drivers/media/platform/soc_camera/atmel-isi.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index bbf6449..e87d354 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -127,6 +127,22 @@ static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_MODE_1;
break;
}
+   } else if (xlate->host_fmt->fourcc == V4L2_PIX_FMT_RGB565) {
+   /* Preview path is enabled, it will convert UYVY to RGB format.
+* But if sensor output format is not UYVY, we need to set
+* YCC_SWAP_MODE to convert it as UYVY.
+*/
+   switch (xlate->code) {
+   case MEDIA_BUS_FMT_VYUY8_2X8:
+   cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_MODE_1;
+   break;
+   case MEDIA_BUS_FMT_YUYV8_2X8:
+   cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_MODE_2;
+   break;
+   case MEDIA_BUS_FMT_YVYU8_2X8:
+   cfg2_yuv_swap = ISI_CFG2_YCC_SWAP_MODE_3;
+   break;
+   }
}
 
return cfg2_yuv_swap;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/5] media: atmel-isi: add code to setup correct resolution for preview path

2015-09-21 Thread Josh Wu
Not like codec path, preview path can do downsampling, so we should setup
a extra preview width, height for it.

This patch add preview resolution setup without down sampling. So currently
preview path will output same size as sensor output size.

Signed-off-by: Josh Wu 
---

 drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
 drivers/media/platform/soc_camera/atmel-isi.h | 10 ++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index e6f4ade..bbf6449 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -135,7 +135,7 @@ static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
 static void configure_geometry(struct atmel_isi *isi, u32 width,
u32 height, const struct soc_camera_format_xlate *xlate)
 {
-   u32 cfg2;
+   u32 cfg2, psize;
 
/* According to sensor's output format to set cfg2 */
switch (xlate->code) {
@@ -163,6 +163,16 @@ static void configure_geometry(struct atmel_isi *isi, u32 
width,
cfg2 |= ((height - 1) << ISI_CFG2_IM_VSIZE_OFFSET)
& ISI_CFG2_IM_VSIZE_MASK;
isi_writel(isi, ISI_CFG2, cfg2);
+
+   /* No down sampling, preview size equal to sensor output size */
+   psize = ((width - 1) << ISI_PSIZE_PREV_HSIZE_OFFSET) &
+   ISI_PSIZE_PREV_HSIZE_MASK;
+   psize |= ((height - 1) << ISI_PSIZE_PREV_VSIZE_OFFSET) &
+   ISI_PSIZE_PREV_VSIZE_MASK;
+   isi_writel(isi, ISI_PSIZE, psize);
+   isi_writel(isi, ISI_PDECF, ISI_PDECF_NO_SAMPLING);
+
+   return;
 }
 
 static bool is_supported(struct soc_camera_device *icd,
diff --git a/drivers/media/platform/soc_camera/atmel-isi.h 
b/drivers/media/platform/soc_camera/atmel-isi.h
index 5acc771..0acb32a 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.h
+++ b/drivers/media/platform/soc_camera/atmel-isi.h
@@ -79,6 +79,16 @@
 #define ISI_CFG2_IM_VSIZE_MASK (0x7FF << ISI_CFG2_IM_VSIZE_OFFSET)
 #define ISI_CFG2_IM_HSIZE_MASK (0x7FF << ISI_CFG2_IM_HSIZE_OFFSET)
 
+/* Bitfields in PSIZE */
+#define ISI_PSIZE_PREV_VSIZE_OFFSET0
+#define ISI_PSIZE_PREV_HSIZE_OFFSET16
+#define ISI_PSIZE_PREV_VSIZE_MASK  (0x3FF << ISI_PSIZE_PREV_VSIZE_OFFSET)
+#define ISI_PSIZE_PREV_HSIZE_MASK  (0x3FF << ISI_PSIZE_PREV_HSIZE_OFFSET)
+
+/* Bitfields in PDECF */
+#define ISI_PDECF_DEC_FACTOR_MASK  (0xFF << 0)
+#defineISI_PDECF_NO_SAMPLING   (16)
+
 /* Bitfields in CTRL */
 /* Also using in SR(ISI_V2) */
 #define ISI_CTRL_EN(1 << 0)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Sylwester Nawrocki
Hi Mauro,

On 21/09/15 13:41, Mauro Carvalho Chehab wrote:
> Btw, I just got a Samsung TM1 device, with seems to be using an arm64
> SoC. Is this driver providing support for its camera?

The TM1 device (Z3) is based on a Qualcomm 64-bit SoC. The $subject
patch adds support for a standalone JPEG codec IP block of Samsung
Exynos5433 SoC, which can be found for instance in Galaxy Note4.
Perhaps someone else can provide more details regarding the TM1's camera
status.

-- 
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [media] tvp5150: add support for asynchronous probing

2015-09-21 Thread Sakari Ailus
Javier Martinez Canillas wrote:
> Allow the subdevice to be probed asynchronously.
> 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device

2015-09-21 Thread Tiffany Lin
vb2_dc_prepare use the number of SG entries dma_map_sg_attrs return.
But in dma_sync_sg_for_device, it use lengths of each SG entries
before dma_map_sg_attrs. dma_map_sg_attrs will concatenate
SGs until dma length > dma seg bundary. sgt->nents will less than
sgt->orig_nents. Using SG entries after dma_map_sg_attrs
in vb2_dc_prepare will make some SGs are not sync to device.
After add DMA_ATTR_SKIP_CPU_SYNC in vb2_dc_get_userptr to remove
sync data to device twice. Device randomly get incorrect data because
some SGs are not sync to device. Change to use number of SG entries
before dma_map_sg_attrs in vb2_dc_prepare to prevent this issue.

Signed-off-by: Tiffany Lin 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 2397ceb..c5d00bd 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -100,7 +100,7 @@ static void vb2_dc_prepare(void *buf_priv)
if (!sgt || buf->db_attach)
return;
 
-   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, 
buf->dma_dir);
 }
 
 static void vb2_dc_finish(void *buf_priv)
@@ -112,7 +112,7 @@ static void vb2_dc_finish(void *buf_priv)
if (!sgt || buf->db_attach)
return;
 
-   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
 }
 
 /*/
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Andrzej Pietrasiewicz

Hi Mauro,

W dniu 21.09.2015 o 13:41, Mauro Carvalho Chehab pisze:





I think the media subsystem can take patches 1-3 and whoever does DT patches can
take this patch, right?



The cover letter explains that the series is rebased onto Mauro's
master with Kukjin's branch merged. The latter does contain
the exynos5433.dtsi. That said, yes, taking patches 1-3 in
media subsystem and leaving DT patch to someone else is the
way to go.


I'm ok with such strategy, provided that the new driver builds fine with
COMPILE_TEST without the need of the dtsi patch.



I've checked. It does compile with COMPILE_TEST.



Please also notice that, if the driver uses MC, it has to wait for
the MC next gen support to be merged,


No, it does not. It is a rather simple mem2mem device.

Sylwester has answered about camera support which is a different
topic.

Andrzej
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Mauro Carvalho Chehab
Em Mon, 21 Sep 2015 11:59:27 +0200
Andrzej Pietrasiewicz  escreveu:

> Hi Hans,
> 
> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
> > On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> >> From: Marek Szyprowski 
> >>
> >> Add Exynos 5433 jpeg h/w codec node.
> >>
> >> Signed-off-by: Marek Szyprowski 
> >> Signed-off-by: Andrzej Pietrasiewicz 
> >> ---
> >>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
> >>   1 file changed, 21 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
> >> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> >
> > This dtsi file doesn't exist in the media-git tree. What is the story here?
> >
> > Should this go through a different subsystem?
> >
> > I think the media subsystem can take patches 1-3 and whoever does DT 
> > patches can
> > take this patch, right?
> >
> 
> The cover letter explains that the series is rebased onto Mauro's
> master with Kukjin's branch merged. The latter does contain
> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
> media subsystem and leaving DT patch to someone else is the
> way to go.

I'm ok with such strategy, provided that the new driver builds fine with
COMPILE_TEST without the need of the dtsi patch.

Please also notice that, if the driver uses MC, it has to wait for
the MC next gen support to be merged, and may need to be rebased, due
to a few changes at the MC internal APIs: one function got renamed
(the function that create links between two pads) and we're now using
lists for links (that will only affect the driver if it has its own
graph traversal routines).

Btw, I just got a Samsung TM1 device, with seems to be using an arm64
SoC. Is this driver providing support for its camera?

Regards,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/38] Fixes related to incorrect usage of unsigned types

2015-09-21 Thread David Howells
Andrzej Hajda  wrote:

> Semantic patch finds comparisons of types:
> unsigned < 0
> unsigned >= 0
> The former is always false, the latter is always true.
> Such comparisons are useless, so theoretically they could be
> safely removed, but their presence quite often indicates bugs.

Or someone has left them in because they don't matter and there's the
possibility that the type being tested might be or become signed under some
circumstances.  If the comparison is useless, I'd expect the compiler to just
discard it - for such cases your patch is pointless.

If I have, for example:

unsigned x;

if (x == 0 || x > 27)
give_a_range_error();

I will write this as:

unsigned x;

if (x <= 0 || x > 27)
give_a_range_error();

because it that gives a way to handle x being changed to signed at some point
in the future for no cost.  In which case, your changing the <= to an ==
"because the < part of the case is useless" is arguably wrong.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] [media] tvp5150: add support for asynchronous probing

2015-09-21 Thread Javier Martinez Canillas
Allow the subdevice to be probed asynchronously.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/media/i2c/tvp5150.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 522a865c5c60..3c5fb2509c47 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1172,8 +1173,7 @@ static int tvp5150_probe(struct i2c_client *c,
sd->ctrl_handler = >hdl;
if (core->hdl.error) {
res = core->hdl.error;
-   v4l2_ctrl_handler_free(>hdl);
-   return res;
+   goto err;
}
v4l2_ctrl_handler_setup(>hdl);
 
@@ -1186,9 +1186,17 @@ static int tvp5150_probe(struct i2c_client *c,
core->rect.left = 0;
core->rect.width = TVP5150_H_MAX;
 
+   res = v4l2_async_register_subdev(sd);
+   if (res < 0)
+   goto err;
+
if (debug > 1)
tvp5150_log_status(sd);
return 0;
+
+err:
+   v4l2_ctrl_handler_free(>hdl);
+   return res;
 }
 
 static int tvp5150_remove(struct i2c_client *c)
@@ -1200,7 +1208,7 @@ static int tvp5150_remove(struct i2c_client *c)
"tvp5150.c: removing tvp5150 adapter on address 0x%x\n",
c->addr << 1);
 
-   v4l2_device_unregister_subdev(sd);
+   v4l2_async_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
return 0;
 }
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device

2015-09-21 Thread Hans Verkuil
Hi Tiffany!

On 21-09-15 14:26, Tiffany Lin wrote:
> vb2_dc_prepare use the number of SG entries dma_map_sg_attrs return.
> But in dma_sync_sg_for_device, it use lengths of each SG entries
> before dma_map_sg_attrs. dma_map_sg_attrs will concatenate
> SGs until dma length > dma seg bundary. sgt->nents will less than
> sgt->orig_nents. Using SG entries after dma_map_sg_attrs
> in vb2_dc_prepare will make some SGs are not sync to device.
> After add DMA_ATTR_SKIP_CPU_SYNC in vb2_dc_get_userptr to remove
> sync data to device twice. Device randomly get incorrect data because
> some SGs are not sync to device. Change to use number of SG entries
> before dma_map_sg_attrs in vb2_dc_prepare to prevent this issue.
> 
> Signed-off-by: Tiffany Lin 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 2397ceb..c5d00bd 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -100,7 +100,7 @@ static void vb2_dc_prepare(void *buf_priv)
>   if (!sgt || buf->db_attach)
>   return;
>  
> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
> + dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, 
> buf->dma_dir);
>  }
>  
>  static void vb2_dc_finish(void *buf_priv)
> @@ -112,7 +112,7 @@ static void vb2_dc_finish(void *buf_priv)
>   if (!sgt || buf->db_attach)
>   return;
>  
> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
> + dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
>  }

I don't really understand it. I am assuming that this happens on an arm and that
the dma_map_sg_attrs and dma_sync_sg_* functions used are arm_iommu_map_sg() and
arm_iommu_sync_sg_* as implemented in arch/arm/mm/dma-mapping.c.

Now, as I understand it (and my understanding may very well be flawed!) the 
map_sg
function concatenates SG entries if possible, so it may return fewer entries. 
But
the dma_sync_sg functions use those updated SG entries, so the full buffer 
should
be covered by this. Using orig_nents will actually sync parts of the buffer 
twice!
The first nents entries already cover the full buffer so any remaining entries 
up
to orig_nents will just duplicate parts of the buffer.

So this patch makes no sense in the current code.

If I understand your log text correctly this patch goes on top of Sakari Ailus' 
vb2
sync patch series. So if it wasn't needed before, but it is needed after his 
patch
series, then the problem is in that patch series.

In any case, I need some help understanding this patch.

And *if* this patch is correct, then the same thing should likely be done for
videobuf2-dma-sg.c.

Regards,

Hans

>  
>  /*/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


cron job: media_tree daily build: OK

2015-09-21 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Sep 22 04:00:16 CEST 2015
git branch: test
git hash:   9ddf9071ea17b83954358b2dac42b34e5857a9af
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:4.0.0-3.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: 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.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-rc1-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/5] media: atmel-isi: prepare for the support of preview path

2015-09-21 Thread Josh Wu
Atmel ISI support a preview path which can output RGB data.

So this patch introduces a bool variable to choose which path is
enabled currently. And also we need setup corresponding path registers.

By default the preview path is disabled. We only use Codec path.

Signed-off-by: Josh Wu 
---

 drivers/media/platform/soc_camera/atmel-isi.c | 72 ++-
 1 file changed, 49 insertions(+), 23 deletions(-)

diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index df64294..e6f4ade 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -79,6 +79,7 @@ struct atmel_isi {
dma_addr_t  fb_descriptors_phys;
struct  list_head dma_desc_head;
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
+   boolenable_preview_path;
 
struct completion   complete;
/* ISI peripherial clock */
@@ -199,11 +200,19 @@ static irqreturn_t atmel_isi_handle_streaming(struct 
atmel_isi *isi)
/* start next dma frame. */
isi->active = list_entry(isi->video_buffer_list.next,
struct frame_buffer, list);
-   isi_writel(isi, ISI_DMA_C_DSCR,
-   (u32)isi->active->p_dma_desc->fbd_phys);
-   isi_writel(isi, ISI_DMA_C_CTRL,
-   ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
-   isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+   if (!isi->enable_preview_path) {
+   isi_writel(isi, ISI_DMA_C_DSCR,
+   (u32)isi->active->p_dma_desc->fbd_phys);
+   isi_writel(isi, ISI_DMA_C_CTRL,
+   ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+   isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+   } else {
+   isi_writel(isi, ISI_DMA_P_DSCR,
+   (u32)isi->active->p_dma_desc->fbd_phys);
+   isi_writel(isi, ISI_DMA_P_CTRL,
+   ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+   isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_P_CH);
+   }
}
return IRQ_HANDLED;
 }
@@ -230,7 +239,8 @@ static irqreturn_t isi_interrupt(int irq, void *dev_id)
isi_writel(isi, ISI_INTDIS, ISI_CTRL_DIS);
ret = IRQ_HANDLED;
} else {
-   if (likely(pending & ISI_SR_CXFR_DONE))
+   if (likely(pending & ISI_SR_CXFR_DONE) ||
+   likely(pending & ISI_SR_PXFR_DONE))
ret = atmel_isi_handle_streaming(isi);
}
 
@@ -372,21 +382,35 @@ static void start_dma(struct atmel_isi *isi, struct 
frame_buffer *buffer)
ISI_SR_CXFR_DONE | ISI_SR_PXFR_DONE);
 
/* Check if already in a frame */
-   if (isi_readl(isi, ISI_STATUS) & ISI_CTRL_CDC) {
-   dev_err(isi->soc_host.icd->parent, "Already in frame 
handling.\n");
-   return;
-   }
+   if (!isi->enable_preview_path) {
+   if (isi_readl(isi, ISI_STATUS) & ISI_CTRL_CDC) {
+   dev_err(isi->soc_host.icd->parent, "Already in frame 
handling.\n");
+   return;
+   }
 
-   isi_writel(isi, ISI_DMA_C_DSCR, (u32)buffer->p_dma_desc->fbd_phys);
-   isi_writel(isi, ISI_DMA_C_CTRL, ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
-   isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+   isi_writel(isi, ISI_DMA_C_DSCR,
+   (u32)buffer->p_dma_desc->fbd_phys);
+   isi_writel(isi, ISI_DMA_C_CTRL,
+   ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+   isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+   } else {
+   isi_writel(isi, ISI_DMA_P_DSCR,
+   (u32)buffer->p_dma_desc->fbd_phys);
+   isi_writel(isi, ISI_DMA_P_CTRL,
+   ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+   isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_P_CH);
+   }
 
cfg1 &= ~ISI_CFG1_FRATE_DIV_MASK;
/* Enable linked list */
cfg1 |= isi->pdata.frate | ISI_CFG1_DISCR;
 
-   /* Enable codec path and ISI */
-   ctrl = ISI_CTRL_CDC | ISI_CTRL_EN;
+   /* Enable ISI */
+   ctrl = ISI_CTRL_EN;
+
+   if (!isi->enable_preview_path)
+   ctrl |= ISI_CTRL_CDC;
+
isi_writel(isi, ISI_CTRL, ctrl);
isi_writel(isi, ISI_CFG1, cfg1);
 }
@@ -462,15 +486,17 @@ static void stop_streaming(struct vb2_queue *vq)
}
spin_unlock_irq(>lock);
 
-   timeout = jiffies + FRAME_INTERVAL_MILLI_SEC * HZ;
-   /* Wait until the end of the 

[PATCH 15/17] ir-hix5hd2: drop the use of IRQF_NO_SUSPEND

2015-09-21 Thread Sudeep Holla
This driver doesn't claim the IR transmitter to be wakeup source. It
even disables the clock and the IR during suspend-resume cycle.

This patch removes yet another misuse of IRQF_NO_SUSPEND.

Cc: Mauro Carvalho Chehab 
Cc: Zhangfei Gao 
Cc: Patrice Chotard 
Cc: Fabio Estevam 
Cc: Guoxiong Yan 
Cc: linux-media@vger.kernel.org
Signed-off-by: Sudeep Holla 
---
 drivers/media/rc/ir-hix5hd2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index 1c087cb76815..d0549fba711c 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -257,7 +257,7 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
goto clkerr;
 
if (devm_request_irq(dev, priv->irq, hix5hd2_ir_rx_interrupt,
-IRQF_NO_SUSPEND, pdev->name, priv) < 0) {
+0, pdev->name, priv) < 0) {
dev_err(dev, "IRQ %d register failed\n", priv->irq);
ret = -EINVAL;
goto regerr;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 14/17] media: st-rc: remove misuse of IRQF_NO_SUSPEND flag

2015-09-21 Thread Sudeep Holla
The device is set as wakeup capable using proper wakeup API but the
driver misuses IRQF_NO_SUSPEND to set the interrupt as wakeup source
which is incorrect.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
enable_irq_wake instead.

Cc: Srinivas Kandagatla 
Cc: Maxime Coquelin 
Cc: Patrice Chotard 
Cc: Mauro Carvalho Chehab 
Cc: linux-arm-ker...@lists.infradead.org
Cc: ker...@stlinux.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Sudeep Holla 
---
 drivers/media/rc/st_rc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 37d040158dff..1fa0c9d1c508 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct st_rc_device {
struct device   *dev;
@@ -190,6 +191,9 @@ static void st_rc_hardware_init(struct st_rc_device *dev)
 static int st_rc_remove(struct platform_device *pdev)
 {
struct st_rc_device *rc_dev = platform_get_drvdata(pdev);
+
+   dev_pm_clear_wake_irq(>dev);
+   device_init_wakeup(>dev, false);
clk_disable_unprepare(rc_dev->sys_clock);
rc_unregister_device(rc_dev->rdev);
return 0;
@@ -298,22 +302,22 @@ static int st_rc_probe(struct platform_device *pdev)
rdev->map_name = RC_MAP_LIRC;
rdev->input_name = "ST Remote Control Receiver";
 
-   /* enable wake via this device */
-   device_set_wakeup_capable(dev, true);
-   device_set_wakeup_enable(dev, true);
-
ret = rc_register_device(rdev);
if (ret < 0)
goto clkerr;
 
rc_dev->rdev = rdev;
if (devm_request_irq(dev, rc_dev->irq, st_rc_rx_interrupt,
-   IRQF_NO_SUSPEND, IR_ST_NAME, rc_dev) < 0) {
+0, IR_ST_NAME, rc_dev) < 0) {
dev_err(dev, "IRQ %d register failed\n", rc_dev->irq);
ret = -EINVAL;
goto rcerr;
}
 
+   /* enable wake via this device */
+   device_init_wakeup(dev, true);
+   dev_pm_set_wake_irq(dev, rc_dev->irq);
+
/**
 * for LIRC_MODE_MODE2 or LIRC_MODE_PULSE or LIRC_MODE_RAW
 * lircd expects a long space first before a signal train to sync.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] [media] cx25821, cx88, tm6000: use SNDRV_DEFAULT_ENABLE_PNP

2015-09-21 Thread Luis de Bethencourt
Instead of manually initializing the bool array enable, use the
SNDRV_DEFAULT_ENABLE_PNP macro. As most drivers do.

Signed-off-by: Luis de Bethencourt 
---

Hi,

I don't see any good reason to use = 1 instead of = SNDRV_DEFAULT_ENABLE_PNP.
Semantically it is the same, and I don't find a purpose to explicitely set the
first element of the array separately.

The proposed patch makes these drivers consistent with the rest and more
readable. In a related note, maybe the dummy driver in sound/drivers/dummy.c
should be updated as well.

I can split this below fix into a patch per driver if that's better.

Thanks,
Luis

 drivers/media/pci/cx25821/cx25821-alsa.c | 2 +-
 drivers/media/pci/cx88/cx88-alsa.c   | 2 +-
 drivers/media/usb/tm6000/tm6000-alsa.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c 
b/drivers/media/pci/cx25821/cx25821-alsa.c
index 24f964b..b602eba 100644
--- a/drivers/media/pci/cx25821/cx25821-alsa.c
+++ b/drivers/media/pci/cx25821/cx25821-alsa.c
@@ -102,7 +102,7 @@ struct cx25821_audio_dev {
 
 static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */
 static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;  /* ID for this card */
-static bool enable[SNDRV_CARDS] = { 1, [1 ... (SNDRV_CARDS - 1)] = 1 };
+static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
 
 module_param_array(enable, bool, NULL, 0444);
 MODULE_PARM_DESC(enable, "Enable cx25821 soundcard. default enabled.");
diff --git a/drivers/media/pci/cx88/cx88-alsa.c 
b/drivers/media/pci/cx88/cx88-alsa.c
index 7f8dc60..57ddf8a 100644
--- a/drivers/media/pci/cx88/cx88-alsa.c
+++ b/drivers/media/pci/cx88/cx88-alsa.c
@@ -101,7 +101,7 @@ typedef struct cx88_audio_dev snd_cx88_card_t;
 
 static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */
 static const char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;/* ID for this 
card */
-static bool enable[SNDRV_CARDS] = {1, [1 ... (SNDRV_CARDS - 1)] = 1};
+static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
 
 module_param_array(enable, bool, NULL, 0444);
 MODULE_PARM_DESC(enable, "Enable cx88x soundcard. default enabled.");
diff --git a/drivers/media/usb/tm6000/tm6000-alsa.c 
b/drivers/media/usb/tm6000/tm6000-alsa.c
index 74e5697..e21c7aa 100644
--- a/drivers/media/usb/tm6000/tm6000-alsa.c
+++ b/drivers/media/usb/tm6000/tm6000-alsa.c
@@ -42,7 +42,7 @@
 
 static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */
 
-static bool enable[SNDRV_CARDS] = {1, [1 ... (SNDRV_CARDS - 1)] = 1};
+static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
 
 module_param_array(enable, bool, NULL, 0444);
 MODULE_PARM_DESC(enable, "Enable tm6000x soundcard. default enabled.");
-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Patch v2] media: v4l2-ctrls: Fix 64bit support in get_ctrl()

2015-09-21 Thread Benoit Parrot
When trying to use v4l2_ctrl_g_ctrl_int64() to retrieve a
V4L2_CTRL_TYPE_INTEGER64 type value the internal helper function
get_ctrl() would prematurely exits because for this control type
the 'is_int' flag is not set. This would result in v4l2_ctrl_g_ctrl_int64
always returning 0.
Also v4l2_ctrl_g_ctrl_int64() is reading and returning the 32bit value
member instead of the 64bit version, so fixing that as well.

This patch extend the condition check to allow V4L2_CTRL_TYPE_INTEGER64
type to continue processing instead of exiting.

Signed-off-by: Benoit Parrot 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6b7dcc1b77d..6f1a8a6cc149 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2884,7 +2884,7 @@ static int get_ctrl(struct v4l2_ctrl *ctrl, struct 
v4l2_ext_control *c)
 * cur_to_user() calls below would need to be modified not to access
 * userspace memory when called from get_ctrl().
 */
-   if (!ctrl->is_int)
+   if (!ctrl->is_int && ctrl->type != V4L2_CTRL_TYPE_INTEGER64)
return -EINVAL;
 
if (ctrl->flags & V4L2_CTRL_FLAG_WRITE_ONLY)
@@ -2942,9 +2942,9 @@ s64 v4l2_ctrl_g_ctrl_int64(struct v4l2_ctrl *ctrl)
 
/* It's a driver bug if this happens. */
WARN_ON(ctrl->is_ptr || ctrl->type != V4L2_CTRL_TYPE_INTEGER64);
-   c.value = 0;
+   c.value64 = 0;
get_ctrl(ctrl, );
-   return c.value;
+   return c.value64;
 }
 EXPORT_SYMBOL(v4l2_ctrl_g_ctrl_int64);
 
-- 
1.8.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RFC: ov5640 kernel driver.

2015-09-21 Thread Javier Martin

Hi,
we want to a v4l2 driver for the ov5640 sensor from Omnivision.

AFAIK, there was an attempt in the past to mainline that driver [1] but 
it didn't make it in the end.


Some people were asking for the code for the ov5640 and the ov5642 to be 
merged [2] as well but IMHO both sensors are not that similar so that 
it's worth a common driver.


The approach we had in mind so far was creating a new, independent, 
v4l2-subdev driver for the ov5640 with mbus support.


I've found several sources out there with code for the ov5640 but, 
surprisingly, few attempts to mainline it. I would whether it is just 
people didn't take the effort or there was something wrong with the code.


Has anyone got some comments/advices on this before we start coding? Is 
anyone already working on this and maybe we can collaborate instead of 
having two forks of the same driver?


Regards,
Javier.

[1] https://lwn.net/Articles/470643/
[2] http://www.spinics.net/lists/linux-omap/msg69611.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] cobalt: fix Kconfig dependency

2015-09-21 Thread Hans Verkuil
The cobalt driver should depend on VIDEO_V4L2_SUBDEV_API.

This fixes this kbuild error:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   99bc7215bc60f6cd414cf1b85cd9d52cc596cccb
commit: 85756a069c55e0315ac5990806899cfb607b987f [media] cobalt: add new driver
date:   4 months ago
config: x86_64-randconfig-s0-09201514 (attached as .config)
reproduce:
  git checkout 85756a069c55e0315ac5990806899cfb607b987f
  # save the attached .config to linux build tree
  make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/media/i2c/adv7604.c: In function 'adv76xx_get_format':
>> drivers/media/i2c/adv7604.c:1853:9: error: implicit declaration of function 
>> 'v4l2_subdev_get_try_format' [-Werror=implicit-function-declaration]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
   drivers/media/i2c/adv7604.c:1853:7: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
  ^
   drivers/media/i2c/adv7604.c: In function 'adv76xx_set_format':
   drivers/media/i2c/adv7604.c:1882:7: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
  ^
   cc1: some warnings being treated as errors
--
   drivers/media/i2c/adv7842.c: In function 'adv7842_get_format':
>> drivers/media/i2c/adv7842.c:2093:9: error: implicit declaration of function 
>> 'v4l2_subdev_get_try_format' [-Werror=implicit-function-declaration]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
   drivers/media/i2c/adv7842.c:2093:7: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
  ^
   drivers/media/i2c/adv7842.c: In function 'adv7842_set_format':
   drivers/media/i2c/adv7842.c:2125:7: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
  ^
   cc1: some warnings being treated as errors
--
   drivers/media/i2c/adv7511.c: In function 'adv7511_get_fmt':
>> drivers/media/i2c/adv7511.c:859:9: error: implicit declaration of function 
>> 'v4l2_subdev_get_try_format' [-Werror=implicit-function-declaration]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
   drivers/media/i2c/adv7511.c:859:7: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
  ^
   drivers/media/i2c/adv7511.c: In function 'adv7511_set_fmt':
   drivers/media/i2c/adv7511.c:910:7: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
  fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
  ^
   cc1: some warnings being treated as errors

Signed-off-by: Hans Verkuil 
Reported by: kbuild test robot 

diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig
index 1f88ccc..a01f0cc 100644
--- a/drivers/media/pci/cobalt/Kconfig
+++ b/drivers/media/pci/cobalt/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_COBALT
tristate "Cisco Cobalt support"
-   depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
depends on PCI_MSI && MTD_COMPLEX_MAPPINGS
depends on GPIOLIB || COMPILE_TEST
depends on SND
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] v4l2-ctrls: arrays are also considered compound controls

2015-09-21 Thread Hans Verkuil
From: Hans Verkuil 

Array controls weren't skipped when only V4L2_CTRL_FLAG_NEXT_CTRL was
provided (so no V4L2_CTRL_FLAG_NEXT_COMPOUND was set). This is wrong
since arrays are also considered compound controls (i.e. with more than
one value), and applications that do not know about arrays will not
be able to handle such controls.

Fix the test to include arrays.

Signed-off-by: Hans Verkuil 
Reported-by: Ricardo Ribalda Delgado 
Cc:   # for v3.17 and up
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6b7dcc..d5de70e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2498,7 +2498,7 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl, 
struct v4l2_query_ext_ctr
/* We found a control with the given ID, so just get
   the next valid one in the list. */
list_for_each_entry_continue(ref, >ctrl_refs, 
node) {
-   is_compound =
+   is_compound = ref->ctrl->is_array ||
ref->ctrl->type >= 
V4L2_CTRL_COMPOUND_TYPES;
if (id < ref->ctrl->id &&
(is_compound & mask) == match)
@@ -2512,7 +2512,7 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl, 
struct v4l2_query_ext_ctr
   is one, otherwise the first 'if' above would have
   been true. */
list_for_each_entry(ref, >ctrl_refs, node) {
-   is_compound =
+   is_compound = ref->ctrl->is_array ||
ref->ctrl->type >= 
V4L2_CTRL_COMPOUND_TYPES;
if (id < ref->ctrl->id &&
(is_compound & mask) == match)
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] DocBook/media: clarify control documentation

2015-09-21 Thread Hans Verkuil
From: Hans Verkuil 

- Add missing V4L2_CTRL_TYPE_U32 documentation
- Remove 'which are actually different on the hardware' sentence which
  is confusing. I think the idea was to let the user know that the step can
  be different for different hardware, but that's obvious because otherwise
  you wouldn't need to specify the step value.
- Clarify that V4L2_CTRL_COMPOUND_TYPES also applies to arrays.

Signed-off-by: Hans Verkuil 
---
 .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml|  7 +++
 .../DocBook/media/v4l/vidioc-queryctrl.xml  | 21 -
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml 
b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
index c5bdbfc..842536a 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
@@ -200,6 +200,13 @@ Valid if this control is of type 
V4L2_CTRL_TYPE_U16.
  

+   __u32 *
+   p_u32
+   A pointer to a matrix control of unsigned 32-bit values.
+Valid if this control is of type 
V4L2_CTRL_TYPE_U32.
+ 
+ 
+   
void *
ptr
A pointer to a compound type which can be an N-dimensional 
array and/or a
diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml 
b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
index 6ec39c6..55b7582 100644
--- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
@@ -101,8 +101,9 @@ prematurely end the enumeration).
 next supported non-compound control, or EINVAL
 if there is none. In addition, the 
V4L2_CTRL_FLAG_NEXT_COMPOUND
 flag can be specified to enumerate all compound controls (i.e. controls
-with type  V4L2_CTRL_COMPOUND_TYPES). Specify both
-V4L2_CTRL_FLAG_NEXT_CTRL and
+with type  V4L2_CTRL_COMPOUND_TYPES and/or array
+control, in other words controls that contain more than one value).
+Specify both V4L2_CTRL_FLAG_NEXT_CTRL and
 V4L2_CTRL_FLAG_NEXT_COMPOUND in order to enumerate
 all controls, compound or not. Drivers which do not support these flags yet
 always return EINVAL.
@@ -422,7 +423,7 @@ the array to zero.
any
An integer-valued control ranging from minimum to
 maximum inclusive. The step value indicates the increment between
-values which are actually different on the hardware.
+values.
  
  
V4L2_CTRL_TYPE_BOOLEAN
@@ -518,7 +519,7 @@ Older drivers which do not support this feature return an
any
An unsigned 8-bit valued control ranging from minimum to
 maximum inclusive. The step value indicates the increment between
-values which are actually different on the hardware.
+values.
 
  
  
@@ -528,7 +529,17 @@ values which are actually different on the hardware.
any
An unsigned 16-bit valued control ranging from minimum to
 maximum inclusive. The step value indicates the increment between
-values which are actually different on the hardware.
+values.
+
+ 
+ 
+   V4L2_CTRL_TYPE_U32
+   any
+   any
+   any
+   An unsigned 32-bit valued control ranging from minimum to
+maximum inclusive. The step value indicates the increment between
+values.
 
  

-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/2] v4l2-ctrls: fix NEXT_COMPOUND support

2015-09-21 Thread Hans Verkuil
This patch series is identical to the original RFC patch (see here:
https://patchwork.linuxtv.org/patch/31423/), but it is now split up in
two patches and the actual code fix now has a CC to stable to patch up
kernels 3.17 and up.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Hans Verkuil
On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> From: Marek Szyprowski 
> 
> Add Exynos 5433 jpeg h/w codec node.
> 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi

This dtsi file doesn't exist in the media-git tree. What is the story here?

Should this go through a different subsystem?

I think the media subsystem can take patches 1-3 and whoever does DT patches can
take this patch, right?

Regards,

Hans

> index 59e21b6..5cb489f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -916,6 +916,27 @@
>   io-channel-ranges;
>   status = "disabled";
>   };
> + jpeg: jpeg@1502 {
> + compatible = "samsung,exynos5433-jpeg";
> + reg = <0x1502 0x1>;
> + interrupts = <0 411 0>;
> + clock-names = "pclk",
> +   "aclk",
> +   "aclk_xiu",
> +   "sclk";
> + clocks = <_mscl CLK_PCLK_JPEG>,
> +  <_mscl CLK_ACLK_JPEG>,
> +  <_mscl CLK_ACLK_XIU_MSCLX>,
> +  <_mscl CLK_SCLK_JPEG>;
> + assigned-clocks = <_mscl 
> CLK_MOUT_ACLK_MSCL_400_USER>,
> +   <_mscl CLK_MOUT_SCLK_JPEG_USER>,
> +   <_mscl CLK_MOUT_SCLK_JPEG>,
> +   <_top CLK_MOUT_SCLK_JPEG_A>;
> + assigned-clock-parents = <_top CLK_ACLK_MSCL_400>,
> +  <_top CLK_SCLK_JPEG_MSCL>,
> +  <_mscl 
> CLK_MOUT_SCLK_JPEG_USER>,
> +  <_top 
> CLK_MOUT_BUS_PLL_USER>;
> + };
>   };
>  
>   timer {
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Andrzej Pietrasiewicz

Hi Hans,

W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:

On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:

From: Marek Szyprowski 

Add Exynos 5433 jpeg h/w codec node.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Andrzej Pietrasiewicz 
---
  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
  1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi


This dtsi file doesn't exist in the media-git tree. What is the story here?

Should this go through a different subsystem?

I think the media subsystem can take patches 1-3 and whoever does DT patches can
take this patch, right?



The cover letter explains that the series is rebased onto Mauro's
master with Kukjin's branch merged. The latter does contain
the exynos5433.dtsi. That said, yes, taking patches 1-3 in
media subsystem and leaving DT patch to someone else is the
way to go.

Andrzej
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL FOR v4.4] Fixes, enhancements, etc.

2015-09-21 Thread Hans Verkuil
This pull request is a pile of fixes and enhancements.

The main changes are a new colorspace and a new transfer function and a cleaned
up saa7164 (now passes v4l2-compliance).

Arnd also did some preparation to simplify future y2038 work.

Regards,

Hans

The following changes since commit 9ddf9071ea17b83954358b2dac42b34e5857a9af:

  Merge tag 'v4.3-rc1' into patchwork (2015-09-13 11:10:12 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.4b

for you to fetch changes up to d8af0338c98cd184eb8753fb1ba4291756ba30d6:

  go7007: Fix returned errno code in gen_mjpeghdr_to_package() (2015-09-21 
11:50:40 +0200)


Arnd Bergmann (2):
  exynos4-is: use monotonic timestamps as advertized
  use v4l2_get_timestamp where possible

Geliang Tang (1):
  media: fix kernel-doc warnings in v4l2-dv-timings.h

Hans Verkuil (24):
  v4l2-compat-ioctl32: replace pr_warn by pr_debug
  vivid: use ARRAY_SIZE to calculate max control value
  vivid: use Bradford method when converting Rec. 709 to NTSC 1953
  videodev2.h: add support for the DCI-P3 colorspace
  DocBook media: document the new DCI-P3 colorspace
  vivid-tpg: support the DCI-P3 colorspace
  vivid: add support for the DCI-P3 colorspace
  videodev2.h: add SMPTE 2084 transfer function define
  vivid-tpg: add support for SMPTE 2084 transfer function
  vivid: add support for SMPTE 2084 transfer function
  DocBook media: Document the SMPTE 2084 transfer function
  vim2m: small cleanup: use assignment instead of memcpy
  v4l2-compat-ioctl32: add missing SDR support
  vivid: add 10 and 12 bit Bayer formats
  saa7164: convert to the control framework
  saa7164: add v4l2_fh support
  saa7164: fix poll bugs
  saa7164: add support for control events
  saa7164: fix format ioctls
  saa7164: remove unused videobuf references
  saa7164: fix input and tuner compliance problems
  saa7164: video and vbi ports share the same input/tuner/std
  v4l2-ctrls: arrays are also considered compound controls
  DocBook/media: clarify control documentation

Javier Martinez Canillas (2):
  s5c73m3: Export OF module alias information
  go7007: Fix returned errno code in gen_mjpeghdr_to_package()

Ricardo Ribalda Delgado (2):
  videodev2.h: Fix typo in comment
  media/v4l2-compat-ioctl32: Simple stylechecks

Sergei Shtylyov (1):
  ml86v7667: implement g_std() method

 Documentation/DocBook/media/v4l/biblio.xml |  18 +++
 Documentation/DocBook/media/v4l/pixfmt.xml | 109 +
 Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml |   7 +
 Documentation/DocBook/media/v4l/vidioc-queryctrl.xml   |  21 ++-
 drivers/media/i2c/ml86v7667.c  |  10 ++
 drivers/media/i2c/s5c73m3/s5c73m3-spi.c|   1 +
 drivers/media/pci/bt8xx/bttv-driver.c  |   5 +-
 drivers/media/pci/cx18/cx18-mailbox.c  |   2 +-
 drivers/media/pci/saa7164/Kconfig  |   1 -
 drivers/media/pci/saa7164/saa7164-encoder.c| 653 
+
 drivers/media/pci/saa7164/saa7164-vbi.c| 629 
+++---
 drivers/media/pci/saa7164/saa7164.h|  26 +++-
 drivers/media/platform/exynos4-is/fimc-capture.c   |   8 +-
 drivers/media/platform/exynos4-is/fimc-lite.c  |   7 +-
 drivers/media/platform/omap3isp/ispstat.c  |   5 +-
 drivers/media/platform/omap3isp/ispstat.h  |   2 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |   8 +-
 drivers/media/platform/vim2m.c |   7 +-
 drivers/media/platform/vivid/vivid-core.h  |   1 +
 drivers/media/platform/vivid/vivid-ctrls.c |  18 ++-
 drivers/media/platform/vivid/vivid-tpg-colors.c| 328 
+--
 drivers/media/platform/vivid/vivid-tpg-colors.h|   4 +-
 drivers/media/platform/vivid/vivid-tpg.c   |  91 +++
 drivers/media/platform/vivid/vivid-vid-common.c|  56 +++
 drivers/media/usb/go7007/go7007-fw.c   |   6 +-
 drivers/media/usb/gspca/gspca.c|   4 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c  |  40 +++--
 drivers/media/v4l2-core/v4l2-ctrls.c   |   4 +-
 drivers/staging/media/omap4iss/iss_video.c |   5 +-
 include/media/v4l2-dv-timings.h|  32 ++--
 include/uapi/linux/videodev2.h |  21 ++-
 31 files changed, 899 insertions(+), 1230 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info 

Re: RFC: ov5640 kernel driver.

2015-09-21 Thread Guennadi Liakhovetski
Hi Javier,

On Mon, 21 Sep 2015, Javier Martin wrote:

> Hi,
> we want to a v4l2 driver for the ov5640 sensor from Omnivision.
> 
> AFAIK, there was an attempt in the past to mainline that driver [1] but it
> didn't make it in the end.
> 
> Some people were asking for the code for the ov5640 and the ov5642 to be
> merged [2] as well but IMHO both sensors are not that similar so that it's
> worth a common driver.
> 
> The approach we had in mind so far was creating a new, independent,
> v4l2-subdev driver for the ov5640 with mbus support.
> 
> I've found several sources out there with code for the ov5640 but,
> surprisingly, few attempts to mainline it. I would whether it is just people
> didn't take the effort or there was something wrong with the code.
> 
> Has anyone got some comments/advices on this before we start coding?

AFAICS there are often multiple versions of drivers for various devices in 
multiple github and other repositories. Many of them never even get 
announced to respective mainline-oriented mailing lists, some do get 
submitted once, but as you say - don't make the effort to finalise the 
process. So, I would say, if you can find a driver, that works for you, 
has a suitable licence and code quality, you can submit it to the 
mainline, preserving the author or at least giving them sufficient credit 
if you heavily modify it. I would also at least inform the author(s) and 
ask them if they want to submit the driver themselves.

Others might add more:)

Thanks
Guennadi

> Is anyone
> already working on this and maybe we can collaborate instead of having two
> forks of the same driver?
> 
> Regards,
> Javier.
> 
> [1] https://lwn.net/Articles/470643/
> [2] http://www.spinics.net/lists/linux-omap/msg69611.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


3.5%loan offer

2015-09-21 Thread wonga loans
 

3.5% WONGA.pdf
Description: Adobe PDF document


[PATCH 25/38] staging: media: davinci_vpfe: fix ipipe_mode type

2015-09-21 Thread Andrzej Hajda
The variable can take negative values.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
index 2a3a56b..b1d5e23 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
@@ -254,7 +254,7 @@ int config_ipipe_hw(struct vpfe_ipipe_device *ipipe)
void __iomem *ipipe_base = ipipe->base_addr;
struct v4l2_mbus_framefmt *outformat;
u32 color_pat;
-   u32 ipipe_mode;
+   int ipipe_mode;
u32 data_path;
 
/* enable clock to IPIPE */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Patch v2 1/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

2015-09-21 Thread Benoit Parrot
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.
The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support

Signed-off-by: Benoit Parrot 
---
 drivers/media/platform/Kconfig   |   12 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/ti-vpe/Makefile   |4 +
 drivers/media/platform/ti-vpe/cal.c  | 2161 ++
 drivers/media/platform/ti-vpe/cal_regs.h |  779 +++
 5 files changed, 2958 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/cal.c
 create mode 100644 drivers/media/platform/ti-vpe/cal_regs.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index dc75694ac12d..c7f5704c56a2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,18 @@ source "drivers/media/platform/s5p-tv/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 
+config VIDEO_TI_CAL
+   tristate "TI CAL (Camera Adaptation Layer) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && SOC_DRA7XX
+   depends on VIDEO_V4L2_SUBDEV_API
+   depends on VIDEOBUF2_DMA_CONTIG
+   default n
+   ---help---
+ Support for the TI CAL (Camera Adaptation Layer) block
+ found on DRA72X SoC.
+ In TI Technical Reference Manual this module is referred as
+ Camera Interface Subsystem (CAMSS).
+
 endif # V4L_PLATFORM_DRIVERS
 
 menuconfig V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295af87b..028a7233096b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -18,6 +18,8 @@ obj-$(CONFIG_VIDEO_VIM2M) += vim2m.o
 
 obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
 
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-vpe/
+
 obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
 obj-$(CONFIG_VIDEO_CODA)   += coda/
 
diff --git a/drivers/media/platform/ti-vpe/Makefile 
b/drivers/media/platform/ti-vpe/Makefile
index be680f839e77..e236059a60ad 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti-vpe/Makefile
@@ -3,3 +3,7 @@ obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
 ti-vpe-y := vpe.o sc.o csc.o vpdma.o
 
 ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
+
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-cal.o
+
+ti-cal-y := cal.o
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
new file mode 100644
index ..25167566be91
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -0,0 +1,2161 @@
+/*
+ * TI CAL camera interface driver
+ *
+ * Copyright (c) 2015 Texas Instruments Inc.
+ * Benoit Parrot, 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cal_regs.h"
+
+#define CAL_MODULE_NAME "cal"
+
+#define MAX_WIDTH 1920
+#define MAX_HEIGHT 1200
+
+#define CAL_VERSION "0.1.0"
+
+MODULE_DESCRIPTION("TI CAL driver");
+MODULE_AUTHOR("Benoit Parrot, ");
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(CAL_VERSION);
+
+static unsigned video_nr = -1;
+module_param(video_nr, uint, 0644);
+MODULE_PARM_DESC(video_nr, "videoX start number, -1 is autodetect");
+
+static unsigned debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "activates debug info");
+
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+   tpf_default = {.numerator = 1001,   .denominator = 3};
+
+#define cal_dbg(level, caldev, fmt, arg...)\
+   v4l2_dbg(level, debug, >v4l2_dev, fmt, ##arg)
+#define cal_info(caldev, fmt, arg...)  \
+   v4l2_info(>v4l2_dev, fmt, ##arg)
+#define cal_err(caldev, fmt, arg...)   \
+   v4l2_err(>v4l2_dev, fmt, ##arg)
+
+#define ctx_dbg(level, ctx, fmt, arg...)   \
+   v4l2_dbg(level, debug, >v4l2_dev, fmt, ##arg)
+#define ctx_info(ctx, fmt, arg...) \
+   v4l2_info(>v4l2_dev, fmt, ##arg)
+#define ctx_err(ctx, fmt, arg...)  \
+   v4l2_err(>v4l2_dev, fmt, ##arg)
+
+#define CAL_NUM_INPUT 1
+#define CAL_NUM_CONTEXT 2
+
+/* --
+   

[Patch v2 0/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

2015-09-21 Thread Benoit Parrot
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
This camera engine is currently found on DRA72xx family of devices.

Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.

The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support

Currently each port is designed to connect to a single sub-device.
In other words port aggregation is not currently supported.

Changes since v1:
- Remove unnecessary format description
- Reworked how transient frame format is maintained
  in order to make it easier to use the fill helper functions
- Added a per port list of active frame format
- Reworked an added missing vb2 cleanup code
- Fix a module load/unload kernel oops
- Switch to use proper int64 get function for pixel rate control

=

Here is a sample output of the v4l2-compliance tool:

# ./v4l2-compliance -f -s -v -d /dev/video0 
Driver Info:
Driver name   : cal
Card type : cal
Bus info : platform:cal-000

Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

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)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
info: checking v4l2_queryctrl of control 'User Controls' 
(0x00980001)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
info: checking v4l2_queryctrl of control 'Image Processing 
Controls' (0x009f0001)
info: checking v4l2_queryctrl of control 'Pixel Rate' 
(0x009f0902)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
info: checking control 'User Controls' (0x00980001)
info: checking control 'Horizontal Flip' (0x00980914)
info: checking control 'Vertical Flip' (0x00980915)
info: checking control 'Image Processing Controls' (0x009f0001)
info: checking control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S_CTRL: OK
info: checking extended control 'User Controls' (0x00980001)
info: checking extended control 'Horizontal Flip' (0x00980914)
info: checking extended control 'Vertical Flip' (0x00980915)
info: checking extended control 'Image Processing Controls' 
(0x009f0001)
info: checking extended control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
info: checking control event 'User Controls' (0x00980001)
info: checking control event 'Horizontal Flip' (0x00980914)
info: checking control event 'Vertical Flip' (0x00980915)
info: checking control event 'Image Processing Controls' 
(0x009f0001)
info: checking control event 'Pixel Rate' (0x009f0902)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: 

[Patch v2 2/2] media: v4l: ti-vpe: Document CAL driver

2015-09-21 Thread Benoit Parrot
Device Tree bindings for the Camera Adaptation Layer (CAL) driver

Signed-off-by: Benoit Parrot 
---
 Documentation/devicetree/bindings/media/ti-cal.txt | 70 ++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti-cal.txt

diff --git a/Documentation/devicetree/bindings/media/ti-cal.txt 
b/Documentation/devicetree/bindings/media/ti-cal.txt
new file mode 100644
index ..680efadb6208
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti-cal.txt
@@ -0,0 +1,70 @@
+Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)
+--
+
+The Camera Adaptation Layer (CAL) is a key component for image capture
+applications. The capture module provides the system interface and the
+processing capability to connect CSI2 image-sensor modules to the
+DRA72x device.
+
+Required properties:
+- compatible: must be "ti,cal"
+- reg: physical base address and length of the registers set for the 4
+   memory regions required;
+- reg-names: name associated with the memory regions described is ;
+- interrupts: should contain IRQ line for the CAL;
+
+CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
+should contain a 'port' child node with child 'endpoint' node. Please
+refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   cal: cal@4845b000 {
+   compatible = "ti,cal";
+   ti,hwmods = "cal";
+   reg = <0x4845B000 0x400>,
+ <0x4845B800 0x40>,
+ <0x4845B900 0x40>,
+ <0x4A002e94 0x4>;
+   reg-names = "cal_top",
+   "cal_rx_core0",
+   "cal_rx_core1",
+   "camerrx_control";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   csi2_0: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+   endpoint {
+   slave-mode;
+   remote-endpoint = <_1>;
+   };
+   };
+   csi2_1: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+
+   i2c5: i2c@4807c000 {
+   ar0330@10 {
+   compatible = "ti,ar0330";
+   reg = <0x10>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ar0330_1: endpoint {
+   reg = <0>;
+   clock-lanes = <1>;
+   data-lanes = <0 2 3 4>;
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+   };
-- 
1.8.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/3 RFC v3] media: platform: add NVIDIA Tegra VI driver

2015-09-21 Thread Bryan Wu
This patchset add and enable V4L2 driver for latest NVIDIA Tegra
Video Input hardware controller.

It's based on the staging/work branch of Thierry Reding Tegra
upstream kernel github repo, which is based on 4.2-rc1.
(https://github.com/thierryreding/linux/tree/staging/work) 

v3:
  - rework on the locking code related to kthread
  - remove some dead code
  - other fixes

v2:
  - allocate kthread for each channel instead of workqueue
  - create tegra-csi as a separated V4L2 subdevice
  - define all the register bits needed in this driver
  - add device tree binding document
  - update things according to Hans and Thierry's review.

Bryan Wu (3):
  [media] v4l: tegra: Add NVIDIA Tegra VI driver
  ARM64: add tegra-vi support in T210 device-tree
  Documentation: DT bindings: add VI and CSI bindings

 .../bindings/gpu/nvidia,tegra20-host1x.txt | 211 +-
 arch/arm64/boot/dts/nvidia/tegra210-p2571-e01.dts  |   8 +
 arch/arm64/boot/dts/nvidia/tegra210.dtsi   | 174 -
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/tegra/Kconfig   |  10 +
 drivers/media/platform/tegra/Makefile  |   3 +
 drivers/media/platform/tegra/tegra-channel.c   | 802 +
 drivers/media/platform/tegra/tegra-core.c  | 252 +++
 drivers/media/platform/tegra/tegra-core.h  | 162 +
 drivers/media/platform/tegra/tegra-csi.c   | 566 +++
 drivers/media/platform/tegra/tegra-vi.c| 581 +++
 drivers/media/platform/tegra/tegra-vi.h| 213 ++
 13 files changed, 2978 insertions(+), 7 deletions(-)
 create mode 100644 drivers/media/platform/tegra/Kconfig
 create mode 100644 drivers/media/platform/tegra/Makefile
 create mode 100644 drivers/media/platform/tegra/tegra-channel.c
 create mode 100644 drivers/media/platform/tegra/tegra-core.c
 create mode 100644 drivers/media/platform/tegra/tegra-core.h
 create mode 100644 drivers/media/platform/tegra/tegra-csi.c
 create mode 100644 drivers/media/platform/tegra/tegra-vi.c
 create mode 100644 drivers/media/platform/tegra/tegra-vi.h

-- 
2.1.4


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/3] ARM64: add tegra-vi support in T210 device-tree

2015-09-21 Thread Bryan Wu
Following device tree support for Tegra VI now:
 - "vi" node which might have 6 ports/endpoints
 - in TPG mode, "vi" node don't need to define any ports/endpoints
 - ports/endpoints defines the link between VI and external sensors.

Signed-off-by: Bryan Wu 
---
 arch/arm64/boot/dts/nvidia/tegra210-p2571-e01.dts |   8 +
 arch/arm64/boot/dts/nvidia/tegra210.dtsi  | 174 +-
 2 files changed, 181 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2571-e01.dts 
b/arch/arm64/boot/dts/nvidia/tegra210-p2571-e01.dts
index d4ee460..534ada52 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2571-e01.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2571-e01.dts
@@ -7,6 +7,14 @@
model = "NVIDIA Tegra210 P2571 reference board (E.1)";
compatible = "nvidia,p2571-e01", "nvidia,tegra210";
 
+   host1x@0,5000 {
+   vi@0,5408 {
+   status = "okay";
+
+   avdd-dsi-csi-supply = <_dsi_csi>;
+   };
+   };
+
pinmux: pinmux@0,78d4 {
pinctrl-names = "boot";
pinctrl-0 = <_boot>;
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 1168bcd..3f6501f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -109,9 +109,181 @@
 
vi@0,5408 {
compatible = "nvidia,tegra210-vi";
-   reg = <0x0 0x5408 0x0 0x0004>;
+   reg = <0x0 0x5408 0x0 0x800>;
interrupts = ;
status = "disabled";
+   clocks = <_car TEGRA210_CLK_VI>,
+<_car TEGRA210_CLK_CSI>,
+<_car TEGRA210_CLK_PLL_C>;
+   clock-names = "vi", "csi", "parent";
+   resets = <_car 20>;
+   reset-names = "vi";
+
+   power-domains = < TEGRA_POWERGATE_VENC>;
+
+   iommus = < TEGRA_SWGROUP_VI>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   vi_in0: endpoint {
+   remote-endpoint = <_out0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+
+   vi_in1: endpoint {
+   remote-endpoint = <_out1>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+
+   vi_in2: endpoint {
+   remote-endpoint = <_out2>;
+   };
+   };
+   port@3 {
+   reg = <3>;
+
+   vi_in3: endpoint {
+   remote-endpoint = <_out3>;
+   };
+   };
+   port@4 {
+   reg = <4>;
+
+   vi_in4: endpoint {
+   remote-endpoint = <_out4>;
+   };
+   };
+   port@5 {
+   reg = <5>;
+
+   vi_in5: endpoint {
+   remote-endpoint = <_out5>;
+   };
+   };
+
+   };
+   };
+
+   csi@0,54080838 {
+   compatible = "nvidia,tegra210-csi";
+   reg = <0x0 0x54080838 0x0 0x700>;
+   clocks = <_car TEGRA210_CLK_CILAB>;
+   clock-names = "cil";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   csi_in0: endpoint@0 {
+   reg = <0x0>;
+   };
+

[PATCH 3/3] Documentation: DT bindings: add VI and CSI bindings

2015-09-21 Thread Bryan Wu
Signed-off-by: Bryan Wu 
---
 .../bindings/gpu/nvidia,tegra20-host1x.txt | 211 -
 1 file changed, 205 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
index 46d6ead..433cb52 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -40,10 +40,39 @@ of the following host1x client modules:
   - interrupts: The interrupt outputs from the controller.
   - clocks: Must contain one entry, for the module clock.
 See ../clocks/clock-bindings.txt for details.
+  - clock-names: Must include the following entries:
+- vi
+  This MUST be the first entry.
+- csi
+- parent
   - resets: Must contain an entry for each entry in reset-names.
 See ../reset/reset.txt for details.
   - reset-names: Must include the following entries:
 - vi
+  - power-domains: The power domains settings.
+See ../power/power_domain.txt
+  - iommus: The IOMMU settings.
+See ../iommu/iommu.txt
+  - ports: several VI input ports which connecting CSI ports. Ports contain
+several port and each port has one endpoint.
+See ../graph.txt and ../media/video-interfaces.txt
+  - avdd-dsi-csi-supply: a regulator required by VI.
+
+- csi: camera serial interface
+
+  Required properties:
+  - compatible: "nvidia,tegra-csi"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+  - clocks: Must contain one entry, for the module clock.
+See ../clocks/clock-bindings.txt for details.
+  - clock-names: Must include the following entries:
+- cil
+  This MUST be the first entry.
+  - ports: 2 ports presenting 2 channels of CSI. Each port has 2 endpoints:
+one connects to sensor device tree node as input and the other one connects
+to VI endpoint.
+See ../graph.txt and ../media/video-interfaces.txt
 
 - epp: encoder pre-processor
 
@@ -274,13 +303,183 @@ Example:
reset-names = "mpe";
};
 
-   vi {
-   compatible = "nvidia,tegra20-vi";
-   reg = <0x5408 0x0004>;
-   interrupts = <0 69 0x04>;
-   clocks = <_car TEGRA20_CLK_VI>;
-   resets = <_car 100>;
+   vi@0,5408 {
+   compatible = "nvidia,tegra210-vi";
+   reg = <0x0 0x5408 0x0 0x800>;
+   interrupts = ;
+   status = "disabled";
+   clocks = <_car TEGRA210_CLK_VI>,
+<_car TEGRA210_CLK_CSI>,
+<_car TEGRA210_CLK_PLL_C>;
+   clock-names = "vi", "csi", "parent";
+   resets = <_car 20>;
reset-names = "vi";
+
+   power-domains = < TEGRA_POWERGATE_VENC>;
+
+   iommus = < TEGRA_SWGROUP_VI>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   vi_in0: endpoint {
+   remote-endpoint = <_out0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+
+   vi_in1: endpoint {
+   remote-endpoint = <_out1>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+
+   vi_in2: endpoint {
+   remote-endpoint = <_out2>;
+   };
+   };
+   port@3 {
+   reg = <3>;
+
+   vi_in3: endpoint {
+   remote-endpoint = <_out3>;
+   };
+   };
+   port@4 {
+   reg = <4>;
+
+   vi_in4: endpoint {
+   remote-endpoint = <_out4>;
+   };
+   };
+   port@5 {
+   reg = <5>;
+
+   vi_in5: endpoint {

[PATCH 1/3] [media] v4l: tegra: Add NVIDIA Tegra VI driver

2015-09-21 Thread Bryan Wu
NVIDIA Tegra processor contains a powerful Video Input (VI) hardware
controller which can support up to 6 MIPI CSI camera sensors.

This patch adds a V4L2 media controller and capture driver to support
Tegra VI hardware. It's verified with Tegra built-in test pattern
generator.

Signed-off-by: Bryan Wu 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/tegra/Kconfig |  10 +
 drivers/media/platform/tegra/Makefile|   3 +
 drivers/media/platform/tegra/tegra-channel.c | 782 +++
 drivers/media/platform/tegra/tegra-core.c| 252 +
 drivers/media/platform/tegra/tegra-core.h| 162 ++
 drivers/media/platform/tegra/tegra-csi.c | 566 +++
 drivers/media/platform/tegra/tegra-vi.c  | 581 
 drivers/media/platform/tegra/tegra-vi.h  | 209 +++
 10 files changed, 2568 insertions(+)
 create mode 100644 drivers/media/platform/tegra/Kconfig
 create mode 100644 drivers/media/platform/tegra/Makefile
 create mode 100644 drivers/media/platform/tegra/tegra-channel.c
 create mode 100644 drivers/media/platform/tegra/tegra-core.c
 create mode 100644 drivers/media/platform/tegra/tegra-core.h
 create mode 100644 drivers/media/platform/tegra/tegra-csi.c
 create mode 100644 drivers/media/platform/tegra/tegra-vi.c
 create mode 100644 drivers/media/platform/tegra/tegra-vi.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f6bed19..553867f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -119,6 +119,7 @@ source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/s5p-tv/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
+source "drivers/media/platform/tegra/Kconfig"
 
 endif # V4L_PLATFORM_DRIVERS
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 114f9ab..426e0e4 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -52,4 +52,6 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)   += am437x/
 
 obj-$(CONFIG_VIDEO_XILINX) += xilinx/
 
+obj-$(CONFIG_VIDEO_TEGRA)  += tegra/
+
 ccflags-y += -I$(srctree)/drivers/media/i2c
diff --git a/drivers/media/platform/tegra/Kconfig 
b/drivers/media/platform/tegra/Kconfig
new file mode 100644
index 000..54c0e7a
--- /dev/null
+++ b/drivers/media/platform/tegra/Kconfig
@@ -0,0 +1,10 @@
+config VIDEO_TEGRA
+   tristate "NVIDIA Tegra Video Input Driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+   depends on TEGRA_HOST1X
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ Driver for Video Input (VI) controller found on NVIDIA Tegra SoC.
+
+ To compile this driver as a module, choose M here: the module will be
+ called tegra-video.
diff --git a/drivers/media/platform/tegra/Makefile 
b/drivers/media/platform/tegra/Makefile
new file mode 100644
index 000..18a1c16
--- /dev/null
+++ b/drivers/media/platform/tegra/Makefile
@@ -0,0 +1,3 @@
+tegra-video-objs += tegra-core.o tegra-csi.o tegra-vi.o tegra-channel.o
+
+obj-$(CONFIG_VIDEO_TEGRA) += tegra-video.o
diff --git a/drivers/media/platform/tegra/tegra-channel.c 
b/drivers/media/platform/tegra/tegra-channel.c
new file mode 100644
index 000..37a7017
--- /dev/null
+++ b/drivers/media/platform/tegra/tegra-channel.c
@@ -0,0 +1,782 @@
+/*
+ * NVIDIA Tegra Video Input Device
+ *
+ * Copyright (c) 2015, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author: Bryan Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "tegra-vi.h"
+
+#define TEGRA_VI_SYNCPT_WAIT_TIMEOUT   200
+
+/* VI registers */
+#define TEGRA_VI_CFG_VI_INCR_SYNCPT0x000
+#define   VI_CFG_VI_INCR_SYNCPT_COND(x)(((x) & 0xff) 
<< 8)
+#define   VI_CSI_PP_LINE_START(port)   (4 + (port) * 4)
+#define   VI_CSI_PP_FRAME_START(port)  (5 + (port) * 4)
+#define   VI_CSI_MW_REQ_DONE(port) (6 + (port) * 4)
+#define   VI_CSI_MW_ACK_DONE(port) (7 + (port) * 4)
+
+#define TEGRA_VI_CFG_VI_INCR_SYNCPT_CNTRL  0x004
+#define TEGRA_VI_CFG_VI_INCR_SYNCPT_ERROR  0x008
+#define TEGRA_VI_CFG_CTXSW 0x020
+#define TEGRA_VI_CFG_INTSTATUS 0x024
+#define 

[PATCH V2 0/2] rc: Add timeout support to gpio-ir-recv

2015-09-21 Thread Eric Nelson
Add timeout support to the gpio-ir-recv driver as discussed
in this original patch:

https://patchwork.ozlabs.org/patch/516827/

V2 uses the timeout field of the rcdev instead of a device tree 
field to set the timeout value as suggested by Sean Young.

Eric Nelson (2):
  rc-core: define a default timeout for drivers
  rc: gpio-ir-recv: add timeout on idle

 drivers/media/rc/gpio-ir-recv.c | 22 ++
 include/media/rc-core.h |  1 +
 2 files changed, 23 insertions(+)

-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] [media] v4l: tegra: Add NVIDIA Tegra VI driver

2015-09-21 Thread Bryan Wu

On 09/16/2015 02:13 AM, Hans Verkuil wrote:

Hi Bryan,

Thanks for this patch series!

The switch to a kthread helps a lot, but I still have a number of comments
about it, primarily locking related.

On 09/16/2015 03:35 AM, Bryan Wu wrote:

NVIDIA Tegra processor contains a powerful Video Input (VI) hardware
controller which can support up to 6 MIPI CSI camera sensors.

This patch adds a V4L2 media controller and capture driver to support
Tegra VI hardware. It's verified with Tegra built-in test pattern
generator.

Signed-off-by: Bryan Wu
Reviewed-by: Hans Verkuil
---
  drivers/media/platform/Kconfig   |   1 +
  drivers/media/platform/Makefile  |   2 +
  drivers/media/platform/tegra/Kconfig |  10 +
  drivers/media/platform/tegra/Makefile|   3 +
  drivers/media/platform/tegra/tegra-channel.c | 802 +++
  drivers/media/platform/tegra/tegra-core.c| 252 +
  drivers/media/platform/tegra/tegra-core.h| 162 ++
  drivers/media/platform/tegra/tegra-csi.c | 566 +++
  drivers/media/platform/tegra/tegra-vi.c  | 581 +++
  drivers/media/platform/tegra/tegra-vi.h  | 213 +++
  10 files changed, 2592 insertions(+)
  create mode 100644 drivers/media/platform/tegra/Kconfig
  create mode 100644 drivers/media/platform/tegra/Makefile
  create mode 100644 drivers/media/platform/tegra/tegra-channel.c
  create mode 100644 drivers/media/platform/tegra/tegra-core.c
  create mode 100644 drivers/media/platform/tegra/tegra-core.h
  create mode 100644 drivers/media/platform/tegra/tegra-csi.c
  create mode 100644 drivers/media/platform/tegra/tegra-vi.c
  create mode 100644 drivers/media/platform/tegra/tegra-vi.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f6bed19..553867f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -119,6 +119,7 @@ source "drivers/media/platform/exynos4-is/Kconfig"
  source "drivers/media/platform/s5p-tv/Kconfig"
  source "drivers/media/platform/am437x/Kconfig"
  source "drivers/media/platform/xilinx/Kconfig"
+source "drivers/media/platform/tegra/Kconfig"
  
  endif # V4L_PLATFORM_DRIVERS
  




diff --git a/drivers/media/platform/tegra/tegra-channel.c 
b/drivers/media/platform/tegra/tegra-channel.c
new file mode 100644
index 000..8149016
--- /dev/null
+++ b/drivers/media/platform/tegra/tegra-channel.c
@@ -0,0 +1,802 @@




+static int tegra_channel_capture_frame(struct tegra_channel *chan)
+{
+   struct tegra_channel_buffer *buf = chan->active;

I think this can just be passed as an argument instead of being a field
in the chan struct. I'm not 100% certain, you'd have to check this.

Good point. I will remove the active of chan and pass a buffer pointer here.


+   struct vb2_buffer *vb = >buf;
+   int err = 0;
+   u32 thresh, value, frame_start;
+   int bytes_per_line = chan->format.bytesperline;
+
+   if (!vb2_start_streaming_called(>queue) || !buf)
+   return -EINVAL;

Can this ever happen? Perhaps this should be using WARN_ON?

This check should be redundant. Let me remove them.



+
+   /* Program buffer address by using surface 0 */
+   csi_write(chan, TEGRA_VI_CSI_SURFACE0_OFFSET_MSB, 0x0);
+   csi_write(chan, TEGRA_VI_CSI_SURFACE0_OFFSET_LSB, buf->addr);
+   csi_write(chan, TEGRA_VI_CSI_SURFACE0_STRIDE, bytes_per_line);
+
+   /* Program syncpoint */
+   frame_start = VI_CSI_PP_FRAME_START(chan->port);
+   value = VI_CFG_VI_INCR_SYNCPT_COND(frame_start) |
+   host1x_syncpt_id(chan->sp);
+   tegra_channel_write(chan, TEGRA_VI_CFG_VI_INCR_SYNCPT, value);
+
+   csi_write(chan, TEGRA_VI_CSI_SINGLE_SHOT, SINGLE_SHOT_CAPTURE);
+
+   /* Use syncpoint to wake up */
+   thresh = host1x_syncpt_incr_max(chan->sp, 1);
+   err = host1x_syncpt_wait(chan->sp, thresh,
+TEGRA_VI_SYNCPT_WAIT_TIMEOUT, );
+   if (err) {
+   dev_err(>video.dev, "frame start syncpt timeout!\n");
+   tegra_channel_capture_error(chan);
+   }
+
+   /* Captured one frame */
+   spin_lock_irq(>queued_lock);

Why use spinlock_irq? You're not in interrupt context. A normal spinlock is
sufficient. Or perhaps the mutex_lock is enough (this function is already
called with that lock held).


I will review the locking code here. looks like mutex_lock(chan->lock) 
is not required here. Or just keep one spinlock should be OK.



+   vb->v4l2_buf.sequence = chan->sequence++;
+   vb->v4l2_buf.field = V4L2_FIELD_NONE;

Add a comment here that this will need to be changed if you ever start 
supporting
interlaced formats.


Sure. fixed.


+   v4l2_get_timestamp(>v4l2_buf.timestamp);
+   vb2_set_plane_payload(vb, 0, chan->format.sizeimage);
+   vb2_buffer_done(vb, err < 0 ? VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
+   

[PATCH V2 1/2] rc-core: define a default timeout for drivers

2015-09-21 Thread Eric Nelson
A default timeout value of 100ms is workable for most decoders.
Declare a constant to help standardize its' use.

Signed-off-by: Eric Nelson 
---
 include/media/rc-core.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index ec921f6..62c64bd 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -239,6 +239,7 @@ static inline void init_ir_raw_event(struct ir_raw_event 
*ev)
memset(ev, 0, sizeof(*ev));
 }
 
+#define IR_DEFAULT_TIMEOUT MS_TO_NS(100)
 #define IR_MAX_DURATION 5  /* 500 ms */
 #define US_TO_NS(usec) ((usec) * 1000)
 #define MS_TO_US(msec) ((msec) * 1000)
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 0/2] rc: Add timeout support to gpio-ir-recv

2015-09-21 Thread Eric Nelson
Add timeout support to the gpio-ir-recv driver as discussed
in this original patch:

https://patchwork.ozlabs.org/patch/516827/

V2 uses the timeout field of the rcdev instead of a device tree 
field to set the timeout value as suggested by Sean Young.

Eric Nelson (2):
  rc-core: define a default timeout for drivers
  rc: gpio-ir-recv: add timeout on idle

 drivers/media/rc/gpio-ir-recv.c | 22 ++
 include/media/rc-core.h |  1 +
 2 files changed, 23 insertions(+)

-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 2/2] rc: gpio-ir-recv: add timeout on idle

2015-09-21 Thread Eric Nelson
Many decoders require a trailing space (period without IR illumination)
to be delivered before completing a decode.

Since the gpio-ir-recv driver only delivers events on gpio transitions,
a single IR symbol (caused by a quick touch on an IR remote) will not
be properly decoded without the use of a timer to flush the tail end
state of the IR receiver.

This patch initializes and uses a timer and the timeout field of rcdev
to complete the stream and allow decode.

The timeout can be overridden through the use of the LIRC_SET_REC_TIMEOUT
ioctl.

Signed-off-by: Eric Nelson 
---
 drivers/media/rc/gpio-ir-recv.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 7dbc9ca..d3b216a 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -30,6 +30,7 @@ struct gpio_rc_dev {
struct rc_dev *rcdev;
int gpio_nr;
bool active_low;
+   struct timer_list flush_timer;
 };
 
 #ifdef CONFIG_OF
@@ -93,12 +94,26 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
if (rc < 0)
goto err_get_value;
 
+   mod_timer(_dev->flush_timer,
+ jiffies + nsecs_to_jiffies(gpio_dev->rcdev->timeout));
+
ir_raw_event_handle(gpio_dev->rcdev);
 
 err_get_value:
return IRQ_HANDLED;
 }
 
+static void flush_timer(unsigned long arg)
+{
+   struct gpio_rc_dev *gpio_dev = (struct gpio_rc_dev *)arg;
+   DEFINE_IR_RAW_EVENT(ev);
+
+   ev.timeout = true;
+   ev.duration =  gpio_dev->rcdev->timeout;
+   ir_raw_event_store(gpio_dev->rcdev, );
+   ir_raw_event_handle(gpio_dev->rcdev);
+}
+
 static int gpio_ir_recv_probe(struct platform_device *pdev)
 {
struct gpio_rc_dev *gpio_dev;
@@ -144,6 +159,9 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
rcdev->input_id.version = 0x0100;
rcdev->dev.parent = >dev;
rcdev->driver_name = GPIO_IR_DRIVER_NAME;
+   rcdev->min_timeout = 1;
+   rcdev->timeout = IR_DEFAULT_TIMEOUT;
+   rcdev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
if (pdata->allowed_protos)
rcdev->allowed_protocols = pdata->allowed_protos;
else
@@ -154,6 +172,10 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
gpio_dev->gpio_nr = pdata->gpio_nr;
gpio_dev->active_low = pdata->active_low;
 
+   init_timer(_dev->flush_timer);
+   gpio_dev->flush_timer.function = flush_timer;
+   gpio_dev->flush_timer.data = (unsigned long)gpio_dev;
+
rc = gpio_request(pdata->gpio_nr, "gpio-ir-recv");
if (rc < 0)
goto err_gpio_request;
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] vivid: add 10 and 12 bit Bayer formats

2015-09-21 Thread Hans Verkuil
Add support for 10 and 12 bit Bayer formats to the test pattern generator
and the vivid driver.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-tpg.c| 91 +
 drivers/media/platform/vivid/vivid-vid-common.c | 56 +++
 2 files changed, 147 insertions(+)

diff --git a/drivers/media/platform/vivid/vivid-tpg.c 
b/drivers/media/platform/vivid/vivid-tpg.c
index 1458c79..1425614 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -193,6 +193,14 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SRGGB8:
+   case V4L2_PIX_FMT_SBGGR10:
+   case V4L2_PIX_FMT_SGBRG10:
+   case V4L2_PIX_FMT_SGRBG10:
+   case V4L2_PIX_FMT_SRGGB10:
+   case V4L2_PIX_FMT_SBGGR12:
+   case V4L2_PIX_FMT_SGBRG12:
+   case V4L2_PIX_FMT_SGRBG12:
+   case V4L2_PIX_FMT_SRGGB12:
tpg->interleaved = true;
tpg->vdownsampling[1] = 1;
tpg->hdownsampling[1] = 1;
@@ -349,6 +357,17 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->twopixelsize[0] = 2;
tpg->twopixelsize[1] = 2;
break;
+   case V4L2_PIX_FMT_SRGGB10:
+   case V4L2_PIX_FMT_SGRBG10:
+   case V4L2_PIX_FMT_SGBRG10:
+   case V4L2_PIX_FMT_SBGGR10:
+   case V4L2_PIX_FMT_SRGGB12:
+   case V4L2_PIX_FMT_SGRBG12:
+   case V4L2_PIX_FMT_SGBRG12:
+   case V4L2_PIX_FMT_SBGGR12:
+   tpg->twopixelsize[0] = 4;
+   tpg->twopixelsize[1] = 4;
+   break;
case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
@@ -1112,6 +1131,70 @@ static void gen_twopix(struct tpg_data *tpg,
buf[0][offset] = odd ? g_u : r_y;
buf[1][offset] = odd ? b_v : g_u;
break;
+   case V4L2_PIX_FMT_SBGGR10:
+   buf[0][offset] = odd ? g_u << 2 : b_v << 2;
+   buf[0][offset + 1] = odd ? g_u >> 6 : b_v >> 6;
+   buf[1][offset] = odd ? r_y << 2 : g_u << 2;
+   buf[1][offset + 1] = odd ? r_y >> 6 : g_u >> 6;
+   buf[0][offset] |= (buf[0][offset] >> 2) & 3;
+   buf[1][offset] |= (buf[1][offset] >> 2) & 3;
+   break;
+   case V4L2_PIX_FMT_SGBRG10:
+   buf[0][offset] = odd ? b_v << 2 : g_u << 2;
+   buf[0][offset + 1] = odd ? b_v >> 6 : g_u >> 6;
+   buf[1][offset] = odd ? g_u << 2 : r_y << 2;
+   buf[1][offset + 1] = odd ? g_u >> 6 : r_y >> 6;
+   buf[0][offset] |= (buf[0][offset] >> 2) & 3;
+   buf[1][offset] |= (buf[1][offset] >> 2) & 3;
+   break;
+   case V4L2_PIX_FMT_SGRBG10:
+   buf[0][offset] = odd ? r_y << 2 : g_u << 2;
+   buf[0][offset + 1] = odd ? r_y >> 6 : g_u >> 6;
+   buf[1][offset] = odd ? g_u << 2 : b_v << 2;
+   buf[1][offset + 1] = odd ? g_u >> 6 : b_v >> 6;
+   buf[0][offset] |= (buf[0][offset] >> 2) & 3;
+   buf[1][offset] |= (buf[1][offset] >> 2) & 3;
+   break;
+   case V4L2_PIX_FMT_SRGGB10:
+   buf[0][offset] = odd ? g_u << 2 : r_y << 2;
+   buf[0][offset + 1] = odd ? g_u >> 6 : r_y >> 6;
+   buf[1][offset] = odd ? b_v << 2 : g_u << 2;
+   buf[1][offset + 1] = odd ? b_v >> 6 : g_u >> 6;
+   buf[0][offset] |= (buf[0][offset] >> 2) & 3;
+   buf[1][offset] |= (buf[1][offset] >> 2) & 3;
+   break;
+   case V4L2_PIX_FMT_SBGGR12:
+   buf[0][offset] = odd ? g_u << 4 : b_v << 4;
+   buf[0][offset + 1] = odd ? g_u >> 4 : b_v >> 4;
+   buf[1][offset] = odd ? r_y << 4 : g_u << 4;
+   buf[1][offset + 1] = odd ? r_y >> 4 : g_u >> 4;
+   buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
+   buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
+   break;
+   case V4L2_PIX_FMT_SGBRG12:
+   buf[0][offset] = odd ? b_v << 4 : g_u << 4;
+   buf[0][offset + 1] = odd ? b_v >> 4 : g_u >> 4;
+   buf[1][offset] = odd ? g_u << 4 : r_y << 4;
+   buf[1][offset + 1] = odd ? g_u >> 4 : r_y >> 4;
+   buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
+   buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
+   break;
+   case V4L2_PIX_FMT_SGRBG12:
+   buf[0][offset] = odd ? r_y << 4 : g_u << 4;
+   buf[0][offset + 1] = odd ? r_y >> 4 : g_u >> 4;
+   buf[1][offset] = odd ? g_u << 4 : b_v << 4;
+   buf[1][offset + 1] = odd ? g_u >> 4 : b_v >> 4;
+   buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
+   buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
+