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: Wed Dec 7 05:00:17 CET 2016 media-tree git hash:365fe4e0ce218dc5ad10df17b150a366b6015499 media_build git hash: 1606032398b1d79149c1507be2029e1a00d8dff0 v4l-utils git hash: 80dbbf2058972628b3b366a20d12cf6bef273d76 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-rc5-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-rc5-x86_64: OK apps: WARNINGS spec-git: OK smatch: ERRORS sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/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
[PATCH v5 4/5] [media] dt-bindings: add TI VPIF documentation
Acked-by: Rob Herring
Signed-off-by: Kevin Hilman
---
.../devicetree/bindings/media/ti,da850-vpif.txt| 67 ++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
new file mode 100644
index ..fa06dfdb6898
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
@@ -0,0 +1,67 @@
+Texas Instruments VPIF
+--
+
+The TI Video Port InterFace (VPIF) is the primary component for video
+capture and display on the DA850/AM18x family of TI DaVinci/Sitara
+SoCs.
+
+TI Document reference: SPRUH82C, Chapter 35
+http://www.ti.com/lit/pdf/spruh82
+
+Required properties:
+- compatible: must be "ti,da850-vpif"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the VPIF
+
+Video Capture:
+
+VPIF has a 16-bit parallel bus input, supporting 2 8-bit channels or a
+single 16-bit channel. It should contain at least one port child node
+with child 'endpoint' node. Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example using 2 8-bit input channels, one of which is connected to an
+I2C-connected TVP5147 decoder:
+
+ vpif: vpif@217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+
+ port {
+ vpif_ch0: endpoint@0 {
+ reg = <0>;
+ bus-width = <8>;
+ remote-endpoint = <&composite>;
+ };
+
+ vpif_ch1: endpoint@1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+ };
+
+[ ... ]
+
+&i2c0 {
+
+ tvp5147@5d {
+ compatible = "ti,tvp5147";
+ reg = <0x5d>;
+ status = "okay";
+
+ port {
+ composite: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+
+ /* VPIF channel 0 (lower 8-bits) */
+ remote-endpoint = <&vpif_ch0>;
+ bus-width = <8>;
+ };
+ };
+ };
+};
--
2.9.3
--
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 v5 5/5] [media] davinci: VPIF: add basic support for DT init
Add basic support for initialization via DT
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c
index f50148dcba64..1b02a6363f77 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -467,8 +467,17 @@ static const struct dev_pm_ops vpif_pm = {
#define vpif_pm_ops NULL
#endif
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_of_match[] = {
+ { .compatible = "ti,da850-vpif", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_of_match);
+#endif
+
static struct platform_driver vpif_driver = {
.driver = {
+ .of_match_table = of_match_ptr(vpif_of_match),
.name = VPIF_DRIVER_NAME,
.pm = vpif_pm_ops,
},
--
2.9.3
--
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 v5 1/5] [media] davinci: VPIF: fix module loading, init errors
Fix problems with automatic module loading by adding MODULE_ALIAS. Also
fix various load-time errors cause by incorrect or not present
platform_data.
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif.c | 5 -
drivers/media/platform/davinci/vpif_capture.c | 15 ++-
drivers/media/platform/davinci/vpif_display.c | 6 ++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c
index 0380cf2e5775..f50148dcba64 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -32,6 +32,9 @@
MODULE_DESCRIPTION("TI DaVinci Video Port Interface driver");
MODULE_LICENSE("GPL");
+#define VPIF_DRIVER_NAME "vpif"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
+
#define VPIF_CH0_MAX_MODES 22
#define VPIF_CH1_MAX_MODES 2
#define VPIF_CH2_MAX_MODES 15
@@ -466,7 +469,7 @@ static const struct dev_pm_ops vpif_pm = {
static struct platform_driver vpif_driver = {
.driver = {
- .name = "vpif",
+ .name = VPIF_DRIVER_NAME,
.pm = vpif_pm_ops,
},
.remove = vpif_remove,
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 5104cc0ee40e..20c4344ed118 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -45,6 +45,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
#define VPIF_DRIVER_NAME "vpif_capture"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
/* global variables */
static struct vpif_device vpif_obj = { {NULL} };
@@ -647,6 +648,10 @@ static int vpif_input_to_subdev(
vpif_dbg(2, debug, "vpif_input_to_subdev\n");
+ if (!chan_cfg)
+ return -1;
+ if (input_index >= chan_cfg->input_count)
+ return -1;
subdev_name = chan_cfg->inputs[input_index].subdev_name;
if (subdev_name == NULL)
return -1;
@@ -654,7 +659,7 @@ static int vpif_input_to_subdev(
/* loop through the sub device list to get the sub device info */
for (i = 0; i < vpif_cfg->subdev_count; i++) {
subdev_info = &vpif_cfg->subdev_info[i];
- if (!strcmp(subdev_info->name, subdev_name))
+ if (subdev_info && !strcmp(subdev_info->name, subdev_name))
return i;
}
return -1;
@@ -685,6 +690,9 @@ static int vpif_set_input(
if (sd_index >= 0) {
sd = vpif_obj.sd[sd_index];
subdev_info = &vpif_cfg->subdev_info[sd_index];
+ } else {
+ /* no subdevice, no input to setup */
+ return 0;
}
/* first setup input path from sub device to vpif */
@@ -1435,6 +1443,11 @@ static __init int vpif_probe(struct platform_device
*pdev)
int res_idx = 0;
int i, err;
+ if (!pdev->dev.platform_data) {
+ dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
+ return -EINVAL;
+ }
+
vpif_dev = &pdev->dev;
err = initialize_vpif();
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 75b27233ec2f..7f632b757d32 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -42,6 +42,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
#define VPIF_DRIVER_NAME "vpif_display"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
/* Is set to 1 in case of SDTV formats, 2 in case of HDTV formats. */
static int ycmux_mode;
@@ -1249,6 +1250,11 @@ static __init int vpif_probe(struct platform_device
*pdev)
int res_idx = 0;
int i, err;
+ if (!pdev->dev.platform_data) {
+ dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
+ return -EINVAL;
+ }
+
vpif_dev = &pdev->dev;
err = initialize_vpif();
--
2.9.3
--
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 v5 0/5] davinci: VPIF: add DT support
Prepare the groundwork for adding DT support for davinci VPIF drivers. This series does some fixups/cleanups and then adds the DT binding and DT compatible string matching for DT probing. The controversial part from previous versions around async subdev parsing, and specifically hard-coding the input/output routing of subdevs, has been left out of this series. That part can be done as a follow-on step after agreement has been reached on the path forward. With this version, platforms can still use the VPIF capture/display drivers, but must provide platform_data for the subdevs and subdev routing. Tested video capture to memory on da850-lcdk board using composite input. Changes since v4: - dropped controversial async subdev parsing support. That can be done as a follow-up step after the discussions have finalized on the right approach. - DT binding Acked by DT maintainer (Rob H.) - reworked locking fix (suggested by Laurent) Changes since v3: - move to a single VPIF node, DT binding updated accordingly - misc fixes/updates based on reviews from Sakari Changes since v2: - DT binding doc: fix example to use correct compatible Changes since v1: - more specific compatible strings, based on SoC: ti,da850-vpif* - fix locking bug when unlocking over subdev s_stream Kevin Hilman (5): [media] davinci: VPIF: fix module loading, init errors [media] davinci: vpif_capture: remove hard-coded I2C adapter id [media] davinci: vpif_capture: fix start/stop streaming locking [media] dt-bindings: add TI VPIF documentation [media] davinci: VPIF: add basic support for DT init .../devicetree/bindings/media/ti,da850-vpif.txt| 67 ++ drivers/media/platform/davinci/vpif.c | 14 - drivers/media/platform/davinci/vpif_capture.c | 26 +++-- drivers/media/platform/davinci/vpif_display.c | 6 ++ include/media/davinci/vpif_types.h | 1 + 5 files changed, 108 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt -- 2.9.3 -- 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 v5 3/5] [media] davinci: vpif_capture: fix start/stop streaming locking
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
The IRQ-disabled locking is meant to protect the DMA queue list
throughout the rest of the driver, so update the locking in
[start|stop]_streaming to protect just this list.
Suggested-by: Laurent Pinchart
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif_capture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index c24049acd40a..f72a719efb3d 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -179,8 +179,6 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
unsigned long addr, flags;
int ret;
- spin_lock_irqsave(&common->irqlock, flags);
-
/* Initialize field_id */
ch->field_id = 0;
@@ -211,6 +209,7 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
vpif_config_addr(ch, ret);
/* Get the next frame from the buffer queue */
+ spin_lock_irqsave(&common->irqlock, flags);
common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
/* Remove buffer from the buffer queue */
@@ -244,6 +243,7 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
return 0;
err:
+ spin_lock_irqsave(&common->irqlock, flags);
list_for_each_entry_safe(buf, tmp, &common->dma_queue, list) {
list_del(&buf->list);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
@@ -287,7 +287,6 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
vpif_dbg(1, debug, "stream off failed in subdev\n");
/* release all active buffers */
- spin_lock_irqsave(&common->irqlock, flags);
if (common->cur_frm == common->next_frm) {
vb2_buffer_done(&common->cur_frm->vb.vb2_buf,
VB2_BUF_STATE_ERROR);
@@ -300,6 +299,7 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
VB2_BUF_STATE_ERROR);
}
+ spin_lock_irqsave(&common->irqlock, flags);
while (!list_empty(&common->dma_queue)) {
common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
--
2.9.3
--
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 v5 2/5] [media] davinci: vpif_capture: remove hard-coded I2C adapter id
Remove hard-coded I2C adapter in favor of getting the
ID from platform_data.
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif_capture.c | 5 -
include/media/davinci/vpif_types.h| 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 20c4344ed118..c24049acd40a 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1486,7 +1486,10 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
if (!vpif_obj.config->asd_sizes) {
- i2c_adap = i2c_get_adapter(1);
+ int i2c_id = vpif_obj.config->i2c_adapter_id;
+
+ i2c_adap = i2c_get_adapter(i2c_id);
+ WARN_ON(!i2c_adap);
for (i = 0; i < subdev_count; i++) {
subdevdata = &vpif_obj.config->subdev_info[i];
vpif_obj.sd[i] =
diff --git a/include/media/davinci/vpif_types.h
b/include/media/davinci/vpif_types.h
index 3cb1704a0650..4282a7db99d4 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -82,6 +82,7 @@ struct vpif_capture_config {
struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
struct vpif_subdev_info *subdev_info;
int subdev_count;
+ int i2c_adapter_id;
const char *card_name;
struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
int *asd_sizes; /* 0-terminated array of asd group sizes */
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] [media] lirc: LIRC_{G,S}ET_SEND_MODE fail if device cannot transmit
Reviewed-by: Andi Shyti On Fri, Dec 02, 2016 at 05:16:09PM +, Sean Young wrote: > These ioctls should not succeed if the device cannot send. Also make it > clear that these ioctls should return the lirc mode, although the actual > value does not change. > > Signed-off-by: Sean Young > --- > drivers/media/rc/ir-lirc-codec.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/rc/ir-lirc-codec.c > b/drivers/media/rc/ir-lirc-codec.c > index c327730..9e41305 100644 > --- a/drivers/media/rc/ir-lirc-codec.c > +++ b/drivers/media/rc/ir-lirc-codec.c > @@ -204,11 +204,17 @@ static long ir_lirc_ioctl(struct file *filep, unsigned > int cmd, > > /* legacy support */ > case LIRC_GET_SEND_MODE: > - val = LIRC_CAN_SEND_PULSE & LIRC_CAN_SEND_MASK; > + if (!dev->tx_ir) > + return -ENOTTY; > + > + val = LIRC_MODE_PULSE; > break; > > case LIRC_SET_SEND_MODE: > - if (val != (LIRC_MODE_PULSE & LIRC_CAN_SEND_MASK)) > + if (!dev->tx_ir) > + return -ENOTTY; > + > + if (val != LIRC_MODE_PULSE) > return -EINVAL; > return 0; > > -- > 2.9.3 > > -- > 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 1/8] [media] mceusb: LIRC_SET_SEND_CARRIER returns 0 on success
Reviewed-by: Andi Shyti
On Fri, Dec 02, 2016 at 05:16:07PM +, Sean Young wrote:
> LIRC_SET_SEND_CARRIER ioctl should not return the carrier used, it
> should return 0.
>
> Signed-off-by: Sean Young
> ---
> drivers/media/rc/mceusb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index 9bf6917..96b0ade 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -890,7 +890,7 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32
> carrier)
> cmdbuf[3] = MCE_IRDATA_TRAILER;
> dev_dbg(ir->dev, "disabling carrier modulation");
> mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
> - return carrier;
> + return 0;
> }
>
> for (prescaler = 0; prescaler < 4; ++prescaler) {
> @@ -904,7 +904,7 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32
> carrier)
>
> /* Transmit new carrier to mce device */
> mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
> - return carrier;
> + return 0;
> }
> }
>
> --
> 2.9.3
>
> --
> 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 2/8] [media] lirc_dev: LIRC_{G,S}ET_REC_MODE do not work
> Since "273b902 [media] lirc_dev: use LIRC_CAN_REC() define" these
> ioctls no longer work.
>
> Signed-off-by: Sean Young
> Cc: Andi Shyti
> Cc: # v4.8+
mmhhh... yes, right! :)
Reviewed-by: Andi Shyti
Thanks,
Andi
> ---
> drivers/media/rc/lirc_dev.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
> index 3854809..7f5d109 100644
> --- a/drivers/media/rc/lirc_dev.c
> +++ b/drivers/media/rc/lirc_dev.c
> @@ -582,7 +582,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int
> cmd, unsigned long arg)
> result = put_user(ir->d.features, (__u32 __user *)arg);
> break;
> case LIRC_GET_REC_MODE:
> - if (LIRC_CAN_REC(ir->d.features)) {
> + if (!LIRC_CAN_REC(ir->d.features)) {
> result = -ENOTTY;
> break;
> }
> @@ -592,7 +592,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int
> cmd, unsigned long arg)
> (__u32 __user *)arg);
> break;
> case LIRC_SET_REC_MODE:
> - if (LIRC_CAN_REC(ir->d.features)) {
> + if (!LIRC_CAN_REC(ir->d.features)) {
> result = -ENOTTY;
> break;
> }
> --
> 2.9.3
>
>
--
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 v7 0/3] Media Device Allocator API
Media Device Allocator API to allows multiple drivers share a media device. Using this API, drivers can allocate a media device with the shared struct device as the key. Once the media device is allocated by a driver, other drivers can get a reference to it. The media device is released when all the references are released. Patches 0001 and 0002 are rebased to 4.9-rc7. Patch 0003 for snd-usb-audio is a rebase of the patch that was tested with the original Media Device Allocator patch series. snd-usb-audio patch includes the fixes found during 4.7-rc1 time in the original snd-usb-audio patch. Changes to patches in this series: Changes to patch 0001 since v6: - No changes Changes to patch 0002 since v6: - No changes Changes to patch 0003 since v6: - Addressed Takashi's review comments on patch v6 Depends on: https://lkml.org/lkml/2016/11/29/1001 Changes to patch 0001 since v5: (comments from Mauro and Sakari) - Removed struct device from media_device_instance. mdev.dev is used instead. - Added documentation. Changes to patch 0002: - No changes since patch v2, applies cleanly on top of the following: media: Protect enable_source and disable_source handler code paths https://lkml.org/lkml/2016/11/29/1001 Changes to patch 0003: - Changed to hold graph_mutex to check and call enable_source and disable_source handlers - to match au0828 doing the same in: media: Protect enable_source and disable_source handler code paths https://lkml.org/lkml/2016/11/29/1001 Changes to patch 0001 since v4: - Addressed Sakari's review comments with the exception of opting to not introduce media_device_usb_allocate() macro, and to not add a new routine to find media device instance to avoid a one line check. Changes to patch 0001 since v3: - Fixed undefined reference to `__media_device_usb_init compile error when CONFIG_USB is disabled. - Fixed kernel paging error when accessing /dev/mediaX after rmmod of the module that owns the media_device. The fix bumps the reference count for the owner when second driver comes along to share the media_device. If au0828 owns the media_device, then snd_usb_audio will bump the refcount for au0828, so it won't get deleted and vice versa. Changes to patch 0002 since v2: - Updated media_device_delete() to pass in module name. Changes to patch 0003 since the last version in 4.7-rc1: - Included fixes to bugs found during testing. - Updated to use the Media Allocator API. This patch series has been tested with au0828 and snd-usb-audio drivers. Ran bind and unbind loop tests on each driver with mc_nextgen_test and media_device_test app loop tests while checking lsmod and dmesg. Please refer to tools/testing/selftests/media_tests/regression_test.txt for testing done on this series. Shuah Khan (3): media: Media Device Allocator API media: change au0828 to use Media Device Allocator API sound/usb: Use Media Controller API to share media resources Documentation/media/kapi/mc-core.rst | 37 drivers/media/Makefile | 3 +- drivers/media/media-dev-allocator.c| 133 ++ drivers/media/usb/au0828/au0828-core.c | 12 +- drivers/media/usb/au0828/au0828.h | 1 + include/media/media-dev-allocator.h| 54 ++ sound/usb/Kconfig | 4 + sound/usb/Makefile | 2 + sound/usb/card.c | 14 ++ sound/usb/card.h | 3 + sound/usb/media.c | 321 + sound/usb/media.h | 73 sound/usb/mixer.h | 3 + sound/usb/pcm.c| 29 ++- sound/usb/quirks-table.h | 1 + sound/usb/stream.c | 2 + sound/usb/usbaudio.h | 6 + 17 files changed, 684 insertions(+), 14 deletions(-) create mode 100644 drivers/media/media-dev-allocator.c create mode 100644 include/media/media-dev-allocator.h create mode 100644 sound/usb/media.c create mode 100644 sound/usb/media.h -- 2.7.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 v7 1/3] media: Media Device Allocator API
Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.
Signed-off-by: Shuah Khan
---
No changes since v6
Documentation/media/kapi/mc-core.rst | 37 ++
drivers/media/Makefile | 3 +-
drivers/media/media-dev-allocator.c | 133 +++
include/media/media-dev-allocator.h | 54 ++
4 files changed, 226 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/media-dev-allocator.c
create mode 100644 include/media/media-dev-allocator.h
diff --git a/Documentation/media/kapi/mc-core.rst
b/Documentation/media/kapi/mc-core.rst
index 1a738e5..4942cdd 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -257,8 +257,45 @@ Subsystems should facilitate link validation by providing
subsystem specific
helper functions to provide easy access for commonly needed information, and
in the end provide a way to use driver-specific callbacks.
+Media Controller Device Allocator API
+^
+
+When media device belongs to more than one driver, the shared media device
+is allocated with the shared struct device as the key for look ups.
+
+Shared media device should stay in registered state until the last driver
+unregisters it. In addition, media device should be released when all the
+references are released. Each driver gets a reference to the media device
+during probe, when it allocates the media device. If media device is already
+allocated, allocate API bumps up the refcount and return the existing media
+device. Driver puts the reference back from its disconnect routine when it
+calls :c:func:`media_device_delete()`.
+
+Media device is unregistered and cleaned up from the kref put handler to
+ensure that the media device stays in registered state until the last driver
+unregisters the media device.
+
+**Driver Usage**
+
+Drivers should use the media-core routines to get register reference and
+call :c:func:`media_device_delete()` routine to make sure the shared media
+device delete is handled correctly.
+
+**driver probe:**
+Call :c:func:`media_device_usb_allocate()` to allocate or get a reference
+Call :c:func:`media_device_register()`, if media devnode isn't registered
+
+**driver disconnect:**
+Call :c:func:`media_device_delete()` to free the media_device. Free'ing is
+handled by the kref put handler.
+
+API Definitions
+^^^
+
.. kernel-doc:: include/media/media-device.h
.. kernel-doc:: include/media/media-devnode.h
.. kernel-doc:: include/media/media-entity.h
+
+.. kernel-doc:: include/media/media-dev-allocator.h
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 0deaa93..7c0701d 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -6,7 +6,8 @@ ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
endif
-media-objs := media-device.o media-devnode.o media-entity.o
+media-objs := media-device.o media-devnode.o media-entity.o \
+ media-dev-allocator.o
#
# I2C drivers should come before other drivers, otherwise they'll fail
diff --git a/drivers/media/media-dev-allocator.c
b/drivers/media/media-dev-allocator.c
new file mode 100644
index 000..0ecf152
--- /dev/null
+++ b/drivers/media/media-dev-allocator.c
@@ -0,0 +1,133 @@
+/*
+ * media-dev-allocator.c - Media Controller Device Allocator API
+ *
+ * Copyright (c) 2016 Shuah Khan
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ * Credits: Suggested by Laurent Pinchart
+ */
+
+/*
+ * This file adds a global refcounted Media Controller Device Instance API.
+ * A system wide global media device list is managed and each media device
+ * includes a kref count. The last put on the media device releases the media
+ * device instance.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+static LIST_HEAD(media_device_list);
+static DEFINE_MUTEX(media_device_lock);
+
+struct media_device_instance {
+ struct media_device mdev;
+ struct module *owner;
+ struct list_head list;
+ struct kref refcount;
+};
+
+static inline struct media_device_instance *
+to_media_device_instance(struct media_device *mdev)
+{
+ return container_of(mdev, struct media_device_instance, mdev);
+}
+
+static void media_device_instance_release(struct kref *kref)
+{
+ struct media_device_instance *mdi =
+ container_of(kref, struct media_device_instance, refcount);
+
+ dev_dbg(mdi->mdev.dev, "%s: mdev=%p\n", __func__, &mdi->mdev);
+
+ mutex_lock(&media_device_lock);
+
+ media_device_unregister(&mdi->mdev);
+ media_device_cleanup(&mdi->mdev);
+
+
[PATCH v7 2/3] media: change au0828 to use Media Device Allocator API
Change au0828 to use Media Device Allocator API to allocate media device
with the parent usb struct device as the key, so it can be shared with the
snd_usb_audio driver.
Signed-off-by: Shuah Khan
---
No changes since v6
drivers/media/usb/au0828/au0828-core.c | 12
drivers/media/usb/au0828/au0828.h | 1 +
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index bfd6482..ff1928e 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -159,9 +159,7 @@ static void au0828_unregister_media_device(struct
au0828_dev *dev)
dev->media_dev->disable_source = NULL;
mutex_unlock(&mdev->graph_mutex);
- media_device_unregister(dev->media_dev);
- media_device_cleanup(dev->media_dev);
- kfree(dev->media_dev);
+ media_device_delete(dev->media_dev, KBUILD_MODNAME);
dev->media_dev = NULL;
#endif
}
@@ -214,14 +212,10 @@ static int au0828_media_device_init(struct au0828_dev
*dev,
#ifdef CONFIG_MEDIA_CONTROLLER
struct media_device *mdev;
- mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
+ mdev = media_device_usb_allocate(udev, KBUILD_MODNAME);
if (!mdev)
return -ENOMEM;
- /* check if media device is already initialized */
- if (!mdev->dev)
- media_device_usb_init(mdev, udev, udev->product);
-
dev->media_dev = mdev;
#endif
return 0;
@@ -482,6 +476,8 @@ static int au0828_media_device_register(struct au0828_dev
*dev,
/* register media device */
ret = media_device_register(dev->media_dev);
if (ret) {
+ media_device_delete(dev->media_dev, KBUILD_MODNAME);
+ dev->media_dev = NULL;
dev_err(&udev->dev,
"Media Device Register Error: %d\n", ret);
return ret;
diff --git a/drivers/media/usb/au0828/au0828.h
b/drivers/media/usb/au0828/au0828.h
index dd7b378..4bf1b0c 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
/* DVB */
#include "demux.h"
--
2.7.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 v7 3/3] sound/usb: Use Media Controller API to share media resources
Change ALSA driver to use Media Controller API to share media resources
with DVB, and V4L2 drivers on a AU0828 media device.
Media Controller specific initialization is done after sound card is
registered. ALSA creates Media interface and entity function graph
nodes for Control, Mixer, PCM Playback, and PCM Capture devices.
snd_usb_hw_params() will call Media Controller enable source handler
interface to request the media resource. If resource request is granted,
it will release it from snd_usb_hw_free(). If resource is busy, -EBUSY is
returned.
Media specific cleanup is done in usb_audio_disconnect().
Signed-off-by: Shuah Khan
---
Changes to patch 0003 since v6:
- Addressed Takashi's review comments on patch v6
sound/usb/Kconfig| 4 +
sound/usb/Makefile | 2 +
sound/usb/card.c | 14 +++
sound/usb/card.h | 3 +
sound/usb/media.c| 321 +++
sound/usb/media.h| 73 +++
sound/usb/mixer.h| 3 +
sound/usb/pcm.c | 29 -
sound/usb/quirks-table.h | 1 +
sound/usb/stream.c | 2 +
sound/usb/usbaudio.h | 6 +
11 files changed, 453 insertions(+), 5 deletions(-)
create mode 100644 sound/usb/media.c
create mode 100644 sound/usb/media.h
diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
index a452ad7..d14bf41 100644
--- a/sound/usb/Kconfig
+++ b/sound/usb/Kconfig
@@ -15,6 +15,7 @@ config SND_USB_AUDIO
select SND_RAWMIDI
select SND_PCM
select BITREVERSE
+ select SND_USB_AUDIO_USE_MEDIA_CONTROLLER if MEDIA_CONTROLLER &&
(MEDIA_SUPPORT=y || MEDIA_SUPPORT=SND_USB_AUDIO)
help
Say Y here to include support for USB audio and USB MIDI
devices.
@@ -22,6 +23,9 @@ config SND_USB_AUDIO
To compile this driver as a module, choose M here: the module
will be called snd-usb-audio.
+config SND_USB_AUDIO_USE_MEDIA_CONTROLLER
+ bool
+
config SND_USB_UA101
tristate "Edirol UA-101/UA-1000 driver"
select SND_PCM
diff --git a/sound/usb/Makefile b/sound/usb/Makefile
index 2d2d122..8dca3c4 100644
--- a/sound/usb/Makefile
+++ b/sound/usb/Makefile
@@ -15,6 +15,8 @@ snd-usb-audio-objs := card.o \
quirks.o \
stream.o
+snd-usb-audio-$(CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER) += media.o
+
snd-usbmidi-lib-objs := midi.o
# Toplevel Module Dependency
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 2ddc034..570ff00 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -66,6 +66,7 @@
#include "format.h"
#include "power.h"
#include "stream.h"
+#include "media.h"
MODULE_AUTHOR("Takashi Iwai ");
MODULE_DESCRIPTION("USB Audio");
@@ -616,6 +617,11 @@ static int usb_audio_probe(struct usb_interface *intf,
if (err < 0)
goto __error;
+ if (quirk && quirk->media_device) {
+ /* don't want to fail when media_snd_device_create() fails */
+ media_snd_device_create(chip, intf);
+ }
+
usb_chip[chip->index] = chip;
chip->num_interfaces++;
usb_set_intfdata(intf, chip);
@@ -672,6 +678,14 @@ static void usb_audio_disconnect(struct usb_interface
*intf)
list_for_each(p, &chip->midi_list) {
snd_usbmidi_disconnect(p);
}
+ /*
+* Nice to check quirk && quirk->media_device and
+* then call media_snd_device_delete(). Don't have
+* access to quirk here. media_snd_device_delete()
+* acceses mixer_list
+*/
+ media_snd_device_delete(chip);
+
/* release mixer resources */
list_for_each_entry(mixer, &chip->mixer_list, list) {
snd_usb_mixer_disconnect(mixer);
diff --git a/sound/usb/card.h b/sound/usb/card.h
index 111b0f0..6ef8e88 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -105,6 +105,8 @@ struct snd_usb_endpoint {
struct list_head list;
};
+struct media_ctl;
+
struct snd_usb_substream {
struct snd_usb_stream *stream;
struct usb_device *dev;
@@ -156,6 +158,7 @@ struct snd_usb_substream {
} dsd_dop;
bool trigger_tstamp_pending_update; /* trigger timestamp being updated
from initial estimate */
+ struct media_ctl *media_ctl;
};
struct snd_usb_stream {
diff --git a/sound/usb/media.c b/sound/usb/media.c
new file mode 100644
index 000..0a8fc14
--- /dev/null
+++ b/sound/usb/media.c
@@ -0,0 +1,321 @@
+/*
+ * media.c - Media Controller specific ALSA driver code
+ *
+ * Copyright (c) 2016 Shuah Khan
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+
+/*
+ * This file adds Media Controller support to ALSA driver
+ * to use the Media Controller API to share tuner with DVB
+ * and V4L2 drivers that control media device. Media device
+ * i
Re: Enabling peer to peer device transactions for PCIe devices
On Tue, Dec 6, 2016 at 1:47 PM, Logan Gunthorpe wrote: > Hey, > >> Okay, so clearly this needs a kernel side NVMe specific allocator >> and locking so users don't step on each other.. > > Yup, ideally. That's why device dax isn't ideal for this application: it > doesn't provide any way to prevent users from stepping on each other. On this particular point I'm in the process of posting patches that allow device-dax sub-division, so you could carve up a bar into multiple devices of various sizes. -- 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: Enabling peer to peer device transactions for PCIe devices
Hey, > Okay, so clearly this needs a kernel side NVMe specific allocator > and locking so users don't step on each other.. Yup, ideally. That's why device dax isn't ideal for this application: it doesn't provide any way to prevent users from stepping on each other. > Or as Christoph says some kind of general mechanism to get these > bounce buffers.. Yeah, I imagine a general allocate from BAR/region system would be very useful. > Ah, I see. > > As a first draft I'd stick with some kind of API built into the > /dev/nvmeX that backs the filesystem. The user app would fstat the > target file, open /dev/block/MAJOR(st_dev):MINOR(st_dev), do some > ioctl to get a CMB mmap, and then proceed from there.. > > When that is all working kernel-side, it would make sense to look at a > more general mechanism that could be used unprivileged?? That makes a lot of sense to me. I suggested mmapping the char device because it's really easy, but I can see that an ioctl on the block device does seem more general and device agnostic. > This is similar to the GPU issues too.. On NVMe you don't need to pin > the pages, you just need to lock that VMA so it doesn't get freed from > the NVMe CMB allocator while the IO is running... > Probably in the long run the get_user_pages is going to have to be > pushed down into drivers.. Future MMU coherent IO hardware also does > not need the pinning or other overheads. Yup. Yup. Logan -- 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 v3 3/4] [media] davinci: vpif_capture: get subdevs from DT
On Tue, Dec 6, 2016 at 9:40 AM, Kevin Hilman wrote:
> Hans Verkuil writes:
>
>> On 12/01/2016 10:16 AM, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> On Thursday 01 Dec 2016 09:57:31 Sakari Ailus wrote:
On Wed, Nov 30, 2016 at 04:14:11PM -0800, Kevin Hilman wrote:
> Sakari Ailus writes:
>> On Wed, Nov 23, 2016 at 03:25:32PM -0800, Kevin Hilman wrote:
>>> Sakari Ailus writes:
On Tue, Nov 22, 2016 at 07:52:43AM -0800, Kevin Hilman wrote:
> Allow getting of subdevs from DT ports and endpoints.
>
> The _get_pdata() function was larely inspired by (i.e. stolen from)
> am437x-vpfe.c
>
> Signed-off-by: Kevin Hilman
> ---
>
> drivers/media/platform/davinci/vpif_capture.c | 130 +++-
> include/media/davinci/vpif_types.h
>| 9 +-
> 2 files changed, 133 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c index
> 94ee6cf03f02..47a4699157e7 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -26,6 +26,8 @@
> #include
>
> #include
> +#include
> +#include
Do you need this header?
>>>
>>> Yes, based on discussion with Hans, since there is no DT binding for
>>> selecting the input pins of the TVP514x, I have to select it in the
>>> driver, so I need the defines from this header. More on this below...
>>>
>>> That's really ugly :-( The problem should be fixed properly instead of
>>> adding
>>> one more offender.
>>
>> Do you have time for that, Laurent? I don't. Until that time we just need to
>> make do with this workaround.
>>
>>>
> #include "vpif.h"
> #include "vpif_capture.h"
> @@ -650,6 +652,10 @@ static int vpif_input_to_subdev(
>
>vpif_dbg(2, debug, "vpif_input_to_subdev\n");
>
> + if (!chan_cfg)
> + return -1;
> + if (input_index >= chan_cfg->input_count)
> + return -1;
>subdev_name = chan_cfg->inputs[input_index].subdev_name;
>if (subdev_name == NULL)
>return -1;
> @@ -657,7 +663,7 @@ static int vpif_input_to_subdev(
>/* loop through the sub device list to get the sub device info
>*/
>for (i = 0; i < vpif_cfg->subdev_count; i++) {
>subdev_info = &vpif_cfg->subdev_info[i];
> - if (!strcmp(subdev_info->name, subdev_name))
> + if (subdev_info && !strcmp(subdev_info->name,
> subdev_name))
>return i;
>}
>return -1;
> @@ -1327,6 +1333,21 @@ static int vpif_async_bound(struct
> v4l2_async_notifier *notifier,> >> >>
> {
>int i;
>
> + for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
> + struct v4l2_async_subdev *_asd = vpif_obj.config
> ->asd[i];
> + const struct device_node *node = _asd->match.of.node;
> +
> + if (node == subdev->of_node) {
> + vpif_obj.sd[i] = subdev;
> + vpif_obj.config->chan_config
> ->inputs[i].subdev_name =
> + (char *)subdev->of_node->full_name;
>>>
>>> Can subdev_name be made const instead of blindly casting the full_name
>>> pointer
>>> ? If not this is probably unsafe, and if yes it should be done :-)
>>>
> + vpif_dbg(2, debug,
> + "%s: setting input %d subdev_name =
> %s\n",
> + __func__, i, subdev->of_node
> ->full_name);
> + return 0;
> + }
> + }
> +
>for (i = 0; i < vpif_obj.config->subdev_count; i++)
>if (!strcmp(vpif_obj.config->subdev_info[i].name,
>subdev->name)) {
> @@ -1422,6 +1443,110 @@ static int vpif_async_complete(struct
> v4l2_async_notifier *notifier)
>return vpif_probe_complete();
> }
>
> +static struct vpif_capture_config *
> +vpif_capture_get_pdata(struct platform_device *pdev)
> +{
> + struct device_node *endpoint = NULL;
> + struct v4l2_of_endpoint bus_cfg;
> + struct vpif_capture_config *pdata;
> + struct vpif_subdev_info *sdinfo;
> + struct vpif_capture_chan_config *chan;
> + unsigned int i;
> +
>
Re: [PATCH] exynos-gsc: Clean up file handle in open() error path.
On Fri, Dec 02, 2016 at 10:15:27AM +0530, Shailendra Verma wrote: > The File handle is not yet added in the vfd list.So no need to call > v4l2_fh_del(&ctx->fh) if it fails to create control. > > Signed-off-by: Shailendra Verma > --- > drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I think I see this and exynos4-is patch for the third time... 1. sent in a very short time-frame (usually resending is after 2 weeks), 2. without any change log (should be after --- separator), 3. with different subjects (really...), 4. without versioning (use git format-patch -v2 etc). Please, keep it a little bit more organized... Look at examples on mailing lists how (and when) people are sending patches. Best regards, Krzysztof > > diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c > b/drivers/media/platform/exynos-gsc/gsc-m2m.c > index 9f03b79..5ea97c1 100644 > --- a/drivers/media/platform/exynos-gsc/gsc-m2m.c > +++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c > @@ -664,8 +664,8 @@ static int gsc_m2m_open(struct file *file) > > error_ctrls: > gsc_ctrls_delete(ctx); > -error_fh: > v4l2_fh_del(&ctx->fh); > +error_fh: > v4l2_fh_exit(&ctx->fh); > kfree(ctx); > unlock: > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/3] sound/usb: Use Media Controller API to share media resources
On Tue, 06 Dec 2016 19:41:37 +0100,
Shuah Khan wrote:
>
> Hi Takashi,
>
> On 12/05/2016 11:50 PM, Takashi Iwai wrote:
> > On Wed, 30 Nov 2016 23:01:16 +0100,
> > Shuah Khan wrote:
> >>
> >> --- a/sound/usb/card.c
> >> +++ b/sound/usb/card.c
> > (snip)
> >> @@ -616,6 +617,11 @@ static int usb_audio_probe(struct usb_interface *intf,
> >>if (err < 0)
> >>goto __error;
> >>
> >> + if (quirk && quirk->media_device) {
> >> + /* don't want to fail when media_snd_device_create() fails */
> >> + media_snd_device_create(chip, intf);
> >
> > Note that the usb-audio driver is probed for each usb interface, and
> > there are multiple interfaces per device. That is, usb_audio_probe()
> > may be called multiple times per device, and at the second or the
> > later calls, it appends the stuff onto the previously created card
> > object.
> >
> > So, you'd have to make this call also conditional (e.g. check
> > chip->num_interfaces == 0, indicating the very first one), or allow to
> > be called multiple times.
> >
> > In the former case, it'd be better to split media_snd_device_create()
> > and media_snd_mixer_init(). The *_device_create() needs to be called
> > only once, while *_mixer_init() still has to be called for each time
> > because the new mixer element may be added for each interface.
> >
>
> Thanks for the catch. I am able to fix this in media_snd_device_create()
> I made a change to do media_dev allocate only once. media_snd_mixer_init()
> will get called every time media_snd_device_create() is called. This way
> new mixers can be handled. media_snd_mixer_init() has logic to deal with
> mixers that are already initialized. We are good here with the following
> change:
>
> @@ -272,6 +258,14 @@ int media_snd_device_create(struct snd_usb_audio *chip,
> struct usb_device *usbdev = interface_to_usbdev(iface);
> int ret;
>
> + /* usb-audio driver is probed for each usb interface, and
> +* there are multiple interfaces per device. Avoid calling
> +* media_device_usb_allocate() each time usb_audio_probe()
> +* is called. Do it only once.
> +*/
> + if (chip->media_dev)
> + goto snd_mixer_init;
> +
> mdev = media_device_usb_allocate(usbdev, KBUILD_MODNAME);
> if (!mdev)
> return -ENOMEM;
> @@ -291,6 +285,7 @@ int media_snd_device_create(struct snd_usb_audio *chip,
> /* save media device - avoid lookups */
> chip->media_dev = mdev;
>
> +snd_mixer_init:
> /* Create media entities for mixer and control dev */
> ret = media_snd_mixer_init(chip);
> if (ret) {
This looks good enough, yes.
>
> >
> >> + }
> >> +
> >>usb_chip[chip->index] = chip;
> >>chip->num_interfaces++;
> >>usb_set_intfdata(intf, chip);
> >> @@ -672,6 +678,14 @@ static void usb_audio_disconnect(struct usb_interface
> >> *intf)
> >>list_for_each(p, &chip->midi_list) {
> >>snd_usbmidi_disconnect(p);
> >>}
> >> + /*
> >> + * Nice to check quirk && quirk->media_device and
> >> + * then call media_snd_device_delete(). Don't have
> >> + * access to quirk here. media_snd_device_delete()
> >> + * acceses mixer_list
> >> + */
> >> + media_snd_device_delete(chip);
> >
> > ... meanwhile this is OK, as it's called only once.
> >
> > (BTW, is it OK to call media_* stuff while the device is still in use?
> > The disconnect callback gets called for hot-unplug.)
> >
>
> Yes. All of the media_* functions that get called during run-time check for
> chip->media_dev or media_ctl and do nothing when these are null.
>
> media_device itself will not be free'd until all reference are gone. When
> usb_audio_disconnect() happens via unbind snd_usb_audio or physical remove,
> media_dev sticks around until au0828 (media driver) goes away. There is
> handling for any user apps. that have /dev/mediaX open.
>
> Does this sound correct? Did I miss any of your concerns?
That sounds all good, so it's safe to call there.
thanks,
Takashi
--
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 3/3] sound/usb: Use Media Controller API to share media resources
Hi Takashi,
On 12/05/2016 11:50 PM, Takashi Iwai wrote:
> On Wed, 30 Nov 2016 23:01:16 +0100,
> Shuah Khan wrote:
>>
>> --- a/sound/usb/card.c
>> +++ b/sound/usb/card.c
> (snip)
>> @@ -616,6 +617,11 @@ static int usb_audio_probe(struct usb_interface *intf,
>> if (err < 0)
>> goto __error;
>>
>> +if (quirk && quirk->media_device) {
>> +/* don't want to fail when media_snd_device_create() fails */
>> +media_snd_device_create(chip, intf);
>
> Note that the usb-audio driver is probed for each usb interface, and
> there are multiple interfaces per device. That is, usb_audio_probe()
> may be called multiple times per device, and at the second or the
> later calls, it appends the stuff onto the previously created card
> object.
>
> So, you'd have to make this call also conditional (e.g. check
> chip->num_interfaces == 0, indicating the very first one), or allow to
> be called multiple times.
>
> In the former case, it'd be better to split media_snd_device_create()
> and media_snd_mixer_init(). The *_device_create() needs to be called
> only once, while *_mixer_init() still has to be called for each time
> because the new mixer element may be added for each interface.
>
Thanks for the catch. I am able to fix this in media_snd_device_create()
I made a change to do media_dev allocate only once. media_snd_mixer_init()
will get called every time media_snd_device_create() is called. This way
new mixers can be handled. media_snd_mixer_init() has logic to deal with
mixers that are already initialized. We are good here with the following
change:
@@ -272,6 +258,14 @@ int media_snd_device_create(struct snd_usb_audio *chip,
struct usb_device *usbdev = interface_to_usbdev(iface);
int ret;
+ /* usb-audio driver is probed for each usb interface, and
+* there are multiple interfaces per device. Avoid calling
+* media_device_usb_allocate() each time usb_audio_probe()
+* is called. Do it only once.
+*/
+ if (chip->media_dev)
+ goto snd_mixer_init;
+
mdev = media_device_usb_allocate(usbdev, KBUILD_MODNAME);
if (!mdev)
return -ENOMEM;
@@ -291,6 +285,7 @@ int media_snd_device_create(struct snd_usb_audio *chip,
/* save media device - avoid lookups */
chip->media_dev = mdev;
+snd_mixer_init:
/* Create media entities for mixer and control dev */
ret = media_snd_mixer_init(chip);
if (ret) {
>
>> +}
>> +
>> usb_chip[chip->index] = chip;
>> chip->num_interfaces++;
>> usb_set_intfdata(intf, chip);
>> @@ -672,6 +678,14 @@ static void usb_audio_disconnect(struct usb_interface
>> *intf)
>> list_for_each(p, &chip->midi_list) {
>> snd_usbmidi_disconnect(p);
>> }
>> +/*
>> + * Nice to check quirk && quirk->media_device and
>> + * then call media_snd_device_delete(). Don't have
>> + * access to quirk here. media_snd_device_delete()
>> + * acceses mixer_list
>> + */
>> +media_snd_device_delete(chip);
>
> ... meanwhile this is OK, as it's called only once.
>
> (BTW, is it OK to call media_* stuff while the device is still in use?
> The disconnect callback gets called for hot-unplug.)
>
Yes. All of the media_* functions that get called during run-time check for
chip->media_dev or media_ctl and do nothing when these are null.
media_device itself will not be free'd until all reference are gone. When
usb_audio_disconnect() happens via unbind snd_usb_audio or physical remove,
media_dev sticks around until au0828 (media driver) goes away. There is
handling for any user apps. that have /dev/mediaX open.
Does this sound correct? Did I miss any of your concerns?
>
>> --- /dev/null
>> +++ b/sound/usb/media.c
> (snip)
>> +void media_snd_stream_delete(struct snd_usb_substream *subs)
>> +{
>> +struct media_ctl *mctl = subs->media_ctl;
>> +
>> +if (mctl && mctl->media_dev) {
>
> mctl->media_dev NULL check here is superfluous, as it's checked
> mctl->below.
>
Done.
>> +struct media_device *mdev;
>> +
>> +mdev = mctl->media_dev;
>> +if (mdev && media_devnode_is_registered(mdev->devnode)) {
>> +media_devnode_remove(mctl->intf_devnode);
>> +media_device_unregister_entity(&mctl->media_entity);
>> +media_entity_cleanup(&mctl->media_entity);
>> +}
>> +kfree(mctl);
>> +subs->media_ctl = NULL;
>> +}
>> +}
>> +
>> +int media_snd_start_pipeline(struct snd_usb_substream *subs)
>> +{
>> +struct media_ctl *mctl = subs->media_ctl;
>> +
>> +if (mctl)
>> +return media_snd_enable_source(mctl);
>> +return 0;
>> +}
>
> It's merely a wrapper, and media_snd_enable_source() itself checks
> NULL mctl. So we can replace media_snd_enable_source() with
> me
Re: [PATCH v3 3/4] [media] davinci: vpif_capture: get subdevs from DT
Hans Verkuil writes:
> On 12/01/2016 10:16 AM, Laurent Pinchart wrote:
>> Hello,
>>
>> On Thursday 01 Dec 2016 09:57:31 Sakari Ailus wrote:
>>> On Wed, Nov 30, 2016 at 04:14:11PM -0800, Kevin Hilman wrote:
Sakari Ailus writes:
> On Wed, Nov 23, 2016 at 03:25:32PM -0800, Kevin Hilman wrote:
>> Sakari Ailus writes:
>>> On Tue, Nov 22, 2016 at 07:52:43AM -0800, Kevin Hilman wrote:
Allow getting of subdevs from DT ports and endpoints.
The _get_pdata() function was larely inspired by (i.e. stolen from)
am437x-vpfe.c
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif_capture.c | 130 +++-
include/media/davinci/vpif_types.h
| 9 +-
2 files changed, 133 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c index
94ee6cf03f02..47a4699157e7 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -26,6 +26,8 @@
#include
#include
+#include
+#include
>>>
>>> Do you need this header?
>>
>> Yes, based on discussion with Hans, since there is no DT binding for
>> selecting the input pins of the TVP514x, I have to select it in the
>> driver, so I need the defines from this header. More on this below...
>>
>> That's really ugly :-( The problem should be fixed properly instead of
>> adding
>> one more offender.
>
> Do you have time for that, Laurent? I don't. Until that time we just need to
> make do with this workaround.
>
>>
#include "vpif.h"
#include "vpif_capture.h"
@@ -650,6 +652,10 @@ static int vpif_input_to_subdev(
vpif_dbg(2, debug, "vpif_input_to_subdev\n");
+ if (!chan_cfg)
+ return -1;
+ if (input_index >= chan_cfg->input_count)
+ return -1;
subdev_name = chan_cfg->inputs[input_index].subdev_name;
if (subdev_name == NULL)
return -1;
@@ -657,7 +663,7 @@ static int vpif_input_to_subdev(
/* loop through the sub device list to get the sub device info
*/
for (i = 0; i < vpif_cfg->subdev_count; i++) {
subdev_info = &vpif_cfg->subdev_info[i];
- if (!strcmp(subdev_info->name, subdev_name))
+ if (subdev_info && !strcmp(subdev_info->name,
subdev_name))
return i;
}
return -1;
@@ -1327,6 +1333,21 @@ static int vpif_async_bound(struct
v4l2_async_notifier *notifier,> >> >>
{
int i;
+ for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
+ struct v4l2_async_subdev *_asd = vpif_obj.config
->asd[i];
+ const struct device_node *node = _asd->match.of.node;
+
+ if (node == subdev->of_node) {
+ vpif_obj.sd[i] = subdev;
+ vpif_obj.config->chan_config
->inputs[i].subdev_name =
+ (char *)subdev->of_node->full_name;
>>
>> Can subdev_name be made const instead of blindly casting the full_name
>> pointer
>> ? If not this is probably unsafe, and if yes it should be done :-)
>>
+ vpif_dbg(2, debug,
+ "%s: setting input %d subdev_name =
%s\n",
+ __func__, i, subdev->of_node
->full_name);
+ return 0;
+ }
+ }
+
for (i = 0; i < vpif_obj.config->subdev_count; i++)
if (!strcmp(vpif_obj.config->subdev_info[i].name,
subdev->name)) {
@@ -1422,6 +1443,110 @@ static int vpif_async_complete(struct
v4l2_async_notifier *notifier)
return vpif_probe_complete();
}
+static struct vpif_capture_config *
+vpif_capture_get_pdata(struct platform_device *pdev)
+{
+ struct device_node *endpoint = NULL;
+ struct v4l2_of_endpoint bus_cfg;
+ struct vpif_capture_config *pdata;
+ struct vpif_subdev_info *sdinfo;
+ struct vpif_capture_chan_config *chan;
+ unsigned int i;
+
+ dev_dbg(&pdev->dev, "vpif_get_pdata\n");
+
+ if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
+ return pdev->d
Re: Enabling peer to peer device transactions for PCIe devices
On Tue, Dec 06, 2016 at 09:51:15AM -0700, Logan Gunthorpe wrote: > Hey, > > On 06/12/16 09:38 AM, Jason Gunthorpe wrote: > >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > >>> device-dax instance under the nvme device, or if you already have the nvme > >>> sysfs path the dax instance(s) will appear under the "dax" sub-directory. > >> > >> Personally I think mapping the dax resource in the sysfs tree is a nice > >> way to do this and a bit more intuitive than mapping a /dev/nvmeX. > > > > It is still not at all clear to me what userpsace is supposed to do > > with this on nvme.. How is the CMB usable from userspace? > > The flow is pretty simple. For example to write to NVMe from an RDMA device: > > 1) Obtain a chunk of the CMB to use as a buffer(either by mmaping > /dev/nvmx, the device dax char device or through a block layer interface > (which sounds like a good suggestion from Christoph, but I'm not really > sure how it would look). Okay, so clearly this needs a kernel side NVMe specific allocator and locking so users don't step on each other.. Or as Christoph says some kind of general mechanism to get these bounce buffers.. > 2) Create an MR with the buffer and use an RDMA function to fill it with > data from a remote host. This will cause the RDMA hardware to write > directly to the memory in the NVMe card. > > 3) Using O_DIRECT, write the buffer to a file on the NVMe filesystem. > When the address reaches hardware the NVMe will recognize it as local > memory and copy it directly there. Ah, I see. As a first draft I'd stick with some kind of API built into the /dev/nvmeX that backs the filesystem. The user app would fstat the target file, open /dev/block/MAJOR(st_dev):MINOR(st_dev), do some ioctl to get a CMB mmap, and then proceed from there.. When that is all working kernel-side, it would make sense to look at a more general mechanism that could be used unprivileged?? > Thus we are able to transfer data to any file on an NVMe device without > going through system memory. This has benefits on systems with lots of > activity in system memory but step 3 is likely to be slowish due to the > need to pin/unpin the memory for every transaction. This is similar to the GPU issues too.. On NVMe you don't need to pin the pages, you just need to lock that VMA so it doesn't get freed from the NVMe CMB allocator while the IO is running... Probably in the long run the get_user_pages is going to have to be pushed down into drivers.. Future MMU coherent IO hardware also does not need the pinning or other overheads. Jason -- 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: Enabling peer to peer device transactions for PCIe devices
On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote: > > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > > device-dax instance under the nvme device, or if you already have the nvme > > > sysfs path the dax instance(s) will appear under the "dax" sub-directory. > > > > Personally I think mapping the dax resource in the sysfs tree is a nice > > way to do this and a bit more intuitive than mapping a /dev/nvmeX. > > It is still not at all clear to me what userpsace is supposed to do > with this on nvme.. How is the CMB usable from userspace? I don't think trying to expose it to userspace makes any sense. Exposing it to in-kernel storage targets on the other hand makes a lot of sense. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
Laurent Pinchart writes: > Hi Kevin, > > Thank you for the patch. > > On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote: >> Video capture subdevs may be over I2C and may sleep during xfer, so we >> cannot do IRQ-disabled locking when calling the subdev. >> >> Signed-off-by: Kevin Hilman >> --- >> drivers/media/platform/davinci/vpif_capture.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> b/drivers/media/platform/davinci/vpif_capture.c index >> 5104cc0ee40e..9f8f41c0f251 100644 >> --- a/drivers/media/platform/davinci/vpif_capture.c >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue *vq, >> unsigned int count) } >> } >> >> +spin_unlock_irqrestore(&common->irqlock, flags); >> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1); >> +spin_lock_irqsave(&common->irqlock, flags); > > I always get anxious when I see a spinlock being released randomly with an > operation in the middle of a protected section. Looking at the code it looks > like the spinlock is abused here. irqlock should only protect the dma_queue > and should thus only be taken around the following code: > > spin_lock_irqsave(&common->irqlock, flags); > /* Get the next frame from the buffer queue */ > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next, > struct vpif_cap_buffer, list); > /* Remove buffer from the buffer queue */ > list_del(&common->cur_frm->list); > spin_unlock_irqrestore(&common->irqlock, flags); Yes, that looks correct. Will update. > The code that is currently protected by the lock in the start and stop > streaming functions should be protected by a mutex instead. I tried taking the mutex here, but lockdep pointed out a deadlock. I may not be fully understanding the V4L2 internals here, but it seems that the ioctl is already taking a mutex, so taking it again in start/stop streaming is a deadlock. Unless you think the locking should be nested here, it seems to me that the mutex isn't needed. Kevin -- 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: Enabling peer to peer device transactions for PCIe devices
Hey, On 06/12/16 09:38 AM, Jason Gunthorpe wrote: >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the >>> device-dax instance under the nvme device, or if you already have the nvme >>> sysfs path the dax instance(s) will appear under the "dax" sub-directory. >> >> Personally I think mapping the dax resource in the sysfs tree is a nice >> way to do this and a bit more intuitive than mapping a /dev/nvmeX. > > It is still not at all clear to me what userpsace is supposed to do > with this on nvme.. How is the CMB usable from userspace? The flow is pretty simple. For example to write to NVMe from an RDMA device: 1) Obtain a chunk of the CMB to use as a buffer(either by mmaping /dev/nvmx, the device dax char device or through a block layer interface (which sounds like a good suggestion from Christoph, but I'm not really sure how it would look). 2) Create an MR with the buffer and use an RDMA function to fill it with data from a remote host. This will cause the RDMA hardware to write directly to the memory in the NVMe card. 3) Using O_DIRECT, write the buffer to a file on the NVMe filesystem. When the address reaches hardware the NVMe will recognize it as local memory and copy it directly there. Thus we are able to transfer data to any file on an NVMe device without going through system memory. This has benefits on systems with lots of activity in system memory but step 3 is likely to be slowish due to the need to pin/unpin the memory for every transaction. Logan -- 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: Enabling peer to peer device transactions for PCIe devices
> > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > device-dax instance under the nvme device, or if you already have the nvme > > sysfs path the dax instance(s) will appear under the "dax" sub-directory. > > Personally I think mapping the dax resource in the sysfs tree is a nice > way to do this and a bit more intuitive than mapping a /dev/nvmeX. It is still not at all clear to me what userpsace is supposed to do with this on nvme.. How is the CMB usable from userspace? Jason -- 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 v2] uvcvideo : Add support for Intel SR300 depth camera
From: Aviv Greenberg
Add support for Intel SR300 depth camera formats in uvc driver.
This includes adding three uvc GUIDs for pixel formats
advertised by device, and their mapping to the proper FourCC definitions.
Signed-off-by: Aviv Greenberg
Signed-off-by: Evgeni Raikhel
---
drivers/media/usb/uvc/uvc_driver.c | 15 +++
drivers/media/usb/uvc/uvcvideo.h | 9 +
2 files changed, 24 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 04bf35063c4c..46d6be0bb316 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -188,6 +188,21 @@ static struct uvc_format_desc uvc_fmts[] = {
.guid = UVC_GUID_FORMAT_GR16,
.fcc= V4L2_PIX_FMT_SGRBG16,
},
+ {
+ .name = "Depth data 16-bit (Z16)",
+ .guid = UVC_GUID_FORMAT_INVZ,
+ .fcc= V4L2_PIX_FMT_Z16,
+ },
+ {
+ .name = "Greyscale 10-bit (Y10 )",
+ .guid = UVC_GUID_FORMAT_INVI,
+ .fcc= V4L2_PIX_FMT_Y10,
+ },
+ {
+ .name = "IR:Depth 26-bit (INZI)",
+ .guid = UVC_GUID_FORMAT_INZI,
+ .fcc= V4L2_PIX_FMT_INZI,
+ },
};
/*
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 3d6cc62f3cd2..672c4c96b767 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -143,6 +143,15 @@
#define UVC_GUID_FORMAT_RW10 \
{ 'R', 'W', '1', '0', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_INVZ \
+ { 'I', 'N', 'V', 'Z', 0x90, 0x2d, 0x58, 0x4a, \
+0x92, 0x0b, 0x77, 0x3f, 0x1f, 0x2c, 0x55, 0x6b}
+#define UVC_GUID_FORMAT_INZI \
+ { 'I', 'N', 'Z', 'I', 0x66, 0x1a, 0x42, 0xa2, \
+0x90, 0x65, 0xd0, 0x18, 0x14, 0xa8, 0xef, 0x8a}
+#define UVC_GUID_FORMAT_INVI \
+ { 'I', 'N', 'V', 'I', 0xdb, 0x57, 0x49, 0x5e, \
+0x8e, 0x3f, 0xf4, 0x79, 0x53, 0x2b, 0x94, 0x6f}
/*
* Driver specific constants.
--
2.7.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
Intel SR300 Depth Camera formats
Changelog for v2: 1. The patch has been rearranged, so instead of separation into "Code" and "Documentation" segments it is built around: - Adding new INZI format definition to V4L2_API - Adding support for SR300 camera formats. 2. Tables used in the documentation were reformatted to preserve line width -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] media: Adding 'INZI' Depth data format to V4L2_API.
From: Aviv Greenberg
This is a proprietary multi-plane format that provides
Infrared and Depth data.
The format is utilized by Intel SR300 depth camera.
The patch comprises of the format definition
to be introduced into V4L2_API via include/uapi/linux/videodev2.h,
and the pixel format description to be added to
Documentation/media/uapi/v4l folder, under 'depth-formats' section
Signed-off-by: Aviv Greenberg
Signed-off-by: Evgeni Raikhel
---
Documentation/media/uapi/v4l/depth-formats.rst | 1 +
Documentation/media/uapi/v4l/pixfmt-inzi.rst | 83 ++
include/uapi/linux/videodev2.h | 1 +
3 files changed, 85 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-inzi.rst
diff --git a/Documentation/media/uapi/v4l/depth-formats.rst
b/Documentation/media/uapi/v4l/depth-formats.rst
index 82f183870aae..c755be0e4d2a 100644
--- a/Documentation/media/uapi/v4l/depth-formats.rst
+++ b/Documentation/media/uapi/v4l/depth-formats.rst
@@ -13,3 +13,4 @@ Depth data provides distance to points, mapped onto the image
plane
:maxdepth: 1
pixfmt-z16
+pixfmt-inzi
diff --git a/Documentation/media/uapi/v4l/pixfmt-inzi.rst
b/Documentation/media/uapi/v4l/pixfmt-inzi.rst
new file mode 100644
index ..5adc2b679be4
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-inzi.rst
@@ -0,0 +1,83 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-INZI:
+
+**
+V4L2_PIX_FMT_INZI ('INZI')
+**
+
+Infrared 10-bit linked with Depth 16-bit images
+
+
+Description
+===
+
+Proprietary multi-planar format used by Intel SR300 Depth cameras, comprise of
+Infrared image followed by Depth data. The pixel definition is 32-bpp,
+with the Depth and Infrared Data split into separate continuous planes of
+identical dimensions.
+
+
+
+The first plane - Infrared data - is stored according to
+:ref:`V4L2_PIX_FMT_Y10 ` greyscale format.
+Each pixel is 16-bit cell, with actual data stored in the 10 LSBs
+with values in range 0 to 1023.
+The six remaining MSBs are padded with zeros.
+
+
+The second plane provides 16-bit per-pixel Depth data arranged in
+:ref:`V4L2-PIX-FMT-Z16 ` format.
+
+
+**Frame Structure.**
+Each cell is a 16-bit word with more significant data stored at higher
+memory address (byte order is little-endian).
+
+.. raw:: latex
+
+\newline\newline\begin{adjustbox}{width=\columnwidth}
+
+.. tabularcolumns:: |p{4.0cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 1
+:widths:1 1 1 1 1 1
+
+* - Ir\ :sub:`0,0`
+ - Ir\ :sub:`0,1`
+ - Ir\ :sub:`0,2`
+ - ...
+ - ...
+ - ...
+* - :cspan:`5` ...
+* - :cspan:`5` Infrared Data
+* - :cspan:`5` ...
+* - ...
+ - ...
+ - ...
+ - Ir\ :sub:`n-1,n-3`
+ - Ir\ :sub:`n-1,n-2`
+ - Ir\ :sub:`n-1,n-1`
+* - Depth\ :sub:`0,0`
+ - Depth\ :sub:`0,1`
+ - Depth\ :sub:`0,2`
+ - ...
+ - ...
+ - ...
+* - :cspan:`5` ...
+* - :cspan:`5` Depth Data
+* - :cspan:`5` ...
+* - ...
+ - ...
+ - ...
+ - Depth\ :sub:`n-1,n-3`
+ - Depth\ :sub:`n-1,n-2`
+ - Depth\ :sub:`n-1,n-1`
+
+.. raw:: latex
+
+\end{adjustbox}\newline\newline
+
+
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e369f9..04263c59b93f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -662,6 +662,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y12I v4l2_fourcc('Y', '1', '2', 'I') /* Greyscale
12-bit L/R interleaved */
#define V4L2_PIX_FMT_Z16 v4l2_fourcc('Z', '1', '6', ' ') /* Depth data
16-bit */
#define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek
compressed block mode */
+#define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel
Infrared 10-bit linked with Depth 16-bit */
/* SDR formats - used only for Software Defined Radio devices */
#define V4L2_SDR_FMT_CU8 v4l2_fourcc('C', 'U', '0', '8') /* IQ u8 */
--
2.7.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 3/3] uvcvideo: add a metadata device node
Hi Guennadi, On Tuesday 06 Dec 2016 11:39:22 Guennadi Liakhovetski wrote: > On Tue, 6 Dec 2016, Laurent Pinchart wrote: > > On Monday 05 Dec 2016 23:13:53 Guennadi Liakhovetski wrote: > >> On Tue, 6 Dec 2016, Laurent Pinchart wrote: > >> + /* > >> + * Register a metadata node. TODO: shall this only be enabled > >> for some > >> + * cameras? > >> + */ > >> + if (!(dev->quirks & UVC_QUIRK_BUILTIN_ISIGHT)) > >> + uvc_meta_register(stream); > >> + > > > > I think so, only for the cameras that can produce metadata. > > Every UVC camera produces metadata, but most cameras only have standard > fields there. Whether we should stream standard header fields from the > metadata node will be discussed later. If we do decide to stream > standard header fields, then every USB camera gets metadata nodes. If > we decide not to include standard fields, how do we know whether the > camera has any private fields in headers without streaming from it? Do > you want a quirk for such cameras? > >>> > >>> Unless they can be detected in a standard way that's probably the best > >>> solution. Please remember that the UVC specification doesn't allow > >>> vendors to extend headers in a vendor-specific way. > >> > >> Does it not? Where is that specified? I didn't find that anywhere. > > > > It's the other way around, it document a standard way to extend the > > payload header. Any option you pick risks being incompatible with future > > revisions of the specification. For instance the payload header's > > bmHeaderInfo field can be extended through the use of the EOF bit, but a > > future version of the specification could also extend it, in a way that > > would make a vendor-specific extension be mistaken for the standard > > extension. > > > > Now, you could add data after the standard payload without touching the > > bmHeaderInfo field, but I'm still worried it could be broken by future > > versions of the specification. > > Exactly - using "free" space in payload headers is not a part of the spec, > but is also not prohibited by it. As for future versions - cameras specify > which version of the spec they implement, and existing versions cannot > change. If a camera decides to upgrade and in future UVC versions there > won't be enough space left for the private data, only then the camera > manufacturer will have a problem, that they will have to solve. The > user-space software will have to know, that UVC 5.1 metadata has a > different format, than UVC 1.5, that's true. I agree that the specification doesn't explicitly forbid it, but it's a very grey area. An extension mechanism should be standardized by the USB-IF UVC working group. I'd propose it myself if they hadn't decided to kick me out years ago :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx broken 4.9.0-rc6+
Em Tue, 6 Dec 2016 01:06:17 +0200 Antti Palosaari escreveu: > Hello Mauro > I just noticed current em28xx driver seem to be broken. When I plug > device first time it loads correctly, but when I re-plug it, it does not > work anymore but yells a lot of noise to message log. Tested with PCTV > 290e and 292e both same. Other USB DVB devices are working so it is very > likely em28xx driver bug. > > Easy to reproduce: > plug device > unplug device > plug device Are you referring to those: [ 1010.310320] WARNING: CPU: 3 PID: 119 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x7b/0x90 [ 1010.310323] sysfs: cannot create duplicate filename '/bus/usb/devices/1-3.3' [ 1010.310325] Modules linked in: lgdt330x em28xx_dvb dvb_core em28xx_alsa tuner_xc2028 tuner tvp5150 em28xx_v4l videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core em28xx tveeprom v4l2_common videodev media xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables cmac bnep cpufreq_powersave cpufreq_conservative cpufreq_userspace binfmt_misc parport_pc ppdev lp parport snd_hda_codec_hdmi iTCO_wdt snd_hda_codec_realtek iTCO_vendor_support snd_hda_codec_generic arc4 intel_rapl x86_pkg_temp_thermal iwlmvm intel_powerclamp coretemp kvm_intel mac80211 kvm i915 [ 1010.310383] irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iwlwifi pl2303 aesni_intel btusb aes_x86_64 usbserial lrw btrtl gf128mul glue_helper btbcm ablk_helper cryptd btintel bluetooth drm_kms_helper cfg80211 drm psmouse pcspkr i2c_i801 e1000e serio_raw snd_hda_intel snd_soc_rt5640 snd_hda_codec snd_soc_rl6231 snd_soc_ssm4567 mei_me i2c_smbus rfkill snd_hda_core ptp mei snd_soc_core ehci_pci sg lpc_ich shpchp mfd_core ehci_hcd pps_core snd_hwdep i2c_algo_bit snd_compress snd_pcm sdhci_acpi snd_timer battery snd sdhci elan_i2c snd_soc_sst_acpi mmc_core fjes dw_dmac i2c_hid soundcore snd_soc_sst_match i2c_designware_platform video i2c_designware_core acpi_pad acpi_als kfifo_buf tpm_tis button industrialio tpm_tis_core tpm ext4 crc16 jbd2 fscrypto mbcache dm_mod joydev evdev hid_logitech_hidpp [ 1010.310449] sd_mod hid_logitech_dj usbhid hid ahci libahci crc32c_intel libata xhci_pci xhci_hcd scsi_mod usbcore fan thermal [ 1010.310464] CPU: 3 PID: 119 Comm: kworker/3:2 Not tainted 4.9.0-rc8+ #14 [ 1010.310466] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 [ 1010.310487] Workqueue: usb_hub_wq hub_event [usbcore] [ 1010.310490] 848f56c5 8803b1f7f858 [ 1010.310496] 8414f8f8 8803001f ed00763eff07 8803b1f7f8f0 [ 1010.310501] 8803b3ea1e60 0001 ffef 8803b45c6840 [ 1010.310505] Call Trace: [ 1010.310517] [] ? dump_stack+0x5c/0x77 [ 1010.310522] [] ? __warn+0x168/0x1a0 [ 1010.310526] [] ? warn_slowpath_fmt+0xb4/0xf0 [ 1010.310529] [] ? __warn+0x1a0/0x1a0 [ 1010.310534] [] ? kasan_kmalloc+0xa6/0xd0 [ 1010.310539] [] ? kernfs_path_from_node+0x4a/0x60 [ 1010.310543] [] ? sysfs_warn_dup+0x7b/0x90 [ 1010.310547] [] ? sysfs_do_create_link_sd.isra.2+0xb6/0xd0 [ 1010.310553] [] ? bus_add_device+0x318/0x6b0 [ 1010.310557] [] ? sysfs_create_groups+0x83/0x110 [ 1010.310562] [] ? device_add+0x777/0x1350 [ 1010.310567] [] ? device_private_init+0x180/0x180 [ 1010.310583] [] ? usb_new_device+0x707/0x1030 [usbcore] [ 1010.310598] [] ? hub_event+0x1d65/0x3280 [usbcore] [ 1010.310604] [] ? account_entity_dequeue+0x30b/0x4a0 [ 1010.310618] [] ? hub_port_debounce+0x280/0x280 [usbcore] [ 1010.310624] [] ? compat_start_thread+0x80/0x80 [ 1010.310629] [] ? __schedule+0x704/0x1770 [ 1010.310633] [] ? io_schedule_timeout+0x390/0x390 [ 1010.310638] [] ? cache_reap+0x173/0x200 [ 1010.310642] [] ? process_one_work+0x4ed/0xe60 [ 1010.310646] [] ? worker_thread+0xe2/0xfd0 [ 1010.310650] [] ? __wake_up_common+0xbc/0x160 [ 1010.310654] [] ? process_one_work+0xe60/0xe60 [ 1010.310658] [] ? kthread+0x1cc/0x220 [ 1010.310663] [] ? kthread_park+0x80/0x80 [ 1010.310667] [] ? kthread_park+0x80/0x80 [ 1010.310671] [] ? kthread_park+0x80/0x80 [ 1010.310675] [] ? ret_from_fork+0x25/0x30 [ 1010.310698] ---[ end trace 49b46eb633ff1197 ]--- [ 1010.311298] usb 1-3.3: can't device_add, error -17 [ 1010.390703] usb 1-3.3: new high-speed USB device number 9 using xhci_hcd [ 1010.496337] usb 1-3.3: New USB device found, idVendor=2040, idProduct=6513 [ 1010.496343] usb 1-3.3: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 1010.496345] usb 1-3.3: Product: WinTV HVR-980 [ 1010.496347] usb 1-3.3: SerialNumber: 4028449018 [ 1010.497259] [ cut here ] [ 1010.497264] WARNING: CPU: 3 PID: 119 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x7b/0x90 [ 1010.497266] sysfs: cannot
[PATCH for v4.10] cec: fix report_current_latency
In the (very) small print of the REPORT_CURRENT_LATENCY message there is a
line that says that the last byte of the message (audio out delay) is only
present if the 'audio out compensated' value is 3.
I missed this, and so if this message was sent with a total length of 6
(i.e.
without the audio out delay byte), then it was rejected by the framework
since a minimum length of 7 was expected.
Fix this minimum length check and update wrappers in cec-funcs.h to do the
right thing based on the message length.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 2 +-
include/uapi/linux/cec-funcs.h | 10 +++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 0ea4efb..f15f6ff 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -851,7 +851,7 @@ static const u8 cec_msg_size[256] = {
[CEC_MSG_REQUEST_ARC_TERMINATION] = 2 | DIRECTED,
[CEC_MSG_TERMINATE_ARC] = 2 | DIRECTED,
[CEC_MSG_REQUEST_CURRENT_LATENCY] = 4 | BCAST,
- [CEC_MSG_REPORT_CURRENT_LATENCY] = 7 | BCAST,
+ [CEC_MSG_REPORT_CURRENT_LATENCY] = 6 | BCAST,
[CEC_MSG_CDC_MESSAGE] = 2 | BCAST,
};
diff --git a/include/uapi/linux/cec-funcs.h b/include/uapi/linux/cec-funcs.h
index 3cbc327..c451eec 100644
--- a/include/uapi/linux/cec-funcs.h
+++ b/include/uapi/linux/cec-funcs.h
@@ -1665,14 +1665,15 @@ static inline void
cec_msg_report_current_latency(struct cec_msg *msg,
__u8 audio_out_compensated,
__u8 audio_out_delay)
{
- msg->len = 7;
+ msg->len = 6;
msg->msg[0] |= 0xf; /* broadcast */
msg->msg[1] = CEC_MSG_REPORT_CURRENT_LATENCY;
msg->msg[2] = phys_addr >> 8;
msg->msg[3] = phys_addr & 0xff;
msg->msg[4] = video_latency;
msg->msg[5] = (low_latency_mode << 2) | audio_out_compensated;
- msg->msg[6] = audio_out_delay;
+ if (audio_out_compensated == 3)
+ msg->msg[msg->len++] = audio_out_delay;
}
static inline void cec_ops_report_current_latency(const struct cec_msg
*msg,
@@ -1686,7 +1687,10 @@ static inline void
cec_ops_report_current_latency(const struct cec_msg *msg,
*video_latency = msg->msg[4];
*low_latency_mode = (msg->msg[5] >> 2) & 1;
*audio_out_compensated = msg->msg[5] & 3;
- *audio_out_delay = msg->msg[6];
+ if (*audio_out_compensated == 3 && msg->len >= 7)
+ *audio_out_delay = msg->msg[6];
+ else
+ *audio_out_delay = 0;
}
static inline void cec_msg_request_current_latency(struct cec_msg *msg,
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/3] sound/usb: Use Media Controller API to share media resources
Hi Shuah, On Monday 05 Dec 2016 17:38:23 Shuah Khan wrote: > On 12/05/2016 04:21 PM, Laurent Pinchart wrote: > > On Monday 05 Dec 2016 15:44:30 Shuah Khan wrote: > >> On 11/30/2016 03:01 PM, Shuah Khan wrote: > >>> Change ALSA driver to use Media Controller API to share media resources > >>> with DVB, and V4L2 drivers on a AU0828 media device. > >>> > >>> Media Controller specific initialization is done after sound card is > >>> registered. ALSA creates Media interface and entity function graph > >>> nodes for Control, Mixer, PCM Playback, and PCM Capture devices. > >>> > >>> snd_usb_hw_params() will call Media Controller enable source handler > >>> interface to request the media resource. If resource request is granted, > >>> it will release it from snd_usb_hw_free(). If resource is busy, -EBUSY > >>> is returned. > >>> > >>> Media specific cleanup is done in usb_audio_disconnect(). > >>> > >>> Signed-off-by: Shuah Khan > >> > >> Hi Takashi, > >> > >> If you are good with this patch, could you please Ack it, so Mauro > >> can pull it into media tree with the other two patches in this series, > >> when he is ready to do so. > > > > I *really* want to address the concerns raised by Sakari before pulling > > more code that makes fixing the race conditions more difficult. Please, > > let's all work on fixing the core code to build a stable base on which we > > can build additional features. V4L2 and MC need teamwork, it's time to > > give the subsystem the love it deserves. > > Hi Laurent, > > The issue Sakari brought up is specific to using devm for video_device in > omap3 and vsp1. I tried reproducing the problem on two different drivers > and couldn't on Linux 4.9-rc7. > > After sharing that with Sakari, I suggested to Sakari to pull up his patch > that removes the devm usage and see if he still needs all the patches in his > patch series. He didn't back to me on that. I also requested him to rebase > on top of media dev allocator because the allocator routines he has don't > address the shared media device need. > > He also didn't respond to my response regarding the reasons for choosing > graph_mutex to protect enable_source and disable_source handlers. > > So I am not sure how to move forward at the moment without a concrete plan > for Sakari's RFC series. Sakari's patch series is still RFC and doesn't > address shared media_device and requires all drivers to change. Today is a public holiday in Finland, I don't expect Sakari to be available. Let's check this with him tomorrow. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] stk1160: Add module param for setting the record gain.
Em Mon, 5 Dec 2016 22:06:59 +0100 Marcel Hasler escreveu: > Hello > > 2016-12-05 16:38 GMT+01:00 Ezequiel Garcia : > > On 5 December 2016 at 09:12, Mauro Carvalho Chehab > > wrote: > >> Em Sun, 4 Dec 2016 15:25:25 -0300 > >> Ezequiel Garcia escreveu: > >> > >>> On 4 December 2016 at 10:01, Marcel Hasler wrote: > >>> > Hello > >>> > > >>> > 2016-12-03 21:46 GMT+01:00 Ezequiel Garcia > >>> > : > >>> >> On 2 December 2016 at 08:05, Mauro Carvalho Chehab > >>> >> wrote: > >>> >>> Em Sun, 27 Nov 2016 12:11:48 +0100 > >>> >>> Marcel Hasler escreveu: > >>> >>> > >>> Allow setting a custom record gain for the internal AC97 codec (if > >>> available). This can be > >>> a value between 0 and 15, 8 is the default and should be suitable > >>> for most users. The Windows > >>> driver also sets this to 8 without any possibility for changing it. > >>> >>> > >>> >>> The problem of removing the mixer is that you need this kind of > >>> >>> crap to setup the volumes on a non-standard way. > >>> >>> > >>> >> > >>> >> Right, that's a good point. > >>> >> > >>> >>> NACK. > >>> >>> > >>> >>> Instead, keep the alsa mixer. The way other drivers do (for example, > >>> >>> em28xx) is that they configure the mixer when an input is selected, > >>> >>> increasing the volume of the active audio channel to 100% and muting > >>> >>> the other audio channels. Yet, as the alsa mixer is exported, users > >>> >>> can change the mixer settings in runtime using some alsa (or pa) > >>> >>> mixer application. > >>> >>> > >>> >> > >>> >> Yeah, the AC97 mixer we are currently leveraging > >>> >> exposes many controls that have no meaning in this device, > >>> >> so removing that still looks like an improvement. > >>> >> > >>> >> I guess the proper way is creating our own mixer > >>> >> (not using snd_ac97_mixer) exposing only the record > >>> >> gain knob. > >>> >> > >>> >> Marcel, what do you think? > >>> >> -- > >>> >> Ezequiel García, VanguardiaSur > >>> >> www.vanguardiasur.com.ar > >>> > > >>> > As I have written before, the recording gain isn't actually meant to > >>> > be changed by the user. In the official Windows driver this value is > >>> > hard-coded to 8 and cannot be changed in any way. And there really is > >>> > no good reason why anyone should need to mess with it in the first > >>> > place. The default value will give the best results in pretty much all > >>> > cases and produces approximately the same volume as the internal 8-bit > >>> > ADC whose gain cannot be changed at all, not even by a driver. > >>> > > >>> > I had considered writing a mixer but chose not to. If the gain setting > >>> > is openly exposed to mixer applications, how do you tell the users > >>> > that the value set by the driver already is the optimal and > >>> > recommended value and that they shouldn't mess with the controls > >>> > unless they really have to? By having a module parameter, this setting > >>> > is practically hidden from the normal user but still is available to > >>> > power-users if they think they really need it. In the end it's really > >>> > just a compromise between hiding it completely and exposing it openly. > >>> > Also, this way the driver guarantees reproducible results, since > >>> > there's no need to remember the positions of any volume sliders. > >>> > > >>> > >>> Hm, right. I've never changed the record gain, and it's true that it > >>> doens't really improve the volume. So, I would be OK with having > >>> a module parameter. > >>> > >>> On the other side, we are exposing it currently, through the "Capture" > >>> mixer control: > >>> > >>> Simple mixer control 'Capture',0 > >>> Capabilities: cvolume cswitch cswitch-joined > >>> Capture channels: Front Left - Front Right > >>> Limits: Capture 0 - 15 > >>> Front Left: Capture 10 [67%] [15.00dB] [on] > >>> Front Right: Capture 8 [53%] [12.00dB] [on] > >>> > >>> So, it would be user-friendly to keep the user interface and continue > >>> to expose the same knob - even if the default is the optimal, etc. > >>> > >>> To be completely honest, I don't think any user is really relying > >>> on any REC_GAIN / Capture setting, and I'm completely OK > >>> with having a mixer control or a module parameter. It doesn't matter. > >> > >> If you're positive that *all* stk1160 use the ac97 mixer the > >> same way, and that there's no sense on having a mixer for it, > >> then it would be ok to remove it. > >> > > > > Let's remove it then! > > > >> In such case, then why you need a modprobe parameter to allow > >> setting the record level? If this mixer entry is not used, > >> just set it to zero and be happy with that. > >> > > > > Let's remove the module param too, then. > > I'm okay with that. > > > > > Thanks, > > -- > > Ezequiel García, VanguardiaSur > > www.vanguardiasur.com.ar > > I'm willing to prepare one final patchset, provided we can agree on > and resolve all issues beforehand. > > So far the chang
Re: [PATCH v2] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay
(resending, hopefully now it reaches the mailing lists)
On 12/05/2016 11:09 AM, Javi Merino wrote:
> Each time the overlay is applied, its of_node pointer will be
> different. We are not interested in matching the pointer, what we
> want to match is that the path is the one we are expecting. Change to
> use of_node_cmp() so that we continue matching after the overlay has
> been removed and reapplied.
>
> Signed-off-by: Javi Merino
Thanks, there is clearly a bug in current code as it assumed static
representation of DT in the kernel.
Reviewed-by: Sylwester Nawrocki
> ---
> drivers/media/v4l2-core/v4l2-async.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> b/drivers/media/v4l2-core/v4l2-async.c
> index 5bada20..d33a17c 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -42,7 +42,8 @@ static bool match_devname(struct v4l2_subdev *sd,
>
> static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> {
> - return sd->of_node == asd->match.of.node;
> + return !of_node_cmp(of_node_full_name(sd->of_node),
> + of_node_full_name(asd->match.of.node));
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] uvcvideo: add a metadata device node
Hi Laurent, On Tue, 6 Dec 2016, Laurent Pinchart wrote: > Hi Guennadi, > > On Monday 05 Dec 2016 23:13:53 Guennadi Liakhovetski wrote: > > Just one question: > > > > On Tue, 6 Dec 2016, Laurent Pinchart wrote: > > + /* > > + * Register a metadata node. TODO: shall this only be enabled > > for some > > + * cameras? > > + */ > > + if (!(dev->quirks & UVC_QUIRK_BUILTIN_ISIGHT)) > > + uvc_meta_register(stream); > > + > > >>> > > >>> I think so, only for the cameras that can produce metadata. > > >> > > >> Every UVC camera produces metadata, but most cameras only have standard > > >> fields there. Whether we should stream standard header fields from the > > >> metadata node will be discussed later. If we do decide to stream > > >> standard header fields, then every USB camera gets metadata nodes. If we > > >> decide not to include standard fields, how do we know whether the camera > > >> has any private fields in headers without streaming from it? Do you want > > >> a quirk for such cameras? > > > > > > Unless they can be detected in a standard way that's probably the best > > > solution. Please remember that the UVC specification doesn't allow vendors > > > to extend headers in a vendor-specific way. > > > > Does it not? Where is that specified? I didn't find that anywhere. > > It's the other way around, it document a standard way to extend the payload > header. Any option you pick risks being incompatible with future revisions of > the specification. For instance the payload header's bmHeaderInfo field can > be > extended through the use of the EOF bit, but a future version of the > specification could also extend it, in a way that would make a > vendor-specific > extension be mistaken for the standard extension. > > Now, you could add data after the standard payload without touching the > bmHeaderInfo field, but I'm still worried it could be broken by future > versions of the specification. Exactly - using "free" space in payload headers is not a part of the spec, but is also not prohibited by it. As for future versions - cameras specify which version of the spec they implement, and existing versions cannot change. If a camera decides to upgrade and in future UVC versions there won't be enough space left for the private data, only then the camera manufacturer will have a problem, that they will have to solve. The user-space software will have to know, that UVC 5.1 metadata has a different format, than UVC 1.5, that's true. 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
[PATCH 1/3] tc358743: Do not read number of CSI lanes in use from chip
From: Mats Randgaard
The number of CSI lanes that should be used is set to the CSI_CONTROL
register by indirectly writing to the CSI_CONFW register. When the
number of lanes is read back from the CSI_CONTROL register the value
is usually correct, but we have seen that it suddenly is 1 for a short
moment before the correct value is restored again.
Toshiba have not figured out why that happen, but we have found it
safer to store the value in the driver.
Signed-off-by: Mats Randgaard
---
drivers/media/i2c/tc358743.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 1e3a0dd2..a35aaf8 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -96,6 +96,7 @@ struct tc358743_state {
struct v4l2_dv_timings timings;
u32 mbus_fmt_code;
+ u8 csi_lanes_in_use;
struct gpio_desc *reset_gpio;
};
@@ -287,11 +288,6 @@ static int get_audio_sampling_rate(struct v4l2_subdev *sd)
return code_to_rate[i2c_rd8(sd, FS_SET) & MASK_FS];
}
-static unsigned tc358743_num_csi_lanes_in_use(struct v4l2_subdev *sd)
-{
- return ((i2c_rd32(sd, CSI_CONTROL) & MASK_NOL) >> 1) + 1;
-}
-
/* --- TIMINGS --- */
static inline unsigned fps(const struct v4l2_bt_timings *t)
@@ -683,6 +679,8 @@ static void tc358743_set_csi(struct v4l2_subdev *sd)
v4l2_dbg(3, debug, sd, "%s:\n", __func__);
+ state->csi_lanes_in_use = lanes;
+
tc358743_reset(sd, MASK_CTXRST);
if (lanes < 1)
@@ -1155,7 +1153,7 @@ static int tc358743_log_status(struct v4l2_subdev *sd)
v4l2_info(sd, "Lanes needed: %d\n",
tc358743_num_csi_lanes_needed(sd));
v4l2_info(sd, "Lanes in use: %d\n",
- tc358743_num_csi_lanes_in_use(sd));
+ state->csi_lanes_in_use);
v4l2_info(sd, "Waiting for particular sync signal: %s\n",
(i2c_rd16(sd, CSI_STATUS) & MASK_S_WSYNC) ?
"yes" : "no");
@@ -1438,12 +1436,14 @@ static int tc358743_dv_timings_cap(struct v4l2_subdev
*sd,
static int tc358743_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
+ struct tc358743_state *state = to_state(sd);
+
cfg->type = V4L2_MBUS_CSI2;
/* Support for non-continuous CSI-2 clock is missing in the driver */
cfg->flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
- switch (tc358743_num_csi_lanes_in_use(sd)) {
+ switch (state->csi_lanes_in_use) {
case 1:
cfg->flags |= V4L2_MBUS_CSI2_1_LANE;
break;
--
2.7.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/3] tc358743: Disable HDCP with "manual HDCP authentication" bit
From: Mats Randgaard
Originally Toshiba told us that the only way to disable HDCP was to
set the receiver in repeater mode, that would make the authentication
fail because of missing software support. It has worked fine with all
the sources we and our customers has used, until it was reported
problems with Apple MacBook (Retina, 12-inch, Early 2015)
(https://support.apple.com/kb/SP712?locale=en_US&viewlocale=en_US)
with Apple A1612 USB type-C multiport adapter
(http://www.apple.com/shop/product/MJ1K2AM/A/usb-c-digital-av-multiport-adapter)
Finally Toshiba came up with a hidden bit that is named "Manual HDCP
authentication". In this patch the original "repeater mode" concept is
removed, and the new bit is set instead.
With his patch HDCP is disabled when connected to the Apple MacBook
and all other sources we have tested so far. The Apple MacBook is
constantly trying to authenticate, but fails and continues to transmit
unencrypted video.
Signed-off-by: Mats Randgaard
---
drivers/media/i2c/tc358743.c | 32
drivers/media/i2c/tc358743_regs.h | 1 +
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index a35aaf8..257969a 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -368,29 +368,21 @@ static void tc358743_set_hdmi_hdcp(struct v4l2_subdev
*sd, bool enable)
v4l2_dbg(2, debug, sd, "%s: %s\n", __func__, enable ?
"enable" : "disable");
- i2c_wr8_and_or(sd, HDCP_REG1,
- ~(MASK_AUTH_UNAUTH_SEL | MASK_AUTH_UNAUTH),
- MASK_AUTH_UNAUTH_SEL_16_FRAMES | MASK_AUTH_UNAUTH_AUTO);
+ if (enable) {
+ i2c_wr8_and_or(sd, HDCP_REG3, ~KEY_RD_CMD, KEY_RD_CMD);
- i2c_wr8_and_or(sd, HDCP_REG2, ~MASK_AUTO_P3_RESET,
- SET_AUTO_P3_RESET_FRAMES(0x0f));
+ i2c_wr8_and_or(sd, HDCP_MODE, ~MASK_MANUAL_AUTHENTICATION, 0);
- /* HDCP is disabled by configuring the receiver as HDCP repeater. The
-* repeater mode require software support to work, so HDCP
-* authentication will fail.
-*/
- i2c_wr8_and_or(sd, HDCP_REG3, ~KEY_RD_CMD, enable ? KEY_RD_CMD : 0);
- i2c_wr8_and_or(sd, HDCP_MODE, ~(MASK_AUTO_CLR | MASK_MODE_RST_TN),
- enable ? (MASK_AUTO_CLR | MASK_MODE_RST_TN) : 0);
+ i2c_wr8_and_or(sd, HDCP_REG1, 0xff,
+ MASK_AUTH_UNAUTH_SEL_16_FRAMES |
+ MASK_AUTH_UNAUTH_AUTO);
- /* Apple MacBook Pro gen.8 has a bug that makes it freeze every fifth
-* second when HDCP is disabled, but the MAX_EXCED bit is handled
-* correctly and HDCP is disabled on the HDMI output.
-*/
- i2c_wr8_and_or(sd, BSTATUS1, ~MASK_MAX_EXCED,
- enable ? 0 : MASK_MAX_EXCED);
- i2c_wr8_and_or(sd, BCAPS, ~(MASK_REPEATER | MASK_READY),
- enable ? 0 : MASK_REPEATER | MASK_READY);
+ i2c_wr8_and_or(sd, HDCP_REG2, ~MASK_AUTO_P3_RESET,
+ SET_AUTO_P3_RESET_FRAMES(0x0f));
+ } else {
+ i2c_wr8_and_or(sd, HDCP_MODE, ~MASK_MANUAL_AUTHENTICATION,
+ MASK_MANUAL_AUTHENTICATION);
+ }
}
static void tc358743_disable_edid(struct v4l2_subdev *sd)
diff --git a/drivers/media/i2c/tc358743_regs.h
b/drivers/media/i2c/tc358743_regs.h
index 81f1db5..657ef50 100644
--- a/drivers/media/i2c/tc358743_regs.h
+++ b/drivers/media/i2c/tc358743_regs.h
@@ -420,6 +420,7 @@
#define MASK_MODE_RST_TN 0x20
#define MASK_LINE_REKEY 0x10
#define MASK_AUTO_CLR 0x04
+#define MASK_MANUAL_AUTHENTICATION0x02 /* Not in REF_01 */
#define HDCP_REG1 0x8563 /* Not in REF_01 */
#define MASK_AUTH_UNAUTH_SEL 0x70
--
2.7.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 3/3] tc358743: ctrl_detect_tx_5v should always be updated
From: Mats Randgaard
The control for +5V Power detection must also be updated when the EDID is
not present.
Signed-off-by: Mats Randgaard
---
drivers/media/i2c/tc358743.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 257969a..f569a05 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -404,6 +404,7 @@ static void tc358743_enable_edid(struct v4l2_subdev *sd)
if (state->edid_blocks_written == 0) {
v4l2_dbg(2, debug, sd, "%s: no EDID -> no hotplug\n", __func__);
+ tc358743_s_ctrl_detect_tx_5v(sd);
return;
}
--
2.7.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 v4 09/13] [media] rc: ir-rc6-decoder: Add encode capability
From: Antti Seppälä
Add the capability to encode RC-6 and RC-6A scancodes as raw events.
The protocol is chosen based on the specified protocol mask, and
whether all the required bits are set in the scancode mask, and none of
the unused bits are set in the scancode data.
The Manchester modulation helper is used several times with various
timings so that RC-6 header preamble, the header, header trailing bit
and the data itself can be modulated correctly.
Signed-off-by: Antti Seppälä
Signed-off-by: Sean Young
Cc: James Hogan
Cc: David Härdeman
---
drivers/media/rc/ir-rc6-decoder.c | 120 ++
1 file changed, 120 insertions(+)
diff --git a/drivers/media/rc/ir-rc6-decoder.c
b/drivers/media/rc/ir-rc6-decoder.c
index 5cc54c9..3667ca2 100644
--- a/drivers/media/rc/ir-rc6-decoder.c
+++ b/drivers/media/rc/ir-rc6-decoder.c
@@ -286,11 +286,131 @@ static int ir_rc6_decode(struct rc_dev *dev, struct
ir_raw_event ev)
return -EINVAL;
}
+static struct ir_raw_timings_manchester ir_rc6_timings[4] = {
+ {
+ .leader = RC6_PREFIX_PULSE,
+ .pulse_space_start = 0,
+ .clock = RC6_UNIT,
+ .invert = 1,
+ .trailer_space = RC6_PREFIX_SPACE,
+ },
+ {
+ .clock = RC6_UNIT,
+ .invert = 1,
+ },
+ {
+ .clock = RC6_UNIT * 2,
+ .invert = 1,
+ },
+ {
+ .clock = RC6_UNIT,
+ .invert = 1,
+ .trailer_space = RC6_SUFFIX_SPACE,
+ },
+};
+
+static int ir_rc6_validate_filter(const struct rc_scancode_filter *scancode,
+ unsigned int important_bits)
+{
+ /* all important bits of scancode should be set in mask */
+ if (~scancode->mask & important_bits)
+ return -EINVAL;
+ /* extra bits in mask should be zero in data */
+ if (scancode->mask & scancode->data & ~important_bits)
+ return -EINVAL;
+ return 0;
+}
+
+/**
+ * ir_rc6_encode() - Encode a scancode as a stream of raw events
+ *
+ * @protocol: protocol to encode
+ * @scancode: scancode filter describing scancode (helps distinguish between
+ * protocol subtypes when scancode is ambiguous)
+ * @events:array of raw ir events to write into
+ * @max: maximum size of @events
+ *
+ * Returns:The number of events written.
+ * -ENOBUFS if there isn't enough space in the array to fit the
+ * encoding. In this case all @max events will have been written.
+ * -EINVAL if the scancode is ambiguous or invalid.
+ */
+static int ir_rc6_encode(enum rc_type protocol,
+const struct rc_scancode_filter *scancode,
+struct ir_raw_event *events, unsigned int max)
+{
+ int ret;
+ struct ir_raw_event *e = events;
+
+ if (protocol == RC_TYPE_RC6_0 &&
+ !ir_rc6_validate_filter(scancode, 0x)) {
+
+ /* Modulate the preamble */
+ ret = ir_raw_gen_manchester(&e, max, &ir_rc6_timings[0], 0, 0);
+ if (ret < 0)
+ return ret;
+
+ /* Modulate the header (Start Bit & Mode-0) */
+ ret = ir_raw_gen_manchester(&e, max - (e - events),
+ &ir_rc6_timings[1],
+ RC6_HEADER_NBITS, (1 << 3));
+ if (ret < 0)
+ return ret;
+
+ /* Modulate Trailer Bit */
+ ret = ir_raw_gen_manchester(&e, max - (e - events),
+ &ir_rc6_timings[2], 1, 0);
+ if (ret < 0)
+ return ret;
+
+ /* Modulate rest of the data */
+ ret = ir_raw_gen_manchester(&e, max - (e - events),
+ &ir_rc6_timings[3], RC6_0_NBITS,
+ scancode->data);
+ if (ret < 0)
+ return ret;
+
+ } else if (!ir_rc6_validate_filter(scancode, 0x8fff)) {
+
+ /* Modulate the preamble */
+ ret = ir_raw_gen_manchester(&e, max, &ir_rc6_timings[0], 0, 0);
+ if (ret < 0)
+ return ret;
+
+ /* Modulate the header (Start Bit & Header-version 6 */
+ ret = ir_raw_gen_manchester(&e, max - (e - events),
+ &ir_rc6_timings[1],
+ RC6_HEADER_NBITS, (1 << 3 | 6));
+ if (ret < 0)
+ return ret;
+
+ /* Modulate Trailer Bit */
+ ret = ir_raw_gen_manchester(&e, max -
[PATCH v4 12/13] [media] rc: rc-loopback: Add loopback of filter scancodes
From: James Hogan
Add the s_wakeup_filter callback to the rc-loopback driver, which instead
of setting the filter just feeds the scancode back through the input
device so that it can be verified.
Signed-off-by: James Hogan
Signed-off-by: Antti Seppälä
Signed-off-by: Sean Young
Cc: David Härdeman
---
drivers/media/rc/rc-loopback.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index 4bc3f01..487214e 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#define DRIVER_NAME"rc-loopback"
@@ -176,6 +177,41 @@ static int loop_set_carrier_report(struct rc_dev *dev, int
enable)
return 0;
}
+static int loop_set_wakeup_filter(struct rc_dev *dev,
+ struct rc_scancode_filter *sc_filter)
+{
+ static const unsigned int max = 512;
+ struct ir_raw_event *raw;
+ int ret;
+ int i;
+
+ /* fine to disable filter */
+ if (!sc_filter->mask)
+ return 0;
+
+ /* encode the specified filter and loop it back */
+ raw = kmalloc_array(max, sizeof(*raw), GFP_KERNEL);
+ if (!raw)
+ return -ENOMEM;
+
+ ret = ir_raw_encode_scancode(dev->wakeup_protocol, sc_filter, raw, max);
+ /* still loop back the partial raw IR even if it's incomplete */
+ if (ret == -ENOBUFS)
+ ret = max;
+ if (ret >= 0) {
+ /* do the loopback */
+ for (i = 0; i < ret; ++i)
+ ir_raw_event_store(dev, &raw[i]);
+ ir_raw_event_handle(dev);
+
+ ret = 0;
+ }
+
+ kfree(raw);
+
+ return ret;
+}
+
static int __init loop_init(void)
{
struct rc_dev *rc;
@@ -195,6 +231,7 @@ static int __init loop_init(void)
rc->map_name= RC_MAP_EMPTY;
rc->priv= &loopdev;
rc->driver_type = RC_DRIVER_IR_RAW;
+ rc->encode_wakeup = true;
rc->allowed_protocols = RC_BIT_ALL_IR_DECODER;
rc->timeout = 100 * 1000 * 1000; /* 100 ms */
rc->min_timeout = 1;
@@ -209,6 +246,7 @@ static int __init loop_init(void)
rc->s_idle = loop_set_idle;
rc->s_learning_mode = loop_set_learning_mode;
rc->s_carrier_report= loop_set_carrier_report;
+ rc->s_wakeup_filter = loop_set_wakeup_filter;
loopdev.txmask = RXMASK_REGULAR;
loopdev.txcarrier = 36000;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/13] [media] rc: rc-ir-raw: Add pulse-distance modulation helper
From: James Hogan
Add IR encoding helper for pulse-distance modulation as used by the NEC
protocol.
Signed-off-by: James Hogan
Signed-off-by: Sean Young
Cc: Antti Seppälä
Cc: David Härdeman
---
drivers/media/rc/rc-core-priv.h | 52 ++
drivers/media/rc/rc-ir-raw.c| 56 +
2 files changed, 108 insertions(+)
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index b175bf3..0680e10 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -190,6 +190,58 @@ int ir_raw_gen_manchester(struct ir_raw_event **ev,
unsigned int max,
const struct ir_raw_timings_manchester *timings,
unsigned int n, unsigned int data);
+/**
+ * ir_raw_gen_pulse_space() - generate pulse and space raw events.
+ * @ev:Pointer to pointer to next free raw event.
+ * Will be incremented for each raw event written.
+ * @max: Pointer to number of raw events available in buffer.
+ * Will be decremented for each raw event written.
+ * @pulse_width: Width of pulse in ns.
+ * @space_width: Width of space in ns.
+ *
+ * Returns:0 on success.
+ * -ENOBUFS if there isn't enough buffer space to write both raw
+ * events. In this case @max events will have been written.
+ */
+static inline int ir_raw_gen_pulse_space(struct ir_raw_event **ev,
+unsigned int *max,
+unsigned int pulse_width,
+unsigned int space_width)
+{
+ if (!*max)
+ return -ENOBUFS;
+ init_ir_raw_event_duration((*ev)++, 1, pulse_width);
+ if (!--*max)
+ return -ENOBUFS;
+ init_ir_raw_event_duration((*ev)++, 0, space_width);
+ --*max;
+ return 0;
+}
+
+/**
+ * struct ir_raw_timings_pd - pulse-distance modulation timings
+ * @header_pulse: duration of header pulse in ns (0 for none)
+ * @header_space: duration of header space in ns
+ * @bit_pulse: duration of bit pulse in ns
+ * @bit_space: duration of bit space (for logic 0 and 1) in ns
+ * @trailer_pulse: duration of trailer pulse in ns
+ * @trailer_space: duration of trailer space in ns
+ * @msb_first: 1 if most significant bit is sent first
+ */
+struct ir_raw_timings_pd {
+ unsigned int header_pulse;
+ unsigned int header_space;
+ unsigned int bit_pulse;
+ unsigned int bit_space[2];
+ unsigned int trailer_pulse;
+ unsigned int trailer_space;
+ unsigned int msb_first:1;
+};
+
+int ir_raw_gen_pd(struct ir_raw_event **ev, unsigned int max,
+ const struct ir_raw_timings_pd *timings,
+ unsigned int n, unsigned int data);
+
/*
* Routines from rc-raw.c to be used internally and by decoders
*/
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 072b4bd..5d299f6 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -335,6 +335,62 @@ int ir_raw_gen_manchester(struct ir_raw_event **ev,
unsigned int max,
EXPORT_SYMBOL(ir_raw_gen_manchester);
/**
+ * ir_raw_gen_pd() - Encode data to raw events with pulse-distance modulation.
+ * @ev:Pointer to pointer to next free event. *@ev is
incremented for
+ * each raw event filled.
+ * @max: Maximum number of raw events to fill.
+ * @timings: Pulse distance modulation timings.
+ * @n: Number of bits of data.
+ * @data: Data bits to encode.
+ *
+ * Encodes the @n least significant bits of @data using pulse-distance
+ * modulation with the timing characteristics described by @timings, writing up
+ * to @max raw IR events using the *@ev pointer.
+ *
+ * Returns:0 on success.
+ * -ENOBUFS if there isn't enough space in the array to fit the
+ * full encoded data. In this case all @max events will have been
+ * written.
+ */
+int ir_raw_gen_pd(struct ir_raw_event **ev, unsigned int max,
+ const struct ir_raw_timings_pd *timings,
+ unsigned int n, unsigned int data)
+{
+ int i;
+ int ret;
+
+ if (timings->header_pulse) {
+ ret = ir_raw_gen_pulse_space(ev, &max, timings->header_pulse,
+timings->header_space);
+ if (ret)
+ return ret;
+ }
+
+ if (timings->msb_first) {
+ for (i = n - 1; i >= 0; --i) {
+ ret = ir_raw_gen_pulse_space(ev, &max,
+ timings->bit_pulse,
+ timings->bit_space[(data >> i) & 1]);
+ if (ret)
+ return ret;
+ }
+
[PATCH v4 11/13] [media] rc: rc-core: Add support for encode_wakeup drivers
From: James Hogan
Add support in rc-core for drivers which implement the wakeup scancode
filter by encoding the scancode using the raw IR encoders. This is by
way of rc_dev::encode_wakeup which should be set to true to make the
allowed wakeup protocols the same as the set of raw IR encoders.
As well as updating the sysfs interface to know which wakeup protocols
are allowed for encode_wakeup drivers, also ensure that the IR
decoders/encoders are loaded when an encode_wakeup driver is registered.
Signed-off-by: James Hogan
Signed-off-by: Antti Seppälä
Signed-off-by: Sean Young
Cc: David Härdeman
---
drivers/media/rc/rc-core-priv.h | 1 +
drivers/media/rc/rc-ir-raw.c| 12
drivers/media/rc/rc-main.c | 4 +++-
include/media/rc-core.h | 3 +++
4 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 0680e10..8527cff 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -246,6 +246,7 @@ int ir_raw_gen_pd(struct ir_raw_event **ev, unsigned int
max,
* Routines from rc-raw.c to be used internally and by decoders
*/
u64 ir_raw_get_allowed_protocols(void);
+u64 ir_raw_get_encode_protocols(void);
int ir_raw_event_register(struct rc_dev *dev);
void ir_raw_event_unregister(struct rc_dev *dev);
int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 5d299f6..f44b9e2 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -27,6 +27,7 @@ static LIST_HEAD(ir_raw_client_list);
static DEFINE_MUTEX(ir_raw_handler_lock);
static LIST_HEAD(ir_raw_handler_list);
static atomic64_t available_protocols = ATOMIC64_INIT(0);
+static atomic64_t encode_protocols = ATOMIC64_INIT(0);
static int ir_raw_event_thread(void *data)
{
@@ -236,6 +237,13 @@ ir_raw_get_allowed_protocols(void)
return atomic64_read(&available_protocols);
}
+/* used internally by the sysfs interface */
+u64
+ir_raw_get_encode_protocols(void)
+{
+ return atomic64_read(&encode_protocols);
+}
+
static int change_protocol(struct rc_dev *dev, u64 *rc_type)
{
/* the caller will update dev->enabled_protocols */
@@ -504,6 +512,8 @@ int ir_raw_handler_register(struct ir_raw_handler
*ir_raw_handler)
list_for_each_entry(raw, &ir_raw_client_list, list)
ir_raw_handler->raw_register(raw->dev);
atomic64_or(ir_raw_handler->protocols, &available_protocols);
+ if (ir_raw_handler->encode)
+ atomic64_or(ir_raw_handler->protocols, &encode_protocols);
mutex_unlock(&ir_raw_handler_lock);
return 0;
@@ -523,6 +533,8 @@ void ir_raw_handler_unregister(struct ir_raw_handler
*ir_raw_handler)
ir_raw_handler->raw_unregister(raw->dev);
}
atomic64_andnot(protocols, &available_protocols);
+ if (ir_raw_handler->encode)
+ atomic64_andnot(protocols, &encode_protocols);
mutex_unlock(&ir_raw_handler_lock);
}
EXPORT_SYMBOL(ir_raw_handler_unregister);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 4d8a984..0385616 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1750,11 +1750,13 @@ int rc_register_device(struct rc_dev *dev)
dev->input_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
- if (dev->driver_type == RC_DRIVER_IR_RAW) {
+ if (dev->driver_type == RC_DRIVER_IR_RAW || dev->encode_wakeup) {
+ /* Load raw decoders, if they aren't already */
if (!raw_init) {
request_module_nowait("ir-lirc-codec");
raw_init = true;
}
+
rc = ir_raw_event_register(dev);
if (rc < 0)
goto out_input;
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 0a72e17..acfdaf5 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -83,6 +83,8 @@ enum rc_filter_type {
* @input_dev: the input child device used to communicate events to userspace
* @driver_type: specifies if protocol decoding is done in hardware or software
* @idle: used to keep track of RX state
+ * @encode_wakeup: wakeup filtering uses IR encode API, therefore the allowed
+ * wakeup protocols is the set of all raw encoders
* @allowed_protocols: bitmask with the supported RC_BIT_* protocols
* @enabled_protocols: bitmask with the enabled RC_BIT_* protocols
* @allowed_wakeup_protocols: bitmask with the supported RC_BIT_* wakeup
protocols
@@ -147,6 +149,7 @@ struct rc_dev {
struct input_dev*input_dev;
enum rc_driver_type driver_type;
boolidle;
+ boolencode_wakeup;
u64 allowed_
[PATCH v4 04/13] [media] rc: raw IR drivers cannot handle cec, unknown or other
unknown and other are for IR protocols for which we have no decoder, so the raw IR drivers have no chance of generating them. cec is not an IR protocol. Signed-off-by: Sean Young --- drivers/hid/hid-picolcd_cir.c | 2 +- drivers/media/common/siano/smsir.c | 2 +- drivers/media/pci/cx23885/cx23885-input.c | 14 +++--- drivers/media/rc/ene_ir.c | 2 +- drivers/media/rc/fintek-cir.c | 2 +- drivers/media/rc/gpio-ir-recv.c| 2 +- drivers/media/rc/igorplugusb.c | 4 ++-- drivers/media/rc/iguanair.c| 2 +- drivers/media/rc/ir-hix5hd2.c | 2 +- drivers/media/rc/ite-cir.c | 2 +- drivers/media/rc/mceusb.c | 2 +- drivers/media/rc/meson-ir.c| 2 +- drivers/media/rc/nuvoton-cir.c | 2 +- drivers/media/rc/rc-loopback.c | 2 +- drivers/media/rc/redrat3.c | 2 +- drivers/media/rc/serial_ir.c | 2 +- drivers/media/rc/st_rc.c | 2 +- drivers/media/rc/streamzap.c | 2 +- drivers/media/rc/sunxi-cir.c | 2 +- drivers/media/rc/ttusbir.c | 2 +- drivers/media/rc/winbond-cir.c | 2 +- drivers/media/usb/dvb-usb-v2/rtl28xxu.c| 2 +- drivers/media/usb/dvb-usb/technisat-usb2.c | 2 +- include/media/rc-map.h | 10 ++ 24 files changed, 40 insertions(+), 30 deletions(-) diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c index 9628651..90add97 100644 --- a/drivers/hid/hid-picolcd_cir.c +++ b/drivers/hid/hid-picolcd_cir.c @@ -114,7 +114,7 @@ int picolcd_init_cir(struct picolcd_data *data, struct hid_report *report) rdev->priv = data; rdev->driver_type = RC_DRIVER_IR_RAW; - rdev->allowed_protocols = RC_BIT_ALL; + rdev->allowed_protocols = RC_BIT_ALL_IR_DECODER; rdev->open = picolcd_cir_open; rdev->close= picolcd_cir_close; rdev->input_name = data->hdev->name; diff --git a/drivers/media/common/siano/smsir.c b/drivers/media/common/siano/smsir.c index 41f2a39..480d8bf 100644 --- a/drivers/media/common/siano/smsir.c +++ b/drivers/media/common/siano/smsir.c @@ -87,7 +87,7 @@ int sms_ir_init(struct smscore_device_t *coredev) dev->priv = coredev; dev->driver_type = RC_DRIVER_IR_RAW; - dev->allowed_protocols = RC_BIT_ALL; + dev->allowed_protocols = RC_BIT_ALL_IR_DECODER; dev->map_name = sms_get_board(board_id)->rc_codes; dev->driver_name = MODULE_NAME; diff --git a/drivers/media/pci/cx23885/cx23885-input.c b/drivers/media/pci/cx23885/cx23885-input.c index 1f092fe..2d4e703 100644 --- a/drivers/media/pci/cx23885/cx23885-input.c +++ b/drivers/media/pci/cx23885/cx23885-input.c @@ -286,28 +286,28 @@ int cx23885_input_init(struct cx23885_dev *dev) case CX23885_BOARD_HAUPPAUGE_HVR1250: /* Integrated CX2388[58] IR controller */ driver_type = RC_DRIVER_IR_RAW; - allowed_protos = RC_BIT_ALL; + allowed_protos = RC_BIT_ALL_IR_DECODER; /* The grey Hauppauge RC-5 remote */ rc_map = RC_MAP_HAUPPAUGE; break; case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL: /* Integrated CX23885 IR controller */ driver_type = RC_DRIVER_IR_RAW; - allowed_protos = RC_BIT_ALL; + allowed_protos = RC_BIT_ALL_IR_DECODER; /* The grey Terratec remote with orange buttons */ rc_map = RC_MAP_NEC_TERRATEC_CINERGY_XS; break; case CX23885_BOARD_TEVII_S470: /* Integrated CX23885 IR controller */ driver_type = RC_DRIVER_IR_RAW; - allowed_protos = RC_BIT_ALL; + allowed_protos = RC_BIT_ALL_IR_DECODER; /* A guess at the remote */ rc_map = RC_MAP_TEVII_NEC; break; case CX23885_BOARD_MYGICA_X8507: /* Integrated CX23885 IR controller */ driver_type = RC_DRIVER_IR_RAW; - allowed_protos = RC_BIT_ALL; + allowed_protos = RC_BIT_ALL_IR_DECODER; /* A guess at the remote */ rc_map = RC_MAP_TOTAL_MEDIA_IN_HAND_02; break; @@ -315,7 +315,7 @@ int cx23885_input_init(struct cx23885_dev *dev) case CX23885_BOARD_TBS_6981: /* Integrated CX23885 IR controller */ driver_type = RC_DRIVER_IR_RAW; - allowed_protos = RC_BIT_ALL; + allowed_protos = RC_BIT_ALL_IR_DECODER; /* A guess at the remote */ rc_map = RC_MAP_TBS_NEC; break; @@ -327,13 +327,13 @@ int cx23885_input_init(struct cx23885_dev *dev) case CX23885_BOARD_DVBSKY_T982:
[PATCH v4 13/13] [media] rc: nuvoton-cir: Add support wakeup via sysfs filter callback
From: Antti Seppälä
Nuvoton-cir utilizes the encoding capabilities of rc-core to convert
scancodes from user space to pulse/space format understood by the
underlying hardware.
Converted samples are then written to the wakeup fifo along with other
necessary configuration to enable wake up functionality.
Signed-off-by: Antti Seppälä
Signed-off-by: James Hogan
Signed-off-by: Sean Young
Cc: Jarod Wilson
---
drivers/media/rc/nuvoton-cir.c | 126 +
drivers/media/rc/nuvoton-cir.h | 1 +
include/media/rc-core.h| 1 +
3 files changed, 128 insertions(+)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 9e04f41..ec16012 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -662,6 +662,129 @@ static int nvt_set_tx_carrier(struct rc_dev *dev, u32
carrier)
return 0;
}
+static int nvt_write_wakeup_codes(struct rc_dev *dev,
+ const u8 *wakeup_sample_buf, int count)
+{
+ u8 reg, reg_learn_mode;
+ struct nvt_dev *nvt = dev->priv;
+ int i;
+
+ nvt_dbg_wake("writing wakeup samples");
+
+ reg = nvt_cir_wake_reg_read(nvt, CIR_WAKE_IRCON);
+ reg_learn_mode = reg & ~CIR_WAKE_IRCON_MODE0;
+ reg_learn_mode |= CIR_WAKE_IRCON_MODE1;
+
+ /* Lock the learn area to prevent racing with wake-isr */
+ spin_lock(&nvt->lock);
+
+ /* Enable fifo writes */
+ nvt_cir_wake_reg_write(nvt, reg_learn_mode, CIR_WAKE_IRCON);
+
+ /* Clear cir wake rx fifo */
+ nvt_clear_cir_wake_fifo(nvt);
+
+ if (count > WAKE_FIFO_LEN) {
+ nvt_dbg_wake("HW FIFO too small for all wake samples");
+ count = WAKE_FIFO_LEN;
+ }
+
+ if (count)
+ pr_info("Wake samples (%d) =", count);
+ else
+ pr_info("Wake sample fifo cleared");
+
+ /* Write wake samples to fifo */
+ for (i = 0; i < count; i++) {
+ pr_cont(" %02x", wakeup_sample_buf[i]);
+ nvt_cir_wake_reg_write(nvt, wakeup_sample_buf[i],
+ CIR_WAKE_WR_FIFO_DATA);
+ }
+ pr_cont("\n");
+
+ /* Switch cir to wakeup mode and disable fifo writing */
+ nvt_cir_wake_reg_write(nvt, reg, CIR_WAKE_IRCON);
+
+ /* Set number of bytes needed for wake */
+ nvt_cir_wake_reg_write(nvt, count ? count :
+ CIR_WAKE_FIFO_CMP_BYTES,
+ CIR_WAKE_FIFO_CMP_DEEP);
+
+ spin_unlock(&nvt->lock);
+
+ return 0;
+}
+
+static int nvt_ir_raw_set_wakeup_filter(struct rc_dev *dev,
+ struct rc_scancode_filter *sc_filter)
+{
+ u8 *reg_buf;
+ u8 buf_val;
+ int i, ret, count;
+ unsigned int val;
+ struct ir_raw_event *raw;
+ bool complete;
+
+ /* Require both mask and protocol to be set */
+ if (!sc_filter->mask || dev->wakeup_protocol != RC_TYPE_UNKNOWN)
+ return 0;
+
+ raw = kmalloc_array(WAKE_FIFO_LEN, sizeof(*raw), GFP_KERNEL);
+ if (!raw)
+ return -ENOMEM;
+
+ ret = ir_raw_encode_scancode(dev->wakeup_protocol, sc_filter,
+raw, WAKE_FIFO_LEN);
+ complete = (ret != -ENOBUFS);
+ if (!complete)
+ ret = WAKE_FIFO_LEN;
+ else if (ret < 0)
+ goto out_raw;
+
+ reg_buf = kmalloc_array(WAKE_FIFO_LEN, sizeof(*reg_buf), GFP_KERNEL);
+ if (!reg_buf) {
+ ret = -ENOMEM;
+ goto out_raw;
+ }
+
+ /* Inspect the ir samples */
+ for (i = 0, count = 0; i < ret && count < WAKE_FIFO_LEN; ++i) {
+ val = NS_TO_US((raw[i]).duration) / SAMPLE_PERIOD;
+
+ /* Split too large values into several smaller ones */
+ while (val > 0 && count < WAKE_FIFO_LEN) {
+
+ /* Skip last value for better comparison tolerance */
+ if (complete && i == ret - 1 && val < BUF_LEN_MASK)
+ break;
+
+ /* Clamp values to BUF_LEN_MASK at most */
+ buf_val = (val > BUF_LEN_MASK) ? BUF_LEN_MASK : val;
+
+ reg_buf[count] = buf_val;
+ val -= buf_val;
+ if ((raw[i]).pulse)
+ reg_buf[count] |= BUF_PULSE_BIT;
+ count++;
+ }
+ }
+
+ ret = nvt_write_wakeup_codes(dev, reg_buf, count);
+
+ kfree(reg_buf);
+out_raw:
+ kfree(raw);
+
+ return ret;
+}
+
+/* Dummy implementation. nuvoton is agnostic to the protocol used */
+static int nvt_ir_raw_change_wakeup_protocol(struct rc_dev *dev,
+enum rc_type protocol)
+{
+ return 0;
+}
+
/*
* nvt_tx_ir
*
@@ -1062,11 +1185,14 @@ static int nvt_probe
[PATCH v4 10/13] [media] rc: ir-nec-decoder: Add encode capability
From: James Hogan
Add the capability to encode NEC scancodes as raw events. The
scancode_to_raw is pretty much taken from the img-ir NEC filter()
callback, and modulation uses the pulse distance helper added in a
previous commit.
Signed-off-by: James Hogan
Signed-off-by: Sean Young
Cc: Antti Seppälä
Cc: David Härdeman
---
drivers/media/rc/ir-nec-decoder.c | 94 +++
1 file changed, 94 insertions(+)
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 2a9d155..898cf65 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -201,9 +201,103 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
return -EINVAL;
}
+/**
+ * ir_nec_scancode_to_raw() - encode an NEC scancode ready for modulation.
+ * @protocol: specific protocol to use
+ * @in:scancode filter describing a single NEC scancode.
+ * @raw: raw data to be modulated.
+ */
+static int ir_nec_scancode_to_raw(enum rc_type protocol,
+ const struct rc_scancode_filter *in, u32 *raw)
+{
+ unsigned int addr, addr_inv, data, data_inv;
+
+ data = in->data & 0xff;
+
+ if (protocol == RC_TYPE_NEC32) {
+ /* 32-bit NEC (used by Apple and TiVo remotes) */
+ /* scan encoding: aaAAddDD */
+ if (in->mask != 0x)
+ return -EINVAL;
+ addr_inv = (in->data >> 24) & 0xff;
+ addr = (in->data >> 16) & 0xff;
+ data_inv = (in->data >> 8) & 0xff;
+ } else if (protocol == RC_TYPE_NECX) {
+ /* Extended NEC */
+ /* scan encoding AAaaDD */
+ if (in->mask != 0x00ff)
+ return -EINVAL;
+ addr = (in->data >> 16) & 0xff;
+ addr_inv = (in->data >> 8) & 0xff;
+ data_inv = data ^ 0xff;
+ } else {
+ /* Normal NEC */
+ /* scan encoding: AADD */
+ if (in->mask != 0x)
+ return -EINVAL;
+ addr = (in->data >> 8) & 0xff;
+ addr_inv = addr ^ 0xff;
+ data_inv = data ^ 0xff;
+ }
+
+ /* raw encoding: ddDDaaAA */
+ *raw = data_inv << 24 |
+ data << 16 |
+ addr_inv << 8 |
+ addr;
+ return 0;
+}
+
+static struct ir_raw_timings_pd ir_nec_timings = {
+ .header_pulse = NEC_HEADER_PULSE,
+ .header_space = NEC_HEADER_SPACE,
+ .bit_pulse = NEC_BIT_PULSE,
+ .bit_space[0] = NEC_BIT_0_SPACE,
+ .bit_space[1] = NEC_BIT_1_SPACE,
+ .trailer_pulse = NEC_TRAILER_PULSE,
+ .trailer_space = NEC_TRAILER_SPACE,
+ .msb_first = 0,
+};
+
+/**
+ * ir_nec_encode() - Encode a scancode as a stream of raw events
+ *
+ * @protocol: protocol
+ * @scancode: scancode filter describing scancode (helps distinguish between
+ * protocol subtypes when scancode is ambiguous)
+ * @events:array of raw ir events to write into
+ * @max: maximum size of @events
+ *
+ * Returns:The number of events written.
+ * -ENOBUFS if there isn't enough space in the array to fit the
+ * encoding. In this case all @max events will have been written.
+ * -EINVAL if the scancode is ambiguous or invalid.
+ */
+static int ir_nec_encode(enum rc_type protocol,
+const struct rc_scancode_filter *scancode,
+struct ir_raw_event *events, unsigned int max)
+{
+ struct ir_raw_event *e = events;
+ int ret;
+ u32 raw;
+
+ /* Convert a NEC scancode to raw NEC data */
+ ret = ir_nec_scancode_to_raw(protocol, scancode, &raw);
+ if (ret < 0)
+ return ret;
+
+ /* Modulate the raw data using a pulse distance modulation */
+ ret = ir_raw_gen_pd(&e, max, &ir_nec_timings, NEC_NBITS, raw);
+ if (ret < 0)
+ return ret;
+
+ return e - events;
+}
+
static struct ir_raw_handler nec_handler = {
.protocols = RC_BIT_NEC | RC_BIT_NECX | RC_BIT_NEC32,
.decode = ir_nec_decode,
+ .encode = ir_nec_encode,
};
static int __init ir_nec_decode_init(void)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/13] [media] winbond-cir: use sysfs wakeup filter
Now that we can select the exact variant of the protocol for wakeup
filter, the winbond-cir can use the wakeup filter rather than module
parameters.
Signed-off-by: Sean Young
---
drivers/media/rc/winbond-cir.c | 252 -
1 file changed, 125 insertions(+), 127 deletions(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 78491ed..ce1e8c2 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -194,7 +194,6 @@ enum wbcir_txstate {
#define WBCIR_NAME "Winbond CIR"
#define WBCIR_ID_FAMILY 0xF1 /* Family ID for the WPCD376I*/
#defineWBCIR_ID_CHIP0x04 /* Chip ID for the WPCD376I
*/
-#define INVALID_SCANCODE 0x7FFF /* Invalid with all protos */
#define WAKEUP_IOMEM_LEN 0x10 /* Wake-Up I/O Reg Len */
#define EHFUNC_IOMEM_LEN 0x10 /* Enhanced Func I/O Reg Len */
#define SP_IOMEM_LEN 0x08 /* Serial Port 3 (IR) Reg Len*/
@@ -225,10 +224,6 @@ struct wbcir_data {
u32 txcarrier;
};
-static enum wbcir_protocol protocol = IR_PROTOCOL_RC6;
-module_param(protocol, uint, 0444);
-MODULE_PARM_DESC(protocol, "IR protocol to use for the power-on command (0 =
RC5, 1 = NEC, 2 = RC6A, default)");
-
static bool invert; /* default = 0 */
module_param(invert, bool, 0444);
MODULE_PARM_DESC(invert, "Invert the signal from the IR receiver");
@@ -237,15 +232,6 @@ static bool txandrx; /* default = 0 */
module_param(txandrx, bool, 0444);
MODULE_PARM_DESC(txandrx, "Allow simultaneous TX and RX");
-static unsigned int wake_sc = 0x800F040C;
-module_param(wake_sc, uint, 0644);
-MODULE_PARM_DESC(wake_sc, "Scancode of the power-on IR command");
-
-static unsigned int wake_rc6mode = 6;
-module_param(wake_rc6mode, uint, 0644);
-MODULE_PARM_DESC(wake_rc6mode, "RC6 mode for the power-on command (0 = 0, 6 =
6A, default)");
-
-
/*
*
@@ -696,138 +682,135 @@ wbcir_shutdown(struct pnp_dev *device)
{
struct device *dev = &device->dev;
struct wbcir_data *data = pnp_get_drvdata(device);
+ struct rc_dev *rc = data->dev;
bool do_wake = true;
u8 match[11];
u8 mask[11];
u8 rc6_csl = 0;
+ u8 proto;
+ u32 wake_sc = rc->scancode_wakeup_filter.data;
+ u32 mask_sc = rc->scancode_wakeup_filter.mask;
int i;
memset(match, 0, sizeof(match));
memset(mask, 0, sizeof(mask));
- if (wake_sc == INVALID_SCANCODE || !device_may_wakeup(dev)) {
+ if (!mask_sc || rc->wakeup_protocol == RC_TYPE_UNKNOWN ||
+ !device_may_wakeup(dev)) {
do_wake = false;
goto finish;
}
- switch (protocol) {
- case IR_PROTOCOL_RC5:
- if (wake_sc > 0xFFF) {
- do_wake = false;
- dev_err(dev, "RC5 - Invalid wake scancode\n");
- break;
- }
-
+ switch (rc->wakeup_protocol) {
+ case RC_TYPE_RC5:
/* Mask = 13 bits, ex toggle */
- mask[0] = 0xFF;
- mask[1] = 0x17;
+ mask[0] = (mask_sc & 0x003f);
+ mask[0] |= (mask_sc & 0x0300) >> 2;
+ mask[1] = (mask_sc & 0x1c00) >> 10;
+ if (mask_sc & 0x0040) /* 2nd start bit */
+ match[1] |= 0x10;
- match[0] = (wake_sc & 0x003F); /* 6 command bits */
- match[0] |= (wake_sc & 0x0180) >> 1; /* 2 address bits */
- match[1] = (wake_sc & 0x0E00) >> 9; /* 3 address bits */
- if (!(wake_sc & 0x0040)) /* 2nd start bit */
+ match[0] = (wake_sc & 0x003F); /* 6 command bits */
+ match[0] |= (wake_sc & 0x0300) >> 2; /* 2 address bits */
+ match[1] = (wake_sc & 0x1c00) >> 10; /* 3 address bits */
+ if (!(wake_sc & 0x0040)) /* 2nd start bit */
match[1] |= 0x10;
+ proto = IR_PROTOCOL_RC5;
break;
- case IR_PROTOCOL_NEC:
- if (wake_sc > 0xFF) {
- do_wake = false;
- dev_err(dev, "NEC - Invalid wake scancode\n");
- break;
- }
+ case RC_TYPE_NEC:
+ mask[1] = bitrev8(mask_sc);
+ mask[0] = ~mask[1];
+ mask[3] = bitrev8(mask_sc >> 8);
+ mask[2] = ~mask[3];
- mask[0] = mask[1] = mask[2] = mask[3] = 0xFF;
+ match[1] = bitrev8(wake_sc);
+ match[0] = ~mask[1];
+ match[3] = bitrev8(wake_sc >> 8);
+ match[2] = ~mask[3];
- match[1] = bitrev8((wake_sc & 0xFF));
- match[0] = ~
[PATCH v4 06/13] [media] rc: rc-ir-raw: Add Manchester encoder (phase encoder) helper
From: Antti Seppälä
Adding a simple Manchester encoder to rc-core.
Manchester coding is used by at least RC-5 and RC-6 protocols and their
variants.
Signed-off-by: Antti Seppälä
Signed-off-by: James Hogan
Signed-off-by: Sean Young
Cc: David Härdeman
---
drivers/media/rc/rc-core-priv.h | 33
drivers/media/rc/rc-ir-raw.c| 85 +
2 files changed, 118 insertions(+)
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 98cc0cf..b175bf3 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -157,6 +157,39 @@ static inline bool is_timing_event(struct ir_raw_event ev)
#define TO_US(duration)DIV_ROUND_CLOSEST((duration),
1000)
#define TO_STR(is_pulse) ((is_pulse) ? "pulse" : "space")
+/* functions for IR encoders */
+
+static inline void init_ir_raw_event_duration(struct ir_raw_event *ev,
+ unsigned int pulse,
+ u32 duration)
+{
+ init_ir_raw_event(ev);
+ ev->duration = duration;
+ ev->pulse = pulse;
+}
+
+/**
+ * struct ir_raw_timings_manchester - Manchester coding timings
+ * @leader:duration of leader pulse (if any) 0 if continuing
+ * existing signal (see @pulse_space_start)
+ * @pulse_space_start: 1 for starting with pulse (0 for starting with space)
+ * @clock: duration of each pulse/space in ns
+ * @invert:if set clock logic is inverted
+ * (0 = space + pulse, 1 = pulse + space)
+ * @trailer_space: duration of trailer space in ns
+ */
+struct ir_raw_timings_manchester {
+ unsigned int leader;
+ unsigned int pulse_space_start:1;
+ unsigned int clock;
+ unsigned int invert:1;
+ unsigned int trailer_space;
+};
+
+int ir_raw_gen_manchester(struct ir_raw_event **ev, unsigned int max,
+ const struct ir_raw_timings_manchester *timings,
+ unsigned int n, unsigned int data);
+
/*
* Routines from rc-raw.c to be used internally and by decoders
*/
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 1b229ef..072b4bd 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -250,6 +250,91 @@ static void ir_raw_disable_protocols(struct rc_dev *dev,
u64 protocols)
}
/**
+ * ir_raw_gen_manchester() - Encode data with Manchester (bi-phase) modulation.
+ * @ev:Pointer to pointer to next free event. *@ev is
incremented for
+ * each raw event filled.
+ * @max: Maximum number of raw events to fill.
+ * @timings: Manchester modulation timings.
+ * @n: Number of bits of data.
+ * @data: Data bits to encode.
+ *
+ * Encodes the @n least significant bits of @data using Manchester (bi-phase)
+ * modulation with the timing characteristics described by @timings, writing up
+ * to @max raw IR events using the *@ev pointer.
+ *
+ * Returns:0 on success.
+ * -ENOBUFS if there isn't enough space in the array to fit the
+ * full encoded data. In this case all @max events will have been
+ * written.
+ */
+int ir_raw_gen_manchester(struct ir_raw_event **ev, unsigned int max,
+ const struct ir_raw_timings_manchester *timings,
+ unsigned int n, unsigned int data)
+{
+ bool need_pulse;
+ unsigned int i;
+ int ret = -ENOBUFS;
+
+ i = 1 << (n - 1);
+
+ if (timings->leader) {
+ if (!max--)
+ return ret;
+ if (timings->pulse_space_start) {
+ init_ir_raw_event_duration((*ev)++, 1, timings->leader);
+
+ if (!max--)
+ return ret;
+ init_ir_raw_event_duration((*ev), 0, timings->leader);
+ } else {
+ init_ir_raw_event_duration((*ev), 1, timings->leader);
+ }
+ i >>= 1;
+ } else {
+ /* continue existing signal */
+ --(*ev);
+ }
+ /* from here on *ev will point to the last event rather than the next */
+
+ while (n && i > 0) {
+ need_pulse = !(data & i);
+ if (timings->invert)
+ need_pulse = !need_pulse;
+ if (need_pulse == !!(*ev)->pulse) {
+ (*ev)->duration += timings->clock;
+ } else {
+ if (!max--)
+ goto nobufs;
+ init_ir_raw_event_duration(++(*ev), need_pulse,
+ timings->clock);
+ }
+
+ if (!max--)
+ goto nobufs;
+ init_ir_raw_event_duration(++(*ev), !need_puls
[PATCH v4 00/13] Use sysfs filter for winbond & nuvoton wakeup
This patch series resurrects an earlier series with a new approach. I've modified wakeup_protocols so that only one protocol variant can be selected, and the ir_raw_encode_scancode() now takes an enum rc_type rather than a protocol bitmask. These changes make it possible for the winbond-cir to use the wakeup filter, and I've tested this. For the nuvoton I have merged the v3 code forward and otherwise it is largely untouched. I do not have the hardware to test this, although v3 reportedly worked. It would be relatively easy to add encoders for the remaining protocols which can be done in follow-on work. Antti Seppälä (3): [media] rc: rc-ir-raw: Add Manchester encoder (phase encoder) helper [media] rc: ir-rc6-decoder: Add encode capability [media] rc: nuvoton-cir: Add support wakeup via sysfs filter callback James Hogan (6): [media] rc: rc-ir-raw: Add scancode encoder callback [media] rc: rc-ir-raw: Add pulse-distance modulation helper [media] rc: ir-rc5-decoder: Add encode capability [media] rc: ir-nec-decoder: Add encode capability [media] rc: rc-core: Add support for encode_wakeup drivers [media] rc: rc-loopback: Add loopback of filter scancodes Sean Young (4): [media] rc: change wakeup_protocols to list all protocol variants [media] rc: Add scancode validation [media] winbond-cir: use sysfs wakeup filter [media] rc: raw IR drivers cannot handle cec, unknown or other Documentation/ABI/testing/sysfs-class-rc | 14 +- Documentation/media/uapi/rc/rc-sysfs-nodes.rst | 13 +- drivers/hid/hid-picolcd_cir.c | 2 +- drivers/media/common/siano/smsir.c | 2 +- drivers/media/pci/cx23885/cx23885-input.c | 14 +- drivers/media/rc/ene_ir.c | 2 +- drivers/media/rc/fintek-cir.c | 2 +- drivers/media/rc/gpio-ir-recv.c| 2 +- drivers/media/rc/igorplugusb.c | 4 +- drivers/media/rc/iguanair.c| 2 +- drivers/media/rc/img-ir/img-ir-hw.c| 2 - drivers/media/rc/ir-hix5hd2.c | 2 +- drivers/media/rc/ir-nec-decoder.c | 94 +++ drivers/media/rc/ir-rc5-decoder.c | 116 + drivers/media/rc/ir-rc6-decoder.c | 120 + drivers/media/rc/ite-cir.c | 2 +- drivers/media/rc/mceusb.c | 2 +- drivers/media/rc/meson-ir.c| 2 +- drivers/media/rc/nuvoton-cir.c | 128 +- drivers/media/rc/nuvoton-cir.h | 1 + drivers/media/rc/rc-core-priv.h| 89 +++ drivers/media/rc/rc-ir-raw.c | 191 +- drivers/media/rc/rc-loopback.c | 40 ++- drivers/media/rc/rc-main.c | 334 + drivers/media/rc/redrat3.c | 2 +- drivers/media/rc/serial_ir.c | 2 +- drivers/media/rc/st_rc.c | 2 +- drivers/media/rc/streamzap.c | 2 +- drivers/media/rc/sunxi-cir.c | 2 +- drivers/media/rc/ttusbir.c | 2 +- drivers/media/rc/winbond-cir.c | 254 ++- drivers/media/usb/dvb-usb-v2/rtl28xxu.c| 2 +- drivers/media/usb/dvb-usb/technisat-usb2.c | 2 +- include/media/rc-core.h| 14 +- include/media/rc-map.h | 10 + 35 files changed, 1249 insertions(+), 225 deletions(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/13] [media] rc: change wakeup_protocols to list all protocol variants
No driver has ever created a wakeup_protocol sysfs file since no
rc_dev driver implemented change_wakeup_protocol, so we are free to
change it.
For IR wakeup a driver has to program the hardware to wakeup at a
specific IR sequence, so it makes no sense to allow multiple wakeup
protocols to be selected. In the same manner the sysfs interface only
allows one scancode to be provided.
In addition we need to know the specific variant of the protocol.
Note that the ImgTec IR only ever set enabled_wakeup_protocols, it
never used it.
Signed-off-by: Sean Young
---
Documentation/ABI/testing/sysfs-class-rc | 14 +-
Documentation/media/uapi/rc/rc-sysfs-nodes.rst | 13 +-
drivers/media/rc/img-ir/img-ir-hw.c| 2 -
drivers/media/rc/rc-ir-raw.c | 1 -
drivers/media/rc/rc-main.c | 266 -
include/media/rc-core.h| 7 +-
6 files changed, 236 insertions(+), 67 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-rc
b/Documentation/ABI/testing/sysfs-class-rc
index b65674d..cd47235 100644
--- a/Documentation/ABI/testing/sysfs-class-rc
+++ b/Documentation/ABI/testing/sysfs-class-rc
@@ -62,18 +62,18 @@ Description:
This value may be reset to 0 if the current protocol is altered.
What: /sys/class/rc/rcN/wakeup_protocols
-Date: Feb 2014
-KernelVersion: 3.15
+Date: Feb 2017
+KernelVersion: 4.12
Contact: Mauro Carvalho Chehab
Description:
Reading this file returns a list of available protocols to use
for the wakeup filter, something like:
- "rc5 rc6 nec jvc [sony]"
+ "rc-5 nec nec-x rc-6-0 rc-6-6a-24 [rc-6-6a-32] rc-6-mce"
+ Note that protocol variants are listed, so "nec", "sony",
+ "rc-5", "rc-6" have their different bit length encodings
+ listed if available.
The enabled wakeup protocol is shown in [] brackets.
- Writing "+proto" will add a protocol to the list of enabled
- wakeup protocols.
- Writing "-proto" will remove a protocol from the list of enabled
- wakeup protocols.
+ Only one protocol can be selected at a time.
Writing "proto" will use "proto" for wakeup events.
Writing "none" will disable wakeup.
Write fails with EINVAL if an invalid protocol combination or
diff --git a/Documentation/media/uapi/rc/rc-sysfs-nodes.rst
b/Documentation/media/uapi/rc/rc-sysfs-nodes.rst
index 6fb944f..3476ae2 100644
--- a/Documentation/media/uapi/rc/rc-sysfs-nodes.rst
+++ b/Documentation/media/uapi/rc/rc-sysfs-nodes.rst
@@ -92,15 +92,16 @@ This value may be reset to 0 if the current protocol is
altered.
Reading this file returns a list of available protocols to use for the
wakeup filter, something like:
-``rc5 rc6 nec jvc [sony]``
+``rc-5 nec nec-x rc-6-0 rc-6-6a-24 [rc-6-6a-32] rc-6-mce``
-The enabled wakeup protocol is shown in [] brackets.
+Note that protocol variants are listed, so "nec", "sony", "rc-5", "rc-6"
+have their different bit length encodings listed if available.
-Writing "+proto" will add a protocol to the list of enabled wakeup
-protocols.
+Note that all protocol variants are listed.
-Writing "-proto" will remove a protocol from the list of enabled wakeup
-protocols.
+The enabled wakeup protocol is shown in [] brackets.
+
+Only one protocol can be selected at a time.
Writing "proto" will use "proto" for wakeup events.
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
b/drivers/media/rc/img-ir/img-ir-hw.c
index 7bb71bc..08f7c9b 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -685,7 +685,6 @@ static int img_ir_change_protocol(struct rc_dev *dev, u64
*ir_type)
if (!hw->decoder || !hw->decoder->filter)
wakeup_protocols = 0;
rdev->allowed_wakeup_protocols = wakeup_protocols;
- rdev->enabled_wakeup_protocols = wakeup_protocols;
return 0;
}
@@ -701,7 +700,6 @@ static void img_ir_set_protocol(struct img_ir_priv *priv,
u64 proto)
mutex_lock(&rdev->lock);
rdev->enabled_protocols = proto;
rdev->allowed_wakeup_protocols = proto;
- rdev->enabled_wakeup_protocols = proto;
mutex_unlock(&rdev->lock);
}
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 1c42a9f..171bdba 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -246,7 +246,6 @@ static void ir_raw_disable_protocols(struct rc_dev *dev,
u64 protocols)
{
mutex_lock(&dev->lock);
dev->enabled_protocols &= ~protocols;
- dev->enabled_wakeup_protocols &= ~protocols;
mutex_unlock(&dev->lock);
}
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index dedaf38..60229e9 100644
--- a/drivers/media/rc/rc-main.c
+++
[PATCH v4 02/13] [media] rc: Add scancode validation
We need to valdiate that scancodes are valid for their protocol; an
incorrect necx scancode could actually be a nec scancode, for example.
Signed-off-by: Sean Young
---
drivers/media/rc/rc-main.c | 66 +-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 60229e9..4d8a984 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -724,6 +724,66 @@ void rc_keydown_notimeout(struct rc_dev *dev, enum rc_type
protocol,
}
EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
+/**
+ * rc_validate_filter() - checks that the scancode and mask are valid and
+ * provides sensible defaults
+ * @protocol: the protocol for the filter
+ * @filter:the scancode and mask
+ * @return:0 or -EINVAL if the filter is not valid
+ */
+int rc_validate_filter(enum rc_type protocol,
+ struct rc_scancode_filter *filter)
+{
+ static u32 masks[] = {
+ [RC_TYPE_RC5] = 0x1f7f,
+ [RC_TYPE_RC5X] = 0x1f7f3f,
+ [RC_TYPE_RC5_SZ] = 0x2fff,
+ [RC_TYPE_SONY12] = 0x1f007f,
+ [RC_TYPE_SONY15] = 0xff007f,
+ [RC_TYPE_SONY20] = 0x1fff7f,
+ [RC_TYPE_JVC] = 0x,
+ [RC_TYPE_NEC] = 0x,
+ [RC_TYPE_NECX] = 0xff,
+ [RC_TYPE_NEC32] = 0x,
+ [RC_TYPE_SANYO] = 0x1f,
+ [RC_TYPE_RC6_0] = 0x,
+ [RC_TYPE_RC6_6A_20] = 0xf,
+ [RC_TYPE_RC6_6A_24] = 0xff,
+ [RC_TYPE_RC6_6A_32] = 0x,
+ [RC_TYPE_RC6_MCE] = 0x,
+ [RC_TYPE_SHARP] = 0x1fff,
+ };
+ u32 s = filter->data;
+
+ switch (protocol) {
+ case RC_TYPE_NECX:
+ if s >> 16) ^ ~(s >> 8)) & 0xff) == 0)
+ return -EINVAL;
+ break;
+ case RC_TYPE_NEC32:
+ if s >> 24) ^ ~(s >> 16)) & 0xff) == 0)
+ return -EINVAL;
+ break;
+ case RC_TYPE_RC6_MCE:
+ if ((s & 0x) != 0x800f)
+ return -EINVAL;
+ break;
+ case RC_TYPE_RC6_6A_32:
+ if ((s & 0x) == 0x800f)
+ return -EINVAL;
+ break;
+ default:
+ break;
+ }
+
+ if (filter->mask == 0)
+ filter->mask = masks[protocol];
+ filter->data &= masks[protocol];
+ filter->mask &= masks[protocol];
+
+ return 0;
+}
+
int rc_open(struct rc_dev *rdev)
{
int rval = 0;
@@ -1232,8 +1292,12 @@ static ssize_t store_filter(struct device *device,
/* refuse to set a filter unless a protocol is enabled */
if (dev->wakeup_protocol == RC_TYPE_UNKNOWN && val) {
ret = -EINVAL;
- goto unlock;
+ } else if (dev->wakeup_protocol != RC_TYPE_UNKNOWN) {
+ ret = rc_validate_filter(dev->wakeup_protocol,
+ &new_filter);
}
+ if (ret != 0)
+ goto unlock;
}
if (fattr->type == RC_FILTER_NORMAL && !dev->enabled_protocols
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/13] [media] rc: rc-ir-raw: Add scancode encoder callback
From: James Hogan
Add a callback to raw ir handlers for encoding and modulating a scancode
to a set of raw events. This could be used for transmit, or for
converting a wakeup scancode filter to a form that is more suitable for
raw hardware wake up filters.
Signed-off-by: James Hogan
Signed-off-by: Antti Seppälä
Signed-off-by: Sean Young
Cc: David Härdeman
---
drivers/media/rc/rc-core-priv.h | 3 +++
drivers/media/rc/rc-ir-raw.c| 37 +
include/media/rc-core.h | 3 +++
3 files changed, 43 insertions(+)
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 585d5e5..98cc0cf 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -28,6 +28,9 @@ struct ir_raw_handler {
u64 protocols; /* which are handled by this handler */
int (*decode)(struct rc_dev *dev, struct ir_raw_event event);
+ int (*encode)(enum rc_type protocol,
+ const struct rc_scancode_filter *scancode,
+ struct ir_raw_event *events, unsigned int max);
/* These two should only be used by the lirc decoder */
int (*raw_register)(struct rc_dev *dev);
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 171bdba..1b229ef 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -249,6 +249,43 @@ static void ir_raw_disable_protocols(struct rc_dev *dev,
u64 protocols)
mutex_unlock(&dev->lock);
}
+/**
+ * ir_raw_encode_scancode() - Encode a scancode as raw events
+ *
+ * @protocol: protocol
+ * @scancode: scancode filter describing a single scancode
+ * @events:array of raw events to write into
+ * @max: max number of raw events
+ *
+ * Attempts to encode the scancode as raw events.
+ *
+ * Returns:The number of events written.
+ * -ENOBUFS if there isn't enough space in the array to fit the
+ * encoding. In this case all @max events will have been written.
+ * -EINVAL if the scancode is ambiguous or invalid, or if no
+ * compatible encoder was found.
+ */
+int ir_raw_encode_scancode(enum rc_type protocol,
+ const struct rc_scancode_filter *scancode,
+ struct ir_raw_event *events, unsigned int max)
+{
+ struct ir_raw_handler *handler;
+ int ret = -EINVAL;
+
+ mutex_lock(&ir_raw_handler_lock);
+ list_for_each_entry(handler, &ir_raw_handler_list, list) {
+ if (handler->protocols & (1 << protocol) && handler->encode) {
+ ret = handler->encode(protocol, scancode, events, max);
+ if (ret >= 0 || ret == -ENOBUFS)
+ break;
+ }
+ }
+ mutex_unlock(&ir_raw_handler_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(ir_raw_encode_scancode);
+
/*
* Used to (un)register raw event clients
*/
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 3c34cac..0a72e17 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -307,6 +307,9 @@ int ir_raw_event_store_edge(struct rc_dev *dev, enum
raw_event_type type);
int ir_raw_event_store_with_filter(struct rc_dev *dev,
struct ir_raw_event *ev);
void ir_raw_event_set_idle(struct rc_dev *dev, bool idle);
+int ir_raw_encode_scancode(enum rc_type protocol,
+ const struct rc_scancode_filter *scancode,
+ struct ir_raw_event *events, unsigned int max);
static inline void ir_raw_event_reset(struct rc_dev *dev)
{
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/13] [media] rc: ir-rc5-decoder: Add encode capability
From: James Hogan
Add the capability to encode RC-5, RC-5X and RC-5-SZ scancodes as raw
events. The protocol is chosen based on the specified protocol mask,
and whether all the required bits are set in the scancode mask, and
none of the unused bits are set in the scancode data. For example a
scancode filter with bit 16 set in both data and mask is unambiguously
RC-5X.
The Manchester modulation helper is used, and for RC-5X it is used twice
with two sets of timings, the first with a short trailer space for the
space in the middle, and the second with no leader so that it can
continue the space.
The encoding in RC-5-SZ first inserts a pulse and then simply utilizes
the generic Manchester encoder available in rc-core.
Signed-off-by: James Hogan
Signed-off-by: Antti Seppälä
Signed-off-by: Sean Young
Cc: David Härdeman
---
drivers/media/rc/ir-rc5-decoder.c | 116 ++
1 file changed, 116 insertions(+)
diff --git a/drivers/media/rc/ir-rc5-decoder.c
b/drivers/media/rc/ir-rc5-decoder.c
index a0fd4e6..c405459 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -181,9 +181,125 @@ static int ir_rc5_decode(struct rc_dev *dev, struct
ir_raw_event ev)
return -EINVAL;
}
+static struct ir_raw_timings_manchester ir_rc5_timings = {
+ .leader = RC5_UNIT,
+ .pulse_space_start = 0,
+ .clock = RC5_UNIT,
+ .trailer_space = RC5_UNIT * 10,
+};
+
+static struct ir_raw_timings_manchester ir_rc5x_timings[2] = {
+ {
+ .leader = RC5_UNIT,
+ .pulse_space_start = 0,
+ .clock = RC5_UNIT,
+ .trailer_space = RC5X_SPACE,
+ },
+ {
+ .clock = RC5_UNIT,
+ .trailer_space = RC5_UNIT * 10,
+ },
+};
+
+static struct ir_raw_timings_manchester ir_rc5_sz_timings = {
+ .leader = RC5_UNIT,
+ .pulse_space_start = 0,
+ .clock = RC5_UNIT,
+ .trailer_space = RC5_UNIT * 10,
+};
+
+static int ir_rc5_validate_filter(const struct rc_scancode_filter *scancode,
+ unsigned int important_bits)
+{
+ /* all important bits of scancode should be set in mask */
+ if (~scancode->mask & important_bits)
+ return -EINVAL;
+ /* extra bits in mask should be zero in data */
+ if (scancode->mask & scancode->data & ~important_bits)
+ return -EINVAL;
+ return 0;
+}
+
+/**
+ * ir_rc5_encode() - Encode a scancode as a stream of raw events
+ *
+ * @protocol: protocol variant to encode
+ * @scancode: scancode filter describing scancode (helps distinguish between
+ * protocol subtypes when scancode is ambiguous)
+ * @events:array of raw ir events to write into
+ * @max: maximum size of @events
+ *
+ * Returns:The number of events written.
+ * -ENOBUFS if there isn't enough space in the array to fit the
+ * encoding. In this case all @max events will have been written.
+ * -EINVAL if the scancode is ambiguous or invalid.
+ */
+static int ir_rc5_encode(enum rc_type protocol,
+const struct rc_scancode_filter *scancode,
+struct ir_raw_event *events, unsigned int max)
+{
+ int ret;
+ struct ir_raw_event *e = events;
+ unsigned int data, xdata, command, commandx, system;
+
+ /* Detect protocol and convert scancode to raw data */
+ if (protocol == RC_TYPE_RC5 &&
+ !ir_rc5_validate_filter(scancode, 0x1f7f)) {
+ /* decode scancode */
+ command = (scancode->data & 0x003f) >> 0;
+ commandx = (scancode->data & 0x0040) >> 6;
+ system = (scancode->data & 0x1f00) >> 8;
+ /* encode data */
+ data = !commandx << 12 | system << 6 | command;
+
+ /* Modulate the data */
+ ret = ir_raw_gen_manchester(&e, max, &ir_rc5_timings, RC5_NBITS,
+ data);
+ if (ret < 0)
+ return ret;
+ } else if (protocol == RC_TYPE_RC5X &&
+ !ir_rc5_validate_filter(scancode, 0x1f7f3f)) {
+ /* decode scancode */
+ xdata= (scancode->data & 0x3f) >> 0;
+ command = (scancode->data & 0x003f00) >> 8;
+ commandx = (scancode->data & 0x004000) >> 14;
+ system = (scancode->data & 0x1f) >> 16;
+ /* commandx and system overlap, bits must match when encoded */
+ if (commandx == (system & 0x1))
+ return -EINVAL;
+ /* encode data */
+ data = 1 << 18 | system << 12 | command << 6 | xdata;
+
+
Re: Enabling peer to peer device transactions for PCIe devices
>>> I've already recommended that iopmem not be a block device and >>> instead be a device-dax instance. I also don't think it should claim >>> the PCI ID, rather the driver that wants to map one of its bars this >>> way can register the memory region with the device-dax core. >>> >>> I'm not sure there are enough device drivers that want to do this to >>> have it be a generic /sys/.../resource_dmableX capability. It still >>> seems to be an exotic one-off type of configuration. >> >> >> Yes, this is essentially my thinking. Except I think the userspace >> interface should really depend on the device itself. Device dax is a >> good choice for many and I agree the block device approach wouldn't be >> ideal. I tend to agree here. The block device interface has seen quite a bit of resistance and /dev/dax looks like a better approach for most. We can look at doing it that way in v2. >> >> Specifically for NVME CMB: I think it would make a lot of sense to just >> hand out these mappings with an mmap call on /dev/nvmeX. I expect CMB >> buffers would be volatile and thus you wouldn't need to keep track of >> where in the BAR the region came from. Thus, the mmap call would just be >> an allocator from BAR memory. If device-dax were used, userspace would >> need to lookup which device-dax instance corresponds to which nvme >> drive. >> > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > device-dax instance under the nvme device, or if you already have the nvme > sysfs path the dax instance(s) will appear under the "dax" sub-directory. > Personally I think mapping the dax resource in the sysfs tree is a nice way to do this and a bit more intuitive than mapping a /dev/nvmeX. -- 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/4] v4l: vsp1: Fix suspend/resume and race on M2M pipelines
This small patchset helps rework the VSP1 driver to repair an issue on suspend/resume operations whereby the pipeline does not get reconfigured after it has been re-initialised following a resume operation. Along side this, there was an intrinsic race in the vsp1_video_start_streaming() function whereby multiple streams operating through a BRU, could find themselves commencing an operation before the pipeline has been configured, or worse - commencing, just as the pipeline is being configured resulting in a null pointer dereference on pipe->dl. This series superceeds a previous effort to fix the BRU race. Patch [1/4] is a code move only, with no functional change. Patch [2/4] refactors the vsp1_video_start_streaming() function and fixes both suspend/resume, and the BRU race in a single change Patch [3/4] removes the context scoped 'pipe->dl' which has been susceptible to races and isn't required to be in the context. Patch [4/4] is an RFC patch really, that fixes a segfault on error paths and I certainly expect feedback and brief discussion. Please drop Patch 4 in the event of any further discussion, and don't consider it as blocking for the first three patches of this series. Kieran Bingham (4): v4l: vsp1: Move vsp1_video_setup_pipeline() v4l: vsp1: Refactor video pipeline configuration v4l: vsp1: Use local display lists and remove global pipe->dl media: Catch null pipes on pipeline stop drivers/media/media-entity.c | 2 + drivers/media/platform/vsp1/vsp1_drm.c | 20 ++--- drivers/media/platform/vsp1/vsp1_drv.c | 3 + drivers/media/platform/vsp1/vsp1_pipe.c | 1 + drivers/media/platform/vsp1/vsp1_pipe.h | 4 +- drivers/media/platform/vsp1/vsp1_video.c | 127 +++ 6 files changed, 78 insertions(+), 79 deletions(-) -- 2.7.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/4] v4l: vsp1: Refactor video pipeline configuration
With multiple inputs through the BRU it is feasible for the streams to
race each other at stream-on. In the case of the video pipelines, this
can present two serious issues.
1) A null-dereference if the pipe->dl is committed at the same time as
the vsp1_video_setup_pipeline() is processing
2) A hardware hang, where a display list is committed without having
called vsp1_video_setup_pipeline() first
Along side these race conditions, the work done by
vsp1_video_setup_pipeline() is undone by the re-initialisation during a
suspend resume cycle, and an active pipeline does not attempt to
reconfigure the correct routing and init parameters for the entities.
To repair all of these issues, we can move the call to a conditional
inside vsp1_video_pipeline_run() and ensure that this can only be called
on the last stream which calls into vsp1_video_start_streaming()
As a convenient side effect of this, by specifying that the
configuration has been lost during suspend/resume actions - the
vsp1_video_pipeline_run() call can re-initialise pipelines when
necessary thus repairing resume actions for active m2m pipelines.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drv.c | 3 +++
drivers/media/platform/vsp1/vsp1_pipe.c | 1 +
drivers/media/platform/vsp1/vsp1_pipe.h | 2 ++
drivers/media/platform/vsp1/vsp1_video.c | 20 +---
4 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 57c713a4e1df..dd26549a6912 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -447,6 +447,9 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
ret = vsp1_reset_wpf(vsp1, i);
if (ret < 0)
return ret;
+
+ if (vsp1->wpf[i] && vsp1->wpf[i]->pipe)
+ vsp1->wpf[i]->pipe->configured = false;
}
vsp1_write(vsp1, VI6_CLK_DCSWT, (8 << VI6_CLK_DCSWT_CSTPW_SHIFT) |
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 756ca4ea7668..7ddf862ee403 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -208,6 +208,7 @@ void vsp1_pipeline_init(struct vsp1_pipeline *pipe)
INIT_LIST_HEAD(&pipe->entities);
pipe->state = VSP1_PIPELINE_STOPPED;
+ pipe->configured = false;
}
/* Must be called with the pipe irqlock held. */
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
b/drivers/media/platform/vsp1/vsp1_pipe.h
index ac4ad261..0743b9fcb655 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -61,6 +61,7 @@ enum vsp1_pipeline_state {
* @pipe: the media pipeline
* @irqlock: protects the pipeline state
* @state: current state
+ * @configured: determines routing configuration active on cell.
* @wq: wait queue to wait for state change completion
* @frame_end: frame end interrupt handler
* @lock: protects the pipeline use count and stream count
@@ -86,6 +87,7 @@ struct vsp1_pipeline {
spinlock_t irqlock;
enum vsp1_pipeline_state state;
+ bool configured;
wait_queue_head_t wq;
void (*frame_end)(struct vsp1_pipeline *pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index 44b687c0b8df..7ff9f4c19ff0 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -388,6 +388,8 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline
*pipe)
VSP1_ENTITY_PARAMS_INIT);
}
+ pipe->configured = true;
+
return 0;
}
@@ -411,6 +413,9 @@ static void vsp1_video_pipeline_run(struct vsp1_pipeline
*pipe)
struct vsp1_device *vsp1 = pipe->output->entity.vsp1;
struct vsp1_entity *entity;
+ if (!pipe->configured)
+ vsp1_video_setup_pipeline(pipe);
+
if (!pipe->dl)
pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
@@ -793,25 +798,18 @@ static int vsp1_video_start_streaming(struct vb2_queue
*vq, unsigned int count)
struct vsp1_video *video = vb2_get_drv_priv(vq);
struct vsp1_pipeline *pipe = video->rwpf->pipe;
unsigned long flags;
- int ret;
mutex_lock(&pipe->lock);
if (pipe->stream_count == pipe->num_inputs) {
- ret = vsp1_video_setup_pipeline(pipe);
- if (ret < 0) {
- mutex_unlock(&pipe->lock);
- return ret;
- }
+ spin_lock_irqsave(&pipe->irqlock, flags);
+ if (vsp1_pipeline_ready(pipe))
+ vsp1_video_pipeline_run(pipe);
+ spin_unlock_irqrestore(&pipe->irqlock, flags);
}
pipe->stream_count++;
mutex_unl
[PATCH RFC 4/4] media: Catch null pipes on pipeline stop
media_entity_pipeline_stop() can be called through error paths with a NULL entity pipe object. In this instance, stopping is a no-op, so simply return without any action Signed-off-by: Kieran Bingham --- I've marked this patch as RFC, although if deemed suitable, by all means integrate it as is. When testing suspend/resume operations on VSP1, I encountered a segfault on the WARN_ON(!pipe->streaming_count) line, where 'pipe == NULL'. The simple protection fix is to return early in this instance, as this patch does however: A) Does this early return path warrant a WARN() statement itself, to identify drivers which are incorrectly calling media_entity_pipeline_stop() with an invalid entity, or would this just be noise ... and therefore.. B) I also partly assume this patch could simply get NAK'd with a request to go and dig out the root cause of calling media_entity_pipeline_stop() with an invalid entity. My brief investigation so far here so far shows that it's almost a second order fault - where the first suspend resume cycle completes but leaves the entity in an invalid state having followed an error path - and then on a second suspend/resume - the stop fails with the affected segfault. If statement A) or B) apply here, please drop this patch from the series, and don't consider it a blocking issue for the other 3 patches. Kieran drivers/media/media-entity.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c index c68239e60487..93c9cbf4bf46 100644 --- a/drivers/media/media-entity.c +++ b/drivers/media/media-entity.c @@ -508,6 +508,8 @@ void __media_entity_pipeline_stop(struct media_entity *entity) struct media_entity_graph *graph = &entity->pipe->graph; struct media_pipeline *pipe = entity->pipe; + if (!pipe) + return; WARN_ON(!pipe->streaming_count); media_entity_graph_walk_start(graph, entity); -- 2.7.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 3/4] v4l: vsp1: Use local display lists and remove global pipe->dl
The usage of pipe->dl is susceptible to races, and it is redundant to
keep this pointer in a larger scoped context.
Now that the calling order of vsp1_video_setup_pipeline() has been
adapted, it is possible to remove the pipe->dl and pass the variable as
required.
Currently the pipe->dl is set during the atomic begin hook, but it is
not utilised until the flush. Moving this should do no harm.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 20 +++---
drivers/media/platform/vsp1/vsp1_pipe.h | 2 --
drivers/media/platform/vsp1/vsp1_video.c | 45 ++--
3 files changed, 30 insertions(+), 37 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index cd209dccff1b..bf735e85b597 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -220,9 +220,6 @@ void vsp1_du_atomic_begin(struct device *dev)
struct vsp1_pipeline *pipe = &vsp1->drm->pipe;
vsp1->drm->num_inputs = pipe->num_inputs;
-
- /* Prepare the display list. */
- pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
}
EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
@@ -426,10 +423,14 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_pipeline *pipe = &vsp1->drm->pipe;
struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
struct vsp1_entity *entity;
+ struct vsp1_dl_list *dl;
unsigned long flags;
unsigned int i;
int ret;
+ /* Prepare the display list. */
+ dl = vsp1_dl_list_get(pipe->output->dlm);
+
/* Count the number of enabled inputs and sort them by Z-order. */
pipe->num_inputs = 0;
@@ -484,26 +485,25 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_rwpf *rpf = to_rwpf(&entity->subdev);
if (!pipe->inputs[rpf->entity.index]) {
- vsp1_dl_list_write(pipe->dl, entity->route->reg,
+ vsp1_dl_list_write(dl, entity->route->reg,
VI6_DPR_NODE_UNUSED);
continue;
}
}
- vsp1_entity_route_setup(entity, pipe->dl);
+ vsp1_entity_route_setup(entity, dl);
if (entity->ops->configure) {
- entity->ops->configure(entity, pipe, pipe->dl,
+ entity->ops->configure(entity, pipe, dl,
VSP1_ENTITY_PARAMS_INIT);
- entity->ops->configure(entity, pipe, pipe->dl,
+ entity->ops->configure(entity, pipe, dl,
VSP1_ENTITY_PARAMS_RUNTIME);
- entity->ops->configure(entity, pipe, pipe->dl,
+ entity->ops->configure(entity, pipe, dl,
VSP1_ENTITY_PARAMS_PARTITION);
}
}
- vsp1_dl_list_commit(pipe->dl);
- pipe->dl = NULL;
+ vsp1_dl_list_commit(dl);
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 0743b9fcb655..98980c85081f 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -108,8 +108,6 @@ struct vsp1_pipeline {
struct list_head entities;
- struct vsp1_dl_list *dl;
-
unsigned int div_size;
unsigned int partitions;
struct v4l2_rect partition;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index 7ff9f4c19ff0..9619ed4dda7c 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -350,18 +350,14 @@ static void vsp1_video_frame_end(struct vsp1_pipeline
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
}
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl)
{
struct vsp1_entity *entity;
/* Determine this pipelines sizes for image partitioning support. */
vsp1_video_pipeline_setup_partitions(pipe);
- /* Prepare the display list. */
- pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
- if (!pipe->dl)
- return -ENOMEM;
-
if (pipe->uds) {
struct vsp1_uds *uds = to_uds(&pipe->uds->subdev);
@@ -381,10 +377,10 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline
*pipe)
}
list_for_each_entry(entity, &pipe->entities, list_pipe) {
- vsp1_entity_route_setup(entity, pipe->dl);
+ vsp1_entity_route_set
[PATCH 1/4] v4l: vsp1: Move vsp1_video_setup_pipeline()
Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.
This commit is just a code move for clarity performing no functional
change.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_video.c | 82
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index d351b9c768d2..44b687c0b8df 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -350,6 +350,47 @@ static void vsp1_video_frame_end(struct vsp1_pipeline
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
}
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+{
+ struct vsp1_entity *entity;
+
+ /* Determine this pipelines sizes for image partitioning support. */
+ vsp1_video_pipeline_setup_partitions(pipe);
+
+ /* Prepare the display list. */
+ pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
+ if (!pipe->dl)
+ return -ENOMEM;
+
+ if (pipe->uds) {
+ struct vsp1_uds *uds = to_uds(&pipe->uds->subdev);
+
+ /* If a BRU is present in the pipeline before the UDS, the alpha
+* component doesn't need to be scaled as the BRU output alpha
+* value is fixed to 255. Otherwise we need to scale the alpha
+* component only when available at the input RPF.
+*/
+ if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
+ uds->scale_alpha = false;
+ } else {
+ struct vsp1_rwpf *rpf =
+ to_rwpf(&pipe->uds_input->subdev);
+
+ uds->scale_alpha = rpf->fmtinfo->alpha;
+ }
+ }
+
+ list_for_each_entry(entity, &pipe->entities, list_pipe) {
+ vsp1_entity_route_setup(entity, pipe->dl);
+
+ if (entity->ops->configure)
+ entity->ops->configure(entity, pipe, pipe->dl,
+ VSP1_ENTITY_PARAMS_INIT);
+ }
+
+ return 0;
+}
+
static void vsp1_video_pipeline_run_partition(struct vsp1_pipeline *pipe,
struct vsp1_dl_list *dl)
{
@@ -747,47 +788,6 @@ static void vsp1_video_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&pipe->irqlock, flags);
}
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
-{
- struct vsp1_entity *entity;
-
- /* Determine this pipelines sizes for image partitioning support. */
- vsp1_video_pipeline_setup_partitions(pipe);
-
- /* Prepare the display list. */
- pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
- if (!pipe->dl)
- return -ENOMEM;
-
- if (pipe->uds) {
- struct vsp1_uds *uds = to_uds(&pipe->uds->subdev);
-
- /* If a BRU is present in the pipeline before the UDS, the alpha
-* component doesn't need to be scaled as the BRU output alpha
-* value is fixed to 255. Otherwise we need to scale the alpha
-* component only when available at the input RPF.
-*/
- if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
- uds->scale_alpha = false;
- } else {
- struct vsp1_rwpf *rpf =
- to_rwpf(&pipe->uds_input->subdev);
-
- uds->scale_alpha = rpf->fmtinfo->alpha;
- }
- }
-
- list_for_each_entry(entity, &pipe->entities, list_pipe) {
- vsp1_entity_route_setup(entity, pipe->dl);
-
- if (entity->ops->configure)
- entity->ops->configure(entity, pipe, pipe->dl,
- VSP1_ENTITY_PARAMS_INIT);
- }
-
- return 0;
-}
-
static int vsp1_video_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct vsp1_video *video = vb2_get_drv_priv(vq);
--
2.7.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] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay
On Mon, Dec 05, 2016 at 10:13:38AM -0300, Javier Martinez Canillas wrote:
> Hello Javi,
>
> On 12/05/2016 07:09 AM, Javi Merino wrote:
> > In asds configured with V4L2_ASYNC_MATCH_OF, the v4l2 subdev can be
> > part of a devicetree overlay, for example:
> >
> > &media_bridge {
> > ...
> > my_port: port@0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <0>;
> > ep: endpoint@0 {
> > remote-endpoint = <&camera0>;
> > };
> > };
> > };
> >
> > / {
> > fragment@0 {
> > target = <&i2c0>;
> > __overlay__ {
> > my_cam {
> > compatible = "foo,bar";
> > port {
> > camera0: endpoint {
> > remote-endpoint = <&my_port>;
> > ...
> > };
> > };
> > };
> > };
> > };
> > };
> >
> > Each time the overlay is applied, its of_node pointer will be
> > different. We are not interested in matching the pointer, what we
> > want to match is that the path is the one we are expecting. Change to
> > use of_node_cmp() so that we continue matching after the overlay has
> > been removed and reapplied.
> >
> > Cc: Mauro Carvalho Chehab
> > Cc: Javier Martinez Canillas
> > Cc: Sakari Ailus
> > Signed-off-by: Javi Merino
> > ---
>
> I already reviewed v1 but you didn't carry the tag. So again:
I forgot to add it :(
> Reviewed-by: Javier Martinez Canillas
Thanks!
Javi
--
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
DVB CAM did not respond / DVBSky S960CI + SmarCAM-3 CI Plus
Hello everybody! This is my very first message here, so first of all, thank you all for your participation in this project. I really do appreciate it! Still I'm looking for some advice.. I bought DVBsky S960CI (DVB-S2), managed to install drivers, VDR, plugins etc on my Linux systems and I can view only not encrypted content, but when it comes to encrypted (and this is my main use) here comes trouble. It seems that CAM is not responding for some reason.. Kernel: 3.16.36-1+deb8u2~bpo70+1 (2016-10-19) x86_64 GNU/Linux Drivers used from DVBsky website: media_build-bst-14-141106 CAM module seems to be: SmarCAM-3 CI Plus / smardtv software version: 09.00.01.01.03.00 hardware version: 01000102 cpu: CAP100 (200mhz) memory: 4 MB Flash/ 8 MB RAM Nagra system bandwidth: up to 200 Mb/s Everything (including encoded channels) works fine on Windows with 20151117 DVBsky driver and 151027 version of DVBsky Player. Could you please advise how can I troubleshoot this issue? Thank you in advance! And here is what DMESG states: [ 3694.896376] usb 1-1.3: dvb_usb_v2: found a 'DVBSky S960CI' in warm state [ 3694.896491] usb 1-1.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 3694.896521] DVB: registering new adapter (DVBSky S960CI) [ 3694.898050] dvbsky_usb MAC address=00:18:42:54:96:0c [ 3694.898065] usb 1-1.3: dvb_usb_v2: MAC address: 00:18:42:54:96:0c [ 3694.900319] DS3000 chip version: d0 attached. [ 3694.901664] TS202x chip version[1]: c1 attached. [ 3694.913840] TS202x chip version[2]: c3 attached. [ 3694.969092] m88ds3103_load_firmware: Waiting for firmware upload (dvb-fe-ds3103.fw)... [ 3694.969164] usb 1-1.3: firmware: direct-loading firmware dvb-fe-ds3103.fw [ 3694.969173] m88ds3103_load_firmware: Waiting for firmware upload(2)... [ 3696.034348] usb 1-1.3: DVB: registering adapter 0 frontend 0 (Montage DS3103/TS2022)... [ 3696.041934] Registered IR keymap rc-dvbsky [ 3696.042165] input: DVBSky S960CI as /devices/pci:00/:00:14.0/usb1/1-1/1-1.3/rc/rc0/input11 [ 3696.042683] rc0: DVBSky S960CI as /devices/pci:00/:00:14.0/usb1/1-1/1-1.3/rc/rc0 [ 3696.042694] usb 1-1.3: dvb_usb_v2: schedule remote query interval to 300 msecs [ 3696.042702] usb 1-1.3: dvb_usb_v2: 'DVBSky S960CI' successfully initialized and connected [ 3757.382943] dvb_ca adapter 0: DVB CAM did not respond :( Any suggestions much appreciated. Kind regards, Konrad -- 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
