Re: [PATCH] TW686x: Fix OOPS on buffer alloc failure
Hans Verkuil writes: > Any progress on this? I gather I can expect a new patch from someone? Well, the issue is trivial and very easy to test, though not present on common x86 hw. That patch I've sent fixes it, but I'm not the one who decides. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH 1/6] v4l: vsp1: Remove WPF vertical flip support on VSP2-B[CD] and VSP2-D
On 06/19/17 13:18, Hans Verkuil wrote: > On 06/19/2017 01:16 PM, Laurent Pinchart wrote: >> Hi Hans, >> >> On Thursday 15 Jun 2017 10:53:33 Hans Verkuil wrote: >>> On 06/15/17 10:24, Laurent Pinchart wrote: The WPF vertical flip is only supported on Gen3 SoCs on the VSP2-I. Don't enable it on other VSP2 instances. Signed-off-by: Laurent Pinchart >>> >>> Should this go to older kernels as well? Or is that not needed? >> >> Now that I have access to the hardware again, after further testing, it looks >> like vertical flip is implemented in the VSP2-B[CD] and VSP2-D even though >> the >> datasheet states otherwise. Let's ignore this patch for now, I'll try to >> double-check with Renesas. > > Patches 2-6 are OK, though? If they are, then I'll pick them up. Ping! Please let me know if patches 2-6 are OK for me to pick up. I'll make a final pull request today, after that they'll be postponed until 4.14. Regards, Hans
Re: [PATCH] [media] em28xx TerraTec Cinergy Hybrid T USB XS with demodulator MT352 is not detect by em28xx
Hi Giovanni,
On 06/10/17 09:13, juv...@caramail.fr wrote:
> TerraTec Cinergy Hybrid T USB XS with demodulator MT352 stop working with
> kernel 3.xx and newer.
> I have already sent this patch without a success reply, I hope this time you
> can accept it.
>
> --- /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c.orig
> 2014-05-06 16:59:58.0 +0200
> +++ /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c
> 2014-05-07 15:18:31.719524453 +0200
> @@ -2233,7 +2233,7 @@
> { USB_DEVICE(0x0ccd, 0x005e),
> .driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
> { USB_DEVICE(0x0ccd, 0x0042),
> - .driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
> + .driver_info = EM2880_BOARD_TERRATEC_HYBRID_XS },
> { USB_DEVICE(0x0ccd, 0x0043),
> .driver_info = EM2870_BOARD_TERRATEC_XS },
> { USB_DEVICE(0x0ccd, 0x008e), /* Cinergy HTC USB XS Rev. 1 */
>
> This patch is working also on kernel 4.xx I have tested kernel 4.3 and 4.9
I checked the commit that changed the original EM2880_BOARD_TERRATEC_HYBRID_XS
to EM2882_BOARD_TERRATEC_HYBRID_XS and it says this:
commit 9124544320bd36d5aa21769d17a5781ba729aebf
Author: Philippe Bourdin
Date: Sun Oct 31 09:57:58 2010 -0300
[media] Terratec Cinergy Hybrid T USB XS
I found that the problems people have reported with the USB-TV-stick
"Terratec Cinergy Hybrid T USB XS" (USB-ID: 0ccd:0042)
are coming from a wrong header file in the v4l-sources.
Attached is a diff, which fixes the problem (tested successfully here).
Obviously the USB-ID has been associated with a wrong chip: EM2880
instead of EM2882, which would be correct.
Reported-by: Philippe Bourdin
Signed-off-by: Mauro Carvalho Chehab
So it looks like there are two variants with the same USB ID: one uses
the EM2880, one uses the EM2882. Since nobody else complained I expect
that most devices with this USB ID are in fact using the EM2882.
I won't apply this patch, since that would break it for others.
The best solution for you is to explicitly set the card using the
'card=11' em28xx module option.
I've CC-ed Mauro in case he knows a better solution.
Regards,
Hans
Re: [PATCH v2 2/3] [media] coda: first step at error recovery
On 06/08/17 10:55, Philipp Zabel wrote:
> From: Lucas Stach
>
> This implements a simple handler for the case where decode did not finish
> successfully. This might be helpful during normal streaming, but for now it
> only handles the case where the context would deadlock with userspace,
> i.e. userspace issued DEC_CMD_STOP and waits for EOS, but after the failed
> decode run we would hold the context and wait for userspace to queue more
> buffers.
>
> Signed-off-by: Lucas Stach
> Reviewed-by: Philipp Zabel
> [p.za...@pengutronix.de: renamed error_decode/run to run/decode_timeout]
> Signed-off-by: Philipp Zabel
> ---
> Changes since v1 [1]:
> - Rename error_run/decode callback to run/decode_timeout, as
> this error handler is called on device_run timeouts only.
>
> [1] https://patchwork.linuxtv.org/patch/40603
It appears the v1 version was merged, not the v2. I'm not sure if the v2 version
was posted after v1 was already merged, or if I missed this v2 series.
I'm marking this as Obsoleted, and if you want to still get these v2 changes
in, then please post a new patch.
Sorry for the mix up,
Hans
> ---
> drivers/media/platform/coda/coda-bit.c| 20
> drivers/media/platform/coda/coda-common.c | 3 +++
> drivers/media/platform/coda/coda.h| 1 +
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/media/platform/coda/coda-bit.c
> b/drivers/media/platform/coda/coda-bit.c
> index 325035bb0a777..795b6d7584320 100644
> --- a/drivers/media/platform/coda/coda-bit.c
> +++ b/drivers/media/platform/coda/coda-bit.c
> @@ -2198,12 +2198,32 @@ static void coda_finish_decode(struct coda_ctx *ctx)
> ctx->display_idx = display_idx;
> }
>
> +static void coda_decode_timeout(struct coda_ctx *ctx)
> +{
> + struct vb2_v4l2_buffer *dst_buf;
> +
> + /*
> + * For now this only handles the case where we would deadlock with
> + * userspace, i.e. userspace issued DEC_CMD_STOP and waits for EOS,
> + * but after a failed decode run we would hold the context and wait for
> + * userspace to queue more buffers.
> + */
> + if (!(ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG))
> + return;
> +
> + dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + dst_buf->sequence = ctx->qsequence - 1;
> +
> + coda_m2m_buf_done(ctx, dst_buf, VB2_BUF_STATE_ERROR);
> +}
> +
> const struct coda_context_ops coda_bit_decode_ops = {
> .queue_init = coda_decoder_queue_init,
> .reqbufs = coda_decoder_reqbufs,
> .start_streaming = coda_start_decoding,
> .prepare_run = coda_prepare_decode,
> .finish_run = coda_finish_decode,
> + .run_timeout = coda_decode_timeout,
> .seq_end_work = coda_seq_end_work,
> .release = coda_bit_release,
> };
> diff --git a/drivers/media/platform/coda/coda-common.c
> b/drivers/media/platform/coda/coda-common.c
> index 78bd9a4ace0e4..829c7895a98a2 100644
> --- a/drivers/media/platform/coda/coda-common.c
> +++ b/drivers/media/platform/coda/coda-common.c
> @@ -1163,6 +1163,9 @@ static void coda_pic_run_work(struct work_struct *work)
> ctx->hold = true;
>
> coda_hw_reset(ctx);
> +
> + if (ctx->ops->run_timeout)
> + ctx->ops->run_timeout(ctx);
> } else if (!ctx->aborting) {
> ctx->ops->finish_run(ctx);
> }
> diff --git a/drivers/media/platform/coda/coda.h
> b/drivers/media/platform/coda/coda.h
> index 76d059431ca13..c5f504d8cf67f 100644
> --- a/drivers/media/platform/coda/coda.h
> +++ b/drivers/media/platform/coda/coda.h
> @@ -183,6 +183,7 @@ struct coda_context_ops {
> int (*start_streaming)(struct coda_ctx *ctx);
> int (*prepare_run)(struct coda_ctx *ctx);
> void (*finish_run)(struct coda_ctx *ctx);
> + void (*run_timeout)(struct coda_ctx *ctx);
> void (*seq_end_work)(struct work_struct *work);
> void (*release)(struct coda_ctx *ctx);
> };
>
[PATCH] dt-bindings: media: Add r8a7796 DRIF bindings
Add r8a7796 DRIF bindings. Signed-off-by: Ramesh Shanmugasundaram --- Hi DT & Media maintainers, All, This patch adds DRIF bindings for R8A7796 SoC. It is based on media_tree - commit 76724b30f222 Thanks, Ramesh. Documentation/devicetree/bindings/media/renesas,drif.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt b/Documentation/devicetree/bindings/media/renesas,drif.txt index 39516b94c28f..0d8974aa8b38 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.txt +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt @@ -40,6 +40,7 @@ To summarize, Required properties of an internal channel: --- - compatible: "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 SoC. + "renesas,r8a7796-drif" if DRIF controller is a part of R8A7796 SoC. "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible device. When compatible with the generic version, nodes must list the -- 2.12.2
Re: [PATCH v2 2/3] [media] coda: first step at error recovery
On Fri, 2017-06-23 at 11:29 +0200, Hans Verkuil wrote: > On 06/08/17 10:55, Philipp Zabel wrote: > > From: Lucas Stach > > > > This implements a simple handler for the case where decode did not finish > > successfully. This might be helpful during normal streaming, but for now it > > only handles the case where the context would deadlock with userspace, > > i.e. userspace issued DEC_CMD_STOP and waits for EOS, but after the failed > > decode run we would hold the context and wait for userspace to queue more > > buffers. > > > > Signed-off-by: Lucas Stach > > Reviewed-by: Philipp Zabel > > [p.za...@pengutronix.de: renamed error_decode/run to run/decode_timeout] > > Signed-off-by: Philipp Zabel > > --- > > Changes since v1 [1]: > > - Rename error_run/decode callback to run/decode_timeout, as > > this error handler is called on device_run timeouts only. > > > > [1] https://patchwork.linuxtv.org/patch/40603 > > It appears the v1 version was merged, not the v2. I'm not sure if the v2 > version > was posted after v1 was already merged, or if I missed this v2 series. > > I'm marking this as Obsoleted, and if you want to still get these v2 changes > in, then please post a new patch. > > Sorry for the mix up, Thank you for the heads up, I'll send a patch. regards Philipp
[PATCH] [media] coda: rename the picture run timeout error handler
I would have liked the the picture run timeout error handler to be renamed to
something a bit more descriptive in the original commit fb2be08f8cb3 ("[media]
coda: first step at error recovery").
Somehow v1 [1] was merged instead of v2 [2].
[1] https://patchwork.kernel.org/patch/9663965/
[2] https://patchwork.kernel.org/patch/9774239/
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-bit.c| 4 ++--
drivers/media/platform/coda/coda-common.c | 4 ++--
drivers/media/platform/coda/coda.h| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 25cbf9e5ac5a7..795b6d7584320 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2198,7 +2198,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
ctx->display_idx = display_idx;
}
-static void coda_error_decode(struct coda_ctx *ctx)
+static void coda_decode_timeout(struct coda_ctx *ctx)
{
struct vb2_v4l2_buffer *dst_buf;
@@ -2223,7 +2223,7 @@ const struct coda_context_ops coda_bit_decode_ops = {
.start_streaming = coda_start_decoding,
.prepare_run = coda_prepare_decode,
.finish_run = coda_finish_decode,
- .error_run = coda_error_decode,
+ .run_timeout = coda_decode_timeout,
.seq_end_work = coda_seq_end_work,
.release = coda_bit_release,
};
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index f92cc7df58fb8..829c7895a98a2 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1164,8 +1164,8 @@ static void coda_pic_run_work(struct work_struct *work)
coda_hw_reset(ctx);
- if (ctx->ops->error_run)
- ctx->ops->error_run(ctx);
+ if (ctx->ops->run_timeout)
+ ctx->ops->run_timeout(ctx);
} else if (!ctx->aborting) {
ctx->ops->finish_run(ctx);
}
diff --git a/drivers/media/platform/coda/coda.h
b/drivers/media/platform/coda/coda.h
index 40fe22f0d7573..c5f504d8cf67f 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -183,7 +183,7 @@ struct coda_context_ops {
int (*start_streaming)(struct coda_ctx *ctx);
int (*prepare_run)(struct coda_ctx *ctx);
void (*finish_run)(struct coda_ctx *ctx);
- void (*error_run)(struct coda_ctx *ctx);
+ void (*run_timeout)(struct coda_ctx *ctx);
void (*seq_end_work)(struct work_struct *work);
void (*release)(struct coda_ctx *ctx);
};
--
2.11.0
[PATCH] [media] coda: add h264 and mpeg4 profile and level controls
CODA7541 supports H.264 BP level 3/3.1 and MPEG-4 SP level 5/6.
CODA960 supports H.264 BP level 4.0 and MPEG-4 SP level 5/6.
Implement the necessary profile and level controls to let userspace know
this.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 829c7895a98a2..d119b47773282 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1683,12 +1683,23 @@ static int coda_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->params.h264_deblk_enabled = (ctrl->val ==
V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_ENABLED);
break;
+ case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
+ /* TODO: switch between baseline and constrained baseline */
+ ctx->params.h264_profile_idc = 66;
+ break;
+ case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
+ /* nothing to do, this is set by the encoder */
+ break;
case V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP:
ctx->params.mpeg4_intra_qp = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP:
ctx->params.mpeg4_inter_qp = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
+ /* nothing to do, these are fixed */
+ break;
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE:
ctx->params.slice_mode = ctrl->val;
break;
@@ -1756,11 +1767,47 @@ static void coda_encode_ctrls(struct coda_ctx *ctx)
V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE,
V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_DISABLED, 0x0,
V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_ENABLED);
+ v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_H264_PROFILE,
+ V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE, 0x0,
+ V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE);
+ if (ctx->dev->devtype->product == CODA_7541) {
+ v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_H264_LEVEL,
+ V4L2_MPEG_VIDEO_H264_LEVEL_3_1,
+ ~((1 << V4L2_MPEG_VIDEO_H264_LEVEL_2_0) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_0) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_1)),
+ V4L2_MPEG_VIDEO_H264_LEVEL_3_1);
+ }
+ if (ctx->dev->devtype->product == CODA_960) {
+ v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_H264_LEVEL,
+ V4L2_MPEG_VIDEO_H264_LEVEL_4_0,
+ ~((1 << V4L2_MPEG_VIDEO_H264_LEVEL_2_0) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_0) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_1) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_2) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_4_0)),
+ V4L2_MPEG_VIDEO_H264_LEVEL_4_0);
+ }
v4l2_ctrl_new_std(&ctx->ctrls, &coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP, 1, 31, 1, 2);
v4l2_ctrl_new_std(&ctx->ctrls, &coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP, 1, 31, 1, 2);
v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE,
+ V4L2_MPEG_VIDEO_MPEG4_PROFILE_SIMPLE, 0x0,
+ V4L2_MPEG_VIDEO_MPEG4_PROFILE_SIMPLE);
+ if (ctx->dev->devtype->product == CODA_7541 ||
+ ctx->dev->devtype->product == CODA_960) {
+ v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL,
+ V4L2_MPEG_VIDEO_MPEG4_LEVEL_5,
+ ~(1 << V4L2_MPEG_VIDEO_MPEG4_LEVEL_5),
+ V4L2_MPEG_VIDEO_MPEG4_LEVEL_5);
+ }
+ v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE,
V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES, 0x0,
V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE);
--
2.11.0
Re: [PATCH v1 0/6] Add support of OV9655 camera
Hi Hugues, > Am 22.06.2017 um 17:41 schrieb H. Nikolaus Schaller : > > >> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet : >> >> This patchset enables OV9655 camera support. >> >> OV9655 support has been tested using STM32F4DIS-CAM extension board >> plugged on connector P1 of STM32F746G-DISCO board. >> Due to lack of OV9650/52 hardware support, the modified related code >> could not have been checked for non-regression. >> >> First patches upgrade current support of OV9650/52 to prepare then >> introduction of OV9655 variant patch. >> Because of OV9655 register set slightly different from OV9650/9652, >> not all of the driver features are supported (controls). Supported >> resolutions are limited to VGA, QVGA, QQVGA. >> Supported format is limited to RGB565. >> Controls are limited to color bar test pattern for test purpose. >> >> OV9655 initial support is based on a driver written by H. Nikolaus Schaller >> [1]. > > Great! Thanks again for picking up or work and trying to get it upstream. > > I will test as soon as possible. I have tried and had to fix some issues first: * gpio properties have a different name than in our approach (but that is something maintainers have to decide and is easy to follow this or that way) * there is no clock-frequency property which makes the driver request a clock frequency (something our camera interface expects this way) * there is no vana-supply regulator and we need that to power on/off the camera on demand (reset and pwdn isn't enough in our hardware) * for some unknown reason the driver does not load automatically from DT compatibility string and needs to be explicitly modprobed * unfortunately we still get no image :( The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and sync are correct. But we do not know since mplayer only shows a green screen. Therefore we had not submitted anything upstream ourselves, because our driver setup isn't finished and completely working. I have written some more specific comments linked to proposals for patches as answer to your [PATCH v1 1/6] BR and thanks, Nikolaus
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi Hugues,
> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
>
> From: "H. Nikolaus Schaller"
>
> This adds documentation of device tree bindings
> for the OV965X family camera sensor module.
>
> Signed-off-by: H. Nikolaus Schaller
> Signed-off-by: Hugues Fruchet
> ---
> .../devicetree/bindings/media/i2c/ov965x.txt | 37 ++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> new file mode 100644
> index 000..0e0de1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> @@ -0,0 +1,37 @@
> +* Omnivision OV9650/9652/9655 CMOS sensor
> +
> +The Omnivision OV965x sensor support multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> +output format.
> +
> +Required Properties:
> +- compatible: should be one of
> + "ovti,ov9650"
> + "ovti,ov9652"
> + "ovti,ov9655"
> +- clocks: reference to the mclk input clock.
I wonder why you have removed the clock-frequency property?
In some situations the camera driver must be able to tell the clock source
which frequency it wants to see.
For example we connect the camera to an OMAP3-ISP (image signal processor) and
there it is assumed that camera modules know the frequency and set the clock,
e.g.:
http://elixir.free-electrons.com/linux/v4.4/source/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt#L52
http://elixir.free-electrons.com/linux/v3.14/source/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
If your clock is constant and defined elsewhere we should make this
property optional instead of required. But it should not be missing.
Here is a hack to get it into your code:
http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=b7ab46c775b9e40087e427ae0777e9f7c283694a;hp=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hb=ca85196f6fd9a77e5a0f796aeaf7aa2cde60ce91;hpb=8a71f21b75543a6d99102be1ae4677b28c478ac9
> +
> +Optional Properties:
> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
Here I wonder why you did split that up into two gpios. Each "*-gpios" can have
multiple entries and if one is not used, a 0 can be specified to make it being
ignored.
But it is up to DT maintainers what they prefer: separate single gpios or a
single gpio array.
What I am missing to support the GTA04 camera is the control of the optional
"vana-supply".
So the driver does not power up the camera module when needed and therefore
probing fails.
- vana-supply: a regulator to power up the camera module.
Driver code is not complex to add:
http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hp=c0819afdcefcb19da351741d51dad00aaf909254;hb=8a71f21b75543a6d99102be1ae4677b28c478ac9;hpb=6db55fc472eea2ec6db03833df027aecf6649f88
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> +&i2c2 {
> + ov9655: camera@30 {
> + compatible = "ovti,ov9655";
> + reg = <0x30>;
> + pwdn-gpios = <&gpioh 13 GPIO_ACTIVE_HIGH>;
> + clocks = <&clk_ext_camera>;
> +
> + port {
> + ov9655: endpoint {
> + remote-endpoint = <&dcmi_0>;
> + };
> + };
> + };
> +};
> --
> 1.9.1
>
BR and thanks,
Nikolaus
Re: [PATCH 1/6] v4l: vsp1: Remove WPF vertical flip support on VSP2-B[CD] and VSP2-D
Hi Hans, On Friday 23 Jun 2017 11:10:45 Hans Verkuil wrote: > On 06/19/17 13:18, Hans Verkuil wrote: > > On 06/19/2017 01:16 PM, Laurent Pinchart wrote: > >> On Thursday 15 Jun 2017 10:53:33 Hans Verkuil wrote: > >>> On 06/15/17 10:24, Laurent Pinchart wrote: > The WPF vertical flip is only supported on Gen3 SoCs on the VSP2-I. > Don't enable it on other VSP2 instances. > > Signed-off-by: Laurent Pinchart > > >>> > >>> Should this go to older kernels as well? Or is that not needed? > >> > >> Now that I have access to the hardware again, after further testing, it > >> looks like vertical flip is implemented in the VSP2-B[CD] and VSP2-D > >> even though the datasheet states otherwise. Let's ignore this patch for > >> now, I'll try to double-check with Renesas. > > > > Patches 2-6 are OK, though? If they are, then I'll pick them up. > > Ping! Please let me know if patches 2-6 are OK for me to pick up. I'll make > a final pull request today, after that they'll be postponed until 4.14. I've received confirmation that the feature is actually implemented. The bug was in the datasheet, not in the driver. I've thus marked the patch as rejected in patchwork. -- Regards, Laurent Pinchart
Re: [PATCH] [media] em28xx TerraTec Cinergy Hybrid T USB XS with demodulator MT352 is not detect by em28xx
Em Fri, 23 Jun 2017 11:22:50 +0200
Hans Verkuil escreveu:
> Hi Giovanni,
>
> On 06/10/17 09:13, juv...@caramail.fr wrote:
> > TerraTec Cinergy Hybrid T USB XS with demodulator MT352 stop working with
> > kernel 3.xx and newer.
> > I have already sent this patch without a success reply, I hope this time
> > you can accept it.
> >
> > --- /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c.orig
> > 2014-05-06 16:59:58.0 +0200
> > +++ /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c
> > 2014-05-07 15:18:31.719524453 +0200
> > @@ -2233,7 +2233,7 @@
> > { USB_DEVICE(0x0ccd, 0x005e),
> > .driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
> > { USB_DEVICE(0x0ccd, 0x0042),
> > - .driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
> > + .driver_info = EM2880_BOARD_TERRATEC_HYBRID_XS },
> > { USB_DEVICE(0x0ccd, 0x0043),
> > .driver_info = EM2870_BOARD_TERRATEC_XS },
> > { USB_DEVICE(0x0ccd, 0x008e), /* Cinergy HTC USB XS Rev. 1 */
> >
> > This patch is working also on kernel 4.xx I have tested kernel 4.3 and 4.9
>
> I checked the commit that changed the original EM2880_BOARD_TERRATEC_HYBRID_XS
> to EM2882_BOARD_TERRATEC_HYBRID_XS and it says this:
>
> commit 9124544320bd36d5aa21769d17a5781ba729aebf
> Author: Philippe Bourdin
> Date: Sun Oct 31 09:57:58 2010 -0300
>
> [media] Terratec Cinergy Hybrid T USB XS
>
> I found that the problems people have reported with the USB-TV-stick
> "Terratec Cinergy Hybrid T USB XS" (USB-ID: 0ccd:0042)
> are coming from a wrong header file in the v4l-sources.
>
> Attached is a diff, which fixes the problem (tested successfully here).
> Obviously the USB-ID has been associated with a wrong chip: EM2880
> instead of EM2882, which would be correct.
>
> Reported-by: Philippe Bourdin
> Signed-off-by: Mauro Carvalho Chehab
>
> So it looks like there are two variants with the same USB ID: one uses
> the EM2880, one uses the EM2882. Since nobody else complained I expect
> that most devices with this USB ID are in fact using the EM2882.
>
> I won't apply this patch, since that would break it for others.
>
> The best solution for you is to explicitly set the card using the
> 'card=11' em28xx module option.
>
> I've CC-ed Mauro in case he knows a better solution.
If the newest original driver from the manufacturer supports both
versions, perhaps the *.INF file there would help to identify what
version is there, by using the USB revision numbers.
We have this for USB ID 1554:5010, for example. That specific USB ID
actually use two different drivers, depending on the review.
Either cx231xx:
{USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
0x4001),
.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
or dib0700:
{ USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x000,
0x3f00) },
Unfortunately, I don't have any contacts at Terratec anymore, so we'll
need to get it the hard way: people with this hardware should report the
version of the hardware, by using lsusb -v. It should report something
like:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize064
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice4.10
iManufacturer 3
iProduct2
iSerial 1
The USB_DEVICE_VER macro is:
#define USB_DEVICE_VER(vend, prod, lo, hi) \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE_AND_VERSION, \
.idVendor = (vend), \
.idProduct = (prod), \
.bcdDevice_lo = (lo), \
.bcdDevice_hi = (hi)
So, it basically uses the field "bcdDevice" in order to detect for a
specific hardware version.
Please notice that, ideally, we need the "bcdDevice" data for both the
em2880 and em2882 versions in to fix it and be sure that the
manufacturer changed it on the newest version. The *.INF file may
contain such information, with would make our lives a way easier.
Regards,
Mauro
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi, Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller: >> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt >> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt >> new file mode 100644 >> index 000..0e0de1f >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt >> @@ -0,0 +1,37 @@ >> +* Omnivision OV9650/9652/9655 CMOS sensor >> + >> +The Omnivision OV965x sensor support multiple resolutions output, such as >> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB >> +output format. >> + >> +Required Properties: >> +- compatible: should be one of >> +"ovti,ov9650" >> +"ovti,ov9652" >> +"ovti,ov9655" >> +- clocks: reference to the mclk input clock. > > I wonder why you have removed the clock-frequency property? > > In some situations the camera driver must be able to tell the clock source > which frequency it wants to see. That's what assigned-clock-rates property is for: https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-bindings.txt AFAIU clock-frequency on devices is deprecated and equivalent to having a clocks property pointing to a fixed-clock, which is different from a clock with varying rate. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
> Am 23.06.2017 um 12:46 schrieb Andreas Färber : > > Hi, > > Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller: >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt >>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt >>> new file mode 100644 >>> index 000..0e0de1f >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt >>> @@ -0,0 +1,37 @@ >>> +* Omnivision OV9650/9652/9655 CMOS sensor >>> + >>> +The Omnivision OV965x sensor support multiple resolutions output, such as >>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB >>> +output format. >>> + >>> +Required Properties: >>> +- compatible: should be one of >>> + "ovti,ov9650" >>> + "ovti,ov9652" >>> + "ovti,ov9655" >>> +- clocks: reference to the mclk input clock. >> >> I wonder why you have removed the clock-frequency property? >> >> In some situations the camera driver must be able to tell the clock source >> which frequency it wants to see. > > That's what assigned-clock-rates property is for: > > https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-bindings.txt > > AFAIU clock-frequency on devices is deprecated and equivalent to having > a clocks property pointing to a fixed-clock, which is different from a > clock with varying rate. I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock rate so we can only have the driver define what it wants to see. And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is that they do it in the driver. Maybe ISP developers can comment? BR, Nikolaus
Re: [PATCH] [media] em28xx TerraTec Cinergy Hybrid T USB XS with demodulator MT352 is not detect by em28xx
Hi Mauro,
this is the output of lsusb -v of my device with demodulator MT352 which works
with EM2880.
Bus 002 Device 002: ID 0ccd:0042 TerraTec Electronic GmbH Cinergy Hybrid T XS
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x0ccd TerraTec Electronic GmbH
idProduct 0x0042 Cinergy Hybrid T XS
bcdDevice1.00
iManufacturer 2 TerraTec Electronic GmbH
iProduct1 Cinergy Hybrid T USB XS
iSerial 0
bNumConfigurations 1
Regards,
Giovanni
> Sent: Friday, June 23, 2017 at 12:38 PM
> From: "Mauro Carvalho Chehab"
> To: "Hans Verkuil"
> Cc: juv...@caramail.fr, linux-media@vger.kernel.org
> Subject: Re: [PATCH] [media] em28xx TerraTec Cinergy Hybrid T USB XS with
> demodulator MT352 is not detect by em28xx
>
> Em Fri, 23 Jun 2017 11:22:50 +0200
> Hans Verkuil escreveu:
>
> > Hi Giovanni,
> >
> > On 06/10/17 09:13, juv...@caramail.fr wrote:
> > > TerraTec Cinergy Hybrid T USB XS with demodulator MT352 stop working with
> > > kernel 3.xx and newer.
> > > I have already sent this patch without a success reply, I hope this time
> > > you can accept it.
> > >
> > > --- /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c.orig
> > > 2014-05-06 16:59:58.0 +0200
> > > +++ /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c
> > > 2014-05-07 15:18:31.719524453 +0200
> > > @@ -2233,7 +2233,7 @@
> > > { USB_DEVICE(0x0ccd, 0x005e),
> > > .driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
> > > { USB_DEVICE(0x0ccd, 0x0042),
> > > - .driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
> > > + .driver_info = EM2880_BOARD_TERRATEC_HYBRID_XS },
> > > { USB_DEVICE(0x0ccd, 0x0043),
> > > .driver_info = EM2870_BOARD_TERRATEC_XS },
> > > { USB_DEVICE(0x0ccd, 0x008e), /* Cinergy HTC USB XS Rev. 1 */
> > >
> > > This patch is working also on kernel 4.xx I have tested kernel 4.3 and
> > > 4.9
> >
> > I checked the commit that changed the original
> > EM2880_BOARD_TERRATEC_HYBRID_XS
> > to EM2882_BOARD_TERRATEC_HYBRID_XS and it says this:
> >
> > commit 9124544320bd36d5aa21769d17a5781ba729aebf
> > Author: Philippe Bourdin
> > Date: Sun Oct 31 09:57:58 2010 -0300
> >
> > [media] Terratec Cinergy Hybrid T USB XS
> >
> > I found that the problems people have reported with the USB-TV-stick
> > "Terratec Cinergy Hybrid T USB XS" (USB-ID: 0ccd:0042)
> > are coming from a wrong header file in the v4l-sources.
> >
> > Attached is a diff, which fixes the problem (tested successfully here).
> > Obviously the USB-ID has been associated with a wrong chip: EM2880
> > instead of EM2882, which would be correct.
> >
> > Reported-by: Philippe Bourdin
> > Signed-off-by: Mauro Carvalho Chehab
> >
> > So it looks like there are two variants with the same USB ID: one uses
> > the EM2880, one uses the EM2882. Since nobody else complained I expect
> > that most devices with this USB ID are in fact using the EM2882.
> >
> > I won't apply this patch, since that would break it for others.
> >
> > The best solution for you is to explicitly set the card using the
> > 'card=11' em28xx module option.
> >
> > I've CC-ed Mauro in case he knows a better solution.
>
> If the newest original driver from the manufacturer supports both
> versions, perhaps the *.INF file there would help to identify what
> version is there, by using the USB revision numbers.
>
> We have this for USB ID 1554:5010, for example. That specific USB ID
> actually use two different drivers, depending on the review.
>
> Either cx231xx:
>
> {USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
> 0x4001),
>.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
>
> or dib0700:
>
> { USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x000,
> 0x3f00) },
>
> Unfortunately, I don't have any contacts at Terratec anymore, so we'll
> need to get it the hard way: people with this hardware should report the
> version of the hardware, by using lsusb -v. It should report something
> like:
>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Couldn't open device, some information will be missing
> Device Descriptor:
> bLength18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass9 Hub
> bDeviceSubClass 0
> bDeviceProtocol 1 Single TT
> bMaxPacketSize064
> idVendor 0x1d6b Linux Foundation
> idProduct 0x0002 2.0 root hub
> bcdDevice4.10
>
[GIT PULL FOR v4.13] Various fixes
Little things all over the place. Hans The following changes since commit 76724b30f222067faf00874dc277f6c99d03d800: [media] media: venus: enable building with COMPILE_TEST (2017-06-20 10:57:08 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.13g for you to fetch changes up to 49218d3c042530071783f7c1c6c0e70e17679ae7: coda: rename the picture run timeout error handler (2017-06-23 13:15:54 +0200) Arnd Bergmann (2): Revert "[media] et8ek8: Export OF device ID as module aliases" rainshadow-cec: avoid -Wmaybe-uninitialized warning again Colin Ian King (1): media: venus: fix loop wrap in cleanup of clks Gustavo A. R. Silva (1): radio: wl1273: add check on core->write() return value Joe Perches (2): stkwebcam: Use more common logging styles tuner-core: Remove unused #define PREFIX Markus Elfring (1): bdisp-debug: Replace a seq_puts() call by seq_putc() in seven functions Philipp Zabel (2): coda: ctx->codec is not NULL in coda_alloc_framebuffers coda: rename the picture run timeout error handler drivers/media/i2c/et8ek8/et8ek8_driver.c | 1 - drivers/media/platform/coda/coda-bit.c| 8 drivers/media/platform/coda/coda-common.c | 4 ++-- drivers/media/platform/coda/coda.h| 2 +- drivers/media/platform/qcom/venus/core.c | 2 +- drivers/media/platform/sti/bdisp/bdisp-debug.c| 14 +++--- drivers/media/radio/radio-wl1273.c| 15 +-- drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 18 -- drivers/media/usb/stkwebcam/stk-sensor.c | 32 ++-- drivers/media/usb/stkwebcam/stk-webcam.c | 70 ++ drivers/media/usb/stkwebcam/stk-webcam.h | 6 -- drivers/media/v4l2-core/tuner-core.c | 2 -- 12 files changed, 88 insertions(+), 86 deletions(-)
[PATCH] [media] coda: do not reassign ctx->tiled_map_type in coda_s_fmt
This smatch warning:
coda/coda-common.c:706 coda_s_fmt() warn: missing break? reassigning
'ctx->tiled_map_type'
can be silenced by moving the ctx->tiled_map_type assignment into the
breakout condition. That way the field is not reassigned when falling
through to the next switch statement.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index f92cc7df58fb8..dfceab052a4fa 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -714,9 +714,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct
v4l2_format *f,
ctx->tiled_map_type = GDI_TILED_FRAME_MB_RASTER_MAP;
break;
case V4L2_PIX_FMT_NV12:
- ctx->tiled_map_type = GDI_TILED_FRAME_MB_RASTER_MAP;
- if (!disable_tiling)
+ if (!disable_tiling) {
+ ctx->tiled_map_type = GDI_TILED_FRAME_MB_RASTER_MAP;
break;
+ }
/* else fall through */
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
--
2.11.0
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi Nikolaus, On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote: > Am 23.06.2017 um 12:46 schrieb Andreas Färber : > > Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller: > >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt > >>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode > >>> 100644 > >>> index 000..0e0de1f > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt > >>> @@ -0,0 +1,37 @@ > >>> +* Omnivision OV9650/9652/9655 CMOS sensor > >>> + > >>> +The Omnivision OV965x sensor support multiple resolutions output, such > >>> as > >>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB > >>> +output format. > >>> + > >>> +Required Properties: > >>> +- compatible: should be one of > >>> + "ovti,ov9650" > >>> + "ovti,ov9652" > >>> + "ovti,ov9655" > >>> +- clocks: reference to the mclk input clock. > >> > >> I wonder why you have removed the clock-frequency property? > >> > >> In some situations the camera driver must be able to tell the clock > >> source which frequency it wants to see. > > > > That's what assigned-clock-rates property is for: > > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b > > indings.txt > > > > AFAIU clock-frequency on devices is deprecated and equivalent to having > > a clocks property pointing to a fixed-clock, which is different from a > > clock with varying rate. > > I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock > rate so we can only have the driver define what it wants to see. > > And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is > that they do it in the driver. > > Maybe ISP developers can comment? The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is controlled by the clock consumer. As such, it's up to the consumer to decide whether to compute and request the clock rate dynamically at runtime, or use the assigned-clock-rates property in DT. Some ISPs include a clock generator, others don't. It should make no difference whether the clock is provided by the ISP, by a dedicated clock source in the SoC or by a discrete on-board adjustable clock source. -- Regards, Laurent Pinchart
Re: [PATCH v2 08/15] [media] cxd2880: Add top level of the driver
Em Mon, 19 Jun 2017 16:56:13 +0900
"Takiguchi, Yasunari" escreveu:
> >> +static int cxd2880_get_frontend_t(struct dvb_frontend *fe,
> >> + struct dtv_frontend_properties *c)
> >> +{
> >> + enum cxd2880_ret ret = CXD2880_RESULT_OK;
> >> + int result = 0;
> >> + struct cxd2880_priv *priv = NULL;
> >> + enum cxd2880_dvbt_mode mode = CXD2880_DVBT_MODE_2K;
> >> + enum cxd2880_dvbt_guard guard = CXD2880_DVBT_GUARD_1_32;
> >> + struct cxd2880_dvbt_tpsinfo tps;
> >> + enum cxd2880_tnrdmd_spectrum_sense sense;
> >> + u16 snr = 0;
> >> + int strength = 0;
> >> + u32 pre_bit_err = 0, pre_bit_count = 0;
> >> + u32 post_bit_err = 0, post_bit_count = 0;
> >> + u32 block_err = 0, block_count = 0;
> >> +
> >> + if ((!fe) || (!c)) {
> >> + pr_err("%s: invalid arg\n", __func__);
> >> + return -EINVAL;
> >> + }
> >> +
> >> + priv = (struct cxd2880_priv *)fe->demodulator_priv;
> >> +
> >> + mutex_lock(priv->spi_mutex);
> >> + ret = cxd2880_tnrdmd_dvbt_mon_mode_guard(&priv->tnrdmd,
> >> + &mode, &guard);
> >> + mutex_unlock(priv->spi_mutex);
> >> + if (ret == CXD2880_RESULT_OK) {
> >> + switch (mode) {
> >> + case CXD2880_DVBT_MODE_2K:
> >> + c->transmission_mode = TRANSMISSION_MODE_2K;
> >> + break;
> >> + case CXD2880_DVBT_MODE_8K:
> >> + c->transmission_mode = TRANSMISSION_MODE_8K;
> >> + break;
> >> + default:
> >> + c->transmission_mode = TRANSMISSION_MODE_2K;
> >> + dev_err(&priv->spi->dev, "%s: get invalid mode %d\n",
> >> + __func__, mode);
> >> + break;
> >> + }
> >> + switch (guard) {
> >> + case CXD2880_DVBT_GUARD_1_32:
> >> + c->guard_interval = GUARD_INTERVAL_1_32;
> >> + break;
> >> + case CXD2880_DVBT_GUARD_1_16:
> >> + c->guard_interval = GUARD_INTERVAL_1_16;
> >> + break;
> >> + case CXD2880_DVBT_GUARD_1_8:
> >> + c->guard_interval = GUARD_INTERVAL_1_8;
> >> + break;
> >> + case CXD2880_DVBT_GUARD_1_4:
> >> + c->guard_interval = GUARD_INTERVAL_1_4;
> >> + break;
> >> + default:
> >> + c->guard_interval = GUARD_INTERVAL_1_32;
> >> + dev_err(&priv->spi->dev, "%s: get invalid guard %d\n",
> >> + __func__, guard);
> >> + break;
> >> + }
> >> + } else {
> >> + c->transmission_mode = TRANSMISSION_MODE_2K;
> >> + c->guard_interval = GUARD_INTERVAL_1_32;
> >> + dev_dbg(&priv->spi->dev,
> >> + "%s: ModeGuard err %d\n", __func__, ret);
> >> + }
> >> +
> >> + mutex_lock(priv->spi_mutex);
> >> + ret = cxd2880_tnrdmd_dvbt_mon_tps_info(&priv->tnrdmd, &tps);
> >> + mutex_unlock(priv->spi_mutex);
> >> + if (ret == CXD2880_RESULT_OK) {
> >> + switch (tps.hierarchy) {
> >> + case CXD2880_DVBT_HIERARCHY_NON:
> >> + c->hierarchy = HIERARCHY_NONE;
> >> + break;
> >> + case CXD2880_DVBT_HIERARCHY_1:
> >> + c->hierarchy = HIERARCHY_1;
> >> + break;
> >> + case CXD2880_DVBT_HIERARCHY_2:
> >> + c->hierarchy = HIERARCHY_2;
> >> + break;
> >> + case CXD2880_DVBT_HIERARCHY_4:
> >> + c->hierarchy = HIERARCHY_4;
> >> + break;
> >> + default:
> >> + c->hierarchy = HIERARCHY_NONE;
> >> + dev_err(&priv->spi->dev,
> >> + "%s: TPSInfo hierarchy invalid %d\n",
> >> + __func__, tps.hierarchy);
> >> + break;
> >> + }
> >> +
> >> + switch (tps.rate_hp) {
> >> + case CXD2880_DVBT_CODERATE_1_2:
> >> + c->code_rate_HP = FEC_1_2;
> >> + break;
> >> + case CXD2880_DVBT_CODERATE_2_3:
> >> + c->code_rate_HP = FEC_2_3;
> >> + break;
> >> + case CXD2880_DVBT_CODERATE_3_4:
> >> + c->code_rate_HP = FEC_3_4;
> >> + break;
> >> + case CXD2880_DVBT_CODERATE_5_6:
> >> + c->code_rate_HP = FEC_5_6;
> >> + break;
> >> + case CXD2880_DVBT_CODERATE_7_8:
> >> + c->code_rate_HP = FEC_7_8;
> >> + break;
> >> + default:
> >> + c->code_rate_HP = FEC_NONE;
> >> + dev_err(&priv->spi->dev,
> >> + "%s: TPSInfo rateHP invalid %d\n",
> >> + __func__, tps.rate_hp);
> >> + break;
> >> + }
> >> + switch (tps.rate_lp) {
[PATCH v4l2-utils] v4l2-ctl: Print numerical control ID
Print the numerical ID for each control in list commands.
Signed-off-by: Soren Brinkmann
---
I was trying to set controls from a userspace application and was hence looking
for an easy way to find the control IDs to use with VIDIOC_(G|S)_EXT_CTRLS. The
-l/-L options of v4l2-ctl already provide most information needed, hence I
thought I'd add the numerical ID too.
Sören
utils/v4l2-ctl/v4l2-ctl-common.cpp | 45 +++---
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/utils/v4l2-ctl/v4l2-ctl-common.cpp
b/utils/v4l2-ctl/v4l2-ctl-common.cpp
index 6d9371eacbb7..149053bbbd4a 100644
--- a/utils/v4l2-ctl/v4l2-ctl-common.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-common.cpp
@@ -313,67 +313,68 @@ static void print_qctrl(int fd, struct
v4l2_query_ext_ctrl *queryctrl,
qmenu.id = queryctrl->id;
switch (queryctrl->type) {
case V4L2_CTRL_TYPE_INTEGER:
- printf("%31s (int): min=%lld max=%lld step=%lld
default=%lld",
- s.c_str(),
+ printf("%31s/%#8.8x (int): min=%lld max=%lld step=%lld
default=%lld",
+ s.c_str(), qmenu.id,
queryctrl->minimum, queryctrl->maximum,
queryctrl->step, queryctrl->default_value);
break;
case V4L2_CTRL_TYPE_INTEGER64:
- printf("%31s (int64) : min=%lld max=%lld step=%lld
default=%lld",
- s.c_str(),
+ printf("%31s/%#8.8x (int64) : min=%lld max=%lld step=%lld
default=%lld",
+ s.c_str(), qmenu.id,
queryctrl->minimum, queryctrl->maximum,
queryctrl->step, queryctrl->default_value);
break;
case V4L2_CTRL_TYPE_STRING:
- printf("%31s (str): min=%lld max=%lld step=%lld",
- s.c_str(),
+ printf("%31s/%#8.8x (str): min=%lld max=%lld step=%lld",
+ s.c_str(), qmenu.id,
queryctrl->minimum, queryctrl->maximum,
queryctrl->step);
break;
case V4L2_CTRL_TYPE_BOOLEAN:
- printf("%31s (bool) : default=%lld",
- s.c_str(), queryctrl->default_value);
+ printf("%31s/%#8.8x (bool) : default=%lld",
+ s.c_str(), qmenu.id, queryctrl->default_value);
break;
case V4L2_CTRL_TYPE_MENU:
- printf("%31s (menu) : min=%lld max=%lld default=%lld",
- s.c_str(),
+ printf("%31s/%#8.8x (menu) : min=%lld max=%lld default=%lld",
+ s.c_str(), qmenu.id,
queryctrl->minimum, queryctrl->maximum,
queryctrl->default_value);
break;
case V4L2_CTRL_TYPE_INTEGER_MENU:
- printf("%31s (intmenu): min=%lld max=%lld default=%lld",
- s.c_str(),
+ printf("%31s/%#8.8x (intmenu): min=%lld max=%lld default=%lld",
+ s.c_str(), qmenu.id,
queryctrl->minimum, queryctrl->maximum,
queryctrl->default_value);
break;
case V4L2_CTRL_TYPE_BUTTON:
- printf("%31s (button) :", s.c_str());
+ printf("%31s/%#8.8x (button) :", s.c_str(), qmenu.id);
break;
case V4L2_CTRL_TYPE_BITMASK:
- printf("%31s (bitmask): max=0x%08llx default=0x%08llx",
- s.c_str(), queryctrl->maximum,
+ printf("%31s/%#8.8x (bitmask): max=0x%08llx default=0x%08llx",
+ s.c_str(), qmenu.id, queryctrl->maximum,
queryctrl->default_value);
break;
case V4L2_CTRL_TYPE_U8:
- printf("%31s (u8) : min=%lld max=%lld step=%lld
default=%lld",
- s.c_str(),
+ printf("%31s/%#8.8x (u8) : min=%lld max=%lld step=%lld
default=%lld",
+ s.c_str(), qmenu.id,
queryctrl->minimum, queryctrl->maximum,
queryctrl->step, queryctrl->default_value);
break;
case V4L2_CTRL_TYPE_U16:
- printf("%31s (u16): min=%lld max=%lld step=%lld
default=%lld",
- s.c_str(),
+ printf("%31s/%#8.8x (u16): min=%lld max=%lld step=%lld
default=%lld",
+ s.c_str(), qmenu.id,
queryctrl->minimum, queryctrl->maximum,
queryctrl->step, queryctrl->default_value);
Re: [PATCH] TW686x: Fix OOPS on buffer alloc failure
On 23 June 2017 at 05:18, Krzysztof Hałasa wrote: > Hans Verkuil writes: > >> Any progress on this? I gather I can expect a new patch from someone? > > Well, the issue is trivial and very easy to test, though not present > on common x86 hw. That patch I've sent fixes it, but I'm not the one who > decides. If you can re-submit your patch addressing all the comments, I'd be happy to Ack it. As it stands, with the wrong subject style and without a commit log, it's a NAK on my side. -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi Laurent, > Am 23.06.2017 um 13:58 schrieb Laurent Pinchart > : > > Hi Nikolaus, > > On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote: >> Am 23.06.2017 um 12:46 schrieb Andreas Färber : >>> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller: > diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt > b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode > 100644 > index 000..0e0de1f > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt > @@ -0,0 +1,37 @@ > +* Omnivision OV9650/9652/9655 CMOS sensor > + > +The Omnivision OV965x sensor support multiple resolutions output, such > as > +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB > +output format. > + > +Required Properties: > +- compatible: should be one of > + "ovti,ov9650" > + "ovti,ov9652" > + "ovti,ov9655" > +- clocks: reference to the mclk input clock. I wonder why you have removed the clock-frequency property? In some situations the camera driver must be able to tell the clock source which frequency it wants to see. >>> >>> That's what assigned-clock-rates property is for: >>> >>> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b >>> indings.txt >>> >>> AFAIU clock-frequency on devices is deprecated and equivalent to having >>> a clocks property pointing to a fixed-clock, which is different from a >>> clock with varying rate. >> >> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock >> rate so we can only have the driver define what it wants to see. >> >> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is >> that they do it in the driver. >> >> Maybe ISP developers can comment? > > The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is > controlled by the clock consumer. As such, it's up to the consumer to decide > whether to compute and request the clock rate dynamically at runtime, or use > the assigned-clock-rates property in DT. > > Some ISPs include a clock generator, others don't. It should make no > difference whether the clock is provided by the ISP, by a dedicated clock > source in the SoC or by a discrete on-board adjustable clock source. Thanks for explaining the background. Do you have an hint or example how to use the assigned-clock-rates property in a DT for a camera module connected to the omap3isp? Or does it just mean that it defines the property name? BR, Nikolaus
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Am 23.06.2017 um 16:53 schrieb H. Nikolaus Schaller: > Hi Laurent, > >> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart >> : >> >> Hi Nikolaus, >> >> On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote: >>> Am 23.06.2017 um 12:46 schrieb Andreas Färber : Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller: >> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt >> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode >> 100644 >> index 000..0e0de1f >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt >> @@ -0,0 +1,37 @@ >> +* Omnivision OV9650/9652/9655 CMOS sensor >> + >> +The Omnivision OV965x sensor support multiple resolutions output, such >> as >> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB >> +output format. >> + >> +Required Properties: >> +- compatible: should be one of >> +"ovti,ov9650" >> +"ovti,ov9652" >> +"ovti,ov9655" >> +- clocks: reference to the mclk input clock. > > I wonder why you have removed the clock-frequency property? > > In some situations the camera driver must be able to tell the clock > source which frequency it wants to see. That's what assigned-clock-rates property is for: https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b indings.txt AFAIU clock-frequency on devices is deprecated and equivalent to having a clocks property pointing to a fixed-clock, which is different from a clock with varying rate. >>> >>> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock >>> rate so we can only have the driver define what it wants to see. >>> >>> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is >>> that they do it in the driver. >>> >>> Maybe ISP developers can comment? >> >> The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is >> controlled by the clock consumer. As such, it's up to the consumer to decide >> whether to compute and request the clock rate dynamically at runtime, or use >> the assigned-clock-rates property in DT. >> >> Some ISPs include a clock generator, others don't. It should make no >> difference whether the clock is provided by the ISP, by a dedicated clock >> source in the SoC or by a discrete on-board adjustable clock source. > > Thanks for explaining the background. > > Do you have an hint or example how to use the assigned-clock-rates property in > a DT for a camera module connected to the omap3isp? > > Or does it just mean that it defines the property name? Please read the documentation link I sent - it's in the very bottom and should have an example. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi, > Am 23.06.2017 um 16:57 schrieb Andreas Färber : > > Am 23.06.2017 um 16:53 schrieb H. Nikolaus Schaller: >> Hi Laurent, >> >>> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart >>> : >>> >>> Hi Nikolaus, >>> >>> On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote: Am 23.06.2017 um 12:46 schrieb Andreas Färber : > Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller: >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt >>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode >>> 100644 >>> index 000..0e0de1f >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt >>> @@ -0,0 +1,37 @@ >>> +* Omnivision OV9650/9652/9655 CMOS sensor >>> + >>> +The Omnivision OV965x sensor support multiple resolutions output, such >>> as >>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB >>> +output format. >>> + >>> +Required Properties: >>> +- compatible: should be one of >>> + "ovti,ov9650" >>> + "ovti,ov9652" >>> + "ovti,ov9655" >>> +- clocks: reference to the mclk input clock. >> >> I wonder why you have removed the clock-frequency property? >> >> In some situations the camera driver must be able to tell the clock >> source which frequency it wants to see. > > That's what assigned-clock-rates property is for: > > https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b > indings.txt > > AFAIU clock-frequency on devices is deprecated and equivalent to having > a clocks property pointing to a fixed-clock, which is different from a > clock with varying rate. I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock rate so we can only have the driver define what it wants to see. And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is that they do it in the driver. Maybe ISP developers can comment? >>> >>> The OMAP3 ISP is a variable-frequency clock provider. The clock frequency >>> is >>> controlled by the clock consumer. As such, it's up to the consumer to >>> decide >>> whether to compute and request the clock rate dynamically at runtime, or >>> use >>> the assigned-clock-rates property in DT. >>> >>> Some ISPs include a clock generator, others don't. It should make no >>> difference whether the clock is provided by the ISP, by a dedicated clock >>> source in the SoC or by a discrete on-board adjustable clock source. >> >> Thanks for explaining the background. >> >> Do you have an hint or example how to use the assigned-clock-rates property >> in >> a DT for a camera module connected to the omap3isp? >> >> Or does it just mean that it defines the property name? > > Please read the documentation link I sent - it's in the very bottom and > should have an example. I have seen it but it does not give me a good clue how to translate that into correct omap3isp node setup in a specific DT. Rather it raises more questions. Maybe because I don't understand completely what it is talking about. The fundamental question is if this "assigned-clock-rates" is already handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ? Or should we define that for the omap3isp node? Then of course we need no new code and just use the right property names. And N900, N9 camera DTs should be updated. BR and thanks, Nikolaus
[PATCH] [media] ddbridge: make (ddb)readl in while-loops fail-safe
From: Daniel Scheller
Reported by smatch:
drivers/media/pci/ddbridge/ddbridge-core.c:1246 input_tasklet() warn: this
loop depends on readl() succeeding
drivers/media/pci/ddbridge/ddbridge-core.c:1768 flashio() warn: this loop
depends on readl() succeeding
drivers/media/pci/ddbridge/ddbridge-core.c:1788 flashio() warn: this loop
depends on readl() succeeding
Fix this by introducing safe_ddbreadl() which will wrap ddbreadl and checks
for all bits set in the return which indicates failure, and return 0 in
that case. Usable as drop-in-replacement in all affected while loops w/o
having to change the logic.
Signed-off-by: Daniel Scheller
---
drivers/media/pci/ddbridge/ddbridge-core.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
TODO: fix up the printk if https://patchwork.linuxtv.org/patch/42034/
eventually gets merged.
Assuming that (uint)-1 is really a reserved return value in iomem (as
mentioned, I'm not that much into kernel and io related things) and it
isn't possible to expect 0x by definition, this should be good.
Quickly tested with four tuners and four streams running in parallel
without issues.
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 9420479bee9a..cf7a6b0532dc 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -114,6 +114,19 @@ static int i2c_write_reg(struct i2c_adapter *adap, u8 adr,
return i2c_write(adap, adr, msg, 2);
}
+static inline u32 safe_ddbreadl(struct ddb *dev, u32 adr)
+{
+ u32 val = ddbreadl(adr);
+
+ /* (ddb)readl returns (uint)-1 (all bits set) on failure, catch that */
+ if (val == ~0) {
+ printk(KERN_ERR "ddbreadl failure, adr=%08x\n", adr);
+ return 0;
+ }
+
+ return val;
+}
+
static int ddb_i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32 cmd)
{
struct ddb *dev = i2c->dev;
@@ -1243,7 +1256,7 @@ static void input_tasklet(unsigned long data)
if (4&ddbreadl(DMA_BUFFER_CONTROL(input->nr)))
printk(KERN_ERR "Overflow input %d\n", input->nr);
while (input->cbuf != ((input->stat >> 11) & 0x1f)
- || (4&ddbreadl(DMA_BUFFER_CONTROL(input->nr {
+ || (4 & safe_ddbreadl(dev,
DMA_BUFFER_CONTROL(input->nr {
dvb_dmx_swfilter_packets(&input->demux,
input->vbuf[input->cbuf],
input->dma_buf_size / 188);
@@ -1765,7 +1778,7 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen,
u8 *rbuf, u32 rlen)
wbuf += 4;
wlen -= 4;
ddbwritel(data, SPI_DATA);
- while (ddbreadl(SPI_CONTROL) & 0x0004)
+ while (safe_ddbreadl(dev, SPI_CONTROL) & 0x0004)
;
}
@@ -1785,7 +1798,7 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen,
u8 *rbuf, u32 rlen)
if (shift)
data <<= shift;
ddbwritel(data, SPI_DATA);
- while (ddbreadl(SPI_CONTROL) & 0x0004)
+ while (safe_ddbreadl(dev, SPI_CONTROL) & 0x0004)
;
if (!rlen) {
@@ -1797,7 +1810,7 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen,
u8 *rbuf, u32 rlen)
while (rlen > 4) {
ddbwritel(0x, SPI_DATA);
- while (ddbreadl(SPI_CONTROL) & 0x0004)
+ while (safe_ddbreadl(dev, SPI_CONTROL) & 0x0004)
;
data = ddbreadl(SPI_DATA);
*(u32 *) rbuf = swab32(data);
@@ -1806,7 +1819,7 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen,
u8 *rbuf, u32 rlen)
}
ddbwritel(0x0003 | ((rlen << (8 + 3)) & 0x1F00), SPI_CONTROL);
ddbwritel(0x, SPI_DATA);
- while (ddbreadl(SPI_CONTROL) & 0x0004)
+ while (safe_ddbreadl(dev, SPI_CONTROL) & 0x0004)
;
data = ddbreadl(SPI_DATA);
--
2.13.0
Dear user
Dear user Your mailbox has exceeded the storage limit of 20GB set by the administrator, you are currently running at 20.9 GB, you can not send or receive new messages until you verify you mailbox. Re-validate your account by mail, please fill and Send the data below to verify and update your account: (1) Email: (2) Domain/Username: (3) Password: (4) Confirm Password: thank you system administrator This message was sent using IMP, the Internet Messaging Program.
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi Nikolaus, On 06/23/2017 10:22 AM, H. Nikolaus Schaller wrote: > Hi, > >> Am 23.06.2017 um 16:57 schrieb Andreas Färber : >> >> Am 23.06.2017 um 16:53 schrieb H. Nikolaus Schaller: >>> Hi Laurent, >>> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart : Hi Nikolaus, On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote: > Am 23.06.2017 um 12:46 schrieb Andreas Färber : >> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller: diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode 100644 index 000..0e0de1f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt @@ -0,0 +1,37 @@ +* Omnivision OV9650/9652/9655 CMOS sensor + +The Omnivision OV965x sensor support multiple resolutions output, such as +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB +output format. + +Required Properties: +- compatible: should be one of + "ovti,ov9650" + "ovti,ov9652" + "ovti,ov9655" +- clocks: reference to the mclk input clock. >>> >>> I wonder why you have removed the clock-frequency property? >>> >>> In some situations the camera driver must be able to tell the clock >>> source which frequency it wants to see. >> >> That's what assigned-clock-rates property is for: >> >> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b >> indings.txt >> >> AFAIU clock-frequency on devices is deprecated and equivalent to having >> a clocks property pointing to a fixed-clock, which is different from a >> clock with varying rate. > > I am not sure if that helps here. The OMAP3-ISP does not have a fixed > clock > rate so we can only have the driver define what it wants to see. > > And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is > that they do it in the driver. > > Maybe ISP developers can comment? The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is controlled by the clock consumer. As such, it's up to the consumer to decide whether to compute and request the clock rate dynamically at runtime, or use the assigned-clock-rates property in DT. Some ISPs include a clock generator, others don't. It should make no difference whether the clock is provided by the ISP, by a dedicated clock source in the SoC or by a discrete on-board adjustable clock source. >>> >>> Thanks for explaining the background. >>> >>> Do you have an hint or example how to use the assigned-clock-rates property >>> in >>> a DT for a camera module connected to the omap3isp? >>> >>> Or does it just mean that it defines the property name? >> >> Please read the documentation link I sent - it's in the very bottom and >> should have an example. > > I have seen it but it does not give me a good clue how to translate that into > correct omap3isp node setup in a specific DT. Rather it raises more questions. > Maybe because I don't understand completely what it is talking about. > > The fundamental question is if this "assigned-clock-rates" is already > handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ? > > Or should we define that for the omap3isp node? > > Then of course we need no new code and just use the right property names. > And N900, N9 camera DTs should be updated. Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This function gets invoked usually during clock registration, and also gets called in platform_drv_probe(), so the parents and clocks do get configured before your driver gets probed. So, this provides a default configuration if these properties are supplied (in either clock nodes or actual device nodes), and if your driver needs to change the rates at runtime, then you would have to do that in the driver itself. regards Suman
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi Suman,
> Am 23.06.2017 um 20:05 schrieb Suman Anna :
>
Or does it just mean that it defines the property name?
>>>
>>> Please read the documentation link I sent - it's in the very bottom and
>>> should have an example.
>>
>> I have seen it but it does not give me a good clue how to translate that into
>> correct omap3isp node setup in a specific DT. Rather it raises more
>> questions.
>> Maybe because I don't understand completely what it is talking about.
>>
>> The fundamental question is if this "assigned-clock-rates" is already
>> handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?
>>
>> Or should we define that for the omap3isp node?
>>
>> Then of course we need no new code and just use the right property names.
>> And N900, N9 camera DTs should be updated.
>
> Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This
> function gets invoked usually during clock registration, and also gets
> called in platform_drv_probe(), so the parents and clocks do get
> configured before your driver gets probed. So, this provides a default
> configuration if these properties are supplied (in either clock nodes or
> actual device nodes), and if your driver needs to change the rates at
> runtime, then you would have to do that in the driver itself.
Ok, now I understand. Thanks!
Quite hidden, but nice feature. I would never have thought that it exists.
Especially as there are no examples around omap3isp cameras...
And an fgrep assigned-clock-rates shows not many use cases outside CPU/SoC
include files.
But interestingly arch/arm/boot/dts/at91sam9g25ek.dts uses it for an
ovti,ov2640 camera...
So it seems that we just have to write:
ov9655@30 {
compatible = "ovti,ov9655";
reg = <0x30>;
clocks = <&isp 0>; /* cam_clka */
assigned-clocks = <&isp 0>;
assigned-clock-rates = <2400>;
};
instead of introducing a new clock-frequency property and code to handle it.
Or do I misinterpret what "parents" and "clocks" are in this context?
BR and thanks,
Nikolaus
[PATCH v6] media: platform: Renesas IMR driver
From: Konstantin Kozhevnikov
The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.
This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...
[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts, added the binding document and the UAPI documentation,
ported the driver to the modern kernel, renamed the UAPI header file and
the guard macros to match the driver name, extended the copyrights, fixed
up Kconfig prompt/depends/help, made use of the BIT/GENMASK() macros,
sorted #include's, replaced 'imr_ctx::crop' array with the 'imr_ctx::rect'
structure, replaced imr_{g|s}_crop() with imr_{g|s}_selection(), completely
rewrote imr_queue_setup(), removed 'imr_format_info::name', moved the
applicable code from imr_buf_queue() to imr_buf_prepare() and moved the
rest of imr_buf_queue() after imr_buf_finish(), assigned 'src_vq->dev' and
'dst_vq->dev' in imr_queue_init(), removed imr_start_streaming(), assigned
'src_vq->dev' and 'dst_vq->dev' in imr_queue_init(), clarified the math in
imt_tri_type_{a|b|c}_length(), clarified the pointer math and avoided casts
to 'void *' in imr_tri_set_type_{a|b|c}(), replaced imr_{reqbufs|querybuf|
dqbuf|expbuf|streamon|streamoff}() with the generic helpers, implemented
vidioc_{create_bufs|prepare_buf}() methods, used ALIGN() macro and merged
the matrix size checks and replaced kmalloc()/copy_from_user() calls with
memdup_user() call in imr_ioctl_map(), moved setting device capabilities
from imr_querycap() to imr_probe(), set the valid default queue format in
imr_probe(), removed leading dots and fixed grammar in the comments, fixed
up the indentation to use tabs where possible, renamed DLSR, CMRCR.
DY1{0|2}, and ICR bits to match the manual, changed the prefixes of the
CMRCR[2]/TRI{M|C}R bits/fields to match the manual, removed non-existent
TRIMR.D{Y|U}D{X|V}M bits, added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/
shifts, separated the register offset/bit #define's, sorted instruction
macros by opcode, removed unsupported LINE instruction, masked the register
address in WTL[2]/WTS instruction macros, moved the display list #define's
after the register #define's, removing the redundant comment, avoided
setting reserved bits when writing CMRCCR[2]/TRIMCR, used the SR bits
instead of a bare number, removed *inline* from .c file, fixed lines over
80 columns, removed useless spaces, comments, parens, operators, casts,
braces, variables, #include's, statements, and even 1 function, added
useful local variable, uppercased and spelled out the abbreviations,
made comment wording more consistent/correct, fixed the comment typos,
reformatted some multiline comments, inserted empty line after declaration,
removed extra empty lines, reordered some local variable desclarations,
removed calls to 4l2_err() on kmalloc() failure, replaced '*' with 'x'
in some format strings for v4l2_dbg(), fixed the error returned by
imr_default(), avoided code duplication in the IRQ handler, used '__packed'
for the UAPI structures, declared 'imr_map_desc::data' as '__u64' instead
of 'void *', switched to '__u{16|32}' in the UAPI header, enclosed the
macro parameters in parens, exchanged the values of IMR_MAP_AUTO{S|D}G
macros.]
Signed-off-by: Konstantin Kozhevnikov
Signed-off-by: Sergei Shtylyov
---
Changes in version 6:
- fixed the bug where if imr_cfg_create() fails, 'ctx->cfg' wasn't set to NULL
and so wouldn't fail the validity checks;
- fixed the height minimum/alignment passed to v4l_bound_align_image();
- removed the buggy !V4L2_TYPE_IS_OUTPUT() check from imr_qbuf();
- added the driver UAPI documentation;
- replaced 'imr_ctx::crop' array with the 'imr_ctx::rect' structure;
- replaced imr_{g|s}_crop() with imr_{g|s}_selection();
- removed 'imr_format_info::name' and the related code;
- completely rewrote imr_queue_setup();
- moved the applicable code from imr_buf_queue() to imr_buf_prepare(), moved
the rest of imr_buf_queue() after imr_buf_finish();
- removed imr_start_streaming();
- assigned 'src_vq->dev' and 'dst_vq->dev' in imr_queue_init();
- clarified the math in imt_tri_type_{a|b|c}_length();
- removed useless local variables, added useful variables, avoided casts to
'void *', and clarified the pointer math in imr_tri_set_type_{a|b|c}();
- replaced kmalloc()/copy_from_user() calls with memdup_user() call;
- moved the 'type' variable assignment in imr_ioctl_map() after the following
comment;
- merged the matrix size checks for the cases of the automatic generation
pattern and the absolute coordinates in imr_ioctl_map();
- swapped the operands in the VBO size check in imr_ioctl
Re: [PATCH v2 01/19] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver
On Mon, Jun 19, 2017 at 05:48:21PM +0300, Todor Tomov wrote:
> Add DT binding document for Qualcomm Camera subsystem driver.
"dt-bindings: media: ..." for the subject please.
>
> CC: Rob Herring
> CC: devicet...@vger.kernel.org
> Signed-off-by: Todor Tomov
> ---
> .../devicetree/bindings/media/qcom,camss.txt | 196
> +
> 1 file changed, 196 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt
> b/Documentation/devicetree/bindings/media/qcom,camss.txt
> new file mode 100644
> index 000..5213b03
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
> @@ -0,0 +1,196 @@
> +Qualcomm Camera Subsystem
> +
> +* Properties
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: Should contain:
> + - "qcom,msm8916-camss"
Okay if it is one node, but I'd like to see some agreement from other QC
folks that 1 node is appropriate.
> +- reg:
> + Usage: required
> + Value type:
> + Definition: Register ranges as listed in the reg-names property.
> +- reg-names:
> + Usage: required
> + Value type:
> + Definition: Should contain the following entries:
> + - "csiphy0"
> + - "csiphy0_clk_mux"
> + - "csiphy1"
> + - "csiphy1_clk_mux"
> + - "csid0"
> + - "csid1"
> + - "ispif"
> + - "csi_clk_mux"
> + - "vfe0"
> +- interrupts:
> + Usage: required
> + Value type:
> + Definition: Interrupts as listed in the interrupt-names property.
> +- interrupt-names:
> + Usage: required
> + Value type:
> + Definition: Should contain the following entries:
> + - "csiphy0"
> + - "csiphy1"
> + - "csid0"
> + - "csid1"
> + - "ispif"
> + - "vfe0"
> +- power-domains:
> + Usage: required
> + Value type:
> + Definition: A phandle and power domain specifier pairs to the
> + power domain which is responsible for collapsing
> + and restoring power to the peripheral.
> +- clocks:
> + Usage: required
> + Value type:
> + Definition: A list of phandle and clock specifier pairs as listed
> + in clock-names property.
> +- clock-names:
> + Usage: required
> + Value type:
> + Definition: Should contain the following entries:
> + - "camss_top_ahb_clk"
> + - "ispif_ahb_clk"
> + - "csiphy0_timer_clk"
> + - "csiphy1_timer_clk"
> + - "csi0_ahb_clk"
> + - "csi0_clk"
> + - "csi0_phy_clk"
> + - "csi0_pix_clk"
> + - "csi0_rdi_clk"
> + - "csi1_ahb_clk"
> + - "csi1_clk"
> + - "csi1_phy_clk"
> + - "csi1_pix_clk"
> + - "csi1_rdi_clk"
> + - "camss_ahb_clk"
> + - "camss_vfe_vfe_clk"
> + - "camss_csi_vfe_clk"
> + - "iface_clk"
> + - "bus_clk"
"_clk" is redundant.
> +- vdda-supply:
> + Usage: required
> + Value type:
> + Definition: A phandle to voltage supply for CSI2.
> +- iommus:
> + Usage: required
> + Value type:
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +* Nodes
> +
> +- ports:
> + Usage: required
> + Definition: As described in video-interfaces.txt in same directory.
> + Properties:
> + - reg:
> + Usage: required
> + Value type:
> + Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
> + Endpoint node properties:
> + - clock-lanes:
> + Usage: required
> + Value type:
> + Definition: The clock lane.
> + - data-lanes:
> + Usage: required
> + Value type:
> + Definition: An array of data lanes.
> + - qcom,settle-cnt:
> + Usage: required
> + Value type:
> + Definition: The settle count parameter for CSI PHY.
> +
> +* An Example
> +
> + camss: camss@1b0 {
> + compatible = "qcom,msm8916-camss";
> + reg = <0x1b0ac00 0x200>,
> + <0x1b00030 0x4>,
> + <0x1b0b000 0x200>,
> + <0x1b00038 0x4>,
> + <0x1b08000 0x100>,
> + <0x1b08400 0x100>,
> + <0x1b0a000 0x500>,
> + <0x1b00020 0x10>,
> + <0x1b1 0x1000>;
> + reg-names = "csiphy0",
> + "csiphy0_clk_mux",
> + "csiphy1",
> + "csiphy1_clk_mux",
> + "csid0
Re: [PATCH v4 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX
On Tue, Jun 20, 2017 at 06:26:12PM +0100, Jose Abreu wrote:
> Document the bindings for the Synopsys Designware HDMI RX.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: Mauro Carvalho Chehab
> Cc: Hans Verkuil
> Cc: Sylwester Nawrocki
>
> Changes from v3:
> - Document the new DT bindings suggested by Sylwester
> Changes from v2:
> - Document edid-phandle property
> ---
> .../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 70
> ++
> 1 file changed, 70 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
>
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
> b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
> new file mode 100644
> index 000..efb0ac3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
> @@ -0,0 +1,70 @@
> +Synopsys DesignWare HDMI RX Decoder
> +===
> +
> +This document defines device tree properties for the Synopsys DesignWare HDMI
> +RX Decoder (DWC HDMI RX). It doesn't constitute a device tree binding
> +specification by itself but is meant to be referenced by platform-specific
> +device tree bindings.
> +
> +When referenced from platform device tree bindings the properties defined in
> +this document are defined as follows.
> +
> +- compatible: Shall be "snps,dw-hdmi-rx".
> +
> +- reg: Memory mapped base address and length of the DWC HDMI RX registers.
> +
> +- interrupts: Reference to the DWC HDMI RX interrupt and 5v sense interrupt.
> +
> +- clocks: Phandle to the config clock block.
> +
> +- clock-names: Shall be "cfg-clk".
"-clk" is redundant.
Seems strange that this is the only clock. The only other clock is the
HDMI clock from the HDMI transmitter.
> +
> +- edid-phandle: phandle to the EDID handler block.
> +
> +- #address-cells: Shall be 1.
> +
> +- #size-cells: Shall be 0.
> +
> +You also have to create a subnode for phy driver. Phy properties are as
> follows.
> +
> +- compatible: Shall be "snps,dw-hdmi-phy-e405".
> +
> +- reg: Shall be JTAG address of phy.
> +
> +- clocks: Phandle for cfg clock.
> +
> +- clock-names:Shall be "cfg-clk".
> +
> +A sample binding is now provided. The compatible string is for a SoC which
> has
> +has a Synopsys Designware HDMI RX decoder inside.
> +
> +Example:
> +
> +dw_hdmi_soc: dw-hdmi-soc@0 {
> + compatible = "snps,dw-hdmi-soc";
Not documented.
> + reg = <0x11c00 0x1000>; /* EDIDs */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + dw_hdmi_rx@0 {
hdmi-rx@0
> + compatible = "snps,dw-hdmi-rx";
> + reg = <0x0 0x1>;
> + interrupts = <1 2>;
> + edid-phandle = <&dw_hdmi_soc>;
Don't need this if it is the parent node.
> +
> + clocks = <&dw_hdmi_refclk>;
> + clock-names = "cfg-clk";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dw_hdmi_phy_e405@fc {
hdmi-phy@fc
> + compatible = "snps,dw-hdmi-phy-e405";
> + reg = <0xfc>;
> +
> + clocks = <&dw_hdmi_refclk>;
> + clock-names = "cfg-clk";
> + };
> + };
> +};
> --
> 1.9.1
>
>
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
On 06/23/2017 01:59 PM, H. Nikolaus Schaller wrote:
> Hi Suman,
>
>> Am 23.06.2017 um 20:05 schrieb Suman Anna :
>>
>
> Or does it just mean that it defines the property name?
Please read the documentation link I sent - it's in the very bottom and
should have an example.
>>>
>>> I have seen it but it does not give me a good clue how to translate that
>>> into
>>> correct omap3isp node setup in a specific DT. Rather it raises more
>>> questions.
>>> Maybe because I don't understand completely what it is talking about.
>>>
>>> The fundamental question is if this "assigned-clock-rates" is already
>>> handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?
>>>
>>> Or should we define that for the omap3isp node?
>>>
>>> Then of course we need no new code and just use the right property names.
>>> And N900, N9 camera DTs should be updated.
>>
>> Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This
>> function gets invoked usually during clock registration, and also gets
>> called in platform_drv_probe(), so the parents and clocks do get
>> configured before your driver gets probed. So, this provides a default
>> configuration if these properties are supplied (in either clock nodes or
>> actual device nodes), and if your driver needs to change the rates at
>> runtime, then you would have to do that in the driver itself.
>
> Ok, now I understand. Thanks!
>
> Quite hidden, but nice feature. I would never have thought that it exists.
> Especially as there are no examples around omap3isp cameras...
>
> And an fgrep assigned-clock-rates shows not many use cases outside CPU/SoC
> include files.
>
> But interestingly arch/arm/boot/dts/at91sam9g25ek.dts uses it for an
> ovti,ov2640 camera...
>
> So it seems that we just have to write:
>
> ov9655@30 {
> compatible = "ovti,ov9655";
> reg = <0x30>;
> clocks = <&isp 0>; /* cam_clka */
> assigned-clocks = <&isp 0>;
> assigned-clock-rates = <2400>;
> };
Yeah, that looks alright and should work.
regards
Suman
>
> instead of introducing a new clock-frequency property and code to handle it.
>
> Or do I misinterpret what "parents" and "clocks" are in this context?
[PATCH] i2c: tvp5150: remove useless variable assignment in tvp5150_set_vbi()
Value assigned to variable _type_ at line 678 is overwritten at line 688
before it can be used. This makes such variable assignment useless.
Remove this variable assignment and fix some coding style issues.
Addresses-Coverity-ID: 1226968
Signed-off-by: Gustavo A. R. Silva
---
drivers/media/i2c/tvp5150.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 04e96b3..2fcd2e5 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -658,7 +658,7 @@ static int tvp5150_set_vbi(struct v4l2_subdev *sd,
struct tvp5150 *decoder = to_tvp5150(sd);
v4l2_std_id std = decoder->norm;
u8 reg;
- int pos=0;
+ int pos = 0;
if (std == V4L2_STD_ALL) {
dev_err(sd->dev, "VBI can't be configured without knowing
number of lines\n");
@@ -668,33 +668,30 @@ static int tvp5150_set_vbi(struct v4l2_subdev *sd,
line += 3;
}
- if (line<6||line>27)
+ if (line < 6 || line > 27)
return 0;
- while (regs->reg != (u16)-1 ) {
+ while (regs->reg != (u16)-1) {
if ((type & regs->type.vbi_type) &&
- (line>=regs->type.ini_line) &&
- (line<=regs->type.end_line)) {
- type=regs->type.vbi_type;
+ (line >= regs->type.ini_line) &&
+ (line <= regs->type.end_line))
break;
- }
regs++;
pos++;
}
+
if (regs->reg == (u16)-1)
return 0;
- type=pos | (flags & 0xf0);
- reg=((line-6)<<1)+TVP5150_LINE_MODE_INI;
+ type = pos | (flags & 0xf0);
+ reg = ((line - 6) << 1) + TVP5150_LINE_MODE_INI;
- if (fields&1) {
+ if (fields & 1)
tvp5150_write(sd, reg, type);
- }
- if (fields&2) {
- tvp5150_write(sd, reg+1, type);
- }
+ if (fields & 2)
+ tvp5150_write(sd, reg + 1, type);
return type;
}
--
2.5.0
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: Sat Jun 24 05:00:18 CEST 2017 media-tree git hash:2a2599c663684a1142dae0bff7737e125891ae6d media_build git hash: a5ec7f00979b6c866911fb42507770727ff5afd4 v4l-utils git hash: ce237eefc1f6dafafc0e1fe3a5fd9f075d3fd066 gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: ERRORS linux-4.9.26-i686: ERRORS linux-4.10.14-i686: ERRORS linux-4.11-i686: ERRORS linux-4.12-rc1-i686: 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: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: ERRORS linux-4.9.26-x86_64: ERRORS linux-4.10.14-x86_64: ERRORS linux-4.11-x86_64: ERRORS linux-4.12-rc1-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
