Re: [PATCH] [media] rc: Remove init_ir_raw_event and DEFINE_IR_RAW_EVENT
Hi Sean,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc3 next-20160412]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Sean-Young/rc-Remove-init_ir_raw_event-and-DEFINE_IR_RAW_EVENT/20160412-203118
base: git://linuxtv.org/media_tree.git master
config: openrisc-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/media/i2c/cx25840/cx25840-ir.c: In function 'cx25840_ir_rx_read':
>> drivers/media/i2c/cx25840/cx25840-ir.c:710:4: error: unknown field
>> 'duration' specified in initializer
--
drivers/media/rc/streamzap.c: In function 'streamzap_callback':
>> drivers/media/rc/streamzap.c:258:6: error: unknown field 'duration'
>> specified in initializer
vim +/duration +710 drivers/media/i2c/cx25840/cx25840-ir.c
704 v = (unsigned) pulse_width_count_to_ns(
705(u16) (p->hw_fifo_data & FIFO_RXTX),
divider);
706 if (v > IR_MAX_DURATION)
707 v = IR_MAX_DURATION;
708
709 p->ir_core_data = (struct ir_raw_event)
> 710 { .pulse = u, .duration = v, .timeout = w };
711
712 v4l2_dbg(2, ir_debug, sd, "rx read: %10u ns %s %s\n",
713 v, u ? "mark" : "space", w ? "(timed out)" :
"");
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
cron job: media_tree daily build: OK
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 Apr 13 04:00:23 CEST 2016 git branch: test git hash: bc5ccdbc990debbcae4602214dddc8d5fd38b01d gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3353-gcae47da host hardware: x86_64 host os:4.4.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-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: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-i686: OK linux-4.5-i686: OK linux-4.6-rc1-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-x86_64: OK linux-4.5-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 1/2] [media] tvp5150: Add input connectors DT bindings
The tvp5150 and tvp5151 decoders support different video input source
connections to their AIP1A and AIP1B pins. Either two Composite or a
S-Video input signals are supported.
The possible configurations are as follows:
- Analog Composite signal connected to AIP1A.
- Analog Composite signal connected to AIP1B.
- Analog S-Video Y (luminance) and C (chrominance)
signals connected to AIP1A and AIP1B respectively.
This patch extends the Device Tree binding documentation to describe
how the input connectors for these devices should be defined in a DT.
Suggested-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
Hello,
The DT binding assumes that there is a 1:1 map between physical connectors
and connections, so there will be a connector described in the DT for each
connection.
There is also the question about how the DT bindings will be extended to
support other attributes (color/position/group) using the properties API.
But I believe that can be done as a follow-up, once the properties API is
in mainline.
Best regards,
Javier
Changes in v2:
- Remove from the changelog a mention of devices that multiplex the
physical RCA connectors to be used for the S-Video Y and C signals
since it's a special case and it doesn't really work on the IGEPv2.
.../devicetree/bindings/media/i2c/tvp5150.txt | 59 ++
1 file changed, 59 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
index 8c0fc1a26bf0..df555650b0b4 100644
--- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
+++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
@@ -26,8 +26,46 @@ Required Endpoint Properties for parallel synchronization:
If none of hsync-active, vsync-active and field-even-active is specified,
the endpoint is assumed to use embedded BT.656 synchronization.
+-Optional nodes:
+- connectors: The list of tvp5150 input connectors available on a given
+ board. The node should contain a child 'port' node for each connector.
+
+ The tvp5150 has support for three possible connectors: 2 Composite and
+ 1 S-video. The "reg" property is used to specify which input connector
+ is associated with each 'port', using the following possible values:
+
+ 0: Composite0
+ 1: Composite1
+ 2: S-Video
+
+ The ports should have an endpoint subnode that is linked to a connector
+ node defined in Documentation/devicetree/bindings/display/connector/.
+ The linked connector compatible string should match the connector type.
+
Example:
+composite0: connector@0 {
+ compatible = "composite-video-connector";
+ label = "Composite0";
+
+ port {
+ comp0_out: endpoint {
+ remote-endpoint = <&tvp5150_comp0_in>;
+ };
+ };
+};
+
+svideo: connector@1 {
+ compatible = "composite-video-connector";
+ label = "S-Video";
+
+ port {
+ svideo_out: endpoint {
+ remote-endpoint = <&tvp5150_svideo_in>;
+ };
+ };
+};
+
&i2c2 {
...
tvp5150@5c {
@@ -36,6 +74,27 @@ Example:
pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
+ connectors {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Composite0 input */
+ port@0 {
+ reg = <0>;
+ tvp5150_comp0_in: endpoint {
+ remote-endpoint = <&comp0_out>;
+ };
+ };
+
+ /* S-Video input */
+ port@2 {
+ reg = <2>;
+ tvp5150_svideo_in: endpoint {
+ remote-endpoint = <&svideo_out>;
+ };
+ };
+ };
+
port {
tvp5150_1: endpoint {
remote-endpoint = <&ccdc_ep>;
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 0/2] [media] tvp515p: Proposal for MC input connector support
Hello, This is a second version of an RFC patch series that adds MC input connector support to the tvp5150 driver. The first RFC version was [0]. The patches are RFC because a previous version was merged and later reverted since the approach was found to be inadequate. So I preferred to post this approach as RFC to discuss it first. The main difference with v1 is that a single sink pad is used for the tvp5150 (instead of using a pad per each input pin) as suggested by Mauro and Hans. The mc_nextgen_test dot output after applying the series can be found at [1] and the graph png generated using the dot tool is at [2]. I tested these patches on an IGEPv2 by capturing using both Composite inputs. [0]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg95389.html [1]: http://hastebin.com/yiduhonome.tex [2]: http://i.imgur.com/EyFtVtJ.png?1 Best regards, Javier Changes in v2: - Remove from the changelog a mention of devices that multiplex the physical RCA connectors to be used for the S-Video Y and C signals since it's a special case and it doesn't really work on the IGEPv2. - Use a single sink pad for the demod and map the connectors as entities so the mux is made via links. Suggested by Mauro and Hans. Javier Martinez Canillas (2): [media] tvp5150: Add input connectors DT bindings [media] tvp5150: Replace connector support according to DT binding .../devicetree/bindings/media/i2c/tvp5150.txt | 59 drivers/media/i2c/tvp5150.c| 155 +++-- 2 files changed, 170 insertions(+), 44 deletions(-) -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 2/2] [media] tvp5150: Replace connector support according to DT binding
The tvp5150 and tvp5151 decoders support different video input source
connections to their AIP1A and AIP1B pins. Either two Composite or a
S-Video input signals are supported.
The input connector support was added before to the device DT binding
with commit 82c2ffeb217a ("[media] tvp5150: document input connectors
DT bindings"), but the binding was found to be wrong so was reverted.
A new binding documentation was added that uses OF graph endpoint and
ports for the input connectors, so this patch replaces the old logic
to be aligned to what is described in the latest tvp5150 binding doc.
The DT binding only describes the type of the input connectors and not
how the signals are routed to the chip, that information is inferred
by the driver that knows what are the possible input configurations.
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Use a single sink pad for the demod and map the connectors as entities
so the mux is made via links. Suggested by Mauro and Hans.
drivers/media/i2c/tvp5150.c | 155 +++-
1 file changed, 111 insertions(+), 44 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index ff18444e19e4..e5003d94f262 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1338,15 +1338,112 @@ static int tvp5150_init(struct i2c_client *c)
return 0;
}
+#ifdef CONFIG_MEDIA_CONTROLLER
+static int tvp5150_parse_connector_node(struct tvp5150 *decoder,
+ struct device_node *port)
+{
+ struct v4l2_of_endpoint endpoint;
+ struct media_entity *input;
+ struct device_node *ep, *rp;
+ unsigned int input_type;
+ const char *name;
+ int ret;
+
+ /* tvp5150 connector ports can have only one endpoint. */
+ ep = of_get_next_child(port, NULL);
+ if (!ep) {
+ v4l2_err(&decoder->sd, "Endpoint not found for connector %s\n",
+port->full_name);
+ return -EINVAL;
+ }
+
+ ret = v4l2_of_parse_endpoint(ep, &endpoint);
+ if (ret) {
+ v4l2_err(&decoder->sd, "Connector %s parse endpoint failed
%d\n",
+port->full_name, ret);
+ goto err_ep;
+ }
+
+ input_type = endpoint.base.port;
+
+ if (input_type >= TVP5150_INPUT_NUM) {
+ v4l2_err(&decoder->sd,
+"Connector %s port address %u is not a valid one\n",
+port->full_name, input_type);
+ ret = -EINVAL;
+ goto err_ep;
+ }
+
+ input = &decoder->input_ent[input_type];
+
+ /* Each input connector can only be defined once */
+ if (input->name) {
+ v4l2_err(&decoder->sd,
+"Connector %s with same type already exists\n",
+input->name);
+ ret = -EINVAL;
+ goto err_ep;
+ }
+
+ rp = of_graph_get_remote_port_parent(ep);
+ if (!rp) {
+ v4l2_err(&decoder->sd, "Port %s remote parent not found\n",
+ep->full_name);
+ ret = -EINVAL;
+ goto err_ep;
+ }
+
+ switch (input_type) {
+ case TVP5150_COMPOSITE0:
+ case TVP5150_COMPOSITE1:
+ if (!of_device_is_compatible(rp, "composite-video-connector")) {
+ v4l2_err(&decoder->sd, "Wrong compatible for port %s\n",
+rp->full_name);
+ ret = -EINVAL;
+ goto err_rp;
+ }
+
+ input->function = MEDIA_ENT_F_CONN_COMPOSITE;
+ break;
+ case TVP5150_SVIDEO:
+ if (!of_device_is_compatible(rp, "svideo-connector")) {
+ v4l2_err(&decoder->sd, "Wrong compatible for port %s\n",
+rp->full_name);
+ ret = -EINVAL;
+ goto err_rp;
+ }
+
+ input->function = MEDIA_ENT_F_CONN_SVIDEO;
+ break;
+ }
+
+ input->flags = MEDIA_ENT_FL_CONNECTOR;
+
+ ret = of_property_read_string(rp, "label", &name);
+ if (ret < 0) {
+ v4l2_err(&decoder->sd,
+"Missing label property in port %s\n",
+rp->full_name);
+ goto err_rp;
+ }
+
+ input->name = name;
+
+err_rp:
+ of_node_put(rp);
+err_ep:
+ of_node_put(ep);
+ return ret;
+
+}
+#endif
+
static int tvp5150_parse_dt(struct tvp5150 *decoder, struct device_node *np)
{
struct v4l2_of_endpoint bus_cfg;
struct device_node *ep;
#ifdef CONFIG_MEDIA_CONTROLLER
struct device_node *connectors, *child;
- struct media_entity *input;
- const char *name;
- u32 input_type;
#endif
unsigned int flags;
int ret = 0;
Re: tvp5150 regression after commit 9f924169c035
> I'll try to find some time next week to dig deeper on this. Just > thought that may be related to the issue you found but it seems > that's not the case. Any updates on this? Thanks, Wolfram signature.asc Description: PGP signature
Re: gstreamer: v4l2videodec plugin
Le mardi 12 avril 2016 à 11:57 +0300, Stanimir Varbanov a écrit : > > I'm very happy to see this report. So far, we only had report that > this > > element works on Freescale IMX.6 (CODA) and Exynos 4/5. > > In this context, I would be very happy to see v4l2videoenc merged > soon :) That will happen when all review comments are resolved. cheers, Nicolas signature.asc Description: This is a digitally signed message part
Re: Kernel docs: muddying the waters a bit
On Fri, 8 Apr 2016 17:12:27 +0200 Markus Heiser wrote: > motivated by this MT, I implemented a toolchain to migrate the kernel’s > DocBook XML documentation to reST markup. > > It converts 99% of the docs well ... to gain an impression how > kernel-docs could benefit from, visit my sphkerneldoc project page > on github: > > http://return42.github.io/sphkerneldoc/ So I've obviously been pretty quiet on this recently. Apologies...I've been dealing with an extended death-in-the-family experience, and there is still a fair amount of cleanup to be done. Looking quickly at this work, it seems similar to the results I got. But there's a lot of code there that came from somewhere? I'd put together a fairly simple conversion using pandoc and a couple of short sed scripts; is there a reason for a more complex solution? Thanks for looking into this, anyway; I hope to be able to focus more on it shortly. jon -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4] [media] rcar-vin: add Renesas R-Car VIN driver
A V4L2 driver for Renesas R-Car VIN driver that do not depend on soc_camera. The driver is heavily based on its predecessor and aims to replace it. Signed-off-by: Niklas Söderlund --- The driver is tested on Koelsch and can do streaming using qv4l2 and grab frames using yavta. It passes a v4l2-compliance (git master) run without any failures, see bellow for output. Some issues I know about but will have to wait for future work in other patches. - One can not bind/unbind the subdevice and continue using the driver. - Do not support FIELD_ALTERNATE. - Suggested compat string "renesas,rcar-gen2-vin" is not included. Will address this in a separate patch together with gen3. The goal is to replace the soc_camera driver completely to prepare for Gen3 enablement. I have therefor chosen to inherit the CONFIG_VIDEO_RCAR_VIN name for this new driver and renamed the soc_camera driver CONFIG_VIDEO_RCAR_VIN_OLD. * Changes since v3 - Print error and return EINVAL instead of ENOBUFS if there is not enough buffers to fill HW in start_streaming. This error should not happen since 'min_buffers_needed' should ensure it never happens but we check for the condition anyhow. - Return all buffers with state VB2_BUF_STATE_QUEUED if there is an error in start_streaming. * Changes since v2 - Fix review comments from Hans Verkuil, thanks! - Update description in Kconfig - Drop V4L2_SEL_TGT_COMPOSE_PADDED - Wrong size for NV16 image - Copy ycbcr_enc and xfer_func when keeping old format. - Add vidioc_cropcap - Return -ENOBUFS in start_streaming to signal more buffers are needed instead of sleeping in a critical section... - Move all v4l2 ioctls and file ops to rcar-v4l2.c (and as a follow up moved all HW functions to rcar-dma.c to increase readability). - Fixed RGB formats 's/V4L2_PIX_FMT_RGB555X/V4L2_PIX_FMT_XRGB555' and 's/V4L2_PIX_FMT_RGB32/V4L2_PIX_FMT_XBGR32'. This was an error carried over from soc-camera dirver, whit this fix I get correct colors in qv4l2. - Rework how media bus type and flags are handled. Instead of defining own values and a unsigned int use struct v4l2_mbus_config to store the configuration parsed from DT. - Remove duplicated code from the v4l2_file_operations release code path. There is no need to try and stop the streaming from here. If start_streaming have been called stop_streaming will be called by the framework stopping the streaming. - Remove all special checks for the chip RCAR_E1. There are no compat string that will select this chip model. Neither for this driver or its predecessor in soc-camera. - Force an width alignment of 32 if the NV16 format is used due to HW limitation. * Changes since RFC/PATCH - Fixed review comments from Hans Verkuil, thanks for reviewing. - Added vidioc_[gs]_selection crop and composition is supported. Thanks Laurent for taking the time and explaining to me how to do composition. - Reworked the DMA flow to better support single and continues frame grabbing mode. - Dropped a lot of the formats that was ported from soc_camera, once I looked at it in a working driver it was obvious that the rcar_vin soc_camera driver did not support them. - Added better comments for the core structs - Fixed copyright in file headers - A lot more testing. I have made a few small additions to the adv7180.c driver while doing this driver but are posted in a separate patch. For completeness I included the output of v4l2-compliance both with and with out the adv7180 enhancements. The adv7180 additions enables the std and tvnorms code paths so it tests a bit more of this driver. There is a failure reported here but it's a false positive and is addressed in Hans Verkuil series '[PATCHv2 0/2] v4l2-ioctl: cropcap improvement'. If I apply that series to my tree the failure goes away. (without adv7180 enhancements) # ./v4l2-compliance -d 27 -s -f Driver Info: Driver name : rcar_vin Card type : R_Car_VIN Bus info : platform:e6ef1000.video Driver version: 4.6.0 Capabilities : 0x8521 Video Capture Read/Write Streaming Extended Pix Format Device Capabilities Device Caps : 0x0521 Video Capture Read/Write Streaming Extended Pix Format Compliance test for device /dev/video27 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not
Re: libdvbv5 licencing
Hi Russel, Em Sat, 26 Mar 2016 06:13:08 + Russel Winder escreveu: > I hadn't noticed previously, but it has been brought to my attention > that libdvbv5 is licenced as GPLv2. This makes it impossible > (effectively) for any non-GPL code to make use of libdvbv5. This seems > to undermine the whole point of libdvbv5. > > In particular, I wanted to rip out all the Linux API based code from > the GStreamer DVB plugins and replace it with use of libdvbv5. However > because of the licencing (GStreamer is LGPL and must only use LGPL or > more liberal licenced code), this is going to be impossible. > > Instead of ripping out the current code (which is DVBv3) and using > libdvbv5, it looks like I will be forced to recreate libdvbv5 but as > LGPL code. > > Is there any chance of relicencing libdvbv5 as LGPL code so that others > may use it? Yes. We had some discussions in the past to re-license it to LGPL, if this is going to be used by some other OSS project that would require that. Most of the code was written by me, and, in the past the other developers that worked on that also agreed on re-licensing as LGPL. So, basically, if gstreamer is willing to use libdvbv5, we'll relicense it to LGPL. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] rc: Remove init_ir_raw_event and DEFINE_IR_RAW_EVENT
These can be done with regular c99 constructs, which makes the
code cleaner and more transparent.
Signed-off-by: Sean Young
---
drivers/hid/hid-picolcd_cir.c | 3 +--
drivers/media/common/siano/smsir.c | 2 +-
drivers/media/i2c/cx25840/cx25840-ir.c | 6 ++
drivers/media/pci/cx23885/cx23888-ir.c | 6 ++
drivers/media/pci/cx88/cx88-input.c | 3 +--
drivers/media/rc/ene_ir.c | 5 ++---
drivers/media/rc/fintek-cir.c | 3 +--
drivers/media/rc/gpio-ir-recv.c | 2 +-
drivers/media/rc/igorplugusb.c | 2 +-
drivers/media/rc/iguanair.c | 4 +---
drivers/media/rc/ir-hix5hd2.c | 2 +-
drivers/media/rc/ite-cir.c | 5 +
drivers/media/rc/mceusb.c | 3 +--
drivers/media/rc/meson-ir.c | 2 +-
drivers/media/rc/nuvoton-cir.c | 4 +---
drivers/media/rc/rc-ir-raw.c| 4 ++--
drivers/media/rc/rc-loopback.c | 2 +-
drivers/media/rc/redrat3.c | 2 +-
drivers/media/rc/st_rc.c| 5 ++---
drivers/media/rc/streamzap.c| 12 ++--
drivers/media/rc/sunxi-cir.c| 2 +-
drivers/media/rc/ttusbir.c | 4 +---
drivers/media/rc/winbond-cir.c | 4 ++--
drivers/media/usb/au0828/au0828-input.c | 5 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 4 +---
include/media/rc-core.h | 15 +--
26 files changed, 37 insertions(+), 74 deletions(-)
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index 9628651..b723307 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -45,7 +45,7 @@ int picolcd_raw_cir(struct picolcd_data *data,
{
unsigned long flags;
int i, w, sz;
- DEFINE_IR_RAW_EVENT(rawir);
+ struct ir_raw_event rawir = {};
/* ignore if rc_dev is NULL or status is shunned */
spin_lock_irqsave(&data->lock, flags);
@@ -67,7 +67,6 @@ int picolcd_raw_cir(struct picolcd_data *data,
*/
sz = size > 0 ? min((int)raw_data[0], size-1) : 0;
for (i = 0; i+1 < sz; i += 2) {
- init_ir_raw_event(&rawir);
w = (raw_data[i] << 8) | (raw_data[i+1]);
rawir.pulse = !!(w & 0x8000);
rawir.duration = US_TO_NS(rawir.pulse ? (65536 - w) : w);
diff --git a/drivers/media/common/siano/smsir.c
b/drivers/media/common/siano/smsir.c
index 41f2a39..093 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -41,7 +41,7 @@ void sms_ir_event(struct smscore_device_t *coredev, const
char *buf, int len)
const s32 *samples = (const void *)buf;
for (i = 0; i < len >> 2; i++) {
- DEFINE_IR_RAW_EVENT(ev);
+ struct ir_raw_event ev = {};
ev.duration = abs(samples[i]) * 1000; /* Convert to ns */
ev.pulse = (samples[i] > 0) ? false : true;
diff --git a/drivers/media/i2c/cx25840/cx25840-ir.c
b/drivers/media/i2c/cx25840/cx25840-ir.c
index 4b78201..84bef3e 100644
--- a/drivers/media/i2c/cx25840/cx25840-ir.c
+++ b/drivers/media/i2c/cx25840/cx25840-ir.c
@@ -706,10 +706,8 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
if (v > IR_MAX_DURATION)
v = IR_MAX_DURATION;
- init_ir_raw_event(&p->ir_core_data);
- p->ir_core_data.pulse = u;
- p->ir_core_data.duration = v;
- p->ir_core_data.timeout = w;
+ p->ir_core_data = (struct ir_raw_event)
+ { .pulse = u, .duration = v, .timeout = w };
v4l2_dbg(2, ir_debug, sd, "rx read: %10u ns %s %s\n",
v, u ? "mark" : "space", w ? "(timed out)" : "");
diff --git a/drivers/media/pci/cx23885/cx23888-ir.c
b/drivers/media/pci/cx23885/cx23888-ir.c
index c1aa888..5bf7abb 100644
--- a/drivers/media/pci/cx23885/cx23888-ir.c
+++ b/drivers/media/pci/cx23885/cx23888-ir.c
@@ -696,10 +696,8 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
if (v > IR_MAX_DURATION)
v = IR_MAX_DURATION;
- init_ir_raw_event(&p->ir_core_data);
- p->ir_core_data.pulse = u;
- p->ir_core_data.duration = v;
- p->ir_core_data.timeout = w;
+ p->ir_core_data = (struct ir_raw_event)
+ { .pulse = u, .duration = v, .timeout = w };
v4l2_dbg(2, ir_888_debug, sd, "rx read: %10u ns %s %s\n",
v, u ? "mark" : "space", w ? "(timed out)" : "");
diff --git a/drivers/media/pci/cx88/cx88-input.c
b/drivers/media/pci/cx88/cx88-input.c
index 3f1342c..c0ed801 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -529,7 +529,7 @@ void cx88_ir_irq(struct cx88_core *core)
Re: gstreamer: v4l2videodec plugin
I'm using the following pipeline: GST_GL_PLATFORM=egl GST_GL_API=gles2 gst-launch-1.0 $GSTDEBUG $GSTFILESRC ! qtdemux name=m m.video_0 ! h264parse ! v4l2video32dec capture-io-mode=dmabuf ! glimagesink I stalled on this error: eglimagememory gsteglimagememory.c:473:gst_egl_image_memory_from_dmabuf:>>> llocator0> eglCreateImage failed: EGL_BAD_MATCH which in Mesa is: libEGL debug: EGL user error 0x3009 (EGL_BAD_MATCH) in dri2_create_image_khr_texture Do someone know how the dmabuf import is tested when the support has been added to glimagesink? Or some pointers how to continue with debugging? >> >> So far the DMABuf support in glimagesink has been tested on Intel/Mesa >> and libMALI. There is work in progress in Gallium/Mesa, but until >> recently there was no support for offset in imported buffer, which >> would result in BAD_MATCH error. I cannot guaranty this is the exact >> reason here, BAD_MATCH is used for a very wide variety of reason in >> those extensions. The right place to dig into this issue would be >> through the Mesa list and/or Mesa code. Find out what is missing for >> you driver in Mesa and then I may help you further. > > I came down to these conditions > > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/dri/dri2.c?h=11.2#n1063 > > but I don't know how this is related. The gstreamer > (gst_egl_image_memory_from_dmabuf) doesn't set this "level" so it will > be zero. That was wrong assumption, the error comes from another Mesa function. I'm not sure still which one dri2_from_dma_bufs() or dri2_create_image_dma_buf(). Will try to rebuild Mesa. -- regards, Stan -- 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: Kernel docs: muddying the waters a bit
Hi Markus, On 04/08/16 17:12, Markus Heiser wrote: > Hi kernel-doc authors, > > motivated by this MT, I implemented a toolchain to migrate the kernel’s > DocBook XML documentation to reST markup. > > It converts 99% of the docs well ... to gain an impression how > kernel-docs could benefit from, visit my sphkerneldoc project page > on github: > > http://return42.github.io/sphkerneldoc/ > > The sources available at: > > https://github.com/return42/sphkerneldoc > > The work is underway, suggestions are welcome! I have to admit that this looks pretty good :-) My main remark based on my quick scan through the docs is that anything in typewriter font seems to be shown as red text with a rectangle around it. That's quite jarring for me and I think it should be just shown as normal text, just using a non-proportional font, just like in the original. I also noticed that the 'title' of tables ends with a '¶' character for some reason. See e.g. the struct v4l2_audioout table in http://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/vidioc-g-audioout.html Regards, Hans > > .. have a nice weekend .. > > --M-- > > > Am 13.03.2016 um 16:33 schrieb Markus Heiser : > >> >> Am 10.03.2016 um 16:21 schrieb Mauro Carvalho Chehab >> : >> >>> Em Thu, 10 Mar 2016 12:25:58 +0200 >>> Jani Nikula escreveu: >>> TL;DR? Skip to the last paragraph. On Wed, 09 Mar 2016, Mauro Carvalho Chehab wrote: > I guess the conversion to asciidoc format is now in good shape, > at least to demonstrate that it is possible to use this format for the > media docbook. Still, there are lots of broken references. Getting references right with asciidoc is a big problem in the kernel-doc side. As I wrote before, the proofs of concept only worked because everything was processed as one big file (via includes). The Asciidoctor inter-document references won't help, because we won't know the target document name while processing kernel-doc. >>> >>> I was able to produce chunked htmls here with: >>> >>> asciidoctor -b docbook45 media_api.adoc >>> xmlto -o html-dir html media_api.xml >>> >>> The results are at: >>> >>> https://mchehab.fedorapeople.org/media-kabi-docs-test/asciidoc_tests/chunked/ >>> >>> But yeah, all references seem to be broken there. It could be due to some >>> conversion issue (I didn't actually tried to check what's wrong there), >>> but I think that there's something not ok with docbook45 >>> output for multi-part documents (on both AsciiDoc and Asciidoctor). >>> Sphinx is massively better at handling cross references for kernel-doc. We can use domains (C language) and roles (e.g. functions, types, etc.) for the references, which provide kind of namespaces. Sphinx warns for referencing non-existing targets, but doesn't generate broken links in the result like Asciidoctor does. For example, in the documentation for a function that has struct foo as parameter or return type, a cross reference to struct foo is added automagically, but only if documentation for struct foo actually exists. In Asciidoctor, we would have to blindly generate the references ourselves, and try to resolve broken links ourselves by somehow post-processing the result. > Yet, from my side, if we're willing to get rid of DocBook, then > Asciidoctor seems to be the *only* alternative so far to parse the > complex media documents. I think you mean, "get rid of DocBook as source format", not altogether? I'm yet to be convinved we could rely on Asciidoctor's native formats. >>> >>> What I mean is that, right now, I see only two alternatives for the >>> media uAPI documentation: >>> 1) keep using DocBook; >>> 2) AsciiDoc/Asciidoctor. >>> >>> Sphinx doesn't have what's needed to support the complexity of the >>> media books, specially since cell span seems to be possible only >>> by using asciiArt formats. Writing a big table using asciiArt is >>> something that is a *real pain*. Also, as tested, if the table is >>> too big, it fails to parse such asciiArt tables. So, while Sphinx >>> doesn't have a decent way to describe tables, we can't use it. >> >> >> Huge tables and cell-spans are the *real pain* ;-) ... with sphinx-doc, >> (mostly) you have more then one choice .. e.g. import csv tables .. >> but this should be discussed by example ... >> >> >>> If it starts implementing it, then we can check if the other >>> features used by the media documentation are also supported. >>> Probably, multi-part books would be another pain with Sphinx. >>> We have actually 4 books inside a common body. A few chapters >>> (like book licensing, bibliography, error codes) are shared >>> by all 4 documents. >>> >>> But, so far, I can't see any way to port media books without >>> lots of lot of work to develop new features at the Sphinx code. >> >> >> may I can help you ... >> >>
Re: gstreamer: v4l2videodec plugin
Hi Nicolas, On 04/11/2016 07:25 PM, Nicolas Dufresne wrote: > Le lundi 11 avril 2016 à 15:11 +0300, Stanimir Varbanov a écrit : >> adding gstreamer-devel >> >> On 04/11/2016 03:03 PM, Stanimir Varbanov wrote: >>> >>> Hi, >>> >>> I'm working on QCOM v4l2 video decoder/encoder driver and in order >>> to >>> test its functionalities I'm using gstreamer v4l2videodec plugin. I >>> am >>> able to use the v4l2videodec plugin with MMAP, now I want to try >>> the >>> dmabuf export from v4l2 and import dmabuf buffers to glimagesink. I >>> upgraded gst to 1.7.91 so that I have the dmabuf support in >>> glimagesink. >>> Mesa version is 11.1.2. > > I'm very happy to see this report. So far, we only had report that this > element works on Freescale IMX.6 (CODA) and Exynos 4/5. In this context, I would be very happy to see v4l2videoenc merged soon :) > >>> >>> I'm using the following pipeline: >>> >>> GST_GL_PLATFORM=egl GST_GL_API=gles2 gst-launch-1.0 $GSTDEBUG >>> $GSTFILESRC ! qtdemux name=m m.video_0 ! h264parse ! v4l2video32dec >>> capture-io-mode=dmabuf ! glimagesink >>> >>> I stalled on this error: >>> >>> eglimagememory >>> gsteglimagememory.c:473:gst_egl_image_memory_from_dmabuf:>> llocator0> >>> eglCreateImage failed: EGL_BAD_MATCH >>> >>> which in Mesa is: >>> >>> libEGL debug: EGL user error 0x3009 (EGL_BAD_MATCH) in >>> dri2_create_image_khr_texture >>> >>> Do someone know how the dmabuf import is tested when the support >>> has >>> been added to glimagesink? Or some pointers how to continue with >>> debugging? > > So far the DMABuf support in glimagesink has been tested on Intel/Mesa > and libMALI. There is work in progress in Gallium/Mesa, but until > recently there was no support for offset in imported buffer, which > would result in BAD_MATCH error. I cannot guaranty this is the exact > reason here, BAD_MATCH is used for a very wide variety of reason in > those extensions. The right place to dig into this issue would be > through the Mesa list and/or Mesa code. Find out what is missing for > you driver in Mesa and then I may help you further. I came down to these conditions https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/dri/dri2.c?h=11.2#n1063 but I don't know how this is related. The gstreamer (gst_egl_image_memory_from_dmabuf) doesn't set this "level" so it will be zero. > > For the reference, the importation strategy we use in GStreamer has > been inspired of Kodi (xmbc). It consist of importing each YUV plane > seperatly using R8 and RG88 textures and doing the color conversion > using shaders. Though, if the frame is allocated as a single DMABuf, > this requires using offset to access the frame data, and that support Yep that is my case, the driver capture buffers has one plain, hence one dmabuf will be exported per buffer. > had only been recently added in Gallium base code and in Radeon driver > recently. I don't know if Freedreno, VC4 have that, and I know nouveau > don't. Rob, do we need to add something in Freedreno Gallium driver to handle dmabuf import? -- regards, Stan -- 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: gstreamer: v4l2videodec plugin
Hi Victor, On 04/11/2016 03:55 PM, Víctor M. Jáquez L. wrote: > On 04/11/16 at 03:11pm, Stanimir Varbanov wrote: >> adding gstreamer-devel >> >> On 04/11/2016 03:03 PM, Stanimir Varbanov wrote: >>> Hi, >>> >>> I'm working on QCOM v4l2 video decoder/encoder driver and in order to >>> test its functionalities I'm using gstreamer v4l2videodec plugin. I am >>> able to use the v4l2videodec plugin with MMAP, now I want to try the >>> dmabuf export from v4l2 and import dmabuf buffers to glimagesink. I >>> upgraded gst to 1.7.91 so that I have the dmabuf support in glimagesink. >>> Mesa version is 11.1.2. >>> >>> I'm using the following pipeline: >>> >>> GST_GL_PLATFORM=egl GST_GL_API=gles2 gst-launch-1.0 $GSTDEBUG >>> $GSTFILESRC ! qtdemux name=m m.video_0 ! h264parse ! v4l2video32dec >>> capture-io-mode=dmabuf ! glimagesink >>> >>> I stalled on this error: >>> >>> eglimagememory >>> gsteglimagememory.c:473:gst_egl_image_memory_from_dmabuf: >>> eglCreateImage failed: EGL_BAD_MATCH >>> >>> which in Mesa is: >>> >>> libEGL debug: EGL user error 0x3009 (EGL_BAD_MATCH) in >>> dri2_create_image_khr_texture >>> >>> Do someone know how the dmabuf import is tested when the support has >>> been added to glimagesink? Or some pointers how to continue with >>> debugging? > > Perhaps this is not useful for your case, but there's a kmssink (a simple > video sink that uses KMS/DRM kernel API)[1]. It supports dmabuf import and > rendering, and the way it does it is heavily inspired on how glimagesink does > it, obviously without the EGL burden, just the kernel's PRIME API. Thanks for the info, I've searched few times for such an element in gstreamer. I find it useful and will give it a try when it is merged. -- regards, Stan -- 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
