[RFC] v4l: omap4iss: DT bindings development
Hi Everyone, I'm working on the DT bindings for the OMAP4 ISS at the moment, but I am unable to capture any data in my test setup. As detailed below, it seems that everything has been configured correctly however I never get any interrupts from the ISS unless I do something drastic like removing one of the wires from the clock differential pair which results in constant complex IO error interrupts from CSIA until I restore the physical connection. My test setup includes a OV6540 sensor camera module (MIPI) from Lepoard Imaging, an Duovero COM from Gumstix and breakout boards forming an interconnect between the two. The sensor is connected to CSI21 on the OMAP4 using a clock lane (on position 1, default polarity) and a single data lane (on position 2, default polarity), the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds to 19.2MHz when asked for 24MHz). The relevant parts of my device tree can be seen here: https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually somewhat unclear what effect stating the ti,hwmod=iss parameter has. Does anything else need to be done here? As far as I can tell I think all clocks and power has been switched on. I do make two function calls to the PM API in the ISS probe function, i.e.: pm_runtime_enable(pdev-dev); r = pm_runtime_get_sync(pdev-dev); Regarding my debugging, this is what I have checked so far * Changing the pixel rate of the sensor - this lead me to discover a possible bug in iss.c or perhaps my ov5640 driver, as the V4L2_CID_PIXEL_RATE control was always returning zero. I patched this by copying what Laurent has done in the OMAP3ISP driver which now works. * As I only have a 100MHz scope, I had to slow down the camera significantly (MIPI clock = 10-12MHz range) to verify that I was getting reasonable output from the sensor (i.e. signals that were characteristic of CSI2/MIPI). I checked the calculations and made sure these updated values came across via the V4L2_CID_PIXEL_RATE control and ended up in the THS_TERM and THS_SETTLE fields of register 0. * Using the omapconf tool, I have manually and one by one pulled up the CSI2 pins and verified multiple times all connections to the sensor module and have even manually tried swapping the DP/DN pairs in case they were still somehow backwards despite previous testing * Verified that the interrupt service routine is called by generating a test interrupt HS_VS from inside the ISS i.e. ./omapconf write ISS_HL_IRQENABLE_SET_5 0x0002 ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x0002 * Verified that the default CMA region is being used, it ends up in the ping-pong resisters of the ISS. Additional information: * Initialisation of pipe line and stream commands: media-ctl -r -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS CSI2a output:0 [1]' media-ctl -V 'ov5640 2-003c:0 [UYVY 640x480]','OMAP4 ISS CSI2a:0 [UYVY 640x480]' yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy * Output from OMAPCONF tool is in the second part of: https://gist.github.com/allsey87/fdf1feb6eb6a94158638 Anyway, at this point, I'm almost completely out of ideas on how to move forwards so any suggestions, criticisms or help of any nature would be appreciated! All the best, -- Michael Allwright PhD Student Paderborn Institute for Advanced Studies in Computer Science and Engineering University of Paderborn Office-number 02-47 Zukunftsmeile 1 33102 Paderborn Germany -- 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 00/35] Improve DVB frontend API documentation
Hi Jon, Em Tue, 02 Jun 2015 12:12:29 +0900 Jonathan Corbet cor...@lwn.net escreveu: On Thu, 28 May 2015 18:49:03 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: This is the first series of patches that will improve the DVB documentation. I've done a *quick* pass over these and sent a few comments, but they are all on the trivial-detail side of things. Looks good in general. Thanks for the review! I'll address them, on a separate patch. Would you like me to carry these in the docs tree, or will you sent them up yourself? Feel free to add my ack if you want in the latter case. I prefer to send it via my tree, if you don't mind. There are some automation at the DocBook/media/Makefile that links the latest version of the UAPI headers and create cross-references between what's there with what's documented. With that, if a patch add new API stuff but don't add documentation, xmlmint will produce warnings. Those are been very helpful to double check if the API is fully documented[1]. Also, there are some scripting at linuxtv.org that updates the documentation there once a day from what's committed on my tree: http://linuxtv.org/downloads/v4l-dvb-apis/ So, merging it via my tree is better. [1] Yet, it doesn't handle enums vars that are largely used on DVB API. I intend to write a new parser for that too on a next patch. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/35] Improve DVB frontend API documentation
On Tue, 2 Jun 2015 06:26:13 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: I prefer to send it via my tree, if you don't mind. That's fine. 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
Re: [PATCH v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
Hi Sakari,
On 06/01/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Mon, May 25, 2015 at 05:13:57PM +0200, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Thanks for adding indicator support!
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
I missed one thing - sysfs interface of the indicator LED class
also has to be disabled/enabled of v4l2_flash_open/close.
I am planning to reimplement the functions as follows,
please let me know if you see any issues here:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh))
goto unlock;
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
mutex_lock(led_cdev_ind-led_access);
led_sysfs_disable(led_cdev_ind);
led_trigger_remove(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
}
ret = __sync_device_with_v4l2_controls(v4l2_flash);
unlock:
mutex_unlock(led_cdev-led_access);
return ret;
}
static int v4l2_flash_close(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
mutex_lock(led_cdev-led_access);
if (v4l2_fh_is_singular(fh-vfh)) {
if (v4l2_flash-ctrls[STROBE_SOURCE])
ret =
v4l2_ctrl_s_ctrl(v4l2_flash-ctrls[STROBE_SV4L2_FLASH_STROBE_SOURCE_SOFTWARE);
led_sysfs_enable(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
mutex_lock(led_cdev_ind-led_access);
led_sysfs_enable(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
}
}
mutex_unlock(led_cdev-led_access);
return ret;
}
--
Best Regards,
Jacek Anaszewski
--
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] media: i2c: add new driver for single string flash.
Hi Daniel and Andy,
My apologies for a late answer; you can always ping me.
On Wed, Jan 21, 2015 at 10:12:05AM +0900, Daniel Jeong wrote:
Hi.
On Mon, 2015-01-19 at 17:25 +0900, Daniel Jeong wrote:
This patch adds the driver for the single string flash products of TI.
Several single string flash controllers of TI have similar register map
and bit data. This driver supports four products,lm3556, lm3561, lm3642
and lm3648.
Why not to name it as lm3648 to be in align with other drivers?
I tried to match it with the above line. I will fix it.
Or even better solution (I suppose) to create a library and on top of
that one driver per each device?
Sakari, what do you think?
Sakrai, I'd like to keep it but please let me know your opinion.
The rest of the drivers use the chip name. If you google for ti single
string flash, this patch is actually what you get as the second hit. The
first one is lm3639a spec which is not included in the above list. :-)
I'd use the chip name, e.g. lm3556.
In the future you should implement LED flash class drivers for such devices
instead, the V4L2 flash LED class wrapper gives you V4L2 flash API as well.
I think this one is good to go from that viewpoint though IMO, as the flash
API wrapper was not ready back then. Feel free to convert the driver though.
There's an additional matter to consider: lm3556 is partially supported by a
LED class drivers. Perhaps the plain LED class support could be replaced by
LED flash class support and the old driver renamed, as it'd only support a
single chip then.
Signed-off-by: Daniel Jeong gshark.je...@gmail.com
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ti-ss-flash.c | 744
+++
include/media/ti-ss-flash.h | 33 ++
4 files changed, 787 insertions(+)
create mode 100644 drivers/media/i2c/ti-ss-flash.c
create mode 100644 include/media/ti-ss-flash.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 205d713..886c1fb 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -638,6 +638,15 @@ config VIDEO_LM3646
This is a driver for the lm3646 dual flash controllers. It controls
flash, torch LEDs.
+config VIDEO_TI_SS_FLASH
+ tristate TI Single String Flash driver support
The list of the chip names fits here, how about putting those instead?
+ depends on I2C VIDEO_V4L2 MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ select REGMAP_I2C
+ ---help---
+ This is a driver for the signle string flash controllers of TI.
+ It supports LM3556, LM3561, LM3642 and LM3648.
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..0e523ec 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o
obj-$(CONFIG_VIDEO_LM3560)+= lm3560.o
obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
+obj-$(CONFIG_VIDEO_TI_SS_FLASH)+= ti-ss-flash.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL)+= smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X)+= ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/ti-ss-flash.c
b/drivers/media/i2c/ti-ss-flash.c
new file mode 100644
index 000..035aeba
--- /dev/null
+++ b/drivers/media/i2c/ti-ss-flash.c
@@ -0,0 +1,744 @@
+/*
+ * drivers/media/i2c/ti-ss-flash.c
+ * General device driver for Single String FLASH LED Drivers of TI
+ * It covers lm3556, lm3561, lm3642 and lm3648.
+ *
+ * Copyright (C) 2015 Texas Instruments
+ *
+ * Contact: Daniel Jeong gshark.je...@gmail.com
+ * Ldd-Mlp ldd-...@list.ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/ti-ss-flash.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+
+/* operation mode */
+enum led_opmode {
+ OPMODE_SHDN = 0x0,
+ OPMODE_INDI_IR,
+ OPMODE_TORCH,
+ OPMODE_FLASH,
+};
+
+/*
+ * register data
+ * @reg : register
+ * @mask : mask bits
+ * @shift : bit shift of data
+ */
+struct ctrl_reg {
+ unsigned int reg;
+ unsigned int mask;
+ unsigned int shift;
+};
+
+/*
+ * unit data
+ * @min : min value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @step : step value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @knee: knee point of step of brightness/timeout
+ *
[PATCH] [media] v4l2-ioctl: Give more information when device_caps are missing
Currently, the warning for missing device_caps gives a backtrace like so: [8175c199] dump_stack+0x45/0x57 [8109ad5a] warn_slowpath_common+0x8a/0xc0 [8109ae8a] warn_slowpath_null+0x1a/0x20 [a0237453] v4l_querycap+0x43/0x80 [videodev] [a0237734] __video_do_ioctl+0x2a4/0x320 [videodev] [812207e5] ? do_last+0x195/0x1210 [a023a11e] video_usercopy+0x22e/0x5b0 [videodev] [a0237490] ? v4l_querycap+0x80/0x80 [videodev] [a023a4b5] video_ioctl2+0x15/0x20 [videodev] [a0233733] v4l2_ioctl+0x113/0x150 [videodev] [81225798] do_vfs_ioctl+0x2f8/0x4f0 [8113b2d4] ? __audit_syscall_entry+0xb4/0x110 [81022d7c] ? do_audit_syscall_entry+0x6c/0x70 [81225a11] SyS_ioctl+0x81/0xa0 [8113b526] ? __audit_syscall_exit+0x1f6/0x2a0 [81763549] system_call_fastpath+0x12/0x17 This indicates that device_caps are missing but doesn't give much of a clue which driver is actually at fault. Improve the warning output by showing the capabilities and which operations set the capabilities. Signed-off-by: Laura Abbott labb...@fedoraproject.org --- drivers/media/v4l2-core/v4l2-ioctl.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index aa407cb..e509608 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1023,8 +1023,9 @@ static int v4l_querycap(const struct v4l2_ioctl_ops *ops, * Drivers MUST fill in device_caps, so check for this and * warn if it was forgotten. */ - WARN_ON(!(cap-capabilities V4L2_CAP_DEVICE_CAPS) || - !cap-device_caps); + WARN(!(cap-capabilities V4L2_CAP_DEVICE_CAPS) || + !cap-device_caps, Bad caps for ops %pS, %x %x, + ops, cap-capabilities, cap-device_caps); cap-device_caps |= V4L2_CAP_EXT_PIX_FORMAT; return ret; -- 2.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] DocBook: specify language and encoding for the document
Define the usage of UTF-8 encoding and let clear that the document is in English. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 43eda245a1b5..6591b3a37600 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -1,4 +1,4 @@ -?xml version=1.0? +?xml version=1.0 encoding=UTF-8? !DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; [ !ENTITY % media-entities SYSTEM ./media-entities.tmpl %media-entities; @@ -33,7 +33,7 @@ !ENTITY dash-ent-24 entry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entryentry-/entry ] -book id=media_api +book id=media_api lang=en bookinfo titleLINUX MEDIA INFRASTRUCTURE API/title -- 2.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] [media] DocBook: Use constant tag for monospaced fonts
As reminded by Jonathan, several places where emphasys
role=tt were used are actually trying to change the font to
monospaced.
We do that, on other places, by using the constant tag.
So, use it here too.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/dvb/audio.xml
b/Documentation/DocBook/media/dvb/audio.xml
index a853e5b81ec7..ea56743ddbe7 100644
--- a/Documentation/DocBook/media/dvb/audio.xml
+++ b/Documentation/DocBook/media/dvb/audio.xml
@@ -1,7 +1,7 @@
titleDVB Audio Device/title
paraThe DVB audio device controls the MPEG2 audio decoder of the DVB
hardware. It
-can be accessed through emphasis
role=bold/dev/dvb/adapter0/audio0/emphasis. Data types and and
-ioctl definitions can be accessed by including emphasis
role=boldlinux/dvb/audio.h/emphasis in your
+can be accessed through constant/dev/dvb/adapter?/audio?/constant. Data
types and and
+ioctl definitions can be accessed by including
constantlinux/dvb/audio.h/constant in your
application.
/para
paraPlease note that some DVB cards don#8217;t have their own MPEG decoder,
which results in
@@ -32,7 +32,7 @@ typedef enum {
/programlisting
paraAUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend
or the
DVR device) as the source of the video stream. If AUDIO_SOURCE_MEMORY
-is selected the stream comes from the application through the emphasis
role=boldwrite()/emphasis system
+is selected the stream comes from the application through the
constantwrite()/constant system
call.
/para
diff --git a/Documentation/DocBook/media/dvb/ca.xml
b/Documentation/DocBook/media/dvb/ca.xml
index bf9e790d674f..d0b07e763908 100644
--- a/Documentation/DocBook/media/dvb/ca.xml
+++ b/Documentation/DocBook/media/dvb/ca.xml
@@ -1,7 +1,7 @@
titleDVB CA Device/title
paraThe DVB CA device controls the conditional access hardware. It can be
accessed through
-emphasis role=bold/dev/dvb/adapter0/ca0/emphasis. Data types and and
ioctl definitions can be accessed by
-including emphasis role=boldlinux/dvb/ca.h/emphasis in your application.
+constant/dev/dvb/adapter?/ca?/constant. Data types and and ioctl
definitions can be accessed by
+including constantlinux/dvb/ca.h/constant in your application.
/para
section id=ca_data_types
diff --git a/Documentation/DocBook/media/dvb/demux.xml
b/Documentation/DocBook/media/dvb/demux.xml
index fae0e0556ca5..11a831d58643 100644
--- a/Documentation/DocBook/media/dvb/demux.xml
+++ b/Documentation/DocBook/media/dvb/demux.xml
@@ -1,8 +1,8 @@
titleDVB Demux Device/title
paraThe DVB demux device controls the filters of the DVB hardware/software.
It can be
-accessed through emphasis role=bold/dev/adapter0/demux0/emphasis. Data
types and and ioctl definitions can be
-accessed by including emphasis role=boldlinux/dvb/dmx.h/emphasis in your
application.
+accessed through constant/dev/adapter?/demux?/constant. Data types and and
ioctl definitions can be
+accessed by including constantlinux/dvb/dmx.h/constant in your application.
/para
section id=dmx_types
titleDemux Data Types/title
@@ -21,11 +21,11 @@ typedef enum
DMX_OUT_TSDEMUX_TAP /#x22C6; Like TS_TAP but retrieved from the DMX
device #x22C6;/
} dmx_output_t;
/programlisting
-paraemphasis role=boldDMX_OUT_TAP/emphasis delivers the stream output
to the demux device on which the ioctl is
+paraconstantDMX_OUT_TAP/constant delivers the stream output to the demux
device on which the ioctl is
called.
/para
-paraemphasis role=boldDMX_OUT_TS_TAP/emphasis routes output to the
logical DVR device emphasis role=bold/dev/dvb/adapter0/dvr0/emphasis,
-which delivers a TS multiplexed from all filters for which emphasis
role=boldDMX_OUT_TS_TAP/emphasis was
+paraconstantDMX_OUT_TS_TAP/constant routes output to the logical DVR
device constant/dev/dvb/adapter?/dvr?/constant,
+which delivers a TS multiplexed from all filters for which
constantDMX_OUT_TS_TAP/constant was
specified.
/para
/section
diff --git a/Documentation/DocBook/media/dvb/frontend.xml
b/Documentation/DocBook/media/dvb/frontend.xml
index dc6a1134478d..01210b33c130 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -14,9 +14,9 @@
listitemparaSatellite Equipment Control (SEC) hardware (only for
Satellite)./para/listitem
/itemizedlist
paraThe frontend can be accessed through
-emphasis role=bold/dev/dvb/adapter?/frontend?/emphasis. Data types
and
+constant/dev/dvb/adapter?/frontend?/constant. Data types and
ioctl definitions can be accessed by including
-emphasis role=boldlinux/dvb/frontend.h/emphasis in your application.
+constantlinux/dvb/frontend.h/constant in your application.
/para
paraNOTE: Transmission via the internet (DVB-IP)
diff --git a/Documentation/DocBook/media/dvb/intro.xml
b/Documentation/DocBook/media/dvb/intro.xml
index 1f7a35a2b365..bcc72c216402 100644
--- a/Documentation/DocBook/media/dvb/intro.xml
+++
[PATCH 2/5] DocBook: Change DTD schema to version 4.5
According with the docs at docbook.org, no backward compatible changes were done between 4.2 and 4.5 schemas. Some fixes were added, together with new features. So, let's use the latest 4.x schema. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 6591b3a37600..2e7d7692821e 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8? -!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.2//EN - http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; [ +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.5//EN + http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [ !ENTITY % media-entities SYSTEM ./media-entities.tmpl %media-entities; !ENTITY media-indices SYSTEM ./media-indices.tmpl -- 2.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] [media] Docbook: typo fix: use note(d) instead of notice(d)
We don't want to announce anything, but to add a note ;)
So:
notice - note
notided - noted
While here, fix another typo at media_api.tmpl:
with - which
Reported-by: Jonathan Corbet cor...@lwn.net
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 5dfde521e9fe..746b4e2ae346 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -193,7 +193,7 @@ get/set up to 64 properties. The actual meaning of each
property is described on
paraMost of the digital TV standards currently offers more than one possible
modulation (sometimes called as constellation on some standards). This
-enum contains the values used by the Kernel. Please notice that not all
+enum contains the values used by the Kernel. Please note that not all
modulations are supported by a given standard./para
table pgwide=1 frame=none id=fe-modulation
@@ -1098,7 +1098,7 @@ enum fe_interleaving {
paraFor most delivery systems,
constantdtv_property.stat.len/constant
will be 1 if the stats is supported, and the properties will
return a single value for each parameter./para
- paraIt should be noticed, however, that new OFDM delivery systems
+ paraIt should be noted, however, that new OFDM delivery systems
like ISDB can use different modulation types for each group of
carriers. On such standards, up to 3 groups of statistics can be
provided, and constantdtv_property.stat.len/constant is
updated
@@ -1162,7 +1162,7 @@ enum fe_interleaving {
titleconstantDTV_STAT_PRE_TOTAL_BIT_COUNT/constant/title
paraMeasures the amount of bits received before the inner
code block, during the same period as
link
linkend=DTV-STAT-PRE-ERROR-BIT-COUNTconstantDTV_STAT_PRE_ERROR_BIT_COUNT/constant/link
measurement was taken./para
- paraIt should be noticed that this measurement can be smaller
than the total amount of bits on the transport stream,
+ paraIt should be noted that this measurement can be smaller
than the total amount of bits on the transport stream,
as the frontend may need to manually restart the
measurement, losing some data between each measurement interval./para
paraThis measurement is monotonically increased, as the
frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is
tuned./para
@@ -1191,7 +1191,7 @@ enum fe_interleaving {
titleconstantDTV_STAT_POST_TOTAL_BIT_COUNT/constant/title
paraMeasures the amount of bits received after the inner
coding, during the same period as
link
linkend=DTV-STAT-POST-ERROR-BIT-COUNTconstantDTV_STAT_POST_ERROR_BIT_COUNT/constant/link
measurement was taken./para
- paraIt should be noticed that this measurement can be smaller
than the total amount of bits on the transport stream,
+ paraIt should be noted that this measurement can be smaller
than the total amount of bits on the transport stream,
as the frontend may need to manually restart the
measurement, losing some data between each measurement interval./para
paraThis measurement is monotonically increased, as the
frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is
tuned./para
diff --git a/Documentation/DocBook/media/dvb/frontend.xml
b/Documentation/DocBook/media/dvb/frontend.xml
index 9d8e95cd9694..dc6a1134478d 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -48,7 +48,7 @@ specification is available at
paraThe information about the frontend tuner locking status can be queried
using link linkend=FE_READ_STATUSFE_READ_STATUS/link./para
paraSignal statistics are provided via link
linkend=FE_GET_PROPERTYconstantFE_GET_PROPERTY/constant/link.
-Please notice that several statistics require the demodulator to be fully
+Please note that several statistics require the demodulator to be fully
locked (e. g. with FE_HAS_LOCK bit set). See
link linkend=frontend-stat-propertiesFrontend statistics
indicators/link
for more details./para
diff --git a/Documentation/DocBook/media/v4l/remote_controllers.xml
b/Documentation/DocBook/media/v4l/remote_controllers.xml
index 5124a6c4daa8..b86844e80257 100644
--- a/Documentation/DocBook/media/v4l/remote_controllers.xml
+++ b/Documentation/DocBook/media/v4l/remote_controllers.xml
@@ -284,7 +284,7 @@ different IR's. Due to that, V4L2 API now specifies a
standard for mapping Media
/tgroup
/table
-paraIt should be noticed that, sometimes, there some fundamental
[PATCH 4/5] [media] DocBook: fix some syntax issues at dvbproperty.xml
Some minor English syntax fixes. Reported-by: Jonathan Corbet cor...@lwn.net Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 746b4e2ae346..28e306ee5827 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -1,12 +1,12 @@ section id=frontend-properties titleDVB Frontend properties/title paraTuning into a Digital TV physical channel and starting decoding it -requires to change a set of parameters, in order to control the +requires changing a set of parameters, in order to control the tuner, the demodulator, the Linear Low-noise Amplifier (LNA) and to set the antenna subsystem via Satellite Equipment Control (SEC), on satellite systems. The actual parameters are specific to each particular digital -TV standards, and may change as the digital TV specs evolutes./para -paraIn the past, the strategy used were to have an union with the parameters +TV standards, and may change as the digital TV specs evolves./para +paraIn the past, the strategy used was to have a union with the parameters needed to tune for DVB-S, DVB-C, DVB-T and ATSC delivery systems grouped there. The problem is that, as the second generation standards appeared, those structs were not big enough to contain the additional parameters. -- 2.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v4.2] Add support for the colorspace transfer function
This patch series adds support to explicitly specify the colorspace transfer function. This was always implicitly defined by the colorspace, but (as I suspected that it might happen) this turned out not to work. In practice it is an independent setting in its own right and it is commonly specified as such (EDID, metadata inside compressed video streams). In addition, you need this if you want to be able to specify linear RGB data such as is often returned by raw sensor images and as is used by openGL. The next step once this is merged is to start providing support for colorspace conversion hardware. Regards, Hans The following changes since commit c1c3c85ddf60a6d97c122d57d385b4929fcec4b3: [media] DocBook: fix FE_SET_PROPERTY ioctl arguments (2015-06-01 06:10:15 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git xfer for you to fetch changes up to 7d7627ee142035c9b9656da0219973814f6afa9a: vivid.txt: update the vivid documentation (2015-06-02 08:27:14 +0200) Hans Verkuil (9): videodev2.h: add support for transfer functions DocBook/media: document new xfer_func fields. adv7511: add xfer_func support am437x-vpfe: add support for xfer_func vivid: add xfer_func support. vivid-tpg: precalculate colorspace/xfer_func combinations cobalt: support transfer function cobalt: simplify colorspace code vivid.txt: update the vivid documentation Documentation/DocBook/media/v4l/pixfmt.xml | 113 ++ Documentation/DocBook/media/v4l/subdev-formats.xml | 12 +- Documentation/video4linux/vivid.txt| 30 +++-- drivers/media/i2c/adv7511.c| 5 + drivers/media/pci/cobalt/cobalt-driver.h | 1 + drivers/media/pci/cobalt/cobalt-v4l2.c | 17 ++- drivers/media/platform/am437x/am437x-vpfe.c| 3 +- drivers/media/platform/vivid/vivid-core.h | 1 + drivers/media/platform/vivid/vivid-ctrls.c | 58 ++--- drivers/media/platform/vivid/vivid-tpg-colors.c| 478 +++-- drivers/media/platform/vivid/vivid-tpg-colors.h| 4 +- drivers/media/platform/vivid/vivid-tpg.c | 13 +- drivers/media/platform/vivid/vivid-tpg.h | 19 +++ drivers/media/platform/vivid/vivid-vid-cap.c | 9 ++ drivers/media/platform/vivid/vivid-vid-common.c| 2 + drivers/media/platform/vivid/vivid-vid-out.c | 4 + drivers/media/v4l2-core/v4l2-ioctl.c | 9 +- include/media/v4l2-mediabus.h | 2 + include/uapi/linux/v4l2-mediabus.h | 4 +- include/uapi/linux/videodev2.h | 41 ++- 20 files changed, 640 insertions(+), 185 deletions(-) -- 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] media: videobuf2-dc: set properly dma_max_segment_size
Hi Marek,
Thank you for the patch.
On Monday 01 June 2015 14:14:17 Marek Szyprowski wrote:
If device has no DMA max_seg_size set, we assume that there is no limit
and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
let DMA-mapping API always create contiguous mappings in DMA address
space. This is essential for all devices, which use dma-contig
videobuf2 memory allocator.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c index
644dec73d220..9d7c1814b0f3 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -862,6 +862,23 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
void *vb2_dma_contig_init_ctx(struct device *dev)
{
struct vb2_dc_conf *conf;
+ int err;
+
+ /*
+ * if device has no max_seg_size set, we assume that there is no limit
+ * and force it to DMA_BIT_MASK(32) to always use contiguous mappings
+ * in DMA address space
+ */
+ if (!dev-dma_parms) {
+ dev-dma_parms = kzalloc(sizeof(*dev-dma_parms), GFP_KERNEL);
I was checking how dma_parms was usually allocated and freed, and was shocked
to find that the memory is never freed. OK, actually not shocked, I had a bad
feeling about it already, but it's still not good :-/
This goes beyond the scope of this patch, but I think we need to clean up
dma_parms. The structure is 8 bytes long on 32-bit systems and 16 bytes long
on 64-bit systems. I wonder if it's really worth it to allocate it separately
from struct device. It might if we moved more DMA-related fields to struct
device_dma_parameters but that hasn't happened since 2008 when the structure
was introduced (yes that's more than 7 years ago).
If we consider it's worth it (and I believe Josh Triplett might, in the
context of the Linux kernel tinification project), we should at least handle
allocation and free of the field coherently across drivers.
+ if (!dev-dma_parms)
+ return ERR_PTR(-ENOMEM);
+ }
+ if (dma_get_max_seg_size(dev) DMA_BIT_MASK(32)) {
+ err = dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
What if the device has set a maximum segment size smaller than 4GB because of
hardware limitations ?
I also wonder whether this is the correct place to solve the issue. Why is the
default value returned by dma_get_max_seg_size() set to 64kB ?
+ if (err)
+ return ERR_PTR(err);
+ }
conf = kzalloc(sizeof *conf, GFP_KERNEL);
if (!conf)
--
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] media: videobuf2-dc: set properly dma_max_segment_size
Hi Marek,
Thank you for the patch.
On Monday 01 June 2015 14:14:17 Marek Szyprowski wrote:
If device has no DMA max_seg_size set, we assume that there is no limit
and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
let DMA-mapping API always create contiguous mappings in DMA address
space. This is essential for all devices, which use dma-contig
videobuf2 memory allocator.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c index
644dec73d220..9d7c1814b0f3 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -862,6 +862,23 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
void *vb2_dma_contig_init_ctx(struct device *dev)
{
struct vb2_dc_conf *conf;
+ int err;
+
+ /*
+ * if device has no max_seg_size set, we assume that there is no limit
+ * and force it to DMA_BIT_MASK(32) to always use contiguous mappings
+ * in DMA address space
+ */
+ if (!dev-dma_parms) {
+ dev-dma_parms = kzalloc(sizeof(*dev-dma_parms), GFP_KERNEL);
I was checking how dma_parms was usually allocated and freed, and was shocked
to find that the memory is never freed. OK, actually not shocked, I had a bad
feeling about it already, but it's still not good :-/
This goes beyond the scope of this patch, but I think we need to clean up
dma_parms. The structure is 8 bytes long on 32-bit systems and 16 bytes long
on 64-bit systems. I wonder if it's really worth it to allocate it separately
from struct device. It might if we moved more DMA-related fields to struct
device_dma_parameters but that hasn't happened since 2008 when the structure
was introduced (yes that's more than 7 years ago).
If we consider it's worth it (and I believe Josh Triplett might, in the
context of the Linux kernel tinification project), we should at least handle
allocation and free of the field coherently across drivers.
+ if (!dev-dma_parms)
+ return ERR_PTR(-ENOMEM);
+ }
+ if (dma_get_max_seg_size(dev) DMA_BIT_MASK(32)) {
+ err = dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
What if the device has set a maximum segment size smaller than 4GB because of
hardware limitations ?
I also wonder whether this is the correct place to solve the issue. Why is the
default value returned by dma_get_max_seg_size() set to 64kB ?
+ if (err)
+ return ERR_PTR(err);
+ }
conf = kzalloc(sizeof *conf, GFP_KERNEL);
if (!conf)
--
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
tw5864 driver development, help needed
Hi! I am working on making a Linux driver for TW5864-based videoaudio capture and encoding PCI boards. The driver is to be submitted for inclusion to Linux upstream. The following two links are links to boards available for buying: http://www.provideo.com.tw/web/DVR%20Card_TW-310.htm http://www.provideo.com.tw/web/DVR%20Card_TW-320.htm We possess one 8-port board and we try to make it play. http://whdd.org/tw5864/TW-3XX_Linux.rar - this is reference driver code. Overwhelmingly complicated IMO. http://whdd.org/tw5864/tw5864b1-ds.pdf - Datasheet. http://whdd.org/tw5864/TW5864_datasheet_0.6d.pdf - Another datasheet. These two differ in some minor points. https://github.com/krieger-od/linux - my work in progress on this, in drivers/staging/media/tw5864 directory. Derived from drivers/media/pci/tw68 (which is raw video capture card), defined reasonable part of registers, now trying to make device produce video capture and encoding interrupts, but cannot get any interrupts except GPIO and timer ones. This is currently the critical blocking issue in development. I hope that somebody experienced with similar boards would have quesswork on how to proceed. My work-on-progress code is dirty, so if you would agree to check that only if it will be cleaned up, please let me know. I am willing to pay for productive help. -- Bluecherry developer. -- 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
dvbv5-tzap with pctv 290e/292e needs EAGAIN for pat/pmt to work when recording.
Running kernel 3.18.14 with git master v4l-utils and a pctv290e + a 292e.
If I try to record with dvbv5-zap and include the p option to get
pat/pmt I get -
read_sections: read error: Resource temporarily unavailable
couldn't find pmt-pid for sid 10bf
Doing this this fixes it for me (obviously not meant to be a a proper
patch).
diff --git a/lib/libdvbv5/dvb-demux.c b/lib/libdvbv5/dvb-demux.c
index 30d4eda..b520948 100644
--- a/lib/libdvbv5/dvb-demux.c
+++ b/lib/libdvbv5/dvb-demux.c
@@ -151,8 +151,10 @@ int dvb_get_pmt_pid(int patfd, int sid)
if (((count = read(patfd, buf, sizeof(buft))) 0)
errno == EOVERFLOW)
count = read(patfd, buf, sizeof(buft));
if (count 0) {
- perror(read_sections: read error);
- return -1;
+ if (errno == EAGAIN) /*ADF*/
+ continue;
+ perror(read_sections: read error);
+ return -1;
}
section_length = ((buf[1] 0x0f) 8) | buf[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 2/9] mm: Provide new get_vaddr_frames() helper
On Tue, 2 Jun 2015 17:23:00 +0200 Jan Kara j...@suse.cz wrote: That's a lump of new code which many kernels won't be needing. Can we put all this in a new .c file and select it within drivers/media Kconfig? So the attached patch should do what you had in mind. OK? lgtm. drivers/gpu/drm/exynos/Kconfig | 1 + drivers/media/platform/omap/Kconfig | 1 + drivers/media/v4l2-core/Kconfig | 1 + mm/Kconfig | 3 + mm/Makefile | 1 + mm/frame-vec.c | 233 But frame_vector.c would be a more pleasing name. For `struct frame_vector'. -- 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
Hauppauge WinTV-HVR2205 driver feedback
I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205. I thought I would post some feedback. I have recently compiled the driver as at 2015-05-31 using media build tree. I am unable to tune a channel. When running the following w_scan command: w_scan -a4 -ft -cAU -t 3 -X /tmp/tzap/channels.conf I get the following error after scanning the frequency range for Australia. ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! At the same time I get the following messages being logged to the Linux console. dmesg [165512.436662] si2168 22-0066: unknown chip version Si2168- [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30' [165512.480559] si2157 21-0060: firmware version: 3.0.5 [165517.981155] si2168 22-0064: unknown chip version Si2168- [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30' [165518.024867] si2157 20-0060: firmware version: 3.0.5 [165682.334171] si2168 22-0064: unknown chip version Si2168- [165730.579085] si2168 22-0064: unknown chip version Si2168- [165838.420693] si2168 22-0064: unknown chip version Si2168- [166337.342437] si2168 22-0064: unknown chip version Si2168- [167305.393572] si2168 22-0064: unknown chip version Si2168- Many thanks to the developers for all of your hard work. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Export alignment requirements for buffers
Hi Laurent, Thanks for looping me into this email chain, and apologies about not responding earlier; it just got lost in the barrage of things. On 1 June 2015 at 21:20, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Hans, On Monday 01 June 2015 11:44:51 Hans Verkuil wrote: One of the things that is really irritating is the fact that drivers that use contig-dma sometimes want to support USERPTR, allowing applications to pass pointers to the driver that point to physically contiguous memory that was somehow obtained, and that userspace has no way of knowing whether the driver has this requirement or not. A related issue is that, depending on the DMA engine, the user pointer might have some alignment requirements (page aligned, or at minimum 16 bytes aligned) that userspace has no way of knowing. The same alignment issue is present also for dma-buf. Doesn't the first issue also apply to DMABUF ? As you already know, I'm not a big fan of USERPTR when used for sharing buffers between devices. DMABUF is a much better choice there. USERPTR can still be helpful for other use cases though. One of them that comes to my mind is to capturing directly buffers allocated by a software codec (or another similar userspace library) that doesn't support externally allocated memory (although the core issue there would be the library design). Anyway, the problem of conveying memory constraints is identical in the DMABUF case, so a solution is needed. Yes, +1 on that. The problem posed here is similar in the sense of requirement of conveying memory constraints, but the key is probably the reverse direction - the userspace here *needs* to share constraints of _buffers_ obtained from elsewhere. I propose to take one reserved field from struct v4l2_create_buffers and from struct v4l2_requestbuffers and change it to this: __u32 flags; #define V4L2_REQBUFS_FL_ALIGNMENT_MSK 0x3f #define V4L2_REQBUFS_FL_PHYS_CONTIG (1 31) Where the alignment is a power of 2 (and if 0 the alignment is unknown). The max is 2^63, which should be enough for the foreseeable future :-) If the physically contiguous flag is set, then the buffer must be physically contiguous. These flags can be set for every vb2 dma implementation: dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless overridden by the driver) page aligned. dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the driver DMA implementation. Note: malloc will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. The flags field can be extended with things like OPAQUE if the buffers cannot be mmapped (since they are in protected memory). Comments? Alternative solutions? The question of conveying memory constraints has been raised several times in the past, without any solutions being merged. The work has been revived recently, see http://lists.freedesktop.org/archives/dri-devel/2015-February/076862.html for instance. Even if the API proposed here is specific to V4L2, and even if the patch set I linked to addresses a different problem, I believe it would be wise to widen the audience to make sure the solutions we come up with are at least aligned between subsystems. I've thus CC'ed Sumit to this e-mail as a start. So I've been (trying to) work out some way of conveying memory constraints between devices, and our idea was to get that added to struct device-dma_parameters; that ways, the userspace doesn't have to necessarily know of the constraints, and some negotiation can happen in the kernel itself. It doesn't at the moment concern with taking care of sharing those back to userspace, but I think that's an orthogonal thing to handle. Absolutely, it'd be great if we can come up with some aligned way of conveying these constraints. -- Regards, Laurent Pinchart -- Thanks and regards, Sumit Semwal Kernel SubTeam Lead - Linaro Mobile Group Linaro.org │ Open source software for ARM SoCs -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jun 3 04:00:19 CEST 2015 git branch: test git hash: c1c3c85ddf60a6d97c122d57d385b4929fcec4b3 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: 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.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/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
[patch] [media] m88ds3103: a couple missing error codes
We need to set some error codes here.
Fixes: f01919e8f54f ('[media] m88ds3103: add I2C client binding')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/dvb-frontends/m88ds3103.c
b/drivers/media/dvb-frontends/m88ds3103.c
index 01b9ded..7b21f1a 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -1563,6 +1563,7 @@ static int m88ds3103_probe(struct i2c_client *client,
u8tmp = 0x10;
break;
default:
+ ret = -EINVAL;
goto err_kfree;
}
@@ -1590,8 +1591,10 @@ static int m88ds3103_probe(struct i2c_client *client,
dev-i2c_adapter = i2c_add_mux_adapter(client-adapter, client-dev,
dev, 0, 0, 0, m88ds3103_select,
m88ds3103_deselect);
- if (dev-i2c_adapter == NULL)
+ if (dev-i2c_adapter == NULL) {
+ ret = -ENOMEM;
goto err_kfree;
+ }
/* create dvb_frontend */
memcpy(dev-fe.ops, m88ds3103_ops, sizeof(struct dvb_frontend_ops));
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/35] DocBook: fix emphasis at the DVB documentation
Em Tue, 02 Jun 2015 11:56:04 +0900 Jonathan Corbet cor...@lwn.net escreveu: On Thu, 28 May 2015 18:49:07 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Currently, it is using 'role=tt', but this is not defined at the DocBook 4.5 spec. The net result is that no emphasis happens. So, replace them to bold emphasis. Nit: I suspect the intent of the emphasis here was to get the code in a monospace font, which bold is unlikely to do. Isn't there a role=code or something useful like that to use? I'd have to go look. Good point! I think that emphasis only does italic (with is the default, and don't need role option) or bold on DocBook 4.5. We're using constant on the places where we want a monospace font. That's probably the right tag there. For the record: this document was produced by merging two different documents: the V4L docbook (that used a legacy DocBook version - 3.x or 2.x) and the DVB LaTex documentation, which was converted by some tool to docbook 3.x (or 2.x) to match the same DocBook spec that V4L were using. The 'role=tt' came from such conversion. This were maintained together with the legacy Mercurial tree that was used to contain the media drivers. When we moved to git, the DocBook got merged in the Kernel and another conversion was taken to allow compiling it using DocBook 4.x. We only checked the tags that didn't compile, but options with invalid arguments like 'role=tt' where xmllint doesn't complain weren't touched. One question: any plans to update the documentation to DocBook schema? We're using either schema 4.1 or 4.2, with are both very old. The latest 4.x is 4.5, with was written back on 2006. So, except for historic reasons, are there any reason why keeping them at version 4.2? I did a quick look at the DocBook specs (for 4.3, 4.4 and 4.5), and they say that no backward compatible changes were done. So, using version 4.5 should be straightforward. I applied this patch here: --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -2,2 +2,2 @@ -!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.2//EN - http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; [ +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.5//EN + http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [ and compiled the media documentation with: make cleanmediadocs make DOCBOOKS=media_api.xml htmldocs 21 | grep -v element.*: validity error : ID .* already defined xmllint --noent --postvalid $PWD/Documentation/DocBook/media_api.xml /tmp/x.xml 2/dev/null xmllint --noent --postvalid --noout /tmp/x.xml xmlto html-nochunks -m ./Documentation/DocBook/stylesheet.xsl -o Documentation/DocBook/media Documentation/DocBook/media_api.xml /dev/null 21 In order to try to produce errors. Everything seemed to work. On a quick look, the documentation looked fine, and no errors (except for some crappy element validity errors, with seems to be due to a bug on recent versions of the xml tools present on Fedora 22). Maybe 5.x would provide nicer documents, but converting to it doesn't seem too easy, although there are some semi-auto way of doing it, at least according with: http://doccookbook.sourceforge.net/html/en/dbc.structure.db4-to-db5.html Not sure if worth the efforts to convert to 5.x. 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: gpio-ir-recv: don't sleep in irq handler
Don't allow sleep when getting the gpio value in the irq-handler. On my rk3288 board this results in might_sleep warnings when receiving data like: BUG: sleeping function called from invalid context at drivers/gpio/gpiolib.c:1531 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 CPU: 0 PID: 0 Comm: swapper/0 Tainted: P4.1.0-rc5+ #2011 Hardware name: Rockchip (Device Tree) [c00189a0] (unwind_backtrace) from [c0013b04] (show_stack+0x20/0x24) [c0013b04] (show_stack) from [c0757970] (dump_stack+0x8c/0xbc) [c0757970] (dump_stack) from [c0053188] (___might_sleep+0x238/0x284) [c0053188] (___might_sleep) from [c0053264] (__might_sleep+0x90/0xa4) [c0053264] (__might_sleep) from [c02ff4ac] (gpiod_get_raw_value_cansleep+0x28/0x44) [c02ff4ac] (gpiod_get_raw_value_cansleep) from [bf0363c4] (gpio_ir_recv_irq+0x24/0x6c [gpio_ir_recv]) [bf0363c4] (gpio_ir_recv_irq [gpio_ir_recv]) from [c008a78c] (handle_irq_event_percpu+0x164/0x550) [c008a78c] (handle_irq_event_percpu) from [c008abc4] (handle_irq_event+0x4c/0x6c) [c008abc4] (handle_irq_event) from [c008df88] (handle_edge_irq+0x128/0x150) [c008df88] (handle_edge_irq) from [c0089edc] (generic_handle_irq+0x30/0x40) [c0089edc] (generic_handle_irq) from [c02fc4cc] (rockchip_irq_demux+0x158/0x210) [c02fc4cc] (rockchip_irq_demux) from [c0089edc] (generic_handle_irq+0x30/0x40) [c0089edc] (generic_handle_irq) from [c008a058] (__handle_domain_irq+0x98/0xc0) [c008a058] (__handle_domain_irq) from [c00094a4] (gic_handle_irq+0x4c/0x70) [c00094a4] (gic_handle_irq) from [c0014684] (__irq_svc+0x44/0x5c) Signed-off-by: Heiko Stuebner he...@sntech.de --- drivers/media/rc/gpio-ir-recv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c index 229853d..e4d43cc 100644 --- a/drivers/media/rc/gpio-ir-recv.c +++ b/drivers/media/rc/gpio-ir-recv.c @@ -78,7 +78,7 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id) int rc = 0; enum raw_event_type type = IR_SPACE; - gval = gpio_get_value_cansleep(gpio_dev-gpio_nr); + gval = gpio_get_value(gpio_dev-gpio_nr); if (gval 0) goto err_get_value; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/35] DocBook: fix emphasis at the DVB documentation
Em Tue, 2 Jun 2015 08:51:38 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com escreveu: Em Tue, 02 Jun 2015 11:56:04 +0900 Jonathan Corbet cor...@lwn.net escreveu: On Thu, 28 May 2015 18:49:07 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Currently, it is using 'role=tt', but this is not defined at the DocBook 4.5 spec. The net result is that no emphasis happens. So, replace them to bold emphasis. Nit: I suspect the intent of the emphasis here was to get the code in a monospace font, which bold is unlikely to do. Isn't there a role=code or something useful like that to use? I'd have to go look. Good point! I think that emphasis only does italic (with is the default, and don't need role option) or bold on DocBook 4.5. We're using constant on the places where we want a monospace font. That's probably the right tag there. For the record: this document was produced by merging two different documents: the V4L docbook (that used a legacy DocBook version - 3.x or 2.x) and the DVB LaTex documentation, which was converted by some tool to docbook 3.x (or 2.x) to match the same DocBook spec that V4L were using. The 'role=tt' came from such conversion. This were maintained together with the legacy Mercurial tree that was used to contain the media drivers. When we moved to git, the DocBook got merged in the Kernel and another conversion was taken to allow compiling it using DocBook 4.x. We only checked the tags that didn't compile, but options with invalid arguments like 'role=tt' where xmllint doesn't complain weren't touched. One question: any plans to update the documentation to DocBook schema? Gah, something got wrong on my edition on the above line... I meant to say, instead: One question: any plans to update the DocBook schema on the documentation? We're using either schema 4.1 or 4.2, with are both very old. The latest 4.x is 4.5, with was written back on 2006. So, except for historic reasons, are there any reason why keeping them at version 4.2? I did a quick look at the DocBook specs (for 4.3, 4.4 and 4.5), and they say that no backward compatible changes were done. So, using version 4.5 should be straightforward. I applied this patch here: --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -2,2 +2,2 @@ -!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.2//EN - http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; [ +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.5//EN + http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [ and compiled the media documentation with: make cleanmediadocs make DOCBOOKS=media_api.xml htmldocs 21 | grep -v element.*: validity error : ID .* already defined xmllint --noent --postvalid $PWD/Documentation/DocBook/media_api.xml /tmp/x.xml 2/dev/null xmllint --noent --postvalid --noout /tmp/x.xml xmlto html-nochunks -m ./Documentation/DocBook/stylesheet.xsl -o Documentation/DocBook/media Documentation/DocBook/media_api.xml /dev/null 21 In order to try to produce errors. Everything seemed to work. On a quick look, the documentation looked fine, and no errors (except for some crappy element validity errors, with seems to be due to a bug on recent versions of the xml tools present on Fedora 22). I did a diff between what's produced with v4.2 and v4.5 using: make cleanmediadocs make DOCBOOKS=media_api.xml htmldocs 21 | grep -v element.*: validity error : ID .* already defined xmlto html-nochunks -m ./Documentation/DocBook/stylesheet.xsl -o Documentation/DocBook/media Documentation/DocBook/media_api.xml /dev/null 21 cat Documentation/DocBook/media/media_api.html |sed s,'','\n',g v4.2 Then applying the patch and doing the same. Except for auto-generated naming references: --- v4.22015-06-02 09:51:14.867426792 -0300 +++ v4.52015-06-02 09:51:21.030553531 -0300 @@ -24 +24 @@ Copyright A9 2009-2014 LinuxTV Developers -a name=idm140503220604352 +a name=idm140423402024512 @@ -45 +45 @@ Table of Contents/b -a href=#idm140503221376592 +a href=#idm140423402329888 The document looks the same. So, I'll likely send on my next docbook patch series a patch changing the DTD to DocBook schema 4.5, with is the latest 4.x spec. Still, the question remains: are there any value on changing it to 5.0? Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: dma_request_slave_channel_compat() 'eats' up the returned error codes which prevents drivers using the compat call to be able to do deferred probing. The new wrapper is identical in functionality but it will return with error code in case of failure and will pass the -EPROBE_DEFER to the caller in case dma_request_slave_channel_reason() returned with it. This is okay but am worried about one more warpper, how about fixing dma_request_slave_channel_compat() Then all callers of dma_request_slave_channel_compat() have to be modified to handle ERR_PTR first. The same is true for (the existing) dma_request_slave_channel_reason() vs. dma_request_slave_channel(). Good point, looking again, I think we should rather fix dma_request_slave_channel_reason() as it was expected to return err code and add new users. Anyway users of this API do expect the reason... Hrm, they are for different use.dma_request_slave_channel()/_reason() is for drivers only working via DT or ACPI while dma_request_slave_channel_compat()/_reason() is for drivers expected to run in DT/ACPI or legacy mode as well. I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci drivers are using this to request channels - they need to support DT and legacy mode. I think we should hide these things behind the API and do this behind the hood for ACPI/DT systems. Also it makes sense to use right API and mark rest as depricated But it is doable to do this for both the non _compat and _compat version: 1. change all users to check IS_ERR_OR_NULL(chan) return the PTR_ERR if not NULL, or do whatever the driver was doing in case of chan == NULL. 2. change the non _compat and _compat versions to do the same as the _reason variants, #define the _reason ones to the non _reason names 3. Rename the _reason use to non _reason function in drivers 4. Remove the #defines for the _reason functions 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers The result: Both dma_request_slave_channel() and dma_request_slave_channel_compat() will return ERR_PTR in case of failure or in success they will return the pinter to chan. Is this what you were asking? It is a bit broader than what this series was doing: taking care of OMAP/daVinci drivers for deferred probing regarding to dmaengine ;) Yes but it would make sense right? I know it is a larger work but then we wouldn't want another dma_request_slave_xxx API, at some point we have stop it exapnding, perhpas now :) Yes I am all ears to stage this work and not do transition gardually.. -- ~Vinod -- 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 v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
Hi, Jacek!
On Tue, Jun 02, 2015 at 11:13:54AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/01/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Mon, May 25, 2015 at 05:13:57PM +0200, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Thanks for adding indicator support!
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
I missed one thing - sysfs interface of the indicator LED class
also has to be disabled/enabled of v4l2_flash_open/close.
Good catch.
I am planning to reimplement the functions as follows,
please let me know if you see any issues here:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
I think you could spare some newlines above (and below as well).
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh))
goto unlock;
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
You can also declare led_cdev_ind here as you don't need it outside the
basic block.
mutex_lock(led_cdev_ind-led_access);
led_sysfs_disable(led_cdev_ind);
led_trigger_remove(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
Please don't acquire the indicator mutex while holding the flash mutex. I
don't think there's a need to do so, thus creating a dependency between the
two. Just remember to check for v4l2_fh_is_singular() in both cases.
}
ret = __sync_device_with_v4l2_controls(v4l2_flash);
If ret is 0 here, you end up disabling the sysfs interface while open()
fails (and v4l2_flash_close() will not be run). Shouldn't you handle that?
unlock:
mutex_unlock(led_cdev-led_access);
return ret;
}
static int v4l2_flash_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
mutex_lock(led_cdev-led_access);
if (v4l2_fh_is_singular(fh-vfh)) {
if (v4l2_flash-ctrls[STROBE_SOURCE])
ret =
v4l2_ctrl_s_ctrl(v4l2_flash-ctrls[STROBE_SV4L2_FLASH_STROBE_SOURCE_SOFTWARE);
led_sysfs_enable(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
mutex_lock(led_cdev_ind-led_access);
Ditto.
led_sysfs_enable(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
}
}
mutex_unlock(led_cdev-led_access);
return ret;
}
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] mm: Provide new get_vaddr_frames() helper
On Thu 28-05-15 16:24:02, Andrew Morton wrote: On Wed, 13 May 2015 15:08:08 +0200 Jan Kara j...@suse.cz wrote: Provide new function get_vaddr_frames(). This function maps virtual addresses from given start and fills given array with page frame numbers of the corresponding pages. If given start belongs to a normal vma, the function grabs reference to each of the pages to pin them in memory. If start belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller must make sure pfns aren't reused for anything else while he is using them. This function is created for various drivers to simplify handling of their buffers. Acked-by: Mel Gorman mgor...@suse.de Acked-by: Vlastimil Babka vba...@suse.cz Signed-off-by: Jan Kara j...@suse.cz --- include/linux/mm.h | 44 +++ mm/gup.c | 226 + That's a lump of new code which many kernels won't be needing. Can we put all this in a new .c file and select it within drivers/media Kconfig? So the attached patch should do what you had in mind. OK? Honza -- Jan Kara j...@suse.cz SUSE Labs, CR From d18fc7863fc62d8ad0c1747b789a0dcf032ccf42 Mon Sep 17 00:00:00 2001 From: Jan Kara j...@suse.cz Date: Tue, 2 Jun 2015 16:40:32 +0200 Subject: [PATCH] mm: Move get_vaddr_frames() behind a config option get_vaddr_frames() is used by relatively rare drivers so hide it and the related functions behind a config option that is selected only by drivers that need the infrastructure. Suggested-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Jan Kara j...@suse.cz --- drivers/gpu/drm/exynos/Kconfig | 1 + drivers/media/platform/omap/Kconfig | 1 + drivers/media/v4l2-core/Kconfig | 1 + mm/Kconfig | 3 + mm/Makefile | 1 + mm/frame-vec.c | 233 mm/gup.c| 225 -- 7 files changed, 240 insertions(+), 225 deletions(-) create mode 100644 mm/frame-vec.c diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 0a6780367d28..b2fac87137c7 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -71,6 +71,7 @@ config DRM_EXYNOS_VIDI config DRM_EXYNOS_G2D bool Exynos DRM G2D depends on DRM_EXYNOS !VIDEO_SAMSUNG_S5P_G2D + select FRAME_VEC help Choose this option if you want to use Exynos G2D for DRM. diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig index dc2aaab54aef..7cceca7b184d 100644 --- a/drivers/media/platform/omap/Kconfig +++ b/drivers/media/platform/omap/Kconfig @@ -10,6 +10,7 @@ config VIDEO_OMAP2_VOUT select OMAP2_DSS if HAS_IOMEM ARCH_OMAP2PLUS select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT OMAP2_VRFB + select FRAME_VEC default n ---help--- V4L2 Display driver support for OMAP2/3 based boards. diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index ba7e21a73023..957e5a18b0ff 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -73,6 +73,7 @@ config VIDEOBUF2_CORE config VIDEOBUF2_MEMOPS tristate + select FRAME_VEC config VIDEOBUF2_DMA_CONTIG tristate diff --git a/mm/Kconfig b/mm/Kconfig index 390214da4546..d039615e8f82 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -635,3 +635,6 @@ config MAX_STACK_SIZE_MB changed to a smaller value in which case that is used. A sane initial value is 80 MB. + +config FRAME_VEC + bool diff --git a/mm/Makefile b/mm/Makefile index 98c4eaeabdcb..d38305462e17 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -78,3 +78,4 @@ obj-$(CONFIG_CMA) += cma.o obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o +obj-$(CONFIG_FRAME_VEC) += frame-vec.o diff --git a/mm/frame-vec.c b/mm/frame-vec.c new file mode 100644 index ..5d85bcd150ae --- /dev/null +++ b/mm/frame-vec.c @@ -0,0 +1,233 @@ +#include linux/kernel.h +#include linux/errno.h +#include linux/err.h +#include linux/mm.h +#include linux/slab.h +#include linux/pagemap.h +#include linux/sched.h + +/* + * get_vaddr_frames() - map virtual addresses to pfns + * @start: starting user address + * @nr_frames: number of pages / pfns from start to map + * @write: whether pages will be written to by the caller + * @force: whether to force write access even if user mapping is + * readonly. See description of the same argument of + get_user_pages(). + * @vec: structure which receives pages / pfns of the addresses mapped. + * It should have space for at least nr_frames entries. + * + * This function maps virtual addresses from @start and fills @vec structure + * with page frame numbers or page
Re: [RFC] v4l: omap4iss: DT bindings development
* Michael Allwright michael.allwri...@upb.de [150602 01:41]: Hi Everyone, I'm working on the DT bindings for the OMAP4 ISS at the moment, but I am unable to capture any data in my test setup. As detailed below, it seems that everything has been configured correctly however I never get any interrupts from the ISS unless I do something drastic like removing one of the wires from the clock differential pair which results in constant complex IO error interrupts from CSIA until I restore the physical connection. My test setup includes a OV6540 sensor camera module (MIPI) from Lepoard Imaging, an Duovero COM from Gumstix and breakout boards forming an interconnect between the two. The sensor is connected to CSI21 on the OMAP4 using a clock lane (on position 1, default polarity) and a single data lane (on position 2, default polarity), the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds to 19.2MHz when asked for 24MHz). The relevant parts of my device tree can be seen here: https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually somewhat unclear what effect stating the ti,hwmod=iss parameter has. Does anything else need to be done here? As far as I can tell I think all clocks and power has been switched on. I do make two function calls to the PM API in the ISS probe function, i.e.: pm_runtime_enable(pdev-dev); r = pm_runtime_get_sync(pdev-dev); The ti,hwmod = iss hooks up the device with the PM runtime, see omap_hwmod_44xx_data.c for iss. Regarding my debugging, this is what I have checked so far * Changing the pixel rate of the sensor - this lead me to discover a possible bug in iss.c or perhaps my ov5640 driver, as the V4L2_CID_PIXEL_RATE control was always returning zero. I patched this by copying what Laurent has done in the OMAP3ISP driver which now works. * As I only have a 100MHz scope, I had to slow down the camera significantly (MIPI clock = 10-12MHz range) to verify that I was getting reasonable output from the sensor (i.e. signals that were characteristic of CSI2/MIPI). I checked the calculations and made sure these updated values came across via the V4L2_CID_PIXEL_RATE control and ended up in the THS_TERM and THS_SETTLE fields of register 0. * Using the omapconf tool, I have manually and one by one pulled up the CSI2 pins and verified multiple times all connections to the sensor module and have even manually tried swapping the DP/DN pairs in case they were still somehow backwards despite previous testing * Verified that the interrupt service routine is called by generating a test interrupt HS_VS from inside the ISS i.e. ./omapconf write ISS_HL_IRQENABLE_SET_5 0x0002 ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x0002 * Verified that the default CMA region is being used, it ends up in the ping-pong resisters of the ISS. Additional information: * Initialisation of pipe line and stream commands: media-ctl -r -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS CSI2a output:0 [1]' media-ctl -V 'ov5640 2-003c:0 [UYVY 640x480]','OMAP4 ISS CSI2a:0 [UYVY 640x480]' yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy * Output from OMAPCONF tool is in the second part of: https://gist.github.com/allsey87/fdf1feb6eb6a94158638 Anyway, at this point, I'm almost completely out of ideas on how to move forwards so any suggestions, criticisms or help of any nature would be appreciated! Usually it's pinmuxing or some regulator or clock not enabled. Or incorrect hwmod sysc and syss configuration for iss that prevents enabling it properly. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] v4l: omap4iss: DT bindings development
On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote: * Michael Allwright michael.allwri...@upb.de [150602 01:41]: Hi Everyone, I'm working on the DT bindings for the OMAP4 ISS at the moment, but I am unable to capture any data in my test setup. As detailed below, it seems that everything has been configured correctly however I never get any interrupts from the ISS unless I do something drastic like removing one of the wires from the clock differential pair which results in constant complex IO error interrupts from CSIA until I restore the physical connection. My test setup includes a OV6540 sensor camera module (MIPI) from Lepoard Imaging, an Duovero COM from Gumstix and breakout boards forming an interconnect between the two. The sensor is connected to CSI21 on the OMAP4 using a clock lane (on position 1, default polarity) and a single data lane (on position 2, default polarity), the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds to 19.2MHz when asked for 24MHz). The relevant parts of my device tree can be seen here: https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually somewhat unclear what effect stating the ti,hwmod=iss parameter has. Does anything else need to be done here? As far as I can tell I think all clocks and power has been switched on. I do make two function calls to the PM API in the ISS probe function, i.e.: pm_runtime_enable(pdev-dev); r = pm_runtime_get_sync(pdev-dev); The ti,hwmod = iss hooks up the device with the PM runtime, see omap_hwmod_44xx_data.c for iss. Regarding my debugging, this is what I have checked so far * Changing the pixel rate of the sensor - this lead me to discover a possible bug in iss.c or perhaps my ov5640 driver, as the V4L2_CID_PIXEL_RATE control was always returning zero. I patched this by copying what Laurent has done in the OMAP3ISP driver which now works. * As I only have a 100MHz scope, I had to slow down the camera significantly (MIPI clock = 10-12MHz range) to verify that I was getting reasonable output from the sensor (i.e. signals that were characteristic of CSI2/MIPI). I checked the calculations and made sure these updated values came across via the V4L2_CID_PIXEL_RATE control and ended up in the THS_TERM and THS_SETTLE fields of register 0. * Using the omapconf tool, I have manually and one by one pulled up the CSI2 pins and verified multiple times all connections to the sensor module and have even manually tried swapping the DP/DN pairs in case they were still somehow backwards despite previous testing * Verified that the interrupt service routine is called by generating a test interrupt HS_VS from inside the ISS i.e. ./omapconf write ISS_HL_IRQENABLE_SET_5 0x0002 ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x0002 * Verified that the default CMA region is being used, it ends up in the ping-pong resisters of the ISS. Additional information: * Initialisation of pipe line and stream commands: media-ctl -r -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS CSI2a output:0 [1]' media-ctl -V 'ov5640 2-003c:0 [UYVY 640x480]','OMAP4 ISS CSI2a:0 [UYVY 640x480]' yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy * Output from OMAPCONF tool is in the second part of: https://gist.github.com/allsey87/fdf1feb6eb6a94158638 Anyway, at this point, I'm almost completely out of ideas on how to move forwards so any suggestions, criticisms or help of any nature would be appreciated! Usually it's pinmuxing or some regulator or clock not enabled. Or incorrect hwmod sysc and syss configuration for iss that prevents enabling it properly. And have you tried the same setup with platform data ? -- 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
randconfig build error with next-20150602, in drivers/media/i2c/adv{7604,7842,7511}.c
Building with the attached random configuration file, drivers/media/i2c/adv7604.c: In function ‘adv76xx_get_format’: drivers/media/i2c/adv7604.c:1853:9: error: implicit declaration of function ‘v4l2_subdev_get_try_format’ [-Werror=implicit-function-declaration] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ drivers/media/i2c/adv7604.c:1853:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ drivers/media/i2c/adv7604.c: In function ‘adv76xx_set_format’: drivers/media/i2c/adv7604.c:1882:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ drivers/media/i2c/adv7842.c: In function ‘adv7842_get_format’: drivers/media/i2c/adv7842.c:2093:9: error: implicit declaration of function ‘v4l2_subdev_get_try_format’ [-Werror=implicit-function-declaration] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ drivers/media/i2c/adv7842.c:2093:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ drivers/media/i2c/adv7842.c: In function ‘adv7842_set_format’: drivers/media/i2c/adv7842.c:2125:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ CC [M] drivers/gpu/drm/drm_fb_helper.o drivers/media/i2c/adv7511.c: In function ‘adv7511_get_fmt’: drivers/media/i2c/adv7511.c:859:9: error: implicit declaration of function ‘v4l2_subdev_get_try_format’ [-Werror=implicit-function-declaration] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ drivers/media/i2c/adv7511.c:859:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ drivers/media/i2c/adv7511.c: In function ‘adv7511_set_fmt’: drivers/media/i2c/adv7511.c:910:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] fmt = v4l2_subdev_get_try_format(sd, cfg, format-pad); ^ # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.1.0-rc6 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_KDBUS=m # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set
