Re: [PATCH v12][ 07/12] drm: drm_display_mode: add signal polarity flags
Hi Denis,
On 04/07/2014 02:44 PM, Denis Carikli wrote:
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v11-v12:
- Rebased: This patch now applies against drm_modes.h
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10-v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
include/drm/drm_modes.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2dbbf99..b3789e2 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -93,6 +93,13 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
What is the purpose of DRM_MODE_FLAG_POL_PIXDATA_PRESERVE?
If 'preserve' means 'ignore' we can set to zero negedge and posedge bits
instead of adding new bit. If it is something different please describe it.
+#define DRM_MODE_FLAG_POL_DE_LOW BIT(4)
+#define DRM_MODE_FLAG_POL_DE_HIGHBIT(5)
+#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
+
The same comments here.
struct drm_display_mode {
/* Header */
struct list_head head;
@@ -144,6 +151,7 @@ struct drm_display_mode {
int vrefresh; /* in Hz */
int hsync; /* in kHz */
enum hdmi_picture_aspect picture_aspect_ratio;
+ unsigned int pol_flags;
Adding field and macros description to the DocBook would be nice.
Regards
Andrzej
};
/* mode specified on the command line */
--
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/4] gsc-m2m: report correct format bytesperline and sizeimage
Hi John Sheu,
Thanks for the patch.
Please find the review comments inline.
On Wed, Mar 12, 2014 at 4:22 AM, John Sheu s...@google.com wrote:
Explicitly specify sampling period for subsampled chroma formats, so
stride and image size are properly reported through VIDIOC_{S,G}_FMT.
Signed-off-by: John Sheu s...@google.com
---
drivers/media/platform/exynos-gsc/gsc-core.c | 154
+++
drivers/media/platform/exynos-gsc/gsc-core.h | 16 +--
drivers/media/platform/exynos-gsc/gsc-regs.c | 40 +++
drivers/media/platform/exynos-gsc/gsc-regs.h | 4 +-
4 files changed, 116 insertions(+), 98 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9d0cc04d..c02addef 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -34,167 +34,185 @@ static const struct gsc_fmt gsc_formats[] = {
{
.name = RGB565,
.pixelformat= V4L2_PIX_FMT_RGB565X,
- .depth = { 16 },
.color = GSC_RGB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
}, {
.name = XRGB-8-8-8-8, 32 bpp,
.pixelformat= V4L2_PIX_FMT_RGB32,
- .depth = { 32 },
.color = GSC_RGB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 32 },
+ .sampling = { { 1, 1 } },
}, {
.name = YUV 4:2:2 packed, YCbYCr,
.pixelformat= V4L2_PIX_FMT_YUYV,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_Y,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
}, {
.name = YUV 4:2:2 packed, CbYCrY,
.pixelformat= V4L2_PIX_FMT_UYVY,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_C,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
}, {
.name = YUV 4:2:2 packed, CrYCbY,
.pixelformat= V4L2_PIX_FMT_VYUY,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_C,
.corder = GSC_CRCB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_VYUY8_2X8,
}, {
.name = YUV 4:2:2 packed, YCrYCb,
.pixelformat= V4L2_PIX_FMT_YVYU,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_Y,
.corder = GSC_CRCB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_YVYU8_2X8,
}, {
.name = YUV 4:4:4 planar, YCbYCr,
.pixelformat= V4L2_PIX_FMT_YUV32,
- .depth = { 32 },
.color = GSC_YUV444,
.yorder = GSC_LSB_Y,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 32 },
+ .sampling = { { 1, 1 } },
}, {
.name = YUV 4:2:2 planar, Y/Cb/Cr,
.pixelformat= V4L2_PIX_FMT_YUV422P,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_Y,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 3,
+ .depth = { 8, 8, 8 },
+ .sampling = { { 1, 1 }, { 2, 1 }, { 2, 1 } },
}, {
.name = YUV 4:2:2 planar, Y/CbCr,
.pixelformat= V4L2_PIX_FMT_NV16,
- .depth
Re: [PATCH 3/4] gsc-m2m: report correct format bytesperline and sizeimage
On Tue, Apr 8, 2014 at 12:26 PM, Shaik Ameer Basha
shaik.sams...@gmail.com wrote:
Hi John Sheu,
Thanks for the patch.
Please find the review comments inline.
On Wed, Mar 12, 2014 at 4:22 AM, John Sheu s...@google.com wrote:
Explicitly specify sampling period for subsampled chroma formats, so
stride and image size are properly reported through VIDIOC_{S,G}_FMT.
Signed-off-by: John Sheu s...@google.com
---
drivers/media/platform/exynos-gsc/gsc-core.c | 154
+++
drivers/media/platform/exynos-gsc/gsc-core.h | 16 +--
drivers/media/platform/exynos-gsc/gsc-regs.c | 40 +++
drivers/media/platform/exynos-gsc/gsc-regs.h | 4 +-
4 files changed, 116 insertions(+), 98 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9d0cc04d..c02addef 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -34,167 +34,185 @@ static const struct gsc_fmt gsc_formats[] = {
{
.name = RGB565,
.pixelformat= V4L2_PIX_FMT_RGB565X,
- .depth = { 16 },
.color = GSC_RGB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
}, {
.name = XRGB-8-8-8-8, 32 bpp,
.pixelformat= V4L2_PIX_FMT_RGB32,
- .depth = { 32 },
.color = GSC_RGB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 32 },
+ .sampling = { { 1, 1 } },
}, {
.name = YUV 4:2:2 packed, YCbYCr,
.pixelformat= V4L2_PIX_FMT_YUYV,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_Y,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
}, {
.name = YUV 4:2:2 packed, CbYCrY,
.pixelformat= V4L2_PIX_FMT_UYVY,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_C,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
}, {
.name = YUV 4:2:2 packed, CrYCbY,
.pixelformat= V4L2_PIX_FMT_VYUY,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_C,
.corder = GSC_CRCB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_VYUY8_2X8,
}, {
.name = YUV 4:2:2 packed, YCrYCb,
.pixelformat= V4L2_PIX_FMT_YVYU,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_Y,
.corder = GSC_CRCB,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 16 },
+ .sampling = { { 1, 1 } },
.mbus_code = V4L2_MBUS_FMT_YVYU8_2X8,
}, {
.name = YUV 4:4:4 planar, YCbYCr,
.pixelformat= V4L2_PIX_FMT_YUV32,
- .depth = { 32 },
.color = GSC_YUV444,
.yorder = GSC_LSB_Y,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 1,
+ .depth = { 32 },
+ .sampling = { { 1, 1 } },
}, {
.name = YUV 4:2:2 planar, Y/Cb/Cr,
.pixelformat= V4L2_PIX_FMT_YUV422P,
- .depth = { 16 },
.color = GSC_YUV422,
.yorder = GSC_LSB_Y,
.corder = GSC_CBCR,
.num_planes = 1,
.num_comp = 3,
+ .depth = { 8, 8, 8 },
+ .sampling = { { 1, 1 }, { 2, 1 }, { 2, 1 } },
}, {
.name = YUV 4:2:2 planar,
Re: [PATCH 4/8] [media] s5p-jpeg: Fix build break when CONFIG_OF is undefined
Hi Jacek, On 7 April 2014 18:46, Jacek Anaszewski j.anaszew...@samsung.com wrote: This patch fixes build break occurring when there is no support for Device Tree turned on in the kernel configuration. In such a case only the driver variant for S5PC210 SoC will be available. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- snip + if (!IS_ENABLED(CONFIG_OF) || dev-of_node == NULL) !dev-of_node instead of equating to NULL. + return s5p_jpeg_drvdata; + match = of_match_node(of_match_ptr(samsung_jpeg_match), Since you are returning above if CONFIG_OF is not enabled, of_match_ptr is not needed. -- With warm regards, Sachin -- 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 7/8] [media] s5p_jpeg: Prevent JPEG 4:2:0 YUV 4:2:0 decompression
Hi Jacek,
On 7 April 2014 18:46, Jacek Anaszewski j.anaszew...@samsung.com wrote:
Prevent decompression of a JPEG 4:2:0 with odd width to
the YUV 4:2:0 compliant formats for Exynos4x12 SoCs and
adjust capture format to RGB565 in such a case. This is
required because the configuration would produce a raw
image with broken luma component.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
snip
+ if (ctx-subsampling == V4L2_JPEG_CHROMA_SUBSAMPLING_420
+ (ctx-out_q.w 1)
+ (pix-pixelformat == V4L2_PIX_FMT_NV12 ||
+pix-pixelformat == V4L2_PIX_FMT_NV21 ||
+pix-pixelformat == V4L2_PIX_FMT_YUV420)) {
+ pix-pixelformat = V4L2_PIX_FMT_RGB565;
+ fmt = s5p_jpeg_find_format(ctx, pix-pixelformat,
+ FMT_TYPE_CAPTURE);
+ v4l2_info(ctx-jpeg-v4l2_dev,
+ Adjusted capture fourcc to RGB565. Decompression\n
+ of a JPEG file with 4:2:0 subsampling and odd\n
+ width to the YUV 4:2:0 compliant formats
produces\n
+ a raw image with broken luma component.\n);
This could be made a comment in the code rather than a info message.
--
With warm regards,
Sachin
--
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 v12][ 07/12] drm: drm_display_mode: add signal polarity flags
On 04/08/2014 08:36 AM, Andrzej Hajda wrote:
Hi Denis,
Hi,
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
What is the purpose of DRM_MODE_FLAG_POL_PIXDATA_PRESERVE?
If 'preserve' means 'ignore' we can set to zero negedge and posedge bits
instead of adding new bit. If it is something different please describe it.
Yes, it meant 'ignore'.
The goal was to be able to have a way to keep the old behavior while
still being able to set the flags.
So, with the imx-drm driver, if none of the DRM_MODE_FLAG_POL_PIXDATA
were set(that is POSEDGE, NEGEDGE, PRESERVE), then in ipuv3-crtc.c, it
went using the old flags settings that were previously hardcoded.
The same applied for DRM_MODE_FLAG_POL_DE.
The patch using theses flags is the 08/12 of this same serie.
struct drm_display_mode {
[..]
+ unsigned int pol_flags;
Adding field and macros description to the DocBook would be nice.
So I will have to describe it in the Connector Helper Operations
section of drm.tmpl, right before the mode_valid synopsis ?
Denis.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] v4l2-dv-timings.c: add the new 4K timings to the list.
From: Hans Verkuil hans.verk...@cisco.com
Add the new CEA-861-F and DMT 4K timings to the list of predefined
timings.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-dv-timings.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 48b20df..4ae54ca 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -131,6 +131,17 @@ const struct v4l2_dv_timings v4l2_dv_timings_presets[] = {
V4L2_DV_BT_DMT_2560X1600P75,
V4L2_DV_BT_DMT_2560X1600P85,
V4L2_DV_BT_DMT_2560X1600P120_RB,
+ V4L2_DV_BT_CEA_3840X2160P24,
+ V4L2_DV_BT_CEA_3840X2160P25,
+ V4L2_DV_BT_CEA_3840X2160P30,
+ V4L2_DV_BT_CEA_3840X2160P50,
+ V4L2_DV_BT_CEA_3840X2160P60,
+ V4L2_DV_BT_CEA_4096X2160P24,
+ V4L2_DV_BT_CEA_4096X2160P25,
+ V4L2_DV_BT_CEA_4096X2160P30,
+ V4L2_DV_BT_CEA_4096X2160P50,
+ V4L2_DV_BT_DMT_4096X2160P59_94_RB,
+ V4L2_DV_BT_CEA_4096X2160P60,
{ }
};
EXPORT_SYMBOL_GPL(v4l2_dv_timings_presets);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] v4l2-dv-timings.h: add CEA-861-F 4K timings
From: Hans Verkuil hans.verk...@cisco.com
Add the CEA-861-F timings for 3840x2160p24/25/30/50/60 and
4096x2160p24/25/30/50/60.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/uapi/linux/v4l2-dv-timings.h | 70
1 file changed, 70 insertions(+)
diff --git a/include/uapi/linux/v4l2-dv-timings.h
b/include/uapi/linux/v4l2-dv-timings.h
index b6a5fe0..6c8f159 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -173,6 +173,76 @@
V4L2_DV_FL_CAN_REDUCE_FPS) \
}
+#define V4L2_DV_BT_CEA_3840X2160P24 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 29700, 1276, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_CAN_REDUCE_FPS) \
+}
+
+#define V4L2_DV_BT_CEA_3840X2160P25 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 29700, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, 0) \
+}
+
+#define V4L2_DV_BT_CEA_3840X2160P30 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 29700, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_CAN_REDUCE_FPS) \
+}
+
+#define V4L2_DV_BT_CEA_3840X2160P50 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 59400, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, 0) \
+}
+
+#define V4L2_DV_BT_CEA_3840X2160P60 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 59400, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_CAN_REDUCE_FPS) \
+}
+
+#define V4L2_DV_BT_CEA_4096X2160P24 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 29700, 1020, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_CAN_REDUCE_FPS) \
+}
+
+#define V4L2_DV_BT_CEA_4096X2160P25 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 29700, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, 0) \
+}
+
+#define V4L2_DV_BT_CEA_4096X2160P30 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 29700, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_CAN_REDUCE_FPS) \
+}
+
+#define V4L2_DV_BT_CEA_4096X2160P50 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 59400, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, 0) \
+}
+
+#define V4L2_DV_BT_CEA_4096X2160P60 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ 59400, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_CAN_REDUCE_FPS) \
+}
+
/* VESA Discrete Monitor Timings as per version 1.0, revision 12 */
--
1.8.4.rc3
--
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: videobuf2-vmalloc suspect for corrupted data
Hi Hans, That should be new enough, I see no important differences between 3.4 and 3.14 in this respect. But really, 3.4? We are moving to 3.10 shortly. Question: if you use MEMORY_MMAP instead of USERPTR, does that work? Unfortunately, this activity is pending (need to get it pushed in plan). I need to port driver and app to do that. Have you tried to stream with v4l2-ctl? It's available here: No, need to see. Read a bit about vm_map_ram(), it gives a kernel vaddr for user pages in which the user vaddr are residing. Can the virtually indexed D-cache be an issue here, or am I too paranoid? I just checked on some webpage probably arm center, that D-caches are physically tagged, so, the above could be ruled out. What about the architectures? I will look into the driver more thoroughly, because, for kernel.org code, I am least skeptical. Regards, Divneil -- 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 v12][ 07/12] drm: drm_display_mode: add signal polarity flags
On 04/08/2014 10:08 AM, Denis Carikli wrote:
On 04/08/2014 08:36 AM, Andrzej Hajda wrote:
Hi Denis,
Hi,
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
What is the purpose of DRM_MODE_FLAG_POL_PIXDATA_PRESERVE?
If 'preserve' means 'ignore' we can set to zero negedge and posedge bits
instead of adding new bit. If it is something different please describe it.
Yes, it meant 'ignore'.
The goal was to be able to have a way to keep the old behavior while
still being able to set the flags.
So, with the imx-drm driver, if none of the DRM_MODE_FLAG_POL_PIXDATA
were set(that is POSEDGE, NEGEDGE, PRESERVE), then in ipuv3-crtc.c, it
went using the old flags settings that were previously hardcoded.
The same applied for DRM_MODE_FLAG_POL_DE.
The patch using theses flags is the 08/12 of this same serie.
So as I understand you want to:
- do not change hw polarity settings by using preserve bit,
- keep the old behavior of the driver by setting all bits to zero.
I think this is the issue of the specific driver, and it should not
influence core structs.
I am not familiar with imx but I guess it should not be a problem
to solve the issue in the driver.
struct drm_display_mode {
[..]
+ unsigned int pol_flags;
Adding field and macros description to the DocBook would be nice.
So I will have to describe it in the Connector Helper Operations
section of drm.tmpl, right before the mode_valid synopsis ?
Yes, I think so.
Andrzej
Denis.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] v4l2-mem2mem: allow reqbufs(0) with in use MMAP buffers
Hello, On 2014-04-07 16:41, Kamil Debski wrote: Pawel, Marek, Before taking this to my tree I wanted to get an ACK from one of the videobuf2 maintainers. Could you spare a moment to look through this patch? It's not a bug, it is a feature. This was one of the fundamental design requirements to allow applications to track if the memory is used or not. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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 v12][ 06/12] ARM: dts: imx5*, imx6*: correct display-timings nodes.
On Mon, Apr 07, 2014 at 02:44:45PM +0200, Denis Carikli wrote:
The imx-drm driver can't use the de-active and
pixelclk-active display-timings properties yet.
Instead the data-enable and the pixel data clock
polarity are hardcoded in the imx-drm driver.
So theses properties are now set to keep
the same behaviour when imx-drm will start
using them.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v9-v10:
- New patch that was splitted out of:
staging imx-drm: Use de-active and pixelclk-active
display-timings.
---
arch/arm/boot/dts/imx51-babbage.dts |2 ++
arch/arm/boot/dts/imx53-m53evk.dts|2 ++
arch/arm/boot/dts/imx53-tx53-x03x.dts |2 +-
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi |2 ++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |2 ++
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi |2 ++
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |2 ++
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi |2 ++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi|2 ++
9 files changed, 17 insertions(+), 1 deletion(-)
...
diff --git a/arch/arm/boot/dts/imx53-tx53-x03x.dts
b/arch/arm/boot/dts/imx53-tx53-x03x.dts
index 0217dde3..4092a81 100644
--- a/arch/arm/boot/dts/imx53-tx53-x03x.dts
+++ b/arch/arm/boot/dts/imx53-tx53-x03x.dts
@@ -93,7 +93,7 @@
hsync-active = 0;
vsync-active = 0;
de-active = 1;
- pixelclk-active = 1;
+ pixelclk-active = 0;
@Lothar, is this change correct?
Shawn
};
ET0500 {
--
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 v12][ 12/12] ARM: imx_v6_v7_defconfig: Add more drm drivers.
On Mon, Apr 07, 2014 at 02:44:51PM +0200, Denis Carikli wrote: The DRM_PANEL_SIMPLE is needed by the eukrea mbimxsd51's displays. Signed-off-by: Denis Carikli de...@eukrea.com Applied, 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 v12][ 03/12] imx-drm: Correct BGR666 and the board's dts that use them.
On Mon, Apr 07, 2014 at 02:44:42PM +0200, Denis Carikli wrote:
arch/arm/boot/dts/imx51-apf51dev.dts|2 +-
arch/arm/boot/dts/imx53-m53evk.dts |2 +-
drivers/staging/imx-drm/imx-ldb.c |4 ++--
drivers/staging/imx-drm/ipu-v3/ipu-dc.c |4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-apf51dev.dts
b/arch/arm/boot/dts/imx51-apf51dev.dts
index c5a9a24..7b3851d 100644
--- a/arch/arm/boot/dts/imx51-apf51dev.dts
+++ b/arch/arm/boot/dts/imx51-apf51dev.dts
@@ -18,7 +18,7 @@
display@di1 {
compatible = fsl,imx-parallel-display;
- interface-pix-fmt = bgr666;
+ interface-pix-fmt = rgb666;
...
/* bgr666 */
ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
- ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
+ ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
- ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */
arm-soc people have become very obtuse with respect to changes to any
patches to arch/arm/boot/dts, and complain loudly if any changes to
that directory do not go through them as separate patches.
What this means is that your patch is unacceptable and needs to be split
up.
The choices seem to be to either break imx-drm by splitting the patch in
two, thereby ending up with the two dependent changes being merged
entirely separate, resulting in breakage while one or other is merged,
or to add the RGB666 support, wait for that to hit mainline, then
update the DT files, wait for that to hit mainline, then fix the BGR666
support. That'll take around six to nine months (two to three months
per release cycle.)
Or arm-soc could come to their senses and realise that they do not have
sole ownership over arch/arm/boot/dts.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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] s5c73m3: Add missing rename of v4l2_of_get_next_endpoint() function
This fixes following build error:
CC drivers/media/i2c/s5c73m3/s5c73m3-core.o
CC drivers/md/dm-ioctl.o
CC net/ipv4/inet_lro.o
drivers/media/i2c/s5c73m3/s5c73m3-core.c: In function
‘s5c73m3_get_platform_data’:
drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:2: error: implicit declaration of
function ‘v4l2_of_get_next_endpoint’ [-Werror=implicit-function-declaration]
drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:10: warning: assignment makes
pointer from integer without a cast [enabled by default]
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/i2c/s5c73m3/s5c73m3-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index a445930..ee0f57e 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -1616,7 +1616,7 @@ static int s5c73m3_get_platform_data(struct s5c73m3
*state)
if (ret 0)
return -EINVAL;
- node_ep = v4l2_of_get_next_endpoint(node, NULL);
+ node_ep = of_graph_get_next_endpoint(node, NULL);
if (!node_ep) {
dev_warn(dev, no endpoint defined for node: %s\n,
node-full_name);
--
1.7.9.5
--
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 v2] uvcvideo: Work around buggy Logitech C920 firmware
On 25/03/14 23:03, Laurent Pinchart wrote: Hi William, On Tuesday 25 March 2014 22:56:33 William Manley wrote: On 13/03/14 12:38, William Manley wrote: The uvcvideo webcam driver exposes the v4l2 control Exposure (Absolute) which allows the user to control the exposure time of the webcam, essentially controlling the brightness of the received image. By default the webcam automatically adjusts the exposure time automatically but the if you set the control Exposure, Auto=Manual Mode the user can fix the exposure time. Unfortunately it seems that the Logitech C920 has a firmware bug where it will forget that it's in manual mode temporarily during initialisation. This means that the camera doesn't respect the exposure time that the user requested if they request it before starting to stream video. They end up with a video stream which is either too bright or too dark and must reset the controls after video starts streaming. This patch introduces the quirk UVC_QUIRK_RESTORE_CTRLS_ON_INIT which causes the cached controls to be re-uploaded to the camera immediately after initialising the camera. This quirk is applied to the C920 to work around this camera bug. Changes since patch v1: * Introduce quirk so workaround is only applied to the C920. Signed-off-by: William Manley w...@williammanley.net Bump? Sorry, I haven't had the time to handle your patch yet. I'll try to do so on Thursday or Friday. Apologies for the nagging: What's the current status? Thanks Will -- 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
mini-summit: AVB Presentation
I'd like to give a small (20 min?) presentation about AVB (Audio Video Bridging, http://en.wikipedia.org/wiki/Audio_Video_Bridging) and possibilities to implement audio/video streaming and parts of AVDECC in ALSA/V4L2 (AVDECC = AVB Discovery, Enumeration, Connection management and Control). It's very early days, so this is more about what it is and what the advantages are of handling part of it in the kernel. 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: [RFC] Fix interrupted recording with Hauppauge HD-PVR
On 04/07/14 22:32, Ryley Angus wrote:
Thanks Hans for getting back to me.
I've been trying out your patch and I found the device wasn't actually
restarting the streaming/recording properly after a channel
change. I changed msecs_to_jiffies(500)) to msecs_to_jiffies(1000)) and
had the same issue, but msecs_to_jiffies(2000))
seems to be working well. I'll let it keep going for a few more hours, but
at the moment it seems to be working well. The recordings
can be ended without anything hanging, and turning off the device ends the
recording properly (mine neglected this occurrence).
I'll let you know if I have any more issues,
ryley
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, April 08, 2014 12:07 AM
To: Ryley Angus; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
Hi Ryley,
Thank you for the patch. Your analysis seems sound. The patch is actually
not bad for a first attempt, but I did it a bit differently.
Can you test my patch?
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..a61373e 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char __user
*buffer, size_t count,
if (buf-status != BUFSTAT_READY
dev-status != STATUS_DISCONNECTED) {
+ int err;
+
/* return nonblocking */
if (file-f_flags O_NONBLOCK) {
if (!ret)
@@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file, char
__user *buffer, size_t count,
goto err;
}
- if (wait_event_interruptible(dev-wait_data,
- buf-status == BUFSTAT_READY))
{
- ret = -ERESTARTSYS;
+ err =
wait_event_interruptible_timeout(dev-wait_data,
+ buf-status == BUFSTAT_READY,
+ msecs_to_jiffies(500));
+ if (err 0) {
+ ret = err;
goto err;
}
+ if (!err) {
+ v4l2_dbg(MSG_INFO, hdpvr_debug,
dev-v4l2_dev,
+ timeout: restart streaming\n);
+ hdpvr_stop_streaming(dev);
+ err = hdpvr_start_streaming(dev);
+ if (err) {
+ ret = err;
+ goto err;
+ }
+ }
}
if (buf-status != BUFSTAT_READY)
On 04/07/2014 02:04 AM, Ryley Angus wrote:
(Sorry in advance for probably breaking a few conventions of the
mailing lists. First time using one so please let me know what I'm
doing wrong)
I'm writing this because of an issue I had with my Hauppauge HD-PVR.
I record from my satellite set top box using component video and
optical audio input. I basically use cat /dev/video0 ~/video.ts
or use dd. The box is set to output audio as AC-3 over optical, but
most channels are actually output as stereo PCM. When the channel is
changed between a PCM channel and (typically to a movie channel) to a
channel utilising AC-3, the HD-PVR stops the recording as the set top
box momentarily outputs no audio. Changing between PCM channels
doesn't cause any issues.
My main problem was that when this happens, cat/dd doesn't actually
exit. When going through the hdpvr driver source and the dmesg output,
I found the hdpvr driver wasn't actually shutting down the device
properly until I manually killed cat/dd.
I've seen references to this issue being a hardware issue from as far
back as 2010:
http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on
-channel-change-Hauppauge-says-too-bad
.
I tracked my issue to the file hdpvr-video.c. Specifically, if
(wait_event_interruptible(dev-wait_data, buf-status =
BUFSTAT_READY)) { (line ~450). The device seems to get stuck waiting
for the buffer to become ready. But as far as I can tell, when the
channel is changed between a PCM and AC-3 broadcast the buffer status
will never actually become ready.
...
I've seen the same problem Ryley describes and handled it in user space
with a cat-like program that could detect stalls and re-open the hdpvr
device. This approach seems much better. Kudos to both Ryley and Hans.
I concur that the 500 ms. timeout is too small. When testing my
program, I tried using a variety of timeout values when I found that the
HD-PVR seems to require some delay following a close before it is
[PATCHv2 3/3] s5p-tv: hdmi: use hdmiphy as PHY
The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.
This patch makes S5P-HDMI driver to control HDMIPHY via PHY interface.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/media/platform/s5p-tv/hdmi_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c
b/drivers/media/platform/s5p-tv/hdmi_drv.c
index 534722c..8013e52 100644
--- a/drivers/media/platform/s5p-tv/hdmi_drv.c
+++ b/drivers/media/platform/s5p-tv/hdmi_drv.c
@@ -32,6 +32,7 @@
#include linux/clk.h
#include linux/regulator/consumer.h
#include linux/v4l2-dv-timings.h
+#include linux/phy/phy.h
#include media/s5p_hdmi.h
#include media/v4l2-common.h
@@ -66,7 +67,7 @@ struct hdmi_resources {
struct clk *sclk_hdmi;
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
- struct clk *hdmiphy;
+ struct phy *hdmiphy;
struct regulator_bulk_data *regul_bulk;
int regul_count;
};
@@ -586,7 +587,7 @@ static int hdmi_resource_poweron(struct hdmi_resources *res)
if (ret 0)
return ret;
/* power-on hdmi physical interface */
- clk_enable(res-hdmiphy);
+ phy_power_on(res-hdmiphy);
/* use VPP as parent clock; HDMIPHY is not working yet */
clk_set_parent(res-sclk_hdmi, res-sclk_pixel);
/* turn clocks on */
@@ -600,7 +601,7 @@ static void hdmi_resource_poweroff(struct hdmi_resources
*res)
/* turn clocks off */
clk_disable(res-sclk_hdmi);
/* power-off hdmiphy */
- clk_disable(res-hdmiphy);
+ phy_power_off(res-hdmiphy);
/* turn HDMI power off */
regulator_bulk_disable(res-regul_count, res-regul_bulk);
}
@@ -784,7 +785,7 @@ static void hdmi_resources_cleanup(struct hdmi_device *hdev)
/* kfree is NULL-safe */
kfree(res-regul_bulk);
if (!IS_ERR(res-hdmiphy))
- clk_put(res-hdmiphy);
+ phy_put(res-hdmiphy);
if (!IS_ERR(res-sclk_hdmiphy))
clk_put(res-sclk_hdmiphy);
if (!IS_ERR(res-sclk_pixel))
@@ -835,7 +836,7 @@ static int hdmi_resources_init(struct hdmi_device *hdev)
dev_err(dev, failed to get clock 'sclk_hdmiphy'\n);
goto fail;
}
- res-hdmiphy = clk_get(dev, hdmiphy);
+ res-hdmiphy = phy_get(dev, hdmiphy);
if (IS_ERR(res-hdmiphy)) {
dev_err(dev, failed to get clock 'hdmiphy'\n);
goto fail;
--
1.7.9.5
--
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
[PATCHv2 2/3] drm: exynos: hdmi: use hdmiphy as PHY
The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.
This patch makes HDMI driver to control HDMIPHY via PHY interface.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..ef1cdd0 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -36,6 +36,7 @@
#include linux/i2c.h
#include linux/of_gpio.h
#include linux/hdmi.h
+#include linux/phy/phy.h
#include drm/exynos_drm.h
@@ -74,8 +75,8 @@ struct hdmi_resources {
struct clk *sclk_hdmi;
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
- struct clk *hdmiphy;
struct clk *mout_hdmi;
+ struct phy *hdmiphy;
struct regulator_bulk_data *regul_bulk;
int regul_count;
};
@@ -1854,7 +1855,7 @@ static void hdmi_poweron(struct exynos_drm_display
*display)
if (regulator_bulk_enable(res-regul_count, res-regul_bulk))
DRM_DEBUG_KMS(failed to enable regulator bulk\n);
- clk_prepare_enable(res-hdmiphy);
+ phy_power_on(res-hdmiphy);
clk_prepare_enable(res-hdmi);
clk_prepare_enable(res-sclk_hdmi);
@@ -1881,7 +1882,7 @@ static void hdmi_poweroff(struct exynos_drm_display
*display)
clk_disable_unprepare(res-sclk_hdmi);
clk_disable_unprepare(res-hdmi);
- clk_disable_unprepare(res-hdmiphy);
+ phy_power_off(res-hdmiphy);
regulator_bulk_disable(res-regul_count, res-regul_bulk);
pm_runtime_put_sync(hdata-dev);
@@ -1977,9 +1978,9 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
DRM_ERROR(failed to get clock 'sclk_hdmiphy'\n);
goto fail;
}
- res-hdmiphy = devm_clk_get(dev, hdmiphy);
+ res-hdmiphy = devm_phy_get(dev, hdmiphy);
if (IS_ERR(res-hdmiphy)) {
- DRM_ERROR(failed to get clock 'hdmiphy'\n);
+ DRM_ERROR(failed to get phy 'hdmiphy'\n);
goto fail;
}
res-mout_hdmi = devm_clk_get(dev, mout_hdmi);
--
1.7.9.5
--
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
[PATCHv2 1/3] phy: Add exynos-simple-phy driver
Add exynos-simple-phy driver to support a single register
PHY interfaces present on Exynos4 SoC.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 24 +++
drivers/phy/Kconfig|5 +
drivers/phy/Makefile |1 +
drivers/phy/exynos-simple-phy.c| 154
4 files changed, 184 insertions(+)
create mode 100644 drivers/phy/exynos-simple-phy.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..f97c4c3 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,27 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung S5P/EXYNOS SoC series SIMPLE PHY
+-
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+ - samsung,exynos4210-simple-phy
+ - samsung,exynos4412-simple-phy
+- reg : offset and length of the register set;
+- #phy-cells : from the generic phy bindings, must be 1;
+
+For samsung,exynos4210-simple-phy compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+ 0 - HDMI PHY,
+ 1 - DAC PHY,
+ 2 - ADC PHY,
+ 3 - PCIE PHY.
+ 4 - SATA PHY.
+
+For samsung,exynos4412-simple-phy compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+ 0 - HDMI PHY,
+ 1 - ADC PHY,
+
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..65ab783 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,9 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config EXYNOS_SIMPLE_PHY
+ tristate Exynos Simple PHY driver
+ help
+ Support for 1-bit PHY controllers on SoCs from Exynos family.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..88c5b60 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
+obj-$(CONFIG_EXYNOS_SIMPLE_PHY)+= exynos-simple-phy.o
diff --git a/drivers/phy/exynos-simple-phy.c b/drivers/phy/exynos-simple-phy.c
new file mode 100644
index 000..57ad338
--- /dev/null
+++ b/drivers/phy/exynos-simple-phy.c
@@ -0,0 +1,154 @@
+/*
+ * Exynos Simple PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tomasz Stanislawski t.stanisl...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/phy/phy.h
+
+#define EXYNOS_PHY_ENABLE (1 0)
+
+static int exynos_phy_power_on(struct phy *phy)
+{
+ void __iomem *reg = phy_get_drvdata(phy);
+ u32 val;
+
+ val = readl(reg);
+ val |= EXYNOS_PHY_ENABLE;
+ writel(val, reg);
+
+ return 0;
+}
+
+static int exynos_phy_power_off(struct phy *phy)
+{
+ void __iomem *reg = phy_get_drvdata(phy);
+ u32 val;
+
+ val = readl(reg);
+ val = ~EXYNOS_PHY_ENABLE;
+ writel(val, reg);
+
+ return 0;
+}
+
+static struct phy_ops exynos_phy_ops = {
+ .power_on = exynos_phy_power_on,
+ .power_off = exynos_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static const u32 exynos4210_offsets[] = {
+ 0x0700, /* HDMI_PHY */
+ 0x070C, /* DAC_PHY */
+ 0x0718, /* ADC_PHY */
+ 0x071C, /* PCIE_PHY */
+ 0x0720, /* SATA_PHY */
+ ~0, /* end mark */
+};
+
+static const u32 exynos4412_offsets[] = {
+ 0x0700, /* HDMI_PHY */
+ 0x0718, /* ADC_PHY */
+ ~0, /* end mark */
+};
+
+static const struct of_device_id exynos_phy_of_match[] = {
+ { .compatible = samsung,exynos4210-simple-phy,
+ .data = exynos4210_offsets},
+ { .compatible = samsung,exynos4412-simple-phy,
+ .data = exynos4412_offsets},
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_phy_of_match);
+
+static struct phy *exynos_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct phy **phys = dev_get_drvdata(dev);
+ int index = args-args[0];
+ int i;
+
+ /* verify if index is valid */
+ for (i = 0; i = index; ++i)
+
[PATCHv2 0/3] phy: Add exynos-simple-phy driver
Hello everyone, The Samsung SoCs from Exynos family are enhanced with a bunch of devices that provide functionality of a physical layer for interfaces like USB, HDMI, SATA, etc. They are controlled by a simple interface, often a single bit that enables and/or resets the physical layer. An IP driver should to control such a controller in an abstract manner. Therefore, such 'enablers' were implemented as clocks in older versions of Linux kernel. With the dawn of PHY subsystems, PHYs become a natural way of exporting the 'enabler' functionality to drivers. However, there is an unexpected consequence. Some of those 1-bit PHYs were implemented as separate drivers. This means that one has to create a struct device, struct phy, its phy provider and 100-150 lines of driver code to basically set one bit. The DP phy driver is a good example: https://lkml.org/lkml/2013/7/18/53 And simple-phy RFC (shares only driver code but not other resources): https://lkml.org/lkml/2013/10/21/313 To avoid waste of resources I propose to create all such 1-bit phys from Exynos SoC using a single device, driver and phy provider. This patchset contains a proposed solution. All comment are welcome. Hopefully in future the functionality introduced by this patch may be merged into a larger Power Management Unit (PMU) gluer driver. On Samsusng SoC , the PMU part contains a number of register barely linked to power management (like clock gating, clock dividers, CPU resetting, etc.). It may be tempting to create a hybrid driver that export clocks/phys/etc that are controlled by PMU unit. Alternative solutions might be: * exporting a regmap to the IP driver and allow the driver to control the PHY layer like in the patch: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/28617/focus=28648 * create a dedicated power domain for hdmiphy Regards, Tomasz Stanislawski Changelog: v2: * rename to exynos-simple-phy * fix usage of devm_ioremap() * add documentation for DT bindings * add patches to client drivers v1: initial version Tomasz Stanislawski (3): phy: Add exynos-simple-phy driver drm: exynos: hdmi: use hdmiphy as PHY s5p-tv: hdmi: use hdmiphy as PHY .../devicetree/bindings/phy/samsung-phy.txt| 24 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 11 +- drivers/media/platform/s5p-tv/hdmi_drv.c | 11 +- drivers/phy/Kconfig|5 + drivers/phy/Makefile |1 + drivers/phy/exynos-simple-phy.c| 154 6 files changed, 196 insertions(+), 10 deletions(-) create mode 100644 drivers/phy/exynos-simple-phy.c -- 1.7.9.5 -- 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 v3 4/6] v4l: vsp1: Add DT support
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
.../devicetree/bindings/media/renesas,vsp1.txt | 43 ++
drivers/media/platform/vsp1/vsp1_drv.c | 52 ++
2 files changed, 87 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.txt
Hi,
This is the second last call (I'm perfectly aware of the logic flaw in this
sentence, thank you :-)) for DT bindings review, with a small change to the
bindings wording compared to v2. I plan to send a pull request at the end of
the week.
Changes since v2:
- Remove the interrupt-parent property
- Drop of_match_ptr() as the table is always compiled in
Changes since v1:
- Drop the clock-names property, as the VSP1 uses a single clock
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
new file mode 100644
index 000..87fe08a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -0,0 +1,43 @@
+* Renesas VSP1 Video Processing Engine
+
+The VSP1 is a video processing engine that supports up-/down-scaling, alpha
+blending, color space conversion and various other image processing features.
+It can be found in the Renesas R-Car second generation SoCs.
+
+Required properties:
+
+ - compatible: Must contain renesas,vsp1
+
+ - reg: Base address and length of the registers block for the VSP1.
+ - interrupts: VSP1 interrupt specifier.
+ - clocks: A phandle + clock-specifier pair for the VSP1 functional clock.
+
+ - renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1.
+ - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1.
+ - renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1.
+
+
+Optional properties:
+
+ - renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is
+available.
+ - renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is
+available.
+ - renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU)
+module is available.
+
+
+Example: R8A7790 (R-Car H2) VSP1-S node
+
+ vsp1@fe928000 {
+ compatible = renesas,vsp1;
+ reg = 0 0xfe928000 0 0x8000;
+ interrupts = 0 267 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp1_clks R8A7790_CLK_VSP1_S;
+
+ renesas,has-lut;
+ renesas,has-sru;
+ renesas,#rpf = 5;
+ renesas,#uds = 3;
+ renesas,#wpf = 4;
+ };
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 28e1de3..c69ee06 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -16,6 +16,7 @@
#include linux/device.h
#include linux/interrupt.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/videodev2.h
@@ -431,34 +432,59 @@ static const struct dev_pm_ops vsp1_pm_ops = {
* Platform Driver
*/
-static struct vsp1_platform_data *
-vsp1_get_platform_data(struct platform_device *pdev)
+static int vsp1_validate_platform_data(struct platform_device *pdev,
+ struct vsp1_platform_data *pdata)
{
- struct vsp1_platform_data *pdata = pdev-dev.platform_data;
-
if (pdata == NULL) {
dev_err(pdev-dev, missing platform data\n);
- return NULL;
+ return -EINVAL;
}
if (pdata-rpf_count = 0 || pdata-rpf_count VPS1_MAX_RPF) {
dev_err(pdev-dev, invalid number of RPF (%u)\n,
pdata-rpf_count);
- return NULL;
+ return -EINVAL;
}
if (pdata-uds_count = 0 || pdata-uds_count VPS1_MAX_UDS) {
dev_err(pdev-dev, invalid number of UDS (%u)\n,
pdata-uds_count);
- return NULL;
+ return -EINVAL;
}
if (pdata-wpf_count = 0 || pdata-wpf_count VPS1_MAX_WPF) {
dev_err(pdev-dev, invalid number of WPF (%u)\n,
pdata-wpf_count);
- return NULL;
+ return -EINVAL;
}
+ return 0;
+}
+
+static struct vsp1_platform_data *
+vsp1_get_platform_data(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct vsp1_platform_data *pdata;
+
+ if (!IS_ENABLED(CONFIG_OF) || np == NULL)
+ return pdev-dev.platform_data;
+
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (pdata == NULL)
+ return NULL;
+
+ if (of_property_read_bool(np, renesas,has-lif))
+ pdata-features |= VSP1_HAS_LIF;
+ if (of_property_read_bool(np, renesas,has-lut))
+ pdata-features |= VSP1_HAS_LUT;
+ if (of_property_read_bool(np,
drivers/media/tuners/r820t.c:1534:3-9: Replace memcpy with struct assignment
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: a7963eb7f4c4b5df84d5dd5083734278ad75bafb
commit: 25cf4d462abd6d78d224b564de82dcdab7973673 [media] r820t: add IMR
calibrate code
date: 12 months ago
coccinelle warnings: (new ones prefixed by )
drivers/media/tuners/r820t.c:1534:3-9: Replace memcpy with struct assignment
Please consider folding the attached diff :-)
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
From: Fengguang Wu fengguang...@intel.com
Subject: [PATCH] [media] r820t: fix coccinelle warnings
TO: Mauro Carvalho Chehab mche...@redhat.com
CC: Mauro Carvalho Chehab mche...@redhat.com
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
drivers/media/tuners/r820t.c:1534:3-9: Replace memcpy with struct assignment
Generated by: scripts/coccinelle/misc/memcpy-assign.cocci
CC: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
r820t.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -1531,7 +1531,7 @@ static int r820t_imr_cross(struct r820t_
cross[i].value = rc;
if (cross[i].value tmp.value)
- memcpy(tmp, cross[i], sizeof(tmp));
+ tmp = cross[i];
}
if ((tmp.phase_y 0x1f) == 1) { /* y-direction */
Re: [PATCH v3 4/6] v4l: vsp1: Add DT support
Hi Laurent,
On 08/04/14 18:16, Laurent Pinchart wrote:
It may be worth to split DT binding documentation and the driver changes
into separate patches, and perhaps add some commit description here.
Either way fell free to stick:
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
.../devicetree/bindings/media/renesas,vsp1.txt | 43 ++
drivers/media/platform/vsp1/vsp1_drv.c | 52
++
2 files changed, 87 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.txt
Hi,
This is the second last call (I'm perfectly aware of the logic flaw in this
sentence, thank you :-)) for DT bindings review, with a small change to the
bindings wording compared to v2. I plan to send a pull request at the end of
the week.
Changes since v2:
- Remove the interrupt-parent property
- Drop of_match_ptr() as the table is always compiled in
Changes since v1:
- Drop the clock-names property, as the VSP1 uses a single clock
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
new file mode 100644
index 000..87fe08a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -0,0 +1,43 @@
+* Renesas VSP1 Video Processing Engine
+
+The VSP1 is a video processing engine that supports up-/down-scaling, alpha
+blending, color space conversion and various other image processing features.
+It can be found in the Renesas R-Car second generation SoCs.
+
+Required properties:
+
+ - compatible: Must contain renesas,vsp1
+
+ - reg: Base address and length of the registers block for the VSP1.
+ - interrupts: VSP1 interrupt specifier.
+ - clocks: A phandle + clock-specifier pair for the VSP1 functional clock.
+
+ - renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1.
+ - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1.
+ - renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1.
+
+
+Optional properties:
+
+ - renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module
is
+available.
+ - renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module
is
+available.
+ - renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU)
+module is available.
+
+
+Example: R8A7790 (R-Car H2) VSP1-S node
+
+ vsp1@fe928000 {
+ compatible = renesas,vsp1;
+ reg = 0 0xfe928000 0 0x8000;
+ interrupts = 0 267 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp1_clks R8A7790_CLK_VSP1_S;
+
+ renesas,has-lut;
+ renesas,has-sru;
+ renesas,#rpf = 5;
+ renesas,#uds = 3;
+ renesas,#wpf = 4;
+ };
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 28e1de3..c69ee06 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -16,6 +16,7 @@
#include linux/device.h
#include linux/interrupt.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/videodev2.h
@@ -431,34 +432,59 @@ static const struct dev_pm_ops vsp1_pm_ops = {
* Platform Driver
*/
-static struct vsp1_platform_data *
-vsp1_get_platform_data(struct platform_device *pdev)
+static int vsp1_validate_platform_data(struct platform_device *pdev,
+struct vsp1_platform_data *pdata)
{
- struct vsp1_platform_data *pdata = pdev-dev.platform_data;
-
if (pdata == NULL) {
dev_err(pdev-dev, missing platform data\n);
- return NULL;
+ return -EINVAL;
}
if (pdata-rpf_count = 0 || pdata-rpf_count VPS1_MAX_RPF) {
dev_err(pdev-dev, invalid number of RPF (%u)\n,
pdata-rpf_count);
- return NULL;
+ return -EINVAL;
}
if (pdata-uds_count = 0 || pdata-uds_count VPS1_MAX_UDS) {
dev_err(pdev-dev, invalid number of UDS (%u)\n,
pdata-uds_count);
- return NULL;
+ return -EINVAL;
}
if (pdata-wpf_count = 0 || pdata-wpf_count VPS1_MAX_WPF) {
dev_err(pdev-dev, invalid number of WPF (%u)\n,
pdata-wpf_count);
- return NULL;
+ return -EINVAL;
}
+ return 0;
+}
+
+static struct vsp1_platform_data *
+vsp1_get_platform_data(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct vsp1_platform_data *pdata;
+
+ if (!IS_ENABLED(CONFIG_OF) || np == NULL)
+ return pdev-dev.platform_data;
+
+ pdata = devm_kzalloc(pdev-dev,
[PATCH v4 4.1/6] v4l: vsp1: Add DT bindings documentation
All parameters supplied through platform data can now be passed through
the device tree.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../devicetree/bindings/media/renesas,vsp1.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.txt
Changes since v3:
- Split DT bindings documentation and support in the driver to seperate patches
- Add a more verbose commit message
Changes since v2:
- Remove the interrupt-parent property
- Drop of_match_ptr() as the table is always compiled in
Changes since v1:
- Drop the clock-names property, as the VSP1 uses a single clock
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
new file mode 100644
index 000..87fe08a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -0,0 +1,43 @@
+* Renesas VSP1 Video Processing Engine
+
+The VSP1 is a video processing engine that supports up-/down-scaling, alpha
+blending, color space conversion and various other image processing features.
+It can be found in the Renesas R-Car second generation SoCs.
+
+Required properties:
+
+ - compatible: Must contain renesas,vsp1
+
+ - reg: Base address and length of the registers block for the VSP1.
+ - interrupts: VSP1 interrupt specifier.
+ - clocks: A phandle + clock-specifier pair for the VSP1 functional clock.
+
+ - renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1.
+ - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1.
+ - renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1.
+
+
+Optional properties:
+
+ - renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is
+available.
+ - renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is
+available.
+ - renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU)
+module is available.
+
+
+Example: R8A7790 (R-Car H2) VSP1-S node
+
+ vsp1@fe928000 {
+ compatible = renesas,vsp1;
+ reg = 0 0xfe928000 0 0x8000;
+ interrupts = 0 267 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp1_clks R8A7790_CLK_VSP1_S;
+
+ renesas,has-lut;
+ renesas,has-sru;
+ renesas,#rpf = 5;
+ renesas,#uds = 3;
+ renesas,#wpf = 4;
+ };
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4.2/6] v4l: vsp1: Add DT support
Implement support for the VSP1 DT bindings in the VSP1 driver. The
driver now first retrieves platform data either from the platform data
pointer or by reading the device tree node, and then validates it
regardless of the platform data source.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/vsp1/vsp1_drv.c | 52 --
1 file changed, 44 insertions(+), 8 deletions(-)
Changes since v3:
- Split DT bindings documentation and support in the driver to seperate patches
- Add a more verbose commit message
Changes since v2:
- Drop of_match_ptr() as the table is always compiled in
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 28e1de3..c69ee06 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -16,6 +16,7 @@
#include linux/device.h
#include linux/interrupt.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/videodev2.h
@@ -431,34 +432,59 @@ static const struct dev_pm_ops vsp1_pm_ops = {
* Platform Driver
*/
-static struct vsp1_platform_data *
-vsp1_get_platform_data(struct platform_device *pdev)
+static int vsp1_validate_platform_data(struct platform_device *pdev,
+ struct vsp1_platform_data *pdata)
{
- struct vsp1_platform_data *pdata = pdev-dev.platform_data;
-
if (pdata == NULL) {
dev_err(pdev-dev, missing platform data\n);
- return NULL;
+ return -EINVAL;
}
if (pdata-rpf_count = 0 || pdata-rpf_count VPS1_MAX_RPF) {
dev_err(pdev-dev, invalid number of RPF (%u)\n,
pdata-rpf_count);
- return NULL;
+ return -EINVAL;
}
if (pdata-uds_count = 0 || pdata-uds_count VPS1_MAX_UDS) {
dev_err(pdev-dev, invalid number of UDS (%u)\n,
pdata-uds_count);
- return NULL;
+ return -EINVAL;
}
if (pdata-wpf_count = 0 || pdata-wpf_count VPS1_MAX_WPF) {
dev_err(pdev-dev, invalid number of WPF (%u)\n,
pdata-wpf_count);
- return NULL;
+ return -EINVAL;
}
+ return 0;
+}
+
+static struct vsp1_platform_data *
+vsp1_get_platform_data(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct vsp1_platform_data *pdata;
+
+ if (!IS_ENABLED(CONFIG_OF) || np == NULL)
+ return pdev-dev.platform_data;
+
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (pdata == NULL)
+ return NULL;
+
+ if (of_property_read_bool(np, renesas,has-lif))
+ pdata-features |= VSP1_HAS_LIF;
+ if (of_property_read_bool(np, renesas,has-lut))
+ pdata-features |= VSP1_HAS_LUT;
+ if (of_property_read_bool(np, renesas,has-sru))
+ pdata-features |= VSP1_HAS_SRU;
+
+ of_property_read_u32(np, renesas,#rpf, pdata-rpf_count);
+ of_property_read_u32(np, renesas,#uds, pdata-uds_count);
+ of_property_read_u32(np, renesas,#wpf, pdata-wpf_count);
+
return pdata;
}
@@ -481,6 +507,10 @@ static int vsp1_probe(struct platform_device *pdev)
if (vsp1-pdata == NULL)
return -ENODEV;
+ ret = vsp1_validate_platform_data(pdev, vsp1-pdata);
+ if (ret 0)
+ return ret;
+
/* I/O, IRQ and clock resources */
io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
vsp1-mmio = devm_ioremap_resource(pdev-dev, io);
@@ -527,6 +557,11 @@ static int vsp1_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id vsp1_of_match[] = {
+ { .compatible = renesas,vsp1 },
+ { },
+};
+
static struct platform_driver vsp1_platform_driver = {
.probe = vsp1_probe,
.remove = vsp1_remove,
@@ -534,6 +569,7 @@ static struct platform_driver vsp1_platform_driver = {
.owner = THIS_MODULE,
.name = vsp1,
.pm = vsp1_pm_ops,
+ .of_match_table = vsp1_of_match,
},
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] uvcvideo: Fix clock param realtime setting
Hi Olivier, On Wednesday 02 April 2014 00:31:59 Olivier Langlois wrote: On Tue, 2014-04-01 at 15:49 +0200, Laurent Pinchart wrote: On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote: Yes. ffmpeg uses wall clock time to create timestamps for audio packets from ALSA device. OK. I suppose I shouldn't drop support for the realtime clock like I wanted to then :-) There is a bug in ffmpeg describing problems to synchronize audio and the video from a v4l2 webcam. https://trac.ffmpeg.org/ticket/692 To workaround this issue, ffmpeg devs added a switch to convert back monotonic to realtime. From ffmpeg/libavdevice/v4l2.c: -tsint.D set type of timestamps for grabbed frames (from 0 to 2) (default 0) default .D use timestamps from the kernel abs .D use absolute timestamps (wall clock) mono2abs .D force conversion from monotonic to absolute timestamps If the v4l2 driver is able to send realtime ts, it is easier synchronize in userspace if all inputs use the same clock. That might be a stupid question, but shouldn't ALSA use the monotonic clock instead ? I think that I have that answer why ffmpeg use realtime clock for ALSA data. In fact ffmpeg uses realtime clock for every data coming from capture devices and the purpose is to be able to seek into the recorded stream by using the date where the recording occured. Same principle than a camera recording dates when pictures are taken. now a tougher question is whether or not it is up to the driver to provide these realtime ts. It makes sense to associate a wall time with recorded streams for that purpose, but synchronization should in my opinion be performed using the monotonic clock, as the wall time can jump around. I believe drivers should provide monotonic timestamps only. However, given that the uvcvideo driver has the option of providing wall clock timestamps, that option should work, so your patch makes sense. I'd still like to remove support for the wall clock though, but I don't want to break userspace. ffmpeg should be fixed, especially given that most V4L devices provide monotonic timestamps only. Please do not stop yourself to remove realtime ts support in your driver because that would not break ffmpeg, IMHO. It is just me that have tried to leverage options offered by your driver to remove the need to use ffmpeg workaround for a sync issue. I apparently have been the first ffmpeg user to try out! Then let's fix it first, and then I'll remove the option :-) I am currently in the process to contribute the introduction of using CLOCK_MONOTONIC inside ffmpeg. CCing their list because I think your reply is relevant to the discussion we have on the topic there at the moment. Very nice. Please keep me informed of the progress. -- Regards, Laurent Pinchart -- 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: [RFC] Fix interrupted recording with Hauppauge HD-PVR
Hi Kyle.
It may be possible that the delay in acceptable grace periods is due to a
difference in our input AV sources more so than the Hauppauge units
themselves. I'm wondering if it would be useful to control the timeout
period via a module parameter that defaults to 3 seconds perhaps?
As far as the issues with concatenated output, I've just looked at the files
containing a channel change and realized that VLC does show the duration as
0:00. Seeking with a keyboard isn't functional. Seeking with the timeline
and a mouse is fine. Avidemux seems to have trouble editing the file. If I
cut a section from a file that is from a single recording session it's
duration is correct, sync is correct and audio properties are correct. I
cannot cut across segments. MPC-HC also has duration issues with the
recording.
If I run the recordings through ffmpeg -fflags +genpts -I INPUT -c:v copy
-c:a copy OUTPUT, the resultant file duration is correct in VLC, I can
seek with the keyboard and mouse and editing is perfect with Avidemux. But
would it be better if the device just cleanly stopped recording instead of
automatically resuming? Or, continuing with the module parameters idea,
could we determine whether or not it will automatically restart based off a
module parameter?
I feel bad for not noticing the VLC issues earlier, but I mostly just use
VLC to broadcast the recordings through my home network to client instances
of VLC. This works well, but obviously seeking isn't relevant.
ryley
-Original Message-
From: Keith Pyle [mailto:kp...@austin.rr.com]
Sent: Wednesday, April 09, 2014 12:28 AM
To: Ryley Angus; 'Hans Verkuil'; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
On 04/07/14 22:32, Ryley Angus wrote:
Thanks Hans for getting back to me.
I've been trying out your patch and I found the device wasn't actually
restarting the streaming/recording properly after a channel change. I
changed msecs_to_jiffies(500)) to msecs_to_jiffies(1000)) and had
the same issue, but msecs_to_jiffies(2000))
seems to be working well. I'll let it keep going for a few more hours,
but at the moment it seems to be working well. The recordings can be
ended without anything hanging, and turning off the device ends the
recording properly (mine neglected this occurrence).
I'll let you know if I have any more issues,
ryley
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, April 08, 2014 12:07 AM
To: Ryley Angus; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
Hi Ryley,
Thank you for the patch. Your analysis seems sound. The patch is
actually not bad for a first attempt, but I did it a bit differently.
Can you test my patch?
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..a61373e 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char
__user *buffer, size_t count,
if (buf-status != BUFSTAT_READY
dev-status != STATUS_DISCONNECTED) {
+ int err;
+
/* return nonblocking */
if (file-f_flags O_NONBLOCK) {
if (!ret)
@@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file,
char __user *buffer, size_t count,
goto err;
}
- if (wait_event_interruptible(dev-wait_data,
- buf-status == BUFSTAT_READY))
{
- ret = -ERESTARTSYS;
+ err =
wait_event_interruptible_timeout(dev-wait_data,
+ buf-status == BUFSTAT_READY,
+ msecs_to_jiffies(500));
+ if (err 0) {
+ ret = err;
goto err;
}
+ if (!err) {
+ v4l2_dbg(MSG_INFO, hdpvr_debug,
dev-v4l2_dev,
+ timeout: restart streaming\n);
+ hdpvr_stop_streaming(dev);
+ err = hdpvr_start_streaming(dev);
+ if (err) {
+ ret = err;
+ goto err;
+ }
+ }
}
if (buf-status != BUFSTAT_READY)
On 04/07/2014 02:04 AM, Ryley Angus wrote:
(Sorry in advance for probably breaking a few conventions of the
mailing lists. First time using one so please let me know what I'm
doing wrong)
gspca second isoc endpoint / kinect depth
Hi, I took drivers/media/usb/gspca/kinect.c as skeleton to build a depth driver for the kinect camera. I needed to implement this feature because libfreenect performs so badly on the raspberry pi that you can't get a single frame. The kinecet has two isoc endpoints but gspca only uses the first. To get it running I made a dirty hack to drivers/media/usb/gspca/gspca.c I changed usb_host_endpoint *alt_xfer(...) so that it always returns the second endpoint, which is not really good for everyone. My driver is not ready for upstream now, it can not coexist with the current gspca_kinect so you have to decide if you want to load the video or the depth driver. Would be better to have one driver to do it all. But in the meantime I would like to ask for ideas about a more clean solution to get other isoc endpoints. There was already a little discussion about this when kinect.c was written by Antonio Ospite: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/26194 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/26213 Has something changed? Is there a point against making multiple endpoints available? Better solution? I am new to device drivers so I hope you can help me with this. Regards, Alexander btw: Thanks for the gspca framework, I started writing a standalone driver from scratch but the isoc handling f* me up a bit. Sorry for my poor English! -- 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: [RFC] Fix interrupted recording with Hauppauge HD-PVR
On 04/08/14 12:07, Ryley Angus wrote: Hi Kyle. It may be possible that the delay in acceptable grace periods is due to a difference in our input AV sources more so than the Hauppauge units themselves. I'm wondering if it would be useful to control the timeout period via a module parameter that defaults to 3 seconds perhaps? As far as the issues with concatenated output, I've just looked at the files containing a channel change and realized that VLC does show the duration as 0:00. Seeking with a keyboard isn't functional. Seeking with the timeline and a mouse is fine. Avidemux seems to have trouble editing the file. If I cut a section from a file that is from a single recording session it's duration is correct, sync is correct and audio properties are correct. I cannot cut across segments. MPC-HC also has duration issues with the recording. If I run the recordings through ffmpeg -fflags +genpts -I INPUT -c:v copy -c:a copy OUTPUT, the resultant file duration is correct in VLC, I can seek with the keyboard and mouse and editing is perfect with Avidemux. But would it be better if the device just cleanly stopped recording instead of automatically resuming? Or, continuing with the module parameters idea, could we determine whether or not it will automatically restart based off a module parameter? I feel bad for not noticing the VLC issues earlier, but I mostly just use VLC to broadcast the recordings through my home network to client instances of VLC. This works well, but obviously seeking isn't relevant. ryley ... I doubt that the multiple segment problem can be easily fixed in the hdpvr Linux driver. With the caveat that I'm far away from being an expert on MPEG, TS, and the like, I believe that the HD-PVR encoder generates the timing data into the stream with its origin being defined when the encoder starts the stream. So, if the capture is restarted, the encoder is re-initialized by the HD-PVR firmware and the result is a new origin for the following stream segment. The only real fix would be in the HD-PVR firmware - which we can't get and is why we have this problem in the first place. Regardless of this problem, I think the proposed driver patch is a distinct improvement over the current situation. Without the patch, we get truncated recordings. With the patch, we get nearly complete recordings which have skip issues. As you noted, this problem may be fixed with ffmpeg. Keith -- 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: [v2] media: soc-camera: OF cameras
Thanks Josh, I think I will take you point and rework my patch again.
But I need Guennadi's review firstly, Guennadi, could you please help
to review it?
-Bryan
On Fri, Mar 14, 2014 at 3:48 AM, Josh Wu josh...@atmel.com wrote:
Hi, Brayn
Sorry for the format of my email. I subscribe the linux-media maillist but
I didn't find your email in my mailbox even. I don't know why some emails are
missed.
anyway, Some comments for your patch.
[snip]
... ...
+static void scan_of_host(struct soc_camera_host *ici)
+{
+ struct soc_camera_of_client *sofc;
+ struct soc_camera_async_client *sasc;
+ struct v4l2_async_subdev *asd;
+ struct soc_camera_device *icd;
+ struct device_node *node = NULL;
+
+ for (;;) {
+ int ret;
+
+ node = v4l2_of_get_next_endpoint(ici-v4l2_dev.dev-of_node,
+ node);
+ if (!node)
+ break;
+
+ sofc = soc_camera_of_alloc_client(ici, node);
+ if (!sofc) {
+ dev_err(ici-v4l2_dev.dev,
+ %s(): failed to create a client device\n,
+ __func__);
+ of_node_put(node);
+ break;
+ }
+ v4l2_of_parse_endpoint(node, sofc-node);
+
+ sasc = sofc-sasc;
+ ret = platform_device_add(sasc-pdev);
+ if (ret 0) {
+ /* Useless thing, but keep trying */
+ platform_device_put(sasc-pdev);
+ of_node_put(node);
+ continue;
+ }
+
+ /* soc_camera_pdrv_probe() probed successfully */
+ icd = platform_get_drvdata(sasc-pdev);
+ if (!icd) {
+ /* Cannot be... */
+ platform_device_put(sasc-pdev);
+ of_node_put(node);
+ continue;
+ }
+
+ asd = sasc-sensor;
+ asd-match_type = V4L2_ASYNC_MATCH_OF;
+ asd-match.of.node = sofc-link_node;
+
+ sasc-notifier.subdevs = asd;
+ sasc-notifier.num_subdevs = 1;
+ sasc-notifier.bound = soc_camera_async_bound;
+ sasc-notifier.unbind = soc_camera_async_unbind;
+ sasc-notifier.complete = soc_camera_async_complete;
+
+ icd-parent = ici-v4l2_dev.dev;
Before register the notifier, you need also register a mclk v4l2 clock.
This clock is needed when the soc-camera i2c sensor driver is probed.
Otherwise the
sensor will always defer the probe and can not probe.
Best Regards,
Josh Wu
+
+ ret = v4l2_async_notifier_register(ici-v4l2_dev,
sasc-notifier);
+ if (!ret)
+ break;
+
+ /*
+* We could destroy the icd in there error case here, but the
+* non-OF version doesn't do that, so, we can keep it around
too
+*/
+ }
+}
[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Apr 9 04:01:04 CEST 2014 git branch: test git hash: a83b93a7480441a47856dc9104bea970e84cda87 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.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: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/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
