cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Jan 27 05:00:21 CET 2017 media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a media_build git hash: 3c6ce4ff75f19adf45869e34b376c5b9dee4d50a v4l-utils git hash: 9df320dd3d1a498fcd6cdeef7d783da609b526e0 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.8.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: 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.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS 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.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10-rc3-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: OK linux-4.9-x86_64: OK linux-4.10-rc3-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.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
[PATCHv5 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support
Hi,
This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's
based on top of v4.10-rc1 and are tested on Renesas Salvator-X together
with the out of tree patches for rcar-vin to add support for Gen3 VIN
and a prototype driver for ADV7482. If anyone is interested to test
video grabbing using these out of tree patches please see [1].
Changes since v4:
- Match SoC part numbers and drop trailing space in documentation,
thanks Geert for pointing this out.
- Clarify that the driver is a CSI-2 receiver by supervised
s/interface/receiver/, thanks Laurent.
- Add entries in Kconfig and Makefile alphabetically instead of append.
- Rename struct rcar_csi2 member swap to lane_swap.
- Remove macros to wrap calls to dev_{dbg,info,warn,err}.
- Add wrappers for ioread32 and iowrite32.
- Remove unused interrupt handler, but keep checking in probe that there
are a interrupt define in DT.
- Rework how to wait for LP-11 state, thanks Laurent for the great idea!
- Remove unneeded delay in rcar_csi2_reset()
- Remove check for duplicated lane id:s from DT parsing. Broken out to a
separate patch adding this check directly to v4l2_of_parse_endpoint().
- Fixed rcar_csi2_start() to ask it's source subdevice for information
about pixel rate and frame format. With this change having
{set,get}_fmt operations became redundant, it was only used for
figuring out this out so dropped them.
- Tabulated frequency settings map.
- Dropped V4L2_SUBDEV_FL_HAS_DEVNODE it should never have been set.
- Switched from MEDIA_ENT_F_ATV_DECODER to
MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER as entity function. I can't
find a more suitable function, and what the hardware do is to fetch
video from an external chip and passes it on to a another SoC internal
IP it's sort of a formatter.
- Break out DT documentation and code in two patches.
Changes since v3:
- Update DT binding documentation with input from Geert Uytterhoeven,
thanks!
Changes since v2:
- Added media control pads as this is needed by the new rcar-vin driver.
- Update DT bindings after review comments and to add r8a7796 support.
- Add get_fmt handler.
- Fix media bus format error s/YUYV8/UYVY8/
Changes since v1:
- Drop dependency on a pad aware s_stream operation.
- Use the DT bindings format "renesas,-", thanks Geert
for pointing this out.
1. http://elinux.org/R-Car/Tests:rcar-vin
Niklas Söderlund (2):
media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver
.../devicetree/bindings/media/rcar-csi2.txt| 116
drivers/media/platform/rcar-vin/Kconfig| 11 +
drivers/media/platform/rcar-vin/Makefile | 1 +
drivers/media/platform/rcar-vin/rcar-csi2.c| 616 +
4 files changed, 744 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
--
2.11.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
[PATCHv5 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver
A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2 hardware blocks are connected between the video sources and the video grabbers (VIN). Driver is based on a prototype by Koji Matsuoka in the Renesas BSP. Signed-off-by: Niklas Söderlund --- drivers/media/platform/rcar-vin/Kconfig | 11 + drivers/media/platform/rcar-vin/Makefile| 1 + drivers/media/platform/rcar-vin/rcar-csi2.c | 616 3 files changed, 628 insertions(+) create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig index 111d2a151f6a4d44..f1df85d526e96a74 100644 --- a/drivers/media/platform/rcar-vin/Kconfig +++ b/drivers/media/platform/rcar-vin/Kconfig @@ -1,3 +1,14 @@ +config VIDEO_RCAR_CSI2 + tristate "R-Car MIPI CSI-2 Receiver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF + depends on ARCH_RENESAS || COMPILE_TEST + ---help--- + Support for Renesas R-Car MIPI CSI-2 receiver. + Supports R-Car Gen3 SoCs. + + To compile this driver as a module, choose M here: the + module will be called rcar-csi2. + config VIDEO_RCAR_VIN tristate "R-Car Video Input (VIN) Driver" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && MEDIA_CONTROLLER diff --git a/drivers/media/platform/rcar-vin/Makefile b/drivers/media/platform/rcar-vin/Makefile index 48c5632c21dc060b..5ab803d3e7c1aa57 100644 --- a/drivers/media/platform/rcar-vin/Makefile +++ b/drivers/media/platform/rcar-vin/Makefile @@ -1,3 +1,4 @@ rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c b/drivers/media/platform/rcar-vin/rcar-csi2.c new file mode 100644 index ..2d18bf32eb4e7fdb --- /dev/null +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c @@ -0,0 +1,616 @@ +/* + * Driver for Renesas R-Car MIPI CSI-2 Receiver + * + * Copyright (C) 2017 Renesas Electronics Corp. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* Register offsets and bits */ + +/* Control Timing Select */ +#define TREF_REG 0x00 +#define TREF_TREF (1 << 0) + +/* Software Reset */ +#define SRST_REG 0x04 +#define SRST_SRST (1 << 0) + +/* PHY Operation Control */ +#define PHYCNT_REG 0x08 +#define PHYCNT_SHUTDOWNZ (1 << 17) +#define PHYCNT_RSTZ(1 << 16) +#define PHYCNT_ENABLECLK (1 << 4) +#define PHYCNT_ENABLE_3(1 << 3) +#define PHYCNT_ENABLE_2(1 << 2) +#define PHYCNT_ENABLE_1(1 << 1) +#define PHYCNT_ENABLE_0(1 << 0) + +/* Checksum Control */ +#define CHKSUM_REG 0x0c +#define CHKSUM_ECC_EN (1 << 1) +#define CHKSUM_CRC_EN (1 << 0) + +/* + * Channel Data Type Select + * VCDT[0-15]: Channel 1 VCDT[16-31]: Channel 2 + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4 + */ +#define VCDT_REG 0x10 +#define VCDT2_REG 0x14 +#define VCDT_VCDTN_EN (1 << 15) +#define VCDT_SEL_VC(n) (((n) & 0x3) << 8) +#define VCDT_SEL_DTN_ON(1 << 6) +#define VCDT_SEL_DT(n) (((n) & 0x1f) << 0) + +/* Frame Data Type Select */ +#define FRDT_REG 0x18 + +/* Field Detection Control */ +#define FLD_REG0x1c +#define FLD_FLD_NUM(n) (((n) & 0xff) << 16) +#define FLD_FLD_EN4(1 << 3) +#define FLD_FLD_EN3(1 << 2) +#define FLD_FLD_EN2(1 << 1) +#define FLD_FLD_EN (1 << 0) + +/* Automatic Standby Control */ +#define ASTBY_REG 0x20 + +/* Long Data Type Setting 0 */ +#define LNGDT0_REG 0x28 + +/* Long Data Type Setting 1 */ +#define LNGDT1_REG 0x2c + +/* Interrupt Enable */ +#define INTEN_REG 0x30 + +/* Interrupt Source Mask */ +#define INTCLOSE_REG 0x34 + +/* Interrupt Status Monitor */ +#define INTSTATE_REG 0x38 + +/* Interrupt Error Status Monitor */ +#define INTERRSTATE_REG0x3c + +/* Short Packet Data */ +#define SHPDAT_REG 0x40 + +/* Short Packet Count */ +#
[PATCHv5 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
are located between the video sources (CSI-2 transmitters) and the video
grabbers (VIN) on Gen3 of Renesas R-Car SoC.
Each CSI-2 device is connected to more then one VIN device which
simultaneously can receive video from the same CSI-2 device. Each VIN
device can also be connected to more then one CSI-2 device. The routing
of which link are used are controlled by the VIN devices. There are only
a few possible routes which are set by hardware limitations, which are
different for each SoC in the Gen3 family.
To work with the limitations of routing possibilities it is necessary
for the DT bindings to describe which VIN device is connected to which
CSI-2 device. This is why port 1 needs to to assign reg numbers for each
VIN device that be connected to it. To setup and to know which links are
valid for each SoC is the responsibility of the VIN driver since the
register to configure it belongs to the VIN hardware.
Signed-off-by: Niklas Söderlund
---
.../devicetree/bindings/media/rcar-csi2.txt| 116 +
1 file changed, 116 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt
b/Documentation/devicetree/bindings/media/rcar-csi2.txt
new file mode 100644
index ..f6e2027ee92b171a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt
@@ -0,0 +1,116 @@
+Renesas R-Car MIPI CSI-2
+
+
+The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
+family of devices. It is to be used in conjunction with the R-Car VIN module,
+which provides the video capture capabilities.
+
+ - compatible: Must be one or more of the following
+ - "renesas,r8a7795-csi2" for the R8A7795 device.
+ - "renesas,r8a7796-csi2" for the R8A7796 device.
+ - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device.
+
+ When compatible with a generic version nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+The device node should contain two 'port' child nodes according to the
+bindings defined in Documentation/devicetree/bindings/media/
+video-interfaces.txt. Port 0 should connect the node that is the video
+source for to the CSI-2. Port 1 should connect all the R-Car VIN
+modules, which can make use of the CSI-2 module.
+
+- Port 0 - Video source
+ - Reg 0 - sub-node describing the endpoint that is the video source
+
+- Port 1 - VIN instances
+ - Reg 0 - sub-node describing the endpoint that is VIN0
+ - Reg 1 - sub-node describing the endpoint that is VIN1
+ - Reg 2 - sub-node describing the endpoint that is VIN2
+ - Reg 3 - sub-node describing the endpoint that is VIN3
+ - Reg 4 - sub-node describing the endpoint that is VIN4
+ - Reg 5 - sub-node describing the endpoint that is VIN5
+ - Reg 6 - sub-node describing the endpoint that is VIN6
+ - Reg 7 - sub-node describing the endpoint that is VIN7
+
+Example:
+
+/* SoC properties */
+
+csi20: csi2@fea8 {
+compatible = "renesas,r8a7796-csi2";
+reg = <0 0xfea8 0 0x1>;
+interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+clocks = <&cpg CPG_MOD 714>;
+power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+status = "disabled";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+reg = <1>;
+
+csi20vin0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&vin0csi20>;
+};
+csi20vin1: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&vin1csi20>;
+};
+csi20vin2: endpoint@2 {
+reg = <2>;
+remote-endpoint = <&vin2csi20>;
+};
+csi20vin3: endpoint@3 {
+reg = <3>;
+remote-endpoint = <&vin3csi20>;
+};
+csi20vin4: endpoint@4 {
+reg = <4>;
+remote-endpo
Re: [PATCH] v4l: of: check for unique lanes in data-lanes and clock-lanes
Hi Niklas,
On Thu, Jan 26, 2017 at 2:12 PM, Niklas Söderlund
wrote:
> diff --git a/drivers/media/v4l2-core/v4l2-of.c
> b/drivers/media/v4l2-core/v4l2-of.c
> index 93b33681776c..1042db6bb996 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -32,12 +32,19 @@ static int v4l2_of_parse_csi_bus(const struct device_node
> *node,
> prop = of_find_property(node, "data-lanes", NULL);
> if (prop) {
> const __be32 *lane = NULL;
> - unsigned int i;
> + unsigned int i, n;
Not "j"?
> for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
> lane = of_prop_next_u32(prop, lane, &v);
> if (!lane)
> break;
> + for (n = 0; n < i; n++) {
I'm not used seeing for loops with an index named "n", and limit named "i" ;-)
> + if (bus->data_lanes[n] == v) {
> + pr_warn("%s: duplicated lane %u in
> data-lanes\n",
> + node->full_name, v);
> + return -EINVAL;
> + }
> + }
> bus->data_lanes[i] = v;
> }
> bus->num_data_lanes = i;
> @@ -63,6 +70,15 @@ static int v4l2_of_parse_csi_bus(const struct device_node
> *node,
> }
>
> if (!of_property_read_u32(node, "clock-lanes", &v)) {
> + unsigned int n;
Likewise.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: of: check for unique lanes in data-lanes and clock-lanes
All lines in data-lanes and clock-lanes properties must be unique.
Instead of drivers checking for this add it to the generic parser.
Signed-off-by: Niklas Söderlund
---
drivers/media/v4l2-core/v4l2-of.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 93b33681776c..1042db6bb996 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -32,12 +32,19 @@ static int v4l2_of_parse_csi_bus(const struct device_node
*node,
prop = of_find_property(node, "data-lanes", NULL);
if (prop) {
const __be32 *lane = NULL;
- unsigned int i;
+ unsigned int i, n;
for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
lane = of_prop_next_u32(prop, lane, &v);
if (!lane)
break;
+ for (n = 0; n < i; n++) {
+ if (bus->data_lanes[n] == v) {
+ pr_warn("%s: duplicated lane %u in
data-lanes\n",
+ node->full_name, v);
+ return -EINVAL;
+ }
+ }
bus->data_lanes[i] = v;
}
bus->num_data_lanes = i;
@@ -63,6 +70,15 @@ static int v4l2_of_parse_csi_bus(const struct device_node
*node,
}
if (!of_property_read_u32(node, "clock-lanes", &v)) {
+ unsigned int n;
+
+ for (n = 0; n < bus->num_data_lanes; n++) {
+ if (bus->data_lanes[n] == v) {
+ pr_warn("%s: duplicated lane %u in
clock-lanes\n",
+ node->full_name, v);
+ return -EINVAL;
+ }
+ }
bus->clock_lane = v;
have_clk_lane = true;
}
--
2.11.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
[RFCv3 PATCH 1/1] hdpvr: fix interrupted recording
This is a reworking of a patch originally submitted by Ryley Angus, modified by
Hans Verkuil and then seemingly forgotten before changes suggested by Keith
Pyle here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg75163.html
were made and tested.
I have implemented the suggested changes and have been testing for several
months. I am no longer experiencing lockups while recording (with blue light
on, requiring power cycling) which had been a long standing problem with the
HD-PVR. I have not noticed any other problems since applying the patch.
Signed-off-by: Jonathan Sims
---
Changes in v3:
- Actually sleep for 4 seconds after the hdpvr_stop_streaming call.
drivers/media/usb/hdpvr/hdpvr-video.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 2a3a8b4..dec8496 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -454,6 +454,7 @@ static ssize_t hdpvr_read(struct file *file, char __user
*buffer, size_t count,
if (buf->status != BUFSTAT_READY &&
dev->status != STATUS_DISCONNECTED) {
+ int err;
/* return nonblocking */
if (file->f_flags & O_NONBLOCK) {
if (!ret)
@@ -461,9 +462,27 @@ static ssize_t hdpvr_read(struct file *file, char __user
*buffer, size_t count,
goto err;
}
- if (wait_event_interruptible(dev->wait_data,
- buf->status == BUFSTAT_READY))
- return -ERESTARTSYS;
+ err = wait_event_interruptible_timeout(dev->wait_data,
+ buf->status == BUFSTAT_READY,
+ msecs_to_jiffies(1000));
+ if (err < 0) {
+ ret = err;
+ goto err;
+ }
+ if (!err) {
+ int delay;
+
+ v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
+ "timeout: restart streaming\n");
+ hdpvr_stop_streaming(dev);
+ delay = msecs_to_jiffies(4000);
+ schedule_timeout(delay);
+ err = hdpvr_start_streaming(dev);
+ if (err) {
+ ret = err;
+ goto err;
+ }
+ }
}
if (buf->status != BUFSTAT_READY)
--
2.10.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
Metadata node IRC discussion on 19.01.2017
Hi all, A discussion of per-frame metadata took place on 19.01 on IRC. Participants: everybody in CC and myself. An earlier email on this mailing list https://www.mail-archive.com/linux-media@vger.kernel.org/msg107013.html served as a basis. The current state of the patches is: [v2.2,1/4] v4l: Add metadata buffer type and format https://patchwork.linuxtv.org/patch/36810/ [v3,4/4] uvcvideo: add a metadata device node https://patchwork.linuxtv.org/patch/38581/ 1. are separate metadata nodes really the best approach? One of the main reasons to use a separate /dev/video* node for per-frame metadata is to achieve maximum flexibility. In some cases metadata is produced and sent by the hardware before the complete video frame has been captured. E.g. image statistics, which is often calculated only over a part of the image to make it available as soon as possible. There are also use-cases, which can benefit from metadata being available before the frame has been transferred completely. The concern, that has been raised, is the difficulty to match metadata and image buffers. As a solution, the matching should be done, based on buffer sequence numbers. The drivers must make sure to always use matching sequence numbers. If any of the buffers got lost, the respective number will be skipped. To enable this a requirement for the first buffer on a video device node to have sequence number 0 should be removed. Further the request API can be used to match image and metadata buffers, once that API is available. 2. how should the image and metadata device nodes be associated? The Media Controller API should be used for this. E.g. on UVC both the image and the metadata video device nodes should have links from the same pad on the last entity in the video chain. It should be noted though, that linking one (source) pad to two (sink) pads isn't always possible. It would be impossible, if respective subdevices were creating device nodes themselves, thus providing a user API to them. The UVC driver doesn't do that, so, such linking should be possible. [remaining question] It should be possible to write a generic user-space application, that is be able to match image and metadata device nodes. On UVC this matching will be done by checking links to the same source pad. On other camera configurations this would be impossible, so, a different matching approach would be used. How can a generic application be written then? 3. how to handle isochronous video streaming interfaces on UVC cameras? As proposed in the above mentioned email, contents of payload headers should be exported via metadata nodes on UVC cameras. Those headers contain (currently, as of UVC standard 1.5) up to 12 bytes of standard data, but the size field of the header is 1 byte, therefore up to 255 bytes can be transferred in each payload header. Importantly, the standard UVC payload headers can include timestampe in the camera and the USB time bases, which can be required in the user-space. UVC video streaming interfaces can use isochronous or bulk endpoints. On bulk endpoints each frame is transferred as one payload. That limits the metadata amount to 255 bytes per frame. The problem with isochronous UVC interfaces is, that the frame can be transferred over USB in arbitrary many payloads. Some of them can even only consist of the minimal 2-byte header. Ideally all headers, belonging to a single video frame, should be transferred to the user in a single metadata buffer. This is problematic, because the maximum size of the metadata is unknown. No decision has been made on this topic. [proposal] to support isochronous endpoints, a decision has to be made to use a certain buffer size. The easiest way to handle excessive data would be to drop it. Alternatively a ring-buffer approach could be used to drop earlier headers and keep the later ones. Simultaneously statistics can be collected about the number and the size of acquired headers. That statistics can be made available to the user in a UVC-specific control. That way after an initial streaming session, an application could re-adjust its buffer size for the following sessions. Additionally entries can be added to the internal uvcvideo device table with maximum metadata size. That way the control could return one field for cameras in the device table, which would be 0 for unknown cameras, and further fields for any dynamically calculated information. Thanks Guennadi -- 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 v3 00/21] Make use of kref in media device, grab references as needed
Em Wed, 25 Jan 2017 13:02:31 +0200 Sakari Ailus escreveu: > Hi Mauro, > > On Tue, Jan 24, 2017 at 08:49:02AM -0200, Mauro Carvalho Chehab wrote: > > Hi Sakari, > > > > Just returned this week from vacations. I'm reading my long e-mail backlog, > > starting from my main inbox... > > > > Em Mon, 2 Jan 2017 09:53:49 +0200 > > Sakari Ailus escreveu: > > > > > Hi Mauro, > > > > > > On Mon, Dec 19, 2016 at 07:46:55AM -0200, Mauro Carvalho Chehab wrote: > > > > Em Fri, 16 Dec 2016 17:07:23 +0200 > > > > Sakari Ailus escreveu: > > > > > > > > > Hi Hans, > > > > > > > > > > chrdev_open in fs/char_dev.c increases the refcount on open() and > > > > > > decreases it > > > > > > on release(). Thus ensuring that the cdev can never be removed > > > > > > while in an > > > > > > ioctl. > > > > > > > > > > It does, but it does not affect memory which is allocated separately > > > > > of that. > > > > > > > > > > See this: > > > > > > > > > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg106390.html> > > > > > > > > > > > > > That sounds promising. If this bug issues other drivers than OMAP3, > > > > then indeed the core has a bug. > > > > > > > > I'll see if I can reproduce it here with some USB drivers later this > > > > week. > > > > > > It's not a driver problem so yes, it is reproducible on other hardware. > > > > Didn't have time to test it before entering into vacations. > > > > I guess I won't have any time this week to test those issues on > > my hardware, as I suspect that my patch queue is full. Also, we're > > approaching the next merge window. So, unfortunately, I won't have > > much time those days to do much testing. > > > > Btw, Hans commented that you were planning to working on it this month. > > > > Do you have some news with regards to the media controller bind/unbind > > fixes? > > I have a bunch of meeting notes to send from the Oslo meeting with Hans and > Laurent; I should have that ready by the end of the week. The RFC patchset > certainly needs changes based on that. OK. I'll wait for your notes and the new patchset. > > > > While IMHO it is overkill trying to support hot plug on omap3, I won't > > > > mind if you do that, provided that your patch series can be applied in > > > > a way that it won't cause regressions for real hot-pluggable hardware. > > > > > > > > > > This is not really about the OMAP3 ISP driver hotplug support; it is > > > indeed > > > about the framework's ability to support hotpluggable hardware. The > > > current > > > painpoint is removing hardware; the current frameworks aren't quite up to > > > that at the moment. > > > > The point here is that, while it would be fun to allow unbinding OMAP3 > > V4L2 drivers, OMAP3 doesn't really require hotplug support. On the other > > hand, on USB drivers, where unbind is a requirement, the current status > > of the tree is that hotplug works. I did some massive parallel bind/unbind > > loops here to double check, when we added such fixup patches. Granted, I > > won't doubt that there are still some rare race conditions that I was > > unable to reproduce on the time I tested. I also didn't try to hack the > > Kernel to introduce extra delays to make those race conditions more > > likely to happen. > > > > Anyway, my main concern with this patch is that it breaks hotplug on devices > > that really need it, while it fix support only for OMAP3 (with doesn't > > need). > > I don't disagree with you. Obviously the intent is not to break > hot-pluggable hardware, albeit the changes needed to avoid that haven't been > implemented yet. (One of the reasons it's been RFC all the time.) > > > > > Also, it starts with a series of patches that will cause regressions. > > > > I won't matter changing the solution to some other approach that would > > work, provided that the patches are added on an incremented way, and > > won't introduce regressions to USB drivers. > > It may be possible to avoid increasing the time window during which bad > things could happen before fully removing them. The fix should be to protecting those windows by either a kref, lock or a lockless (RCU) approach. > However the patchset is a > lot easier to work with without bundling the reverts into other (and likely > multiple) patches as the reverted patches took quite a different direction > than is followed in this patchset. Doing the reverts before doing the fixes do break things. What you're reverting is basically the logic that unbinds the struct media_devnode from struct media_device. This is independent from whatever changes you would be doing at struct media_device. So, you could do all changes there, apply such changes on OMAP3 and on the USB drivers and then rebind struct media_devnode at struct media_device[1]. [1] assuming that everyone agrees that rebinding it is for the best. I still think that having a separate struct is better - but this is something that I'l
