RE: [PATCH v3 0/7] marvell-ccic: update ccic driver to support some features
Hi Jonathan, Do you have some comments? Regards, Libin >-Original Message- >From: Libin Yang [mailto:lby...@marvell.com] >Sent: Wednesday, July 03, 2013 1:56 PM >To: cor...@lwn.net; g.liakhovet...@gmx.de >Cc: linux-media@vger.kernel.org; albert.v.w...@gmail.com; Libin Yang >Subject: [PATCH v3 0/7] marvell-ccic: update ccic driver to support some >features > >The patch set adds some feature into the marvell ccic driver > >Patch 1: Support MIPI sensor >Patch 2: Support clock tree >Patch 3: reset ccic when stop streaming, which makes CCIC more stable >Patch 4: refine the mcam_set_contig_buffer function >Patch 5: add some new fmts to support >Patch 6: add SOF-EOF pair check to make the CCIC more stable >Patch 7: use resource managed allocation > >change log: >Patch 1: > fix the unlock issue > add some comments > remove int mipi_enabled in struct mmp_camera_platform_data > get "mipi" clk at first in mmpcam_power_up() >Patch 2: > Add mcam_deinit_clk function > Some changes in mcam_init_clk function >Patch 7: > A little adjustment based patch 2 change > >Libin Yang (7): > marvell-ccic: add MIPI support for marvell-ccic driver > marvell-ccic: add clock tree support for marvell-ccic driver > marvell-ccic: reset ccic phy when stop streaming for stability > marvell-ccic: refine mcam_set_contig_buffer function > marvell-ccic: add new formats support for marvell-ccic driver > marvell-ccic: add SOF / EOF pair check for marvell-ccic driver > marvell-ccic: switch to resource managed allocation and request > > drivers/media/platform/marvell-ccic/cafe-driver.c |4 +- > drivers/media/platform/marvell-ccic/mcam-core.c | 325 + > drivers/media/platform/marvell-ccic/mcam-core.h | 50 +++- > drivers/media/platform/marvell-ccic/mmp-driver.c | 274 ++--- > include/media/mmp-camera.h| 18 ++ > 5 files changed, 578 insertions(+), 93 deletions(-) > >-- >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 3/5] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses
Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media/v4l/subdev-formats.xml | 609 + Documentation/DocBook/media_api.tmpl | 6 + include/uapi/linux/v4l2-mediabus.h | 6 +- 3 files changed, 254 insertions(+), 367 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 0c2b1f2..9100674 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -97,31 +97,39 @@ - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier @@ -133,6 +141,14 @@ Bit + 31 + 30 + 29 + 28 + 27 + 26 + 25 + 24 23 22 21 @@ -164,7 +180,7 @@ V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE 0x1001 - &dash-ent-16; + &dash-ent-24; 0 0 0 @@ -178,7 +194,7 @@ - &dash-ent-16; + &dash-ent-24; g3 g2 g1 @@ -192,7 +208,7 @@ V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE 0x1002 - &dash-ent-16; + &dash-ent-24; g3 g2 g1 @@ -206,7 +222,7 @@ - &dash-ent-16; + &dash-ent-24; 0 0 0 @@ -220,7 +236,7 @@ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE 0x1003 - &dash-ent-16; + &dash-ent-24; 0 r4 r3 @@ -234,7 +250,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -248,7 +264,7 @@ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE 0x1004 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -262,7 +278,7 @@ - &dash-ent-16; + &dash-ent-24; 0 r4 r3 @@ -276,7 +292,7 @@ V4L2_MBUS_FMT_BGR565_2X8_BE 0x1005 - &dash-ent-16; + &dash-ent-24; b4 b3 b2 @@ -290,7 +306,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -304,7 +320,7 @@ V4L2_MBUS_FMT_BGR565_2X8_LE 0x1006 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -318,7 +334,7 @@ - &dash-ent-16; + &dash-ent-24; b4 b3 b2 @@ -332,7 +348,7 @@ V4L2_MBUS_FMT_RGB565_2X8_BE 0x1007 - &dash-ent-16; + &dash-ent-24; r4 r3 r2 @@ -346,7 +362,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -360,7 +376,7 @@ V4L2_MBUS_FMT_RGB565_2X8_LE 0x1008 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -374,7 +390,7 @@ - &dash-ent-16; + &dash-ent-24; r4 r3 r2 @@ -388,12 +404,7 @@ V4L2_MBUS_FMT_RGB666_1X18 0x1009 - - - - - - - - - - - - + &dash-ent-14; r5 r4 r3 @@ -417,6 +428,7 @@ V4L2_MBUS_FMT_RGB888_1X24 0x100a + &dash-ent-8; r7
[PATCH 4/5] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats
NV16M and NV61M are planar YCbCr 4:2:2 and YCrCb 4:2:2 formats with a
luma plane followed by an interleaved chroma plane. The planes are not
required to be contiguous in memory, and the formats can only be used
with the multi-planar formats API.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 170 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
include/uapi/linux/videodev2.h | 2 +
3 files changed, 173 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..84a8bb3
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,170 @@
+
+
+ V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M
('NM61')
+ &manvol;
+
+
+ V4L2_PIX_FMT_NV16M
+ V4L2_PIX_FMT_NV61M
+ Variation of V4L2_PIX_FMT_NV16 and
V4L2_PIX_FMT_NV61 with planes
+ non contiguous in memory.
+
+
+ Description
+
+ This is a multi-planar, two-plane version of the YUV 4:2:0 format.
+The three components are separated into two sub-images or planes.
+V4L2_PIX_FMT_NV16M differs from
V4L2_PIX_FMT_NV16
+ in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane is the same width and height, in bytes, as the Y plane.
+Each CbCr pair belongs to four pixels. For example,
+Cb0/Cr0 belongs to
+Y'00, Y'01,
+Y'10, Y'11.
+V4L2_PIX_FMT_NV61M is the same as
V4L2_PIX_FMT_NV16M
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte.
+
+ V4L2_PIX_FMT_NV16M is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in .
+
+
+ V4L2_PIX_FMT_NV16M 4 × 4 pixel
image
+
+
+ Byte Order.
+ Each cell is one byte.
+
+
+
+
+
+ start0 + 0:
+ Y'00
+ Y'01
+ Y'02
+ Y'03
+
+
+ start0 + 4:
+ Y'10
+ Y'11
+ Y'12
+ Y'13
+
+
+ start0 + 8:
+ Y'20
+ Y'21
+ Y'22
+ Y'23
+
+
+ start0 + 12:
+ Y'30
+ Y'31
+ Y'32
+ Y'33
+
+
+
+
+
+ start1 + 0:
+ Cb00
+ Cr00
+ Cb02
+ Cr02
+
+
+ start1 + 4:
+ Cb10
+ Cr10
+ Cb12
+ Cr12
+
+
+ start1 + 8:
+ Cb20
+ Cr20
+ Cb22
+ Cr22
+
+
+ start1 + 12:
+ Cb30
+ Cr30
+ Cb32
+ Cr32
+
+
+
+
+
+
+
+
+ Color Sample Location.
+
+
+
+
+
+
+
01
+ 23
+
+
+ 0
+
YY
+ YY
+
+
+
+
C
+ C
+
+
+ 1
+
YY
+ YY
+
+
+
+
C
+ C
+
+
+
+
+
+ 2
+
YY
+ YY
+
+
+
+
C
+ C
+
+
+ 3
+
YY
+ YY
+
[PATCH 0/5] Renesas VSP1 driver
Hello, Here's a driver for the VSP1 (Video Signal Processor) engine found in several Renesas R-Car SoCs. The VSP1 is a video processing engine that includes a blender, scalers, filters and statistics computation. Configurable data path routing logic allows ordering the internal blocks in a flexible way, making this driver a prime candidate for the media controller API. Due to the configurable nature of the pipeline the driver doesn't use the V4L2 mem-to-mem framework, even though the device usually operates in memory to memory mode. Only the read pixel formatters, up/down scalers, write pixel formatters and LCDC interface are supported at this stage. The patch series starts with a fix for the media controller graph traversal code, a documentation fix and new pixel format and media bus code definitions. The last patch finally adds the VSP1 driver. Laurent Pinchart (5): media: Fix circular graph traversal v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value v4l: Add media format codes for ARGB and AYUV on 32-bit busses v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats v4l: Renesas R-Car VSP1 driver Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 170 +++ Documentation/DocBook/media/v4l/pixfmt.xml |1 + Documentation/DocBook/media/v4l/subdev-formats.xml | 611 +-- Documentation/DocBook/media_api.tmpl |6 + drivers/media/media-entity.c | 17 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|2 + drivers/media/platform/vsp1/Makefile |5 + drivers/media/platform/vsp1/vsp1.h | 73 ++ drivers/media/platform/vsp1/vsp1_drv.c | 475 drivers/media/platform/vsp1/vsp1_entity.c | 186 drivers/media/platform/vsp1/vsp1_entity.h | 68 ++ drivers/media/platform/vsp1/vsp1_lif.c | 237 drivers/media/platform/vsp1/vsp1_lif.h | 38 + drivers/media/platform/vsp1/vsp1_regs.h| 581 ++ drivers/media/platform/vsp1/vsp1_rpf.c | 209 drivers/media/platform/vsp1/vsp1_rwpf.c| 124 +++ drivers/media/platform/vsp1/vsp1_rwpf.h| 56 + drivers/media/platform/vsp1/vsp1_uds.c | 346 ++ drivers/media/platform/vsp1/vsp1_uds.h | 41 + drivers/media/platform/vsp1/vsp1_video.c | 1154 drivers/media/platform/vsp1/vsp1_video.h | 144 +++ drivers/media/platform/vsp1/vsp1_wpf.c | 233 include/linux/platform_data/vsp1.h | 25 + include/uapi/linux/v4l2-mediabus.h |6 +- include/uapi/linux/videodev2.h |2 + 26 files changed, 4447 insertions(+), 373 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml create mode 100644 drivers/media/platform/vsp1/Makefile create mode 100644 drivers/media/platform/vsp1/vsp1.h create mode 100644 drivers/media/platform/vsp1/vsp1_drv.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.h create mode 100644 drivers/media/platform/vsp1/vsp1_lif.c create mode 100644 drivers/media/platform/vsp1/vsp1_lif.h create mode 100644 drivers/media/platform/vsp1/vsp1_regs.h create mode 100644 drivers/media/platform/vsp1/vsp1_rpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.h create mode 100644 drivers/media/platform/vsp1/vsp1_uds.c create mode 100644 drivers/media/platform/vsp1/vsp1_uds.h create mode 100644 drivers/media/platform/vsp1/vsp1_video.c create mode 100644 drivers/media/platform/vsp1/vsp1_video.h create mode 100644 drivers/media/platform/vsp1/vsp1_wpf.c create mode 100644 include/linux/platform_data/vsp1.h -- 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
[PATCH 2/5] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value
The V4L2_MBUS_FMT_YUV10_1X30 code is documented as being equal to 0x2014, while the v4l2-mediabus.h header defines it as 0x2016. Fix the documentation. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media/v4l/subdev-formats.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index adc6198..0c2b1f2 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2574,7 +2574,7 @@ V4L2_MBUS_FMT_YUV10_1X30 - 0x2014 + 0x2016 y9 y8 -- 1.8.1.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 1/5] media: Fix circular graph traversal
The graph traversal API (media_entity_graph_walk_*) will fail to
correctly walk the graph when circular links exist. Fix it by checking
whether an entity is already present in the stack before pushing it.
Cc: Sakari Ailus
Signed-off-by: Laurent Pinchart
---
drivers/media/media-entity.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index e1cd132..9084205 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -121,9 +121,9 @@ static struct media_entity *stack_pop(struct
media_entity_graph *graph)
return entity;
}
-#define stack_peek(en) ((en)->stack[(en)->top - 1].entity)
-#define link_top(en) ((en)->stack[(en)->top].link)
-#define stack_top(en) ((en)->stack[(en)->top].entity)
+#define stack_peek(en, i) ((en)->stack[i].entity)
+#define link_top(en) ((en)->stack[(en)->top].link)
+#define stack_top(en) ((en)->stack[(en)->top].entity)
/**
* media_entity_graph_walk_start - Start walking the media graph at a given
entity
@@ -159,6 +159,8 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
struct media_entity *
media_entity_graph_walk_next(struct media_entity_graph *graph)
{
+ unsigned int i;
+
if (stack_top(graph) == NULL)
return NULL;
@@ -181,8 +183,13 @@ media_entity_graph_walk_next(struct media_entity_graph
*graph)
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
- /* Was it the entity we came here from? */
- if (next == stack_peek(graph)) {
+ /* Is the entity already in the path? */
+ for (i = 1; i < graph->top; ++i) {
+ if (next == stack_peek(graph, i))
+ break;
+ }
+
+ if (i < graph->top) {
link_top(graph)++;
continue;
}
--
1.8.1.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 v4 0/2] Introduce buffer synchronization framework
Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. to implement generic user mode interface, we have used fcntl system call[4]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ Moreover, we had tried to find how we could utilize limited hardware resources more using buffer synchronization mechanism. And finally, we have realized that it could enhance performance using multi threads with this buffer synchronization mechanism: DMA and CPU works individually so CPU could perform other works while DMA is performing some works, and vise versa. However, in the conventional way, that is not easy to do so because DMA operation is depend on CPU operation, and vice versa. Conventional way: User Kernel - CPU writes something to src send the src to driver-> update DMA register request DMA start(1)---> DMA start <-completion signal(2)-- CPU accesses dst (1) Request DMA start after the CPU access to src buffer is completed. (2) Access dst buffer after DMA access to the dst buffer is completed. On the other hand, if there is something to control buffer access between CPU and DMA? The below shows that: User(thread a) User(thread b)Kernel - send a src to driver--> update DMA register lock the src request DMA start(1)--> CPU acccess to src unlock the srclock src and dst DMA start <-completion signal(2)- lock dst DMA completion CPU access to dst unlock src and dst unlock DST (1) Try to start DMA operation while CPU is accessing the src buffer. (2) Try CPU access to dst buffer while DMA is accessing the dst buffer. This means that CPU or DMA could do more works. In the same way, we could reduce hand shaking overhead between two processes when those processes need to share a shared buffer. There may be other cases that we could reduce overhead as well. References: [1] http://lwn.net/Articles/470339/ [2] http://lwn.net/Articles/532616/ [3] https://patchwork.kernel.org/patch/2625361/ [4] http://linux.die.net/man/2/fcntl Inki Dae (2): dmabuf-sync: Introduce buffer synchronization framework dma-buf: add lock callback for fcntl system call. Documentation/dma-buf-sync.txt | 283 + drivers/base/Kconfig |7 + drivers/base/Makefile |1 + drivers/base/dma-buf.c | 34 ++ drivers/base/dmabuf-sync.c | 661 include/linux/dma-buf.h| 14 + include/linux/dmabuf-sync.h| 132 include/linux/reservation.h|9 + 8 files changed, 1141 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call.
This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.
With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/base/dma-buf.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index fe39120..cd71447 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
static inline int is_dma_buf_file(struct file *);
@@ -82,9 +83,42 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
return dmabuf->ops->mmap(dmabuf, vma);
}
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+ struct dma_buf *dmabuf;
+ unsigned int type;
+ bool wait = false;
+
+ if (!is_dma_buf_file(file))
+ return -EINVAL;
+
+ dmabuf = file->private_data;
+
+ if ((fl->fl_type & F_UNLCK) == F_UNLCK) {
+ dmabuf_sync_single_unlock(dmabuf);
+ return 0;
+ }
+
+ /* convert flock type to dmabuf sync type. */
+ if ((fl->fl_type & F_WRLCK) == F_WRLCK)
+ type = DMA_BUF_ACCESS_W;
+ else if ((fl->fl_type & F_RDLCK) == F_RDLCK)
+ type = DMA_BUF_ACCESS_R;
+ else
+ return -EINVAL;
+
+ if (fl->fl_flags & FL_SLEEP)
+ wait = true;
+
+ /* TODO. the locking to certain region should also be considered. */
+
+ return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
+ .lock = dma_buf_lock,
};
/*
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 1/2] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and user application. This framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); ... And the below can be used as access types: DMA_BUF_ACCESS_R - CPU will access a buffer for read. DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use for device driver: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-sync&id=4030bdee9bab5841ad32faade
Re: [PATCH 5/5] v4l: Renesas R-Car VSP1 driver
On Wed 10 July 2013 12:19:32 Laurent Pinchart wrote:
> The VSP1 is a video processing engine that includes a blender, scalers,
> filters and statistics computation. Configurable data path routing logic
> allows ordering the internal blocks in a flexible way.
>
> Due to the configurable nature of the pipeline the driver implements the
> media controller API and doesn't use the V4L2 mem-to-mem framework, even
> though the device usually operates in memory to memory mode.
>
> Only the read pixel formatters, up/down scalers, write pixel formatters
> and LCDC interface are supported at this stage.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/platform/Kconfig| 10 +
> drivers/media/platform/Makefile |2 +
> drivers/media/platform/vsp1/Makefile |5 +
> drivers/media/platform/vsp1/vsp1.h| 73 ++
> drivers/media/platform/vsp1/vsp1_drv.c| 475
> drivers/media/platform/vsp1/vsp1_entity.c | 186 +
> drivers/media/platform/vsp1/vsp1_entity.h | 68 ++
> drivers/media/platform/vsp1/vsp1_lif.c| 237 ++
> drivers/media/platform/vsp1/vsp1_lif.h| 38 +
> drivers/media/platform/vsp1/vsp1_regs.h | 581 +++
> drivers/media/platform/vsp1/vsp1_rpf.c| 209 ++
> drivers/media/platform/vsp1/vsp1_rwpf.c | 124
> drivers/media/platform/vsp1/vsp1_rwpf.h | 56 ++
> drivers/media/platform/vsp1/vsp1_uds.c| 346 +
> drivers/media/platform/vsp1/vsp1_uds.h| 41 +
> drivers/media/platform/vsp1/vsp1_video.c | 1154
> +
> drivers/media/platform/vsp1/vsp1_video.h | 144
> drivers/media/platform/vsp1/vsp1_wpf.c| 233 ++
> include/linux/platform_data/vsp1.h| 25 +
> 19 files changed, 4007 insertions(+)
> create mode 100644 drivers/media/platform/vsp1/Makefile
> create mode 100644 drivers/media/platform/vsp1/vsp1.h
> create mode 100644 drivers/media/platform/vsp1/vsp1_drv.c
> create mode 100644 drivers/media/platform/vsp1/vsp1_entity.c
> create mode 100644 drivers/media/platform/vsp1/vsp1_entity.h
> create mode 100644 drivers/media/platform/vsp1/vsp1_lif.c
> create mode 100644 drivers/media/platform/vsp1/vsp1_lif.h
> create mode 100644 drivers/media/platform/vsp1/vsp1_regs.h
> create mode 100644 drivers/media/platform/vsp1/vsp1_rpf.c
> create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.c
> create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.h
> create mode 100644 drivers/media/platform/vsp1/vsp1_uds.c
> create mode 100644 drivers/media/platform/vsp1/vsp1_uds.h
> create mode 100644 drivers/media/platform/vsp1/vsp1_video.c
> create mode 100644 drivers/media/platform/vsp1/vsp1_video.h
> create mode 100644 drivers/media/platform/vsp1/vsp1_wpf.c
> create mode 100644 include/linux/platform_data/vsp1.h
>
Hi Laurent,
It took some effort, but I finally did find some things to complain about :-)
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> b/drivers/media/platform/vsp1/vsp1_video.c
> new file mode 100644
> index 000..47a739a
> --- /dev/null
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
...
> +/*
> -
> + * videobuf2 Queue Operations
> + */
> +
> +static int
> +vsp1_video_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
> + unsigned int *nbuffers, unsigned int *nplanes,
> + unsigned int sizes[], void *alloc_ctxs[])
> +{
> + struct vsp1_video *video = vb2_get_drv_priv(vq);
> + struct v4l2_pix_format_mplane *format = &video->format;
> + unsigned int i;
> +
> + *nplanes = format->num_planes;
> +
> + for (i = 0; i < format->num_planes; ++i) {
> + sizes[i] = format->plane_fmt[i].sizeimage;
> + alloc_ctxs[i] = video->alloc_ctx;
> + }
> +
> + return 0;
> +}
> +
> +static int vsp1_video_buffer_prepare(struct vb2_buffer *vb)
> +{
> + struct vsp1_video *video = vb2_get_drv_priv(vb->vb2_queue);
> + struct vsp1_video_buffer *buf = to_vsp1_video_buffer(vb);
> + unsigned int i;
> +
> + buf->video = video;
> +
> + for (i = 0; i < vb->num_planes; ++i) {
> + buf->addr[i] = vb2_dma_contig_plane_dma_addr(vb, i);
> + buf->length[i] = vb2_plane_size(vb, i);
> + }
> +
> + return 0;
> +}
> +
> +static void vsp1_video_buffer_queue(struct vb2_buffer *vb)
> +{
> + struct vsp1_video *video = vb2_get_drv_priv(vb->vb2_queue);
> + struct vsp1_pipeline *pipe = to_vsp1_pipeline(&video->video.entity);
> + struct vsp1_video_buffer *buf = to_vsp1_video_buffer(vb);
> + unsigned long flags;
> + bool empty;
> +
> + spin_lock_irqsave(&video->irqlock, flags);
> + empty = list_empty(&video->irqqueue);
> + list_add_tail(&buf->queue, &video->irqqueue);
> + spin_unlock_irqrestore(&video->irqlock, flags);
> +
> + if (empty) {
> + spin_lock_irqsave(&pipe->irqloc
Re: lgdt3304
On Tue, Jul 9, 2013 at 9:40 PM, Carl-Fredrik Sundstrom wrote: > > I don't have digital cable only over the air ATSC. No one else on this list > has this card ? You are very welcome, thank you. We generally recommend Linux users purchase cards that are already supported (or semi supported), such as the HVR2250. If you're keen enough to tackle adding support for a new board then that's great news, but very few people usually have experience with hardware not yet supported. The channels.conf is capable of support digital cable and ATSC, simply change the modulation scheme and your target frequency and try again. A quick google for an equivalent ATSC channels.conf provides a lot of useful information. Create your channels.conf to match your target frequencies in Hz and use azap to debug. Eg. KPAX-CW:177028615:8VSB:65:68:2 > > Thanks /// Carl > > -Original Message- > From: linux-media-ow...@vger.kernel.org > [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Steven Toth > Sent: Tuesday, July 09, 2013 9:54 AM > To: Carl-Fredrik Sundstrom > Cc: Devin Heitmueller; linux-media@vger.kernel.org > Subject: Re: lgdt3304 > >> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > tune to: 57028615:8VSB >> WARNING: >>> tuning failed!!! > tune to: 57028615:8VSB (tuning failed) > > I don't have a box in front of me but that's usually a sign that the > frequency details you are passing in are bogus, so the tuner driver is > rejecting it. > > Check your command line tuning tools and args. > > Here's a one line channels.conf for azap (US digital cable) that works fine, > and the azap console output: > > ch86:59700:QAM_256:0:0:101 > > stoth@mythbackend:~/.azap$ azap ch86 > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > tuning to 59700 Hz > video pid 0x, audio pid 0x > status 00 | signal | snr b770 | ber | unc | status 1f > | signal 0154 | snr 0154 | ber 00ad | unc 00ad | FE_HAS_LOCK status > 1f | signal 0156 | snr 0156 | ber | unc | FE_HAS_LOCK > > -- > Steven Toth - Kernel Labs > http://www.kernellabs.com -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] v4l: Renesas R-Car VSP1 driver
Hi Hans,
Thank you for the very quick review.
On Wednesday 10 July 2013 14:34:24 Hans Verkuil wrote:
> On Wed 10 July 2013 12:19:32 Laurent Pinchart wrote:
> > The VSP1 is a video processing engine that includes a blender, scalers,
> > filters and statistics computation. Configurable data path routing logic
> > allows ordering the internal blocks in a flexible way.
> >
> > Due to the configurable nature of the pipeline the driver implements the
> > media controller API and doesn't use the V4L2 mem-to-mem framework, even
> > though the device usually operates in memory to memory mode.
> >
> > Only the read pixel formatters, up/down scalers, write pixel formatters
> > and LCDC interface are supported at this stage.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/media/platform/Kconfig| 10 +
> > drivers/media/platform/Makefile |2 +
> > drivers/media/platform/vsp1/Makefile |5 +
> > drivers/media/platform/vsp1/vsp1.h| 73 ++
> > drivers/media/platform/vsp1/vsp1_drv.c| 475
> > drivers/media/platform/vsp1/vsp1_entity.c | 186 +
> > drivers/media/platform/vsp1/vsp1_entity.h | 68 ++
> > drivers/media/platform/vsp1/vsp1_lif.c| 237 ++
> > drivers/media/platform/vsp1/vsp1_lif.h| 38 +
> > drivers/media/platform/vsp1/vsp1_regs.h | 581 +++
> > drivers/media/platform/vsp1/vsp1_rpf.c| 209 ++
> > drivers/media/platform/vsp1/vsp1_rwpf.c | 124
> > drivers/media/platform/vsp1/vsp1_rwpf.h | 56 ++
> > drivers/media/platform/vsp1/vsp1_uds.c| 346 +
> > drivers/media/platform/vsp1/vsp1_uds.h| 41 +
> > drivers/media/platform/vsp1/vsp1_video.c | 1154
> > drivers/media/platform/vsp1/vsp1_video.h | 144
> > drivers/media/platform/vsp1/vsp1_wpf.c| 233 ++
> > include/linux/platform_data/vsp1.h| 25 +
> > 19 files changed, 4007 insertions(+)
> > create mode 100644 drivers/media/platform/vsp1/Makefile
> > create mode 100644 drivers/media/platform/vsp1/vsp1.h
> > create mode 100644 drivers/media/platform/vsp1/vsp1_drv.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_entity.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_entity.h
> > create mode 100644 drivers/media/platform/vsp1/vsp1_lif.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_lif.h
> > create mode 100644 drivers/media/platform/vsp1/vsp1_regs.h
> > create mode 100644 drivers/media/platform/vsp1/vsp1_rpf.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.h
> > create mode 100644 drivers/media/platform/vsp1/vsp1_uds.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_uds.h
> > create mode 100644 drivers/media/platform/vsp1/vsp1_video.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_video.h
> > create mode 100644 drivers/media/platform/vsp1/vsp1_wpf.c
> > create mode 100644 include/linux/platform_data/vsp1.h
>
> Hi Laurent,
>
> It took some effort, but I finally did find some things to complain about
> :-)
:-)
> > diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> > b/drivers/media/platform/vsp1/vsp1_video.c new file mode 100644
> > index 000..47a739a
> > --- /dev/null
> > +++ b/drivers/media/platform/vsp1/vsp1_video.c
[snip]
> > +static int __vsp1_video_try_format(struct vsp1_video *video,
> > + struct v4l2_pix_format_mplane *pix,
> > + const struct vsp1_format_info **fmtinfo)
> > +{
> > + const struct vsp1_format_info *info;
> > + unsigned int width = pix->width;
> > + unsigned int height = pix->height;
> > + unsigned int i;
> > +
> > + /* Retrieve format information and select the default format if the
> > +* requested format isn't supported.
> > +*/
> > + info = vsp1_get_format_info(pix->pixelformat);
> > + if (info == NULL)
> > + info = vsp1_get_format_info(VSP1_VIDEO_DEF_FORMAT);
> > +
> > + pix->pixelformat = info->fourcc;
> > + pix->colorspace = V4L2_COLORSPACE_SRGB;
> > + pix->field = V4L2_FIELD_NONE;
>
> pix->priv should be set to 0. v4l2-compliance catches such errors, BTW.
Isn't this handled by the CLEAR_AFTER_FIELD() macros in v4l2-ioctl2.c ?
> > +
> > + /* Align the width and height for YUV 4:2:2 and 4:2:0 formats. */
> > + width = round_down(width, info->hsub);
> > + height = round_down(height, info->vsub);
> > +
> > + /* Clamp the width and height. */
> > + pix->width = clamp(width, VSP1_VIDEO_MIN_WIDTH,
> > VSP1_VIDEO_MAX_WIDTH);
> > + pix->height = clamp(height, VSP1_VIDEO_MIN_HEIGHT,
> > + VSP1_VIDEO_MAX_HEIGHT);
> > +
> > + /* Compute and clamp the stride and image size. */
> > + for (i = 0; i < max(info->planes, 2U); ++i) {
> > + unsigned int hsub = i > 0 ? info->hsub : 1;
> > + unsigned int vsub = i > 0 ? info->vsub : 1;
> > +
Re: [PATCH 5/5] v4l: Renesas R-Car VSP1 driver
On Wed July 10 2013 16:24:58 Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the very quick review.
>
> On Wednesday 10 July 2013 14:34:24 Hans Verkuil wrote:
> > On Wed 10 July 2013 12:19:32 Laurent Pinchart wrote:
> > > The VSP1 is a video processing engine that includes a blender, scalers,
> > > filters and statistics computation. Configurable data path routing logic
> > > allows ordering the internal blocks in a flexible way.
> > >
> > > Due to the configurable nature of the pipeline the driver implements the
> > > media controller API and doesn't use the V4L2 mem-to-mem framework, even
> > > though the device usually operates in memory to memory mode.
> > >
> > > Only the read pixel formatters, up/down scalers, write pixel formatters
> > > and LCDC interface are supported at this stage.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > >
> > > drivers/media/platform/Kconfig| 10 +
> > > drivers/media/platform/Makefile |2 +
> > > drivers/media/platform/vsp1/Makefile |5 +
> > > drivers/media/platform/vsp1/vsp1.h| 73 ++
> > > drivers/media/platform/vsp1/vsp1_drv.c| 475
> > > drivers/media/platform/vsp1/vsp1_entity.c | 186 +
> > > drivers/media/platform/vsp1/vsp1_entity.h | 68 ++
> > > drivers/media/platform/vsp1/vsp1_lif.c| 237 ++
> > > drivers/media/platform/vsp1/vsp1_lif.h| 38 +
> > > drivers/media/platform/vsp1/vsp1_regs.h | 581 +++
> > > drivers/media/platform/vsp1/vsp1_rpf.c| 209 ++
> > > drivers/media/platform/vsp1/vsp1_rwpf.c | 124
> > > drivers/media/platform/vsp1/vsp1_rwpf.h | 56 ++
> > > drivers/media/platform/vsp1/vsp1_uds.c| 346 +
> > > drivers/media/platform/vsp1/vsp1_uds.h| 41 +
> > > drivers/media/platform/vsp1/vsp1_video.c | 1154
> > > drivers/media/platform/vsp1/vsp1_video.h | 144
> > > drivers/media/platform/vsp1/vsp1_wpf.c| 233 ++
> > > include/linux/platform_data/vsp1.h| 25 +
> > > 19 files changed, 4007 insertions(+)
> > > create mode 100644 drivers/media/platform/vsp1/Makefile
> > > create mode 100644 drivers/media/platform/vsp1/vsp1.h
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_drv.c
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_entity.c
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_entity.h
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_lif.c
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_lif.h
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_regs.h
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_rpf.c
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.c
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.h
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_uds.c
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_uds.h
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_video.c
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_video.h
> > > create mode 100644 drivers/media/platform/vsp1/vsp1_wpf.c
> > > create mode 100644 include/linux/platform_data/vsp1.h
> >
> > Hi Laurent,
> >
> > It took some effort, but I finally did find some things to complain about
> > :-)
>
> :-)
>
> > > diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> > > b/drivers/media/platform/vsp1/vsp1_video.c new file mode 100644
> > > index 000..47a739a
> > > --- /dev/null
> > > +++ b/drivers/media/platform/vsp1/vsp1_video.c
>
> [snip]
>
> > > +static int __vsp1_video_try_format(struct vsp1_video *video,
> > > +struct v4l2_pix_format_mplane *pix,
> > > +const struct vsp1_format_info **fmtinfo)
> > > +{
> > > + const struct vsp1_format_info *info;
> > > + unsigned int width = pix->width;
> > > + unsigned int height = pix->height;
> > > + unsigned int i;
> > > +
> > > + /* Retrieve format information and select the default format if the
> > > + * requested format isn't supported.
> > > + */
> > > + info = vsp1_get_format_info(pix->pixelformat);
> > > + if (info == NULL)
> > > + info = vsp1_get_format_info(VSP1_VIDEO_DEF_FORMAT);
> > > +
> > > + pix->pixelformat = info->fourcc;
> > > + pix->colorspace = V4L2_COLORSPACE_SRGB;
> > > + pix->field = V4L2_FIELD_NONE;
> >
> > pix->priv should be set to 0. v4l2-compliance catches such errors, BTW.
>
> Isn't this handled by the CLEAR_AFTER_FIELD() macros in v4l2-ioctl2.c ?
For G_FMT, yes, but there is no CLEAR_AFTER_FIELD for S/TRY_FMT. So priv
needs to be zeroed manually.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
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 Jul 10 19:00:28 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-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: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-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: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS 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.10-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: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 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
Re: width and height of JPEG compressed images
Hi Tom,
On 07/07/2013 10:18 AM, Thomas Vajzovic wrote:
On 06 July 2013 20:58 Sylwester Nawrocki wrote:
On 07/05/2013 10:22 AM, Thomas Vajzovic wrote:
I am writing a driver for the sensor MT9D131. This device supports
digital zoom and JPEG compression.
The hardware reads AxB sensor pixels from its array, resamples them
to CxD image pixels, and then compresses them to ExF bytes.
fmt->width and fmt->height then ought to specify the size of the
compressed image ExF, that is, the size specified is the size in the
format specified (the number of JPEG_1X8), not the size it would be
in a raw format.
In VIDIOC_S_FMT 'sizeimage' specifies size of the buffer for the
compressed frame at the bridge driver side. And width/height should
specify size of the re-sampled (binning, skipping ?) frame - CxD,
if I understand what you are saying correctly.
I don't quite what transformation is done at CxD -> ExF. Why you are
using ExF (two numbers) to specify number of bytes ? And how can you
know exactly beforehand what is the frame size after compression ?
Does the sensor transmit fixed number of bytes per frame, by adding
some padding bytes if required to the compressed frame data ?
Is it something like:
sensor matrix (AxB pixels) -> binning/skipping (CxD pixels) ->
-> JPEG compresion (width = C, height = D, sizeimage ExF bytes)
I think you should use VIDIOC_S_FMT(width = C, height = D,
sizeimage = ExF) for that. And s_frame_desc sudev op could be used to
pass sizeimage to the sensor subdev driver.
Yes you are correct that the sensor zero pads the compressed data to a
fixed size. That size must be specified in two separate registers,
called spoof width and spoof height. Above CxD is the image size after
binning/skipping and resizing, ExF is the spoof size.
The reason for two numbers for the number of bytes is that as the
sensor outputs the JPEG bytes the VSYNC and HSYNC lines behave as
though they were still outputting a 2D image with 8bpp. This means
that no changes are required in the bridge hardware. I am trying to
make it so very few changes are required in the bridge driver too.
As far as the bridge driver is concerned the only size is ExF, it is
unconcerned with CxD.
OK, that sounds good.
I somehow overlooked the member sizeimage. Having re-read the
documentation I think that in the user<->bridge device the interface
is clear:
v4l2_pix_format.width= C;
v4l2_pix_format.height = D;
v4l2_pix_format.bytesperline = E;
v4l2_pix_format.sizeimage= (E * F);
bytesperline< width
(sizeimage % bytesperline) == 0
(sizeimage / bytesperline)< height
bytesperline has not much meaning for compressed formats at the video
device (DMA) driver side. For compressed streams like JPEG size of the
memory buffer to allocate is normally determined by sizeimage.
'bytesperline' could be less than 'width', that means a "virtual"
bits-per-pixel factor is less than 8. But this factor could (should?) be
configurable e.g. indirectly through V4L2_CID_JPEG_QUALITY control, and
the bridge can query it from the sensor through g_frame_desc subdev op.
The bridge has normally no clue what the compression ratio at the sensor
side is. It could hard code some default "bpp", but then it needs to be
ensured the sensor doesn't transmit more data than the size of allocated
buffer.
But the question now is how does the bridge device communicate this to
the I2C subdevice? v4l2_mbus_framefmt doesn't have bytesperline or
sizeimage, and v4l2_mbus_frame_desc_entry has only length (which I
presume is sizeimage) but not both dimensions.
That's a good question. The frame descriptors really need more discussion
and improvement, to also cover use cases as your JPEG sensor.
Currently it is pretty pre-eliminary stuff, used by just a few drivers.
Here is the original RFC from Sakari [1].
Since we can't add bytesperline/sizeimage to struct v4l2_mbus_framefmt
I think struct v4l2_mbus_frame_desc_entry needs to be extended and
interaction between subdev ops like video.{s,g}_mbus_fmt, pad.{set,get}_fmt
needs to be specified.
As a side note, looking at the MT9D131 sensor datasheet I can see it has
preview (Mode A) and capture (Mode B) modes. Are you also planning adding
proper support for switching between those modes ? I'm interested in
supporting this in standard way in V4L2, as lot's of sensors I have been
working with also support such modes.
[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg43530.html
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] v4l2: add matrix support.
Hi Hans,
Thanks for the patchset!
On Fri, Jun 28, 2013 at 02:27:30PM +0200, Hans Verkuil wrote:
From: Hans Verkuil
This patch adds core support for matrices: querying, getting and setting.
Two initial matrix types are defined for motion detection (defining regions
and thresholds).
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-dev.c | 3 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 23 -
include/media/v4l2-ioctl.h | 8 +
include/uapi/linux/videodev2.h | 64
4 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index c8859d6..5e58df6 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -598,6 +598,9 @@ static void determine_valid_ioctls(struct video_device
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_UNSUBSCRIBE_EVENT,
vidioc_unsubscribe_event);
if (ops->vidioc_enum_freq_bands || ops->vidioc_g_tuner ||
ops->vidioc_g_modulator)
set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
+ SET_VALID_IOCTL(ops, VIDIOC_QUERY_MATRIX, vidioc_query_matrix);
+ SET_VALID_IOCTL(ops, VIDIOC_G_MATRIX, vidioc_g_matrix);
+ SET_VALID_IOCTL(ops, VIDIOC_S_MATRIX, vidioc_s_matrix);
if (is_vid) {
/* video specific ioctls */
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 68e6b5e..47debfc 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -549,7 +549,7 @@ static void v4l_print_cropcap(const void *arg, bool
write_only)
const struct v4l2_cropcap *p = arg;
pr_cont("type=%s, bounds wxh=%dx%d, x,y=%d,%d, "
- "defrect wxh=%dx%d, x,y=%d,%d\n, "
+ "defrect wxh=%dx%d, x,y=%d,%d, "
"pixelaspect %d/%d\n",
prt_names(p->type, v4l2_type_names),
p->bounds.width, p->bounds.height,
@@ -831,6 +831,24 @@ static void v4l_print_freq_band(const void *arg, bool
write_only)
p->rangehigh, p->modulation);
}
+static void v4l_print_query_matrix(const void *arg, bool write_only)
+{
+ const struct v4l2_query_matrix *p = arg;
+
+ pr_cont("type=0x%x, columns=%u, rows=%u, elem_min=%lld, elem_max=%lld,
elem_size=%u\n",
+ p->type, p->columns, p->rows,
+ p->elem_min.val, p->elem_max.val, p->elem_size);
+}
+
+static void v4l_print_matrix(const void *arg, bool write_only)
+{
+ const struct v4l2_matrix *p = arg;
+
+ pr_cont("type=0x%x, wxh=%dx%d, x,y=%d,%d, matrix=%p\n",
+ p->type, p->rect.width, p->rect.height,
+ p->rect.top, p->rect.left, p->matrix);
+}
+
static void v4l_print_u32(const void *arg, bool write_only)
{
pr_cont("value=%u\n", *(const u32 *)arg);
@@ -2055,6 +2073,9 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
+ IOCTL_INFO_STD(VIDIOC_QUERY_MATRIX, vidioc_query_matrix,
v4l_print_query_matrix, INFO_FL_CLEAR(v4l2_query_matrix, ref)),
+ IOCTL_INFO_STD(VIDIOC_G_MATRIX, vidioc_g_matrix, v4l_print_matrix,
INFO_FL_CLEAR(v4l2_matrix, matrix)),
+ IOCTL_INFO_STD(VIDIOC_S_MATRIX, vidioc_s_matrix, v4l_print_matrix,
INFO_FL_PRIO | INFO_FL_CLEAR(v4l2_matrix, matrix)),
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e0b74a4..7e4538e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -271,6 +271,14 @@ struct v4l2_ioctl_ops {
int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
const struct v4l2_event_subscription
*sub);
+ /* Matrix ioctls */
+ int (*vidioc_query_matrix) (struct file *file, void *fh,
+ struct v4l2_query_matrix *qmatrix);
+ int (*vidioc_g_matrix) (struct file *file, void *fh,
+ struct v4l2_matrix *matrix);
+ int (*vidioc_s_matrix) (struct file *file, void *fh,
+ struct v4l2_matrix *matrix);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
bool valid_prio, unsigned int cmd, void
*arg);
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 95ef455..5cbe815 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1838,6 +1838,64 @@ struc
[PATCH] usb: USB host support should depend on HAS_DMA
If NO_DMA=y:
drivers/built-in.o: In function `usb_hcd_unmap_urb_setup_for_dma':
drivers/usb/core/hcd.c:1361: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `usb_hcd_unmap_urb_for_dma':
drivers/usb/core/hcd.c:1393: undefined reference to `dma_unmap_sg'
drivers/usb/core/hcd.c:1398: undefined reference to `dma_unmap_page'
drivers/usb/core/hcd.c:1403: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `usb_hcd_map_urb_for_dma':
drivers/usb/core/hcd.c:1445: undefined reference to `dma_map_single'
drivers/usb/core/hcd.c:1450: undefined reference to `dma_mapping_error'
drivers/usb/core/hcd.c:1480: undefined reference to `dma_map_sg'
drivers/usb/core/hcd.c:1495: undefined reference to `dma_map_page'
drivers/usb/core/hcd.c:1501: undefined reference to `dma_mapping_error'
drivers/usb/core/hcd.c:1507: undefined reference to `dma_map_single'
drivers/usb/core/hcd.c:1512: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `hcd_buffer_free':
drivers/usb/core/buffer.c:146: undefined reference to `dma_pool_free'
drivers/usb/core/buffer.c:150: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `hcd_buffer_destroy':
drivers/usb/core/buffer.c:90: undefined reference to `dma_pool_destroy'
drivers/built-in.o: In function `hcd_buffer_create':
drivers/usb/core/buffer.c:65: undefined reference to `dma_pool_create'
drivers/built-in.o: In function `hcd_buffer_alloc':
drivers/usb/core/buffer.c:120: undefined reference to `dma_pool_alloc'
drivers/usb/core/buffer.c:122: undefined reference to `dma_alloc_coherent'
,,,
Commit d9ea21a779278da06d0cbe989594bf542ed213d7 ("usb: host: make
USB_ARCH_HAS_?HCI obsolete") allowed to enable USB on platforms with
NO_DMA=y, and exposed several input and media USB drivers that just select
USB if USB_ARCH_HAS_HCD, without checking HAS_DMA.
Fix the former by making USB depend on HAS_DMA.
To fix the latter, instead of adding lots of "depends on HAS_DMA", make
those drivers depend on USB, instead of depending on USB_ARCH_HAS_HCD and
selecting USB. Drivers for other busses (e.g. MOUSE_SYNAPTICS_I2C) already
handle this in a similar way.
Signed-off-by: Geert Uytterhoeven
---
drivers/input/joystick/Kconfig|3 +--
drivers/input/misc/Kconfig| 15 +--
drivers/input/mouse/Kconfig |9 +++--
drivers/input/tablet/Kconfig | 15 +--
drivers/input/touchscreen/Kconfig |3 +--
drivers/media/rc/Kconfig | 21 +++--
drivers/usb/Kconfig |2 +-
7 files changed, 23 insertions(+), 45 deletions(-)
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 56eb471..d7e36fb 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -278,8 +278,7 @@ config JOYSTICK_JOYDUMP
config JOYSTICK_XPAD
tristate "X-Box gamepad support"
- depends on USB_ARCH_HAS_HCD
- select USB
+ depends on USB
help
Say Y here if you want to use the X-Box pad with your computer.
Make sure to say Y to "Joystick support" (CONFIG_INPUT_JOYDEV)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 0b541cd..00cdecb 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -286,8 +286,7 @@ config INPUT_ATLAS_BTNS
config INPUT_ATI_REMOTE2
tristate "ATI / Philips USB RF remote control"
- depends on USB_ARCH_HAS_HCD
- select USB
+ depends on USB
help
Say Y here if you want to use an ATI or Philips USB RF remote control.
These are RF remotes with USB receivers.
@@ -301,8 +300,7 @@ config INPUT_ATI_REMOTE2
config INPUT_KEYSPAN_REMOTE
tristate "Keyspan DMR USB remote control"
- depends on USB_ARCH_HAS_HCD
- select USB
+ depends on USB
help
Say Y here if you want to use a Keyspan DMR USB remote control.
Currently only the UIA-11 type of receiver has been tested. The tag
@@ -333,8 +331,7 @@ config INPUT_KXTJ9_POLLED_MODE
config INPUT_POWERMATE
tristate "Griffin PowerMate and Contour Jog support"
- depends on USB_ARCH_HAS_HCD
- select USB
+ depends on USB
help
Say Y here if you want to use Griffin PowerMate or Contour Jog
devices.
These are aluminum dials which can measure clockwise and anticlockwise
@@ -349,8 +346,7 @@ config INPUT_POWERMATE
config INPUT_YEALINK
tristate "Yealink usb-p1k voip phone"
- depends on USB_ARCH_HAS_HCD
- select USB
+ depends on USB
help
Say Y here if you want to enable keyboard and LCD functions of the
Yealink usb-p1k usb phones. The audio part is enabled by the generic
@@ -364,8 +360,7 @@ config INPUT_YEALINK
config INPUT_CM109
tristate "C-Media CM109 USB I/O Controller"
- depends on USB_ARCH_HAS_HCD
- select USB
+ depends on USB
Re: [BRAINSTORM] Controls, matrices and properties
Hi Hans, Hans Verkuil wrote: Hi all, I have been working on support for passing matrices to/from drivers using a new matrix API. See this earlier thread for more background information: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/66200 The basic feedback is that, yes, matrices are useful, but it is yet another control-like API. My problem with using the control API for things like this is that the control API has been designed for use with GUIs: e.g. the controls are elements that the end-user can modify through a GUI. Things like a matrix or some really low-level driver property are either hard to model in a GUI or too advanced and obscure for an end-user. We also have a lot of low level controls. GUI implementations can always choose not to show matrix controls. I think a low level control flag has been proposed earlier on, but AFAIR the conclusion that time around was that it's sometimes difficult to define what is actually a low level control and what isn't. IMHO (and according to Unix principles, too), APIs should provide means, not policy. Saying that controls should be used for something that can (or should) be displayed by a GUI, and what isn't displayed in a GUI isn't a control, definitely falls into this category. On the other hand, the control framework has all the desirable properties that you would want: atomicity (as far as is allowed by the hardware), the ability to get/set multiple controls in one ioctl, efficient, inheritance of subdev controls in bridge devices, events, etc. I'm wondering whether we cannot tweak the control API a bit to make it possible to use it for matrices and general 'properties' as well. The main requirement for me is that when applications enumerate over controls such properties should never turn up in the enumerations: only controls suitable for a GUI should appear. After all, an application would have no idea what to do with a matrix of e.g. 200x300 elements. This sounds like the low-level control flag. I'm certainly not against it. I have to admit I'm not someone who'd ever access controls through a GUI, and if it helps, then why not. Alternatively... how about just ignoring control types that aren't supported in GUI? That'd be probably even easier for GUIs than checking a flag --- just ignore what you don't know about. While it is possible to extend queryctrl to e.g. enumerate only properties instead of controls, it is probably better to create a new VIDIOC_QUERYPROP ioctl. Also because the v4l2_queryctrl is pretty full and has no support to set the minimum/maximum values of a 64 bit value. In addition, the name field is not needed for a property, I think. Currently the name is there for the GUI, not for identification purposes. The are drivers that use private controls the ID of which is only defined as a macro in the driver. I wonder if user space programs expect controls under certain names. Alternatively we could require that macro definitions exists for all new controls. Would you intend VIDIOC_QUERYPROP to replace VIDIOC_QUERYCTRL or not? I might just create an extended version of QUERYCTRL which would fix the limits for 64-bit controls, too... it'd be easy to add a wrapper in v4l2-ioctl.c to implement the original VIDIOV_QUERYCTRL for drivers that implement the extended version (like we've done a bunch of time already). For setting/getting controls the existing extended control API can be used, although I would be inclined to go for VIDIOC_G/S/TRY_PROPS ioctls as well. For example, when I set a matrix property it is very desirable to pass only a subset of the matrix along instead of a full matrix. In my original matrix proposal I had a v4l2_rect struct that defined that. But there is no space in struct v4l2_ext_control to store such information. Doe you have a use case for this? An unrelated thing, which is out of scope for now, but something to think about: when passing around large amounts of (configuration) data the number of times the data is copied really counts. Especially on embedded systems. Memory mapping helps avoiding problems --- what would happen is that the driver would access memory mapped to the device directly and the driver would then get the address to pass to the device as the configuration. Like video buffers, but for control, not data. This requires a new RFC (one or more). For later, definitely. In general, implementing properties requires more variation since the GUI restriction has been lifted. Also, properties can be assigned to specific internal objects (e.g. buffer specific properties), so you need fields to tell the kernel with which object the property is associated. Interesting idea. Definitely. However, although the public API is different from the control API, there is no reason not to use the internal control framework for both. This could be extended ^ 2 controls. For existing controls the scope would always be either the
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Wed, 10 Jul 2013, Geert Uytterhoeven wrote:
> If NO_DMA=y:
>
> drivers/built-in.o: In function `usb_hcd_unmap_urb_setup_for_dma':
> drivers/usb/core/hcd.c:1361: undefined reference to `dma_unmap_single'
> ,,,
>
> Commit d9ea21a779278da06d0cbe989594bf542ed213d7 ("usb: host: make
> USB_ARCH_HAS_?HCI obsolete") allowed to enable USB on platforms with
> NO_DMA=y, and exposed several input and media USB drivers that just select
> USB if USB_ARCH_HAS_HCD, without checking HAS_DMA.
>
> Fix the former by making USB depend on HAS_DMA.
This isn't right. There are USB host controllers that use PIO, not
DMA. The HAS_DMA dependency should go with the controller driver, not
the USB core.
On the other hand, the USB core does call various routines like
dma_unmap_single. It ought to be possible to compile these calls even
when DMA isn't enabled. That is, they should be defined as do-nothing
stubs.
> To fix the latter, instead of adding lots of "depends on HAS_DMA", make
> those drivers depend on USB, instead of depending on USB_ARCH_HAS_HCD and
> selecting USB. Drivers for other busses (e.g. MOUSE_SYNAPTICS_I2C) already
> handle this in a similar way.
That seems reasonable.
Alan Stern
--
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: Question: interaction between selection API, ENUM_FRAMESIZES and S_FMT?
Hi Hans, Hans Verkuil wrote: On Thu 4 July 2013 00:37:46 Sakari Ailus wrote: Hi Hans, On Tue, Jun 25, 2013 at 11:02:51AM +0200, Hans Verkuil wrote: On Tue 25 June 2013 10:21:19 Sakari Ailus wrote: Hi Hans, On Mon, Jun 24, 2013 at 02:48:15PM +0200, Hans Verkuil wrote: Hi all, While working on extending v4l2-compliance with cropping/selection test cases I decided to add support for that to vivi as well (this would give applications a good test driver to work with). However, I ran into problems how this should be implemented for V4L2 devices (we are not talking about complex media controller devices where the video pipelines are setup manually). There are two problems, one related to ENUM_FRAMESIZES and one to S_FMT. The ENUM_FRAMESIZES issue is simple: if you have a sensor that has several possible frame sizes, and that can crop, compose and/or scale, then you need to be able to set the frame size. Currently this is decided by S_FMT which Sensors have a single "frame size". Other sizes are achieved by using cropping and scaling (or binning) from the native pixel array size. The drivers should probably also expose these properties rather than advertise multiple frame sizes. The problem is that from the point of view of a generic application you really don't want to know about that. You have a number of possible framesizes and you just want to pick one. Also, the hardware may hide how each framesize was achieved and in the case of vivi or mem2mem devices things are even murkier. maps the format size to the closest valid frame size. This however makes it impossible to e.g. scale up a frame, or compose the image into a larger buffer. For video receivers this issue doesn't exist: there the size of the incoming video is decided by S_STD or S_DV_TIMINGS, but no equivalent exists for sensors. I propose that a new selection target is added: V4L2_SEL_TGT_FRAMESIZE. The smiapp (well, subdev) driver uses V4L2_SEL_TGT_CROP_BOUNDS rectangle for this purpose. It was agreed to use that instead of creating a separate "pixel array size" rectangle back then. Could it be used for the same purpose on video nodes, too? If not, then smiapp should also be switched to use the new "frame size" rectangle. The problem with CROP_BOUNDS is that it may be larger than the actual framesize, as it can include blanking (for video) or the additional border pixels in a sensor. I don't think it should include anything else than just the image. Blanking isn't valid image data, and I'd also leave any possible borders out: this is hardly interesting to the user, nor is really part of the image. That's what the user expects, right? The rest can't be meaningfully processed in anyway by hardware blocks, which would mix badly with configuring the pipeline from the user space. It's not so easy: I'm pretty sure bttv allows messing with the blanking area, and in the case of analog it can be useful in case of misalignment of syncs. Oh right --- TVs can be different. I only thought about sensors and other devices. AFAIR also the analogue text TV data is transferred in the VBI. But there's a separate way to access it. The question is: does anyone actually still use it like that? I have to admit I have absolutely no idea about that. But I still have a bttv card: I use it to receive video from my C-64 that I connect to my PC once every five years or so. ;-) If we add a new selection target for the purpose we also must define how it interacts with the existing ones. Just to tell the size of the pixel array in the coordinates of the crop bounds rectangle on the source pad would appear sound to me. To keep things generic, the crop bounds rectangle should still be supported by the drivers. -- Cheers, Sakari Ailus sakari.ai...@iki.fi -- 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: Samsung i2c subdev drivers that set sd->name
Hi Sylwester and Laurent, Sylwester Nawrocki wrote: Hi Laurent, ... We need an ioctl to report additional information about media entities (it's been on my to-do list for way too long). It could be used to report bus information as well. Yes, that sounds much more interesting than using just subdev name to sqeeze all the information in. Why we don't have such an ioctl yet anyway ? Were there some arguments against it, or its been just a low priority issue ? I think it's just been left unaddressed until now since there have been even more important things to work on. :-) I'm all for that, btw.; associating bus information to the media device instead of entities was always a little odd (feel free to blame me, too...). Perhaps we could steal some bytes from the union in struct media_entity_desc? :-) -- Cheers, Sakari Ailus sakari.ai...@iki.fi -- 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] usb: USB host support should depend on HAS_DMA
On Wednesday 10 July 2013, Alan Stern wrote:
> This isn't right. There are USB host controllers that use PIO, not
> DMA. The HAS_DMA dependency should go with the controller driver, not
> the USB core.
>
> On the other hand, the USB core does call various routines like
> dma_unmap_single. It ought to be possible to compile these calls even
> when DMA isn't enabled. That is, they should be defined as do-nothing
> stubs.
The asm-generic/dma-mapping-broken.h file intentionally causes link
errors, but that could be changed.
The better approach in my mind would be to replace code like
if (hcd->self.uses_dma)
with
if (IS_ENABLED(CONFIG_HAS_DMA) && hcd->self.uses_dma) {
which will reliably cause that reference to be omitted from object code,
but not stop giving link errors for drivers that actually require
DMA.
Arnd
--
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: Samsung i2c subdev drivers that set sd->name
Hi Sylwester, On Saturday 06 July 2013 22:50:32 Sylwester Nawrocki wrote: > Hi Laurent, > > On 07/05/2013 01:30 PM, Laurent Pinchart wrote: > > On Thursday 04 July 2013 22:19:20 Sylwester Nawrocki wrote: > >> On 07/04/2013 01:13 PM, Hans Verkuil wrote: > >>> On Thu 4 July 2013 00:49:36 Laurent Pinchart wrote: > On Thursday 27 June 2013 11:53:15 Sylwester Nawrocki wrote: > > On 06/27/2013 08:43 AM, Hans Verkuil wrote: > >> On Wed June 26 2013 11:00:51 Sakari Ailus wrote: > >>> On Tue, Jun 25, 2013 at 06:55:49PM +0200, Sylwester Nawrocki wrote: > On 06/24/2013 10:54 AM, Hans Verkuil wrote: > > [snip] > > > Before we start messing with those drivers it would be nice to have > defined rules of the media entity naming. I2C bus number and > address is not something that's useful in the media entity name. > And multiple > >>> > >>> Isn't it? > >> > >> Why not? As long as the format is strictly adhered to then I see no > >> reason not to use it. Not only does it make the name unique, it also > >> tells you where the device is in the hardware topology. > > It's a shame that entities don't have a bus info field in addition to > their name, but we have to live with that. > > Userspace needs a way to distinguish between multiple identical > subdevs. We can't rely on IDs only, as they're not guaranteed to be > stable. We thus need to use names and possibly connection information. > > Two identical sensors connected to separate receivers could be > distinguished by checking which receiver they're connected to. > Unfortunately this breaks when the two sensors are connected to the > same receiver, in which case we can only rely on the name. Media entity > names thus need to be unique when connection information can't help > distinguishing otherwise identical subdevs, which implies that subdev > names must be unique. > > >> We could make the simple rule that the driver name is the first word > >> of the name. So it would be easy to provide a function that matches > >> just the first word and ignores the bus info (if there is any). > > > > Yes, and that's basically all I needed before "fixing" those affected > > drivers. No matter what exact rules, if there are any, user space > > could handle various hardware configurations without issues. > > > > Besides, the drivers would need to strip/replace with something else > > any spaces when initializing subddev name, as that character would be > > used as the bus info delimiter ? > > Or we could decide that the bus info can't contain any space, in which > case the last space would be the delimiter. > >> > >> Sounds reasonable as well. > >> > >>> Frankly, I don't think either should contain a space :-) Today nobody is > >>> using spaces anywhere to the best of my knowledge. > >> > >> OK, then there would be spaces neither in nor in. From > >> a quick grep I can't see any driver currently using spaces in its subdev > >> name. > > > > In case of multi-subdev sensors (when the sensor includes a scaler for > > instance) the subdev names will likely be made of the sensor name (or > > driver name) and a subdev description. Something like "x pixel array" > > and "xx scaler". We could use a dash or underscore to replace spaces > > though. > > Yes, I guess dash or underscore could be well used instead of spaces. > But my feeling is that 32 characters might be often not enough to hold > longer names and bus info. Also it would be good to denote what sort of > bus we refer to, i2c, spi, usb, platform, etc. I doesn't look like we > can always fit that information in 32 characters. > > [...] > > How should bus info be retrieved if it's not part of the media entity > name ? > >>> > >>> If that subdev name is also going to be used in the MC, then yes, it > >>> should contain the i2c bus info. At the moment the v4l2 core makes no > >>> assumptions on the subdev name, other than that it must be unique. which > >>> is generally achieved by appending the i2c bus info. But some platform > >>> subdevs (non-i2c) may not have any bus info since that doesn't apply in > >>> all cases. > >>> > >>> I would propose a guideline for the subdev naming like this: > >>> > >>> > >>> where is optional and neither string contains spaces. > >> > >> Hmm, it might be inconvenient for platform subdevs. E.g. it could mean > >> something like: > >> > >> currently | > >> --+-- > >> s5p-mipi-csis.0 | s5p-mipi-csis 1180.csis > >> s5p-mipi-csis.1 | s5p-mipi-csis 1181.csis > >> FIMC-LITE.0 | FIMC-LITE 1204.fimc-lite > >> FIMC-LITE.0 | FIMC-LITE 1205.fimc-lite > >> > >> > >> The register window addresses can vary across various SoCs and
Re: Samsung i2c subdev drivers that set sd->name
Hi Sakari, On Thursday 11 July 2013 01:19:35 Sakari Ailus wrote: > Hi Sylwester and Laurent, > > Sylwester Nawrocki wrote: > > Hi Laurent, > > ... > > >> We need an ioctl to report additional information about media entities > >> (it's been on my to-do list for way too long). It could be used > >> to report bus information as well. > > > > Yes, that sounds much more interesting than using just subdev name to > > sqeeze all the information in. Why we don't have such an ioctl yet anyway > > ? Were there some arguments against it, or its been just a low priority > > issue ? > > I think it's just been left unaddressed until now since there have been > even more important things to work on. :-) I'm all for that, btw.; > associating bus information to the media device instead of entities was > always a little odd (feel free to blame me, too...). > > Perhaps we could steal some bytes from the union in struct > media_entity_desc? :-) I've thought about that as well, but we will eventually need to pass more entity information to userspace, so a new ioctl would in my opinion be better, given the potentially large size of the bus information string. -- 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: rc: ene_ir: few fixes
Any update? Best regards, Maxim Levitsky On Mon, 2013-07-08 at 03:22 +0300, Maxim Levitsky wrote: > Hi, > > Could you consider merging few fixes to my driver: > > 1. Fix accidently introduced error, that is the hardware is a bit unusual > in the way that it needs the interrupt number, and one of the recent patches > moved the irq number read to be too late for that. > > 2. I just now played with my remote that wakes the system, and noticed that > it wakes the system even if I disable the wake bit. > Just disable the device if wake is disabled, and this fixes the issue. > > 3. I noticed that debug prints from my driver don't work anymore, > and this is due to conversion to pr_dbg, which is in my opinion too > restructive in > enabling it. > If you allow, I want to use pr_info instead. > > patch #1 should go to stable as well, as it outright breaks my driver. > > PS: I am very short on time, and I will be free in about month, after I pass > another round of exams. > > Best regards, > Maxim Levitsky > -- Best regards, Maxim Levitsky Visit my blog: http://maximlevitsky.wordpress.com Warning: Above blog contains rants. -- 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] usb: USB host support should depend on HAS_DMA
On Thu, 11 Jul 2013, Arnd Bergmann wrote:
> On Wednesday 10 July 2013, Alan Stern wrote:
> > This isn't right. There are USB host controllers that use PIO, not
> > DMA. The HAS_DMA dependency should go with the controller driver, not
> > the USB core.
> >
> > On the other hand, the USB core does call various routines like
> > dma_unmap_single. It ought to be possible to compile these calls even
> > when DMA isn't enabled. That is, they should be defined as do-nothing
> > stubs.
>
> The asm-generic/dma-mapping-broken.h file intentionally causes link
> errors, but that could be changed.
>
> The better approach in my mind would be to replace code like
>
>
> if (hcd->self.uses_dma)
>
> with
>
> if (IS_ENABLED(CONFIG_HAS_DMA) && hcd->self.uses_dma) {
>
> which will reliably cause that reference to be omitted from object code,
> but not stop giving link errors for drivers that actually require
> DMA.
How will it give link errors for drivers that require DMA?
Besides, wouldn't it be better to get an error at config time rather
than at link time? Or even better still, not to be allowed to
configure drivers that depend on DMA if DMA isn't available?
If we add an explicit dependency for HAS_DMA to the Kconfig entries for
these drivers, then your suggestion would be a good way to allow
usbcore to be built independently of DMA support.
Alan Stern
--
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: lgdt3304
Thanks Steven for all the support, Now I got the master slave to work and I can scan the local FOX channel with azap tridentsx@tridentsx-P5K-E:~/.kde/share/apps/kaffeine$ azap FOX using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 599028615 Hz video pid 0x0031, audio pid 0x0034 status 01 | signal | snr | ber | unc ca8b | status 1f | signal 8e53 | snr 00c4 | ber | unc | FE_HAS_LOCK status 1f | signal 907a | snr 00c5 | ber | unc 0165 | FE_HAS_LOCK status 1f | signal 8dc8 | snr 00c4 | ber | unc | FE_HAS_LOCK status 1f | signal 8d3f | snr 00c1 | ber | unc | FE_HAS_LOCK However when I try to view or scan channels in mplayer or kaffeine it can't find them and there are some timeouts Similar to the ones I got in scan utility. kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section; type = 3 pid = 8187 kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section; type = 3 pid = 8187 Playing dvb://. dvb_tune Freq: 599028615 dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 2048 bytes dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 2048 bytes dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 2048 bytes dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 2048 bytes dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 2048 bytes dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 2048 bytes dvb_streaming_read, return 0 bytes Failed to recognize file format. When I use the scan tool I get the following for every channel that I can get a lock on in azap >>> tune to: 473028615:8VSB WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x1ffb Below is a kernel trace at the same time. It seems the tuning is successful still no channels are output at the end of scan. [ 4800.196989] tda18271_tune: [1-0060|M] freq = 473028615, ifc = 3250, bw = 600, agc_mode = 3, std = 4 [ 4800.196992] tda18271_agc: [1-0060|M] no agc configuration provided [ 4800.196996] tda18271_set_standby_mode: [1-0060|M] sm = 0, sm_lt = 0, sm_xt = 0 [ 4800.199133] tda18271_dump_regs: [1-0060|M] === TDA18271 REG DUMP === [ 4800.199136] tda18271_dump_regs: [1-0060|M] ID_BYTE= 0x84 [ 4800.199140] tda18271_dump_regs: [1-0060|M] THERMO_BYTE= 0x48 [ 4800.199143] tda18271_dump_regs: [1-0060|M] POWER_LEVEL_BYTE = 0x80 [ 4800.199146] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_1 = 0xde [ 4800.199149] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_2 = 0xb4 [ 4800.199152] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_3 = 0x1c [ 4800.199155] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_4 = 0x64 [ 4800.199157] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_5 = 0x86 [ 4800.199160] tda18271_dump_regs: [1-0060|M] CAL_POST_DIV_BYTE = 0x98 [ 4800.199163] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_1 = 0x69 [ 4800.199166] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_2 = 0x40 [ 4800.199169] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_3 = 0x00 [ 4800.199172] tda18271_dump_regs: [1-0060|M] MAIN_POST_DIV_BYTE = 0xb1 [ 4800.199175] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_1= 0x79 [ 4800.199178] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_2= 0xa8 [ 4800.199181] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_3= 0x08 [ 4800.199184] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_1= 0xfc [ 4800.199187] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_2= 0x01 [ 4800.199190] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_3= 0x84 [ 4800.199192] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_4= 0x41 [ 4800.199195] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_5= 0x01 [ 4800.199198] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_6= 0x84 [ 4800.199201] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_7= 0x41 [ 4800.199204] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_8= 0x07 [ 4800.199207] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_9 W = 0x00 [ 4800.199210] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_10 = 0x29 [ 4800.199213] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_11 = 0x96 [ 4800.199216] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_12 = 0x13 [ 4800.199219] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_13 = 0xbd [ 4800.199222] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_14 = 0x11 [ 4800.199224] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_15 = 0x85 [ 4800.199227] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_16 W = 0x00 [ 4800.199230] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_17 W = 0x4c [ 4800.199233] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_18 = 0x0c [ 4800.199236] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_19 W = 0x00 [ 4800.199239] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_20 W = 0x20 [ 4800.199242] tda18271_dump_regs: [1-0060|M]
