[RFC/PATCH v2 2/5] drm: Connect live source to framebuffers
Introduce a new live source flag for framebuffers. When a framebuffer is
created with that flag set, a live source is associated with the
framebuffer instead of buffer objects. The framebuffer can then be used
with a plane to connect it with the live source.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/drm_crtc.c | 123 +++-
include/uapi/drm/drm_mode.h | 7 +++
2 files changed, 107 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1f71978b4f17..838fd5051a00 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3408,31 +3408,13 @@ static int format_check(const struct drm_mode_fb_cmd2
*r)
}
}
-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
+static int framebuffer_check_buffers(const struct drm_mode_fb_cmd2 *r,
+int hsub, int vsub)
{
- int ret, hsub, vsub, num_planes, i;
+ int num_planes, i;
- ret = format_check(r);
- if (ret) {
- DRM_DEBUG_KMS(bad framebuffer format %s\n,
- drm_get_format_name(r-pixel_format));
- return ret;
- }
-
- hsub = drm_format_horz_chroma_subsampling(r-pixel_format);
- vsub = drm_format_vert_chroma_subsampling(r-pixel_format);
num_planes = drm_format_num_planes(r-pixel_format);
- if (r-width == 0 || r-width % hsub) {
- DRM_DEBUG_KMS(bad framebuffer width %u\n, r-width);
- return -EINVAL;
- }
-
- if (r-height == 0 || r-height % vsub) {
- DRM_DEBUG_KMS(bad framebuffer height %u\n, r-height);
- return -EINVAL;
- }
-
for (i = 0; i num_planes; i++) {
unsigned int width = r-width / (i != 0 ? hsub : 1);
unsigned int height = r-height / (i != 0 ? vsub : 1);
@@ -3464,6 +3446,100 @@ static int framebuffer_check(const struct
drm_mode_fb_cmd2 *r)
return 0;
}
+static int framebuffer_check_sources(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
+{
+ struct drm_mode_object *obj;
+ struct drm_live_source *src;
+ unsigned int cpp;
+ unsigned int i;
+
+ /*
+* Ensure that userspace has zeroed unused handles, pitches, offsets and
+* modifiers to allow future API extensions.
+*/
+ if (r-offsets[0] || r-modifier[0])
+ return -EINVAL;
+
+ for (i = 1; i ARRAY_SIZE(r-handles); ++i) {
+ if (r-handles[i] || r-pitches[i] ||
+ r-offsets[i] || r-modifier[i])
+ return -EINVAL;
+ }
+
+ /* Validate width, height and pitch. */
+ cpp = drm_format_plane_cpp(r-pixel_format, 0);
+
+ if ((uint64_t) r-width * cpp UINT_MAX)
+ return -ERANGE;
+
+ if ((uint64_t) r-height * r-pitches[0] UINT_MAX)
+ return -ERANGE;
+
+ if (r-pitches[0] != r-width * cpp) {
+ DRM_DEBUG_KMS(bad pitch %u for plane %d\n, r-pitches[0], i);
+ return -EINVAL;
+ }
+
+ /*
+* Find the live source and check whether it supports the requested
+* pixel format.
+*/
+
+ obj = drm_mode_object_find(dev, r-handles[0],
+ DRM_MODE_OBJECT_LIVE_SOURCE);
+ if (!obj) {
+ DRM_DEBUG_KMS(bad framebuffer source ID %u\n, r-handles[0]);
+ return -EINVAL;
+ }
+
+ src = obj_to_live_source(obj);
+
+ for (i = 0; i src-format_count; i++) {
+ if (r-pixel_format == src-format_types[i])
+ break;
+ }
+
+ if (i == src-format_count) {
+ DRM_DEBUG_KMS(bad framebuffer pixel format 0x%08x for source
%u\n,
+ r-pixel_format, r-handles[0]);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int framebuffer_check(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
+{
+ int ret, hsub, vsub;
+
+ ret = format_check(r);
+ if (ret) {
+ DRM_DEBUG_KMS(bad framebuffer format %s\n,
+ drm_get_format_name(r-pixel_format));
+ return ret;
+ }
+
+ hsub = drm_format_horz_chroma_subsampling(r-pixel_format);
+ vsub = drm_format_vert_chroma_subsampling(r-pixel_format);
+
+ if (r-width == 0 || r-width % hsub) {
+ DRM_DEBUG_KMS(bad framebuffer width %u\n, r-width);
+ return -EINVAL;
+ }
+
+ if (r-height == 0 || r-height % vsub) {
+ DRM_DEBUG_KMS(bad framebuffer height %u\n, r-height);
+ return -EINVAL;
+ }
+
+ if (r-flags DRM_MODE_FB_LIVE_SOURCE)
+ return framebuffer_check_sources(dev, r);
+ else
+
[RFC/PATCH v2 3/5] drm/rcar-du: Add VSP1 support to the planes allocator
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0
and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0
or DU0/1 plane 1.
Allocate the correct fixed plane when sourcing frames from VSPD0 or
VSPD1, and allocate planes in reverse index order otherwise to ensure
maximum availability of planes 0 and 1.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 40 -
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 1 +
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 7 ++
3 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index fb052bca574f..17f89bfca8f8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -244,11 +244,41 @@ static unsigned int rcar_du_plane_hwmask(struct
rcar_du_plane_state *state)
return mask;
}
-static int rcar_du_plane_hwalloc(unsigned int num_planes, unsigned int free)
+/*
+ * The R8A7790 DU can source frames directly from the VSP1 devices VSPD0 and
+ * VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0 or
+ * DU0/1 plane 1.
+ *
+ * Allocate the correct fixed plane when sourcing frames from VSPD0 or VSPD1,
+ * and allocate planes in reverse index order otherwise to ensure maximum
+ * availability of planes 0 and 1.
+ *
+ * The caller is responsible for ensuring that the requested source is
+ * compatible with the DU revision.
+ */
+static int rcar_du_plane_hwalloc(struct rcar_du_plane *plane,
+struct rcar_du_plane_state *state,
+unsigned int free)
{
- unsigned int i;
+ unsigned int num_planes = state-format-planes;
+ int fixed = -1;
+ int i;
+
+ if (state-source == RCAR_DU_PLANE_VSPD0) {
+ /* VSPD0 feeds plane 0 on DU0/1. */
+ if (plane-group-index != 0)
+ return -EINVAL;
+
+ fixed = 0;
+ } else if (state-source == RCAR_DU_PLANE_VSPD1) {
+ /* VSPD1 feeds plane 1 on DU0/1 or plane 0 on DU2. */
+ fixed = plane-group-index == 0 ? 1 : 0;
+ }
+
+ if (fixed = 0)
+ return free (1 fixed) ? fixed : -EBUSY;
- for (i = 0; i RCAR_DU_NUM_HW_PLANES; ++i) {
+ for (i = RCAR_DU_NUM_HW_PLANES - 1; i = 0; --i) {
if (!(free (1 i)))
continue;
@@ -256,7 +286,7 @@ static int rcar_du_plane_hwalloc(unsigned int num_planes,
unsigned int free)
break;
}
- return i == RCAR_DU_NUM_HW_PLANES ? -EBUSY : i;
+ return i 0 ? -EBUSY : i;
}
static int rcar_du_atomic_check(struct drm_device *dev,
@@ -372,7 +402,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
!rcar_du_plane_needs_realloc(plane, plane_state))
continue;
- idx = rcar_du_plane_hwalloc(plane_state-format-planes,
+ idx = rcar_du_plane_hwalloc(plane, plane_state,
group_free_planes[plane-group-index]);
if (idx 0) {
dev_dbg(rcdu-dev, %s: no available hardware plane\n,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 210e5c3fd982..80e4dba78aef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -288,6 +288,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
return;
state-hwindex = -1;
+ state-source = RCAR_DU_PLANE_MEMORY;
state-alpha = 255;
state-colorkey = RCAR_DU_COLORKEY_NONE;
state-zpos = plane-type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index abff0ebeb195..81c2d361a94f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -28,6 +28,12 @@ struct rcar_du_group;
#define RCAR_DU_NUM_KMS_PLANES 9
#define RCAR_DU_NUM_HW_PLANES 8
+enum rcar_du_plane_source {
+ RCAR_DU_PLANE_MEMORY,
+ RCAR_DU_PLANE_VSPD0,
+ RCAR_DU_PLANE_VSPD1,
+};
+
struct rcar_du_plane {
struct drm_plane plane;
struct rcar_du_group *group;
@@ -51,6 +57,7 @@ struct rcar_du_plane_state {
const struct rcar_du_format_info *format;
int hwindex;/* 0-based, -1 means unused */
+ enum rcar_du_plane_source source;
unsigned int alpha;
unsigned int colorkey;
--
2.0.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
[RFC/PATCH v2 4/5] drm/rcar-du: Add VSP1 live source support
Register live sources for VSPD0 and VSPD1 and configure the plane source
at plane setup time to source frames from memory or from the VSP1.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 19 ++--
drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 92 -
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 3 +
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 168 +---
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 3 +
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 1 +
9 files changed, 246 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index da1216a73969..e16a912327b7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -58,7 +58,8 @@ static const struct rcar_du_device_info rcar_du_r8a7779_info
= {
static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
- | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
.quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
.num_crtcs = 3,
.routes = {
@@ -86,7 +87,8 @@ static const struct rcar_du_device_info rcar_du_r8a7790_info
= {
static const struct rcar_du_device_info rcar_du_r8a7791_info = {
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
- | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 2,
.routes = {
/* R8A7791 has one RGB output, one LVDS output and one
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index c7c538dd2e68..b5be16053e71 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -29,6 +29,7 @@ struct rcar_du_lvdsenc;
#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK (1 0)/* Per-CRTC IRQ and
clock */
#define RCAR_DU_FEATURE_EXT_CTRL_REGS (1 1)/* Has extended control
registers */
+#define RCAR_DU_FEATURE_VSP1_SOURCE(1 2)/* Has inputs from VSP1
*/
#define RCAR_DU_QUIRK_ALIGN_128B (1 0)/* Align pitches to 128
bytes */
#define RCAR_DU_QUIRK_LVDS_LANES (1 1)/* LVDS lanes 1 and 3
inverted */
@@ -84,6 +85,8 @@ struct rcar_du_device {
struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
unsigned int dpad0_source;
+ unsigned int vspd1_sink;
+
struct rcar_du_lvdsenc *lvds[RCAR_DU_MAX_LVDS];
struct {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 1bdc0ee0c248..71f50bf45581 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -49,10 +49,13 @@ static void rcar_du_group_setup_defr8(struct rcar_du_group
*rgrp)
u32 defr8 = DEFR8_CODE | DEFR8_DEFE8;
/* The DEFR8 register for the first group also controls RGB output
-* routing to DPAD0
+* routing to DPAD0 and VSPD1 routing to DU0/1/2.
*/
- if (rgrp-index == 0)
+ if (rgrp-index == 0) {
defr8 |= DEFR8_DRGBS_DU(rgrp-dev-dpad0_source);
+ if (rgrp-dev-vspd1_sink == 2)
+ defr8 |= DEFR8_VSCS;
+ }
rcar_du_group_write(rgrp, DEFR8, defr8);
}
@@ -155,17 +158,17 @@ void rcar_du_group_restart(struct rcar_du_group *rgrp)
__rcar_du_group_start_stop(rgrp, true);
}
-static int rcar_du_set_dpad0_routing(struct rcar_du_device *rcdu)
+int rcar_du_set_dpad0_vsp1_routing(struct rcar_du_device *rcdu)
{
int ret;
if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_EXT_CTRL_REGS))
return 0;
- /* RGB output routing to DPAD0 is configured in the DEFR8 register of
-* the first group. As this function can be called with the DU0 and DU1
-* CRTCs disabled, we need to enable the first group clock before
-* accessing the register.
+ /* RGB output routing to DPAD0 and VSP1D routing to DU0/1/2 are
+* configured in the DEFR8 register of the first group. As this function
+* can be called with the DU0 and DU1 CRTCs disabled, we need to enable
+* the first group clock before accessing the register.
*/
ret = clk_prepare_enable(rcdu-crtcs[0].clock);
if (ret 0)
@@ -196,5 +199,5 @@ int rcar_du_group_set_routing(struct rcar_du_group *rgrp)
rcar_du_group_write(rgrp, DORCR, dorcr);
- return rcar_du_set_dpad0_routing(rgrp-dev);
+ return rcar_du_set_dpad0_vsp1_routing(rgrp-dev);
}
diff --git
[RFC/PATCH v2 0/5] Add live source objects to DRM
Hello, Here's a proposal for a different approach to live source in DRM based on an idea by Daniel Vetter. The previous version can be found at http://lists.freedesktop.org/archives/dri-devel/2015-March/079319.html. The need comes from the Renesas R-Car SoCs in which a video processing engine (named VSP1) that operates from memory to memory has one output directly connected to a plane of the display engine (DU) without going through memory. The VSP1 is supported by a V4L2 driver. While it could be argued that it should instead be supported directly by the DRM rcar-du driver, this wouldn't be a good idea for at least two reasons. First, the R-Car SoCs contain several VSP1 instances, of which only a subset have a direct DU connection. The only other instances operate solely in memory to memory mode. Then, the VSP1 is a video processing engine and not a display engine. Its features are easily supported by the V4L2 API, but don't map to the DRM/KMS API. Significant changes to DRM/KMS would be required, beyond what is in my opinion an acceptable scope for a display API. Now that the need to interface two separate devices supported by two different drivers in two separate subsystems has been established, we need an API to do so. It should be noted that while that API doesn't exist in the mainline kernel, the need isn't limited to Renesas SoCs. This patch set proposes one possible solution for the problem in the form of a new DRM object named live source. Live sources are created by drivers to model hardware connections between a plane input and an external source, and are attached to planes through the KMS userspace API. Patch 1/5 adds live source objects to DRM, with an in-kernel API for drivers to register the sources, and a userspace API to enumerate them. Patch 2/5 implements connection between live sources and planes through framebuffers. It introduces a new live source flag for framebuffers. When a framebuffer is created with that flag set, a live source is associated with the framebuffer instead of buffer objects. The framebuffer can then be used with a plane to connect it with the live source. This is the biggest difference compared to the previous approach, and has several benefits: - Changes are less intrusive in the DRM core - The implementation supports both the legacy API and atomic updates without any code specific to either - No changes to existing drivers are needed - The framebuffer format and size configuration API is reused The framebuffer format and size should ideally be validated using information queried directly from the driver that supports the live source device, but I've decided not to implement such communication between V4L2 and DRM/KMS at the moment to keep the proposal simple. Patches 3/5 to 5/5 then implement support for live sources in the R-Car DU driver. The rcar_du_live_framebuffer structure and its associated helper functions could be moved to the DRM core later if other drivers need a similar implementation. I've decided to keep them in the rcar-du driver for now as it's not clear yet what other drivers might need. Once again nothing here is set in stone. Laurent Pinchart (5): drm: Add live source object drm: Connect live source to framebuffers drm/rcar-du: Add VSP1 support to the planes allocator drm/rcar-du: Add VSP1 live source support drm/rcar-du: Restart the DU group when a plane source changes drivers/gpu/drm/drm_crtc.c | 287 +--- drivers/gpu/drm/drm_ioctl.c | 2 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 10 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 21 ++- drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 132 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.h | 3 + drivers/gpu/drm/rcar-du/rcar_du_plane.c | 191 - drivers/gpu/drm/rcar-du/rcar_du_plane.h | 11 ++ drivers/gpu/drm/rcar-du/rcar_du_regs.h | 1 + include/drm/drm_crtc.h | 35 include/uapi/drm/drm.h | 3 + include/uapi/drm/drm_mode.h | 23 +++ 15 files changed, 647 insertions(+), 83 deletions(-) -- 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
[RFC/PATCH v2 1/5] drm: Add live source object
Live sources represent a hardware connection between a video stream
source and a CRTC, going through a plane. The kernel API lets driver
register live sources, and the userspace API lets applications enumerate
them.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/drm_crtc.c | 164
drivers/gpu/drm/drm_ioctl.c | 2 +
include/drm/drm_crtc.h | 35 ++
include/uapi/drm/drm.h | 3 +
include/uapi/drm/drm_mode.h | 16 +
5 files changed, 220 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b3989e23195e..1f71978b4f17 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1265,6 +1265,70 @@ void drm_plane_cleanup(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_cleanup);
+int drm_live_source_init(struct drm_device *dev, struct drm_live_source *src,
+const char *name, unsigned long possible_planes,
+const uint32_t *formats, uint32_t format_count,
+const struct drm_live_source_funcs *funcs)
+{
+ unsigned int i;
+ int ret;
+
+ /* Multi-planar live sources are not supported for now. */
+ for (i = 0; i format_count; ++i) {
+ if (drm_format_num_planes(formats[i]) != 1) {
+ DRM_DEBUG_KMS(multiplanar live sources unsupported\n);
+ return -EINVAL;
+ }
+ }
+
+ drm_modeset_lock_all(dev);
+
+ ret = drm_mode_object_get(dev, src-base, DRM_MODE_OBJECT_LIVE_SOURCE);
+ if (ret)
+ goto out;
+
+ src-dev = dev;
+ src-funcs = funcs;
+ if (name)
+ strlcpy(src-name, name, DRM_SOURCE_NAME_LEN);
+ src-possible_planes = possible_planes;
+
+ src-format_types = kmalloc_array(format_count,
+ sizeof(*src-format_types),
+ GFP_KERNEL);
+ if (!src-format_types) {
+ DRM_DEBUG_KMS(out of memory when allocating source foramts\n);
+ drm_mode_object_put(dev, src-base);
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ memcpy(src-format_types, formats,
+ format_count * sizeof(*src-format_types));
+ src-format_count = format_count;
+
+ list_add_tail(src-head, dev-mode_config.live_source_list);
+ dev-mode_config.num_live_source++;
+
+ out:
+ drm_modeset_unlock_all(dev);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_live_source_init);
+
+void drm_live_source_cleanup(struct drm_live_source *src)
+{
+ struct drm_device *dev = src-dev;
+
+ drm_modeset_lock_all(dev);
+ drm_mode_object_put(dev, src-base);
+ list_del(src-head);
+ dev-mode_config.num_live_source--;
+ drm_modeset_unlock_all(dev);
+}
+EXPORT_SYMBOL(drm_live_source_cleanup);
+
/**
* drm_plane_index - find the index of a registered plane
* @plane: plane to find index for
@@ -2616,6 +2680,99 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
}
/**
+ * drm_mode_getsource_res - get live source info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return a live source and set of IDs.
+ */
+int drm_mode_getsource_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_live_source_res *src_resp = data;
+ struct drm_mode_config *config;
+ struct drm_live_source *src;
+ uint32_t __user *src_ptr;
+ int copied = 0, ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ drm_modeset_lock_all(dev);
+ config = dev-mode_config;
+
+ /*
+* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it.
+*/
+ if (config-num_live_source
+ (src_resp-count_sources = config-num_live_source)) {
+ src_ptr = (uint32_t __user *)(unsigned
long)src_resp-source_id_ptr;
+
+ list_for_each_entry(src, config-live_source_list, head) {
+ if (put_user(src-base.id, src_ptr + copied)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ copied++;
+ }
+ }
+ src_resp-count_sources = config-num_live_source;
+
+out:
+ drm_modeset_unlock_all(dev);
+ return ret;
+}
+
+/**
+ * drm_mode_getsource - get live source info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return live source info, including formats supported, ...
+ */
+int drm_mode_getsource(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_live_source *src_resp = data;
+ struct
[RFC/PATCH v2 5/5] drm/rcar-du: Restart the DU group when a plane source changes
Plane sources are configured by the VSPS bit in the PnDDCR4 register.
Although the datasheet states that the bit is updated during vertical
blanking, it seems that updates only occur when the DU group is held in
reset through the DSYSR.DRES bit. Restart the group if the source
changes.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 10 --
drivers/gpu/drm/rcar-du/rcar_du_group.c | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 22 --
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 1 +
4 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7d0b8ef9bea2..969d49ab0d09 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -249,6 +249,8 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc
*rcrtc)
}
}
+ mutex_lock(rcrtc-group-lock);
+
/* Select display timing and dot clock generator 2 for planes associated
* with superposition controller 2.
*/
@@ -260,15 +262,19 @@ static void rcar_du_crtc_update_planes(struct
rcar_du_crtc *rcrtc)
* split, or through a module parameter). Flicker would then
* occur only if we need to break the pre-association.
*/
- mutex_lock(rcrtc-group-lock);
if (rcar_du_group_read(rcrtc-group, DPTSR) != dptsr) {
rcar_du_group_write(rcrtc-group, DPTSR, dptsr);
if (rcrtc-group-used_crtcs)
rcar_du_group_restart(rcrtc-group);
}
- mutex_unlock(rcrtc-group-lock);
}
+ /* Restart the group if plane sources have changed. */
+ if (rcrtc-group-planes.need_restart)
+ rcar_du_group_restart(rcrtc-group);
+
+ mutex_unlock(rcrtc-group-lock);
+
rcar_du_group_write(rcrtc-group, rcrtc-index % 2 ? DS2PR : DS1PR,
dspr);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 71f50bf45581..101997e6e531 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -154,6 +154,8 @@ void rcar_du_group_start_stop(struct rcar_du_group *rgrp,
bool start)
void rcar_du_group_restart(struct rcar_du_group *rgrp)
{
+ rgrp-planes.need_restart = false;
+
__rcar_du_group_start_stop(rgrp, false);
__rcar_du_group_start_stop(rgrp, true);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 07802639ac99..0bf2aaaf91e6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -357,9 +357,27 @@ static void rcar_du_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *old_state)
{
struct rcar_du_plane *rplane = to_rcar_plane(plane);
+ struct rcar_du_plane_state *old_rstate;
+ struct rcar_du_plane_state *new_rstate;
- if (plane-state-crtc)
- rcar_du_plane_setup(rplane);
+ if (!plane-state-crtc)
+ return;
+
+ rcar_du_plane_setup(rplane);
+
+ /* Check whether the source has changed from memory to live source or
+* from live source to memory. The source has been configured by the
+* VSPS bit in the PnDDCR4 register. Although the datasheet states that
+* the bit is updated during vertical blanking, it seems that updates
+* only occur when the DU group is held in reset through the DSYSR.DRES
+* bit. We thus need to restart the group if the source changes.
+*/
+ old_rstate = to_rcar_du_plane_state(old_state);
+ new_rstate = to_rcar_du_plane_state(plane-state);
+
+ if ((old_rstate-source == RCAR_DU_PLANE_MEMORY) !=
+ (new_rstate-source == RCAR_DU_PLANE_MEMORY))
+ rplane-group-planes.need_restart = true;
}
static const struct drm_plane_helper_funcs rcar_du_plane_helper_funcs = {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index 9a6132899d59..694b44c151b6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -47,6 +47,7 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
drm_plane *plane)
struct rcar_du_planes {
struct rcar_du_plane planes[RCAR_DU_NUM_KMS_PLANES];
+ bool need_restart;
struct drm_property *alpha;
struct drm_property *colorkey;
--
2.0.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] v4l: vsp1: Don't sleep in atomic context
The vsp1_entity_is_streaming() function is called in atomic context when
queuing buffers, and sleeps due to a mutex. As the mutex just protects
access to one structure field, fix this by replace the mutex with a
spinlock.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/platform/vsp1/vsp1_entity.c | 18 +-
drivers/media/platform/vsp1/vsp1_entity.h | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
This bug seems to have been there since the very first version of the VSP1
driver and never got caught. Amazing...
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c
b/drivers/media/platform/vsp1/vsp1_entity.c
index 79af71d5e270..622acd1c8d58 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -24,22 +24,24 @@
bool vsp1_entity_is_streaming(struct vsp1_entity *entity)
{
+ unsigned long flags;
bool streaming;
- mutex_lock(entity-lock);
+ spin_lock_irqsave(entity-lock, flags);
streaming = entity-streaming;
- mutex_unlock(entity-lock);
+ spin_unlock_irqrestore(entity-lock, flags);
return streaming;
}
int vsp1_entity_set_streaming(struct vsp1_entity *entity, bool streaming)
{
+ unsigned long flags;
int ret;
- mutex_lock(entity-lock);
+ spin_lock_irqsave(entity-lock, flags);
entity-streaming = streaming;
- mutex_unlock(entity-lock);
+ spin_unlock_irqrestore(entity-lock, flags);
if (!streaming)
return 0;
@@ -49,9 +51,9 @@ int vsp1_entity_set_streaming(struct vsp1_entity *entity,
bool streaming)
ret = v4l2_ctrl_handler_setup(entity-subdev.ctrl_handler);
if (ret 0) {
- mutex_lock(entity-lock);
+ spin_lock_irqsave(entity-lock, flags);
entity-streaming = false;
- mutex_unlock(entity-lock);
+ spin_unlock_irqrestore(entity-lock, flags);
}
return ret;
@@ -193,7 +195,7 @@ int vsp1_entity_init(struct vsp1_device *vsp1, struct
vsp1_entity *entity,
if (i == ARRAY_SIZE(vsp1_routes))
return -EINVAL;
- mutex_init(entity-lock);
+ spin_lock_init(entity-lock);
entity-vsp1 = vsp1;
entity-source_pad = num_pads - 1;
@@ -228,6 +230,4 @@ void vsp1_entity_destroy(struct vsp1_entity *entity)
if (entity-subdev.ctrl_handler)
v4l2_ctrl_handler_free(entity-subdev.ctrl_handler);
media_entity_cleanup(entity-subdev.entity);
-
- mutex_destroy(entity-lock);
}
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
b/drivers/media/platform/vsp1/vsp1_entity.h
index aa20aaa58208..b634013b0958 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -14,7 +14,7 @@
#define __VSP1_ENTITY_H__
#include linux/list.h
-#include linux/mutex.h
+#include linux/spinlock.h
#include media/v4l2-subdev.h
@@ -73,7 +73,7 @@ struct vsp1_entity {
struct vsp1_video *video;
- struct mutex lock; /* Protects the streaming field */
+ spinlock_t lock;/* Protects the streaming field */
bool streaming;
};
--
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: [PATCH v2] OMAP3 ISP: Set DMA segment size
Hi Tim,
Thank you for the patch.
On Thursday 19 March 2015 08:59:52 Tim Nordell wrote:
When utilizing userptr buffers for output from the CCDC, the
DMA subsystem maps buffers into the virtual address space.
However, the DMA subsystem also has a configurable parameter
for what the largest segment to allocate is out of the virtual
address space as well.
Since we need contiguous buffers for the memory space from the
OMAP3 ISP's vantage point, we need to configure the segments
to be at least as large as the largest buffer we expect.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
drivers/media/platform/omap3isp/isp.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index ead2d0d..906d3e5 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2170,6 +2170,20 @@ static int isp_attach_iommu(struct isp_device *isp)
goto error;
}
+ isp-dev-dma_parms = devm_kzalloc(isp-dev,
+ sizeof(*isp-dev-dma_parms), GFP_KERNEL);
+ if (!isp-dev-dma_parms) {
+ dev_err(isp-dev, failed to allocate memory for dma_parms\n);
+ ret = -ENOMEM;
+ goto error;
+ }
How about adding a struct device_dma_parameters field in struct isp_device and
just assigning isp-dev-dma_parms = isp-dma_parms ? This would get rid of
the separate allocation step.
+
+ ret = dma_set_max_seg_size(isp-dev, SZ_32M);
There's no reason to limit the size to 32MB, you can use the full 4GB
addressable space.
+ if (ret 0) {
+ dev_err(isp-dev, failed to set max segment size for dma\n);
+ goto error;
+ }
+
return 0;
error:
--
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: capture high resolution images from webcam
Hi Oliver, On Thursday 19 March 2015 20:31:43 Oliver Lehmann wrote: Hi Laurent, I took the first option ;) http://pastebin.com/7YUgS2Zt I have good news and bad news. The good news is that the camera seems to support capturing video in 1920x1080 natively, which is higher than the 720p you reported. This should work out of the box with the uvcvideo driver. The bad news is that still image capture at higher resolutions isn't supported by the camera, or at least not in a UVC-compatible way. My guess is that 8MP is achieved either using software interpolation, or possibly using a vendor- specific undocumented protocol. -- 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: [PATCH] OMAP3 ISP: Support top and bottom fields
Hi Tim,
Thank you for the patch.
On Friday 20 March 2015 15:32:20 Tim Nordell wrote:
The OMAP3ISP can selectively stream either the top or bottom
field by setting the start line vertical field to a high value
for the field that one doesn't want to stream. The driver
can switch between these utilizing the vertical start feature
of the CCDC.
Additionally, we need to ensure that the FLDMODE bit is set
when we're doing this as we need to differentiate between
the two frames.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
drivers/media/platform/omap3isp/ispccdc.c | 29 +--
drivers/media/platform/omap3isp/ispvideo.c | 4 ++--
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispccdc.c
b/drivers/media/platform/omap3isp/ispccdc.c index 882ebde..beb8d96 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1131,6 +1131,7 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) unsigned int sph;
u32 syn_mode;
u32 ccdc_pattern;
+ int slv0, slv1;
slv0 and slv1 are positive integers, you can use unsigned int. Could you
please declare one variable per line to match the coding style of the driver,
and move them right after the declaration of sph ?
ccdc-bt656 = false;
ccdc-fields = 0;
@@ -1237,11 +1238,27 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) nph = crop-width - 1;
}
+ /* Default the start vertical line offset to the crop point */
+ slv0 = slv1 = crop-top;
+
+ /* When streaming just the top or bottom field, enable processing
+ * of the field input signal so that SLV1 is processed.
+ */
The slv[01] trick below doesn't seem trivial to me, it would make sense to
document it. How about
/* When capturing only the top or bottom field, enable processing of the
* field input signal and reject the unneeded field by setting its start
* line to a value larger than the frame height.
*/
+ if (ccdc-formats[CCDC_PAD_SINK].field == V4L2_FIELD_ALTERNATE) {
+ if (format-field == V4L2_FIELD_TOP) {
+ slv1 = 0x7FFF;
Could you please use lowercase for hex constants ?
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+ } else if (format-field == V4L2_FIELD_BOTTOM) {
Can format-field be equal to V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM if ccdc-
formats[CCDC_PAD_SINK].field is not equal to V4L2_FIELD_ALTERNATE ? If not
you can remove the outer condition check.
+ slv0 = 0x7FFF;
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+ }
+ }
+
isp_reg_writel(isp, (sph ISPCCDC_HORZ_INFO_SPH_SHIFT) |
(nph ISPCCDC_HORZ_INFO_NPH_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO);
- isp_reg_writel(isp, (crop-top ISPCCDC_VERT_START_SLV0_SHIFT) |
-(crop-top ISPCCDC_VERT_START_SLV1_SHIFT),
+ isp_reg_writel(isp, (slv0 ISPCCDC_VERT_START_SLV0_SHIFT) |
+(slv1 ISPCCDC_VERT_START_SLV1_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
isp_reg_writel(isp, (crop-height - 1)
ISPCCDC_VERT_LINES_NLV_SHIFT,
@@ -2064,6 +2081,14 @@ ccdc_try_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh, fmt-height *= 2;
}
+ /* When input format is interlaced with alternating fields the
+ * CCDC can pick out just the top or bottom field.
+ */
+ if (fmt-field == V4L2_FIELD_ALTERNATE
+(field == V4L2_FIELD_TOP ||
+ field == V4L2_FIELD_BOTTOM))
You could combine this check with the one right above into something like the
following (untested).
/* When the input format is interlaced with alternating fields
* the CCDC can interleave the fields or selectively capture the
* top or bottom field.
*/
if (fmt-field == V4L2_FIELD_ALTERNATE) {
switch (field) {
case V4L2_FIELD_INTERLACED_TB:
case V4L2_FIELD_INTERLACED_BT:
fmt-height *= 2;
/* Fall-through */
case V4L2_FIELD_TOP:
case V4L2_FIELD_BOTTOM:
fmt-field = field;
break;
}
}
(an empty default case might be needed to silence compiler warnings)
+ fmt-field = field;
+
break;
case CCDC_PAD_SOURCE_VP:
There's something else that bothers me. If I'm not mistaken, the CCDC will
generate VD0 and VD1 interrupts for both fields, and the ccdc_has_all_fields()
logic will wait until both fields have been captured before returning the
buffer to userspace. This seems to work by chance, and will possibly delay the
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: Tue Apr 14 04:00:24 CEST 2015 git branch: test git hash: e183201b9e917daf2530b637b2f34f1d5afb934d gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.19.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: 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: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR
Cc'ing a few others as we ended up talking about the cruxes of my
unposted v2 series as I confirmed that set_memor_wc() would not work
as an alternative to my originally proposed __arch_phys_wc_add() to
force MTRR as a last resort on a few set of last remaining drivers.
This also discusses overlapping ioremap() calls and what we'd need
for a default shift from UC- to strong UC.
On Fri, Apr 10, 2015 at 11:25:22PM -0700, Andy Lutomirski wrote:
On Apr 10, 2015 6:29 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Apr 10, 2015 at 02:22:51PM -0700, Andy Lutomirski wrote:
On Fri, Apr 10, 2015 at 1:58 PM, Toshi Kani toshi.k...@hp.com wrote:
On Fri, 2015-04-10 at 23:05 +0200, Luis R. Rodriguez wrote:
On Fri, Apr 10, 2015 at 01:49:39PM -0600, Toshi Kani wrote:
On Fri, 2015-04-10 at 12:34 -0700, Luis R. Rodriguez wrote:
On Fri, Apr 10, 2015 at 12:14 PM, Andy Lutomirski
l...@amacapital.net wrote:
On Fri, Apr 10, 2015 at 10:17 AM, Luis R. Rodriguez
mcg...@suse.com wrote:
Andy, I'm ready to post a v2 series based on review of the
first iteration of
the bury-MTRR series however I ran into a snag in vetting for
the ioremap_uc()
followed by a set_memory_wc() strategy as a measure to both
avoid when possible
overlapping ioremap*() calls and/or to avoid the power of 2
MTRR size
implications on having to use multiple MTRRs.
I tested the strategy by just making my thinkpad's i915 driver
use iremap_uc()
which I add, and then use set_memory_wc(). To start off with I
should note
set_memory_*() helpers are x86 specific right now, this is not
a problem for
the series but its worth noting as we're replacing MTRR
strategies which
are x86 specific, but I am having issues getting
set_memory_wc() take effect
on my intel graphics card.
I've reviewed if this is OK in code and I see no issues other
than set_memory_*()
helpers seem to be desirable for RAM, not IO memory, so was
wondering if we need
to add other helpers which can address IO memory or if this
should work? The diff
for the drivers is below, the actual commit for adding
ioremap_uc() folllows
with its commit log. Feedback / review on both is welcome as
well as if you
could help me figure out why this test-patch for i915 fails.
I think they should work for IO memory, but I'm not really an
authority here.
Adding some people who have looked at the code recently.
I was avoiding reviewing the cpa code but since this failed I just
had
to review it and I see nothing prevent it from being used on IO
memory
but -- memtype_rb_check_conflict() does prevent an overlap to be
set
on an *existing range* -- and since ioremap_uc() was used earlier
the
first reserve_memtype() with _PAGE_CACHE_MODE_WC by
set_memory_wc() I
believe should fail then. Please correct me if I'm wrong, I don't
see
the conflicting memory types print though, so not sure if it was
because of that.
I only started looking at this though but shouldn't this also mean
we
can't use overlapping ioremap() calls too? I thought that worked,
because at least some drivers are using that strategy.
set_memory_*() does not work with I/O memory ranges with the
following
reasons:
1. __pa(addr) returns a fake address since there is no direct map.
2. reserve_memtype() tracks regular memory and I/O memory
differently.
For regular memory, set_memory_*() can modify WB with a new type
since
reserve_memtype() does not track WB. For I/O memory,
reserve_memtype()
detects a conflict when a given type is different from a tracked
type.
Interesting, but I also just realized I had messed up my test patch
too,
I checked for (!ret) instead of (ret). This works now.
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index dccdc8a..dd9501b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1958,12 +1958,22 @@ static int ggtt_probe_common(struct
drm_device *dev,
gtt_phys_addr = pci_resource_start(dev-pdev, 0) +
(pci_resource_len(dev-pdev, 0) / 2);
- dev_priv-gtt.gsm = ioremap_wc(gtt_phys_addr, gtt_size);
+ dev_priv-gtt.gsm = ioremap_uc(gtt_phys_addr, gtt_size);
if (!dev_priv-gtt.gsm) {
DRM_ERROR(Failed to map the gtt page table\n);
return -ENOMEM;
}
+ printk(mcgrof:set_memory_wc() ggtt_probe_common()\n);
+
+
Re: [PATCH v4 1/4] [media] videodev2: Add V4L2_BUF_FLAG_LAST
Am Montag, den 13.04.2015, 14:42 +0900 schrieb Pawel Osciak: Hi, Thanks for working on this! On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel p.za...@pengutronix.de wrote: From: Peter Seiderer ps.rep...@gmx.net This v4l2_buffer flag can be used by drivers to mark a capture buffer as the last generated buffer, for example after a V4L2_DEC_CMD_STOP command was issued. The DocBook is updated to mention mem2mem codecs and the mem2mem draining flow signals in the VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP documentation. Signed-off-by: Peter Seiderer ps.rep...@gmx.net Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- Changes since v3: - Added DocBook update mentioning V4L2_BUF_FLAG_LAST in the encoder/decoder stop command documentation. --- Documentation/DocBook/media/v4l/io.xml | 10 ++ Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 6 +- Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 5 - include/trace/events/v4l2.h| 3 ++- include/uapi/linux/videodev2.h | 2 ++ 5 files changed, 23 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 1c17f80..f3b8bc0 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -1129,6 +1129,16 @@ in this buffer has not been created by the CPU but by some DMA-capable unit, in which case caches have not been used./entry /row row + entryconstantV4L2_BUF_FLAG_LAST/constant/entry + entry0x0010/entry + entryLast buffer produced by the hardware. mem2mem codec drivers +set this flag on the capture queue for the last buffer when the +link linkend=vidioc-querybufVIDIOC_QUERYBUF/link or +link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. After the +queue is drained, the link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will Perhaps just s/After the queue is drained, the/Any subsequent/ ? This would make it more clear I feel. DQBUF of LAST is the end of draining. Concise, I like it. +not block anymore, but return an EPIPE;./entry + /row + row entryconstantV4L2_BUF_FLAG_TIMESTAMP_MASK/constant/entry entry0xe000/entry entryMask for timestamp types below. To test the diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml index 9215627..cbb7135 100644 --- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -197,7 +197,11 @@ be muted when playing back at a non-standard speed. this command does nothing. This command has two flags: if constantV4L2_DEC_CMD_STOP_TO_BLACK/constant is set, then the decoder will set the picture to black after it stopped decoding. Otherwise the last image will -repeat. If constantV4L2_DEC_CMD_STOP_IMMEDIATELY/constant is set, then the decoder +repeat. mem2mem decoders will stop producing new frames altogether. They will send +a constantV4L2_EVENT_EOS/constant event after the last frame was decoded and s/was decoded/has been decoded and all frames are ready to be dequeued/ Yes. +will set the constantV4L2_BUF_FLAG_LAST/constant buffer flag when there will +be no new buffers produced to dequeue. To make the timing description more explicit, s/when there will be no new buffers produced to dequeue./on the final buffer being dequeued/ perhaps? EOS indicates no more buffers will be produced and all are ready to be dequeued, while LAST indicates final buffer being dequeued. Yes. +If constantV4L2_DEC_CMD_STOP_IMMEDIATELY/constant is set, then the decoder stops immediately (ignoring the structfieldpts/structfield value), otherwise it will keep decoding until timestamp = pts or until the last of the pending data from its internal buffers was decoded. diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml index 0619ca5..e9cf601 100644 --- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -129,7 +129,10 @@ this command./entry encoding will continue until the end of the current wordaswordGroup Of Pictures/wordasword, otherwise encoding will stop immediately. When the encoder is already stopped, this command does -nothing./entry +nothing. mem2mem encoders will send a constantV4L2_EVENT_EOS/constant event +after the last frame was encoded and will set the +constantV4L2_BUF_FLAG_LAST/constant buffer flag on the capture queue when +there will be no new buffers produced to dequeue/entry I'd propose
Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi,
On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel p.za...@pengutronix.de wrote:
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Added DocBook update mentioning DQBUF returning -EPIPE in the
encoder/decoder
stop command documentation.
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +-
drivers/media/v4l2-core/videobuf2-core.c | 18
+-
include/media/videobuf2-core.h | 10 ++
6 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
Would it make sense to perhaps split this patch into docbook and vb2
changes please?
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 80c588f..1b5b432 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list))
+ if (list_empty(dst_q-done_list)) {
+ /*
+* If the last buffer was dequeued from the capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (dst_q-last_buffer_dequeued)
+ return rc | POLLIN | POLLRDNORM;
These indicate there is data to be read. Is there something else we
could return? Maybe POLLHUP?
+
poll_wait(file, dst_q-done_wq, wait);
+ }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..a0b9946 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
struct vb2_buffer *vb = NULL;
int ret;
+ if (q-last_buffer_dequeued) {
+ dprintk(3, last buffer dequeued already\n);
+ return -EPIPE;
+ }
This should go after the check for queue type at least. However, best
probably to __vb2_wait_for_done_vb(), where we already have the checks
for q-streaming and q-error.
if (b-type != q-type) {
dprintk(1, invalid buffer type\n);
return -EINVAL;
@@ -2073,6 +2077,9 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
/* Remove from videobuf queue */
list_del(vb-queued_entry);
q-queued_count--;
+ if (!V4L2_TYPE_IS_OUTPUT(q-type)
+ vb-v4l2_buf.flags V4L2_BUF_FLAG_LAST)
+ q-last_buffer_dequeued = true;
/* go back to dequeued state */
__vb2_dqbuf(vb);
@@ -2286,6 +2293,7 @@ static int vb2_internal_streamoff(struct vb2_queue *q,
enum v4l2_buf_type type)
*/
__vb2_queue_cancel(q);
q-waiting_for_buffers = !V4L2_TYPE_IS_OUTPUT(q-type);
+ q-last_buffer_dequeued = false;
dprintk(3, successful\n);
return 0;
@@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
if (V4L2_TYPE_IS_OUTPUT(q-type) q-queued_count q-num_buffers)
return res | POLLOUT | POLLWRNORM;
- if (list_empty(q-done_list))
+ if (list_empty(q-done_list)) {
+ /*
+* If the last buffer was dequeued from a capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (!V4L2_TYPE_IS_OUTPUT(q-type) q-last_buffer_dequeued)
Do we need to check !V4L2_TYPE_IS_OUTPUT(q-type) here? We wouldn't
have set last_buffer_dequeued to true if it wasn't, so we could drop
this check?
+ return res | POLLIN | POLLRDNORM;
Same comment as above.
+
poll_wait(file, q-done_wq, wait);
+ }
/*
* Take first buffer available for dequeuing.
diff --git
Re: [PATCH] Add support for TechniSat Skystar S2
Oh, I was doing this the wrong way then. I did have some preamble to this but it seems to have been stripped. Anyway, this patch adds support for the Technisat Skystar S2 - this has been tried before but the cx24120 driver was a bit out of shape and it didn't got any further: https://patchwork.linuxtv.org/patch/10575/ It is an old card, but currently being sold off for next to nothing, so it's proving quite popular of late. Noticing it's quite similar to the cx24116 and cx24117 I've rewritten the driver in a similar way. There were a few registers and commands from those drivers missing from this one I've tested out and found they do something so they've been added in to speed up tuning and to make get_frontend return something useful. I've only got access to 28.2E, but everything I've tried seems to work OK, on both the v3 and v5 APIs. Assuming I've read the APIs and some of the modern drivers OK it should be doing things in the reasonably modern way, but if anything else needs doing let me know. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v4.2] Marvell fixes
This supersedes https://patchwork.linuxtv.org/patch/28767 since that fell through the cracks somehow and it is now too late to merge for 4.1 :-( Added one more patch (drop support for PIX_FMT_422P) that was also Acked by Jon and the fix Y'CbCr ordering is now Cc-ed for stable for 3.19 and up. It really should be applied to 3.12 and up, but the patch won't apply for those older kernels, so I will have to manually make a patch for that once it is merged. Regards, Hans The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d: [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.2a for you to fetch changes up to f7e5c96534c40aef688d323f1b0f0a0014580b13: marvell-ccic: drop support for PIX_FMT_422P (2015-04-13 12:04:59 +0200) Hans Verkuil (19): marvell-ccic: fix vb2 warning marvell-ccic: fill in bus_info marvell-ccic: webcam drivers shouldn't support g/s_std ov7670: check for valid width/height in ov7670_enum_frame_interval marvell-ccic: fill in colorspace marvell-ccic: control handler fixes marvell-ccic: switch to struct v4l2_fh marvell-ccic: implement control events marvell-ccic: use vb2 helpers and core locking marvell-ccic: add create_bufs support marvell-ccic: add DMABUF support for all three DMA modes marvell-ccic: fix streaming issues marvell-ccic: correctly requeue buffers marvell-ccic: add planar support to dma-vmalloc marvell-ccic: drop V4L2_PIX_FMT_JPEG dead code ov7670: use colorspace SRGB instead of JPEG marvell-ccic: fix the bytesperline and sizeimage calculations marvell-ccic: fix Y'CbCr ordering marvell-ccic: drop support for PIX_FMT_422P drivers/media/i2c/ov7670.c| 25 +++- drivers/media/platform/marvell-ccic/cafe-driver.c | 1 + drivers/media/platform/marvell-ccic/mcam-core.c | 462 +++--- drivers/media/platform/marvell-ccic/mcam-core.h | 11 +- drivers/media/platform/marvell-ccic/mmp-driver.c | 1 + 5 files changed, 198 insertions(+), 302 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] media: atmel-isi: remove mck back compatiable code as it's not need
Hi, Laurent
On 4/12/2015 9:08 PM, Laurent Pinchart wrote:
Hi Josh,
Thank you for the patch.
On Thursday 09 April 2015 17:01:48 Josh Wu wrote:
The master clock should handled by sensor itself.
Signed-off-by: Josh Wu josh...@atmel.com
---
Changes in v2:
- totally remove clock_start()/clock_stop() as they are optional.
drivers/media/platform/soc_camera/atmel-isi.c | 45
1 file changed, 45 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c index 2b05f89..7bba7d9
100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -83,8 +83,6 @@ struct atmel_isi {
struct completion complete;
/* ISI peripherial clock */
struct clk *pclk;
- /* ISI_MCK, feed to camera sensor to generate pixel clock */
- struct clk *mck;
unsigned intirq;
struct isi_platform_datapdata;
@@ -727,31 +725,6 @@ static void isi_camera_remove_device(struct
soc_camera_device *icd) icd-devnum);
}
-/* Called with .host_lock held */
-static int isi_camera_clock_start(struct soc_camera_host *ici)
-{
- struct atmel_isi *isi = ici-priv;
- int ret;
-
- if (!IS_ERR(isi-mck)) {
- ret = clk_prepare_enable(isi-mck);
- if (ret) {
- return ret;
- }
- }
-
- return 0;
-}
-
-/* Called with .host_lock held */
-static void isi_camera_clock_stop(struct soc_camera_host *ici)
-{
- struct atmel_isi *isi = ici-priv;
-
- if (!IS_ERR(isi-mck))
- clk_disable_unprepare(isi-mck);
-}
-
static unsigned int isi_camera_poll(struct file *file, poll_table *pt)
{
struct soc_camera_device *icd = file-private_data;
@@ -865,8 +838,6 @@ static struct soc_camera_host_ops
isi_soc_camera_host_ops = { .owner = THIS_MODULE,
.add= isi_camera_add_device,
.remove = isi_camera_remove_device,
- .clock_start= isi_camera_clock_start,
- .clock_stop = isi_camera_clock_stop,
.set_fmt= isi_camera_set_fmt,
.try_fmt= isi_camera_try_fmt,
.get_formats= isi_camera_get_formats,
@@ -904,7 +875,6 @@ static int atmel_isi_probe_dt(struct atmel_isi *isi,
/* Default settings for ISI */
isi-pdata.full_mode = 1;
- isi-pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
You can also remove the #define ISI_DEFAULT_MCLK_FREQ at the beginning of this
file.
I'll remove the useless definition.
With this fixed,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thanks.
Best Regards,
Josh Wu
isi-pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
np = of_graph_get_next_endpoint(np, NULL);
@@ -980,21 +950,6 @@ static int atmel_isi_probe(struct platform_device
*pdev) INIT_LIST_HEAD(isi-video_buffer_list);
INIT_LIST_HEAD(isi-dma_desc_head);
- /* ISI_MCK is the sensor master clock. It should be handled by the
-* sensor driver directly, as the ISI has no use for that clock. Make
-* the clock optional here while platforms transition to the correct
-* model.
-*/
- isi-mck = devm_clk_get(dev, isi_mck);
- if (!IS_ERR(isi-mck)) {
- /* Set ISI_MCK's frequency, it should be faster than pixel
-* clock.
-*/
- ret = clk_set_rate(isi-mck, isi-pdata.mck_hz);
- if (ret 0)
- return ret;
- }
-
isi-p_fb_descriptors = dma_alloc_coherent(pdev-dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi-fb_descriptors_phys,
--
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 1/3] media: atmel-isi: remove the useless code which disable isi
Hi, Laurent
On 4/12/2015 9:10 PM, Laurent Pinchart wrote:
Hi Josh,
Thank you for the patch.
On Thursday 09 April 2015 17:01:46 Josh Wu wrote:
To program ISI control register, the pixel clock should be enabled.
That's an awful hardware design :-(
yes, But I need to live with this.
So without pixel clock (from sensor) enabled, disable ISI controller is
not make sense. So this patch remove those code.
Signed-off-by: Josh Wu josh...@atmel.com
---
Changes in v2:
- this file is new added.
drivers/media/platform/soc_camera/atmel-isi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c index c125b1d..31254b4
100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -131,8 +131,6 @@ static int configure_geometry(struct atmel_isi *isi, u32
width, return -EINVAL;
}
- isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
-
cfg2 = isi_readl(isi, ISI_CFG2);
Can the configuration registers be accessed when the pixel clock is disabled ?
yes, it can be accessed. The CFG1, CFG2 are not impacted.
So far as I know only the ISI_CR is impacted, we can
disable/enable/reset ISI by set ISI_CR.
Since ISI_CR register will work with pixel clock, so you need to poll
the ISI_SR to verify your control of ISI is effective.
Best Regards,
Josh Wu
/* Set YCC swap mode */
cfg2 = ~ISI_CFG2_YCC_SWAP_MODE_MASK;
@@ -843,7 +841,6 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
cfg1 |= ISI_CFG1_THMASK_BEATS_16;
- isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
isi_writel(isi, ISI_CFG1, cfg1);
return 0;
@@ -1022,8 +1019,6 @@ static int atmel_isi_probe(struct platform_device
*pdev) if (isi-pdata.data_width_flags ISI_DATAWIDTH_10)
isi-width_flags |= 1 9;
- isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
-
irq = platform_get_irq(pdev, 0);
if (IS_ERR_VALUE(irq)) {
ret = irq;
--
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: i2c: ov2659: Use v4l2_of_alloc_parse_endpoint()
Hi Sakari,
Thanks for the review.
On Sat, Apr 11, 2015 at 1:48 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Prabhakar,
On Fri, Apr 10, 2015 at 11:13:28PM +0100, Lad Prabhakar wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Instead of parsing the link-frequencies property in the driver, let
v4l2_of_alloc_parse_endpoint() do it.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
This patch depends on https://patchwork.kernel.org/patch/6190901/
drivers/media/i2c/ov2659.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index edebd11..c1e310b 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1340,8 +1340,8 @@ static struct ov2659_platform_data *
ov2659_get_pdata(struct i2c_client *client)
{
struct ov2659_platform_data *pdata;
+ struct v4l2_of_endpoint *bus_cfg;
struct device_node *endpoint;
- int ret;
if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
return client-dev.platform_data;
@@ -1350,18 +1350,27 @@ ov2659_get_pdata(struct i2c_client *client)
if (!endpoint)
return NULL;
+ bus_cfg = v4l2_of_alloc_parse_endpoint(endpoint);
+ if (IS_ERR(bus_cfg)) {
+ pdata = NULL;
+ goto done;
+ }
+
pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
goto done;
- ret = of_property_read_u64(endpoint, link-frequencies,
-pdata-link_frequency);
- if (ret) {
- dev_err(client-dev, link-frequencies property not found\n);
+ if (bus_cfg-nr_of_link_frequencies != 1) {
I wonder if it should be considered a problem if the array is larger than
one item. I would not, even if the rest of the entries wouldn't be used by
the driver at the moment. Up to you.
OK will drop the check for more than one entries.
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Thanks for the Ack.
Cheers,
--Prabhakar Lad
+ dev_err(client-dev,
+ link-frequencies property not found or too many\n);
pdata = NULL;
+ goto done;
}
+ pdata-link_frequency = bus_cfg-link_frequencies[0];
+
done:
+ v4l2_of_free_endpoint(bus_cfg);
of_node_put(endpoint);
return pdata;
}
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT FIXES FOR v4.1] marvell-ccic fix
This one was part of a 4.1 pull request that never made it in time for 4.1, but this fix should really go to 4.1 since the marvell-ccic driver is currently broken (swapped color components). Regards, Hans The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d: [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.1i for you to fetch changes up to 0b2838093effc6ee07705b04c0ad3293c2bf7f6a: marvell-ccic: fix Y'CbCr ordering (2015-04-13 16:18:51 +0200) Hans Verkuil (1): marvell-ccic: fix Y'CbCr ordering drivers/media/platform/marvell-ccic/mcam-core.c | 14 +++--- drivers/media/platform/marvell-ccic/mcam-core.h | 8 2 files changed, 11 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] drx-j: Misspelled comment corrected
Signed-off-by: Cheolhyun Park pch851...@gmail.com
---
drivers/media/dvb-frontends/drx39xyj/drxj.c | 38 ++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c
b/drivers/media/dvb-frontends/drx39xyj/drxj.c
index 2bfa7a4..61f7603 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -210,7 +210,7 @@ DEFINES
/**
* \def DRXJ_DEF_I2C_ADDR
-* \brief Default I2C addres of a demodulator instance.
+* \brief Default I2C address of a demodulator instance.
*/
#define DRXJ_DEF_I2C_ADDR (0x52)
@@ -336,7 +336,7 @@ DEFINES
* MICROCODE RELATED DEFINES
*/
-/* Magic word for checking correct Endianess of microcode data */
+/* Magic word for checking correct Endianness of microcode data */
#define DRX_UCODE_MAGIC_WORD u16)'H')8)+((u16)'L'))
/* CRC flag in ucode header, flags field. */
@@ -847,9 +847,9 @@ static struct drx_common_attr drxj_default_comm_attr_g = {
static clockrate is selected */
DRX_MPEG_STR_WIDTH_1 /* MPEG Start width in clock cycles */
},
- /* Initilisations below can be ommited, they require no user input and
+ /* Initilisations below can be omitted, they require no user input and
are initialy 0, NULL or false. The compiler will initialize them to
these
- values when ommited. */
+ values when omitted. */
false, /* is_opened */
/* SCAN */
@@ -1175,7 +1175,7 @@ static u32 log1_times100(u32 x)
Now x has binary point between bit[scale] and bit[scale-1]
and 1.0 = x 2.0 */
- /* correction for divison: log(x) = log(x/y)+log(y) */
+ /* correction for division: log(x) = log(x/y)+log(y) */
y = k * u32) 1) scale) * 200);
/* remove integer part */
@@ -1653,7 +1653,7 @@ static int drxdap_fasi_write_block(struct i2c_device_addr
*dev_addr,
sequense will be visible: (1) write address {i2c addr,
4 bytes chip address} (2) write data {i2c addr, 4 bytes data
}
(3) write address (4) write data etc...
- Addres must be rewriten because HI is reset after data
transport and
+ Address must be rewriten because HI is reset after data
transport and
expects an address.
*/
todo = (block_size datasize ? block_size : datasize);
@@ -2971,7 +2971,7 @@ ctrl_set_cfg_mpeg_output(struct drx_demod_instance
*demod, struct drx_cfg_mpeg_o
} /* ext_attr-standard */
}
- if (cfg_data-enable_parallel == true) {/* MPEG data
output is paralel - clear ipr_mode[0] */
+ if (cfg_data-enable_parallel == true) {/* MPEG data
output is parallel - clear ipr_mode[0] */
fec_oc_reg_ipr_mode = (~(FEC_OC_IPR_MODE_SERIAL__M));
} else {/* MPEG data output is serial - set
ipr_mode[0] */
fec_oc_reg_ipr_mode |= FEC_OC_IPR_MODE_SERIAL__M;
@@ -3157,7 +3157,7 @@ ctrl_set_cfg_mpeg_output(struct drx_demod_instance
*demod, struct drx_cfg_mpeg_o
pr_err(error %d\n, rc);
goto rw_error;
}
- if (cfg_data-enable_parallel == true) {/* MPEG data
output is paralel - set MD1 to MD7 to output mode */
+ if (cfg_data-enable_parallel == true) {/* MPEG data
output is parallel - set MD1 to MD7 to output mode */
sio_pdr_md_cfg =
MPEG_PARALLEL_OUTPUT_PIN_DRIVE_STRENGTH
SIO_PDR_MD0_CFG_DRIVE__B | 0x03
@@ -4320,7 +4320,7 @@ static int adc_synchronization(struct drx_demod_instance
*demod)
}
if (count == 1) {
- /* Try sampling on a diffrent edge */
+ /* Try sampling on a different edge */
u16 clk_neg = 0;
rc = drxj_dap_read_reg16(dev_addr, IQM_AF_CLKNEG__A, clk_neg,
0);
@@ -6461,7 +6461,7 @@ set_qam_measurement(struct drx_demod_instance *demod,
enum drx_modulation constellation, u32 symbol_rate)
{
struct i2c_device_addr *dev_addr = NULL;/* device address for
I2C writes */
- struct drxj_data *ext_attr = NULL; /* Global data container for
DRXJ specif data */
+ struct drxj_data *ext_attr = NULL; /* Global data container for
DRXJ specific data */
int rc;
u32 fec_bits_desired = 0; /* BER accounting period */
u16 fec_rs_plen = 0;/* defines RS BER measurement period */
@@ -8864,7 +8864,7 @@ qam64auto(struct drx_demod_instance *demod,
u32 timeout_ofs = 0;
u16 data = 0;
- /* external attributes for storing aquired channel constellation */
+ /*
RE: [RFC v3 5/9] cec: add new driver for cec support.
Hi Hans,
Thank you so much for the review.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Friday, March 20, 2015 7:08 PM
Hi Kamil,
Once again thank you for continuing this work!
I do have some comments, see below.
On 03/20/2015 05:52 PM, Kamil Debski wrote:
Add the CEC framework.
Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: Merged Update author commit by Hans Verkuil]
[k.deb...@samsung.com: change kthread handling when setting logical
address]
[k.deb...@samsung.com: code cleanup and fixes]
[k.deb...@samsung.com: add missing CEC commands to match spec]
[k.deb...@samsung.com: add RC framework support]
[k.deb...@samsung.com: move and edit documentation]
[k.deb...@samsung.com: add vendor id reporting]
[k.deb...@samsung.com: add promiscuous mode]
[k.deb...@samsung.com: add possibility to clear assigned logical
addresses]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
Documentation/cec.txt| 321 +
drivers/media/Kconfig|6 +
drivers/media/Makefile |2 +
drivers/media/cec.c | 1158
++
include/media/cec.h | 137 ++
include/uapi/linux/cec.h | 283 +++
6 files changed, 1907 insertions(+)
create mode 100644 Documentation/cec.txt
create mode 100644 drivers/media/cec.c
create mode 100644 include/media/cec.h
create mode 100644 include/uapi/linux/cec.h
diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..e96fcc0
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,321 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with
HDMI CEC
+hardware. It is designed to handle a multiple variants of hardware.
Adding to
+the flexibility of the framework it enables to set which parts of
the CEC
+protocol processing is handled by the hardware, by the driver and by
the
+userspace application.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables cosumer electronic devices to communicate
with each
cosumer - consumer
+other through the HDMI connection. The protocol uses logical
addresses in the
+communication. The logical address is strictly connected with the
functionality
+provided by the device. The TV acting as the communication hub is
always
+assigned address 0. The physicall addressis determined by physical
connection
'physicall addressis' - 'physical address is'
s/by/by the/
+between devices.
+
+The protocol enables control of compatible devices with a single
remote.
+Synchronous power on/standby, instant playback with changing the
content source
+on the TV.
+
+The Kernel Interface
+
+
+CEC Adaptor
s/Adaptor/Adapter/
+---
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+/* The maximum number of logical addresses one device can be
assigned to.
+ * The CEC 2.0 spec allows for only 2 logical addresses at the
moment. The
+ * Analog Devices CEC hardware supports 3. So let's go wild and go
for 4. */
+#define CEC_MAX_LOG_ADDRS 4
+
+/* The Primary Device Type */
+#define CEC_PRIM_DEVTYPE_TV0
+#define CEC_PRIM_DEVTYPE_RECORD1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK 4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5
+#define CEC_PRIM_DEVTYPE_SWITCH6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+/* The All Device Types flags (CEC 2.0) */
+#define CEC_FL_ALL_DEVTYPE_TV (1 7)
+#define CEC_FL_ALL_DEVTYPE_RECORD (1 6)
+#define CEC_FL_ALL_DEVTYPE_TUNER (1 5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH (1 2)
+/* And if you wondering what happened to VIDEOPROC devices: those
should
+ * be mapped to a SWITCH. */
+
+/* The logical address types that the CEC device wants to claim */
+#define CEC_LOG_ADDR_TYPE_TV 0
+#define CEC_LOG_ADDR_TYPE_RECORD 1
+#define CEC_LOG_ADDR_TYPE_TUNER2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+/* Switches should use UNREGISTERED.
+ * Video processors should use SPECIFIC. */
+
+/* The CEC version */
+#define CEC_VERSION_1_4B 5
+#define CEC_VERSION_2_06
+
+struct cec_adapter {
+ /* internal fields removed */
+
+ u16 phys_addr;
+ u32 capabilities;
+ u8 version;
+ u8 num_log_addrs;
+ u8 prim_device[CEC_MAX_LOG_ADDRS];
+ u8 log_addr_type[CEC_MAX_LOG_ADDRS];
+ u8
Re: [PATCHv7] media: i2c/adp1653: Devicetree support for adp1653
Hi! #define to_adp1653_flash(sd) container_of(sd, struct adp1653_flash, subdev) Let me know if you're going to send v8 or if I can make the changes. I think we're pretty much done then. You are free to make the changes. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi Pawel,
thanks for the review!
Am Montag, den 13.04.2015, 15:30 +0900 schrieb Pawel Osciak:
Hi,
On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel p.za...@pengutronix.de wrote:
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Added DocBook update mentioning DQBUF returning -EPIPE in the
encoder/decoder
stop command documentation.
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +-
drivers/media/v4l2-core/videobuf2-core.c | 18
+-
include/media/videobuf2-core.h | 10 ++
6 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
Would it make sense to perhaps split this patch into docbook and vb2
changes please?
Alright, I'll split DocBook from vb2 changes, with the documentation
patches first.
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 80c588f..1b5b432 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list))
+ if (list_empty(dst_q-done_list)) {
+ /*
+* If the last buffer was dequeued from the capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (dst_q-last_buffer_dequeued)
+ return rc | POLLIN | POLLRDNORM;
These indicate there is data to be read. Is there something else we
could return? Maybe POLLHUP?
This is a good point, but I'm not sure. POLLHUP seems to mean a similar
thing, yet not quite the same. The documentation explicitly mentions
disconnected devices or FIFOs without writers, neither of which applies.
Also a FIFO signals POLLHUP when the last writer leaves, so we would
probably have to signal POLLHUP|POLLIN after the last buffer was decoded
for consistency, and keep that until the last buffer is dequeued. Then
we could signal POLLHUP alone here.
I didn't want to risk redefining/misinterpreting any poll(2) behavior,
so my interpretation was that POLLIN signals userspace to try a DQBUF,
as usual.
+
poll_wait(file, dst_q-done_wq, wait);
+ }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..a0b9946 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
struct vb2_buffer *vb = NULL;
int ret;
+ if (q-last_buffer_dequeued) {
+ dprintk(3, last buffer dequeued already\n);
+ return -EPIPE;
+ }
This should go after the check for queue type at least. However, best
probably to __vb2_wait_for_done_vb(), where we already have the checks
for q-streaming and q-error.
Yes, that'll be better.
if (b-type != q-type) {
dprintk(1, invalid buffer type\n);
return -EINVAL;
[...]
@@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
if (V4L2_TYPE_IS_OUTPUT(q-type) q-queued_count
q-num_buffers)
return res | POLLOUT | POLLWRNORM;
- if (list_empty(q-done_list))
+ if (list_empty(q-done_list)) {
+ /*
+* If the last buffer was dequeued from a capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ if (!V4L2_TYPE_IS_OUTPUT(q-type)
q-last_buffer_dequeued)
Do we need to check !V4L2_TYPE_IS_OUTPUT(q-type) here? We wouldn't
have set last_buffer_dequeued to true if it wasn't, so we could drop
this check?
Indeed we don't. I'll drop the check.
+
Wonga Loans
Wonga Loans Wonga Express Loan Promtion.pdf Description: Adobe PDF document
Re: [PATCHv3 00/22] marvell-ccic: drop and fix formats
On Sat, 04 Apr 2015 16:54:42 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Jon, ping! Patch 18 is merged and I have your Ack for patch 19, but I'd like your Ack as well for patches 20-22, if possible. Sorry, I'm traveling and dealing with a bunch of stuff...lots of balls falling all over the floor. You can add my ack to those patches, but let me just toss out my thoughts for consideration. At one point, the RGB444 format was what the OLPC XO was going to use for performance reasons. As I recall, when you looked recently, that was no longer the case. So that makes it safe to fix things without worrying that somebody might just be crazy enough to put a 4.x kernel on an XO and have their video be messed up. If, however, we're going to do that, we could also just fix RGB444 to actually return RGB. I'd have to go back and look (and I'm far from the manual at the moment), but I believe it was a pretty simple tweak to flip the nibbles around. jon -- 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
