Re: [RFC] media DT bindings
Hi Stephen,
On Tuesday 31 July 2012 17:29:24 Stephen Warren wrote:
On 07/31/2012 03:22 PM, Laurent Pinchart wrote:
On Tuesday 31 July 2012 14:39:07 Guennadi Liakhovetski wrote:
...
Ok, then, how about
#address-cells = 1;
#size-cells = 0;
...
ov772x-1 = {
reg = 1; /* local pad # */
client = ov772x@0x21-0 0;/* remote phandle and
pad */
The client property looks good, but isn't such a usage of the reg property
an abuse ? Maybe the local pad # should be a device-specific property.
Many hosts won't need it, and on others it would actually need to
reference a subdev, not just a pad.
That's a very odd syntax the the phandle; I assume that ov772x@0x21-0
is supposed to reference some other DT node. However, other nodes are
either referenced by:
foo where foo is a label, and the label name is unlikely to include
the text @0x21; the @ symbol probably isn't even legal in label names.
{/path/to/node} which might include the @0x21 syntax since it might
be part of the node's name, but your example didn't include {}.
I'm not sure what -0 is meant to be in that string - a math
expression, or ...? If it's intended to represent some separate field
relative to the node the phandle references, it needs to be just another
cell.
I'm actually not sure what -0 represents, and I don't think we need the
@0x21-0 at all. I believe ov772x@0x21-0 is supposed to just be a label. We
don't need an extra cell.
So overall, perhaps:
/ {
...
pad: something { ... };
...
ov772x@1 = { /* @1 not -1 would be canonical syntax */
reg = 1;
client = pad 0 0;
...
I'm sorry I haven't followed the thread; I'm wondering why a client is a
pad, which to me means a pin/pad/ball on an IC package, so I'm still not
entirely sure if even this makes sense.
Client references an image source (which is usually an I2C client, but can be
a different type of device) and a pad. Pad refers here to a media entity pad
(see http://linuxtv.org/downloads/v4l-dvb-apis/media-controller-model.html),
not a physical pin on an IC package.
--
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: [PULL] video_visstrim for 3.6
On 31 July 2012 15:05, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Jul 31, 2012 at 08:13:59AM +0200, javier Martin wrote: On 31 July 2012 00:42, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 26-07-2012 06:36, Javier Martin escreveu: Hi Mauro, this pull request is composed of two series that provide support for two mem2mem devices: - 'm2m-deinterlace' video deinterlacer - 'coda video codec' I've included platform support for them too. The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: https://github.com/jmartinc/video_visstrim.git for_3.6 for you to fetch changes up to 9bb10266da63ae7f8f198573e099580e9f98f4e8: i.MX27: Visstrim_M10: Add support for deinterlacing driver. (2012-07-26 10:57:30 +0200) Javier Martin (5): i.MX: coda: Add platform support for coda in i.MX27. media: coda: Add driver for Coda video codec. Visstrim M10: Add support for Coda. media: Add mem2mem deinterlacing driver. i.MX27: Visstrim_M10: Add support for deinterlacing driver. arch/arm/mach-imx/clk-imx27.c |4 +- arch/arm/mach-imx/devices-imx27.h |4 + arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 49 +- arch/arm/plat-mxc/devices/Kconfig |6 +- arch/arm/plat-mxc/devices/Makefile |1 + arch/arm/plat-mxc/devices/platform-imx27-coda.c | 37 + arch/arm/plat-mxc/include/mach/devices-common.h |8 + I need ARM maintainer's ack for the patches that touch the above files. Generally: Acked-by: Sascha Hauer s.ha...@pengutronix.de I think that these are quite late for this merge window though. The pull request should have been out before the 3.5 Release. Hi, these patches have been publicly discussed for 4 weeks, since July the 4th. The pull request is only meant to make things easier for Mauro. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Hi Laurent, I have a query for you regarding the support and testing of MJPEG frame type in the UVC webcam gadget. I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats are supported. I was trying the same out and got confused because the data arriving from a real video capture video supporting JPEG will have no fixed size. We will have the JPEG defined Start-of-Frame and End-of-Frame markers defining the boundary of the JPEG frame. But for almost all JPEG video capture devices even if we have kept a frame size of VGA initially, the final frame size will be a compressed version (with the compression depending on the nature of the scene, so a flat scene will have high compression and hence less frame size) of VGA and will not be equal to 640 * 480. So I couldn't exactly get why the dwMaxVideoFrameBufferSize is kept as 614400 in webcam.c (see [1]). Can you please let me know your opinions and how you tested the UVC gadget's MJPEG frame format. [1] http://lxr.linux.no/linux+v3.5/drivers/usb/gadget/webcam.c#L232 Thanks, Bhupesh -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tue July 24 2012 19:40:27 Michael Krufky wrote: Apologies for my late reply -- I plan to attend the conference!!! I am looking to book everything today... I think I'm going to Barcelona as well -- will you guys go to both conferences? I plan on going to Barcelona as well. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Laurent, I have a query for you regarding the support and testing of MJPEG frame type in the UVC webcam gadget. I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats are supported. I was trying the same out and got confused because the data arriving from a real video capture video supporting JPEG will have no fixed size. We will have the JPEG defined Start-of-Frame and End-of-Frame markers defining the boundary of the JPEG frame. But for almost all JPEG video capture devices even if we have kept a frame size of VGA initially, the final frame size will be a compressed version (with the compression depending on the nature of the scene, so a flat scene will have high compression and hence less frame size) of VGA and will not be equal to 640 * 480. So I couldn't exactly get why the dwMaxVideoFrameBufferSize is kept as 614400 in webcam.c (see [1]). Can you please let me know your opinions and how you tested the UVC gadget's MJPEG frame format. [1] http://lxr.linux.no/linux+v3.5/drivers/usb/gadget/webcam.c#L232 Thanks, Bhupesh -- 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: Update VIP to videobuf2 and control framework
On Tue July 31 2012 22:17:06 Federico Vaga wrote:
As suggested I moved the Video Buffer Input (VIP) of the STA2X11 board to the
videobuf2. This patch series is an RFC.
Thank you very much for working on this! Much appreciated!
The first patch is just an update to the adv7180 because the VIP (the only
user) now use the control framework so query{g_|s_|ctrl} are not necessery.
For this patch:
Acked-by: Hans Verkuil hans.verk...@cisco.com
The second patch adds a new memory allocator for the videobuf2. I name it
videobuf2-dma-streaming but I think streaming is not the best choice, so
suggestions are welcome. My inspiration for this buffer come from
videobuf-dma-contig (cached) version. After I made this buffer I found the
videobuf2-dma-nc made by Jonathan Corbet and I improve the allocator with
some suggestions (http://patchwork.linuxtv.org/patch/7441/). The VIP doesn't
work with videobu2-dma-contig and I think this solution is easier the sg.
I leave this to the vb2 experts. It's not obvious to me why we would need
a fourth memory allocator.
The third patch updates the VIP to videobuf2 and control framework. I made
also
some restyling to the driver and change some mechanism so I take the ownership
of the driver and I add the copyright of ST Microelectronics. Some trivial
code is unchanged. The patch probably needs some extra update.
I add the control framework to the VIP but without any control. I add it to
inherit controls from adv7180.
Did you run the latest v4l2-compliance tool from the v4l-utils.git repository
over your driver? I'm sure you didn't since VIP is missing support for control
events and v4l2-compliance would certainly complain about that.
Always check with v4l2-compliance whenever you make changes! It's continuously
improved as well, so a periodic check wouldn't hurt.
Also take a look at the new vb2 helper functions in media/videobuf2-core.h:
it is likely that you can use those to simplify your driver. They are used in
e.g. vivi, so take a look there.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] media DT bindings
On Tue, 31 Jul 2012, Laurent Pinchart wrote:
Hi Guennadi,
On Tuesday 31 July 2012 14:39:07 Guennadi Liakhovetski wrote:
On Tue, 31 Jul 2012, Laurent Pinchart wrote:
On Tuesday 31 July 2012 11:26:27 Guennadi Liakhovetski wrote:
On Fri, 27 Jul 2012, Laurent Pinchart wrote:
On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
[snip]
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg =0xfe91 0xa0;
interrupts =0x880;
bus-width =16;/* #lines
routed on the board */
clock-frequency =5000;/* max clock */
#address-cells =1;
#size-cells =0;
...
ov772x-1 = {
reg =0;
This property might be redundant, we already have the client
phandle pointing to ov772x@0x21-0, which has all interesting
properties inside it. Other than there is probably no reasonable
usage for it under ceu0@0xfe91 node ?
client =ov772x@0x21-0;
local-pad = parallel-sink;
remote-pad = parallel-source;
I'm not sure I like that. Is it really needed when we already
have the child/parent properties around ?
I think it is. Both the host and the client can have multiple pads
(e.g., parallel / serial). These properties specify which pads are
used and make the translation between DT data and our subdev / pad
APIs simpler.
OK, sorry, but isn't it all about just specifying what sort of data
bus is used ? :-)
In some (many/most ?) cases probably, but not in all of them.
What about merging the client and remote-pad properties ? The
resulting property would then reference a pad with ov772x@0x21-0 0.
What would the 0 parameter mean then? Pad #0?
Yes.
But aren't these numbers device specific? Maybe not a huge deal, but
these numbers are defind by the driver, right? Not the DT itself. So,
drivers then will have to take care not to change their pad numbering.
Whereas using strings, we can fix strings in the common V4L DT spec and
keep them standard across devices and drivers. Then drivers might be
less likely to change these assignments randomly ;-)
Userspace applications usually rely on pad numbers as well, so I consider
them as more or less part of the ABI. If we really need to, we could add
a DT pad number - media controller pad number conversion in the driver,
that would be less expensive than pad name - pad number conversion
(especially since it would be skipped in most cases).
Ok, then, how about
#address-cells = 1;
#size-cells = 0;
...
ov772x-1 = {
reg = 1; /* local pad # */
client = ov772x@0x21-0 0;/* remote phandle and
pad */
The client property looks good, but isn't such a usage of the reg property an
abuse ?
Don't know, is it?
Maybe the local pad # should be a device-specific property. Many hosts
won't need it, and on others it would actually need to reference a subdev,
not
just a pad.
Wait, the correspondence cannot be one pad to many subdevs, right? So, we
always can assign at least 1 pad to each subdev. Hm, or you mean subdevs
like flash, that don't access data, in which case they don't need pads?
but then we also don't need links to them. Those child nodes are links,
and links always run between 2 pads, right? So, in the above
representation child devices are pads of the parent node, to which other
entities are linked.
But while writing this, another question occurred to me: what if several
entities are connected to one pad (activated selectively by a switch)? We
cannot have several child nodes with the same address. But in such a case
we could use
#address-cells = 2;
...
subdev1 = {
reg = 1 1; /* first client on pad 1 */
};
subdev2 = {
reg = 1 2; /* second client on pad 1 */
};
But I'm not particularly attached to this idea. If we decide, that it's an
abuse, we can switch back to some property.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: stk7700d problem
Apologies for resending. Mailing list bounced the email the first time becuase it wasn't plain text format. I have a dual USB DVB-T tuner which is sold under the brand Kaiser Baas KBA 01004 but under the hood looks pretty much the same as the Emtec s830 http://linuxtv.org/wiki/index.php/Emtec_S830 Whilst the device is recognised and seems to load ok, locally the only station that it seems to be able to tune is the a community TV station which transmits on QPSK. All the other TV stations are detected but the BER is too high which to me would imply that the devices LNA is proably not being turned on correctly. In heading down that path I have sat and captured the USB communications both under windows and Linux with the intent to compare the two and work out which gpio is being used to turn on the LNA under windows and then duplicate that under Linux. Well that was the intent but the behaviour I am seeing under Linux is a bit strange and I think resolving that might explain why the device has not worked in the past. Specifically, the device is identified as 1164:1e8c and within dib0700_devices.c proceeds to do a stk7700d_frontend_attach. This tries to set GPIOs 6,9,4 and 7 to 1, then it tries to set GPIO10 to 0 before resetting it to 1 and then finally tries to set GPIO 0 to 1. The driver reports no problem doing this but when you drill deeper you find that it does not seem to be doing what it is supposed to. That is, irrespective of which GPIO is set to 1 or 0 the same message is sent to the device over the USB interface. Specifically the USB message as seen in wireshark is 40 0C 00 00 00 00 03 00 00 00 00. Drilling further still I can see that stk7700d_front_end_attach calls dib0700_set_gpio within dib0700_core.c. Within dib0700_set_gpio the main data seems to be loaded into st-buf. The contents of st-buf seem to be ok. That is, when setting any of the GPIOs st-buf[0] is always 0x0C, st-buf[1] follows the GPIOs eg GPIO6=8, GPIO9=14, GPIO4=5, GPIO7=10, GPIO10=15 and GPIO0=0 and finally st-buf[3] is 0x80 when setting GPIO10 to 0 and 0xC0 when setting any of the GPIOs to 1. dib0700_set_gpio subsequently calls dib0700_ctrl_wr within dib0700_core.c but it was at this point I decided that surely this part of the code is pretty robust as it seems to be common for a number of devices and a problem would have been spotted long ago. My question is whether any one has any ideas why I am seeing the same USB message irrespective of which GPIO is being set/reset? Patrick, I have CC'd you specifically as your fingerprints seem to be all over the Dibcom code and presumably you are very familiar with it. Happy to run additional tests and captures as required. Regards Pete -- 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 4/4] media: mx2_camera: Fix clock handling for i.MX27.
Hi Sascha
On Tue, 31 Jul 2012, Sascha Hauer wrote:
Hi Guennadi,
On Tue, Jul 31, 2012 at 05:14:25PM +0200, Guennadi Liakhovetski wrote:
Hi Javier
@@ -436,7 +436,8 @@ static void mx2_camera_deactivate(struct
mx2_camera_dev *pcdev)
{
unsigned long flags;
- clk_disable(pcdev-clk_csi);
+ if (cpu_is_mx27())
+ clk_disable_unprepare(pcdev-clk_csi);
This tells me, there are already 2 things going on here:
1. add clock-(un)prepare operations to enable / disable. Is this a problem
atm? is the driver non-functional without this change or is it just an API
correctness change? I thought you replied to this already, but
unfortunately I couldn't find that your reply again, sorry.
Since the common clock framework clk_prepare is mandatory.
Good, thanks for the clarification. So, this is not a functional, but a
correctness fix. I think, such fixes are acceptable after -rc1 until
something like -rc5, but maybe not after that. So, I'd try to push this
some time within the next couple of weeks, once I get this fix as a
separate patch.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] media DT bindings
Hi Guennadi,
On Wednesday 01 August 2012 08:47:20 Guennadi Liakhovetski wrote:
On Tue, 31 Jul 2012, Laurent Pinchart wrote:
On Tuesday 31 July 2012 14:39:07 Guennadi Liakhovetski wrote:
On Tue, 31 Jul 2012, Laurent Pinchart wrote:
On Tuesday 31 July 2012 11:26:27 Guennadi Liakhovetski wrote:
On Fri, 27 Jul 2012, Laurent Pinchart wrote:
On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
[snip]
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg =0xfe91 0xa0;
interrupts =0x880;
bus-width =16;/* #lines
routed on the board */
clock-frequency =5000;/* max clock */
#address-cells =1;
#size-cells =0;
...
ov772x-1 = {
reg =0;
This property might be redundant, we already have the client
phandle pointing to ov772x@0x21-0, which has all interesting
properties inside it. Other than there is probably no reasonable
usage for it under ceu0@0xfe91 node ?
client =ov772x@0x21-0;
local-pad = parallel-sink;
remote-pad = parallel-source;
I'm not sure I like that. Is it really needed when we already
have the child/parent properties around ?
I think it is. Both the host and the client can have multiple
pads (e.g., parallel / serial). These properties specify which
pads are used and make the translation between DT data and our
subdev / pad APIs simpler.
OK, sorry, but isn't it all about just specifying what sort of
data bus is used ? :-)
In some (many/most ?) cases probably, but not in all of them.
What about merging the client and remote-pad properties ? The
resulting property would then reference a pad with ov772x@0x21-0
0.
What would the 0 parameter mean then? Pad #0?
Yes.
But aren't these numbers device specific? Maybe not a huge deal, but
these numbers are defind by the driver, right? Not the DT itself.
So, drivers then will have to take care not to change their pad
numbering. Whereas using strings, we can fix strings in the common
V4L DT spec and keep them standard across devices and drivers. Then
drivers might be less likely to change these assignments randomly
;-)
Userspace applications usually rely on pad numbers as well, so I
consider them as more or less part of the ABI. If we really need to,
we could add a DT pad number - media controller pad number conversion
in the driver, that would be less expensive than pad name - pad
number conversion (especially since it would be skipped in most
cases).
Ok, then, how about
#address-cells = 1;
#size-cells = 0;
...
ov772x-1 = {
reg = 1; /* local pad # */
client = ov772x@0x21-0 0;/* remote phandle and
pad */
The client property looks good, but isn't such a usage of the reg property
an abuse ?
Don't know, is it?
Maybe the local pad # should be a device-specific property. Many hosts
won't need it, and on others it would actually need to reference a subdev,
not just a pad.
Wait, the correspondence cannot be one pad to many subdevs, right?
So, we always can assign at least 1 pad to each subdev. Hm, or you mean
subdevs like flash, that don't access data, in which case they don't need
pads? but then we also don't need links to them. Those child nodes are
links, and links always run between 2 pads, right? So, in the above
representation child devices are pads of the parent node, to which other
entities are linked.
But while writing this, another question occurred to me: what if several
entities are connected to one pad (activated selectively by a switch)? We
cannot have several child nodes with the same address. But in such a case
we could use
#address-cells = 2;
...
subdev1 = {
reg = 1 1; /* first client on pad 1 */
};
subdev2 = {
reg = 1 2; /* second client on pad 1 */
};
But I'm not particularly attached to this idea. If we decide, that it's an
abuse, we can switch back to some property.
I think that would be an abuse :-)
My point was that a host represented by a single DT node might contain several
media entities. For instance the OMAP3 ISP contains two CSI2 receivers. Each
of them has a single sink
[PATCH for v3.6] Fix mem2mem_testdev querycap regression
Trival but important patch. Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/video/mem2mem_testdev.c b/drivers/media/video/mem2mem_testdev.c index 7efe9ad..0b91a5c 100644 --- a/drivers/media/video/mem2mem_testdev.c +++ b/drivers/media/video/mem2mem_testdev.c @@ -431,7 +431,7 @@ static int vidioc_querycap(struct file *file, void *priv, strncpy(cap-driver, MEM2MEM_NAME, sizeof(cap-driver) - 1); strncpy(cap-card, MEM2MEM_NAME, sizeof(cap-card) - 1); strlcpy(cap-bus_info, MEM2MEM_NAME, sizeof(cap-bus_info)); - cap-capabilities = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING; + cap-device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING; cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS; return 0; } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 0/5] Add new driver for generic scaler
On 07/31/2012 10:44 PM, Shaik Ameer Basha wrote: -Original Message- From: Shaik Ameer Basha [mailto:shaik.am...@samsung.com] Sent: Tuesday, July 31, 2012 10:44 PM To: linux-media@vger.kernel.org Cc: sungchun.k...@samsung.com; khw0178@samsung.com; mche...@infradead.org; laurent.pinch...@ideasonboard.com; sy0816.k...@samsung.com; s.nawro...@samsung.com; posc...@google.com; hverk...@xs4all.nl; alim.akh...@gmail.com; prashant...@samsung.com; jo...@samsung.com; shaik.sams...@gmail.com; shaik.am...@samsung.com Subject: [PATCH v5 0/5] Add new driver for generic scaler This patch adds support for the gscaler device which is a new device for scaling and color space conversion on EXYNOS5 SoCs. This device supports the followings as key feature. 1) Input image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, TILE 2) Output image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, YUV444 3) Input rotation - 0/90/180/270 degree, X/Y Flip 4) Scale ratio - 1/16 scale down to 8 scale up 5) CSC - RGB to YUV / YUV to RGB 6) Size - 2048 x 2048 for tile or rotation - 4800 x 3344 other case changes since v4: - Rebased on latest media-tree git, branch staging/for_v3.6. http://linuxtv.org/git/media_tree.git - Addressed review comments from Hans Verkuil http://www.mail-archive.com/linux-media@vger.kernel.org/msg49754.html - Removed the v4l: Add fourcc definitions for new formats patch dependency. Shaik Ameer Basha (2): v4l: Add new YVU420 multi planar fourcc definition media: gscaler: Add Makefile for G-Scaler Driver Sungchun Kang (3): media: gscaler: Add new driver for generic scaler media: gscaler: Add core functionality for the G-Scaler driver media: gscaler: Add m2m functionality for the G-Scaler driver Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml | 154 +++ Documentation/DocBook/media/v4l/pixfmt.xml |1 + drivers/media/video/Kconfig|8 + drivers/media/video/Makefile |2 + drivers/media/video/exynos-gsc/Makefile|3 + drivers/media/video/exynos-gsc/gsc-core.c | 1254 drivers/media/video/exynos-gsc/gsc-core.h | 532 + drivers/media/video/exynos-gsc/gsc-m2m.c | 771 drivers/media/video/exynos-gsc/gsc-regs.c | 425 +++ drivers/media/video/exynos-gsc/gsc-regs.h | 172 +++ include/linux/videodev2.h |1 + 11 files changed, 3323 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml create mode 100644 drivers/media/video/exynos-gsc/Makefile create mode 100644 drivers/media/video/exynos-gsc/gsc-core.c create mode 100644 drivers/media/video/exynos-gsc/gsc-core.h create mode 100644 drivers/media/video/exynos-gsc/gsc-m2m.c create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.c create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.h I'm sorry to be so late. Basically, I wonder important one thing. What would you implement a device driver connected with gscaler. For example, fimc-lite, mipi-csis. As you know Exynos5 has local-path with gscaler MIPI-CSIS = Fimc-lite = Gscaler And, you should use media control framework. So, We made exynos folder, and implement drivers with mc. We use mdev that is virtual device driver for connecting gscaler, fimc-lite, mipi-csis with MC. This is camera path. There are not only camera path but also rendering path. Gscaler = FIMD or TV Rendering path use mdev-0, Camera path use mdev-1. In conclusion, because we use to connect each other devices with MC, we made exynos folder. And how you make to implement devices with MC? -- 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: [media-ctl PATCH 1/1] libv4l2subdev: Add v4l2_subdev_enum_mbus_code()
Hi Laurent,
On Tue, Jul 31, 2012 at 11:50:53PM +0200, Laurent Pinchart wrote:
On Tuesday 31 July 2012 15:17:04 Sakari Ailus wrote:
On Tue, Jul 31, 2012 at 01:38:41PM +0200, Laurent Pinchart wrote:
On Tuesday 31 July 2012 01:16:00 Sakari Ailus wrote:
v4l2_subdev_enum_mbus_code() enumerates over supported media bus formats
on a pad.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
src/v4l2subdev.c | 23 +++
src/v4l2subdev.h | 14 ++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
index d60bd7e..6b6df0a 100644
--- a/src/v4l2subdev.c
+++ b/src/v4l2subdev.c
@@ -58,6 +58,29 @@ void v4l2_subdev_close(struct media_entity *entity)
entity-fd = -1;
}
+int v4l2_subdev_enum_mbus_code(struct media_entity *entity,
+ uint32_t *code, uint32_t pad, uint32_t
index)
I would use unsigned int for the pad and index arguments to match the
other functions. We could then fix all of them in one go to use stdint
types to match the kernel API types.
I'm fine with that.
+{
+ struct v4l2_subdev_mbus_code_enum c;
+ int ret;
+
+ ret = v4l2_subdev_open(entity);
+ if (ret 0)
+ return ret;
+
+ memset(c, 0, sizeof(c));
+ c.pad = pad;
+ c.index = index;
+
+ ret = ioctl(entity-fd, VIDIOC_SUBDEV_ENUM_MBUS_CODE, c);
+ if (ret 0)
+ return -errno;
+
+ *code = c.code;
+
+ return 0;
+}
What about a higher-level API that would enumerate all formats and return
a list/array ?
The information could be stored to media entities. We could add a V4L2
subdev pointer to media entities, and have the information stored there the
first time this function is called. How about that?
On source pads the pixel code is obviously possibly dependent on the pixel
code on the sink pad so I need to store mappings from sink pad pixel code to
a list of source pad pixel code, but can it have other dependencies? None
come to mind right now, though.
I would make this function store the enumerated mbus codes in the media
entity, as the codes on a source pad could depend on the selected code on a
sink pad. I would instead make the function allocate an array, fill it with
(After a short discussion it has been confirmed that not should be added
somewhere to the above sentence.)
media bus codes and return it. The caller would be responsible for freeing it
(possibly later, after storing it).
I like this option better as it forces the user to make a decision how long
to keep the enumeration around. Changing the sink pad's try format is one
thing that may invalidate the enumeration on a source pad, but that doesn't
rule out other reasons since they may be hardware dependent.
So I'll change it so.
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
[PATCH v2] mt9v032: Provide link frequency control
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/mt9v032.c | 48
include/media/mt9v032.h |3 ++
2 files changed, 46 insertions(+), 5 deletions(-)
Changes compared to v1:
- Assign pixel_rate-val64 instead of pixel_rate-cur.val
diff --git a/drivers/media/video/mt9v032.c b/drivers/media/video/mt9v032.c
index 2203a6f..bf591b8 100644
--- a/drivers/media/video/mt9v032.c
+++ b/drivers/media/video/mt9v032.c
@@ -29,6 +29,8 @@
#define MT9V032_PIXEL_ARRAY_HEIGHT 492
#define MT9V032_PIXEL_ARRAY_WIDTH 782
+#define MT9V032_SYSCLK_FREQ_DEF2660
+
#define MT9V032_CHIP_VERSION 0x00
#defineMT9V032_CHIP_ID_REV10x1311
#defineMT9V032_CHIP_ID_REV30x1313
@@ -122,13 +124,18 @@ struct mt9v032 {
struct v4l2_mbus_framefmt format;
struct v4l2_rect crop;
- struct v4l2_ctrl *pixel_rate;
struct v4l2_ctrl_handler ctrls;
+ struct {
+ struct v4l2_ctrl *link_freq;
+ struct v4l2_ctrl *pixel_rate;
+ };
struct mutex power_lock;
int power_count;
struct mt9v032_platform_data *pdata;
+
+ u32 sysclk;
u16 chip_control;
u16 aec_agc;
};
@@ -196,7 +203,7 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032)
int ret;
if (mt9v032-pdata-set_clock) {
- mt9v032-pdata-set_clock(mt9v032-subdev, EXT_CLK);
+ mt9v032-pdata-set_clock(mt9v032-subdev, mt9v032-sysclk);
udelay(1);
}
@@ -374,7 +381,8 @@ static void mt9v032_configure_pixel_rate(struct mt9v032
*mt9v032,
struct i2c_client *client = v4l2_get_subdevdata(mt9v032-subdev);
int ret;
- ret = v4l2_ctrl_s_ctrl_int64(mt9v032-pixel_rate, EXT_CLK / hratio);
+ ret = v4l2_ctrl_s_ctrl_int64(mt9v032-pixel_rate,
+mt9v032-sysclk / hratio);
if (ret 0)
dev_warn(client-dev, failed to set pixel rate (%d)\n, ret);
}
@@ -487,6 +495,7 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
struct mt9v032 *mt9v032 =
container_of(ctrl-handler, struct mt9v032, ctrls);
struct i2c_client *client = v4l2_get_subdevdata(mt9v032-subdev);
+ u32 freq;
u16 data;
switch (ctrl-id) {
@@ -505,6 +514,16 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
return mt9v032_write(client, MT9V032_TOTAL_SHUTTER_WIDTH,
ctrl-val);
+ case V4L2_CID_PIXEL_RATE:
+ case V4L2_CID_LINK_FREQ:
+ if (mt9v032-link_freq == NULL)
+ break;
+
+ freq = mt9v032-pdata-link_freqs[mt9v032-link_freq-val];
+ mt9v032-pixel_rate-val64 = freq;
+ mt9v032-sysclk = freq;
+ break;
+
case V4L2_CID_TEST_PATTERN:
switch (ctrl-val) {
case 0:
@@ -683,6 +702,7 @@ static const struct v4l2_subdev_internal_ops
mt9v032_subdev_internal_ops = {
static int mt9v032_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
+ struct mt9v032_platform_data *pdata = client-dev.platform_data;
struct mt9v032 *mt9v032;
unsigned int i;
int ret;
@@ -699,9 +719,9 @@ static int mt9v032_probe(struct i2c_client *client,
return -ENOMEM;
mutex_init(mt9v032-power_lock);
- mt9v032-pdata = client-dev.platform_data;
+ mt9v032-pdata = pdata;
- v4l2_ctrl_handler_init(mt9v032-ctrls, ARRAY_SIZE(mt9v032_ctrls) + 5);
+ v4l2_ctrl_handler_init(mt9v032-ctrls, ARRAY_SIZE(mt9v032_ctrls) + 6);
v4l2_ctrl_new_std(mt9v032-ctrls, mt9v032_ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
@@ -715,10 +735,27 @@ static int mt9v032_probe(struct i2c_client *client,
V4L2_CID_EXPOSURE, MT9V032_TOTAL_SHUTTER_WIDTH_MIN,
MT9V032_TOTAL_SHUTTER_WIDTH_MAX, 1,
MT9V032_TOTAL_SHUTTER_WIDTH_DEF);
+
mt9v032-pixel_rate =
v4l2_ctrl_new_std(mt9v032-ctrls, mt9v032_ctrl_ops,
V4L2_CID_PIXEL_RATE, 0, 0, 1, 0);
+ if (pdata pdata-link_freqs) {
+ unsigned int def = 0;
+
+ for (i = 0; pdata-link_freqs[i]; ++i) {
+ if (pdata-link_freqs[i] == pdata-link_def_freq)
+ def = i;
+ }
+
+ mt9v032-link_freq =
+ v4l2_ctrl_new_int_menu(mt9v032-ctrls,
+ mt9v032_ctrl_ops,
+ V4L2_CID_LINK_FREQ, i - 1, def,
+
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans,
On 07/31/2012 02:11 PM, Hans Verkuil wrote:
On Tue 31 July 2012 13:56:14 Laurent Pinchart wrote:
Hi Hans,
On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
On Thu June 14 2012 16:32:23 Tomasz Stanislawski wrote:
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor + *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
struct + * v4l2_buffer::m.offset (for single-plane formats) or
+ *v4l2_plane::m.offset (for multi-planar formats)
+ * @flags:flags for newly created file, currently only O_CLOEXEC
is
+ *supported, refer to manual of open syscall for more
details
+ *
+ * Contains data used for exporting a video buffer as DMABUF file
descriptor. + * The buffer is identified by a 'cookie' returned by
VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
userspace). All + * reserved fields must be set to zero. The field
reserved0 is expected to + * become a structure 'type' allowing an
alternative layout of the structure + * content. Therefore this field
should not be used for any other extensions. + */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
+ __u32 mem_offset;
This should be a union identical to the m union in v4l2_plane, together with
a u32 memory field. That way you can just copy memory and m from
v4l2_plane/buffer and call expbuf. If new memory types are added in the
future, then you don't need to change this struct.
OK, reserved0 could be replace by __u32 memory. Could we have other dma-buf
export types in the future not corresponding to a memory type ? I don't see
any use case right now though.
The memory type should be all you need. And the union is also needed since the
userptr value is unsigned long, thus ensuring that you have 64-bits available
for pointer types in the future. That's really my main point: the union should
have the same size as the union in v4l2_buffer/plane, allowing for the same
size pointers or whatever to be added in the future.
I do not see any good point in using v4l2_plane. What would be the meaning
of bytesused, length, data_offset in case of DMABUF exporting?
The field reserved0 was introduced to be replaced by __u32 memory if other means
of buffer description would be needed. The reserved fields at the end of
the structure could be used for auxiliary parameters other then offset and
flags.
The flags field is expected to be used by all exporting types therefore the
layout could be reorganized to:
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
alignment */
__u32 mem_offset; /* what do you thing about using 64-bit field? */
__u32 reserved1[11];
};
What is your opinion about this idea?
For that matter, wouldn't it be useful to support exporting a userptr buffer
at some point in the future?
Shouldn't USERPTR usage be discouraged once we get dma-buf support ?
Why? It's perfectly fine to use it and it's not going away.
I'm not saying that we should support exporting a userptr buffer as a dmabuf
fd,
but I'm just wondering if that is possible at all and how difficult it would
be.
It would be difficult. Currently there is no safe/portable way to transform
a userptr into a scatterlist mappable for other devices. The most trouble
some examples are userspace-mapping of IO memory like framebuffers.
How reference management is going to work if there are no struct pages
describing mapped memory?
The VB2 uses a workaround by keeping a copy of vma that is used to call
open/close callbacks. I am not sure how reliable this solution is.
Who knows, maybe in future someone will introduce a mechanism for creation of
DMABUF descriptor from a userptr without any help of client APIs.
In such a case, it will be the part of DMABUF api not V4L2 :).
Regards,
Tomasz Stanislawski
Regards,
Hans
BTW, this patch series needs to be rebased to the latest for_v3.6. Quite a
few core things have changed when it comes to adding new ioctls.
--
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 v2] media: mx3_camera: buf_init() add buffer state check
From: Alex Gershgorin al...@meprolight.com
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin al...@meprolight.com
[g.liakhovet...@gmx.de: remove mx3_camera_buffer::state completely]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hi Alex
Thanks for your explanation. Please, check whether this version of your
patch also fixes the problem and works in both MMAP and USERPTR modes.
Thanks
Guennadi
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 02d54a0..0af24d0 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -61,15 +61,9 @@
#define MAX_VIDEO_MEM 16
-enum csi_buffer_state {
- CSI_BUF_NEEDS_INIT,
- CSI_BUF_PREPARED,
-};
-
struct mx3_camera_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
- enum csi_buffer_state state;
struct list_headqueue;
/* One descriptot per scatterlist (per frame) */
@@ -285,7 +279,7 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
goto error;
}
- if (buf-state == CSI_BUF_NEEDS_INIT) {
+ if (!buf-txd) {
sg_dma_address(sg) = vb2_dma_contig_plane_dma_addr(vb, 0);
sg_dma_len(sg) = new_size;
@@ -298,7 +292,6 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
txd-callback_param = txd;
txd-callback = mx3_cam_dma_done;
- buf-state = CSI_BUF_PREPARED;
buf-txd= txd;
} else {
txd = buf-txd;
@@ -385,7 +378,6 @@ static void mx3_videobuf_release(struct vb2_buffer *vb)
/* Doesn't hurt also if the list is empty */
list_del_init(buf-queue);
- buf-state = CSI_BUF_NEEDS_INIT;
if (txd) {
buf-txd = NULL;
@@ -405,13 +397,13 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
struct mx3_camera_dev *mx3_cam = ici-priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(buf-queue);
- sg_init_table(buf-sg, 1);
+ if (!buf-txd) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(buf-queue);
+ sg_init_table(buf-sg, 1);
- buf-state = CSI_BUF_NEEDS_INIT;
-
- mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Tomasz,
On Wednesday 01 August 2012 10:01:45 Tomasz Stanislawski wrote:
On 07/31/2012 02:11 PM, Hans Verkuil wrote:
On Tue 31 July 2012 13:56:14 Laurent Pinchart wrote:
On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
On Thu June 14 2012 16:32:23 Tomasz Stanislawski wrote:
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor + *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF
in
struct + * v4l2_buffer::m.offset (for single-plane
formats) or
+ * v4l2_plane::m.offset (for multi-planar formats)
+ * @flags: flags for newly created file, currently only O_CLOEXEC
is
+ * supported, refer to manual of open syscall for more
details
+ *
+ * Contains data used for exporting a video buffer as DMABUF file
descriptor. + * The buffer is identified by a 'cookie' returned by
VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer
to
userspace). All + * reserved fields must be set to zero. The field
reserved0 is expected to + * become a structure 'type' allowing an
alternative layout of the structure + * content. Therefore this field
should not be used for any other extensions. + */
+struct v4l2_exportbuffer {
+__u32 fd;
+__u32 reserved0;
+__u32 mem_offset;
This should be a union identical to the m union in v4l2_plane, together
with a u32 memory field. That way you can just copy memory and m from
v4l2_plane/buffer and call expbuf. If new memory types are added in the
future, then you don't need to change this struct.
OK, reserved0 could be replace by __u32 memory. Could we have other
dma-buf
export types in the future not corresponding to a memory type ? I don't
see
any use case right now though.
The memory type should be all you need. And the union is also needed since
the userptr value is unsigned long, thus ensuring that you have 64-bits
available for pointer types in the future. That's really my main point:
the union should have the same size as the union in v4l2_buffer/plane,
allowing for the same size pointers or whatever to be added in the
future.
I do not see any good point in using v4l2_plane. What would be the meaning
of bytesused, length, data_offset in case of DMABUF exporting?
I don't think Hans meant using v4l2_plane directly, but to use the same union
as in v4l2_plane.
The field reserved0 was introduced to be replaced by __u32 memory if other
means of buffer description would be needed. The reserved fields at the end
of the structure could be used for auxiliary parameters other then offset
and flags. The flags field is expected to be used by all exporting types
therefore the layout could be reorganized to:
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
alignment
*/ __u32 mem_offset; /* what do you thing about using 64-bit field? */
__u32 reserved1[11];
};
What is your opinion about this idea?
For that matter, wouldn't it be useful to support exporting a userptr
buffer at some point in the future?
Shouldn't USERPTR usage be discouraged once we get dma-buf support ?
Why? It's perfectly fine to use it and it's not going away.
I'm not saying that we should support exporting a userptr buffer as a
dmabuf fd, but I'm just wondering if that is possible at all and how
difficult it would be.
It would be difficult. Currently there is no safe/portable way to transform
a userptr into a scatterlist mappable for other devices. The most trouble
some examples are userspace-mapping of IO memory like framebuffers.
How reference management is going to work if there are no struct pages
describing mapped memory?
The VB2 uses a workaround by keeping a copy of vma that is used to call
open/close callbacks. I am not sure how reliable this solution is.
Who knows, maybe in future someone will introduce a mechanism for creation
of DMABUF descriptor from a userptr without any help of client APIs.
In such a case, it will be the part of DMABUF api not V4L2 :).
--
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: linux-next: Tree for July 31 (media/radio-tea5777)
Thanks for fixing this for me! Acked-by: Hans de Goede hdego...@redhat.com On 07/31/2012 09:56 PM, Mauro Carvalho Chehab wrote: Em 31-07-2012 14:22, Randy Dunlap escreveu: drivers/built-in.o: In function `radio_tea5777_set_freq': radio-tea5777.c:(.text+0x4d8704): undefined reference to `__udivdi3' The patch below should fix it. Thanks for reporting it! Regards, Mauro [media] radio-tea5777: use library for 64bits div From: Mauro Carvalho Chehab mche...@redhat.com drivers/built-in.o: In function `radio_tea5777_set_freq': radio-tea5777.c:(.text+0x4d8704): undefined reference to `__udivdi3' Reported-by: Randy Dunlap rdun...@xenotime.net Cc: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/radio/radio-tea5777.c b/drivers/media/radio/radio-tea5777.c index 3e12179..5bc9fa6 100644 --- a/drivers/media/radio/radio-tea5777.c +++ b/drivers/media/radio/radio-tea5777.c @@ -33,6 +33,7 @@ #include media/v4l2-fh.h #include media/v4l2-ioctl.h #include media/v4l2-event.h +#include asm/div64.h #include radio-tea5777.h MODULE_AUTHOR(Hans de Goede pe...@perex.cz); @@ -158,10 +159,11 @@ static int radio_tea5777_set_freq(struct radio_tea5777 *tea) int res; freq = clamp_t(u32, tea-freq, - TEA5777_FM_RANGELOW, TEA5777_FM_RANGEHIGH); - freq = (freq + 8) / 16; /* to kHz */ + TEA5777_FM_RANGELOW, TEA5777_FM_RANGEHIGH) + 8; + do_div(freq, 16); /* to kHz */ - freq = (freq - TEA5777_FM_IF) / TEA5777_FM_FREQ_STEP; + freq -= TEA5777_FM_IF; + do_div(freq, TEA5777_FM_FREQ_STEP); tea-write_reg = ~(TEA5777_W_FM_PLL_MASK | TEA5777_W_FM_FREF_MASK); tea-write_reg |= freq TEA5777_W_FM_PLL_SHIFT; -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Wed 1 August 2012 10:01:45 Tomasz Stanislawski wrote:
Hi Hans,
On 07/31/2012 02:11 PM, Hans Verkuil wrote:
On Tue 31 July 2012 13:56:14 Laurent Pinchart wrote:
Hi Hans,
On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
On Thu June 14 2012 16:32:23 Tomasz Stanislawski wrote:
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor + *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
struct + * v4l2_buffer::m.offset (for single-plane
formats) or
+ * v4l2_plane::m.offset (for multi-planar formats)
+ * @flags: flags for newly created file, currently only O_CLOEXEC
is
+ * supported, refer to manual of open syscall for more
details
+ *
+ * Contains data used for exporting a video buffer as DMABUF file
descriptor. + * The buffer is identified by a 'cookie' returned by
VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
userspace). All + * reserved fields must be set to zero. The field
reserved0 is expected to + * become a structure 'type' allowing an
alternative layout of the structure + * content. Therefore this field
should not be used for any other extensions. + */
+struct v4l2_exportbuffer {
+__u32 fd;
+__u32 reserved0;
+__u32 mem_offset;
This should be a union identical to the m union in v4l2_plane, together
with
a u32 memory field. That way you can just copy memory and m from
v4l2_plane/buffer and call expbuf. If new memory types are added in the
future, then you don't need to change this struct.
OK, reserved0 could be replace by __u32 memory. Could we have other
dma-buf
export types in the future not corresponding to a memory type ? I don't
see
any use case right now though.
The memory type should be all you need. And the union is also needed since
the
userptr value is unsigned long, thus ensuring that you have 64-bits
available
for pointer types in the future. That's really my main point: the union
should
have the same size as the union in v4l2_buffer/plane, allowing for the same
size pointers or whatever to be added in the future.
I do not see any good point in using v4l2_plane. What would be the meaning
of bytesused, length, data_offset in case of DMABUF exporting?
The field reserved0 was introduced to be replaced by __u32 memory if other
means
of buffer description would be needed. The reserved fields at the end of
the structure could be used for auxiliary parameters other then offset and
flags.
The flags field is expected to be used by all exporting types therefore the
layout could be reorganized to:
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
alignment */
__u32 mem_offset; /* what do you thing about using 64-bit field? */
__u32 reserved1[11];
};
What is your opinion about this idea?
You're missing the point of my argument. How does v4l2_buffer work currently:
you
have a memory field and a union. The memory field determines which field of the
union is to be used. In order to be able to use VIDIOC_EXPBUF you need to be
able to add new memory types in the future. Currently only MMAP makes sense
here,
so all you need is the offset, but in order to be able to support future memory
types you need to make sure that you can extend v4l2_exportbuffers with the
largest possible value that v4l2_buffers can contain in the union, and that's
an unsigned long/pointer. That won't fit in the current proposal since there is
only
a u32.
So I would propose this:
struct v4l2_exportbuffers {
__u32 fd;
__u32 memory;
union {
__u32 mem_offset;
void *reserved; /* ensure that we can handle pointers in the
future */
} m;
__u32 flags;
__u32 reserved1[11];
};
That way an application can just do:
struct v4l2_buffer buf;
struct v4l2_exportbuffers expbuf;
expbuf.memory = buf.memory;
memcpy(expbuf.m, buf.m, sizeof(expbuf.m));
and VIDIOC_EXPBUF will return an error if expbuf.memory != V4L2_MEMORY_MMAP.
I was actually wondering whether it might not be an idea to pass a v4l2_buffer
directly to VIDIOC_EXPBUF. In order to support that you would have to add fd
fields to v4l2_buffer and v4l2_plane and those would be filled in by
VIDIOC_EXPBUF.
For the flags field in exportbuffers you would have to add new V4L2_BUF_FLAG_
flags.
That way you don't need to introduce a new struct and all planes are also
automatically exported. It's just an idea...
For that matter, wouldn't it be useful to support exporting a userptr
buffer
at some point in the future?
Shouldn't USERPTR usage be discouraged once we
Re: [PATCH v5 0/5] Add new driver for generic scaler
On 08/01/2012 09:35 AM, Sungchun Kang wrote: I'm sorry to be so late. Basically, I wonder important one thing. What would you implement a device driver connected with gscaler. For example, fimc-lite, mipi-csis. As you know Exynos5 has local-path with gscaler MIPI-CSIS = Fimc-lite = Gscaler And, you should use media control framework. So, We made exynos folder, and implement drivers with mc. We use mdev that is virtual device driver for connecting gscaler, fimc-lite, mipi-csis with MC. This is camera path. There are not only camera path but also rendering path. Gscaler = FIMD or TV Rendering path use mdev-0, Camera path use mdev-1. In conclusion, because we use to connect each other devices with MC, we made exynos folder. And how you make to implement devices with MC? As you may know, these patches only add mem-to-mem functionality, which can be used together with the Exynos multi-format video codec. Remaining features, as you listed, are planned to be added later, in subsequent steps, after discussing it here on the mailing list. I think it's much better approach, than coming up with a complete huge driver with many API compliance issues. Especially that some drivers, like MIPI-CSIS or FIMC-LITE are already in the mainline kernel. As for the driver directory name, IMHO drivers/media/exynos is too generic, s5p-fimc, s5p-jpeg, s5p-tv also cover some Exynos SoCs. I don't think having drivers/media/exynos directory would be helpful in anything. Regards, Sylwester -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Tue, 31 Jul 2012 23:52:35 +0200, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I want to receive the video buffers in user space for processing. Typically processing is software encoding or conversion. That's what virtually any V4L application does on the desktop... But what prevents you from using MMAP ? As I wrote several times earlier, MMAP uses fixed number of buffers. In some tightly controlled media pipeline with low latency, it might work. But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers. This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer. By the way, this was already discussed a few months ago for the exact same DMABUF patch series... -- Rémi Denis-Courmont Sent from my collocated server -- 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: [Workshop-2011] Media summit/KS-2012 proposals
On Tue 31 July 2012 19:58:23 Mauro Carvalho Chehab wrote: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Yes: I would like to discuss how to add support for HDMI CEC to the kernel. In particularly I need some feedback from the GPU driver developers on what their ideas are, since CEC is something that touches both V4L2 and GPU. I'm not sure what the best place is to do this, it's a fairly specialized topic. It might be better suited to just get a few interested devs together in the evening or during some other suitable time and just see if we can hammer out some scheme. I'll have a presentation on the topic ready. Rob, what are your ideas on this? Who else might be interested in this? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: mx2_camera: Fix clock handling for i.MX27.
This driver wasn't converted to the new clock framework
(e038ed50a4a767add205094c035b6943e7b30140).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 47 +-
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 3c38b5f..6de7c48 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -273,7 +273,7 @@ struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
struct soc_camera_device *icd;
- struct clk *clk_csi, *clk_emma;
+ struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
unsigned intirq_csi, irq_emma;
void __iomem*base_csi, *base_emma;
@@ -436,7 +436,7 @@ static void mx2_camera_deactivate(struct mx2_camera_dev
*pcdev)
{
unsigned long flags;
- clk_disable(pcdev-clk_csi);
+ clk_disable_unprepare(pcdev-clk_csi);
writel(0, pcdev-base_csi + CSICR1);
if (cpu_is_mx27()) {
writel(0, pcdev-base_emma + PRP_CNTL);
@@ -464,7 +464,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
if (pcdev-icd)
return -EBUSY;
- ret = clk_enable(pcdev-clk_csi);
+ ret = clk_prepare_enable(pcdev-clk_csi);
if (ret 0)
return ret;
@@ -1675,23 +1675,34 @@ static int __devinit mx27_camera_emma_init(struct
mx2_camera_dev *pcdev)
goto exit_iounmap;
}
- pcdev-clk_emma = clk_get(NULL, emma);
- if (IS_ERR(pcdev-clk_emma)) {
- err = PTR_ERR(pcdev-clk_emma);
+ pcdev-clk_emma_ipg = clk_get(pcdev-dev, emma-ipg);
+ if (IS_ERR(pcdev-clk_emma_ipg)) {
+ err = PTR_ERR(pcdev-clk_emma_ipg);
goto exit_free_irq;
}
- clk_enable(pcdev-clk_emma);
+ clk_prepare_enable(pcdev-clk_emma_ipg);
+
+ pcdev-clk_emma_ahb = clk_get(pcdev-dev, emma-ahb);
+ if (IS_ERR(pcdev-clk_emma_ahb)) {
+ err = PTR_ERR(pcdev-clk_emma_ahb);
+ goto exit_clk_emma_ipg_put;
+ }
+
+ clk_prepare_enable(pcdev-clk_emma_ahb);
err = mx27_camera_emma_prp_reset(pcdev);
if (err)
- goto exit_clk_emma_put;
+ goto exit_clk_emma_ahb_put;
return err;
-exit_clk_emma_put:
- clk_disable(pcdev-clk_emma);
- clk_put(pcdev-clk_emma);
+exit_clk_emma_ahb_put:
+ clk_disable_unprepare(pcdev-clk_emma_ahb);
+ clk_put(pcdev-clk_emma_ahb);
+exit_clk_emma_ipg_put:
+ clk_disable_unprepare(pcdev-clk_emma_ipg);
+ clk_put(pcdev-clk_emma_ipg);
exit_free_irq:
free_irq(pcdev-irq_emma, pcdev);
exit_iounmap:
@@ -1727,7 +1738,7 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit;
}
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
+ pcdev-clk_csi = clk_get(pdev-dev, ahb);
if (IS_ERR(pcdev-clk_csi)) {
dev_err(pdev-dev, Could not get csi clock\n);
err = PTR_ERR(pcdev-clk_csi);
@@ -1827,8 +1838,10 @@ exit_free_emma:
eallocctx:
if (cpu_is_mx27()) {
free_irq(pcdev-irq_emma, pcdev);
- clk_disable(pcdev-clk_emma);
- clk_put(pcdev-clk_emma);
+ clk_disable_unprepare(pcdev-clk_emma_ipg);
+ clk_put(pcdev-clk_emma_ipg);
+ clk_disable_unprepare(pcdev-clk_emma_ahb);
+ clk_put(pcdev-clk_emma_ahb);
iounmap(pcdev-base_emma);
release_mem_region(pcdev-res_emma-start,
resource_size(pcdev-res_emma));
}
@@ -1867,8 +1880,10 @@ static int __devexit mx2_camera_remove(struct
platform_device *pdev)
iounmap(pcdev-base_csi);
if (cpu_is_mx27()) {
- clk_disable(pcdev-clk_emma);
- clk_put(pcdev-clk_emma);
+ clk_disable_unprepare(pcdev-clk_emma_ipg);
+ clk_put(pcdev-clk_emma_ipg);
+ clk_disable_unprepare(pcdev-clk_emma_ahb);
+ clk_put(pcdev-clk_emma_ahb);
iounmap(pcdev-base_emma);
res = pcdev-res_emma;
release_mem_region(res-start, resource_size(res));
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for v3.6] Fix mem2mem_testdev querycap regression
On 08/01/2012 09:32 AM, Hans Verkuil wrote: Trival but important patch. Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/video/mem2mem_testdev.c b/drivers/media/video/mem2mem_testdev.c index 7efe9ad..0b91a5c 100644 --- a/drivers/media/video/mem2mem_testdev.c +++ b/drivers/media/video/mem2mem_testdev.c @@ -431,7 +431,7 @@ static int vidioc_querycap(struct file *file, void *priv, strncpy(cap-driver, MEM2MEM_NAME, sizeof(cap-driver) - 1); strncpy(cap-card, MEM2MEM_NAME, sizeof(cap-card) - 1); strlcpy(cap-bus_info, MEM2MEM_NAME, sizeof(cap-bus_info)); - cap-capabilities = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING; + cap-device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING; cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS; return 0; } Oops, my bad. Thanks for fixing this Hans! Regards, Sylwester -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans,
I do not see any good point in using v4l2_plane. What would be the meaning
of bytesused, length, data_offset in case of DMABUF exporting?
The field reserved0 was introduced to be replaced by __u32 memory if other
means
of buffer description would be needed. The reserved fields at the end of
the structure could be used for auxiliary parameters other then offset and
flags.
The flags field is expected to be used by all exporting types therefore the
layout could be reorganized to:
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
alignment */
__u32 mem_offset; /* what do you thing about using 64-bit field? */
__u32 reserved1[11];
};
What is your opinion about this idea?
You're missing the point of my argument. How does v4l2_buffer work currently:
you
have a memory field and a union. The memory field determines which field of
the
union is to be used. In order to be able to use VIDIOC_EXPBUF you need to be
able to add new memory types in the future. Currently only MMAP makes sense
here,
so all you need is the offset, but in order to be able to support future
memory
types you need to make sure that you can extend v4l2_exportbuffers with the
largest possible value that v4l2_buffers can contain in the union, and that's
an unsigned long/pointer. That won't fit in the current proposal since there
is only
a u32.
So I would propose this:
struct v4l2_exportbuffers {
__u32 fd;
__u32 memory;
union {
__u32 mem_offset;
void *reserved; /* ensure that we can handle pointers in the
future */
} m;
__u32 flags;
__u32 reserved1[11];
};
The layout about prevents adding any auxiliary fields other then mem_offset if
expbuf.memory == V4L2_MEMORY_MMAP. This could be fixed by the layout below
(it might be considered ugly by some people):
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 memory;
__u32 reserved;
union {
struct v4l2_exportbyoffset {
__u32 mem_offset;
__u32 reserved[11];
} byoffset;
struct v4l2_exportbyuserptr {
__u64 userptr;
__u32 reserved[10];
} byuserptr;
__u32 reserved[12];
};
};
Notice that the structure above in binary compatible with:
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 reserved0[2];
__u32 mem_offset;
__u32 reserved1[11];
};
That way an application can just do:
struct v4l2_buffer buf;
struct v4l2_exportbuffers expbuf;
expbuf.memory = buf.memory;
memcpy(expbuf.m, buf.m, sizeof(expbuf.m));
and VIDIOC_EXPBUF will return an error if expbuf.memory != V4L2_MEMORY_MMAP.
The other question is if we should use V4L2_MEMORY_MMAP as expbuf.memory.
I think that new enums should be introduced for this purpose. Exporting is
very different from buffer requesting or queuing. One could envision
extension to VIDIOC_EXPBUF for exporting a buffer as entity different then
DMABUF file. In such a case, the fd and flags should go to a separate union.
This argument supports *not* using any v4l2_buffer related structs for
VIDIOC_EXPBUF.
It should use its own structures. Likely, no extra structs are needed at the
moment.
I was actually wondering whether it might not be an idea to pass a v4l2_buffer
directly to VIDIOC_EXPBUF. In order to support that you would have to add fd
fields to v4l2_buffer and v4l2_plane and those would be filled in by
VIDIOC_EXPBUF.
For the flags field in exportbuffers you would have to add new V4L2_BUF_FLAG_
flags.
That way you don't need to introduce a new struct and all planes are also
automatically exported. It's just an idea...
One may not want to create DMABUF descriptors for all the planes.
The number of file descriptors is limited for the process.
Why creating file descriptor if they are going to closed or
(even worse) not used?
The mmap is called on each plane separately. So why VIDIOC_EXPBUF should
behave differently?
Regards,
Tomasz Stanislawski
--
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: Media summit/KS-2012 proposals
Hi Mauro, On 07/31/2012 07:58 PM, Mauro Carvalho Chehab wrote: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Unfortunately I won't be attending the media summit this time. Instead, my colleagues: Bartlomiej Zolnierkiewicz and Marek Szyprowski could cover the topic I proposed. Can you please add them to the list of attendants instead of me ? Best regards, Sylwester -- 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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
James bjloc...@lockie.ca wrote: I got the latest kernel from git and I can't find the kernel options for my tv card. I have: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 -- 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 /sbin/modinfo cx23885 Regards, Andy -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Rémi, On Wednesday 01 August 2012 10:37:02 Rémi Denis-Courmont wrote: On Tue, 31 Jul 2012 23:52:35 +0200, Laurent Pinchart wrote: I want to receive the video buffers in user space for processing. Typically processing is software encoding or conversion. That's what virtually any V4L application does on the desktop... But what prevents you from using MMAP ? As I wrote several times earlier, MMAP uses fixed number of buffers. In some tightly controlled media pipeline with low latency, it might work. Sorry about making you repeat. But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers. This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer. What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? By the way, this was already discussed a few months ago for the exact same DMABUF patch series... -- 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: Update VIP to videobuf2 and control framework
On Wed, 1 Aug 2012 08:41:56 +0200 Hans Verkuil hverk...@xs4all.nl wrote: The second patch adds a new memory allocator for the videobuf2. I name it videobuf2-dma-streaming but I think streaming is not the best choice, so suggestions are welcome. My inspiration for this buffer come from videobuf-dma-contig (cached) version. After I made this buffer I found the videobuf2-dma-nc made by Jonathan Corbet and I improve the allocator with some suggestions (http://patchwork.linuxtv.org/patch/7441/). The VIP doesn't work with videobu2-dma-contig and I think this solution is easier the sg. I leave this to the vb2 experts. It's not obvious to me why we would need a fourth memory allocator. I first wrote my version after observing that performance dropped by a factor of three on the OLPC XO 1.75 when using contiguous, coherent memory. If the architecture needs to turn off caching, things really slow down, to the point that it's unusable. There's no real reason why a V4L2 device shouldn't be able to use streaming mappings in this situation; it performs better and doesn't eat into the limited amounts of coherent DMA space available on some systems. I never got my version into a mergeable state only because I finally figured out how to bludgeon the hardware into doing s/g DMA and didn't need it anymore. But I think it's a worthwhile functionality to have, and, with CMA, it could be the preferred mode for a number of devices. 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: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Bhupesh, On Wednesday 01 August 2012 14:26:33 Bhupesh SHARMA wrote: Hi Laurent, I have a query for you regarding the support and testing of MJPEG frame type in the UVC webcam gadget. I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats are supported. I was trying the same out and got confused because the data arriving from a real video capture video supporting JPEG will have no fixed size. We will have the JPEG defined Start-of-Frame and End-of-Frame markers defining the boundary of the JPEG frame. But for almost all JPEG video capture devices even if we have kept a frame size of VGA initially, the final frame size will be a compressed version (with the compression depending on the nature of the scene, so a flat scene will have high compression and hence less frame size) of VGA and will not be equal to 640 * 480. So I couldn't exactly get why the dwMaxVideoFrameBufferSize is kept as 614400 in webcam.c (see [1]). The dwMaxVideoFrameBufferSize value must be larger than or equal to the largest MJPEG frame size. As I have no idea what that value is, I've kept the same size as for uncompressed frames, which should be big enough (and most probably too big). Can you please let me know your opinions and how you tested the UVC gadget's MJPEG frame format. [1] http://lxr.linux.no/linux+v3.5/drivers/usb/gadget/webcam.c#L232 -- 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: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Laurent, Thanks for clearing this doubt.. -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, August 01, 2012 6:46 PM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org Subject: Re: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget Hi Bhupesh, On Wednesday 01 August 2012 14:26:33 Bhupesh SHARMA wrote: Hi Laurent, I have a query for you regarding the support and testing of MJPEG frame type in the UVC webcam gadget. I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats are supported. I was trying the same out and got confused because the data arriving from a real video capture video supporting JPEG will have no fixed size. We will have the JPEG defined Start-of-Frame and End-of-Frame markers defining the boundary of the JPEG frame. But for almost all JPEG video capture devices even if we have kept a frame size of VGA initially, the final frame size will be a compressed version (with the compression depending on the nature of the scene, so a flat scene will have high compression and hence less frame size) of VGA and will not be equal to 640 * 480. So I couldn't exactly get why the dwMaxVideoFrameBufferSize is kept as 614400 in webcam.c (see [1]). The dwMaxVideoFrameBufferSize value must be larger than or equal to the largest MJPEG frame size. As I have no idea what that value is, I've kept the same size as for uncompressed frames, which should be big enough (and most probably too big). .. Yes, so that means that the user-space application should set the length of the buffer being queued at the UVC side equal to the length of the buffer dequeued from the V4L2 side, to ensure that varying length JPEG frames are correctly handled. I will try with these changes in the user-space daemon. Thanks for your help, Regards, Bhupesh Can you please let me know your opinions and how you tested the UVC gadget's MJPEG frame format. [1] http://lxr.linux.no/linux+v3.5/drivers/usb/gadget/webcam.c#L232 -- 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: set default protocol for TerraTec Cinergy XXS to nec
On 07/30/2012 06:13 PM, Mauro Carvalho Chehab wrote: Em 16-07-2012 17:22, Toralf Förster escreveu: /me wonders whether nec should be set as the default for this key in kernel or not It makes sense to patch it to use the nec protocol. If not all keys are working, it also makes sense to fix the kernel table to handle all codes, or to point to a new table where all Terratec keys are defined. With this command : $ ir-keytable --protocol=nec --sysdev=`ir-keytable 21 | head -n 1 | cut -f5 -d'/'` -w /etc/rc_keymaps/dib0700_nec I get it to working. FWIW it is the USB_PID_TERRATEC_CINERGY_T_XXS_2 (ID 0ccd:00ab TerraTec Electronic GmbH) id. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] media: mx3_camera: buf_init() add buffer state check
From: Alex Gershgorin al...@meprolight.com
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin al...@meprolight.com
[g.liakhovet...@gmx.de: remove mx3_camera_buffer::state completely]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hi Alex
Thanks for your explanation. Please, check whether this version of your
patch also fixes the problem and works in both MMAP and USERPTR modes.
Thanks
Guennadi
Hi Guennadi,
This is a good upgrade :-)
I tested both modes, it works fine without any problems.
Sincerely,
Alex
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 02d54a0..0af24d0 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -61,15 +61,9 @@
#define MAX_VIDEO_MEM 16
-enum csi_buffer_state {
- CSI_BUF_NEEDS_INIT,
- CSI_BUF_PREPARED,
-};
-
struct mx3_camera_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
- enum csi_buffer_state state;
struct list_headqueue;
/* One descriptot per scatterlist (per frame) */
@@ -285,7 +279,7 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
goto error;
}
- if (buf-state == CSI_BUF_NEEDS_INIT) {
+ if (!buf-txd) {
sg_dma_address(sg) = vb2_dma_contig_plane_dma_addr(vb, 0);
sg_dma_len(sg) = new_size;
@@ -298,7 +292,6 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
txd-callback_param = txd;
txd-callback = mx3_cam_dma_done;
- buf-state = CSI_BUF_PREPARED;
buf-txd= txd;
} else {
txd = buf-txd;
@@ -385,7 +378,6 @@ static void mx3_videobuf_release(struct vb2_buffer *vb)
/* Doesn't hurt also if the list is empty */
list_del_init(buf-queue);
- buf-state = CSI_BUF_NEEDS_INIT;
if (txd) {
buf-txd = NULL;
@@ -405,13 +397,13 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
struct mx3_camera_dev *mx3_cam = ici-priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(buf-queue);
- sg_init_table(buf-sg, 1);
+ if (!buf-txd) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(buf-queue);
+ sg_init_table(buf-sg, 1);
- buf-state = CSI_BUF_NEEDS_INIT;
-
- mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] media DT bindings
On 07/31/2012 11:59 PM, Laurent Pinchart wrote:
Hi Stephen,
On Tuesday 31 July 2012 17:29:24 Stephen Warren wrote:
On 07/31/2012 03:22 PM, Laurent Pinchart wrote:
On Tuesday 31 July 2012 14:39:07 Guennadi Liakhovetski wrote:
...
Ok, then, how about
#address-cells = 1;
#size-cells = 0;
...
ov772x-1 = {
reg = 1; /* local pad # */
client = ov772x@0x21-0 0;/* remote phandle and
pad */
The client property looks good, but isn't such a usage of the reg property
an abuse ? Maybe the local pad # should be a device-specific property.
Many hosts won't need it, and on others it would actually need to
reference a subdev, not just a pad.
That's a very odd syntax the the phandle; I assume that ov772x@0x21-0
is supposed to reference some other DT node. However, other nodes are
either referenced by:
foo where foo is a label, and the label name is unlikely to include
the text @0x21; the @ symbol probably isn't even legal in label names.
{/path/to/node} which might include the @0x21 syntax since it might
be part of the node's name, but your example didn't include {}.
I'm not sure what -0 is meant to be in that string - a math
expression, or ...? If it's intended to represent some separate field
relative to the node the phandle references, it needs to be just another
cell.
I'm actually not sure what -0 represents, and I don't think we need the
@0x21-0 at all. I believe ov772x@0x21-0 is supposed to just be a label. We
don't need an extra cell.
Ah, OK. The lexer in dtc has the following definition for label names:
LABEL [a-zA-Z_][a-zA-Z0-9_]*
--
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
[ANNOUNCE] patchwork notifications
Hi Developers, Just to let you know, I finally made patchwork notifications to work. With this change, every time a patch (or a group of patches) have their status changed, an email will be sent to the patch author, similar to this one: The following patches (submitted by you) have been updated in patchwork: * [43/47,media] mt2063: add some useful info for the dvb callback calls - http://patchwork.linuxtv.org/patch/9332/ was: New now: RFC * [2/4,media] DocBook/dvbproperty.xml: Fix ISDB-T delivery system parameters - http://patchwork.linuxtv.org/patch/9557/ was: New now: Accepted * [13/35,media] az6007: need to define drivers name before including dvb-usb.h - http://patchwork.linuxtv.org/patch/9593/ was: New now: Accepted ... Developers that don't want this feature can opt-out, using this link: http://patchwork.linuxtv.org/mail/ Still, I suggest you to don't to that ;) As a reminder, the policy I'm using to handle patches is: New patches are marked there as 'New'. When I'm expecting someone (typically, the driver's author) to review a patch, the status is changed to 'Under review'. Unfortunately, patchwork doesn't have a field to indicate to whom, so I'm currently this information on a separate file on my local machine. When the same patch is sent twice, or a new version of the same patch and I am able to identify it, the old patch is marked as 'superseded'. When someone asks for changes at the patch, the patch is marked as 'changes requested'. When the patch is wrong or doesn't apply, it is marked as 'rejected'. Most of the time, 'rejected' and 'changes requested' means the same thing for the developer: he'll need to re-work on the patch. Patches that aren't meant to be applicable at the media-tree.git are typically marked as 'not applicable' [1]. Finally, when everything is ok and it got applied either at the main tree or at the fixes tree, the patch is marked as 'accepted'. Of course, as we're all humans (and patchwork status is changed manually by me), errors may happen. Feel free to ping me on irc or via email on such cases. [1] Just to make my life easier, patches for a few other random trees that I maintain/partially maintain, like media-build tree, are generally marked as 'Accepted' as well, when I am the one applying it, as it saves me time ;) I hope you'll find this new tool useful. 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
[MINI SUMMIT] media mini-summit at KS/2012
After the discussions around the media mini-summit, this is the consolidated list of topics. We tried to give a fair time for each topic. With regards to the proposed topic Intel media SDK, nobody volunteered to give such a talk. So, if there is anyone interested to talk about it, it can either be part of SoC vendor's feedback (if it won't take too long), or it could be handled as a topic during LPC. So, let's put this one in the fridge. Topics for the media mini-summit - morning: V4L2 API ambiguities + v4l2 compliance tool: 60 min Media Controller library: 30 min ALSA and V4L/Media Controller: 30 min ARM and needed features for V4L/DVB: 30 min - after lunch: SoC Vendors feedback – how to help them to go upstream: 45 min V4L2/DVB issues from userspace perspective: 45 min Android's V4L2 cam library: 30 min HDMI CEC: 30 min Synchronization, shared resource and optimizations: 30 min The DT discussions will likely require more time and maybe a different audience. So, it seems better to handle it as either as a separate/LPC section or at DT mini-summit: Common device tree bindings for media devices: 45 min Attendants == Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hans.verk...@xs4all.nl Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab mche...@redhat.com Michael Krufky mkru...@linuxtv.org Naveen Krishnamurthy naveen.krishnamur...@st.com Palash Bandyopadhyay palash.bandyopadh...@conexant.com Pawel Osciak pa...@osciak.com Rémi Denis-Courmont r...@remlab.net Sakari Ailus sakari.ai...@iki.fi Sri Deevi srinivasa.de...@conexant.com Steven Toth st...@kernellabs.com Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Marek Szyprowski m.szyprow...@samsung.com Kamil Debski k.deb...@samsung.com Naveen also asked another seat for ST, but didn't provide us yet the name of the other interested party. For the cross-system topics, it is important to have people from the other subsystems there. So, we're proposing to have some people there, but we need to double-check if they can really be there for the discussions. Of course, other Kernel developers from KS/LPC that work on those subsystems are welcome. The names that came up during our discussions for those panels are: Rob Clark rob.cl...@linaro.org (HDMI CEC, ALSA, ARM) Takashi Iwai ti...@suse.de (ALSA) Catalin Marinas catalin.mari...@arm.com (ARM) Mark Brown broo...@opensource.wolfsonmicro.com (DT) Not sure if they all will be there or if they'll have some time to discuss those things with us. We hope they will ;) Thanks, Mauro Carvalho Chehab Hans Verkuil -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Aug 1 19:00:23 CEST 2012 git hash:24ed693da0cefede7382d498dd5e9a83f0a21c38 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: ERRORS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: 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 V4L-DVB specification 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
[GIT PULL FOR v3.6] uvcvideo fixes
Hi Mauro, Resending the pull request, without changing the git request-pull text this time. The following changes since commit 931efdf58bd83af8d0578a6cc53421675daf6d41: Merge branch 'v4l_for_linus' into staging/for_v3.6 (2012-07-14 15:45:44 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Jayakrishnan Memana (1): uvcvideo: Reset the bytesused field when recycling an erroneous buffer drivers/media/video/uvc/uvc_queue.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- 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: [Ksummit-2012-discuss] [MINI SUMMIT] media mini-summit at KS/2012
On Wed, Aug 01, 2012 at 04:17:07PM -0300, Mauro Carvalho Chehab wrote: The names that came up during our discussions for those panels are: Rob Clark rob.cl...@linaro.org (HDMI CEC, ALSA, ARM) Takashi Iwai ti...@suse.de (ALSA) Catalin Marinas catalin.mari...@arm.com (ARM) Mark Brown broo...@opensource.wolfsonmicro.com (DT) Not sure if they all will be there or if they'll have some time to discuss those things with us. We hope they will ;) I'll be around, though potentially otherwise engaged (depending on when tis is schedled for). I'm also pretty familiar with ARM and ALSA. -- 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 for v3.6] VIDIOC_ENUM_FREQ_BANDS fix
When VIDIOC_ENUM_FREQ_BANDS is called for a driver that doesn't supply an enum_freq_bands op, then it will fall back to reporting a single freq band based on information from g_tuner or g_modulator. Due to a bug this is an infinite list since the index field wasn't tested. This patch fixes this and returns -EINVAL if index != 0. Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index c3b7b5f..54f4ac6 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -1853,6 +1853,8 @@ static int v4l_enum_freq_bands(const struct v4l2_ioctl_ops *ops, .type = type, }; + if (p-index) + return -EINVAL; err = ops-vidioc_g_tuner(file, fh, t); if (err) return err; @@ -1870,6 +1872,8 @@ static int v4l_enum_freq_bands(const struct v4l2_ioctl_ops *ops, if (type != V4L2_TUNER_RADIO) return -EINVAL; + if (p-index) + return -EINVAL; err = ops-vidioc_g_modulator(file, fh, m); if (err) return err; -- 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] Add support for Prof Revolution DVB-S2 8000 PCI-E card
On 07/26/2012 08:08 PM, Mariusz Bialonczyk wrote: The device is based on STV0903 demodulator, STB6100 tuner and CX23885 chipset; subsystem id: 8000:3034 Signed-off-by: Mariusz Bialonczyk ma...@skyboo.net Igor, can I please get your ACK on this patch? I was contacting proftuners for information who is the author of the prof8000 patch (on their website), but i haven't got a clear answer, they only point me your hg repo. regards, -- Mariusz Białończyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net -- 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 for v3.6] Add missing logging for rangelow/high of hwseek
struct v4l2_hw_freq_seek has two new fields that weren't printed in the
logging function. Added.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index c3b7b5f..6bc47fc 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -402,8 +402,10 @@ static void v4l_print_hw_freq_seek(const void *arg, bool
write_only)
{
const struct v4l2_hw_freq_seek *p = arg;
- pr_cont(tuner=%u, type=%u, seek_upward=%u, wrap_around=%u,
spacing=%u\n,
- p-tuner, p-type, p-seek_upward, p-wrap_around, p-spacing);
+ pr_cont(tuner=%u, type=%u, seek_upward=%u, wrap_around=%u, spacing=%u,
+ rangelow=%u, rangehigh=%u\n,
+ p-tuner, p-type, p-seek_upward, p-wrap_around, p-spacing,
+ p-rangelow, p-rangehigh);
}
static void v4l_print_requestbuffers(const void *arg, bool write_only)
--
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 for v3.6] VIDIOC_ENUM_FREQ_BANDS fix
Le mercredi 1 août 2012 22:52:46 Hans Verkuil, vous avez écrit : When VIDIOC_ENUM_FREQ_BANDS is called for a driver that doesn't supply an enum_freq_bands op, then it will fall back to reporting a single freq band based on information from g_tuner or g_modulator. By the way... Isn't V4L2_TUNER_CAP_FREQ_BANDS expected to tell whether the driver can enumerate bands? Why is there a need for fallback implementation? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mercredi 1 août 2012 14:35:03 Laurent Pinchart, vous avez écrit : But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers. This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer. What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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] davinci: vpfe: Add documentation
Hi Manju,
Thanks for the patch.
Please make sure these patches reach linux-media next time. If they do not,
it severely limits the number of potential reviewers. I don't know why, but
the original patch isn't on linux-media even if the list was cc'd.
Dropping linux-kernel from cc.
Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
Documentation/video4linux/davinci-vpfe-mc.txt | 263 +
1 files changed, 263 insertions(+), 0 deletions(-)
create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
b/Documentation/video4linux/davinci-vpfe-mc.txt
new file mode 100644
index 000..968194f
--- /dev/null
+++ b/Documentation/video4linux/davinci-vpfe-mc.txt
@@ -0,0 +1,263 @@
+Davinci Video processing Front End (VPFE) driver
+
+Copyright (C) 2012 Texas Instruments Inc
+
+Contacts: Manjunath Hadli manjunath.ha...@ti.com
+
+Introduction
+
+
+This file documents the Texas Instruments Davinci Video processing Front End
+(VPFE) driver located under drivers/media/video/davinci. The original driver
+exists for Davinci VPFE, which is now being changed to Media Controller
+Framework.
+
+Currently the driver has been successfully used on the following version of
Davinci:
+
+ DM365/DM368
+
+The driver implements V4L2, Media controller and v4l2_subdev interfaces.
+Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
+are supported.
+
+
+Split to subdevs
+
+
+The Davinic VPFE is split into V4L2 subdevs, each of the blocks inside the VPFE
+having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
+interface to userspace.
+
+ DAVINCI CCDC
+ DAVINCI PREVIEWER
+ DAVINCI RESIZER
+ DAVINCI AEW
+ DAVINCI AF
+
+Each possible link in the VPFE is modeled by a link in the Media controller
+interface. For an example program see [1].
+
+
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports standard V4L2
+IOCTLs and controls where possible and practical. Much of the functions
provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+ Sets/Gets the parameters required by the previewer module
+Parameter:
+ /**
+* struct prev_module_param- structure to configure preview modules
+* @version: Version of the preview module
+* @len: Length of the module config structure
+* @module_id: Module id
+* @param: pointer to module config parameter.
+*/
+ struct prev_module_param {
+ char version[IMP_MAX_NAME_SIZE];
+ unsigned short len;
+ unsigned short module_id;
+ void *param;
+ };
In addition to what Laurent commented on this, could the version
information be passed in struct media_entity_desc instead?
As a general comment, it's a bad idea to design an API that allows passing
blobs, especially when the expected size of the blobs isn't known. That
really equals to asking for trouble.
That said, I know this is an area where complete documentation is acarce,
but I think that at least the memory layout of the current blob pointers
should be visible in the struct definitions whenever possible. See e.g. the
OMAP 3 ISP driver.
+2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
+Description:
+ Sets/Gets the configuration required by the previewer channel
+Parameter:
+ /**
+* struct prev_channel_config - structure for configuring the previewer
channel
+* @len: Length of the user configuration
+* @config: pointer to either single shot config or continuous
+*/
+ struct prev_channel_config {
+ unsigned short len;
+ void *config;
+ };
+
+3: IOCTL: PREV_ENUM_CAP
+Description:
+ Queries the modules available in the image processor for preview the
+ input image.
+Parameter:
+ /**
+* struct prev_cap - structure to enumerate capabilities of previewer
+* @index: application use this to iterate over the available modules
+* @version: version of the preview module
+* @module_id: module id
+* @control: control operation allowed in continuous mode? 1 - allowed,
0 - not allowed
+* @path: path on which the module is sitting
+* @module_name: module name
+*/
+ struct prev_cap {
+ unsigned short index;
+ char version[IMP_MAX_NAME_SIZE];
+ unsigned short module_id;
Huh? How many
Re: [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365
Hi Prabhakar,
Thanks for the patch.
On Fri, Jul 27, 2012 at 04:25:05PM +0530, Prabhakar Lad wrote:
From: Manjunath Hadli manjunath.ha...@ti.com
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |2 +
include/linux/videodev2.h |8 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000..c934192
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ refentry
+ refmeta
+ refentrytitle
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+ /refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname id=V4L2-PIX-FMT-SBGGR10ALAW8
+ constantV4L2_PIX_FMT_SBGGR10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGBRG10ALAW8
+ constantV4L2_PIX_FMT_SGBRG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGRBG10ALAW8
+ constantV4L2_PIX_FMT_SGRBG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SRGGB10ALAW8
+ constantV4L2_PIX_FMT_SRGGB10ALAW8/constant
+ /refname
+ refpurpose10-bit Bayer formats compressed to 8 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraThe following four pixel formats are raw sRGB / Bayer
+ formats with 10 bits per color compressed to 8 bits each,
+ using the A-LAW algorithm. Each color component consumes 8
+ bits of memory. In other respects this format is similar to
+ xref linkend=V4L2-PIX-FMT-SRGGB8./xref/para
+ /refsect1
+ /refentry
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+ refentry id=V4L2-PIX-FMT-UV8
+ refmeta
+ refentrytitleV4L2_PIX_FMT_UV8 ('UV8')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_UV8/constant/refname
+ refpurposeUV plane interleaved/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraIn this format there is no Y plane, Only CbCr plane. ie
+ (UV interleaved)/para
+ example
+ title
+ constantV4L2_PIX_FMT_UV8/constant
+pixel image
+ /title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript20/subscript/entry
+ entryCrsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCrsubscript21/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryCbsubscript30/subscript/entry
+
Re: [GIT PULL FOR v3.6] DVB USB v2
On 07/31/2012 02:52 AM, Antti Palosaari wrote: On 07/30/2012 11:46 PM, Mauro Carvalho Chehab wrote: Em 09-07-2012 15:49, Antti Palosaari escreveu: On 07/07/2012 01:22 AM, Mauro Carvalho Chehab wrote: Em 03-07-2012 18:47, Antti Palosaari escreveu: On 07/02/2012 04:08 PM, Antti Palosaari wrote: Here it is finally - quite totally rewritten DVB-USB-framework. I haven't got almost any feedback so far... I rebased it in order to fix compilation issues coming from Kconfig. regards Antti The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git dvb_usb_pull for you to fetch changes up to 747abaa1e0ee4415e67026c119cb73e6277f4898: dvb_usb_v2: remove usb_clear_halt() from stream (2012-07-02 15:54:29 +0300) Antti Palosaari (103): dvb_usb_v2: copy current dvb_usb as a starting point Naming the DVB USB v2 as dvb_usb, instead of dvb-usb is very very ugly. It took me some time to discover what happened. You should have named it as dvb-usb-v2 instead, or to store it into a separate directory. This is even worse as it seems that this series doesn't change all drivers to use dvb usb v2. So, it will be harder to discover what drivers are at V1 and what are at V2. I won't merge it as-is at staging/for_v3.6. I may eventually create a separate topic branch and add them there, while the namespace mess is not corrected, if I still have some time today. Otherwise, I'll only handle that after returning from vacations. I moved it to the dvb-usb-v2 directory. Same location only added patch top of that. Surely I can convert all drivers and use old directory, but IMHO it is simply too risky. We have already too much problems coming from that kind of big changes. And what goes to file naming hyphen (-) vs. underscore (_), underscore seems to be much more common inside Kernel. Anyhow, I keep directory name as dvb-usb-v2 to follow old naming. $ find ./ -type f -printf %f\n | grep _ | wc -l 21465 $ find ./ -type f -printf %f\n | grep - | wc -l 13927 The above works for me, but unfortunately, the tree can't be applied. The fact is that there are lots of duplicated symbols between dvb-usb and dvb-usb-v2. They'll fail if someone would compile everything bultin (make allyesconfig). I tried to remove the Kconfig/Makefile changes from the initial patch, moving it to happen just before the first driver using dvb-usb-v2. See: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/dvb-usb-v2 The patch that adds it to the build system is enclosed. It is basically what's there at the initial patch, plus the changes done at the intermediate patches at the Makefile. The result is shown below: # make ARCH=i386 allyesconfig ... $ make ARCH=i386 CONFIG_DEBUG_SECTION_MISMATCH=y M=drivers/media drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `_GLOBAL__sub_I_65535_0_dvb_usb_download_firmware': /home/v4l/v4l/patchwork/include/linux/usb.h:197: multiple definition of `dvb_usb_disable_rc_polling' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/include/linux/usb.h:1570: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `usb_urb_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb_urb.c:310: multiple definition of `usb_urb_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb-urb.c:213: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_frontend_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:332: multiple definition of `dvb_usb_adapter_frontend_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:221: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_exit': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:260: multiple definition of `dvb_usb_adapter_dvb_exit' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:164: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:191: multiple definition of `dvb_usb_adapter_dvb_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:98: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_device_power_ctrl': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_init.c:254: multiple definition of `dvb_usb_device_power_ctrl' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-init.c:216: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_remote_init':
Re: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
On 08/01/12 07:07, Andy Walls wrote: James bjloc...@lockie.ca wrote: I got the latest kernel from git and I can't find the kernel options for my tv card. I have: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 -- 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 /sbin/modinfo cx23885 Regards, Andy I don't build any modules. In case anyone else has trouble getting to work (the kernel makes options invisible unless dependencies are met). 1. Turn on expert mode (to be able to select frontends to build). General setup/Configure standard kernel features (expert users) 2. Device Drivers/Multimedia support 3. Analog TV support 4. Digital TV support 5. Remote Controller support 6. Customize analog and hybrid tuner modules to build Customize TV tuners --- Microtune MT2131 silicon tuner 7. V4L PCI(e) devices/Conexant cx23885 (2388x successor) support 8. DVB/ATSC adapters --- Customise the frontend modules to build/Customise DVB Frontends/Samsung S5H1409 based I think that is it but I did other stuff so I may be missing a step or 2. Can I make the make menuconfig show all the options an when I select something, it selects all the dependencies? -- 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
