Re: [RFC] How implement Secure Data Path ?
Am 08.05.2015 um 10:37 schrieb Daniel Vetter: dma-buf user handles are fds, which means anything allocated can be passed around nicely already. The question really is whether we'll have one ioctl on top of a special dev node or a syscall. I thought that in these cases where the dev node is only ever used to allocate the real thing, a syscall is the preferred way to go. I'd generally prefer a /dev node instead of syscall, as they can be dynamically allocated (loaded as module, etc), which in turn offers more finer control (eg. for containers, etc). One could easily replace the it with its own implementation (w/o patching the kernel directly and reboot it). Actually, I'm a bit unhappy with the syscall inflation, in fact I'm not even a big friend of ioctl's - I'd really prefer the Plan9 way :p I guess the same kind of logic as with GEM (except preferably without the DoS security holes) applies as to why its useful to have handles to the DMA buffers. We have handles (well file descriptors) to dma-bufs already, I'm a bit confused what you mean? Just curious (as I'm pretty new to this area): how to GEM objects and dma-bufs relate to each other ? Is it possible to directly exchange buffers between GPUs, VPUs, IPUs, FBs, etc ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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] How implement Secure Data Path ?
On Thu, May 07, 2015 at 05:40:03PM +0100, One Thousand Gnomes wrote: On Thu, 7 May 2015 15:52:12 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Thu, May 07, 2015 at 03:22:20PM +0200, Thierry Reding wrote: On Wed, May 06, 2015 at 03:15:32PM +0200, Daniel Vetter wrote: Yes the idea would be a special-purpose allocater thing like ion. Might even want that to be a syscall to do it properly. Would you care to elaborate why a syscall would be more proper? Not that I'm objecting to it, just for my education. It seems to be the theme with someone proposing a global /dev node for a few system wide ioctls, then reviewers ask to make a proper ioctl out of it. E.g. kdbus, but I have vague memory of this happening a lot. kdbus is not necessarily an advert for how to do anything 8) If it can be user allocated then it really ought to be one or more device nodes IMHO, because you want the resource to be passable between users, you need a handle to it and you want it to go away nicely on last close. In the cases where the CPU is allowed to or expected to have write only access you also might want an mmap of it. dma-buf user handles are fds, which means anything allocated can be passed around nicely already. The question really is whether we'll have one ioctl on top of a special dev node or a syscall. I thought that in these cases where the dev node is only ever used to allocate the real thing, a syscall is the preferred way to go. I guess the same kind of logic as with GEM (except preferably without the DoS security holes) applies as to why its useful to have handles to the DMA buffers. We have handles (well file descriptors) to dma-bufs already, I'm a bit confused what you mean? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- 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] v4l2-subdev: allow subdev to send an event to the v4l2_device notify function
From: jean-michel.hautb...@vodalys.com jean-michel.hautb...@vodalys.com
All drivers use custom notifications, in particular when source changes.
The bridge only has to map the subdev that sends it to whatever video node it
is connected to.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
Documentation/video4linux/v4l2-framework.txt | 4
include/media/v4l2-subdev.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/Documentation/video4linux/v4l2-framework.txt
b/Documentation/video4linux/v4l2-framework.txt
index 59e619f..75d5c18 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -1129,6 +1129,10 @@ available event type is 'class base + 1'.
An example on how the V4L2 events may be used can be found in the OMAP
3 ISP driver (drivers/media/platform/omap3isp).
+A subdev can directly send an event to the v4l2_device notify function with
+V4L2_DEVICE_NOTIFY_EVENT. This allows the bridge to map the subdev that sends
+the event to the video node(s) associated with the subdev that need to be
+informed about such an event.
V4L2 clocks
---
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73..dc20102 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -40,6 +40,8 @@
#define V4L2_SUBDEV_IR_TX_NOTIFY _IOW('v', 1, u32)
#define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001
+#defineV4L2_DEVICE_NOTIFY_EVENT_IOW('v', 2, struct
v4l2_event)
+
struct v4l2_device;
struct v4l2_ctrl_handler;
struct v4l2_event_subscription;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] vb2: allow requeuing buffers while streaming
From: Hans Verkuil hans.verk...@cisco.com
vb2_buffer_done() already allows STATE_QUEUED, but currently only when not
streaming. It is useful to allow it while streaming as well, as this makes
it possible for drivers to requeue buffers while waiting for a stable
video signal.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 20cdbc0..95f3d3a 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -182,6 +182,7 @@ module_param(debug, int, 0644);
V4L2_BUF_FLAG_KEYFRAME |
V4L2_BUF_FLAG_TIMECODE)
static void __vb2_queue_cancel(struct vb2_queue *q);
+static void __enqueue_in_driver(struct vb2_buffer *vb);
/**
* __vb2_buf_mem_alloc() - allocate video memory for the given buffer
@@ -1153,8 +1154,9 @@ EXPORT_SYMBOL_GPL(vb2_plane_cookie);
/**
* vb2_buffer_done() - inform videobuf that an operation on a buffer is
finished
* @vb:vb2_buffer returned from the driver
- * @state: either VB2_BUF_STATE_DONE if the operation finished successfully
- * or VB2_BUF_STATE_ERROR if the operation finished with an error.
+ * @state: either VB2_BUF_STATE_DONE if the operation finished
successfully,
+ * VB2_BUF_STATE_ERROR if the operation finished with an error or
+ * VB2_BUF_STATE_QUEUED if the driver wants to requeue buffers.
* If start_streaming fails then it should return buffers with
state
* VB2_BUF_STATE_QUEUED to put them back into the queue.
*
@@ -1205,8 +1207,11 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
atomic_dec(q-owned_by_drv_count);
spin_unlock_irqrestore(q-done_lock, flags);
- if (state == VB2_BUF_STATE_QUEUED)
+ if (state == VB2_BUF_STATE_QUEUED) {
+ if (q-start_streaming_called)
+ __enqueue_in_driver(vb);
return;
+ }
/* Inform any processes that may be waiting for buffers */
wake_up(q-done_wq);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] adv7604/adv7842: replace FMT_CHANGED by V4L2_DEVICE_NOTIFY_EVENT
From: Hans Verkuil hans.verk...@cisco.com
This makes it easier for the bridge driver to just passthrough such
events to the corresponding device node.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 12 +---
drivers/media/i2c/adv7842.c | 11 +--
include/media/adv7604.h | 1 -
include/media/adv7842.h | 3 ---
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index c1be0f7..275a322 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -341,6 +341,11 @@ static const struct adv76xx_video_standards
adv76xx_prim_mode_hdmi_gr[] = {
{ },
};
+static const struct v4l2_event adv76xx_ev_fmt = {
+ .type = V4L2_EVENT_SOURCE_CHANGE,
+ .u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
+};
+
/* --- */
static inline struct adv76xx_state *to_state(struct v4l2_subdev *sd)
@@ -1744,11 +1749,11 @@ static int adv76xx_s_routing(struct v4l2_subdev *sd,
state-selected_input = input;
disable_input(sd);
-
select_input(sd);
-
enable_input(sd);
+ v4l2_subdev_notify(sd, V4L2_DEVICE_NOTIFY_EVENT,
+ (void *)adv76xx_ev_fmt);
return 0;
}
@@ -1915,7 +1920,8 @@ static int adv76xx_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
%s: fmt_change = 0x%x, fmt_change_digital = 0x%x\n,
__func__, fmt_change, fmt_change_digital);
- v4l2_subdev_notify(sd, ADV76XX_FMT_CHANGE, NULL);
+ v4l2_subdev_notify(sd, V4L2_DEVICE_NOTIFY_EVENT,
+ (void *)adv76xx_ev_fmt);
if (handled)
*handled = true;
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index dceabc2..f5248ba 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -242,6 +242,11 @@ static const struct adv7842_video_standards
adv7842_prim_mode_hdmi_gr[] = {
{ },
};
+static const struct v4l2_event adv7842_ev_fmt = {
+ .type = V4L2_EVENT_SOURCE_CHANGE,
+ .u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
+};
+
/* --- */
static inline struct adv7842_state *to_state(struct v4l2_subdev *sd)
@@ -1975,7 +1980,8 @@ static int adv7842_s_routing(struct v4l2_subdev *sd,
select_input(sd, state-vid_std_select);
enable_input(sd);
- v4l2_subdev_notify(sd, ADV7842_FMT_CHANGE, NULL);
+ v4l2_subdev_notify(sd, V4L2_DEVICE_NOTIFY_EVENT,
+ (void *)adv7842_ev_fmt);
return 0;
}
@@ -2208,7 +2214,8 @@ static int adv7842_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
%s: fmt_change_cp = 0x%x, fmt_change_digital = 0x%x,
fmt_change_sdp = 0x%x\n,
__func__, fmt_change_cp, fmt_change_digital,
fmt_change_sdp);
- v4l2_subdev_notify(sd, ADV7842_FMT_CHANGE, NULL);
+ v4l2_subdev_notify(sd, V4L2_DEVICE_NOTIFY_EVENT,
+ (void *)adv7842_ev_fmt);
if (handled)
*handled = true;
}
diff --git a/include/media/adv7604.h b/include/media/adv7604.h
index 9ecf353..a913859 100644
--- a/include/media/adv7604.h
+++ b/include/media/adv7604.h
@@ -168,6 +168,5 @@ enum adv76xx_pad {
/* notify events */
#define ADV76XX_HOTPLUG1
-#define ADV76XX_FMT_CHANGE 2
#endif
diff --git a/include/media/adv7842.h b/include/media/adv7842.h
index 64a66d0..1f38db8 100644
--- a/include/media/adv7842.h
+++ b/include/media/adv7842.h
@@ -230,9 +230,6 @@ struct adv7842_platform_data {
#define V4L2_CID_ADV_RX_FREE_RUN_COLOR_MANUAL (V4L2_CID_DV_CLASS_BASE +
0x1001)
#define V4L2_CID_ADV_RX_FREE_RUN_COLOR (V4L2_CID_DV_CLASS_BASE +
0x1002)
-/* notify events */
-#define ADV7842_FMT_CHANGE 1
-
/* custom ioctl, used to test the external RAM that's used by the
* deinterlacer. */
#define ADV7842_CMD_RAM_TEST _IO('V', BASE_VIDIOC_PRIVATE)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] cobalt: new HDMI Rx/Tx PCIe driver
From: Hans Verkuil hans.verk...@cisco.com Hi all, This driver is for the Cisco Cobalt card, which is a PCIe device with four HDMI inputs (adv7604) and optionally one fifth input (adv7842) or one output (adv7511). This board is not for sale (sadly) but it is used internally for testing and prototyping. Many of the HDMI/Digital Video related features that I have added to V4L2 over the last few years have been prototyped using this driver and I am planning more new features based on this board. During the ELC in San Jose a month back I discussed whether it would be OK to upstream this driver, even though the hardware is not for sale. Mauro had no problem with this and given the fact that this driver is a good starting point for similar HDMI hardware, and that this allows me to upstream new API additions showing them off in this driver (so ensuring that they are actually used somewhere), I've decided to go ahead with this. This patch series starts off with a few improvements to other drivers: The adv7842 now makes the output pixel port format configurable, just like its cousin adv7604. Note that there is one user of adv7842_platform_data: arch/blackfin/mach-bf609/boards/ezkit.c. However, this board code has been broken from the beginning and nobody noticed since gcc doesn't support the bf609. You need a custom toolchain to compile this :-( I can't do anything about this, someone (Scott Jiang?) will need to fix this. The next patch makes it possible to requeue buffers in vb2 from the driver. It's a very small change, but the cobalt driver uses that while it is waiting for a stable video signal. The next patch is from Jean-Michel Hautbois which hasn't been merged yet since no driver used that event, but in the next patch I implement it. The final patch is the cobalt driver itself. Note that the m00* headers are generated from our FPGA code (slightly cleaned up by hand), which is why there are many lines 80 columns. It makes sense in this case and it does not affect the readability, and I don't want to edit them too much since that would make it hard to handle when they are regenerated due to FPGA changes. And there are also a lot of volatile __iomem pointers: the memory-mapped registers are written and read directly using struct pointers, so you really need volatile __iomem there. In the near future I plan on added CEC support (once the CEC framework has been merged), colorspace conversion support, possibly deep color support and more. But let's try to get this driver in first. Regards, Hans Hans Verkuil (4): adv7842: Make output format configurable through pad format operations vb2: allow requeuing buffers while streaming adv7604/adv7842: replace FMT_CHANGED by V4L2_DEVICE_NOTIFY_EVENT cobalt: add new driver jean-michel.hautb...@vodalys.com (1): v4l2-subdev: allow subdev to send an event to the v4l2_device notify function Documentation/video4linux/v4l2-framework.txt |4 + MAINTAINERS|8 + drivers/media/i2c/adv7604.c| 12 +- drivers/media/i2c/adv7842.c| 280 - drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile |1 + drivers/media/pci/cobalt/Kconfig | 18 + drivers/media/pci/cobalt/Makefile |5 + drivers/media/pci/cobalt/cobalt-alsa-main.c| 162 +++ drivers/media/pci/cobalt/cobalt-alsa-pcm.c | 618 ++ drivers/media/pci/cobalt/cobalt-alsa-pcm.h | 22 + drivers/media/pci/cobalt/cobalt-alsa.h | 42 + drivers/media/pci/cobalt/cobalt-cpld.c | 341 ++ drivers/media/pci/cobalt/cobalt-cpld.h | 29 + drivers/media/pci/cobalt/cobalt-driver.c | 821 + drivers/media/pci/cobalt/cobalt-driver.h | 377 ++ drivers/media/pci/cobalt/cobalt-flash.c| 132 +++ drivers/media/pci/cobalt/cobalt-flash.h| 29 + drivers/media/pci/cobalt/cobalt-i2c.c | 396 +++ drivers/media/pci/cobalt/cobalt-i2c.h | 25 + drivers/media/pci/cobalt/cobalt-irq.c | 254 drivers/media/pci/cobalt/cobalt-irq.h | 25 + drivers/media/pci/cobalt/cobalt-omnitek.c | 340 ++ drivers/media/pci/cobalt/cobalt-omnitek.h | 62 + drivers/media/pci/cobalt/cobalt-v4l2.c | 1248 drivers/media/pci/cobalt/cobalt-v4l2.h | 22 + .../cobalt/m00233_video_measure_memmap_package.h | 115 ++ .../pci/cobalt/m00235_fdma_packer_memmap_package.h | 44 + .../media/pci/cobalt/m00389_cvi_memmap_package.h | 59 + .../media/pci/cobalt/m00460_evcnt_memmap_package.h | 44 + .../pci/cobalt/m00473_freewheel_memmap_package.h | 57 + .../m00479_clk_loss_detector_memmap_package.h | 53 + .../m00514_syncgen_flow_evcnt_memmap_package.h | 88 ++
[PATCH 1/5] adv7842: Make output format configurable through pad format operations
From: Hans Verkuil hans.verk...@cisco.com
Replace the dummy video format operations by pad format operations that
configure the output format.
Copied from the adv7604 driver.
Note: while arch/blackfin/mach-bf609/boards/ezkit.c uses adv7842_platform_data
this source has not been updated because it is broken since the very
beginning. It depends on a struct adv7842_output_format that does not
exist.
And besides that gcc has no support for bf609 so nobody can compile it
except by installing a toolchain from ADI.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Scott Jiang scott.jiang.li...@gmail.com
---
drivers/media/i2c/adv7842.c | 269 +++-
include/media/adv7842.h | 89 ++-
2 files changed, 276 insertions(+), 82 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 86e65a8..dceabc2 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -56,6 +56,28 @@ MODULE_LICENSE(GPL);
/* ADV7842 system clock frequency */
#define ADV7842_fsc (28636360)
+#define ADV7842_RGB_OUT(1 1)
+
+#define ADV7842_OP_FORMAT_SEL_8BIT (0 0)
+#define ADV7842_OP_FORMAT_SEL_10BIT(1 0)
+#define ADV7842_OP_FORMAT_SEL_12BIT(2 0)
+
+#define ADV7842_OP_MODE_SEL_SDR_422(0 5)
+#define ADV7842_OP_MODE_SEL_DDR_422(1 5)
+#define ADV7842_OP_MODE_SEL_SDR_444(2 5)
+#define ADV7842_OP_MODE_SEL_DDR_444(3 5)
+#define ADV7842_OP_MODE_SEL_SDR_422_2X (4 5)
+#define ADV7842_OP_MODE_SEL_ADI_CM (5 5)
+
+#define ADV7842_OP_CH_SEL_GBR (0 5)
+#define ADV7842_OP_CH_SEL_GRB (1 5)
+#define ADV7842_OP_CH_SEL_BGR (2 5)
+#define ADV7842_OP_CH_SEL_RGB (3 5)
+#define ADV7842_OP_CH_SEL_BRG (4 5)
+#define ADV7842_OP_CH_SEL_RBG (5 5)
+
+#define ADV7842_OP_SWAP_CB_CR (1 0)
+
/*
**
*
@@ -64,6 +86,14 @@ MODULE_LICENSE(GPL);
**
*/
+struct adv7842_format_info {
+ u32 code;
+ u8 op_ch_sel;
+ bool rgb_out;
+ bool swap_cb_cr;
+ u8 op_format_sel;
+};
+
struct adv7842_state {
struct adv7842_platform_data pdata;
struct v4l2_subdev sd;
@@ -72,6 +102,9 @@ struct adv7842_state {
enum adv7842_mode mode;
struct v4l2_dv_timings timings;
enum adv7842_vid_std_select vid_std_select;
+
+ const struct adv7842_format_info *format;
+
v4l2_std_id norm;
struct {
u8 edid[256];
@@ -221,11 +254,21 @@ static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl
*ctrl)
return container_of(ctrl-handler, struct adv7842_state, hdl)-sd;
}
+static inline unsigned hblanking(const struct v4l2_bt_timings *t)
+{
+ return V4L2_DV_BT_BLANKING_WIDTH(t);
+}
+
static inline unsigned htotal(const struct v4l2_bt_timings *t)
{
return V4L2_DV_BT_FRAME_WIDTH(t);
}
+static inline unsigned vblanking(const struct v4l2_bt_timings *t)
+{
+ return V4L2_DV_BT_BLANKING_HEIGHT(t);
+}
+
static inline unsigned vtotal(const struct v4l2_bt_timings *t)
{
return V4L2_DV_BT_FRAME_HEIGHT(t);
@@ -335,6 +378,12 @@ static inline int io_write_and_or(struct v4l2_subdev *sd,
u8 reg, u8 mask, u8 va
return io_write(sd, reg, (io_read(sd, reg) mask) | val);
}
+static inline int io_write_clr_set(struct v4l2_subdev *sd,
+ u8 reg, u8 mask, u8 val)
+{
+ return io_write(sd, reg, (io_read(sd, reg) ~mask) | val);
+}
+
static inline int avlink_read(struct v4l2_subdev *sd, u8 reg)
{
struct adv7842_state *state = to_state(sd);
@@ -535,6 +584,64 @@ static void main_reset(struct v4l2_subdev *sd)
mdelay(5);
}
+/*
-
+ * Format helpers
+ */
+
+static const struct adv7842_format_info adv7842_formats[] = {
+ { MEDIA_BUS_FMT_RGB888_1X24, ADV7842_OP_CH_SEL_RGB, true, false,
+ ADV7842_OP_MODE_SEL_SDR_444 | ADV7842_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YUYV8_2X8, ADV7842_OP_CH_SEL_RGB, false, false,
+ ADV7842_OP_MODE_SEL_SDR_422 | ADV7842_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YVYU8_2X8, ADV7842_OP_CH_SEL_RGB, false, true,
+ ADV7842_OP_MODE_SEL_SDR_422 | ADV7842_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YUYV10_2X10, ADV7842_OP_CH_SEL_RGB, false, false,
+ ADV7842_OP_MODE_SEL_SDR_422 | ADV7842_OP_FORMAT_SEL_10BIT },
+ { MEDIA_BUS_FMT_YVYU10_2X10, ADV7842_OP_CH_SEL_RGB, false, true,
+ ADV7842_OP_MODE_SEL_SDR_422 |
Re: [PATCH v2 2/3] [media] bdisp: 2D blitter driver using v4l2 mem2mem framework
Hi Fabien,
Some comments below:
On 05/04/2015 11:24 AM, Fabien Dessenne wrote:
This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
It uses the v4l2 mem2mem framework.
The following features are supported and tested:
- Color format conversion (RGB32, RGB24, RGB16, NV12, YUV420P)
- Copy
- Scale
- Flip
- Deinterlace
- Wide (4K) picture support
- Crop
Signed-off-by: Fabien Dessenne fabien.desse...@st.com
---
drivers/media/platform/Kconfig | 10 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/sti/bdisp/Kconfig|9 +
drivers/media/platform/sti/bdisp/Makefile |3 +
drivers/media/platform/sti/bdisp/bdisp-filter.h | 346 ++
drivers/media/platform/sti/bdisp/bdisp-hw.c | 783 +
drivers/media/platform/sti/bdisp/bdisp-reg.h| 235
drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 1393
+++
drivers/media/platform/sti/bdisp/bdisp.h| 186 +++
9 files changed, 2967 insertions(+)
create mode 100644 drivers/media/platform/sti/bdisp/Kconfig
create mode 100644 drivers/media/platform/sti/bdisp/Makefile
create mode 100644 drivers/media/platform/sti/bdisp/bdisp-filter.h
create mode 100644 drivers/media/platform/sti/bdisp/bdisp-hw.c
create mode 100644 drivers/media/platform/sti/bdisp/bdisp-reg.h
create mode 100644 drivers/media/platform/sti/bdisp/bdisp-v4l2.c
create mode 100644 drivers/media/platform/sti/bdisp/bdisp.h
snip
diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
new file mode 100644
index 000..b81596f
--- /dev/null
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
snip
+/* Default format : VGA ARGB32*/
+#define BDISP_DEF_WIDTH 640
+#define BDISP_DEF_HEIGHT480
+
+static const struct bdisp_frame bdisp_dflt_fmt = {
+ .width = BDISP_DEF_WIDTH,
+ .height = BDISP_DEF_HEIGHT,
+ .fmt= bdisp_formats[0],
+ .field = V4L2_FIELD_NONE,
+ .bytesperline = BDISP_DEF_WIDTH * 4,
+ .sizeimage = BDISP_DEF_WIDTH * BDISP_DEF_HEIGHT * 4,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
Are you sure about SMPTE170M? That's generally for SDTV (e.g. PAL/SECAM/NTSC)
formats. VGA has normally colorspace SRGB.
+ .crop = {0, 0, BDISP_DEF_WIDTH, BDISP_DEF_HEIGHT},
+ .paddr = {0, 0, 0, 0}
+};
snip
+static int bdisp_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *nb_buf, unsigned int *nb_planes,
+ unsigned int sizes[], void *allocators[])
+{
+ struct bdisp_ctx *ctx = vb2_get_drv_priv(vq);
+ struct bdisp_frame *frame = ctx_get_frame(ctx, vq-type);
+
+ if (IS_ERR(frame)) {
+ dev_err(ctx-bdisp_dev-dev, Invalid frame (%p)\n, frame);
+ return PTR_ERR(frame);
+ }
+
+ if (!frame-fmt) {
+ dev_err(ctx-bdisp_dev-dev, Invalid format\n);
+ return -EINVAL;
+ }
+
+ *nb_planes = 1;
+ sizes[0] = frame-sizeimage;
+ allocators[0] = ctx-bdisp_dev-alloc_ctx;
+
+ return 0;
+}
+
+static int bdisp_buf_prepare(struct vb2_buffer *vb)
+{
+ struct bdisp_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
+ struct bdisp_frame *frame = ctx_get_frame(ctx, vb-vb2_queue-type);
+
+ if (IS_ERR(frame)) {
+ dev_err(ctx-bdisp_dev-dev, Invalid frame (%p)\n, frame);
+ return PTR_ERR(frame);
+ }
+
+ if (vb-vb2_queue-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ vb-v4l2_planes[0].bytesused = frame-sizeimage;
Please use vb2_set_plane_payload() instead.
+
+ return 0;
+}
+
+static void bdisp_buf_queue(struct vb2_buffer *vb)
+{
+ struct bdisp_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
+
+ /* return to V4L2 any 0-size buffer so it can be dequeued by user */
+ if (!vb-v4l2_planes[0].bytesused) {
Please use vb2_get_plane_payload() instead.
+ dev_dbg(ctx-bdisp_dev-dev, 0 data buffer, skip it\n);
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+ return;
+ }
+
+ if (ctx-fh.m2m_ctx)
+ v4l2_m2m_buf_queue(ctx-fh.m2m_ctx, vb);
+}
+
+static int bdisp_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct bdisp_ctx *ctx = q-drv_priv;
+ int ret = pm_runtime_get_sync(ctx-bdisp_dev-dev);
+
+ if (ret 0) {
+ dev_err(ctx-bdisp_dev-dev, failed to set runtime PM\n);
Test what happens when you force an error here. I suspect you get a warning
about unbalanced vb2 ops. You likely will have to call v4l2_m2m_buf_done()
with state VB2_BUF_STATE_QUEUE for all queued buffers to keep the vb2 ops
in balance.
+ return ret;
+ }
+
+
[PATCH] DocBook/media: remove spurious space.
Looks ugly, a space before a period at the end of a sentence. Remove it. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 1c17f80..aee91e7 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -1155,7 +1155,7 @@ in which case caches have not been used./entry entryThe buffer timestamp has been taken from the constantCLOCK_MONOTONIC/constant clock. To access the same clock outside V4L2, use - functionclock_gettime(2)/function ./entry + functionclock_gettime(2)/function./entry /row row entryconstantV4L2_BUF_FLAG_TIMESTAMP_COPY/constant/entry -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DocBook/media: improve timestamp documentation
Explain which clock was used to make the timestamp. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 50ccd33..c9c3c77 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -133,7 +133,10 @@ entrystruct timespec/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryEvent timestamp./entry + entryEvent timestamp. The timestamp has been taken from the + constantCLOCK_MONOTONIC/constant clock. To access the + same clock outside V4L2, use functionclock_gettime(2)/function. + /entry /row row entryu32/entry -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] libgencec: Add userspace library for the generic CEC kernel interface
Hi Kamil, On 05/04/2015 07:33 PM, Kamil Debski wrote: This is the first version of the libGenCEC library. It was designed to act as an interface between the generic CEC kernel API and userspace applications. It provides a simple interface for applications and an example application that can be used to test the CEC functionality. signed-off-by: Kamil Debski k.deb...@samsung.com I still strongly recommend that this library is added to the v4l-utils repo. That already has support for v4l, dvb, media controller and IR (i.e. everything under drivers/media), and the CEC library/utility should be added there IMHO. For example, I might want to use it in qv4l2, so being able to link it knowing that I always get the latest version is very useful. Also, v4l-utils is always updated to be in sync with the latest media_tree kernel, and since CEC is part of that you really don't want to reinvent the wheel in that respect. There were objections in the past to renaming v4l-utils to media-utils, but perhaps this should be revisited as it hasn't been v4l specific for a long time now. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb_usb_af9015: command failed=1 - stable: 4.0.2
On 08.05.2015 12:20, poma wrote: [0.00] Linux version 4.0.2-200.fc21.x86_64 ... [0.870875] usb 1-2: new high-speed USB device number 2 using ehci-pci [0.990286] usb 1-2: New USB device found, idVendor=15a4, idProduct=9016 [0.992575] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [0.994859] usb 1-2: Product: DVB-T 2 [1.001398] usb 1-2: Manufacturer: Afatech [1.003555] usb 1-2: SerialNumber: 01010101061 [1.009194] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 - 7 [1.011694] input: Afatech DVB-T 2 as /devices/pci:00/:00:02.1/usb1/1-2/1-2:1.1/0003:15A4:9016.0001/input/input5 [1.066814] hid-generic 0003:15A4:9016.0001: input,hidraw0: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:02.1-2/input1 [ 11.997119] usb 1-2: dvb_usb_v2: found a 'Afatech AF9015 reference design' in warm state [ 12.206778] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 12.207412] DVB: registering new adapter (Afatech AF9015 reference design) [ 12.286137] i2c i2c-13: af9013: firmware version 5.1.0.0 [ 12.289121] usb 1-2: DVB: registering adapter 0 frontend 0 (Afatech AF9013)... [ 12.343650] mxl5007t 13-00c0: creating new instance [ 12.346003] mxl5007t_get_chip_id: unknown rev (3f) [ 12.346156] mxl5007t_get_chip_id: MxL5007T detected @ 13-00c0 [ 12.350371] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 12.350649] DVB: registering new adapter (Afatech AF9015 reference design) [ 12.553632] i2c i2c-13: af9013: found a 'Afatech AF9013' in warm state [ 12.557256] i2c i2c-13: af9013: firmware version 5.1.0.0 [ 12.563779] usb 1-2: DVB: registering adapter 1 frontend 0 (Afatech AF9013)... [ 12.564554] mxl5007t 13-00c0: attaching existing instance [ 12.567004] usb 1-2: dvb_usb_af9015: command failed=1 [ 12.567555] mxl5007t_soft_reset: 521: failed! [ 12.569745] mxl5007t_attach: error -121 on line 907 [ 12.571231] usbcore: registered new interface driver dvb_usb_af9015 $ lsdvb lsdvb: Simple utility to list PCI/PCIe DVB devices Version: 0.0.4 Copyright (C) Manu Abraham $ Afatech AF9015 reference design: 3.18.12-200.fc21.x86_64- OK 3.19.7-200.fc21.x86_64 - KO 4.0.2-200.fc21.x86_64 - KO 4.1.0-0.rc2.git3.1.fc23.x86_64 - KO If you have a patch to test, shout loudly. -- 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 v6 05/11] rc: Add HDMI CEC protoctol handling
On 05/08/2015 01:02 PM, Hans Verkuil wrote: On 05/04/2015 07:32 PM, Kamil Debski wrote: Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski k.deb...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com But if you could fix the typo in the subject: protoctol - protocol, then that would be appreciated... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 07/11] DocBook/media: add CEC documentation
Hi Kamil, A few more comments about the documentation: First of all you should add some documentation about what the passthrough mode actually is. Right now all this says is that you can enable or disable it, but not what it actually does. And next I have a few small comments about the timestamp documentation: diff --git a/Documentation/DocBook/media/v4l/cec-ioc-g-event.xml b/Documentation/DocBook/media/v4l/cec-ioc-g-event.xml new file mode 100644 index 000..cbde320 --- /dev/null +++ b/Documentation/DocBook/media/v4l/cec-ioc-g-event.xml @@ -0,0 +1,125 @@ ... + refsect1 +titleDescription/title + +paraCEC devices can send asynchronous events. These can be retrieved by calling +the constantCEC_G_EVENT/constant ioctl. If the file descriptor is in non-blocking +mode and no event is pending, then it will return -1 and set errno to the EAGAIN;./para + +paraThere can be up to 40 events queued up. If more events are added, then the oldest event will be discarded./para + +table pgwide=1 frame=none id=cec-event + titlestruct structnamecec_event/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u64/entry + entrystructfieldts/structfield/entry + entryTimestamp of the event in ns./entry Timestamp of the event in ns. This is based on the monotonic clock. Applications can access this clock using functionclock_gettime(2)/function with clock ID constantCLOCK_MONOTONIC/constant. To turn this into a structnamestruct timespec/structname use: programlisting struct timespec tmspec; tmspec.tv_sec = ts / 10; tmspec.tv_nsec = ts % 10; programlisting (I hope the docbook syntax for programlisting is correct) snip diff --git a/Documentation/DocBook/media/v4l/cec-ioc-receive.xml b/Documentation/DocBook/media/v4l/cec-ioc-receive.xml new file mode 100644 index 000..dbec20a --- /dev/null +++ b/Documentation/DocBook/media/v4l/cec-ioc-receive.xml @@ -0,0 +1,185 @@ ... +table pgwide=1 frame=none id=cec-msg + titlestruct structnamecec_msg/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u64/entry + entrystructfieldts/structfield/entry + entryTimestamp of when the message was transmitted in ns in the case + of constantCEC_TRANSMIT/constant with structfieldreply/structfield + set to 0, or the timestamp of the received message in all other cases./entry The same timestamp explanation should be given here. 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
Fwd: Error with TBS6285
Hi, I'm trying to use this card for DVB-C and when I use w_scan I get this error: -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.3 frontend 'TurboSight TBS 62x1 DVBT/T2 frontend' supports INVERSION_AUTO QAM_AUTO FEC_AUTO FREQ (42.00MHz ... 1002.00MHz) This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org Any ideas? Many thanks,-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 04/11] HID: add HDMI CEC specific keycodes
On 05/04/2015 07:32 PM, Kamil Debski wrote:
Add HDMI CEC specific keycodes to the keycodes definition.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
include/uapi/linux/input.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 731417c..7430a3f 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -752,6 +752,18 @@ struct input_keymap_entry {
#define KEY_KBDINPUTASSIST_ACCEPT0x264
#define KEY_KBDINPUTASSIST_CANCEL0x265
+#define KEY_RIGHT_UP 0x266
+#define KEY_RIGHT_DOWN 0x267
+#define KEY_LEFT_UP 0x268
+#define KEY_LEFT_DOWN0x269
+
+#define KEY_NEXT_FAVORITE0x270
+#define KEY_STOP_RECORD 0x271
+#define KEY_PAUSE_RECORD 0x272
+#define KEY_VOD 0x273
+#define KEY_UNMUTE 0x274
+#define KEY_DVB 0x275
+
#define BTN_TRIGGER_HAPPY0x2c0
#define BTN_TRIGGER_HAPPY1 0x2c0
#define BTN_TRIGGER_HAPPY2 0x2c1
--
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 v6 05/11] rc: Add HDMI CEC protoctol handling
On 05/04/2015 07:32 PM, Kamil Debski wrote: Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski k.deb...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.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
[PATCH v6b 09/11] cec: adv7604: add cec support.
Hi Kamil,
I've updated this patch so that it uses _clr_set instead of _and_or for the CEC
register access code.
---
Add CEC support to the adv7604 driver.
Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: add missing methods cec/io_write_and_or]
[k.deb...@samsung.com: change adv7604 to adv76xx in added functions]
[hansv...@cisco.com: use _clr_set instead of _and_or]
---
drivers/media/i2c/adv7604.c | 200 +++-
1 file changed, 199 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index c1be0f7..dc1c82a 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -38,6 +38,7 @@
#include linux/workqueue.h
#include media/adv7604.h
+#include media/cec.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
#include media/v4l2-dv-timings.h
@@ -77,6 +78,8 @@ MODULE_LICENSE(GPL);
#define ADV76XX_OP_SWAP_CB_CR (1 0)
+#define ADV76XX_MAX_ADDRS (3)
+
enum adv76xx_type {
ADV7604,
ADV7611,
@@ -173,6 +176,10 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+ u8 cec_addr[ADV76XX_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -438,7 +445,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg,
u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_IO, reg, val);
}
-static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8
val)
+static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
{
return io_write(sd, reg, (io_read(sd, reg) ~mask) | val);
}
@@ -471,6 +479,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8
reg, u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_CEC, reg, val);
}
+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
+{
+ return cec_write(sd, reg, (cec_read(sd, reg) ~mask) | val);
+}
+
static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
{
struct adv76xx_state *state = to_state(sd);
@@ -1884,6 +1898,183 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
return 0;
}
+static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+ if ((cec_read(sd, 0x11) 0x01) == 0) {
+ v4l2_dbg(1, debug, sd, %s: tx raw: tx disabled\n, __func__);
+ return;
+ }
+
+ if (tx_raw_status 0x02) {
+ v4l2_dbg(1, debug, sd, %s: tx raw: arbitration lost\n,
+__func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_ARB_LOST);
+ return;
+ }
+ if (tx_raw_status 0x04) {
+ v4l2_dbg(1, debug, sd, %s: tx raw: retry failed\n, __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_RETRY_TIMEOUT);
+ return;
+ }
+ if (tx_raw_status 0x01) {
+ v4l2_dbg(1, debug, sd, %s: tx raw: ready ok\n, __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_OK);
+ return;
+ }
+}
+
+static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+ struct cec_msg msg;
+ u8 cec_irq;
+
+ /* cec controller */
+ cec_irq = io_read(sd, 0x4d) 0x0f;
+ if (!cec_irq)
+ return;
+
+ v4l2_dbg(1, debug, sd, %s: cec: irq 0x%x\n, __func__, cec_irq);
+ adv76xx_cec_tx_raw_status(sd, cec_irq);
+ if (cec_irq 0x08) {
+ msg.len = cec_read(sd, 0x25) 0x1f;
+ if (msg.len 16)
+ msg.len = 16;
+
+ if (msg.len) {
+ u8 i;
+
+ for (i = 0; i msg.len; i++)
+ msg.msg[i] = cec_read(sd, i + 0x15);
+ cec_write(sd, 0x26, 0x01); /* re-enable rx */
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, msg);
+ }
+ }
+
+ /* note: the bit order is swapped between 0x4d and 0x4e */
+ cec_irq = ((cec_irq 0x08) 3) | ((cec_irq 0x04) 1) |
+ ((cec_irq 0x02) 1) | ((cec_irq 0x01) 3);
+ io_write(sd, 0x4e, cec_irq);
+
+ if (handled)
+ *handled = true;
+}
+
+static int adv76xx_cec_enable(struct v4l2_subdev *sd, bool enable)
+{
+ struct adv76xx_state *state = to_state(sd);
+
+
dvb_usb_af9015: command failed=1 - stable: 4.0.2
[0.00] Linux version 4.0.2-200.fc21.x86_64 ... [0.870875] usb 1-2: new high-speed USB device number 2 using ehci-pci [0.990286] usb 1-2: New USB device found, idVendor=15a4, idProduct=9016 [0.992575] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [0.994859] usb 1-2: Product: DVB-T 2 [1.001398] usb 1-2: Manufacturer: Afatech [1.003555] usb 1-2: SerialNumber: 01010101061 [1.009194] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 - 7 [1.011694] input: Afatech DVB-T 2 as /devices/pci:00/:00:02.1/usb1/1-2/1-2:1.1/0003:15A4:9016.0001/input/input5 [1.066814] hid-generic 0003:15A4:9016.0001: input,hidraw0: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:02.1-2/input1 [ 11.997119] usb 1-2: dvb_usb_v2: found a 'Afatech AF9015 reference design' in warm state [ 12.206778] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 12.207412] DVB: registering new adapter (Afatech AF9015 reference design) [ 12.286137] i2c i2c-13: af9013: firmware version 5.1.0.0 [ 12.289121] usb 1-2: DVB: registering adapter 0 frontend 0 (Afatech AF9013)... [ 12.343650] mxl5007t 13-00c0: creating new instance [ 12.346003] mxl5007t_get_chip_id: unknown rev (3f) [ 12.346156] mxl5007t_get_chip_id: MxL5007T detected @ 13-00c0 [ 12.350371] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 12.350649] DVB: registering new adapter (Afatech AF9015 reference design) [ 12.553632] i2c i2c-13: af9013: found a 'Afatech AF9013' in warm state [ 12.557256] i2c i2c-13: af9013: firmware version 5.1.0.0 [ 12.563779] usb 1-2: DVB: registering adapter 1 frontend 0 (Afatech AF9013)... [ 12.564554] mxl5007t 13-00c0: attaching existing instance [ 12.567004] usb 1-2: dvb_usb_af9015: command failed=1 [ 12.567555] mxl5007t_soft_reset: 521: failed! [ 12.569745] mxl5007t_attach: error -121 on line 907 [ 12.571231] usbcore: registered new interface driver dvb_usb_af9015 $ lsdvb lsdvb: Simple utility to list PCI/PCIe DVB devices Version: 0.0.4 Copyright (C) Manu Abraham $ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] dma-buf: add ref counting for module as exporter
Add reference counting on a kernel module that exports dma-buf and
implements its operations. This prevents the module from being unloaded
while DMABUF file is in use.
The original patch [1] was submitted by Tomasz Stanislawski, but this
is a simpler way to do it.
v3: call module_put() as late as possible, per gregkh's comment.
v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO
macro to simplify the change.
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
[1]: https://lkml.org/lkml/2012/8/8/163
---
drivers/dma-buf/dma-buf.c | 10 +-
include/linux/dma-buf.h | 10 --
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138a6a8d..63a9914e42b8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,7 @@
#include linux/anon_inodes.h
#include linux/export.h
#include linux/debugfs.h
+#include linux/module.h
#include linux/seq_file.h
#include linux/poll.h
#include linux/reservation.h
@@ -72,6 +73,7 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
if (dmabuf-resv == (struct reservation_object *)dmabuf[1])
reservation_object_fini(dmabuf-resv);
+ module_put(dmabuf-owner);
kfree(dmabuf);
return 0;
}
@@ -302,14 +304,20 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (!try_module_get(exp_info-owner))
+ return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
- if (dmabuf == NULL)
+ if (!dmabuf) {
+ module_put(exp_info-owner);
return ERR_PTR(-ENOMEM);
+ }
dmabuf-priv = exp_info-priv;
dmabuf-ops = exp_info-ops;
dmabuf-size = exp_info-size;
dmabuf-exp_name = exp_info-exp_name;
+ dmabuf-owner = exp_info-owner;
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 2f0b431b73e0..f98bd7068d55 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -115,6 +115,8 @@ struct dma_buf_ops {
* @attachments: list of dma_buf_attachment that denotes all devices attached.
* @ops: dma_buf_ops associated with this buffer object.
* @exp_name: name of the exporter; useful for debugging.
+ * @owner: pointer to exporter module; used for refcounting when exporter is a
+ * kernel module.
* @list_node: node for dma_buf accounting and debugging.
* @priv: exporter specific private data for this buffer object.
* @resv: reservation object linked to this dma-buf
@@ -129,6 +131,7 @@ struct dma_buf {
unsigned vmapping_counter;
void *vmap_ptr;
const char *exp_name;
+ struct module *owner;
struct list_head list_node;
void *priv;
struct reservation_object *resv;
@@ -164,7 +167,8 @@ struct dma_buf_attachment {
/**
* struct dma_buf_export_info - holds information needed to export a dma_buf
- * @exp_name: name of the exporting module - useful for debugging.
+ * @exp_name: name of the exporter - useful for debugging.
+ * @owner: pointer to exporter module - used for refcounting kernel module
* @ops: Attach allocator-defined dma buf ops to the new buffer
* @size: Size of the buffer
* @flags: mode flags for the file
@@ -176,6 +180,7 @@ struct dma_buf_attachment {
*/
struct dma_buf_export_info {
const char *exp_name;
+ struct module *owner;
const struct dma_buf_ops *ops;
size_t size;
int flags;
@@ -187,7 +192,8 @@ struct dma_buf_export_info {
* helper macro for exporters; zeros and fills in most common values
*/
#define DEFINE_DMA_BUF_EXPORT_INFO(a) \
- struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
+ struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \
+.owner = THIS_MODULE }
/**
* get_dma_buf - convenience wrapper for get_file.
--
1.9.1
--
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-utils/util/dvb add -C to manpages
Hi I noticed the -C option was in the help from the -? option but not in the manpages. Cheers Vince diff --git a/utils/dvb/dvbv5-scan.1.in b/utils/dvb/dvbv5-scan.1.in index 08e3163..8016185 100644 --- a/utils/dvb/dvbv5-scan.1.in +++ b/utils/dvb/dvbv5-scan.1.in @@ -35,6 +35,9 @@ Force dvbv5\-scan to use DVBv3 only. \fB\-a\fR, \fB\-\-adapter\fR=\fIadapter#\fR Use the given adapter. Default value: 0. .TP +\fB\-C\fR, \fB\-\-cc\fR=\fIcountry_code\fR +Use the default parameters for the given country code. +.TP \fB\-d\fR, \fB\-\-demux\fR=\fIdemux#\fR Use the given demux. Default value: 0. .TP diff --git a/utils/dvb/dvbv5-zap.1.in b/utils/dvb/dvbv5-zap.1.in index adfcaac..2e471e6 100644 --- a/utils/dvb/dvbv5-zap.1.in +++ b/utils/dvb/dvbv5-zap.1.in @@ -40,6 +40,9 @@ Use the given adapter. Default value: 0. Select a different audio Packet ID (PID). The default is to use the first audio PID found at the \fBchannel-name-file\fR. .TP +\fB\-C\fR, \fB\-\-cc\fR=\fIcountry_code\fR +Use the default parameters for the given country code. +.TP \fB\-d\fR, \fB\-\-demux\fR=\fIdemux#\fR Use the given demux. Default value: 0. .TP -- 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 07/18] media controller: rename the tuner entity
On 05/08/2015 04:08 PM, Mauro Carvalho Chehab wrote: Em Fri, 08 May 2015 15:21:39 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote: Em Fri, 08 May 2015 14:13:22 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: Finally, let's rename the tuner entity. inside the media subsystem, a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV. It could even be used on other subsystems, like network, for wireless devices. So, it is not constricted to V4L2 API, or to a subdev. Let's then rename it as: MEDIA_ENT_T_V4L2_SUBDEV_TUNER - MEDIA_ENT_T_TUNER See patch 04/18. Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume that a tuner will always be mapped via V4L2 subdev API. True. Today we have subdevs that have no device node to control them, so in that case it would just be a SUBDEV entity. There are subdevs that make a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities. The question is: what are your ideas for e.g. DVB-only tuners? Would they get a DVB-like device node? (so DTV_SUBDEV) I guess we may need DVB subdevs in the future. For now, I don't see much usage. Would hybrid tuners have two device nodes? One v4l-subdev, one dvb/dtv-subdev? No. A tuner is a tuner. The very same device can be used for analog or digital TV. Ok, there are tuners that only work for digital TV (satellite tuners, typically), because satellite requires a different tuning range, and require an extra hardware to power up the satellite antena. So, on most devices, the tuner is integrated with SEC. In any case, I don't see any reason why artificially one piece of hardware component (tuner) into one subdevice entity per API. What it might make sense in the future is to have some DVB-specific ioctls for a hybrid tuner, in order to allow adjusting its internal filters to an specific digital TV standard. Just curious what your thoughts are. Brainstorming: It might be better to map each device node to an entity and each hardware component (tuner, DMA engine) to an entity, and avoid this mixing of hw entity vs device node entity. Ok, but then we need to properly define the namespaces for HW and for Linux API components. So, we would have a namespace like: - ENT_T_DEVNODE_DVB_(FE|CA|NET|DEMUX|DVR) for the DVB API device nodes; - ENT_T_DEVNODE_V4L for the radio/swradio/video/vbi devnodes, or, alternatively, use ENT_T_DEVNODE_V4L_(RADIO|SWRADIO|VIDEO|VBI); - ENT_T_HW_(TUNER|CAM_SENSOR|ATV_DEMOD|DTV_DEMOD|...) for the hardware components. In other words, the namespace would actually define two subtypes: - devnodes; - hardware components There's one advantage on this strategy: it is easier to keep backward compatibility, IMHO, as we'll be preserving 1 16 for device nodes Right, that will work. and 2 16 for hardware components. This remains problematic since I believe this should be done as a list of properties. Instead the entity type would be ENT_T_HW (if it represents actual hardware), ENT_T_SW (if it is a software implementation, for example for the DVB demux if there is no HW demux), and perhaps ENT_T_IP for representing IP blocks (not sure about this one). And the properties will tell what functions it supports. The existing 2 16 defines would only be used if the property list matches the original meaning of the define to keep it backwards compatible. Yet, we'll need to add an entity for the V4L2 hardware DMA (with makes sense to me), and this might break backward compatibility if not done well. I see this as a property as well, but otherwise I agree with this. It should be said that, in such case, hardware components will then mean not only V4L2-specific hardware (V4L2_SUBDEV_foo), but also DVB, ALSA, ... components. So, we'll still need a way to identify what of those components are V4L2 subdevs, probably using the properties API. Why? A hardware component that can be controlled via a v4l-subdev node would be linked to an entity for that v4l-subdev node. That's an API entity. The whole 'is this a v4l-subdev' question disappears, since that is now no longer relevant. Instead you will have an ENT_T_DEVNODE_V4L_SUBDEV entity linked to the hw entity. Even a radio device would fit cleanly into this: the tuner entity simply has a link to a radio device node entity. Hmm, does this also solve the control vs DMA issue? If a DEVNODE entity is hooked up to an entity with the DMA functionality, then you can stream, otherwise it is just for control. I'm not sure if this is always true, though. Of course, we can also just add the streaming/dma property to the DEVNODE entity as well. If you all agree with that, I'll respin the patch series to map the entities like that. We can interpret the existing ENT_T_HW_TUNER etc. as shorthand for a property while the property
Re: [PATCH 13/18] s5k5baf: fix subdev type
Hi Andrzej, Em Fri, 08 May 2015 15:51:16 +0200 Andrzej Hajda a.ha...@samsung.com escreveu: Hi Mauro, On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: This sensor driver is abusing MEDIA_ENT_T_V4L2_SUBDEV, creating some subdevs with a non-existing type. As this is a sensor driver, the proper type is likely MEDIA_ENT_T_CAM_SENSOR. This driver exposes two media entities: - pure camera sensor, it has type MEDIA_ENT_T_V4L2_SUBDEV_SENSOR/MEDIA_ENT_T_CAM_SENSOR, - image processing entity, I have assigned to it MEDIA_ENT_T_V4L2_SUBDEV type, as there were no better option. Maybe it would be better to introduce another define for such entities, for example MEDIA_ENT_T_CAM_ISP? The same applies to s5c73m3 driver. Yeah, a new type is needed instead of abusing MEDIA_ENT_T_V4L2_SUBDEV. Anyway this patch breaks current code as type field is used internally to distinguish both entities in subdev callbacks - s5k5baf_is_cis_subdev function. Of course the function can be rewritten if necessary. Ah, ok. Yes, the better is to rewrite it to use the new ISP type. We're still discussing the namespaces, so, for now, please consider those patches as RFC, but this is something that needs to be fixed anyway, by creating an specific type for ISP hardware. Regards, Mauro Regards Andrzej Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c index fadd48d35a55..8373552847ab 100644 --- a/drivers/media/i2c/s5k5baf.c +++ b/drivers/media/i2c/s5k5baf.c @@ -1919,7 +1919,7 @@ static int s5k5baf_configure_subdevs(struct s5k5baf *state, state-pads[PAD_CIS].flags = MEDIA_PAD_FL_SINK; state-pads[PAD_OUT].flags = MEDIA_PAD_FL_SOURCE; - sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV; + sd-entity.type = MEDIA_ENT_T_CAM_SENSOR; ret = media_entity_init(sd-entity, NUM_ISP_PADS, state-pads, 0); if (!ret) -- 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 13/18] s5k5baf: fix subdev type
Hi Mauro, On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: This sensor driver is abusing MEDIA_ENT_T_V4L2_SUBDEV, creating some subdevs with a non-existing type. As this is a sensor driver, the proper type is likely MEDIA_ENT_T_CAM_SENSOR. This driver exposes two media entities: - pure camera sensor, it has type MEDIA_ENT_T_V4L2_SUBDEV_SENSOR/MEDIA_ENT_T_CAM_SENSOR, - image processing entity, I have assigned to it MEDIA_ENT_T_V4L2_SUBDEV type, as there were no better option. Maybe it would be better to introduce another define for such entities, for example MEDIA_ENT_T_CAM_ISP? The same applies to s5c73m3 driver. Anyway this patch breaks current code as type field is used internally to distinguish both entities in subdev callbacks - s5k5baf_is_cis_subdev function. Of course the function can be rewritten if necessary. Regards Andrzej Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c index fadd48d35a55..8373552847ab 100644 --- a/drivers/media/i2c/s5k5baf.c +++ b/drivers/media/i2c/s5k5baf.c @@ -1919,7 +1919,7 @@ static int s5k5baf_configure_subdevs(struct s5k5baf *state, state-pads[PAD_CIS].flags = MEDIA_PAD_FL_SINK; state-pads[PAD_OUT].flags = MEDIA_PAD_FL_SOURCE; - sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV; + sd-entity.type = MEDIA_ENT_T_CAM_SENSOR; ret = media_entity_init(sd-entity, NUM_ISP_PADS, state-pads, 0); if (!ret) -- 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 10/18] media controller: use macros to check for V4L2 subdev entities
Em Fri, 08 May 2015 14:46:19 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
Instead of relying on media subtype, use the new macros to detect
if an entity is a subdev or an A/V DMA entity.
Please note that most drivers assume that there's just AV_DMA or
V4L2 subdevs. This is not true anymore, as we've added MC support
for DVB, and there are plans to add support for ALSA and FB/DRM
too.
Ok, on the current pipelines supported by those drivers, just V4L
stuff are there, but, assuming that some day a pipeline that also
works with other subsystems will ever added, it is better to add
explicit checks for the AV_DMA stuff.
So, a lot of what you try to do really can't be done until we have a
properties API.
Well, we need to do the changes incrementally. I suspect that the
renaming patches is a way easier to discuss/review than a properties
API patchset.
So, IMHO, we should focus on fixing the entities namespace first.
Once this is done, the internal methods could be changed to take a
properties API into account.
So, for example, let's assume that Laurent/Sakari's properties API
would have a way to tell if an entity is a v4l2 subdevice.
All such patchset would need to do is to change the implementation
of is_media_entity_v4l2_subdev() to take it into account.
In any case, we should not call an entity as V4L2_SUBDEV, as the entity
is a piece of the hardware and not a Linux Kernel V4L2 component.
Oddly enough it is not the DVB part that worries me, that
makes sense to me. But the V4L2 part has problems.
To summarize my concerns here:
The DVB (or DTV) entity types map cleanly to specific device nodes that
applications
will use to access the functionality, but AV_DMA is just much too vague. I.e.
does it mean this is a V4L2 device? Or an ALSA device? Something else?
Any better suggestion for its name?
Why have a DTV_DEMOD, DTV_DEMUX, etc. but not a MEDIA_ENT_T_V4L2?
DTV_DEMOD, DTV_DEMUX, etc are hardware components.
What V4L2 exactly means in terms of the hardware? This is currently a big
source of mess, as some drivers map this as just the DMA engine, while others
map the entire board, as the V4L2 API can control everything at the non-DTV
part of the device.
Such an
entity type clearly indicates a V4L2 device node, which is what an application
needs to know. Whether this entity has DMA (or streaming) functionality I see
as a property of the entity.
I can actually see two possible conflicting possibilities:
1) map entities as Linux components. Each entity will represent a single
devnode. Entities without devnodes won't be represented. The hardware
components would be represented as properties.
2) map entities as hardware components (or software implementation of
hardware). The Linux API components would be represented as properties.
We should pick one and make the namespace coherent with our choice.
I would prefer to see ENT_T_V4L2 and ENT_T_V4L_SUBDEV since this indicates the
crucial information of how this entity should be controlled, and use
properties
to indicate the functions of the entity (and possibly the information required
to locate the device nodes, as we discussed in San Jose).
This is consistent with the DTV entities (since each DTV entity has its own
device node and API).
Each entity may have lots of functions, depending on the hardware behind it,
so properties are ideal for that.
Finally, what to do with e.g. a radio device? Since there is no data flow but
it
only controls other entities, perhaps we should just list as properties which
other
entities are controlled it (i.e. the tuner).
I don't think we can make this right without using properties. We could get
away
with it while it was only V4L2 that used this (although it would have been
useful
even there), but this is now getting urgent.
As I said previously, we should either use properties for hardware and entities
for software or the reverse. Not mix both ;)
Regards,
Hans
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/platform/exynos4-is/common.c
b/drivers/media/platform/exynos4-is/common.c
index 0eb34ecb8ee4..1f1b9a56e24e 100644
--- a/drivers/media/platform/exynos4-is/common.c
+++ b/drivers/media/platform/exynos4-is/common.c
@@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct
media_entity *entity)
while (pad-flags MEDIA_PAD_FL_SINK) {
/* source pad */
pad = media_entity_remote_pad(pad);
- if (pad == NULL ||
- media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+ if (!is_media_entity_v4l2_subdev(pad-entity))
break;
sd = media_entity_to_v4l2_subdev(pad-entity);
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index
Re: [PATCH 07/18] media controller: rename the tuner entity
On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote: Em Fri, 08 May 2015 14:13:22 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: Finally, let's rename the tuner entity. inside the media subsystem, a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV. It could even be used on other subsystems, like network, for wireless devices. So, it is not constricted to V4L2 API, or to a subdev. Let's then rename it as: MEDIA_ENT_T_V4L2_SUBDEV_TUNER - MEDIA_ENT_T_TUNER See patch 04/18. Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume that a tuner will always be mapped via V4L2 subdev API. True. Today we have subdevs that have no device node to control them, so in that case it would just be a SUBDEV entity. There are subdevs that make a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities. The question is: what are your ideas for e.g. DVB-only tuners? Would they get a DVB-like device node? (so DTV_SUBDEV) Would hybrid tuners have two device nodes? One v4l-subdev, one dvb/dtv-subdev? Just curious what your thoughts are. Brainstorming: It might be better to map each device node to an entity and each hardware component (tuner, DMA engine) to an entity, and avoid this mixing of hw entity vs device node entity. Hmm, we need a another brainstorm meeting... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] mm: Provide new get_vaddr_frames() helper
On Wed, May 06, 2015 at 09:28:09AM +0200, Jan Kara wrote:
Provide new function get_vaddr_frames(). This function maps virtual
addresses from given start and fills given array with page frame numbers of
the corresponding pages. If given start belongs to a normal vma, the function
grabs reference to each of the pages to pin them in memory. If start
belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
must make sure pfns aren't reused for anything else while he is using
them.
This function is created for various drivers to simplify handling of
their buffers.
Signed-off-by: Jan Kara j...@suse.cz
Trivial comments only;
---
include/linux/mm.h | 44 +++
mm/gup.c | 214
+
2 files changed, 258 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0755b9fd03a7..dcd1f02a78e9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -20,6 +20,7 @@
#include linux/shrinker.h
#include linux/resource.h
#include linux/page_ext.h
+#include linux/err.h
struct mempolicy;
struct anon_vma;
@@ -1197,6 +1198,49 @@ long get_user_pages_unlocked(struct task_struct *tsk,
struct mm_struct *mm,
int write, int force, struct page **pages);
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+
+/* Container for pinned pfns / pages */
+struct frame_vector {
+ unsigned int nr_allocated; /* Number of frames we have space for */
+ unsigned int nr_frames; /* Number of frames stored in ptrs array */
+ bool got_ref; /* Did we pin pages by getting page ref? */
+ bool is_pfns; /* Does array contain pages or pfns? */
+ void *ptrs[0]; /* Array of pinned pfns / pages. Use
+ * pfns_vector_pages() or pfns_vector_pfns()
+ * for access */
+};
+
+struct frame_vector *frame_vector_create(unsigned int nr_frames);
+void frame_vector_destroy(struct frame_vector *vec);
+int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
+ bool write, bool force, struct frame_vector *vec);
+void put_vaddr_frames(struct frame_vector *vec);
+int frame_vector_to_pages(struct frame_vector *vec);
+void frame_vector_to_pfns(struct frame_vector *vec);
+
+static inline unsigned int frame_vector_count(struct frame_vector *vec)
+{
+ return vec-nr_frames;
+}
+
+static inline struct page **frame_vector_pages(struct frame_vector *vec)
+{
+ if (vec-is_pfns) {
+ int err = frame_vector_to_pages(vec);
+
+ if (err)
+ return ERR_PTR(err);
+ }
+ return (struct page **)(vec-ptrs);
+}
+
+static inline unsigned long *frame_vector_pfns(struct frame_vector *vec)
+{
+ if (!vec-is_pfns)
+ frame_vector_to_pfns(vec);
+ return (unsigned long *)(vec-ptrs);
+}
+
struct kvec;
int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
struct page **pages);
diff --git a/mm/gup.c b/mm/gup.c
index 6297f6bccfb1..8db5c40e65c4 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -8,6 +8,7 @@
#include linux/rmap.h
#include linux/swap.h
#include linux/swapops.h
+#include linux/vmalloc.h
#include linux/sched.h
#include linux/rwsem.h
@@ -936,6 +937,219 @@ int __mm_populate(unsigned long start, unsigned long
len, int ignore_errors)
return ret; /* 0 or negative error code */
}
+/*
+ * get_vaddr_frames() - map virtual addresses to pfns
+ * @start: starting user address
+ * @nr_frames: number of pages / pfns from start to map
+ * @write: whether pages will be written to by the caller
+ * @force: whether to force write access even if user mapping is
+ * readonly. This will result in the page being COWed even
+ * in MAP_SHARED mappings. You do not want this.
If they don't want it, why does it exist?
+ * @vec: structure which receives pages / pfns of the addresses mapped.
+ * It should have space for at least nr_frames entries.
+ *
+ * This function maps virtual addresses from @start and fills @vec structure
+ * with page frame numbers or page pointers to corresponding pages (choice
+ * depends on the type of the vma underlying the virtual address). If @start
+ * belongs to a normal vma, the function grabs reference to each of the pages
+ * to pin them in memory. If @start belongs to VM_IO | VM_PFNMAP vma, we
don't
+ * touch page structures and the caller must make sure pfns aren't reused for
+ * anything else while he is using them.
+ *
+ * The function returns number of pages mapped which may be less than
+ * @nr_frames. In particular we stop mapping if there are more vmas of
+ * different type underlying the specified range of virtual addresses.
+ *
+ * This function takes care of grabbing
Re: [PATCH 07/18] media controller: rename the tuner entity
Em Fri, 08 May 2015 15:21:39 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote: Em Fri, 08 May 2015 14:13:22 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: Finally, let's rename the tuner entity. inside the media subsystem, a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV. It could even be used on other subsystems, like network, for wireless devices. So, it is not constricted to V4L2 API, or to a subdev. Let's then rename it as: MEDIA_ENT_T_V4L2_SUBDEV_TUNER - MEDIA_ENT_T_TUNER See patch 04/18. Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume that a tuner will always be mapped via V4L2 subdev API. True. Today we have subdevs that have no device node to control them, so in that case it would just be a SUBDEV entity. There are subdevs that make a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities. The question is: what are your ideas for e.g. DVB-only tuners? Would they get a DVB-like device node? (so DTV_SUBDEV) I guess we may need DVB subdevs in the future. For now, I don't see much usage. Would hybrid tuners have two device nodes? One v4l-subdev, one dvb/dtv-subdev? No. A tuner is a tuner. The very same device can be used for analog or digital TV. Ok, there are tuners that only work for digital TV (satellite tuners, typically), because satellite requires a different tuning range, and require an extra hardware to power up the satellite antena. So, on most devices, the tuner is integrated with SEC. In any case, I don't see any reason why artificially one piece of hardware component (tuner) into one subdevice entity per API. What it might make sense in the future is to have some DVB-specific ioctls for a hybrid tuner, in order to allow adjusting its internal filters to an specific digital TV standard. Just curious what your thoughts are. Brainstorming: It might be better to map each device node to an entity and each hardware component (tuner, DMA engine) to an entity, and avoid this mixing of hw entity vs device node entity. Ok, but then we need to properly define the namespaces for HW and for Linux API components. So, we would have a namespace like: - ENT_T_DEVNODE_DVB_(FE|CA|NET|DEMUX|DVR) for the DVB API device nodes; - ENT_T_DEVNODE_V4L for the radio/swradio/video/vbi devnodes, or, alternatively, use ENT_T_DEVNODE_V4L_(RADIO|SWRADIO|VIDEO|VBI); - ENT_T_HW_(TUNER|CAM_SENSOR|ATV_DEMOD|DTV_DEMOD|...) for the hardware components. In other words, the namespace would actually define two subtypes: - devnodes; - hardware components There's one advantage on this strategy: it is easier to keep backward compatibility, IMHO, as we'll be preserving 1 16 for device nodes and 2 16 for hardware components. Yet, we'll need to add an entity for the V4L2 hardware DMA (with makes sense to me), and this might break backward compatibility if not done well. It should be said that, in such case, hardware components will then mean not only V4L2-specific hardware (V4L2_SUBDEV_foo), but also DVB, ALSA, ... components. So, we'll still need a way to identify what of those components are V4L2 subdevs, probably using the properties API. If you all agree with that, I'll respin the patch series to map the entities like that. Regards, Mauro Hmm, we need a another brainstorm meeting... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/18] media controller: rename the tuner entity
Em Fri, 08 May 2015 16:32:03 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 04:08 PM, Mauro Carvalho Chehab wrote: Em Fri, 08 May 2015 15:21:39 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote: Em Fri, 08 May 2015 14:13:22 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: Finally, let's rename the tuner entity. inside the media subsystem, a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV. It could even be used on other subsystems, like network, for wireless devices. So, it is not constricted to V4L2 API, or to a subdev. Let's then rename it as: MEDIA_ENT_T_V4L2_SUBDEV_TUNER - MEDIA_ENT_T_TUNER See patch 04/18. Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume that a tuner will always be mapped via V4L2 subdev API. True. Today we have subdevs that have no device node to control them, so in that case it would just be a SUBDEV entity. There are subdevs that make a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities. The question is: what are your ideas for e.g. DVB-only tuners? Would they get a DVB-like device node? (so DTV_SUBDEV) I guess we may need DVB subdevs in the future. For now, I don't see much usage. Would hybrid tuners have two device nodes? One v4l-subdev, one dvb/dtv-subdev? No. A tuner is a tuner. The very same device can be used for analog or digital TV. Ok, there are tuners that only work for digital TV (satellite tuners, typically), because satellite requires a different tuning range, and require an extra hardware to power up the satellite antena. So, on most devices, the tuner is integrated with SEC. In any case, I don't see any reason why artificially one piece of hardware component (tuner) into one subdevice entity per API. What it might make sense in the future is to have some DVB-specific ioctls for a hybrid tuner, in order to allow adjusting its internal filters to an specific digital TV standard. Just curious what your thoughts are. Brainstorming: It might be better to map each device node to an entity and each hardware component (tuner, DMA engine) to an entity, and avoid this mixing of hw entity vs device node entity. Ok, but then we need to properly define the namespaces for HW and for Linux API components. So, we would have a namespace like: - ENT_T_DEVNODE_DVB_(FE|CA|NET|DEMUX|DVR) for the DVB API device nodes; - ENT_T_DEVNODE_V4L for the radio/swradio/video/vbi devnodes, or, alternatively, use ENT_T_DEVNODE_V4L_(RADIO|SWRADIO|VIDEO|VBI); - ENT_T_HW_(TUNER|CAM_SENSOR|ATV_DEMOD|DTV_DEMOD|...) for the hardware components. In other words, the namespace would actually define two subtypes: - devnodes; - hardware components There's one advantage on this strategy: it is easier to keep backward compatibility, IMHO, as we'll be preserving 1 16 for device nodes Right, that will work. and 2 16 for hardware components. This remains problematic since I believe this should be done as a list of properties. Instead the entity type would be ENT_T_HW (if it represents actual hardware), ENT_T_SW (if it is a software implementation, for example for the DVB demux if there is no HW demux), and perhaps ENT_T_IP for representing IP blocks (not sure about this one). I don't think we should distinguish IP block from HW. I would also use a different namespace for SW implementation like the DVB demux or for API devnodes. Perhaps: ENT_T_API - for non-subdev API device nodes; ENT_T_HW - for hardware/firmware/IP blocks; ENT_T_SW - for software emulation blocks like DVB demux I would not map subdev API as a separate entity, as those should have a 1:1 map to the entity. So, a property (or a flag) should be enough to indicate that either a ENT_T_HW_ or a ENT_T_SW_ is exposed via a subdev. With regards to the API mapping, I would have a set of properties that would be grouping V4L2, subdev, DVB, ... parts of the API. So, for example, if the entity that represents a video devnode controls the tuner, the analog demod and the DMA engine, such entity would have 3 properties: - ENT_PROP_V4L2_TUNER - ENT_PROP_V4L2_ATV_DEMOD - ENT_PROP_V4L2_DMA And the properties will tell what functions it supports. Yes, but, as the API right now groups the subtypes, it would be better to keep it splitted, not for userspace to use this as subtype. Just as a matter of keeping things well organized. I mean, if you take a look at the resulting namespace after all those patches I wrote, the end result is: #define MEDIA_ENT_T_UNKNOWN 0 #define MEDIA_ENT_T_AV_DMA (((1 16)) + 1) #define MEDIA_ENT_T_DTV_DEMOD (MEDIA_ENT_T_AV_DMA + 3) #define MEDIA_ENT_T_DTV_DEMUX (MEDIA_ENT_T_AV_DMA + 4) #define
[PATCH 0/2] Update ALSA driver to use media controller API
This patch series updates ALSA driver to use media controller API to share tuner with DVB and V4L2 drivers that control AU0828 media device. Two new interfaces are added to media controller API to enable creating media device as a device resource. This allows creating media device as a device resource on the main struct device that is common to all drivers that control a single media hardware and share resources on it. Drivers then can find the common media device to register entities and manage links, and pipelines. Tested with and without CONFIG_MEDIA_CONTROLLER enabled. Tested tuner entity doesn't exist case as au0828 v4l2 driver is the one that will create the tuner when it gets updated to use media controller API. Please note that au0828 updates media controller are necessary before the resource sharing can work across ALSA and au0828 dvb and v4l2 drivers. This work is in progress and another developer is working on it. Shuah Khan (2): media: new media controller API for device resource support sound/usb: Update ALSA driver to use media controller API drivers/media/media-device.c | 33 + include/media/media-device.h | 2 ++ sound/usb/card.c | 5 sound/usb/card.h | 12 + sound/usb/pcm.c | 23 +- sound/usb/quirks-table.h | 1 + sound/usb/quirks.c | 58 +++- sound/usb/quirks.h | 6 + sound/usb/stream.c | 40 ++ sound/usb/usbaudio.h | 1 + 10 files changed, 179 insertions(+), 2 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] sound/usb: Update ALSA driver to use media controller API
Change ALSA driver to use media controller API to share tuner
with DVB and V4L2 drivers that control AU0828 media device.
Media device is created based on a newly added field value
in the struct snd_usb_audio_quirk. Using this approach, the
media controller API usage can be added for a specific device.
In this patch, media controller API is enabled for AU0828 hw.
snd_usb_create_quirk() will check this new field, if set will
create a media device using media_device_get_dr() interface.
media_device_get_dr() will allocate a new media device device
resource or return an existing one if it exists. During probe,
media usb driver could have created the media device. It will
then register the media device if it isn't already registered.
Media device unregister is done from usb_audio_disconnect().
New fields to add support for media entity and links are
added to struct snd_usb_substream. A new media entity for
ALSA and a link from tuner entity to the newly registered
ALSA entity are created from snd_usb_init_substream() and
removed from free_substream(). The state is kept to indicate
if tuner is linked. This is to account for case when tuner
entity doesn't exist. Media pipeline gets started to mark
the tuner busy from snd_usb_substream_capture_trigger in
response to SNDRV_PCM_TRIGGER_START and pipeline is stopped
in response to SNDRV_PCM_TRIGGER_STOP. snd_usb_pcm_close()
stops pipeline to cover the case when SNDRV_PCM_TRIGGER_STOP
isn't issued. Pipeline start and stop are done only when
tuner_linked is set.
Tested with and without CONFIG_MEDIA_CONTROLLER enabled.
Tested tuner entity doesn't exist case as au0828 v4l2
driver is the one that will create the tuner when it gets
updated to use media controller API.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
sound/usb/card.c | 5 +
sound/usb/card.h | 12 ++
sound/usb/pcm.c | 23 ++-
sound/usb/quirks-table.h | 1 +
sound/usb/quirks.c | 58 +++-
sound/usb/quirks.h | 6 +
sound/usb/stream.c | 40 +
sound/usb/usbaudio.h | 1 +
8 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 1fab977..587fc24 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -621,6 +621,11 @@ static void usb_audio_disconnect(struct usb_interface
*intf)
}
}
+ /* Nice to check quirk quirk-media_device
+* need some special handlings. Doesn't look like
+* we have access to quirk here */
+ media_device_delete(intf);
+
chip-num_interfaces--;
if (chip-num_interfaces = 0) {
usb_chip[chip-index] = NULL;
diff --git a/sound/usb/card.h b/sound/usb/card.h
index ef580b4..477bdcd 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -1,6 +1,11 @@
#ifndef __USBAUDIO_CARD_H
#define __USBAUDIO_CARD_H
+#ifdef CONFIG_MEDIA_CONTROLLER
+#include media/media-device.h
+#include media/media-entity.h
+#endif
+
#define MAX_NR_RATES 1024
#define MAX_PACKS 6 /* per URB */
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
@@ -155,6 +160,13 @@ struct snd_usb_substream {
} dsd_dop;
bool trigger_tstamp_pending_update; /* trigger timestamp being updated
from initial estimate */
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device *media_dev;
+ struct media_entity media_entity;
+ struct media_pad media_pads;
+ struct media_pipeline media_pipe;
+ bool tuner_linked;
+#endif
};
struct snd_usb_stream {
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index b4ef410..c2a40a9 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -1225,6 +1225,10 @@ static int snd_usb_pcm_close(struct snd_pcm_substream
*substream, int direction)
subs-pcm_substream = NULL;
snd_usb_autosuspend(subs-stream-chip);
+#ifdef CONFIG_MEDIA_CONTROLLER
+ if (subs-tuner_linked)
+ media_entity_pipeline_stop(subs-media_entity);
+#endif
return 0;
}
@@ -1587,9 +1591,22 @@ static int snd_usb_substream_capture_trigger(struct
snd_pcm_substream *substream
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
+#ifdef CONFIG_MEDIA_CONTROLLER
+ if (subs-tuner_linked) {
+ err = media_entity_pipeline_start(subs-media_entity,
+ subs-media_pipe);
+ if (err)
+ return err;
+ }
+#endif
err = start_endpoints(subs, false);
- if (err 0)
+ if (err 0) {
+#ifdef CONFIG_MEDIA_CONTROLLER
+ if (subs-tuner_linked)
+ media_entity_pipeline_stop(subs-media_entity);
+#endif
return err;
+ }
subs-data_endpoint-retire_data_urb =
[PATCH 1/2] media: new media controller API for device resource support
Add new media controller API to allocate media device as a
device resource. When a media device is created on the main
struct device which is the parent device for the interface
device, it will be available to all drivers associated with
that interface. For example, if a usb media device driver
creates the media device on the main struct device which is
common for all the drivers that control the media device,
including the non-media ALSA driver, media controller API
can be used to share access to the resources on the media
device. This new interface provides the above described
feature. A second interface that finds and returns the media
device is added to allow drivers to find the media device
created by any of the drivers associated with the device.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/media-device.c | 33 +
include/media/media-device.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 7b39440..1c32752 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -462,3 +462,36 @@ void media_device_unregister_entity(struct media_entity
*entity)
entity-parent = NULL;
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
+
+static void media_device_release_dr(struct device *dev, void *res)
+{
+}
+
+/*
+ * media_device_get_dr() - get media device as device resource
+ * creates if one doesn't exist
+*/
+struct media_device *media_device_get_dr(struct device *dev)
+{
+ struct media_device *mdev;
+
+ mdev = devres_find(dev, media_device_release_dr, NULL, NULL);
+ if (mdev)
+ return mdev;
+
+ mdev = devres_alloc(media_device_release_dr,
+ sizeof(struct media_device), GFP_KERNEL);
+ if (!mdev)
+ return NULL;
+ return devres_get(dev, mdev, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_get_dr);
+
+/*
+ * media_device_find_dr() - find media device as device resource
+*/
+struct media_device *media_device_find_dr(struct device *dev)
+{
+ return devres_find(dev, media_device_release_dr, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_find_dr);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 6e6db78..53d0fc3 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -95,6 +95,8 @@ void media_device_unregister(struct media_device *mdev);
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity);
void media_device_unregister_entity(struct media_entity *entity);
+struct media_device *media_device_get_dr(struct device *dev);
+struct media_device *media_device_find_dr(struct device *dev);
/* Iterate over all entities. */
#define media_device_for_each_entity(entity, mdev) \
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How implement Secure Data Path ?
dma-buf user handles are fds, which means anything allocated can be passed around nicely already. The question really is whether we'll have one ioctl on top of a special dev node or a syscall. I thought that in these cases where the dev node is only ever used to allocate the real thing, a syscall is the preferred way to go. So you'd go for fd = dmabuf_alloc(blah..., O_whatever) ? Whichever I guess.. really we want open(/dev/foo/parameters.) but we missed that chance a long time ago. The billion dollar question is how is the resource managed, who owns the object, who is charged for it, how to does containerise. We really ought to have a clear answer to that. I guess the same kind of logic as with GEM (except preferably without the DoS security holes) applies as to why its useful to have handles to the DMA buffers. We have handles (well file descriptors) to dma-bufs already, I'm a bit confused what you mean? I was agreeing with your argument - with GEM as an example that it works for the CPU accessing case. Alan -- 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 04/18] media controller: Rename camera entities
Em Fri, 08 May 2015 14:03:01 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: As explained before, the hole idea of subtypes at entities was hole - whole not nice. All V4L2 subdevs may have a device node associated. Also, the hole idea is to expose hardware IP blocks, so calling them as V4L2 is a very bad practice, as they were not designed for the V4L2 API. It is just the reverse. So, instead of using V4L2_SUBDEV, let's call the camera sub- devices with CAM, instead: MEDIA_ENT_T_V4L2_SUBDEV_SENSOR - MEDIA_ENT_T_CAM_SENSOR MEDIA_ENT_T_V4L2_SUBDEV_FLASH - MEDIA_ENT_T_CAM_FLASH MEDIA_ENT_T_V4L2_SUBDEV_LENS - MEDIA_ENT_T_CAM_LENS I would actually postpone this until Laurent has a properties API ready. These entity types are fatally flawed since an entity can combine functions in one. E.g. an i2c device (generally represented as a single entity) might provide for both sensor and flash. Or combine tuner and video decoder, etc. Mapping one I2C address as one entity is plain wrong. It doesn't matter if a piece of hardware has just one I2C address or multiple ones. There are tuners that have multiple I2C addresses. This is actually common on some RDS tuners: they have one address for control, and another one to transfer data from the tuned station. Still, it is just one tuner. There are also cases where there's no I2C address at all, but still there are multiple entities. Just enumerating a few examples of drivers I touched recently: - au8522 - the same I2C address controls both V4L2 analod demod and DVB demod; - as102 - it is just a single chip, with tuner, demod and bridge on it. no I2C buses internally at all. - cx231xx - It has one internal I2C bus used to control different functions inside the bridge chipset. etc. So, if a single piece of hardware has the functions of two entities (sensor and flash), it should be represented as two separate entities. The I2C bus would matter if we were mapping the control plane of the entities, adding PADs for the control lines. But last time I checked, Laurent was still strongly opposed to that. Basically an entity like this is a sub-device (as in the literal meaning of being a part of a larger device) that has one or more functions and may have device node(s) associated with it. That is best expressed as properties. And you really do have to tell userspace that these entities expose a v4l-subdev device node. Renaming them doesn't make that go away. Well, we should decide if we want the namespace and the entities representing the hardware or representing the Linux API. V4L2_SUBDEV has nothing to do with hardware. It is just an abstraction that we've created on one of our subsystems. Regards, Hans Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 5b8147629159..759604e3529f 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -219,15 +219,15 @@ entryUnknown V4L sub-device/entry /row row - entryconstantMEDIA_ENT_T_V4L2_SUBDEV_SENSOR/constant/entry + entryconstantMEDIA_ENT_T_CAM_SENSOR/constant/entry entryVideo sensor/entry /row row - entryconstantMEDIA_ENT_T_V4L2_SUBDEV_FLASH/constant/entry + entryconstantMEDIA_ENT_T_CAM_FLASH/constant/entry entryFlash controller/entry /row row - entryconstantMEDIA_ENT_T_V4L2_SUBDEV_LENS/constant/entry + entryconstantMEDIA_ENT_T_CAM_LENS/constant/entry entryLens controller/entry /row row diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c index c70ababce954..c12f873a8e26 100644 --- a/drivers/media/i2c/adp1653.c +++ b/drivers/media/i2c/adp1653.c @@ -516,7 +516,7 @@ static int adp1653_probe(struct i2c_client *client, if (ret 0) goto free_and_quit; - flash-subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH; + flash-subdev.entity.type = MEDIA_ENT_T_CAM_FLASH; return 0; diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c index 301084b07887..9a2872be11b0 100644 --- a/drivers/media/i2c/as3645a.c +++ b/drivers/media/i2c/as3645a.c @@ -831,7 +831,7 @@ static int as3645a_probe(struct i2c_client *client, if (ret 0) goto done; - flash-subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH; + flash-subdev.entity.type = MEDIA_ENT_T_CAM_FLASH; mutex_init(flash-power_lock); diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c index d9ece4b2d047..4d28cda77f4d 100644 --- a/drivers/media/i2c/lm3560.c +++
Re: [PATCH 05/18] media controller: rename MEDIA_ENT_T_DEVNODE_DVB entities
Em Fri, 08 May 2015 14:10:48 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
In order to reflect that the entities are actually the hardware
(or firmware, or in-kernel software), and are not associated
with the DVB API, let's remove DEVNODE_ from the entity names
and use DTV (Digital TV) for the entities.
The frontend is an special case: the frontend devnode actually
talks directly with the DTV demodulator. It may or may not also
talk with the SEC (Satellite Equipment Control) and with the
tuner. For the sake of unifying the nomenclature, let's call it
as MEDIA_ENT_T_DTV_DEMOD, because this component is always
there.
So:
MEDIA_ENT_T_DEVNODE_DVB_FE- MEDIA_ENT_T_DTV_DEMOD
MEDIA_ENT_T_DEVNODE_DVB_DEMUX - MEDIA_ENT_T_DTV_DEMUX
MEDIA_ENT_T_DEVNODE_DVB_DVR - MEDIA_ENT_T_DTV_DVR
MEDIA_ENT_T_DEVNODE_DVB_CA- MEDIA_ENT_T_DTV_CA
MEDIA_ENT_T_DEVNODE_DVB_NET - MEDIA_ENT_T_DTV_NET
I'm happy with the new names.
PS.: we could actually not keep this define:
#define MEDIA_ENT_T_DEVNODE_DVB_FE MEDIA_ENT_T_DTV_DEMOD
As MEDIA_ENT_T_DEVNODE_DVB_FE symbol will not arrive any Kernel
version (being present only at the 4.1-rc kernels), but keeping
it helps to show that the DVB frontend node is actually associated
with the DTV demodulator. So, keeping it for now helps to better
document. Also, it avoids to break experimental versions of v4l-utils.
So, better to remove this only when we remove the remaining legacy
stuff.
I disagree with that. Let's not introduce defines that are not going to
be used. And v4l-utils is easily fixed.
Instead of keeping an unused define, why not...
We agree to disagree here ;)
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 759604e3529f..27082b07f4c2 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -195,23 +195,23 @@
entryALSA card/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_FE/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_DEMOD/constant/entry
entryDVB frontend devnode/entry
... explain what is going on here? I.e. that this frontend always controls a
demod
and optionally also a tuner and/or SEC.
I'm actually doing just the renames on those initial patches. There are
some adjustments to be done at the documentation, not just that.
So, I opted to do such adjustment on the last patch of this series.
Regards,
Hans
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_DEMUX/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_DEMUX/constant/entry
entryDVB demux devnode/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_DVR/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_DVR/constant/entry
entryDVB DVR devnode/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_CA/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_CA/constant/entry
entryDVB CAM devnode/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_NET/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_NET/constant/entry
entryDVB network devnode/entry
/row
row
diff --git a/drivers/media/dvb-core/dvbdev.c
b/drivers/media/dvb-core/dvbdev.c
index 13bb57f0457f..39846077045e 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -221,26 +221,26 @@ static void dvb_register_media_device(struct
dvb_device *dvbdev,
switch (type) {
case DVB_DEVICE_FRONTEND:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_FE;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_DEMOD;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev-pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_DEMUX:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_DEMUX;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_DEMUX;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev-pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_DVR:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_DVR;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_DVR;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
break;
case DVB_DEVICE_CA:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_CA;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_CA;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev-pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_NET:
-
Re: [PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines
Hi Mauro, On 05/08/2015 02:32 PM, Mauro Carvalho Chehab wrote: and may also not be true on embedded devices that, due to DRM reasons, don't allow writing unencrypted data on a memory that could be seen by the CPU. This actually might still work by using opaque DMABUF handles. But that's under discussion right now in the Secure Data Path thread. Well, a DMABUF opaque handler like that actually refers to either a buffer that is shared only between 2 devices or to a device-to-device DMA transfer. Such dataflow is different than the usual meaning of the video devnode, where the devnode is used to do I/O transfers. So, it may actually be mapped as a different type of entity. We'll need to discuss further when we start mapping this via MC. Yes, this is quite theoretical at the moment. So, we'll eventually need to add another entity for such bridge chipsets that have a video/vbi/radio device node associated, but don't have DMA engines on (some) devnodes. As, currently, we don't have any such case, ??? Radio devices are exactly that. I actually meant to say: As, currently, no driver uses Media Controller on such cases, Ah, OK. That makes more sense :-) let's for now just rename the device nodes that are associated with a DMA engine as MEDIA_ENT_T_AV_DMA. So, MEDIA_ENT_T_DEVNODE_V4L - MEDIA_ENT_T_AV_DMA PS.: This is not actually true for USB devices, as the DMA engine is an internal component, as it is up to the Kernel to strip the stream payload from the URB packages. How about MEDIA_ENT_T_DATA_STREAMING? Or perhaps DATA_IO? Perhaps even just IO? Almost entities do I/O and data streaming (exceptions are flash controller, SEC and similar control subdevices). So, DATA_STREAMING, DATA_IO or IO are a way too generic. For some of our products we have lots of video nodes that just control the receiver or transmitter (and possibly other related blocks), but leave the streaming to vendor code where we are forced to use that. So this can be a lot more common than you might think, although you won't see that appearing in the kernel. DMA is a little bit more restrictive than we wanted. Actually, I originally named those as MEDIA_ENT_T_AV_BRIDGE, because the hardware component that implements the device-CPU I/O is typically a bridge. But then I went into the drivers, and I noticed that several devices with just one bridge have several different entities for I/O. So, I ran this script: $ git filter-branch -f --msg-filter 'cat sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g' origin/patchwork.. $ git filter-branch -f --tree-filter 'for i in $(git grep -l MEDIA_ENT_T_AV_BRIDGE); do sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g $i a mv a $i; done' origin/patchwork.. To replace the name everywere. Provided that we decide a better name, this can be easily fixable by doing the above scripting. Perhaps MEDIA_ENT_T_DEV_CPU_AV_IO would be a better name? That would cover USB as well, and I dislike the use of AV, since the data might contain other things besides audio and/or video. True, but how to distinguish such device from an ALSA DEV/CPU IO? Answering myself, I see one alternative for that... we could use MEDIA_ENT_T_DEV_CPU_IO for all device-CPU I/O devices, and use properties to tell what APIs are valid on such entity. The bad thing is that someone could add multiple incompatible APIs at the same device (like ALSA, V4L and DVB - all on the dame sevnode). I'm running out of ideas here ;) In the lack of a better name, I would keep MEDIA_ENT_T_AV_DMA, as it is the closest one to what's provided by such entities (or the less wrong one). See my reply to patch 10/18: I see whether streaming is supported or not as a function (or feature) of the entity, just like a subdev entity can be both a tuner and a video decoder. I.e. these are properties. I think the naming issue here shows the problem with your approach. Whereas having a 'streaming' property simplifies this IMHO. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/18] media controller: rename the tuner entity
Em Fri, 08 May 2015 14:13:22 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
Finally, let's rename the tuner entity. inside the media subsystem,
a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
It could even be used on other subsystems, like network, for wireless
devices.
So, it is not constricted to V4L2 API, or to a subdev.
Let's then rename it as:
MEDIA_ENT_T_V4L2_SUBDEV_TUNER - MEDIA_ENT_T_TUNER
See patch 04/18.
Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume
that a tuner will always be mapped via V4L2 subdev API.
Hans
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 9b3861058f0d..5c7f366bb1f4 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -241,7 +241,7 @@
signals./entry
/row
row
- entryconstantMEDIA_ENT_T_V4L2_SUBDEV_TUNER/constant/entry
+ entryconstantMEDIA_ENT_T_TUNER/constant/entry
entryTV and/or radio tuner/entry
/row
/tbody
diff --git a/drivers/media/dvb-core/dvbdev.c
b/drivers/media/dvb-core/dvbdev.c
index 39846077045e..d6a096495035 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -393,7 +393,7 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
media_device_for_each_entity(entity, mdev) {
switch (entity-type) {
- case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+ case MEDIA_ENT_T_TUNER:
tuner = entity;
break;
case MEDIA_ENT_T_DTV_DEMOD:
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index a756f74f0adc..2a7331e3c4a0 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1213,7 +1213,7 @@ static void cx231xx_create_media_graph(struct cx231xx
*dev)
media_device_for_each_entity(entity, mdev) {
switch (entity-type) {
- case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+ case MEDIA_ENT_T_TUNER:
tuner = entity;
break;
case MEDIA_ENT_T_ATV_DECODER:
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index abdcffabcb59..ecf4e8a543b3 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -696,7 +696,7 @@ static int tuner_probe(struct i2c_client *client,
register_client:
#if defined(CONFIG_MEDIA_CONTROLLER)
t-pad.flags = MEDIA_PAD_FL_SOURCE;
- t-sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t-sd.entity.type = MEDIA_ENT_T_TUNER;
t-sd.entity.name = t-name;
ret = media_entity_init(t-sd.entity, 1, t-pad, 0);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 9b3d80e765f0..6acc4be1378c 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -57,7 +57,7 @@ struct media_device_info {
#define MEDIA_ENT_T_ATV_DECODER(MEDIA_ENT_T_CAM_SENSOR + 3)
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
+#define MEDIA_ENT_T_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
#if 1
/*
@@ -88,6 +88,8 @@ struct media_device_info {
#define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_T_CAM_LENS
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER MEDIA_ENT_T_TUNER
#endif
/* Used bitmasks for media_entity_desc::flags */
--
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 04/18] media controller: Rename camera entities
On 05/08/2015 02:53 PM, Mauro Carvalho Chehab wrote: Em Fri, 08 May 2015 14:03:01 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: As explained before, the hole idea of subtypes at entities was hole - whole not nice. All V4L2 subdevs may have a device node associated. Also, the hole idea is to expose hardware IP blocks, so calling them as V4L2 is a very bad practice, as they were not designed for the V4L2 API. It is just the reverse. So, instead of using V4L2_SUBDEV, let's call the camera sub- devices with CAM, instead: MEDIA_ENT_T_V4L2_SUBDEV_SENSOR - MEDIA_ENT_T_CAM_SENSOR MEDIA_ENT_T_V4L2_SUBDEV_FLASH - MEDIA_ENT_T_CAM_FLASH MEDIA_ENT_T_V4L2_SUBDEV_LENS - MEDIA_ENT_T_CAM_LENS I would actually postpone this until Laurent has a properties API ready. These entity types are fatally flawed since an entity can combine functions in one. E.g. an i2c device (generally represented as a single entity) might provide for both sensor and flash. Or combine tuner and video decoder, etc. Mapping one I2C address as one entity is plain wrong. I said 'i2c device', not i2c address. That would definitely be wrong. I'm also not saying that each i2c device (chip) maps always to one entity, although this is generally true. In the end it depends on the driver author to decide how to split up the functionality of the device into entities. There is no hard and fast rule for that. So, if a single piece of hardware has the functions of two entities (sensor and flash), it should be represented as two separate entities. Perhaps, perhaps not. There is in the general case no clear rule at what level you design your entities. In a complex pipeline it would be madness to map every little HW block to an entity since you would get a zillion entities, which is highly impractical. The cx25840 combines multiple functions (tuner, audio/video decoders), and I am not at all sure you would gain anything from splitting that up into smaller entities. In the end, if you would write a block diagram of your board the cx25840 would be a single block. And experience has shown that that is typically the right level for deciding what will be an entity or not. Also, in such devices the various functions are often intertwined and generally not easy to separate. The I2C bus would matter if we were mapping the control plane of the entities, adding PADs for the control lines. But last time I checked, Laurent was still strongly opposed to that. Basically an entity like this is a sub-device (as in the literal meaning of being a part of a larger device) that has one or more functions and may have device node(s) associated with it. That is best expressed as properties. And you really do have to tell userspace that these entities expose a v4l-subdev device node. Renaming them doesn't make that go away. Well, we should decide if we want the namespace and the entities representing the hardware or representing the Linux API. V4L2_SUBDEV has nothing to do with hardware. It is just an abstraction that we've created on one of our subsystems. I agree. MEDIA_ENT_T_V4L2_SUBDEV_SENSOR basically contains two bits of information: the linux API used to access the entity and the function. Since you don't combine multiple APIs (e.g. ALSA and V4L2) for a single device node (I would certainly never allow such code in the kernel!) there is only one of those, but one entity can certainly combine multiple functions as I argued for above. Hence, those should be properties. Anyway, let's wait what Laurent thinks and setup an irc session for this. 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: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat May 9 04:00:19 CEST 2015 git branch: test git hash: c3f22501b52de17c6087b6fe6f2236e4183ac07c gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-0.slh.3-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: ERRORS linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines
Em Fri, 08 May 2015 13:54:07 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: At the Video4Linux API, the /dev/video?, /dev/vbi? and /dev/radio? device nodes are used for the chipset that I knew that this patch would cause some discussions ;) You should add /dev/swradio? for SDR devices. I will. provides the bridge between video/radio streams and the USB, PCI or CPU buses. Such bridge is also typically used to control the V4L2 device as a hole. hole - whole Ok. For video streaming devices and SDR radio devices, they're also associated with the DMA engines that transfer the video stream (or SDR stream) to the CPU's memory. It should be noticed, however, this is not true on non-SDR radio devices, I think you forgot that SDR devices are not using /dev/radio but /dev/swradio. Yeah, true. I forgot that, in the end of the day, we used a different naming for SDR radio devnodes. I'll fix the comments. They have different names. Radio devices never stream (OK, I think there are one or two exceptions, but that's really because nobody bothered to make an alsa driver. Those boards are in practice out of spec.) Yes, I know. and may also not be true on embedded devices that, due to DRM reasons, don't allow writing unencrypted data on a memory that could be seen by the CPU. This actually might still work by using opaque DMABUF handles. But that's under discussion right now in the Secure Data Path thread. Well, a DMABUF opaque handler like that actually refers to either a buffer that is shared only between 2 devices or to a device-to-device DMA transfer. Such dataflow is different than the usual meaning of the video devnode, where the devnode is used to do I/O transfers. So, it may actually be mapped as a different type of entity. We'll need to discuss further when we start mapping this via MC. Another reason can also be that the SoC vendor re-invented the wheel and made there own DMA streaming solution. You can still make V4L drivers that control the video receivers/transmitters, but for the actual streaming you are forced to use the vendor's crap code (hello TI!). I've bitter experiences with that :-( So, we'll eventually need to add another entity for such bridge chipsets that have a video/vbi/radio device node associated, but don't have DMA engines on (some) devnodes. As, currently, we don't have any such case, ??? Radio devices are exactly that. I actually meant to say: As, currently, no driver uses Media Controller on such cases, let's for now just rename the device nodes that are associated with a DMA engine as MEDIA_ENT_T_AV_DMA. So, MEDIA_ENT_T_DEVNODE_V4L - MEDIA_ENT_T_AV_DMA PS.: This is not actually true for USB devices, as the DMA engine is an internal component, as it is up to the Kernel to strip the stream payload from the URB packages. How about MEDIA_ENT_T_DATA_STREAMING? Or perhaps DATA_IO? Perhaps even just IO? Almost entities do I/O and data streaming (exceptions are flash controller, SEC and similar control subdevices). So, DATA_STREAMING, DATA_IO or IO are a way too generic. DMA is a little bit more restrictive than we wanted. Actually, I originally named those as MEDIA_ENT_T_AV_BRIDGE, because the hardware component that implements the device-CPU I/O is typically a bridge. But then I went into the drivers, and I noticed that several devices with just one bridge have several different entities for I/O. So, I ran this script: $ git filter-branch -f --msg-filter 'cat sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g' origin/patchwork.. $ git filter-branch -f --tree-filter 'for i in $(git grep -l MEDIA_ENT_T_AV_BRIDGE); do sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g $i a mv a $i; done' origin/patchwork.. To replace the name everywere. Provided that we decide a better name, this can be easily fixable by doing the above scripting. Perhaps MEDIA_ENT_T_DEV_CPU_AV_IO would be a better name? That would cover USB as well, and I dislike the use of AV, since the data might contain other things besides audio and/or video. True, but how to distinguish such device from an ALSA DEV/CPU IO? Answering myself, I see one alternative for that... we could use MEDIA_ENT_T_DEV_CPU_IO for all device-CPU I/O devices, and use properties to tell what APIs are valid on such entity. The bad thing is that someone could add multiple incompatible APIs at the same device (like ALSA, V4L and DVB - all on the dame sevnode). I'm running out of ideas here ;) In the lack of a better name, I would keep MEDIA_ENT_T_AV_DMA, as it is the closest one to what's provided by such entities (or the less wrong one). Regards, Mauro -- 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 10/18] media controller: use macros to check for V4L2 subdev entities
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
Instead of relying on media subtype, use the new macros to detect
if an entity is a subdev or an A/V DMA entity.
Please note that most drivers assume that there's just AV_DMA or
V4L2 subdevs. This is not true anymore, as we've added MC support
for DVB, and there are plans to add support for ALSA and FB/DRM
too.
Ok, on the current pipelines supported by those drivers, just V4L
stuff are there, but, assuming that some day a pipeline that also
works with other subsystems will ever added, it is better to add
explicit checks for the AV_DMA stuff.
So, a lot of what you try to do really can't be done until we have a
properties API. Oddly enough it is not the DVB part that worries me, that
makes sense to me. But the V4L2 part has problems.
To summarize my concerns here:
The DVB (or DTV) entity types map cleanly to specific device nodes that
applications
will use to access the functionality, but AV_DMA is just much too vague. I.e.
does it mean this is a V4L2 device? Or an ALSA device? Something else?
Why have a DTV_DEMOD, DTV_DEMUX, etc. but not a MEDIA_ENT_T_V4L2? Such an
entity type clearly indicates a V4L2 device node, which is what an application
needs to know. Whether this entity has DMA (or streaming) functionality I see
as a property of the entity.
I would prefer to see ENT_T_V4L2 and ENT_T_V4L_SUBDEV since this indicates the
crucial information of how this entity should be controlled, and use properties
to indicate the functions of the entity (and possibly the information required
to locate the device nodes, as we discussed in San Jose).
This is consistent with the DTV entities (since each DTV entity has its own
device node and API).
Each entity may have lots of functions, depending on the hardware behind it,
so properties are ideal for that.
Finally, what to do with e.g. a radio device? Since there is no data flow but it
only controls other entities, perhaps we should just list as properties which
other
entities are controlled it (i.e. the tuner).
I don't think we can make this right without using properties. We could get away
with it while it was only V4L2 that used this (although it would have been
useful
even there), but this is now getting urgent.
Regards,
Hans
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/platform/exynos4-is/common.c
b/drivers/media/platform/exynos4-is/common.c
index 0eb34ecb8ee4..1f1b9a56e24e 100644
--- a/drivers/media/platform/exynos4-is/common.c
+++ b/drivers/media/platform/exynos4-is/common.c
@@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct
media_entity *entity)
while (pad-flags MEDIA_PAD_FL_SINK) {
/* source pad */
pad = media_entity_remote_pad(pad);
- if (pad == NULL ||
- media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+ if (!is_media_entity_v4l2_subdev(pad-entity))
break;
sd = media_entity_to_v4l2_subdev(pad-entity);
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index cfebf292e15a..545286813414 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev *fimc)
}
}
- if (src_pad == NULL ||
- media_entity_type(src_pad-entity) !=
MEDIA_ENT_T_V4L2_SUBDEV)
+ if (!is_media_entity_v4l2_subdev(src_pad-entity))
break;
/* Don't call FIMC subdev operation to avoid nested locking */
@@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity *entity,
struct fimc_vid_cap *vc = fimc-vid_cap;
struct v4l2_subdev *sensor;
- if (media_entity_type(remote-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+ if (!is_media_entity_v4l2_subdev(remote-entity))
return -EINVAL;
if (WARN_ON(fimc == NULL))
diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c
b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 76b6b4d14616..014d0bad657d 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct fimc_isp
*isp)
/* Retrieve format at the source pad */
pad = media_entity_remote_pad(pad);
- if (pad == NULL ||
- media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+ if (!is_media_entity_v4l2_subdev(pad-entity))
break;
sd = media_entity_to_v4l2_subdev(pad-entity);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index
Re: [PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
At the Video4Linux API, the /dev/video?, /dev/vbi? and
/dev/radio? device nodes are used for the chipset that
You should add /dev/swradio? for SDR devices.
provides the bridge between video/radio streams and the
USB, PCI or CPU buses.
Such bridge is also typically used to control the V4L2 device
as a hole.
hole - whole
For video streaming devices and SDR radio devices, they're
also associated with the DMA engines that transfer the
video stream (or SDR stream) to the CPU's memory.
It should be noticed, however, this is not true on non-SDR
radio devices,
I think you forgot that SDR devices are not using /dev/radio
but /dev/swradio. They have different names. Radio devices never
stream (OK, I think there are one or two exceptions, but that's really
because nobody bothered to make an alsa driver. Those boards are
in practice out of spec.)
and may also not be true on embedded devices
that, due to DRM reasons, don't allow writing unencrypted
data on a memory that could be seen by the CPU.
This actually might still work by using opaque DMABUF handles. But that's
under discussion right now in the Secure Data Path thread.
Another reason can also be that the SoC vendor re-invented the wheel
and made there own DMA streaming solution. You can still make V4L drivers
that control the video receivers/transmitters, but for the actual streaming
you are forced to use the vendor's crap code (hello TI!).
I've bitter experiences with that :-(
So, we'll eventually need to add another entity for such
bridge chipsets that have a video/vbi/radio device node
associated, but don't have DMA engines on (some) devnodes.
As, currently, we don't have any such case,
??? Radio devices are exactly that.
let's for now
just rename the device nodes that are associated with a
DMA engine as MEDIA_ENT_T_AV_DMA.
So,
MEDIA_ENT_T_DEVNODE_V4L - MEDIA_ENT_T_AV_DMA
PS.: This is not actually true for USB devices, as the
DMA engine is an internal component, as it is up to the
Kernel to strip the stream payload from the URB packages.
How about MEDIA_ENT_T_DATA_STREAMING? Or perhaps DATA_IO? Perhaps even just
IO?
That would cover USB as well, and I dislike the use of AV, since the
data might contain other things besides audio and/or video.
Regards,
Hans
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 5872f8bbf774..5b8147629159 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -183,7 +183,7 @@
entryUnknown device node/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_V4L/constant/entry
+ entryconstantMEDIA_ENT_T_AV_DMA/constant/entry
entryV4L video, radio or vbi device node/entry
/row
row
diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
b/drivers/media/platform/xilinx/xilinx-dma.c
index efde88adf624..7fa0cc0f08f0 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -193,7 +193,7 @@ static int xvip_pipeline_validate(struct xvip_pipeline
*pipe,
while ((entity = media_entity_graph_walk_next(graph))) {
struct xvip_dma *dma;
- if (entity-type != MEDIA_ENT_T_DEVNODE_V4L)
+ if (entity-type != MEDIA_ENT_T_AV_DMA)
continue;
dma = to_xvip_dma(media_entity_to_video_device(entity));
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index 71a1b93b0790..9ef920221b5a 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -912,7 +912,7 @@ int __video_register_device(struct video_device *vdev,
int type, int nr,
/* Part 5: Register the entity. */
if (vdev-v4l2_dev-mdev
vdev-vfl_type != VFL_TYPE_SUBDEV) {
- vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
+ vdev-entity.type = MEDIA_ENT_T_AV_DMA;
vdev-entity.name = vdev-name;
vdev-entity.info.dev.major = VIDEO_MAJOR;
vdev-entity.info.dev.minor = vdev-minor;
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 63596063b213..9f8fc8330b3e 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -535,7 +535,7 @@ v4l2_subdev_link_validate_get_format(struct media_pad
*pad,
return v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
}
- WARN(pad-entity-type != MEDIA_ENT_T_DEVNODE_V4L,
+ WARN(pad-entity-type != MEDIA_ENT_T_AV_DMA,
Driver bug! Wrong media entity type 0x%08x, entity %s\n,
pad-entity-type,
Re: [PATCH 04/18] media controller: Rename camera entities
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: As explained before, the hole idea of subtypes at entities was hole - whole not nice. All V4L2 subdevs may have a device node associated. Also, the hole idea is to expose hardware IP blocks, so calling them as V4L2 is a very bad practice, as they were not designed for the V4L2 API. It is just the reverse. So, instead of using V4L2_SUBDEV, let's call the camera sub- devices with CAM, instead: MEDIA_ENT_T_V4L2_SUBDEV_SENSOR - MEDIA_ENT_T_CAM_SENSOR MEDIA_ENT_T_V4L2_SUBDEV_FLASH - MEDIA_ENT_T_CAM_FLASH MEDIA_ENT_T_V4L2_SUBDEV_LENS - MEDIA_ENT_T_CAM_LENS I would actually postpone this until Laurent has a properties API ready. These entity types are fatally flawed since an entity can combine functions in one. E.g. an i2c device (generally represented as a single entity) might provide for both sensor and flash. Or combine tuner and video decoder, etc. Basically an entity like this is a sub-device (as in the literal meaning of being a part of a larger device) that has one or more functions and may have device node(s) associated with it. That is best expressed as properties. And you really do have to tell userspace that these entities expose a v4l-subdev device node. Renaming them doesn't make that go away. Regards, Hans Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 5b8147629159..759604e3529f 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -219,15 +219,15 @@ entryUnknown V4L sub-device/entry /row row - entryconstantMEDIA_ENT_T_V4L2_SUBDEV_SENSOR/constant/entry + entryconstantMEDIA_ENT_T_CAM_SENSOR/constant/entry entryVideo sensor/entry /row row - entryconstantMEDIA_ENT_T_V4L2_SUBDEV_FLASH/constant/entry + entryconstantMEDIA_ENT_T_CAM_FLASH/constant/entry entryFlash controller/entry /row row - entryconstantMEDIA_ENT_T_V4L2_SUBDEV_LENS/constant/entry + entryconstantMEDIA_ENT_T_CAM_LENS/constant/entry entryLens controller/entry /row row diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c index c70ababce954..c12f873a8e26 100644 --- a/drivers/media/i2c/adp1653.c +++ b/drivers/media/i2c/adp1653.c @@ -516,7 +516,7 @@ static int adp1653_probe(struct i2c_client *client, if (ret 0) goto free_and_quit; - flash-subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH; + flash-subdev.entity.type = MEDIA_ENT_T_CAM_FLASH; return 0; diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c index 301084b07887..9a2872be11b0 100644 --- a/drivers/media/i2c/as3645a.c +++ b/drivers/media/i2c/as3645a.c @@ -831,7 +831,7 @@ static int as3645a_probe(struct i2c_client *client, if (ret 0) goto done; - flash-subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH; + flash-subdev.entity.type = MEDIA_ENT_T_CAM_FLASH; mutex_init(flash-power_lock); diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c index d9ece4b2d047..4d28cda77f4d 100644 --- a/drivers/media/i2c/lm3560.c +++ b/drivers/media/i2c/lm3560.c @@ -368,7 +368,7 @@ static int lm3560_subdev_init(struct lm3560_flash *flash, rval = media_entity_init(flash-subdev_led[led_no].entity, 0, NULL, 0); if (rval 0) goto err_out; - flash-subdev_led[led_no].entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH; + flash-subdev_led[led_no].entity.type = MEDIA_ENT_T_CAM_FLASH; return rval; diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c index 626fb4679c02..19ee2ac00be7 100644 --- a/drivers/media/i2c/lm3646.c +++ b/drivers/media/i2c/lm3646.c @@ -285,7 +285,7 @@ static int lm3646_subdev_init(struct lm3646_flash *flash) rval = media_entity_init(flash-subdev_led.entity, 0, NULL, 0); if (rval 0) goto err_out; - flash-subdev_led.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH; + flash-subdev_led.entity.type = MEDIA_ENT_T_CAM_FLASH; return rval; err_out: diff --git a/drivers/media/i2c/m5mols/m5mols_core.c b/drivers/media/i2c/m5mols/m5mols_core.c index 6404c0d93e7a..beb519cf8be4 100644 --- a/drivers/media/i2c/m5mols/m5mols_core.c +++ b/drivers/media/i2c/m5mols/m5mols_core.c @@ -978,7 +978,7 @@ static int m5mols_probe(struct i2c_client *client, ret = media_entity_init(sd-entity, 1, info-pad, 0); if (ret 0) return ret; - sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR; + sd-entity.type = MEDIA_ENT_T_CAM_SENSOR; init_waitqueue_head(info-irq_waitq);
Re: [PATCH] media: replace bellow - below
Hi Mauro,
On Friday 08 May 2015 09:01:28 Mauro Carvalho Chehab wrote:
Bellow is yelling. Ok, sometimes the code is yells a lot, but
but this is not the case there ;)
:-)
checkpatch.pl has support for finding common spelling mistakes nowadays.
Instead of fixing them one by one, should we run it on the whole media
subsystem and fix all detected errors in one go ?
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/common/siano/smsir.c
b/drivers/media/common/siano/smsir.c index 1d60d200d9ab..41f2a3939979
100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -78,7 +78,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
dev-dev.parent = coredev-device;
#if 0
- /* TODO: properly initialize the parameters bellow */
+ /* TODO: properly initialize the parameters below */
dev-input_id.bustype = BUS_USB;
dev-input_id.version = 1;
dev-input_id.vendor = le16_to_cpu(dev-udev-descriptor.idVendor);
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c
b/drivers/media/dvb-frontends/drx39xyj/drxj.c index
61f76038442a..52245354bf04 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -9541,7 +9541,7 @@ ctrl_get_qam_sig_quality(struct drx_demod_instance
*demod) /* - */
/* Pre Viterbi Symbol Error Rate Calculation */
/* - */
- /* pre viterbi SER is good if it is bellow 0.025 */
+ /* pre viterbi SER is good if it is below 0.025 */
/* get the register value */
/* no of quadrature symbol errors */
diff --git a/drivers/media/dvb-frontends/drxk_hard.c
b/drivers/media/dvb-frontends/drxk_hard.c index d46cf5f7cd2e..ad35264a3819
100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -544,7 +544,7 @@ error:
static int init_state(struct drxk_state *state)
{
/*
- * FIXME: most (all?) of the values bellow should be moved into
+ * FIXME: most (all?) of the values below should be moved into
* struct drxk_config, as they are probably board-specific
*/
u32 ul_vsb_if_agc_mode = DRXK_AGC_CTRL_AUTO;
diff --git a/drivers/media/dvb-frontends/tda10021.c
b/drivers/media/dvb-frontends/tda10021.c index 1bff7f457e19..28d987068048
100644
--- a/drivers/media/dvb-frontends/tda10021.c
+++ b/drivers/media/dvb-frontends/tda10021.c
@@ -258,7 +258,7 @@ static int tda10021_set_parameters(struct dvb_frontend
*fe) }
/*
- * gcc optimizes the code bellow the same way as it would code:
+ * gcc optimizes the code below the same way as it would code:
* if (qam 5) return -EINVAL;
* Yet, the code is clearer, as it shows what QAM standards are
* supported by the driver, and avoids the usage of magic numbers on
diff --git a/drivers/media/dvb-frontends/tda10023.c
b/drivers/media/dvb-frontends/tda10023.c index ca1e0d54b69a..f92f4a71
100644
--- a/drivers/media/dvb-frontends/tda10023.c
+++ b/drivers/media/dvb-frontends/tda10023.c
@@ -331,7 +331,7 @@ static int tda10023_set_parameters(struct dvb_frontend
*fe) }
/*
- * gcc optimizes the code bellow the same way as it would code:
+ * gcc optimizes the code below the same way as it would code:
* if (qam 5) return -EINVAL;
* Yet, the code is clearer, as it shows what QAM standards are
* supported by the driver, and avoids the usage of magic numbers on
diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
index 070c152da95a..0c50e5285cf6 100644
--- a/drivers/media/i2c/tvaudio.c
+++ b/drivers/media/i2c/tvaudio.c
@@ -272,7 +272,7 @@ static int chip_cmd(struct CHIPSTATE *chip, char *name,
audiocmd *cmd) return -EINVAL;
}
- /* FIXME: it seems that the shadow bytes are wrong bellow !*/
+ /* FIXME: it seems that the shadow bytes are wrong below !*/
/* update our shadow register set; print bytes if (debug 0) */
v4l2_dbg(1, debug, sd, chip_cmd(%s): reg=%d, data:,
diff --git a/drivers/media/tuners/tuner-xc2028.c
b/drivers/media/tuners/tuner-xc2028.c index d12f5e4ad8bf..4e941f00b600
100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1094,7 +1094,7 @@ static int generic_set_freq(struct dvb_frontend *fe,
u32 freq /* in HZ */, * Still need tests for XC3028L (firmware 3.2 or
upper)
* So, for now, let's just comment the per-firmware
* version of this change. Reports with xc3028l working
- * with and without the lines bellow are welcome
+ * with and without the lines below are welcome
*/
if (priv-firm_version 0x0302) {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line
Re: [PATCH 06/18] media controller: rename analog TV decoder
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
To keep coherency, let's also remove V4L2_SUBDEV from the analog
TV decoder, calling it by its function, and not by the V4L2
API mapping.
Same issue as with patch 04/18.
Hans
So,
MEDIA_ENT_T_V4L2_SUBDEV_DECODER - MEDIA_ENT_T_ATV_DECODER
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 27082b07f4c2..9b3861058f0d 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -231,7 +231,7 @@
entryLens controller/entry
/row
row
- entryconstantMEDIA_ENT_T_V4L2_SUBDEV_DECODER/constant/entry
+ entryconstantMEDIA_ENT_T_ATV_DECODER/constant/entry
entryVideo decoder, the basic function of the video decoder is to
accept analogue video from a wide variety of sources such as
broadcast, DVD players, cameras and video cassette recorders, in
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index a493c0b0b5fe..e8f0b53cc253 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -1212,7 +1212,7 @@ static int adv7180_probe(struct i2c_client *client,
goto err_unregister_vpp_client;
state-pad.flags = MEDIA_PAD_FL_SOURCE;
- sd-entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ sd-entity.flags |= MEDIA_ENT_T_ATV_DECODER;
ret = media_entity_init(sd-entity, 1, state-pad, 0);
if (ret)
goto err_free_ctrl;
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
b/drivers/media/i2c/cx25840/cx25840-core.c
index e15a789ad596..cd8a3c273ab8 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5208,7 +5208,7 @@ static int cx25840_probe(struct i2c_client *client,
state-pads[CX25840_PAD_INPUT].flags = MEDIA_PAD_FL_SINK;
state-pads[CX25840_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
state-pads[CX25840_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
- sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ sd-entity.type = MEDIA_ENT_T_ATV_DECODER;
ret = media_entity_init(sd-entity, ARRAY_SIZE(state-pads),
state-pads, 0);
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 24e47279e30c..77744c390941 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -1106,7 +1106,7 @@ tvp514x_probe(struct i2c_client *client, const struct
i2c_device_id *id)
#if defined(CONFIG_MEDIA_CONTROLLER)
decoder-pad.flags = MEDIA_PAD_FL_SOURCE;
decoder-sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- decoder-sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ decoder-sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
ret = media_entity_init(decoder-sd.entity, 1, decoder-pad, 0);
if (ret 0) {
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 05077cffd235..3facef49aef1 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -1019,7 +1019,7 @@ static int tvp7002_probe(struct i2c_client *c, const
struct i2c_device_id *id)
#if defined(CONFIG_MEDIA_CONTROLLER)
device-pad.flags = MEDIA_PAD_FL_SOURCE;
device-sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- device-sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ device-sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
error = media_entity_init(device-sd.entity, 1, device-pad, 0);
if (error 0)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index fe00da105e77..a756f74f0adc 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1216,7 +1216,7 @@ static void cx231xx_create_media_graph(struct cx231xx
*dev)
case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
tuner = entity;
break;
- case MEDIA_ENT_T_V4L2_SUBDEV_DECODER:
+ case MEDIA_ENT_T_ATV_DECODER:
decoder = entity;
break;
}
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c
b/drivers/media/usb/cx231xx/cx231xx-video.c
index af44f2d1c0a1..bed4ee28916d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -119,7 +119,7 @@ static int cx231xx_enable_analog_tuner(struct cx231xx
*dev)
* this should be enough for the actual needs.
*/
media_device_for_each_entity(entity, mdev) {
- if (entity-type == MEDIA_ENT_T_V4L2_SUBDEV_DECODER) {
+ if (entity-type == MEDIA_ENT_T_ATV_DECODER) {
decoder = entity;
Re: [PATCH 2/2] sound/usb: Update ALSA driver to use media controller API
Shuah Khan shua...@osg.samsung.com wrote:
@@ -541,13 +591,19 @@ int snd_usb_create_quirk(struct snd_usb_audio *chip,
[QUIRK_AUDIO_ALIGN_TRANSFER] = create_align_transfer_quirk,
[QUIRK_AUDIO_STANDARD_MIXER] = create_standard_mixer_quirk,
};
+ int ret;
+ if (quirk-media_device) {
+ /* don't want to fail when media_device_init() doesn't work */
+ ret = media_device_init(iface);
+ }
if (quirk-type QUIRK_TYPE_COUNT) {
- return quirk_funcs[quirk-type](chip, iface, driver, quirk);
+ ret = quirk_funcs[quirk-type](chip, iface, driver, quirk);
} else {
usb_audio_err(chip, invalid quirk type %d\n, quirk-type);
return -ENXIO;
}
+ return ret;
}
What is the point of saving 'ret' of media_device_init if it'll
only be clobbered or ignored for ENXIO?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] media controller: deprecate entity subtype
Hi Mauro,
Just a typo, after that you can add my:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Thanks,
Hans
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
The media controller entity subtype doesn't make much sense,
especially since V4L2 subdevices may also have associated devnodes.
So, better to get rid of it while it is not too late.
We need, of course, to keep the old symbols to avoid userspace
breakage, but we should avoid using them internally at the
Kernel.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4e816be3de39..775c11c6b173 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -42,31 +42,45 @@ struct media_device_info {
#define MEDIA_ENT_ID_FLAG_NEXT (1 31)
+/* Used values for media_entity_desc::type */
+
+#define MEDIA_ENT_T_DEVNODE_V4L (((1 16)) + 1)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE_V4L + 3)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX(MEDIA_ENT_T_DEVNODE_V4L + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE_V4L + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE_V4L + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE_V4L + 7)
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR ((2 16) + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR
+ 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV_LENS (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
+/* A converter of analogue video to its digital representation. */
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR
+ 3)
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR
+ 4)
+
+#if 1
+/*
+ * Legacy symbols.
+ * Kept just to avoid userspace compilation breakages.
+ * One day, the symbols bellow will be removed
bellow - below
+ */
+
#define MEDIA_ENT_TYPE_SHIFT 16
#define MEDIA_ENT_TYPE_MASK 0x00ff
#define MEDIA_ENT_SUBTYPE_MASK 0x
#define MEDIA_ENT_T_DEVNODE (1 MEDIA_ENT_TYPE_SHIFT)
-#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV (2 MEDIA_ENT_TYPE_SHIFT)
+
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
-#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX(MEDIA_ENT_T_DEVNODE + 5)
-#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE + 6)
-#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
-#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE + 8)
-/* Legacy symbol. Use it to avoid userspace compilation breakages */
+
#define MEDIA_ENT_T_DEVNODE_DVB MEDIA_ENT_T_DEVNODE_DVB_FE
+#endif
-#define MEDIA_ENT_T_V4L2_SUBDEV (2 MEDIA_ENT_TYPE_SHIFT)
-#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR (MEDIA_ENT_T_V4L2_SUBDEV + 1)
-#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH(MEDIA_ENT_T_V4L2_SUBDEV + 2)
-#define MEDIA_ENT_T_V4L2_SUBDEV_LENS (MEDIA_ENT_T_V4L2_SUBDEV + 3)
-/* A converter of analogue video to its digital representation. */
-#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4)
-
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER(MEDIA_ENT_T_V4L2_SUBDEV + 5)
+/* Used bitmasks for media_entity_desc::flags */
#define MEDIA_ENT_FL_DEFAULT (1 0)
--
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: replace bellow - below
Bellow is yelling. Ok, sometimes the code is yells a lot, but
but this is not the case there ;)
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/common/siano/smsir.c
b/drivers/media/common/siano/smsir.c
index 1d60d200d9ab..41f2a3939979 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -78,7 +78,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
dev-dev.parent = coredev-device;
#if 0
- /* TODO: properly initialize the parameters bellow */
+ /* TODO: properly initialize the parameters below */
dev-input_id.bustype = BUS_USB;
dev-input_id.version = 1;
dev-input_id.vendor = le16_to_cpu(dev-udev-descriptor.idVendor);
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c
b/drivers/media/dvb-frontends/drx39xyj/drxj.c
index 61f76038442a..52245354bf04 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -9541,7 +9541,7 @@ ctrl_get_qam_sig_quality(struct drx_demod_instance *demod)
/* - */
/* Pre Viterbi Symbol Error Rate Calculation */
/* - */
- /* pre viterbi SER is good if it is bellow 0.025 */
+ /* pre viterbi SER is good if it is below 0.025 */
/* get the register value */
/* no of quadrature symbol errors */
diff --git a/drivers/media/dvb-frontends/drxk_hard.c
b/drivers/media/dvb-frontends/drxk_hard.c
index d46cf5f7cd2e..ad35264a3819 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -544,7 +544,7 @@ error:
static int init_state(struct drxk_state *state)
{
/*
-* FIXME: most (all?) of the values bellow should be moved into
+* FIXME: most (all?) of the values below should be moved into
* struct drxk_config, as they are probably board-specific
*/
u32 ul_vsb_if_agc_mode = DRXK_AGC_CTRL_AUTO;
diff --git a/drivers/media/dvb-frontends/tda10021.c
b/drivers/media/dvb-frontends/tda10021.c
index 1bff7f457e19..28d987068048 100644
--- a/drivers/media/dvb-frontends/tda10021.c
+++ b/drivers/media/dvb-frontends/tda10021.c
@@ -258,7 +258,7 @@ static int tda10021_set_parameters(struct dvb_frontend *fe)
}
/*
-* gcc optimizes the code bellow the same way as it would code:
+* gcc optimizes the code below the same way as it would code:
* if (qam 5) return -EINVAL;
* Yet, the code is clearer, as it shows what QAM standards are
* supported by the driver, and avoids the usage of magic numbers on
diff --git a/drivers/media/dvb-frontends/tda10023.c
b/drivers/media/dvb-frontends/tda10023.c
index ca1e0d54b69a..f92f4a71 100644
--- a/drivers/media/dvb-frontends/tda10023.c
+++ b/drivers/media/dvb-frontends/tda10023.c
@@ -331,7 +331,7 @@ static int tda10023_set_parameters(struct dvb_frontend *fe)
}
/*
-* gcc optimizes the code bellow the same way as it would code:
+* gcc optimizes the code below the same way as it would code:
* if (qam 5) return -EINVAL;
* Yet, the code is clearer, as it shows what QAM standards are
* supported by the driver, and avoids the usage of magic numbers on
diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
index 070c152da95a..0c50e5285cf6 100644
--- a/drivers/media/i2c/tvaudio.c
+++ b/drivers/media/i2c/tvaudio.c
@@ -272,7 +272,7 @@ static int chip_cmd(struct CHIPSTATE *chip, char *name,
audiocmd *cmd)
return -EINVAL;
}
- /* FIXME: it seems that the shadow bytes are wrong bellow !*/
+ /* FIXME: it seems that the shadow bytes are wrong below !*/
/* update our shadow register set; print bytes if (debug 0) */
v4l2_dbg(1, debug, sd, chip_cmd(%s): reg=%d, data:,
diff --git a/drivers/media/tuners/tuner-xc2028.c
b/drivers/media/tuners/tuner-xc2028.c
index d12f5e4ad8bf..4e941f00b600 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1094,7 +1094,7 @@ static int generic_set_freq(struct dvb_frontend *fe, u32
freq /* in HZ */,
* Still need tests for XC3028L (firmware 3.2 or upper)
* So, for now, let's just comment the per-firmware
* version of this change. Reports with xc3028l working
-* with and without the lines bellow are welcome
+* with and without the lines below are welcome
*/
if (priv-firm_version 0x0302) {
--
2.1.0
--
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 05/18] media controller: rename MEDIA_ENT_T_DEVNODE_DVB entities
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
In order to reflect that the entities are actually the hardware
(or firmware, or in-kernel software), and are not associated
with the DVB API, let's remove DEVNODE_ from the entity names
and use DTV (Digital TV) for the entities.
The frontend is an special case: the frontend devnode actually
talks directly with the DTV demodulator. It may or may not also
talk with the SEC (Satellite Equipment Control) and with the
tuner. For the sake of unifying the nomenclature, let's call it
as MEDIA_ENT_T_DTV_DEMOD, because this component is always
there.
So:
MEDIA_ENT_T_DEVNODE_DVB_FE- MEDIA_ENT_T_DTV_DEMOD
MEDIA_ENT_T_DEVNODE_DVB_DEMUX - MEDIA_ENT_T_DTV_DEMUX
MEDIA_ENT_T_DEVNODE_DVB_DVR - MEDIA_ENT_T_DTV_DVR
MEDIA_ENT_T_DEVNODE_DVB_CA- MEDIA_ENT_T_DTV_CA
MEDIA_ENT_T_DEVNODE_DVB_NET - MEDIA_ENT_T_DTV_NET
I'm happy with the new names.
PS.: we could actually not keep this define:
#define MEDIA_ENT_T_DEVNODE_DVB_FE MEDIA_ENT_T_DTV_DEMOD
As MEDIA_ENT_T_DEVNODE_DVB_FE symbol will not arrive any Kernel
version (being present only at the 4.1-rc kernels), but keeping
it helps to show that the DVB frontend node is actually associated
with the DTV demodulator. So, keeping it for now helps to better
document. Also, it avoids to break experimental versions of v4l-utils.
So, better to remove this only when we remove the remaining legacy
stuff.
I disagree with that. Let's not introduce defines that are not going to
be used. And v4l-utils is easily fixed.
Instead of keeping an unused define, why not...
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 759604e3529f..27082b07f4c2 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -195,23 +195,23 @@
entryALSA card/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_FE/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_DEMOD/constant/entry
entryDVB frontend devnode/entry
... explain what is going on here? I.e. that this frontend always controls a
demod
and optionally also a tuner and/or SEC.
Regards,
Hans
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_DEMUX/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_DEMUX/constant/entry
entryDVB demux devnode/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_DVR/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_DVR/constant/entry
entryDVB DVR devnode/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_CA/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_CA/constant/entry
entryDVB CAM devnode/entry
/row
row
- entryconstantMEDIA_ENT_T_DEVNODE_DVB_NET/constant/entry
+ entryconstantMEDIA_ENT_T_DTV_NET/constant/entry
entryDVB network devnode/entry
/row
row
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 13bb57f0457f..39846077045e 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -221,26 +221,26 @@ static void dvb_register_media_device(struct dvb_device
*dvbdev,
switch (type) {
case DVB_DEVICE_FRONTEND:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_FE;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_DEMOD;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev-pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_DEMUX:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_DEMUX;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_DEMUX;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev-pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_DVR:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_DVR;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_DVR;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
break;
case DVB_DEVICE_CA:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_CA;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_CA;
dvbdev-pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev-pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_NET:
- dvbdev-entity-type = MEDIA_ENT_T_DEVNODE_DVB_NET;
+ dvbdev-entity-type = MEDIA_ENT_T_DTV_NET;
break;
default:
kfree(dvbdev-entity);
@@ -396,16 +396,16 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
Re: [PATCH 07/18] media controller: rename the tuner entity
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
Finally, let's rename the tuner entity. inside the media subsystem,
a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
It could even be used on other subsystems, like network, for wireless
devices.
So, it is not constricted to V4L2 API, or to a subdev.
Let's then rename it as:
MEDIA_ENT_T_V4L2_SUBDEV_TUNER - MEDIA_ENT_T_TUNER
See patch 04/18.
Hans
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 9b3861058f0d..5c7f366bb1f4 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -241,7 +241,7 @@
signals./entry
/row
row
- entryconstantMEDIA_ENT_T_V4L2_SUBDEV_TUNER/constant/entry
+ entryconstantMEDIA_ENT_T_TUNER/constant/entry
entryTV and/or radio tuner/entry
/row
/tbody
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 39846077045e..d6a096495035 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -393,7 +393,7 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
media_device_for_each_entity(entity, mdev) {
switch (entity-type) {
- case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+ case MEDIA_ENT_T_TUNER:
tuner = entity;
break;
case MEDIA_ENT_T_DTV_DEMOD:
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index a756f74f0adc..2a7331e3c4a0 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1213,7 +1213,7 @@ static void cx231xx_create_media_graph(struct cx231xx
*dev)
media_device_for_each_entity(entity, mdev) {
switch (entity-type) {
- case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+ case MEDIA_ENT_T_TUNER:
tuner = entity;
break;
case MEDIA_ENT_T_ATV_DECODER:
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index abdcffabcb59..ecf4e8a543b3 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -696,7 +696,7 @@ static int tuner_probe(struct i2c_client *client,
register_client:
#if defined(CONFIG_MEDIA_CONTROLLER)
t-pad.flags = MEDIA_PAD_FL_SOURCE;
- t-sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t-sd.entity.type = MEDIA_ENT_T_TUNER;
t-sd.entity.name = t-name;
ret = media_entity_init(t-sd.entity, 1, t-pad, 0);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 9b3d80e765f0..6acc4be1378c 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -57,7 +57,7 @@ struct media_device_info {
#define MEDIA_ENT_T_ATV_DECODER (MEDIA_ENT_T_CAM_SENSOR + 3)
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER(MEDIA_ENT_T_CAM_SENSOR + 4)
+#define MEDIA_ENT_T_TUNER(MEDIA_ENT_T_CAM_SENSOR + 4)
#if 1
/*
@@ -88,6 +88,8 @@ struct media_device_info {
#define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_T_CAM_LENS
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNERMEDIA_ENT_T_TUNER
#endif
/* Used bitmasks for media_entity_desc::flags */
--
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 v6 06/11] cec: add HDMI CEC framework
Hi Kamil,
Just two tiny issues, and after that you can add my:
Reviewed-by: Hans Verkuil hans.verk...@ciso.com
to this.
On 05/04/2015 07:32 PM, Kamil Debski wrote:
diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
new file mode 100644
index 000..67b0049
--- /dev/null
+++ b/include/uapi/linux/cec.h
@@ -0,0 +1,332 @@
+#ifndef _CEC_H
+#define _CEC_H
+
+#include linux/types.h
+
+struct cec_msg {
+ __u64 ts;
+ __u32 len;
+ __u32 status;
+ __u32 timeout;
+ /* timeout (in ms) is used to timeout CEC_RECEIVE.
+Set to 0 if you want to wait forever. */
+ __u8 msg[16];
+ __u8 reply;
+ /* If non-zero, then wait for a reply with this opcode.
+If there was an error when sending the msg or FeatureAbort
+was returned, then reply is set to 0.
+If reply is non-zero upon return, then len/msg are set to
+the received message.
+If reply is zero upon return and status has the
+CEC_TX_STATUS_FEATURE_ABORT bit set, then len/msg are set to the
+received feature abort message.
+If reply is zero upon return and status has the
+CEC_TX_STATUS_REPLY_TIMEOUT
+bit set, then no reply was seen at all.
+This field is ignored with CEC_RECEIVE.
+If reply is non-zero for CEC_TRANSMIT and the message is a broadcast,
+then -EINVAL is returned.
+if reply is non-zero, then timeout is set to 1000 (the required
+maximum response time).
+ */
+ __u32 sequence;
+ /* The framework assigns a sequence number to messages that are sent.
+ * This can be used to track replies to previously sent messages.
+ */
+ __u8 reserved[35];
+};
It is confusing in struct cec_msg that the comments come *after* the field
they belong to instead of just before. Can you change this?
+
+#define CEC_G_EVENT _IOWR('a', 9, struct cec_event)
This can be __IOR since we never write anything.
+/*
+ Read and set the vendor ID of the CEC adapter.
+ */
+#define CEC_G_VENDOR_ID _IOR('a', 10, __u32)
+#define CEC_S_VENDOR_ID _IOW('a', 11, __u32)
+/*
+ Enable/disable the passthrough mode
+ */
+#define CEC_G_PASSTHROUGH_IOR('a', 12, __u32)
+#define CEC_S_PASSTHROUGH_IOW('a', 13, __u32)
+
+#endif
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] media controller: add EXPERIMENTAL to Kconfig option for DVB support
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote: The Media Controller DVB support is still an experimental feature, as it is under heavy development. It is already said that it is an experimental feature at the help, but let make it even clearer and louder, as we may need to adjust some bits when we start using it on embedded drivers. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks! Hans diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 3ef0f90b128f..8af89b084267 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -95,7 +95,7 @@ config MEDIA_CONTROLLER This API is mostly used by camera interfaces in embedded platforms. config MEDIA_CONTROLLER_DVB - bool Enable Media controller for DVB + bool Enable Media controller for DVB (EXPERIMENTAL) depends on MEDIA_CONTROLLER ---help--- Enable the media controller API support for DVB. -- 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
