date:20150129


Hello.

On 01/29/2015 07:19 PM, William Towle wrote:

   No signed off? Although, looking at the patch, I'm not very surprised...


---
  arch/arm/boot/dts/r8a7790-lager.dts |   51 +++
  1 file changed, 34 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index be44493..c20b6cb 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -249,9 +249,9 @@
renesas,function = usb2;
};

-   vin1_pins: vin {
-   renesas,groups = vin1_data8, vin1_clk;
-   renesas,function = vin1;


   I'm not sure why are you removing the VIN1 pins while adding VIN0 pins.


+   vin0_pins: vin0 {
+   renesas,groups = vin0_data24, vin0_sync, vin0_field, vin0_clkenb, 
vin0_clk;
+   renesas,function = vin0;
};
  };

@@ -391,15 +391,15 @@
pinctrl-0 = iic2_pins;
pinctrl-names = default;

-   composite-in@20 {
-   compatible = adi,adv7180;
-   reg = 0x20;
-   remote = vin1;


Why remove it?


+   adv7612: adv7612@0x4c {


   We don't call the nodes with chip names. According to the ePAPR standard 
section 2.2.2, node names should reflect the general function of the device.

And drop 0x prefix from unit-address prt of the name please.


+   compatible = adi,adv7612;
+   reg = 0x4c;
+   remote = vin0;

port {
-   adv7180: endpoint {
-   bus-width = 8;
-   remote-endpoint = vin1ep0;
+   adv7612_1: endpoint {
+   remote-endpoint = vin0ep0;
+   default-input = 0;
};
};
};
@@ -419,6 +419,19 @@
i2c-gpio,delay-us = 1;  /* ~100 kHz */
#address-cells = 1;
#size-cells = 0;
+
+   adv7612: adv7612@0x4c {


   Two identical labels? Do we really have 2 ADV7162 chips on the board?
   And the same comments on the node name...


+   compatible = adi,adv7612;
+   reg = 0x4c;
+   remote = vin0;
+
+   port {
+   adv7612_1: endpoint {


   Two identical labels?


+   remote-endpoint = vin0ep0;
+   default-input = 0;
+   };
+   };
+   };
};
  };
  #endif
@@ -457,9 +470,9 @@
pinctrl-names = default;
  };

-/* composite video input */
-vin1 {
-   pinctrl-0 = vin1_pins;


   Why remove it?


+/* HDMI video input */
+vin0 {
+   pinctrl-0 = vin0_pins;
pinctrl-names = default;

status = ok;
@@ -468,9 +481,13 @@
#address-cells = 1;
#size-cells = 0;

-   vin1ep0: endpoint {
-   remote-endpoint = adv7180;
-   bus-width = 8;
+   vin0ep0: endpoint {
+   remote-endpoint = adv7612_1;
+   bus-width = 24;
+   hsync-active = 0;
+   vsync-active = 0;
+   pclk-sample = 1;
+   data-active = 1;
};
};

[...]

WBR, Sergei

--
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 5/8] media: rcar_vin: Add RGB888_1X24 input format support


Hello.

On 01/29/2015 07:19 PM, William Towle wrote:


This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.



Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com


   I wonder why it hasn't been merged still? It's pending since 2013, and I'm 
seeing no objections to it...


WBR, Sergei

--
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] coda: Add tracing support

2015-01-29 Thread Philipp Zabel

This patch adds tracepoints to the coda driver that can be used together
with the v4l2:v4l2_qbuf and v4l2:v4l2_dqbuf tracepoints to to follow video
frames through the mem2mem device.

For encoding with the BIT processor:
coda:coda_enc_pic_run
coda:coda_enc_pic_done

For decoding with the BIT processor:
coda:coda_bit_queue
coda:coda_dec_pic_run
coda:coda_dec_pic_done
coda:coda_dec_rot_done

Additionally, two low level tracepoints register whenever the BIT processor
is started and returns:
coda:coda_bit_run
coda:coda_bit_done

Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
 drivers/media/platform/coda/Makefile|   2 +
 drivers/media/platform/coda/coda-bit.c  |  24 +++-
 drivers/media/platform/coda/coda-jpeg.c |   1 +
 drivers/media/platform/coda/coda.h  |   5 +
 drivers/media/platform/coda/trace.h | 203 
 5 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/coda/trace.h

diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 25ce155..834e504 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -1,3 +1,5 @@
+ccflags-y += -I$(src)
+
 coda-objs := coda-common.o coda-bit.o coda-h264.o coda-jpeg.o
 
 obj-$(CONFIG_VIDEO_CODA) += coda.o
diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 856b542..494cf59 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -29,6 +29,8 @@
 #include media/videobuf2-vmalloc.h
 
 #include coda.h
+#define CREATE_TRACE_POINTS
+#include trace.h
 
 #define CODA7_PS_BUF_SIZE  0x28000
 #define CODA9_PS_SAVE_SIZE (512 * 1024)
@@ -84,15 +86,21 @@ static void coda_command_async(struct coda_ctx *ctx, int 
cmd)
coda_write(dev, ctx-params.codec_mode, CODA_REG_BIT_RUN_COD_STD);
coda_write(dev, ctx-params.codec_mode_aux, CODA7_REG_BIT_RUN_AUX_STD);
 
+   trace_coda_bit_run(ctx, cmd);
+
coda_write(dev, cmd, CODA_REG_BIT_RUN_COMMAND);
 }
 
 static int coda_command_sync(struct coda_ctx *ctx, int cmd)
 {
struct coda_dev *dev = ctx-dev;
+   int ret;
 
coda_command_async(ctx, cmd);
-   return coda_wait_timeout(dev);
+   ret = coda_wait_timeout(dev);
+   trace_coda_bit_done(ctx);
+
+   return ret;
 }
 
 int coda_hw_reset(struct coda_ctx *ctx)
@@ -262,6 +270,8 @@ void coda_fill_bitstream(struct coda_ctx *ctx)
ctx-bitstream_fifo.kfifo.mask;
list_add_tail(meta-list,
  ctx-buffer_meta_list);
+
+   trace_coda_bit_queue(ctx, src_buf, meta);
}
 
v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE);
@@ -1227,6 +1237,8 @@ static int coda_prepare_encode(struct coda_ctx *ctx)
coda_write(dev, ctx-iram_info.axi_sram_use,
CODA7_REG_BIT_AXI_SRAM_USE);
 
+   trace_coda_enc_pic_run(ctx, src_buf);
+
coda_command_async(ctx, CODA_COMMAND_PIC_RUN);
 
return 0;
@@ -1241,6 +1253,8 @@ static void coda_finish_encode(struct coda_ctx *ctx)
src_buf = v4l2_m2m_src_buf_remove(ctx-fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx-fh.m2m_ctx);
 
+   trace_coda_enc_pic_done(ctx, dst_buf);
+
/* Get results from the coda */
start_ptr = coda_read(dev, CODA_CMD_ENC_PIC_BB_START);
wr_ptr = coda_read(dev, CODA_REG_BIT_WR_PTR(ctx-reg_idx));
@@ -1675,6 +1689,8 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
/* Clear decode success flag */
coda_write(dev, 0, CODA_RET_DEC_PIC_SUCCESS);
 
+   trace_coda_dec_pic_run(ctx, meta);
+
coda_command_async(ctx, CODA_COMMAND_PIC_RUN);
 
return 0;
@@ -1835,6 +1851,8 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
mutex_unlock(ctx-bitstream_mutex);
 
+   trace_coda_dec_pic_done(ctx, ctx-frame_metas[decoded_idx]);
+
val = coda_read(dev, CODA_RET_DEC_PIC_TYPE)  0x7;
if (val == 0)
ctx-frame_types[decoded_idx] = V4L2_BUF_FLAG_KEYFRAME;
@@ -1874,6 +1892,8 @@ static void coda_finish_decode(struct coda_ctx *ctx)
dst_buf-v4l2_buf.timecode = meta-timecode;
dst_buf-v4l2_buf.timestamp = meta-timestamp;
 
+   trace_coda_dec_rot_done(ctx, meta, dst_buf);
+
switch (q_data_dst-fourcc) {
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
@@ -1931,6 +1951,8 @@ irqreturn_t coda_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
 
+   trace_coda_bit_done(ctx);
+
if (ctx-aborting) {
v4l2_dbg(1, coda_debug, ctx-dev-v4l2_dev,
 task has been

Re: [PATCH v5] media: au0828 - convert to use videobuf2

2015-01-29 Thread Davidlohr Bueso

On Thu, 2015-01-29 at 12:15 +0100, Hans Verkuil wrote:
 You can't split this up, it's one of those changes that is all or
 nothing.

Fair enough. With changes that large, it should be mentioned, though.
Thanks.

--
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 v5] media: au0828 - convert to use videobuf2

2015-01-29 Thread Davidlohr Bueso

On Wed, 2015-01-28 at 16:14 -0700, Shuah Khan wrote:
 On 01/23/2015 12:41 PM, Shuah Khan wrote:
  Convert au0828 to use videobuf2. Tested with NTSC.
  Tested video and vbi devices with xawtv, tvtime,
  and vlc. Ran v4l2-compliance to ensure there are
  no failures. 
  
  Video compliance test results summary:
  Total: 75, Succeeded: 75, Failed: 0, Warnings: 18
  
  Vbi compliance test results summary:
  Total: 75, Succeeded: 75, Failed: 0, Warnings: 0
  
  Signed-off-by: Shuah Khan shua...@osg.samsung.com
  ---
 
 Hi Hans,
 
 Please don't pull this in. Found a bug in stop_streaming() when
 re-tuning that requires re-working this patch.

... and also:

 drivers/media/usb/au0828/Kconfig|   2 +-
 drivers/media/usb/au0828/au0828-vbi.c   | 122 ++--
 drivers/media/usb/au0828/au0828-video.c | 962 
 drivers/media/usb/au0828/au0828.h   |  61 +-
 4 files changed, 443 insertions(+), 704 deletions(-)

in a single patch. Lets be nice to reviewers, we can spare a few extra
hash ids.

--
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: use consistent colorspace/Y'CbCr Encoding strings

Keep the colorspace and encoding names consistent with what is
used elsewhere (primarily the utilities in v4l-utils.git).

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/platform/vivid/vivid-ctrls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
b/drivers/media/platform/vivid/vivid-ctrls.c
index 857e786..32a798f 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -689,7 +689,7 @@ static const struct v4l2_ctrl_config 
vivid_ctrl_max_edid_blocks = {
 
 static const char * const vivid_ctrl_colorspace_strings[] = {
SMPTE 170M,
-   REC 709,
+   Rec. 709,
sRGB,
AdobeRGB,
BT.2020,
@@ -716,7 +716,7 @@ static const char * const vivid_ctrl_ycbcr_enc_strings[] = {
xvYCC 601,
xvYCC 709,
sYCC,
-   BT.2020 Non-Constant Luminance,
+   BT.2020,
BT.2020 Constant Luminance,
SMPTE 240M,
NULL,
-- 
2.1.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: [PATCH 3/7] [media] staging/davinci/vpfe/dm365: add missing dependencies

On Wed, Jan 28, 2015 at 9:17 PM, Arnd Bergmann a...@arndb.de wrote:
 This driver can only be built when VIDEO_V4L2_SUBDEV_API
 and VIDEO_DAVINCI_VPBE_DISPLAY are also provided by the
 kernel.

 drivers/staging/media/davinci_vpfe/dm365_isif.c: In function 
 '__isif_get_format':
 drivers/staging/media/davinci_vpfe/dm365_isif.c:1410:3: error: implicit 
 declaration of function 'v4l2_subdev_get_try_format' 
 [-Werror=implicit-function-declaration]
return v4l2_subdev_get_try_format(fh, pad);
^

 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org

Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com

Regards,
--Prabhakar Lad

 ---
  drivers/staging/media/davinci_vpfe/Kconfig | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/staging/media/davinci_vpfe/Kconfig 
 b/drivers/staging/media/davinci_vpfe/Kconfig
 index 4de2f082491d..f40a06954a92 100644
 --- a/drivers/staging/media/davinci_vpfe/Kconfig
 +++ b/drivers/staging/media/davinci_vpfe/Kconfig
 @@ -2,6 +2,8 @@ config VIDEO_DM365_VPFE
 tristate DM365 VPFE Media Controller Capture Driver
 depends on VIDEO_V4L2  ARCH_DAVINCI_DM365  !VIDEO_DM365_ISIF
 depends on HAS_DMA
 +   depends on VIDEO_V4L2_SUBDEV_API
 +   depends on VIDEO_DAVINCI_VPBE_DISPLAY
 select VIDEOBUF2_DMA_CONTIG
 help
   Support for DM365 VPFE based Media Controller Capture driver.
 --
 2.1.0.rc2


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2

2015-01-29 Thread Raimonds Cicans


On 29.01.2015 09:33, Hans Verkuil wrote:

On 01/11/2015 10:33 AM, Raimonds Cicans wrote:

I contacted you because I am hit by regression caused by your commit:
453afdd [media] cx23885: convert to vb2


My system:
AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard
TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver)

After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7
(have commit) I started receiving following IOMMU related messages:

1)
AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d
address=0x0637c000 flags=0x]

where device=0a:00.0 is TBS6981 card

As far as I can tell this has nothing to do with the cx23885 driver but is
a bug in the amd iommu/BIOS. See e.g.:

https://bbs.archlinux.org/viewtopic.php?pid=1309055

I managed to reproduce the Intel equivalent if I enable CONFIG_IOMMU_SUPPORT.

Most likely due to broken BIOS/ACPI/whatever information that's read by the
kernel. I would recommend disabling this kernel option.


Maybe...

But on other hand this did not happen on old kernel with old driver.
And when I did bisection on old kernel + media tree I started to
receive this message only on new driver.

And I can not disable this feature because then USB and LAN
stop working.


Ray
--
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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2

On 01/29/15 12:51, Raimonds Cicans wrote:
 On 29.01.2015 09:33, Hans Verkuil wrote:
 On 01/11/2015 10:33 AM, Raimonds Cicans wrote:
 I contacted you because I am hit by regression caused by your commit:
 453afdd [media] cx23885: convert to vb2


 My system:
 AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard
 TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver)

 After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7
 (have commit) I started receiving following IOMMU related messages:

 1)
 AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d
 address=0x0637c000 flags=0x]

 where device=0a:00.0 is TBS6981 card
 As far as I can tell this has nothing to do with the cx23885 driver but is
 a bug in the amd iommu/BIOS. See e.g.:

 https://bbs.archlinux.org/viewtopic.php?pid=1309055

 I managed to reproduce the Intel equivalent if I enable CONFIG_IOMMU_SUPPORT.

 Most likely due to broken BIOS/ACPI/whatever information that's read by the
 kernel. I would recommend disabling this kernel option.

 Maybe...
 
 But on other hand this did not happen on old kernel with old driver.
 And when I did bisection on old kernel + media tree I started to
 receive this message only on new driver.

Was CONFIG_IOMMU_SUPPORT enabled in the old kernel?

Regards,

Hans

 And I can not disable this feature because then USB and LAN
 stop working.


--
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 RFC] staging: media: davinci_vpfe: drop condition with no effect

On Mon, Jan 26, 2015 at 7:27 AM, Nicholas Mc Guire der.h...@hofr.at wrote:
 As the if and else branch body are identical the condition has no effect and
 can be dropped.

 Signed-off-by: Nicholas Mc Guire der.h...@hofr.at

Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com

Regards,
--Prabhakar Lad

 ---

 As the if and the else branch of the inner conditional paths are the same
 the condition is without effect. Given the comments indicate that
 the else branch *should* be handling a specific case this may indicate
 a bug, in which case the below patch is *wrong*. This needs a review by
 someone that knows the specifics of this driver.

 If the inner if/else is a placeholder for planed updates then it should
 be commented so this is clear.

 Patch was only compile tested with davinci_all_defconfig + CONFIG_STAGING=y
 CONFIG_STAGING_MEDIA=y, CONFIG_MEDIA_SUPPORT=m,
 CONFIG_MEDIA_ANALOG_TV_SUPPORT=y, CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_MEDIA_CONTROLLER=y, CONFIG_VIDEO_V4L2_SUBDEV_API=y
 CONFIG_VIDEO_DM365_VPFE=m

 Patch is against 3.0.19-rc5 -next-20150123

  drivers/staging/media/davinci_vpfe/dm365_resizer.c |9 ++---
  1 file changed, 2 insertions(+), 7 deletions(-)

 diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c 
 b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
 index 75e70e1..bf2cb7a 100644
 --- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
 +++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
 @@ -63,16 +63,11 @@ resizer_calculate_line_length(u32 pix, int width, int 
 height,
 if (pix == MEDIA_BUS_FMT_UYVY8_2X8 ||
 pix == MEDIA_BUS_FMT_SGRBG12_1X12) {
 *line_len = width  1;
 -   } else if (pix == MEDIA_BUS_FMT_Y8_1X8 ||
 -  pix == MEDIA_BUS_FMT_UV8_1X8) {
 -   *line_len = width;
 -   *line_len_c = width;
 -   } else {
 -   /* YUV 420 */
 -   /* round width to upper 32 byte boundary */
 +   } else {
 *line_len = width;
 *line_len_c = width;
 }
 +
 /* adjust the line len to be a multiple of 32 */
 *line_len += 31;
 *line_len = ~0x1f;
 --
 1.7.10.4

--
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 v5] media: au0828 - convert to use videobuf2



On 01/29/15 12:13, Davidlohr Bueso wrote:
 On Wed, 2015-01-28 at 16:14 -0700, Shuah Khan wrote:
 On 01/23/2015 12:41 PM, Shuah Khan wrote:
 Convert au0828 to use videobuf2. Tested with NTSC.
 Tested video and vbi devices with xawtv, tvtime,
 and vlc. Ran v4l2-compliance to ensure there are
 no failures. 

 Video compliance test results summary:
 Total: 75, Succeeded: 75, Failed: 0, Warnings: 18

 Vbi compliance test results summary:
 Total: 75, Succeeded: 75, Failed: 0, Warnings: 0

 Signed-off-by: Shuah Khan shua...@osg.samsung.com
 ---

 Hi Hans,

 Please don't pull this in. Found a bug in stop_streaming() when
 re-tuning that requires re-working this patch.
 
 ... and also:
 
  drivers/media/usb/au0828/Kconfig|   2 +-
  drivers/media/usb/au0828/au0828-vbi.c   | 122 ++--
  drivers/media/usb/au0828/au0828-video.c | 962 
 
  drivers/media/usb/au0828/au0828.h   |  61 +-
  4 files changed, 443 insertions(+), 704 deletions(-)
 
 in a single patch. Lets be nice to reviewers, we can spare a few extra
 hash ids.

You can't split this up, it's one of those changes that is all or
nothing.

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 02/21] [media] coda: bitrate can only be set in kbps steps

2015-01-29 Thread Kamil Debski

Hi Philipp,

Could you add a one sentence description for this patch?
I know that it is really simple, but still the description is still
necessary.

Best wishes,
-- 
Kamil Debski
Samsung RD Institute Poland


 -Original Message-
 From: Philipp Zabel [mailto:p.za...@pengutronix.de]
 Sent: Friday, January 23, 2015 5:51 PM
 To: Kamil Debski
 Cc: linux-media@vger.kernel.org; Philipp Zabel
 Subject: [PATCH 02/21] [media] coda: bitrate can only be set in kbps
 steps
 
 Signed-off-by: Philipp Zabel p.za...@pengutronix.de
 ---
  drivers/media/platform/coda/coda-common.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/media/platform/coda/coda-common.c
 b/drivers/media/platform/coda/coda-common.c
 index 39330a7..1cc4e90 100644
 --- a/drivers/media/platform/coda/coda-common.c
 +++ b/drivers/media/platform/coda/coda-common.c
 @@ -1407,7 +1407,7 @@ static const struct v4l2_ctrl_ops coda_ctrl_ops =
 {  static void coda_encode_ctrls(struct coda_ctx *ctx)  {
   v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
 - V4L2_CID_MPEG_VIDEO_BITRATE, 0, 32767000, 1, 0);
 + V4L2_CID_MPEG_VIDEO_BITRATE, 0, 32767000, 1000, 0);
   v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
   V4L2_CID_MPEG_VIDEO_GOP_SIZE, 1, 60, 1, 16);
   v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
 --
 2.1.4

--
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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

2015-01-29 Thread Sumit Semwal

Hi Russell!

On 29 January 2015 at 20:09, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
 +/*
 + * recalc_constraints - recalculates constraints for all attached devices;
 + *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
 + *  helper.
 + *  Returns recalculated constraints in recalc_cons, or error in the 
 unlikely
 + *  case when constraints of attached devices might have changed.
 + */

Thanks for your valuable review comments!

 Please see kerneldoc documentation for the proper format of these comments.
These are static functions, and as such kerneldoc doesn't enforce
kernel-doc style comments, so in the dma-buf files, we've not followed
them for static functions.
That said, it is certainly a valuable advice, and I could create a
separate patch-set for updating the documentation for the static
functions as well.

 +static int recalc_constraints(struct dma_buf *dmabuf,
 +   struct device_dma_parameters *recalc_cons)
 +{
 + struct device_dma_parameters calc_cons;
 + struct dma_buf_attachment *attach;
 + int ret = 0;
 +
 + init_constraints(calc_cons);
 +
 + list_for_each_entry(attach, dmabuf-attachments, node) {
 + ret = calc_constraints(attach-dev, calc_cons);
 + if (ret)
 + return ret;
 + }
 + *recalc_cons = calc_cons;
 + return 0;
 +}
 +
  /**
   * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
   * with this buffer, so it can be exported.
 @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
 struct dma_buf_ops *ops,
   dmabuf-ops = ops;
   dmabuf-size = size;
   dmabuf-exp_name = exp_name;
 +
 + init_constraints(dmabuf-constraints);
 +
   init_waitqueue_head(dmabuf-poll);
   dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
   dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
 @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,
 struct device *dev)
  {
   struct dma_buf_attachment *attach;
 - int ret;
 + int ret = 0;

   if (WARN_ON(!dmabuf || !dev))
   return ERR_PTR(-EINVAL);
 @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,

   mutex_lock(dmabuf-lock);

 + if (calc_constraints(dev, dmabuf-constraints))
 + goto err_constraints;
 +
   if (dmabuf-ops-attach) {
   ret = dmabuf-ops-attach(dmabuf, dev, attach);
   if (ret)
 @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,

  err_attach:
   kfree(attach);
 +err_constraints:
   mutex_unlock(dmabuf-lock);
   return ERR_PTR(ret);
  }
 @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
 dma_buf_attachment *attach)
   if (dmabuf-ops-detach)
   dmabuf-ops-detach(dmabuf, attach);

 + recalc_constraints(dmabuf, dmabuf-constraints);
 +

 To me, this whole thing seems horribly racy.

 What happens if subsystem X creates a dmabuf, which is passed to
 userspace. It's then passed to subsystem Y, which starts making use
 of it, calling dma_buf_map_attachment() on it.

 The same buffer is also passed (via unix domain sockets) to another
 program, which then passes it independently into subsystem Z, and
 subsystem Z has more restrictive DMA constraints.

 What happens at this point?

 Subsystems such as DRM cache the scatter table, and return it for
 subsequent attach calls, so DRM drivers using the default
 drm_gem_map_dma_buf() implementation would not see the restrictions
 placed upon the dmabuf.  Moreover, the returned scatterlist would not
 be modified for those restrictions either.

 What would other subsystems do?

 This needs more thought before it's merged.

 For example, in the above situation, should we deny the ability to
 create a new attachment when a dmabuf has already been mapped by an
 existing attachment?  Should we deny it only when the new attachment
 has more restrictive DMA constraints?

So, short answer is, it is left to the exporter to decide. The dma-buf
framework should not even attempt to decide or enforce any of the
above.

At each dma_buf_attach(), there's a callback to the exporter, where
the exporter can decide, if it intends to handle these kind of cases,
on the best way forward.

The exporter might, for example, decide to migrate backing storage,
should there be a need to do so, or simply deny when the new
attachment has more restrictive DMA constraints, as you mentioned as a
possibility.

These changes simply allow the exporter, should it wish to, to take
the DMA constraints into consideration while making those decisions.
For the current cases, it should not even matter if the DMA
constraints aren't shared by the devices.

 Please consider the possible sequences of use (such

RE: [possible BUG, cx23885] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used

2015-01-29 Thread dCrypt

Thank you for your comments, James. I'm sure it's not a hw fault because mine
works in Windows perfectly, and both tuners used independently also worked in
Linux.

BREl 29/1/2015 2:34, James Harper ja...@ejbdigital.com.au escribió:

Hi, James.

After searching for somebody posting some issues similar to mine, I think
this
one you posted to the mailing list can be related:

https://www.mail-archive.com/linux-
media%40vger.kernel.org/msg80078.html

I'm having problems using both tuners in a dual tuner card (Terratec
Cinergy T
PCIe Dual), also based on cx23885, but it uses different frontends/tuners
than yours.

I'm pretty sure mine was an actual hardware fault. At first it worked
perfectly. Then after a bit the server would occasionally lock up hard or
reboot, then more often, then every time. I spent ages thinking it was a
driver problem and did all sorts of traces etc and found nothing. In the end
I just got mythtv to not use the second tuner (or the first tuner - as long
as only one was used it was fine).

Then about a month ago it started locking up again occasionally, then more
often, then every time, only using the one tuner. Strange though that if it
booted up without locking up it would be okay.

I bought a usb tuner and haven't used the cx23885 card since.

I will be seeking a replacement under warranty though, as the signal quality
is quite a bit better.

Good luck in your quest though!

James

N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH 5/8] media: rcar_vin: Add RGB888_1X24 input format support


Hello.

On 01/29/2015 09:18 PM, Guennadi Liakhovetski wrote:


This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.



Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com



I wonder why it hasn't been merged still? It's pending since 2013, and I'm
seeing no objections to it...



Indeed, strange. I'm saving it for me to look at it for the next merge...
and I'll double-check that series. Maybe the series had some objections,


   Indeed, I'm now seeing the patch #1 was objected to. Patch #2 has been 
merged somewhat later.



Thanks
Guennadi


WBR, Sergei

--
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 5/8] media: rcar_vin: Add RGB888_1X24 input format support

2015-01-29 Thread Guennadi Liakhovetski

Hi Sergei,

On Thu, 29 Jan 2015, Sergei Shtylyov wrote:

 Hello.
 
 On 01/29/2015 07:19 PM, William Towle wrote:
 
  This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
  which is used by the ADV7612 chip.
 
  Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
 
I wonder why it hasn't been merged still? It's pending since 2013, and I'm
 seeing no objections to it...

Indeed, strange. I'm saving it for me to look at it for the next merge... 
and I'll double-check that series. Maybe the series had some objections, 
and for that reason this patch hasn't been picked up. I'll double-check 
anyway.

Thanks
Guennadi

 
 WBR, Sergei
 
--
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] davinci: add V4L2 dependencies

On Thu, Jan 29, 2015 at 4:12 PM, Arnd Bergmann a...@arndb.de wrote:
 The davinci media drivers use videobuf2, which they enable through
 a 'select' statement. If one of these drivers is built-in, but
 the v4l2 core is a loadable modules, we end up with a link
 error:

 drivers/built-in.o: In function `vb2_fop_mmap':
 :(.text+0x113e84): undefined reference to `video_devdata'
 drivers/built-in.o: In function `vb2_ioctl_create_bufs':
 :(.text+0x114710): undefined reference to `video_devdata'
 drivers/built-in.o: In function `vb2_ioctl_reqbufs':
 :(.text+0x114ed8): undefined reference to `video_devdata'
 drivers/built-in.o: In function `vb2_ioctl_querybuf':
 :(.text+0x115530): undefined reference to `video_devdata'

 To solve this, we need to add a dependency on VIDEO_V4L2,
 which enforces that the davinci drivers themselves can only
 be loadable modules if V4L2 is not built-in, and they do
 not cause the videobuf2 code to be built-in.

 Signed-off-by: Arnd Bergmann a...@arndb.de

Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com

Regards,
--Prabhakar Lad

 diff --git a/drivers/media/platform/davinci/Kconfig 
 b/drivers/media/platform/davinci/Kconfig
 index d9e1ddb586b1..469e9d28cec0 100644
 --- a/drivers/media/platform/davinci/Kconfig
 +++ b/drivers/media/platform/davinci/Kconfig
 @@ -1,6 +1,6 @@
  config VIDEO_DAVINCI_VPIF_DISPLAY
 tristate TI DaVinci VPIF V4L2-Display driver
 -   depends on VIDEO_DEV
 +   depends on VIDEO_V4L2
 depends on ARCH_DAVINCI || COMPILE_TEST
 depends on HAS_DMA
 select VIDEOBUF2_DMA_CONTIG
 @@ -16,7 +16,7 @@ config VIDEO_DAVINCI_VPIF_DISPLAY

  config VIDEO_DAVINCI_VPIF_CAPTURE
 tristate TI DaVinci VPIF video capture driver
 -   depends on VIDEO_DEV
 +   depends on VIDEO_V4L2
 depends on ARCH_DAVINCI || COMPILE_TEST
 depends on HAS_DMA
 select VIDEOBUF2_DMA_CONTIG
 @@ -75,7 +75,7 @@ config VIDEO_DM365_ISIF

  config VIDEO_DAVINCI_VPBE_DISPLAY
 tristate TI DaVinci VPBE V4L2-Display driver
 -   depends on ARCH_DAVINCI
 +   depends on VIDEO_V4L2  ARCH_DAVINCI
 depends on HAS_DMA
 select VIDEOBUF2_DMA_CONTIG
 help

 --
 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

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

2015-01-29 Thread Maarten Lankhorst

Op 27-01-15 om 09:25 schreef Sumit Semwal:
 Add some helpers to share the constraints of devices while attaching
 to the dmabuf buffer.

 At each attach, the constraints are calculated based on the following:
 - max_segment_size, max_segment_count, segment_boundary_mask from
device_dma_parameters.

 In case the attaching device's constraints don't match up, attach() fails.

 At detach, the constraints are recalculated based on the remaining
 attached devices.

 Two helpers are added:
 - dma_buf_get_constraints - which gives the current constraints as calculated
   during each attach on the buffer till the time,
 - dma_buf_recalc_constraints - which recalculates the constraints for all
   currently attached devices for the 'paranoid' ones amongst us.

 The idea of this patch is largely taken from Rob Clark's RFC at
 https://lkml.org/lkml/2012/7/19/285, and the comments received on it.

 Cc: Rob Clark robdcl...@gmail.com
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
 ---
 v3: 
 - Thanks to Russell's comment, remove dma_mask and coherent_dma_mask from
   constraints' calculation; has a nice side effect of letting us use
   device_dma_parameters directly to list constraints.
 - update the debugfs output to show constraint info as well.
   
 v2: split constraints-sharing and allocation helpers

  drivers/dma-buf/dma-buf.c | 126 
 +-
  include/linux/dma-buf.h   |   7 +++
  2 files changed, 132 insertions(+), 1 deletion(-)

 diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
 index 5be225c2ba98..f363f1440803 100644
 --- a/drivers/dma-buf/dma-buf.c
 +++ b/drivers/dma-buf/dma-buf.c
 @@ -264,6 +264,66 @@ static inline int is_dma_buf_file(struct file *file)
   return file-f_op == dma_buf_fops;
  }
  
 +static inline void init_constraints(struct device_dma_parameters *cons)
 +{
 + cons-max_segment_count = (unsigned int)-1;
 + cons-max_segment_size = (unsigned int)-1;
 + cons-segment_boundary_mask = (unsigned long)-1;
 +}
Use DMA_SEGMENTS_MAX_SEG_COUNT or UINT/ULONG_MAX here instead?

Patches look sane,
Reviewed-By: Maarten Lankhorst maarten.lankho...@canonical.com
 +/*
 + * calc_constraints - calculates if the new attaching device's constraints
 + * match, with the constraints of already attached devices; if yes, returns
 + * the constraints; else return ERR_PTR(-EINVAL)
 + */
 +static int calc_constraints(struct device *dev,
 + struct device_dma_parameters *calc_cons)
 +{
 + struct device_dma_parameters cons = *calc_cons;
 +
 + cons.max_segment_count = min(cons.max_segment_count,
 + dma_get_max_seg_count(dev));
 + cons.max_segment_size = min(cons.max_segment_size,
 + dma_get_max_seg_size(dev));
 + cons.segment_boundary_mask = dma_get_seg_boundary(dev);
 +
 + if (!cons.max_segment_count ||
 + !cons.max_segment_size ||
 + !cons.segment_boundary_mask) {
 + pr_err(Dev: %s's constraints don't match\n, dev_name(dev));
 + return -EINVAL;
 + }
 +
 + *calc_cons = cons;
 +
 + return 0;
 +}
 +
 +/*
 + * recalc_constraints - recalculates constraints for all attached devices;
 + *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
 + *  helper.
 + *  Returns recalculated constraints in recalc_cons, or error in the unlikely
 + *  case when constraints of attached devices might have changed.
 + */
 +static int recalc_constraints(struct dma_buf *dmabuf,
 +   struct device_dma_parameters *recalc_cons)
 +{
 + struct device_dma_parameters calc_cons;
 + struct dma_buf_attachment *attach;
 + int ret = 0;
 +
 + init_constraints(calc_cons);
 +
 + list_for_each_entry(attach, dmabuf-attachments, node) {
 + ret = calc_constraints(attach-dev, calc_cons);
 + if (ret)
 + return ret;
 + }
 + *recalc_cons = calc_cons;
 + return 0;
 +}
 +
  /**
   * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
   * with this buffer, so it can be exported.
 @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
 struct dma_buf_ops *ops,
   dmabuf-ops = ops;
   dmabuf-size = size;
   dmabuf-exp_name = exp_name;
 +
 + init_constraints(dmabuf-constraints);
 +
   init_waitqueue_head(dmabuf-poll);
   dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
   dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
 @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,
 struct device *dev)
  {
   struct dma_buf_attachment *attach;
 - int ret;
 + int ret = 0;
  
   if (WARN_ON(!dmabuf || !dev))
   return ERR_PTR(-EINVAL);
 @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
 +/*
 + * recalc_constraints - recalculates constraints for all attached devices;
 + *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
 + *  helper.
 + *  Returns recalculated constraints in recalc_cons, or error in the unlikely
 + *  case when constraints of attached devices might have changed.
 + */

Please see kerneldoc documentation for the proper format of these comments.

 +static int recalc_constraints(struct dma_buf *dmabuf,
 +   struct device_dma_parameters *recalc_cons)
 +{
 + struct device_dma_parameters calc_cons;
 + struct dma_buf_attachment *attach;
 + int ret = 0;
 +
 + init_constraints(calc_cons);
 +
 + list_for_each_entry(attach, dmabuf-attachments, node) {
 + ret = calc_constraints(attach-dev, calc_cons);
 + if (ret)
 + return ret;
 + }
 + *recalc_cons = calc_cons;
 + return 0;
 +}
 +
  /**
   * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
   * with this buffer, so it can be exported.
 @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
 struct dma_buf_ops *ops,
   dmabuf-ops = ops;
   dmabuf-size = size;
   dmabuf-exp_name = exp_name;
 +
 + init_constraints(dmabuf-constraints);
 +
   init_waitqueue_head(dmabuf-poll);
   dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
   dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
 @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,
 struct device *dev)
  {
   struct dma_buf_attachment *attach;
 - int ret;
 + int ret = 0;
  
   if (WARN_ON(!dmabuf || !dev))
   return ERR_PTR(-EINVAL);
 @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,
  
   mutex_lock(dmabuf-lock);
  
 + if (calc_constraints(dev, dmabuf-constraints))
 + goto err_constraints;
 +
   if (dmabuf-ops-attach) {
   ret = dmabuf-ops-attach(dmabuf, dev, attach);
   if (ret)
 @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,
  
  err_attach:
   kfree(attach);
 +err_constraints:
   mutex_unlock(dmabuf-lock);
   return ERR_PTR(ret);
  }
 @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
 dma_buf_attachment *attach)
   if (dmabuf-ops-detach)
   dmabuf-ops-detach(dmabuf, attach);
  
 + recalc_constraints(dmabuf, dmabuf-constraints);
 +

To me, this whole thing seems horribly racy.

What happens if subsystem X creates a dmabuf, which is passed to
userspace. It's then passed to subsystem Y, which starts making use
of it, calling dma_buf_map_attachment() on it.

The same buffer is also passed (via unix domain sockets) to another
program, which then passes it independently into subsystem Z, and
subsystem Z has more restrictive DMA constraints.

What happens at this point?

Subsystems such as DRM cache the scatter table, and return it for
subsequent attach calls, so DRM drivers using the default
drm_gem_map_dma_buf() implementation would not see the restrictions
placed upon the dmabuf.  Moreover, the returned scatterlist would not
be modified for those restrictions either.

What would other subsystems do?

This needs more thought before it's merged.

For example, in the above situation, should we deny the ability to
create a new attachment when a dmabuf has already been mapped by an
existing attachment?  Should we deny it only when the new attachment
has more restrictive DMA constraints?

Please consider the possible sequences of use (such as the scenario
above) when creating or augmenting an API.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
 So, short answer is, it is left to the exporter to decide. The dma-buf
 framework should not even attempt to decide or enforce any of the
 above.
 
 At each dma_buf_attach(), there's a callback to the exporter, where
 the exporter can decide, if it intends to handle these kind of cases,
 on the best way forward.
 
 The exporter might, for example, decide to migrate backing storage,

That's a decision which the exporter can not take.  Think about it...

If subsystem Y has mapped the buffer, it could be accessing the buffer's
backing storage at the same time that subsystem Z tries to attach to the
buffer.

Once the buffer has been exported to another user, the exporter has
effectively lost control over mediating accesses to that buffer.

All that it can do with the way the dma-buf API is today is to allocate
a _different_ scatter list pointing at the same backing storage which
satisfies the segment size and number of segments, etc.

There's also another issue which you haven't addressed.  What if several
attachments result in lowering max_segment_size and max_segment_count
such that:

max_segment_size * max_segment_count  dmabuf-size

but individually, the attachments allow dmabuf-size to be represented
as a scatterlist?

If an exporter were to take notice of the max_segment_size and
max_segment_count, the resulting buffer is basically unrepresentable
as a scatterlist.

  Please consider the possible sequences of use (such as the scenario
  above) when creating or augmenting an API.
 
 
 I tried to think of the scenarios I could think of, but If you still
 feel this approach doesn't help with your concerns, I'll graciously
 accept advice to improve it.

See the new one above :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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] s5p-tv: hdmi needs I2C support

2015-01-29 Thread Arnd Bergmann

Building the s5p-tv HDMI support when CONFIG_I2C is disabled
gives us this build error:

s5p-tv/hdmi_drv.c: In function 'hdmi_probe':
s5p-tv/hdmi_drv.c:947:2: error: implicit declaration of function 
'i2c_get_adapter' [-Werror=implicit-function-declaration]
  adapter = i2c_get_adapter(pdata-hdmiphy_bus);
  ^

This patch changes the Kconfig description to include I2C
as a dependency for this driver, so it cannot be configured
incorrectly.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/drivers/media/platform/s5p-tv/Kconfig 
b/drivers/media/platform/s5p-tv/Kconfig
index 5a1835dd65e8..697aaed42486 100644
--- a/drivers/media/platform/s5p-tv/Kconfig
+++ b/drivers/media/platform/s5p-tv/Kconfig
@@ -20,6 +20,7 @@ if VIDEO_SAMSUNG_S5P_TV
 config VIDEO_SAMSUNG_S5P_HDMI
tristate Samsung HDMI Driver
depends on VIDEO_V4L2
+   depends on I2C
depends on VIDEO_SAMSUNG_S5P_TV
select VIDEO_SAMSUNG_S5P_HDMIPHY
help

--
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/8] WmT: document adi,adv7612

---
 Documentation/devicetree/bindings/media/i2c/adv7604.txt |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index bc50da2..1ca6e5a 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -1,4 +1,4 @@
-* Analog Devices ADV7604/11 video decoder with HDMI receiver
+* Analog Devices ADV7604/11/12 video decoder with HDMI receiver
 
 The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI
 receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input,
@@ -10,6 +10,7 @@ Required Properties:
 
   - compatible: Must contain one of the following
 - adi,adv7611 for the ADV7611
+- adi,adv7612 for the ADV7612
 
   - reg: I2C slave address
 
-- 
1.7.10.4

--
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] davinci: add V4L2 dependencies

2015-01-29 Thread Arnd Bergmann

The davinci media drivers use videobuf2, which they enable through
a 'select' statement. If one of these drivers is built-in, but
the v4l2 core is a loadable modules, we end up with a link
error:

drivers/built-in.o: In function `vb2_fop_mmap':
:(.text+0x113e84): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_create_bufs':
:(.text+0x114710): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_reqbufs':
:(.text+0x114ed8): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_querybuf':
:(.text+0x115530): undefined reference to `video_devdata'

To solve this, we need to add a dependency on VIDEO_V4L2,
which enforces that the davinci drivers themselves can only
be loadable modules if V4L2 is not built-in, and they do
not cause the videobuf2 code to be built-in.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/drivers/media/platform/davinci/Kconfig 
b/drivers/media/platform/davinci/Kconfig
index d9e1ddb586b1..469e9d28cec0 100644
--- a/drivers/media/platform/davinci/Kconfig
+++ b/drivers/media/platform/davinci/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_DAVINCI_VPIF_DISPLAY
tristate TI DaVinci VPIF V4L2-Display driver
-   depends on VIDEO_DEV
+   depends on VIDEO_V4L2
depends on ARCH_DAVINCI || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
@@ -16,7 +16,7 @@ config VIDEO_DAVINCI_VPIF_DISPLAY
 
 config VIDEO_DAVINCI_VPIF_CAPTURE
tristate TI DaVinci VPIF video capture driver
-   depends on VIDEO_DEV
+   depends on VIDEO_V4L2
depends on ARCH_DAVINCI || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
@@ -75,7 +75,7 @@ config VIDEO_DM365_ISIF
 
 config VIDEO_DAVINCI_VPBE_DISPLAY
tristate TI DaVinci VPBE V4L2-Display driver
-   depends on ARCH_DAVINCI
+   depends on VIDEO_V4L2  ARCH_DAVINCI
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
help

--
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: supporting adv7604.c under soc_camera/rcar_vin

  The following constitutes parts of our rcar_vin development branch
beyond the update to our hotfixes published earlier this month.
Similarly, these patches are intended to the mainline 3.18 kernel.
Further development is required, but we would like to highlight the
following issues and discuss them before completing the work.

1. Our internal review has noted that our use of v4l2_subdev_has_op()
is not yet ideal (but but does suffice for the purposes of generating
images as-is). These tests are intended to detect whether or not a
camera whose driver is aware of the pad API is present or not, and
ensure we interact with subdevices accordingly. We think we should be
iterating around all camera(s), and testing each subdevice link in
turn. Is this sound, or is there a better way?

2. Our second problem regards the supported formats list in adv7604.c,
which needs further attention. We believe that having entries that go
on to be rejected by rcar_vin_get_formats() may trigger a failure to
initialise cleanly. Workaround code is marked Ian Hack; we intend to
remove this and the list entries that cause this issue.

3. Our third problem concerns detecting the resolution of the stream.
Our code works with the obsoleted driver (adv761x.c) in place, but with
our modifications to adv7604.c we have seen a) recovery of a 640x480
image which is cropped rather than scaled, and/or b) recovery of a
2048x2048 image with the stream content in the top left corner. We
think we understand the former problem, but the latter seems to be
caused by full initialisation of the 'struct v4l2_subdev_format
sd_format' variable, and we only have a partial solution [included
as patch 4/8] so far. Of particular concern here is that potential
consequences of changes in this particular patch are not clear.


  Any advice would be appreciated, particularly regarding the first and
last point above.

Cheers,
  Wills.

  Associated patches:
[PATCH 1/8] Add ability to read default input port from DT
[PATCH 2/8] adv7604.c: formats, default colourspace, and IRQs
[PATCH 3/8] WmT: document adi,adv7612
[PATCH 4/8] WmT: m-5mols_core style pad handling for adv7604
[PATCH 5/8] media: rcar_vin: Add RGB888_1X24 input format support
[PATCH 6/8] WmT: adv7604 driver compatibility
[PATCH 7/8] WmT: rcar_vin new ADV7612 support
[PATCH 8/8] WmT: dts/i vin0/adv7612 (HDMI)
--
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 6/8] WmT: adv7604 driver compatibility

Add 'struct media_pad pad' member and suitable glue code, so that
soc_camera/rcar_vin can become agnostic to whether an old or new-
style driver (wrt pad API use) can sit underneath

This version has been reworked to include appropriate constant and
datatype names for kernel v3.18
---
 drivers/media/platform/soc_camera/soc_camera.c |  148 +++-
 drivers/media/platform/soc_camera/soc_scale_crop.c |   43 +-
 include/media/soc_camera.h |1 +
 3 files changed, 182 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..efc20bf 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -37,8 +37,11 @@
 #include media/v4l2-ioctl.h
 #include media/v4l2-dev.h
 #include media/v4l2-of.h
+#if 0
 #include media/videobuf-core.h
 #include media/videobuf2-core.h
+#endif
+#include media/v4l2-mediabus.h
 
 /* Default to VGA resolution */
 #define DEFAULT_WIDTH  640
@@ -453,6 +456,98 @@ static int soc_camera_expbuf(struct file *file, void *priv,
return vb2_expbuf(icd-vb2_vidq, p);
 }
 
+static int soc_camera_init_user_formats_pad(struct soc_camera_device *icd, int 
src_pad_idx)
+{
+   struct v4l2_subdev *sd= soc_camera_to_subdev(icd);
+   struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+   struct v4l2_subdev_mbus_code_enum code;
+   int fmts= 0, raw_fmts, i, ret;
+
+   code.pad= src_pad_idx;
+   code.index= 0;
+
+   // subdev_has_op - enum_mbus_code vs enum_mbus_fmt
+   if (v4l2_subdev_has_op(sd, pad, enum_mbus_code)) {
+   while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, code))
+   code.index++;
+   } else {
+   u32 pixcode;
+
+   while (!v4l2_subdev_call(sd, video, enum_mbus_fmt, code.index, 
pixcode))
+   {
+   code.code= pixcode;
+   code.index++;
+   }
+   }
+   raw_fmts= code.index;
+
+   if (!ici-ops-get_formats) {
+   /*
+* Fallback mode - the host will have to serve all
+* sensor-provided formats one-to-one to the user
+*/
+   fmts = raw_fmts;
+   }
+   else {
+   /*
+* First pass - only count formats this host-sensor
+* configuration can provide
+*/
+   for (i = 0; i  raw_fmts; i++) {
+   int ret = ici-ops-get_formats(icd, i, NULL);
+   if (ret  0)
+   return ret;
+   fmts += ret;
+   }
+   }
+
+   if (!fmts)
+   return -ENXIO;
+
+   icd-user_formats =
+   vmalloc(fmts * sizeof(struct soc_camera_format_xlate));
+   if (!icd-user_formats)
+   return -ENOMEM;
+
+   dev_dbg(icd-pdev, Found %d supported formats.\n, fmts);
+
+   /* Second pass - actually fill data formats */
+   fmts = 0;
+   for (i = 0; i  raw_fmts; i++) {
+   if (!ici-ops-get_formats) {
+   code.index= i;
+   // subdev_has_op - enum_mbus_code vs enum_mbus_fmt
+   if (v4l2_subdev_has_op(sd, pad, enum_mbus_code)) {
+   v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, 
code);
+   } else {
+   u32 pixcode;
+
+   v4l2_subdev_call(sd, video, enum_mbus_fmt, 
code.index, pixcode);
+   code.code= pixcode;
+   }
+   icd-user_formats[fmts].host_fmt =
+   soc_mbus_get_fmtdesc(code.code);
+   if (icd-user_formats[fmts].host_fmt)
+   icd-user_formats[fmts++].code = code.code;
+   } else {
+   ret = ici-ops-get_formats(icd, i,
+   icd-user_formats[fmts]);
+   if (ret  0)
+   goto egfmt;
+   fmts += ret;
+   }
+   }
+
+   icd-num_user_formats = fmts;
+   icd-current_fmt = icd-user_formats[0];
+
+   return 0;
+
+egfmt:
+   vfree(icd-user_formats);
+   return ret;
+}
+
 /* Always entered with .host_lock held */
 static int soc_camera_init_user_formats(struct soc_camera_device *icd)
 {
@@ -1289,6 +1384,7 @@ static int soc_camera_probe_finish(struct 
soc_camera_device *icd)
 {
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct v4l2_mbus_framefmt mf;
+   int src_pad_idx= -1;
int ret;
 
sd-grp_id = soc_camera_grp_id(icd);
@@ -1307,7 +1403,30 @@ static int soc_camera_probe_finish(struct 
soc_camera_device *icd)

[PATCH 1/8] Add ability to read default input port from DT

From: Ian Molton ian.mol...@codethink.co.uk

---
 Documentation/devicetree/bindings/media/i2c/adv7604.txt |3 +++
 drivers/media/i2c/adv7604.c |8 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..bc50da2 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -33,6 +33,9 @@ Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the device's reset pin.
 
+  - default-input: Reference to the chip's default input port. This value
+should match the pad number for the intended device
+
 Optional Endpoint Properties:
 
   The following three properties are defined in video-interfaces.txt and are
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e43dd2e..803 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2686,6 +2686,7 @@ static int adv7604_parse_dt(struct adv7604_state *state)
struct device_node *endpoint;
struct device_node *np;
unsigned int flags;
+   u32 v;
 
np = state-i2c_clients[ADV7604_PAGE_IO]-dev.of_node;
 
@@ -2695,6 +2696,12 @@ static int adv7604_parse_dt(struct adv7604_state *state)
return -EINVAL;
 
v4l2_of_parse_endpoint(endpoint, bus_cfg);
+
+   if (!of_property_read_u32(endpoint, default-input, v))
+   state-pdata.default_input = v;
+   else
+   state-pdata.default_input = -1;
+
of_node_put(endpoint);
 
flags = bus_cfg.bus.parallel.flags;
@@ -2733,7 +2740,6 @@ static int adv7604_parse_dt(struct adv7604_state *state)
/* Hardcode the remaining platform data fields. */
state-pdata.disable_pwrdnb = 0;
state-pdata.disable_cable_det_rst = 0;
-   state-pdata.default_input = -1;
state-pdata.blank_data = 1;
state-pdata.alt_data_sat = 1;
state-pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0;
-- 
1.7.10.4

--
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 8/8] WmT: dts/i vin0/adv7612 (HDMI)

---
 arch/arm/boot/dts/r8a7790-lager.dts |   51 +++
 1 file changed, 34 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index be44493..c20b6cb 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -249,9 +249,9 @@
renesas,function = usb2;
};
 
-   vin1_pins: vin {
-   renesas,groups = vin1_data8, vin1_clk;
-   renesas,function = vin1;
+   vin0_pins: vin0 {
+   renesas,groups = vin0_data24, vin0_sync, vin0_field, 
vin0_clkenb, vin0_clk;
+   renesas,function = vin0;
};
 };
 
@@ -391,15 +391,15 @@
pinctrl-0 = iic2_pins;
pinctrl-names = default;
 
-   composite-in@20 {
-   compatible = adi,adv7180;
-   reg = 0x20;
-   remote = vin1;
+   adv7612: adv7612@0x4c {
+   compatible = adi,adv7612;
+   reg = 0x4c;
+   remote = vin0;
 
port {
-   adv7180: endpoint {
-   bus-width = 8;
-   remote-endpoint = vin1ep0;
+   adv7612_1: endpoint {
+   remote-endpoint = vin0ep0;
+   default-input = 0;
};
};
};
@@ -419,6 +419,19 @@
i2c-gpio,delay-us = 1;/* ~100 kHz */
#address-cells = 1;
#size-cells = 0;
+
+   adv7612: adv7612@0x4c {
+   compatible = adi,adv7612;
+   reg = 0x4c;
+   remote = vin0;
+
+   port {
+   adv7612_1: endpoint {
+   remote-endpoint = vin0ep0;
+   default-input = 0;
+   };
+   };
+   };
};
 };
 #endif
@@ -457,9 +470,9 @@
pinctrl-names = default;
 };
 
-/* composite video input */
-vin1 {
-   pinctrl-0 = vin1_pins;
+/* HDMI video input */
+vin0 {
+   pinctrl-0 = vin0_pins;
pinctrl-names = default;
 
status = ok;
@@ -468,9 +481,13 @@
#address-cells = 1;
#size-cells = 0;
 
-   vin1ep0: endpoint {
-   remote-endpoint = adv7180;
-   bus-width = 8;
+   vin0ep0: endpoint {
+   remote-endpoint = adv7612_1;
+   bus-width = 24;
+   hsync-active = 0;
+   vsync-active = 0;
+   pclk-sample = 1;
+   data-active = 1;
};
};
-};
+};
\ No newline at end of file
-- 
1.7.10.4

--
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/8] adv7604.c: formats, default colourspace, and IRQs

** for lx3.18.x+; from previous description **

The original adv7612-specific driver only contained formats meeting
a certain specification; allowing the adv7612 chip to permit all the
formats the adv7611 supports breaks this restriction and means that
enum_mbus_code can end up containing values that cause problems with
frame capture.

...Specifically, introducing a fully identical supported formats list
breaks video capture for video/x-raw-rgb in particular unless the
code path in rcar_vin.c marked Ian HACK is present. Reducing the
list leads to the possibility of gstreamer creating zero-length files.

This patch enables the reduced list by default, and does not enable
the corresponding fixup hack.

Support for 'video/x-raw-yuv' is unaffected in either case.

WmT: rcar_vin.c adv7604 driver compatibility

Add 'struct media_pad pad' member and suitable glue code, so that
soc_camera/rcar_vin can become agnostic to whether an old or new-
style driver (wrt pad API use) can sit underneath

This version has been reworked to include appropriate constant and
datatype names for kernel v3.18
---
 drivers/media/i2c/adv7604.c |  148 ++-
 1 file changed, 145 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 803..30bbd9d 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -43,7 +43,18 @@
 #include media/v4l2-dv-timings.h
 #include media/v4l2-of.h
 
-static int debug;
+#if 1  /*  WmT: TESTING  */
+#define HAVE_ADV7612_FORMATS
+   /*  Possible issue: adv7604_formats[] is extensive, whereas
+   adv7612.c only had RGB888_1X24 (- V4L2_COLORSPACE_SRGB)
+   ...this doesn't cover MEDIA_BUS_FMT_YUYV8_2X8, which appears
+   to be the new default format. Forcing 'code' helps
+*/
+//define HAVE_ADV7611_EXTRA_FORMATS/* identical list to 7611 */
+//#define HAVE_ADV7604_EXTRA_FORMATS   /* - unsupported warnings */
+#endif
+
+static int debug = 0;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, debug level (0-2));
 
@@ -80,6 +91,7 @@ MODULE_LICENSE(GPL);
 enum adv7604_type {
ADV7604,
ADV7611,
+   ADV7612,
 };
 
 struct adv7604_reg_seq {
@@ -818,6 +830,73 @@ static const struct adv7604_format_info adv7611_formats[] 
= {
  ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_12BIT },
 };
 
+#ifdef HAVE_ADV7612_FORMATS
+static const struct adv7604_format_info adv7612_formats[] = {
+   { MEDIA_BUS_FMT_RGB888_1X24, ADV7604_OP_CH_SEL_RGB, true, false,
+ ADV7604_OP_MODE_SEL_SDR_444 | ADV7604_OP_FORMAT_SEL_8BIT },
+#ifdef HAVE_ADV7611_EXTRA_FORMATS  /* breaks without Ian HACK? */
+   { MEDIA_BUS_FMT_YUYV8_2X8, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+#endif
+   { MEDIA_BUS_FMT_YVYU8_2X8, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+#ifdef HAVE_ADV7604_EXTRA_FORMATS
+   /* 0x200b not in soc_mediabus.c mbus_fmt[] (07/01/2015) */
+   { MEDIA_BUS_FMT_YUYV10_2X10, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+   /* 0x200c not in soc_mediabus.c mbus_fmt[] (07/01/2015) */
+   { MEDIA_BUS_FMT_YVYU10_2X10, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+   /* 0x201e not in soc_mediabus.c mbus_fmt[] (07/01/2015) */
+   { MEDIA_BUS_FMT_YUYV12_2X12, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+   /* 0x201f not in soc_mediabus.c mbus_fmt[] (07/01/2015) */
+   { MEDIA_BUS_FMT_YVYU12_2X12, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+#endif
+   { MEDIA_BUS_FMT_UYVY8_1X16, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+   { MEDIA_BUS_FMT_VYUY8_1X16, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+#ifdef HAVE_ADV7611_EXTRA_FORMATS  /* inconsistent RGB - RGB without 
Ian HACK */
+   { MEDIA_BUS_FMT_YUYV8_1X16, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+   { MEDIA_BUS_FMT_YVYU8_1X16, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+#endif
+#ifdef HAVE_ADV7604_EXTRA_FORMATS
+   /* 0x201a not in soc_mediabus.c mbus_fmt[] (07/01/2015) */
+   { MEDIA_BUS_FMT_UYVY10_1X20, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+   /* 0x201b not in soc_mediabus.c mbus_fmt[] (07/01/2015) */
+   { MEDIA_BUS_FMT_VYUY10_1X20, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X

[PATCH 5/8] media: rcar_vin: Add RGB888_1X24 input format support

This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.

Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
URL:http://marc.info/?l=linux-shm=138002993417489q=raw
FIXMEs required:
- From: as per URL
- adapted for lx3.18 by William Towle - add S-o-b **
---
 drivers/media/platform/soc_camera/rcar_vin.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index c4f88c3..e4f60d3 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -74,6 +74,7 @@
 #define VNMC_INF_YUV10_BT656   (2  16)
 #define VNMC_INF_YUV10_BT601   (3  16)
 #define VNMC_INF_YUV16 (5  16)
+#define VNMC_INF_RGB888(6  16)
 #define VNMC_VUP   (1  10)
 #define VNMC_IM_ODD(0  3)
 #define VNMC_IM_ODD_EVEN   (1  3)
@@ -241,7 +242,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
struct soc_camera_device *icd = priv-ici.icd;
struct rcar_vin_cam *cam = icd-host_priv;
u32 vnmc, dmr, interrupts;
-   bool progressive = false, output_is_yuv = false;
+   bool progressive = false, output_is_yuv = false, input_is_yuv = false;
 
switch (priv-field) {
case V4L2_FIELD_TOP:
@@ -275,11 +276,16 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
+   input_is_yuv = true;
break;
case MEDIA_BUS_FMT_YUYV8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= priv-pdata_flags  RCAR_VIN_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
+   input_is_yuv = true;
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   vnmc |= VNMC_INF_RGB888;
break;
case MEDIA_BUS_FMT_YUYV10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
@@ -328,7 +334,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
vnmc |= VNMC_VUP;
 
/* If input and output use the same colorspace, use bypass mode */
-   if (output_is_yuv)
+   if (input_is_yuv == output_is_yuv)
vnmc |= VNMC_BPS;
 
/* progressive or interlaced mode */
@@ -1015,6 +1021,7 @@ static int rcar_vin_get_formats(struct soc_camera_device 
*icd, unsigned int idx,
case MEDIA_BUS_FMT_YUYV8_1X16:
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_YUYV10_2X10:
+   case MEDIA_BUS_FMT_RGB888_1X24:
if (cam-extra_fmt)
break;
 
-- 
1.7.10.4

--
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 7/8] WmT: rcar_vin new ADV7612 support

Add 'struct media_pad pad' member and suitable glue code, so that
soc_camera/rcar_vin can become agnostic to whether an old or new-
style driver (wrt pad API use) can sit underneath

This version has been reworked to include appropriate constant and
datatype names for kernel v3.18

---

** this version for kernel 3.18.x+ (v4l2 constant names) **
** now including: **
| WmT: assume max resolution at init
|
| Make rcar_vin agnostic to the driver beneath having a smaller
| resolution as its default size. Previously, the logic for calculating
| cropping region size -which depends on going from larger to smaller
| values- would have been confused by this.
---
 drivers/media/platform/soc_camera/rcar_vin.c |  112 +++---
 1 file changed, 101 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index e4f60d3..046fcc1 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -932,9 +932,27 @@ static int rcar_vin_get_formats(struct soc_camera_device 
*icd, unsigned int idx,
u32 code;
const struct soc_mbus_pixelfmt *fmt;
 
-   ret = v4l2_subdev_call(sd, video, enum_mbus_fmt, idx, code);
-   if (ret  0)
-   return 0;
+   // subdev_has_op - enum_mbus_code vs enum_mbus_fmt
+   if (v4l2_subdev_has_op(sd, pad, enum_mbus_code)) {
+   struct v4l2_subdev_mbus_code_enum c;
+
+   c.index = idx;
+
+   ret = v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, c);
+   if (ret  0)
+   return 0;
+
+#if 1  /*  ideal  */
+   code = c.code;
+#else  /*  Ian HACK - required with full(er) formats table  */
+   code = MEDIA_BUS_FMT_RGB888_1X24; //HACK
+#endif
+   }
+   else {
+   ret = v4l2_subdev_call(sd, video, enum_mbus_fmt, idx, code);
+   if (ret  0)
+   return 0;
+   }
 
fmt = soc_mbus_get_fmtdesc(code);
if (!fmt) {
@@ -948,11 +966,28 @@ static int rcar_vin_get_formats(struct soc_camera_device 
*icd, unsigned int idx,
 
if (!icd-host_priv) {
struct v4l2_mbus_framefmt mf;
+   struct v4l2_subdev_format sd_format;
struct v4l2_rect rect;
struct device *dev = icd-parent;
int shift;
 
-   ret = v4l2_subdev_call(sd, video, g_mbus_fmt, mf);
+   // subdev_has_op - get_fmt vs g_mbus_fmt
+   if (v4l2_subdev_has_op(sd, pad, get_fmt)) {
+   struct media_pad *remote_pad;
+
+   remote_pad= 
media_entity_remote_pad(icd-vdev-entity.pads[0]);
+   sd_format.pad= remote_pad-index;
+   sd_format.which=V4L2_SUBDEV_FORMAT_ACTIVE;
+
+   ret = v4l2_subdev_call(sd, pad, get_fmt, NULL,
+   sd_format);
+   mf= sd_format.format;
+   mf.width= VIN_MAX_WIDTH;
+   mf.height= VIN_MAX_HEIGHT;
+   }
+   else {
+   ret = v4l2_subdev_call(sd, video, g_mbus_fmt, mf);
+   }
if (ret  0)
return ret;
 
@@ -979,10 +1014,18 @@ static int rcar_vin_get_formats(struct soc_camera_device 
*icd, unsigned int idx,
 
mf.width = 1280  shift;
mf.height = 960  shift;
-   ret = v4l2_device_call_until_err(sd-v4l2_dev,
-soc_camera_grp_id(icd),
-video, s_mbus_fmt,
-mf);
+   // subdev_has_op - set_fmt vs s_mbus_fmt
+   if (v4l2_subdev_has_op(sd, pad, set_fmt)) {
+   ret = v4l2_device_call_until_err(sd-v4l2_dev,
+soc_camera_grp_id(icd),
+pad, set_fmt, NULL,
+sd_format);
+   } else {
+   ret = v4l2_device_call_until_err(sd-v4l2_dev,
+soc_camera_grp_id(icd),
+video, s_mbus_fmt,
+mf);
+   }
if (ret  0)
return ret;
}
@@ -1099,7 +1142,22 @@ static int rcar_vin_set_crop(struct soc_camera_device 
*icd,
/* On success cam_crop contains current camera crop */
 
/* Retrieve camera output window */
-   ret = v4l2_subdev_call(sd, video, g_mbus_fmt, mf);
+   // subdev_has_op - get_fmt vs g_mbus_fmt

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

2015-01-29 Thread Rob Clark

On Thu, Jan 29, 2015 at 10:47 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
 So, short answer is, it is left to the exporter to decide. The dma-buf
 framework should not even attempt to decide or enforce any of the
 above.

 At each dma_buf_attach(), there's a callback to the exporter, where
 the exporter can decide, if it intends to handle these kind of cases,
 on the best way forward.

 The exporter might, for example, decide to migrate backing storage,

 That's a decision which the exporter can not take.  Think about it...

 If subsystem Y has mapped the buffer, it could be accessing the buffer's
 backing storage at the same time that subsystem Z tries to attach to the
 buffer.

The *theory* is that Y is map/unmap'ing the buffer around each use, so
there will be some point where things could be migrated and remapped..
in practice, I am not sure that anyone is doing this yet.

Probably it would be reasonable if a more restrictive subsystem tried
to attach after the buffer was already allocated and mapped in a way
that don't meet the new constraints, then -EBUSY.

But from a quick look it seems like there needs to be a slight fixup
to not return 0 if calc_constraints() fails..

 Once the buffer has been exported to another user, the exporter has
 effectively lost control over mediating accesses to that buffer.

 All that it can do with the way the dma-buf API is today is to allocate
 a _different_ scatter list pointing at the same backing storage which
 satisfies the segment size and number of segments, etc.

 There's also another issue which you haven't addressed.  What if several
 attachments result in lowering max_segment_size and max_segment_count
 such that:

 max_segment_size * max_segment_count  dmabuf-size

 but individually, the attachments allow dmabuf-size to be represented
 as a scatterlist?

Quite possibly for some of these edge some of cases, some of the
dma-buf exporters are going to need to get more clever (ie. hand off
different scatterlists to different clients).  Although I think by far
the two common cases will be I can support anything via an iommu/mmu
and I need phys contig.

But that isn't an issue w/ dma-buf itself, so much as it is an issue
w/ drivers.  I guess there would be more interest in fixing up drivers
when actual hw comes along that needs it..

BR,
-R

 If an exporter were to take notice of the max_segment_size and
 max_segment_count, the resulting buffer is basically unrepresentable
 as a scatterlist.

  Please consider the possible sequences of use (such as the scenario
  above) when creating or augmenting an API.
 

 I tried to think of the scenarios I could think of, but If you still
 feel this approach doesn't help with your concerns, I'll graciously
 accept advice to improve it.

 See the new one above :)

 --
 FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
 according to speedtest.net.
--
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] staging: media: lirc: lirc_zilog: Fix for possible null pointer dereference

2015-01-29 Thread Rickard Strandqvist

Fix a possible null pointer dereference, there is
otherwise a risk of a possible null pointer dereference.

This was found using a static code analysis program called cppcheck

Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
 drivers/staging/media/lirc/lirc_zilog.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
index cc872fb..78ce3b0 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -1332,10 +1332,8 @@ static int close(struct inode *node, struct file *filep)
/* find our IR struct */
struct IR *ir = filep-private_data;
 
-   if (ir == NULL) {
-   dev_err(ir-l.dev, close: no private_data attached to the 
file!\n);
+   if (ir == NULL)
return -ENODEV;
-   }
 
atomic_dec(ir-open_count);
 
-- 
1.7.10.4

--
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 02/21] [media] coda: bitrate can only be set in kbps steps

2015-01-29 Thread Philipp Zabel

Am Donnerstag, den 29.01.2015, 16:34 +0100 schrieb Kamil Debski:
 Hi Philipp,
 
 Could you add a one sentence description for this patch?
 I know that it is really simple, but still the description is still
 necessary.
 
 Best wishes,

Will do, thanks.

regards
Philipp

--
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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
 Quite possibly for some of these edge some of cases, some of the
 dma-buf exporters are going to need to get more clever (ie. hand off
 different scatterlists to different clients).  Although I think by far
 the two common cases will be I can support anything via an iommu/mmu
 and I need phys contig.
 
 But that isn't an issue w/ dma-buf itself, so much as it is an issue
 w/ drivers.  I guess there would be more interest in fixing up drivers
 when actual hw comes along that needs it..

However, validating the attachments is the business of dma-buf.  This
is actual infrastructure, which should ensure some kind of sanity such
as the issues I've raised.

The whole we can push it onto our users is really on - what that
results in is the users ignoring most of the requirements and just doing
their own thing, which ultimately ends up with the whole thing turning
into a disgusting mess - one which becomes very difficult to fix later.

Now, if we're going to do the more clever thing you mention above,
that rather negates the point of this two-part patch set, which is to
provide the union of the DMA capabilities of all users.  A union in
that case is no longer sane as we'd be tailoring the SG lists to each
user.

If we aren't going to do the more clever thing, then yes, we need this
code to calculate that union, but we _also_ need it to do sanity checking
right from the start, and refuse conditions which ultimately break the
ability to make use of that union - in other words, when the union of
the DMA capabilities means that the dmabuf can't be represented.

Unless we do that, we'll just end up with random drivers interpreting
what they want from the DMA capabilities, and we'll have some drivers
exporting (eg) scatterlists which satisfy the maximum byte size of an
element, but ignoring the maximum number of entries or vice versa, and
that'll most probably hide the case of too small a union.

It really doesn't make sense to do both either: that route is even more
madness, because we'll end up with two classes of drivers - those which
use the union approach, and those which don't.

The KISS principle applies here.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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: [GIT FIXES FOR v3.19] smiapp compile fix for non-OF configuration

2015-01-29 Thread Mauro Carvalho Chehab

Em Tue, 27 Jan 2015 12:36:49 +0200
Sakari Ailus sakari.ai...@iki.fi escreveu:

 Hi Mauro,
 
 The recent smiapp OF support patches contained a small issue related to
 reading 64-bit numbers from the device tree, such that the compilation fails
 if CONFIG_OF is undefined.
 
 This patch provides a temporary fix to the matter. The proper one is to use
 of_property_read_u64_array(), but that's currently not exported. I've
 submitted a patch for that.

Didn't apply at fixes, so I applied it at the master development branch.

If this is really needed for 3.19, please backport against 3.19-rc6.

Regards,
Mauro

 
 Please pull.
 
 
 The following changes since commit e32b31ae45c18679c186e67aa41d0e2318cae487:
 
   [media] mb86a20s: remove unused debug modprobe parameter (2015-01-26 
 10:08:29 -0200)
 
 are available in the git repository at:
 
   ssh://linuxtv.org/git/sailus/media_tree.git smiapp-of-compile
 
 for you to fetch changes up to 45fe24236dd638b170a7ca91a3aa0e9b2b153889:
 
   smiapp: Don't compile of_read_number() if CONFIG_OF isn't defined 
 (2015-01-27 12:18:49 +0200)
 
 
 Sakari Ailus (1):
   smiapp: Don't compile of_read_number() if CONFIG_OF isn't defined
 
  drivers/media/i2c/smiapp/smiapp-core.c |4 
  1 file changed, 4 insertions(+)
 
--
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] gspca/touptek: Fix a few CodingStyle issues

2015-01-29 Thread Mauro Carvalho Chehab

Checkpatch complained about a few issues, like FSF address. Also,
multi-line comments are not following the Kernel CodingStyle.

While not too late, let's fix those issues.

Cc: John McMaster johndmcmas...@gmail.com
Cc: Hans de Goede hdego...@redhat.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/drivers/media/usb/gspca/touptek.c 
b/drivers/media/usb/gspca/touptek.c
index 8b7c01e4b772..7bac6bc96063 100644
--- a/drivers/media/usb/gspca/touptek.c
+++ b/drivers/media/usb/gspca/touptek.c
@@ -17,10 +17,6 @@
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
  */
 
 #include gspca.h
@@ -32,80 +28,80 @@ MODULE_DESCRIPTION(ToupTek UCMOS / Amscope MU microscope 
camera driver);
 MODULE_LICENSE(GPL);
 
 /*
-Exposure reg is linear with exposure time
-Exposure (sec), E (reg)
-0.000400, 0x0002
-0.001000, 0x0005
-0.005000, 0x0019
-0.02, 0x0064
-0.08, 0x0190
-0.40, 0x07D0
-1.00, 0x1388
-2.00, 0x2710
-
-Three gain stages
-0x1000: master channel enable bit
-0x007F: low gain bits
-0x0080: medium gain bit
-0x0100: high gain bit
-gain = enable * (1 + regH) * (1 + regM) * z * regL
-
-Gain implementation
-Want to do something similar to mt9v011.c's set_balance
-
-Gain does not vary with resolution (checked 640x480 vs 1600x1200)
-
-Constant derivation:
-
-Raw data:
-Gain,   GTOP,   B,   R,  GBOT
-1.00,   0x105C, 0x1068, 0x10C8, 0x105C
-1.20,   0x106E, 0x107E, 0x10D6, 0x106E
-1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0
-1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9
-1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2
-2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC
-2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5
-2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE
-2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7
-2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0
-3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5
-
-zR = 0.0069605943152454778
-   about 3/431 = 0.0069605568445475635
-zB = 0.0095695970695970703
-   about 6/627 = 0.0095693779904306216
-zG = 0.010889328063241107
-   about 6/551 = 0.010889292196007259
-about 10 bits for constant + 7 bits for value = at least 17 bit intermediate
-with 32 bit ints should be fine for overflow etc
-Essentially gains are in range 0-0x001FF
-
-However, V4L expects a main gain channel + R and B balance
-To keep things simple for now saturate the values of balance is too high/low
-This isn't really ideal but easy way to fit the Linux model
-
-Converted using gain model turns out to be quite linear:
-Gain, GTOP, B, R, GBOT
-1.00, 92, 104, 144, 92
-1.20, 110, 126, 172, 110
-1.40, 128, 148, 202, 128
-1.60, 146, 168, 230, 146
-1.80, 164, 188, 260, 164
-2.00, 184, 210, 288, 184
-2.20, 202, 230, 316, 202
-2.40, 220, 252, 348, 220
-2.60, 238, 272, 376, 238
-2.80, 256, 296, 404, 256
-3.00, 276, 316, 436, 276
-
-Maximum gain is 0x7FF * 2 * 2 = 0x1FFC (8188)
-or about 13 effective bits of gain
-The highest the commercial driver goes in my setup 436
-However, because could *maybe* damage circuits
-limit the gain until have a reason to go higher
-Solution: gain clipped and warning emitted
-*/
+ * Exposure reg is linear with exposure time
+ * Exposure (sec), E (reg)
+ * 0.000400, 0x0002
+ * 0.001000, 0x0005
+ * 0.005000, 0x0019
+ * 0.02, 0x0064
+ * 0.08, 0x0190
+ * 0.40, 0x07D0
+ * 1.00, 0x1388
+ * 2.00, 0x2710
+ *
+ * Three gain stages
+ * 0x1000: master channel enable bit
+ * 0x007F: low gain bits
+ * 0x0080: medium gain bit
+ * 0x0100: high gain bit
+ * gain = enable * (1 + regH) * (1 + regM) * z * regL
+ *
+ * Gain implementation
+ * Want to do something similar to mt9v011.c's set_balance
+ *
+ * Gain does not vary with resolution (checked 640x480 vs 1600x1200)
+ *
+ * Constant derivation:
+ *
+ * Raw data:
+ * Gain,   GTOP,   B,R,  GBOT
+ * 1.00,   0x105C, 0x1068, 0x10C8, 0x105C
+ * 1.20,   0x106E, 0x107E, 0x10D6, 0x106E
+ * 1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0
+ * 1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9
+ * 1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2
+ * 2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC
+ * 2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5
+ * 2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE
+ * 2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7
+ * 2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0
+ * 3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5
+ *
+ * zR = 0.0069605943152454778
+ * about 3/431 = 0.0069605568445475635
+ * zB = 0.0095695970695970703
+ * about 6/627 = 0.0095693779904306216
+ * zG = 0.010889328063241107
+ * about 6/551 = 0.010889292196007259
+ * about 10 bits for constant + 7 bits for value = at least 17 bit
+ * intermediate with 32 bit ints should be fine for overflow etc
+ * Essentially gains are in range 0-0x001FF
+ *
+ * However, V4L expects a main gain channel + R

Re: [PATCH 5/8] media: rcar_vin: Add RGB888_1X24 input format support

2015-01-29 Thread Guennadi Liakhovetski

On Thu, 29 Jan 2015, Sergei Shtylyov wrote:

 On 01/29/2015 11:19 PM, Guennadi Liakhovetski wrote:
 
  This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
  which is used by the ADV7612 chip.
 
  Signed-off-by: Valentine Barshak
  valentine.bars...@cogentembedded.com
 
  I wonder why it hasn't been merged still? It's pending since
 2013, and
 I'm
 seeing no objections to it...
 
Indeed, strange. I'm saving it for me to look at it for the next
merge...
and I'll double-check that series. Maybe the series had some objections,
 
   Indeed, I'm now seeing the patch #1 was objected to. Patch #2 has been
   merged somewhat later.
 
  Right, and since this RGB888 format support was needed for the ADV761X
  driver from patch #1, this patch wasn't merged either. Do you need it now
  for something different?
 
No, the same ADV7612 chip, just the different driver this time, it seems.

Right, I see now. [OT] The problem is - this is not the first time this is 
happening - I didn't get that thread in my INBOX, only in the mailing list 
folder. I subscribe the mailing list from a different email address, than 
the one I'm CC'ed at. So, I anyway should be getting 2 copies of all these 
mails. I received 2 copies of Sergei's mails, but the rest only once... 
Not in spam, not in logs - they just disappear. A day or two ago another 
similar thread also missed my INBOX... Investigating...

Thanks
Guennadi
--
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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

2015-01-29 Thread Rob Clark

On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
 Quite possibly for some of these edge some of cases, some of the
 dma-buf exporters are going to need to get more clever (ie. hand off
 different scatterlists to different clients).  Although I think by far
 the two common cases will be I can support anything via an iommu/mmu
 and I need phys contig.

 But that isn't an issue w/ dma-buf itself, so much as it is an issue
 w/ drivers.  I guess there would be more interest in fixing up drivers
 when actual hw comes along that needs it..

 However, validating the attachments is the business of dma-buf.  This
 is actual infrastructure, which should ensure some kind of sanity such
 as the issues I've raised.


My initial thought is for dma-buf to not try to prevent something than
an exporter can actually do.. I think the scenario you describe could
be handled by two sg-lists, if the exporter was clever enough.

That all said, I think probably all the existing exporters cache the
sg-list.  And I can't think of any actual hw which would hit this
problem that can be solved by multiple sg-lists for the same physical
memory.  (And the constraint calculation kind of assumes the end
result will be a single sg-list.)  So it seems reasonable to me to
check that max_segment_count * max_segment_size is not smaller than
the buffer.

If it was a less theoretical problem, I think I'd more inclined for a
way that the exporter could override the checks, or something along
those lines.

otoh, if the attachment is just not possible because the buffer has
been already allocated and mapped by someone with more relaxed
constraints.. then I think the driver should be the one returning the
error since dma-buf doesn't know this.

 The whole we can push it onto our users is really on - what that
 results in is the users ignoring most of the requirements and just doing
 their own thing, which ultimately ends up with the whole thing turning
 into a disgusting mess - one which becomes very difficult to fix later.

Ideally at some point, dma-mapping or some helpers would support
allocations matching constraints..  I think only actual gpu drivers
want to do crazy enough things that they'd want to bypass dma-mapping.
If everyone else can use dma-mapping and/or helpers then we make it
harder for drivers to do the wrong thing than to do the right thing.

 Now, if we're going to do the more clever thing you mention above,
 that rather negates the point of this two-part patch set, which is to
 provide the union of the DMA capabilities of all users.  A union in
 that case is no longer sane as we'd be tailoring the SG lists to each
 user.

It doesn't really negate.. a different sg list representing the same
physical memory cannot suddenly make the buffer physically contiguous
(from the perspective of memory)..

(unless we are not on the same page here, so to speak)

BR,
-R

 If we aren't going to do the more clever thing, then yes, we need this
 code to calculate that union, but we _also_ need it to do sanity checking
 right from the start, and refuse conditions which ultimately break the
 ability to make use of that union - in other words, when the union of
 the DMA capabilities means that the dmabuf can't be represented.

 Unless we do that, we'll just end up with random drivers interpreting
 what they want from the DMA capabilities, and we'll have some drivers
 exporting (eg) scatterlists which satisfy the maximum byte size of an
 element, but ignoring the maximum number of entries or vice versa, and
 that'll most probably hide the case of too small a union.

 It really doesn't make sense to do both either: that route is even more
 madness, because we'll end up with two classes of drivers - those which
 use the union approach, and those which don't.

 The KISS principle applies here.

 --
 FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
 according to speedtest.net.
--
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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
 On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  Now, if we're going to do the more clever thing you mention above,
  that rather negates the point of this two-part patch set, which is to
  provide the union of the DMA capabilities of all users.  A union in
  that case is no longer sane as we'd be tailoring the SG lists to each
  user.
 
 It doesn't really negate.. a different sg list representing the same
 physical memory cannot suddenly make the buffer physically contiguous
 (from the perspective of memory)..
 
 (unless we are not on the same page here, so to speak)

If we are really only interested in the physically contiguous vs
scattered differentiation, why can't this be just a simple flag?

I think I know where you're coming from on that distinction - most
GPUs can cope with their buffers being discontiguous in memory, but
scanout and capture hardware tends to need contiguous buffers.

My guess is that you're looking for some way that a GPU driver could
allocate a buffer, which can then be imported into the scanout
hardware - and when it is, the underlying backing store is converted
to a contiguous buffer.  Is that the usage scenario you're thinking
of?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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] staging: media: lirc: lirc_zilog: Fix for possible null pointer dereference

2015-01-29 Thread Valdis . Kletnieks

On Thu, 29 Jan 2015 19:48:08 +0100, Rickard Strandqvist said:
 Fix a possible null pointer dereference, there is
 otherwise a risk of a possible null pointer dereference.

 This was found using a static code analysis program called cppcheck

 Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
 ---
  drivers/staging/media/lirc/lirc_zilog.c |4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

   /* find our IR struct */
   struct IR *ir = filep-private_data;

 - if (ir == NULL) {
 - dev_err(ir-l.dev, close: no private_data attached to the 
 file!\n);

Yes, the dev_err() call is an obvious thinko.

However, I'm not sure whether removing it entirely is right either.  If
there *should* be a struct IR * passed there, maybe some other printk()
should be issued, or even a WARN_ON(!ir), or something?


pgpzWDpKVWXi_.pgp
Description: PGP signature

Re: [PATCH 5/8] media: rcar_vin: Add RGB888_1X24 input format support

2015-01-29 Thread Guennadi Liakhovetski

On Thu, 29 Jan 2015, Sergei Shtylyov wrote:

 Hello.
 
 On 01/29/2015 09:18 PM, Guennadi Liakhovetski wrote:
 
This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.
 
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
 
   I wonder why it hasn't been merged still? It's pending since 2013, and
   I'm
   seeing no objections to it...
 
  Indeed, strange. I'm saving it for me to look at it for the next merge...
  and I'll double-check that series. Maybe the series had some objections,
 
Indeed, I'm now seeing the patch #1 was objected to. Patch #2 has been
 merged somewhat later.

Right, and since this RGB888 format support was needed for the ADV761X 
driver from patch #1, this patch wasn't merged either. Do you need it now 
for something different?

Thanks
Guennadi
--
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/8] Add ability to read default input port from DT

2015-01-29 Thread Jean-Michel Hautbois

2015-01-29 17:19 GMT+01:00 William Towle william.to...@codethink.co.uk:
 From: Ian Molton ian.mol...@codethink.co.uk

 ---
  Documentation/devicetree/bindings/media/i2c/adv7604.txt |3 +++
  drivers/media/i2c/adv7604.c |8 +++-
  2 files changed, 10 insertions(+), 1 deletion(-)

Is this really passing through checkpatch ? Without a proper signed-off-by ?

 diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
 b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
 index c27cede..bc50da2 100644
 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
 +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
 @@ -33,6 +33,9 @@ Optional Properties:

- reset-gpios: Reference to the GPIO connected to the device's reset pin.

 +  - default-input: Reference to the chip's default input port. This value
 +should match the pad number for the intended device
 +
  Optional Endpoint Properties:

The following three properties are defined in video-interfaces.txt and are
 diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
 index e43dd2e..803 100644
 --- a/drivers/media/i2c/adv7604.c
 +++ b/drivers/media/i2c/adv7604.c
 @@ -2686,6 +2686,7 @@ static int adv7604_parse_dt(struct adv7604_state *state)
 struct device_node *endpoint;
 struct device_node *np;
 unsigned int flags;
 +   u32 v;

Could be named default_input ?

 np = state-i2c_clients[ADV7604_PAGE_IO]-dev.of_node;

 @@ -2695,6 +2696,12 @@ static int adv7604_parse_dt(struct adv7604_state 
 *state)
 return -EINVAL;

 v4l2_of_parse_endpoint(endpoint, bus_cfg);
 +
 +   if (!of_property_read_u32(endpoint, default-input, v))
 +   state-pdata.default_input = v;
 +   else
 +   state-pdata.default_input = -1;
 +

OK, so, whatever the value I put in DT, it will be put in the pdata ?
No test against max_port ?

 of_node_put(endpoint);

 flags = bus_cfg.bus.parallel.flags;
 @@ -2733,7 +2740,6 @@ static int adv7604_parse_dt(struct adv7604_state *state)
 /* Hardcode the remaining platform data fields. */
 state-pdata.disable_pwrdnb = 0;
 state-pdata.disable_cable_det_rst = 0;
 -   state-pdata.default_input = -1;
 state-pdata.blank_data = 1;
 state-pdata.alt_data_sat = 1;
 state-pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0;
 --
 1.7.10.4

 --
 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

JM
--
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/8] WmT: m-5mols_core style pad handling for adv7604

2015-01-29 Thread Jean-Michel Hautbois

First of all, this subject puzzles me... What means WmT ??

2015-01-29 17:19 GMT+01:00 William Towle william.to...@codethink.co.uk:
 ---
  drivers/media/i2c/adv7604.c |   12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

Again, it it passing checkpatch without signed-off-by ? And a little
description does not hurt :).

 diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
 index 30bbd9d..6ed9303 100644
 --- a/drivers/media/i2c/adv7604.c
 +++ b/drivers/media/i2c/adv7604.c
 @@ -1976,7 +1976,11 @@ static int adv7604_get_format(struct v4l2_subdev *sd, 
 struct v4l2_subdev_fh *fh,
 if (format-which == V4L2_SUBDEV_FORMAT_TRY) {
 struct v4l2_mbus_framefmt *fmt;

 -   fmt = v4l2_subdev_get_try_format(fh, format-pad);
 +   fmt = (fh == NULL) ? NULL
 +   : v4l2_subdev_get_try_format(fh, format-pad);
 +   if (fmt == NULL)
 +   return EINVAL;
 +

Mmmh, Hans probably has an explanation on this, I just don't get a use
case where fh can be NULL... So can't see the point of this patch ?

 format-format.code = fmt-code;
 } else {
 format-format.code = state-format-code;
 @@ -2008,7 +2012,11 @@ static int adv7604_set_format(struct v4l2_subdev *sd, 
 struct v4l2_subdev_fh *fh,
 if (format-which == V4L2_SUBDEV_FORMAT_TRY) {
 struct v4l2_mbus_framefmt *fmt;

 -   fmt = v4l2_subdev_get_try_format(fh, format-pad);
 +   fmt = (fh == NULL) ? NULL
 +   : v4l2_subdev_get_try_format(fh, format-pad);
 +   if (fmt == NULL)
 +   return -EINVAL;
 +
 fmt-code = format-format.code;
 } else {
 state-format = info;

Same comment as above.
Thanks,
JM
--
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: solo6x10: all interrupts for all cards handled by CPU0, no balancing - why?

2015-01-29 Thread Andrey Utkin

The host was rebooted and got back online.
Without irqbalance daemon, all solo6x10 interrupts are still on CPU0.
See https://gist.github.com/krieger-od/d1686243c67fbe3e14a5
Any ideas are strongly appreciated.


-- 
Andrey Utkin
--
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 5/8] media: rcar_vin: Add RGB888_1X24 input format support


On 01/29/2015 11:19 PM, Guennadi Liakhovetski wrote:


This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.



Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com



 I wonder why it hasn't been merged still? It's pending since 2013, and
I'm
seeing no objections to it...



Indeed, strange. I'm saving it for me to look at it for the next merge...
and I'll double-check that series. Maybe the series had some objections,



Indeed, I'm now seeing the patch #1 was objected to. Patch #2 has been
merged somewhat later.



Right, and since this RGB888 format support was needed for the ADV761X
driver from patch #1, this patch wasn't merged either. Do you need it now
for something different?


   No, the same ADV7612 chip, just the different driver this time, it seems.


Thanks
Guennadi


WBR, Sergei

--
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: [PULL patches for 3.20]: New gspca touptek driver, gspca fixes and sunxi-cir driver improvments

2015-01-29 Thread Mauro Carvalho Chehab

Em Thu, 15 Jan 2015 11:52:14 +0100
Hans de Goede hdego...@redhat.com escreveu:

 Hi Mauro,
 
 Note this pull-req superseeds my previous pull-req for 3.20 .

Hmm... I ended by applying the previous pull request. I was unable to see
what's new on this one. Please check if everything went fine.

Thanks!
Mauro

 
 Please pull from my tree for a new gspca touptek driver, various
 gspca fixes and some sunxi-cir driver improvments.
 
 The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f:
 
[media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA 
 (2014-12-23 16:28:09 -0200)
 
 are available in the git repository at:
 
git://linuxtv.org/hgoede/gspca.git media-for_v3.20
 
 for you to fetch changes up to e6a734195e2fbd9386aa58fe8931dd30c013f23e:
 
gspca: Fix underflow in vidioc_s_parm() (2015-01-15 11:46:17 +0100)
 
 
 Antonio Ospite (1):
gspca_stv06xx: enable button found on some Quickcam Express variant
 
 Hans Verkuil (1):
pwc: fix WARN_ON
 
 Hans de Goede (3):
rc: sunxi-cir: Add support for an optional reset controller
rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i
gspca: Fix underflow in vidioc_s_parm()
 
 Joe Howse (1):
gspca: Add high-speed modes for PS3 Eye camera
 
 John McMaster (1):
gspca_touptek: Add support for ToupTek UCMOS series USB cameras
 
   .../devicetree/bindings/media/sunxi-ir.txt |   4 +-
   drivers/media/rc/sunxi-cir.c   |  46 +-
   drivers/media/usb/gspca/Kconfig|  10 +
   drivers/media/usb/gspca/Makefile   |   2 +
   drivers/media/usb/gspca/gspca.c|   2 +-
   drivers/media/usb/gspca/ov534.c|  10 +-
   drivers/media/usb/gspca/stv06xx/stv06xx.c  |   4 +-
   drivers/media/usb/gspca/touptek.c  | 732 
 +
   drivers/media/usb/pwc/pwc-if.c |  12 +-
   9 files changed, 800 insertions(+), 22 deletions(-)
   create mode 100644 drivers/media/usb/gspca/touptek.c
 
 Thanks  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
--
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] add raw video support for Samsung SUR40 touchscreen

2015-01-29 Thread Florian Echtler

Hello again,

On 21.01.2015 14:29, Hans Verkuil wrote:
 On 01/21/15 14:28, Florian Echtler wrote:
 On 20.01.2015 14:06, Laurent Pinchart wrote:
 That depends on the platform and whether it can DMA to vmalloc'ed memory 
 :-) 
 To be totally safe I think vb2-dma-sg would be better, but I'm not sure 
 it's 
 worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway.
 The SUR40 sends raw video data without any headers over the bulk
 endpoint in blocks of 16k, so I'm assuming that in this specific case,
 vb2-dma-sg would be the most efficient choice?
I'm still having a couple of issues sorting out the correct way to
provide DMA access for my driver. I've integrated most of your
suggestions, but I still can't switch from dma-contig to dma-sg.

As far as I understood it, there is no further initialization required
besides using vb2_dma_sg_memops, vb2_dma_sg_init_ctx and
vb2_dma_sg_cleanup_ctx instead of the respective -contig- calls, correct?

However, as soon as I swap the relevant function calls, the video image
stays black and in dmesg, I get the following warning:

[ cut here ]
WARNING: CPU: 1 PID: 37 at
/home/kernel/COD/linux/drivers/usb/core/hcd.c:1504
usb_hcd_map_urb_for_dma+0x4eb/0x500()
transfer buffer not dma capable
Modules linked in: sur40(OE) videobuf2_dma_contig videobuf2_dma_sg
videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev
media dm_crypt joydev input_polldev wl(POE) snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel
snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_seq_midi
snd_seq_midi_event snd_rawmidi cfg80211 kvm_amd snd_seq kvm edac_core
serio_raw snd_seq_device btusb snd_timer edac_mce_amd snd ipmi_si
ipmi_msghandler k10temp sp5100_tco i2c_piix4 soundcore bnep 8250_fintek
shpchp tpm_infineon rfcomm bluetooth mac_hid parport_pc ppdev lp parport
hid_apple usbhid hid pata_acpi uas usb_storage amdkfd amd_iommu_v2
radeon psmouse pata_atiixp i2c_algo_bit ttm drm_kms_helper drm ahci
libahci r8169 mii [last unloaded: sur40]
CPU: 1 PID: 37 Comm: kworker/1:1 Tainted: P   OE
3.19.0-031900rc6-generic #201501261152
Hardware name: Samsung SUR40/SDNE-R78BA2-20, BIOS SDNE-R78BA2-2000
11/04/2011
Workqueue: events_freezable input_polled_device_work [input_polldev]
05e0 8801320c3aa8 817c4584 0007
8801320c3af8 8801320c3ae8 81076df7 
8800a71fa6c0 88013243f800 0010 0002
Call Trace:
[817c4584] dump_stack+0x45/0x57
[81076df7] warn_slowpath_common+0x97/0xe0
[81076ef6] warn_slowpath_fmt+0x46/0x50
[815aff0b] usb_hcd_map_urb_for_dma+0x4eb/0x500
[817d03b4] ? schedule_timeout+0x124/0x210
[815b0bd5] usb_hcd_submit_urb+0x135/0x1c0
[815b20a6] usb_submit_urb.part.8+0x1f6/0x580
[811bb542] ? vmap_pud_range+0x122/0x1c0
[815b2465] usb_submit_urb+0x35/0x80
[815b339a] usb_start_wait_urb+0x6a/0x170
[815b1cce] ? usb_alloc_urb+0x1e/0x50
[815b1cce] ? usb_alloc_urb+0x1e/0x50
[815b3570] usb_bulk_msg+0xd0/0x1a0
[c059a841] sur40_poll+0x561/0x5e0 [sur40]
[c016134b] input_polled_device_work+0x1b/0x30 [input_polldev]
[8108f6dd] process_one_work+0x14d/0x460
[810900bb] worker_thread+0x11b/0x3f0
[8108ffa0] ? create_worker+0x1e0/0x1e0
[81095cc9] kthread+0xc9/0xe0
[81095c00] ? flush_kthread_worker+0x90/0x90
[817d17fc] ret_from_fork+0x7c/0xb0
[81095c00] ? flush_kthread_worker+0x90/0x90
---[ end trace 30eaf6524fd028d3 ]---

Moreover, I'm getting the following test failure from v4l2-compliance:

Streaming ioctls:
test read/write: OK
test MMAP: OK
fail: v4l2-test-buffers.cpp(951): buf.qbuf(node)
fail: v4l2-test-buffers.cpp(994): setupUserPtr(node, q)
test USERPTR: FAIL
test DMABUF: Cannot test, specify --expbuf-device

Total: 45, Succeeded: 44, Failed: 1, Warnings: 0

Any suggestions how to deal with this?

Best regards, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



signature.asc
Description: OpenPGP digital signature

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2015-01-29 Thread Pavel Machek

Hi!

   This approach would require implementing additional mechanisms on
   both sides: LED Flash class core and a LED Flash class driver.
   In the former the sysfs attribute write permissions would have
   to be decided in the runtime and in the latter caching mechanism
  
  Write attributes at runtime? Why? We can emulate sane and consistent
  behaviour for all the controllers: read gives you list of faults,
  write clears it. We can do it for all the controllers.
  
  Only cost is few lines of code in the drivers where hardware clears
  faults at read.
 
 Please take the time to read this, and consider it.
 
 I'd say the cost is I2C register access, not so much a few lines added to
 the drivers. The functionality and behaviour between the flash controllers
 varies. They have different faults, presence of (some) faults may prevent
 strobing, some support reading the flash status and some don't.
 
 Some of the flash faults are mostly relevant in production testing, some can
 be used to find hardware issues during use (rare) and some are produced in
 common use (timeout, for instance).
 
 The V4L2 flash API defines that reading the faults clears them, but does not
 state whether presence of faults would prevent further use of the flash.
 This is flash controller chip specific.

Yeah, but we are discussing sysfs reads. V4L2 API can just behave differently.

 I think you *could* force a policy on the level of kernel API, for instance
 require that the user clears the faults before strobing again rather than
 relying on the chip requiring this instead.

Yes, we could do that.

 Most of the time there are no faults. When there are, they may appear at
 some point of time after the strobing, but how long? Probably roughly after
 the timeout period the flash should have faults available if there were any
 --- except if the strobe is external such as a sensor timed strobe. In that
 case the software running on the CPU has no knowledge when the flash is
 strobed nor when the faults should be read. So the requirement of checking
 the faults would probably have to be limited to software strobe only. The
 user would still have to be able to check the faults for externally strobed
 pulses. Would it be acceptable that the interface was different
 there?

Should the user just read the faults before scheduling next strobe?

 So, after the user has strobed, when the user should check the flash faults?
 After the timeout period has passed? Right before strobing again? If this
 was a requirement, it adds an additional I2C access to potentially the place
 which should absolutely have no extra delay --- the flash strobe time. This
 would be highly unwanted.

I'd do it before strobing again. Not neccessarily just before
strobing again (you claim it is slow ... is it really so slow it matters)?

 Finally, should the LED flash class enforce such a policy, would the V4L2
 flash API which is provided to the same devices be changed as well? I'm not
 against that if we have
 
   1) can come up with a good policy that is understood to be
  meaningful for all thinkable flash controller implementations and
 
   2) agreement the behaviour can be changed.

I am saying that reading from /sys should not have side effects. For
V4L2, existing behaviour might be ok.

Each driver should have two operations: read_faults() and
clear_faults().

On devices where i2c read clears faults, operations will be:

int my_faults

read_faults()
my_faults |= read_i2c_faults()
return my_faults

clear_faults()
my_faults = 0

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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

solo6x10: all interrupts for all cards handled by CPU0, no balancing - why?

2015-01-29 Thread Andrey Utkin

Hi, having another card freeze issue with linux-next (tag
next-20150128) on a server running 3 solo6110 cards. The freeze
happens after 3 days or so. Much better than 30 minutes, which was the
case before the recent enhancement by Krzysztof Halasa.
This is Ubuntu Trusty. There's /usr/sbin/irqbalance process running.
See interrupt stats here:
https://gist.github.com/krieger-od/f8d99080d6fc30dad3d2
I wonder why all solo6x10 interrupts happen on CPU0, while there are 3
more cores.

However, I have got an idea reading this:
Irqbalance is a daemon to help balance the cpu load generated by interrupts
across all of a systems cpus.  Irqbalance identifies the highest volume
interrupt sources, and isolates them to a single unique cpu, so that load is
spread as much as possible over an entire processor set, while minimizing cache
hit rates for irq handlers.

Disabled irqbalance launch on boot. Rebooted, and the host got down up to now :(
Any comments, except laugh? :)

-- 
Andrey Utkin
--
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

[linuxtv-media:master 66/173] drivers/media/platform/am437x/am437x-vpfe.c:2767:3-8: No need to set .owner here. The core will do it.

2015-01-29 Thread kbuild test robot

tree:   git://linuxtv.org/media_tree.git master
head:   a5f43c18fceb2b96ec9fddb4348f5282a71cf2b0
commit: 417d2e507edcb5cf15eb344f86bd3dd28737f24e [66/173] [media] media: 
platform: add VPFE capture driver support for AM437X


coccinelle warnings: (new ones prefixed by )

 drivers/media/platform/am437x/am437x-vpfe.c:2767:3-8: No need to set .owner 
 here. The core will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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] media: platform: fix platform_no_drv_owner.cocci warnings

2015-01-29 Thread kbuild test robot

drivers/media/platform/am437x/am437x-vpfe.c:2767:3-8: No need to set .owner 
here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Benoit Parrot bpar...@ti.com
Signed-off-by: Fengguang Wu fengguang...@intel.com
---

 am437x-vpfe.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -2764,7 +2764,6 @@ static struct platform_driver vpfe_drive
.remove = vpfe_remove,
.driver = {
.name   = VPFE_MODULE_NAME,
-   .owner  = THIS_MODULE,
.pm = vpfe_pm_ops,
.of_match_table = of_match_ptr(vpfe_of_match),
},
--
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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

2015-01-29 Thread Rob Clark

On Thu, Jan 29, 2015 at 5:31 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
 On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  Now, if we're going to do the more clever thing you mention above,
  that rather negates the point of this two-part patch set, which is to
  provide the union of the DMA capabilities of all users.  A union in
  that case is no longer sane as we'd be tailoring the SG lists to each
  user.

 It doesn't really negate.. a different sg list representing the same
 physical memory cannot suddenly make the buffer physically contiguous
 (from the perspective of memory)..

 (unless we are not on the same page here, so to speak)

 If we are really only interested in the physically contiguous vs
 scattered differentiation, why can't this be just a simple flag?

I'd be fine with that..  I was trying to make it a bit less of a point
solution, but maybe trying to be too generic is not worth it..

There is apparently some hw which has iommu's but small # of tlb
entries, and would prefer partially contiguous buffers.  But that
isn't a hard constraint, and maybe shouldn't be solved w/
max_segment_count.  And I'm not sure how common that is.

 I think I know where you're coming from on that distinction - most
 GPUs can cope with their buffers being discontiguous in memory, but
 scanout and capture hardware tends to need contiguous buffers.

 My guess is that you're looking for some way that a GPU driver could
 allocate a buffer, which can then be imported into the scanout
 hardware - and when it is, the underlying backing store is converted
 to a contiguous buffer.  Is that the usage scenario you're thinking
 of?

Pretty much..  and maybe a few slight permutations on that involving
cameras / video codecs / etc.  But the really-really common case is
gpu (with mmu/iommu) + display (without).  Just solving this problem
would be a really good first step.

BR,
-R


 --
 FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
 according to speedtest.net.
--
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: ERRORS

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:   Fri Jan 30 04:00:23 CET 2015
git branch: test
git hash:   a5f43c18fceb2b96ec9fddb4348f5282a71cf2b0
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-41-g6c2d743
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:3.18.0-1.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: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: ERRORS
linux-2.6.33.7-i686: ERRORS
linux-2.6.34.7-i686: ERRORS
linux-2.6.35.9-i686: ERRORS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: 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-i686: OK
linux-3.17.8-i686: OK
linux-3.18-i686: OK
linux-3.19-rc4-i686: OK
linux-2.6.32.27-x86_64: ERRORS
linux-2.6.33.7-x86_64: ERRORS
linux-2.6.34.7-x86_64: ERRORS
linux-2.6.35.9-x86_64: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: 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-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18-x86_64: OK
linux-3.19-rc4-x86_64: OK
apps: OK
spec-git: OK
sparse: ERRORS
ABI WARNING: change for mips
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.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

Re: [PATCH] [media] media: platform: fix platform_no_drv_owner.cocci warnings