Re: [PATCH] dvb/as102 nBox DVB-T dongle
Hi,
Could someone pull the AS102 driver into the media tree?
http://git.linuxtv.org/media_tree.git/tree/HEAD:/drivers/media/dvb
--HPS
On Wednesday 20 July 2011 22:29:41 Piotr Chmura wrote:
I just bought DVB-T USB dongle for one of polish digital platform. It
works fine with as102 driver.
Here is patch adding vendor and product ID to as102 driver taken from
http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102.
I tested it with kernel-3.0-rc7-git7 (had to change usb_buffer_alloc()
to usb_alloc_coherent and usb_buffer_free to usb_free_coherent() ).
patch:
diff -Nur linux/drivers/media/dvb/as102/as102_usb_drv.c
linux-mine/drivers/media/dvb/as102/as102_usb_drv.c
--- as102/as102_usb_drv.c2011-07-20 21:37:33.924143297 +0200
+++ /usr/src/linux/drivers/media/dvb/as102/as102_usb_drv.c2011-07-20
20:40:21.0 +0200
@@ -39,6 +39,7 @@
static struct usb_device_id as102_usb_id_table[] = {
{ USB_DEVICE(AS102_USB_DEVICE_VENDOR_ID, AS102_USB_DEVICE_PID_0001)
}, { USB_DEVICE(PCTV_74E_USB_VID, PCTV_74E_USB_PID) },
+{ USB_DEVICE(NBOX_USB_VID, NBOX_USB_PID) },
{ USB_DEVICE(ELGATO_EYETV_DTT_USB_VID, ELGATO_EYETV_DTT_USB_PID) },
{ } /* Terminating entry */
};
@@ -48,6 +49,7 @@
static const char *as102_device_names[] = {
AS102_REFERENCE_DESIGN,
AS102_PCTV_74E,
+AS102_NBOX,
AS102_ELGATO_EYETV_DTT_NAME,
NULL /* Terminating entry */
};
diff -Nur linux/drivers/media/dvb/as102/as102_usb_drv.h
linux-mine/drivers/media/dvb/as102/as102_usb_drv.h
--- as102/as102_usb_drv.h2011-07-20 21:37:33.925143297 +0200
+++ /usr/src/linux/drivers/media/dvb/as102/as102_usb_drv.h2011-07-20
20:39:46.0 +0200
@@ -36,6 +36,11 @@
#define PCTV_74E_USB_VID0x2013
#define PCTV_74E_USB_PID0x0246
+/* nBox DVB-T Stick */
+#define AS102_NBOXnBox DVB-T Stick
+#define NBOX_USB_VID0x0b89
+#define NBOX_USB_PID0x0007
+
/* Elgato: EyeTV DTT Deluxe */
#define AS102_ELGATO_EYETV_DTT_NAMEElgato EyeTV DTT Deluxe
#define ELGATO_EYETV_DTT_USB_VID0x0fd9
--
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: [Linaro-mm-sig] [PATCH 8/9] ARM: integrate CMA with DMA-mapping subsystem
Hello, On Friday, October 14, 2011 6:33 AM Subash Patel wrote: Hi Marek, As informed to you in private over IRC, below piece of code broke during booting EXYNOS4:SMDKV310 with ZONE_DMA enabled. Right, I missed the fact that ZONE_DMA can be enabled but the machine does not provide specific zone size. I will fix this in the next version. Thanks for pointing this bug! Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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]Support for Terratec G1
Hi,
This is a little patch to support Terratec G1 (based on Terratec Grabby).
It works perfectly on my pc (Ubuntu 11.04 / Kernel 2.6.38).
Best regards,
--- linux-source-2.6.38.org/drivers/media/video/em28xx/em28xx-cards.c 2011-03-15 02:20:32.0 +0100
+++ linux-source-2.6.38/drivers/media/video/em28xx/em28xx-cards.c 2011-09-12 19:53:23.992373291 +0200
@@ -1830,6 +1830,8 @@
.driver_info = EM2860_BOARD_TERRATEC_AV350 },
{ USB_DEVICE(0x0ccd, 0x0096),
.driver_info = EM2860_BOARD_TERRATEC_GRABBY },
+ { USB_DEVICE(0x0ccd, 0x10AF),
+ .driver_info = EM2860_BOARD_TERRATEC_GRABBY },
{ USB_DEVICE(0x0fd9, 0x0033),
.driver_info = EM2860_BOARD_ELGATO_VIDEO_CAPTURE},
{ USB_DEVICE(0x185b, 0x2870),
Re: [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
Hi Mr. Sumit Semwal, Thank you for taking care of the framework for buffer sharing. The support of buffer sharing in V4L2, both exporting and importing was posted in shrbuf proof-of-concept patch. It should be easy to port it to dmabuf. http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000485.html Please refer to the comments below: On 10/11/2011 11:23 AM, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using get_scatterlist and put_scatterlist operations. Atleast one 'attach()' call is required to be made prior to calling the get_scatterlist() operation. Couple of building blocks in get_scatterlist() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. mmap() file operation is provided for the associated 'fd', as wrapper over the optional allocator defined mmap(), to be used by devices that might need one. More details are there in the documentation patch. This is based on design suggestions from many people at the mini-summits[1], most notably from Arnd Bergmanna...@arndb.de, Rob Clarkr...@ti.com and Daniel Vetterdan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawskit.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Signed-off-by: Sumit Semwalsumit.sem...@linaro.org Signed-off-by: Sumit Semwalsumit.sem...@ti.com --- drivers/base/Kconfig| 10 ++ drivers/base/Makefile |1 + drivers/base/dma-buf.c | 242 +++ include/linux/dma-buf.h | 162 +++ 4 files changed, 415 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-buf.c create mode 100644 include/linux/dma-buf.h diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 21cf46f..07d8095 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -174,4 +174,14 @@ config SYS_HYPERVISOR source drivers/base/regmap/Kconfig +config DMA_SHARED_BUFFER + bool Buffer framework to be shared between drivers + default n + depends on ANON_INODES + help + This option enables the framework for buffer-sharing between + multiple drivers. A buffer is associated with a file using driver + APIs extension; the file's descriptor can then be passed on to other + driver. + endmenu diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 99a375a..d0df046 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS) += devtmpfs.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER) += firmware_class.o obj-$(CONFIG_NUMA)+= node.o diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c new file mode 100644 index 000..58c51a0 --- /dev/null +++ b/drivers/base/dma-buf.c @@ -0,0 +1,242 @@ +/* + * Framework for buffer objects that can be shared across devices/subsystems. + * + * Copyright(C) 2011 Linaro Limited. All rights reserved. + * Author: Sumit Semwalsumit.sem...@ti.com + * + * Many thanks to linaro-mm-sig list, and specially + * Arnd Bergmanna...@arndb.de, Rob Clarkr...@ti.com and + * Daniel Vetterdan...@ffwll.ch for their support in creation and + * refining of this idea. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not,
Re: freeze/crash
On Fri, 14 Oct 2011 01:51:37 +0200, James bjloc...@lockie.ca wrote: It always crashes when I access the hardware but the place it crashes is random. Maybe you would want to pass those crash logs for debugging purposes :) It's possible for developers to track from them where the crash occurs in driver. -- 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] dvb/as102 nBox DVB-T dongle
Hi,
There's licencing problem with as10x_cmd_cfg.c and as10x_cmd_stream.c
files which are not GPL ( (c) Copyright Abilis Systems SARL 2005-2009
All rigths reserved \n
www.abilis.com).
Dunno if it's only Davin's Heitmueller oversight in changing licencing
or a real problem.
What about it Davin ?
Peter
W dniu 14.10.2011 09:27, Hans Petter Selasky pisze:
Hi,
Could someone pull the AS102 driver into the media tree?
http://git.linuxtv.org/media_tree.git/tree/HEAD:/drivers/media/dvb
--HPS
On Wednesday 20 July 2011 22:29:41 Piotr Chmura wrote:
I just bought DVB-T USB dongle for one of polish digital platform. It
works fine with as102 driver.
Here is patch adding vendor and product ID to as102 driver taken from
http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102.
I tested it with kernel-3.0-rc7-git7 (had to change usb_buffer_alloc()
to usb_alloc_coherent and usb_buffer_free to usb_free_coherent() ).
patch:
diff -Nur linux/drivers/media/dvb/as102/as102_usb_drv.c
linux-mine/drivers/media/dvb/as102/as102_usb_drv.c
--- as102/as102_usb_drv.c2011-07-20 21:37:33.924143297 +0200
+++ /usr/src/linux/drivers/media/dvb/as102/as102_usb_drv.c2011-07-20
20:40:21.0 +0200
@@ -39,6 +39,7 @@
static struct usb_device_id as102_usb_id_table[] = {
{ USB_DEVICE(AS102_USB_DEVICE_VENDOR_ID, AS102_USB_DEVICE_PID_0001)
}, { USB_DEVICE(PCTV_74E_USB_VID, PCTV_74E_USB_PID) },
+{ USB_DEVICE(NBOX_USB_VID, NBOX_USB_PID) },
{ USB_DEVICE(ELGATO_EYETV_DTT_USB_VID, ELGATO_EYETV_DTT_USB_PID) },
{ } /* Terminating entry */
};
@@ -48,6 +49,7 @@
static const char *as102_device_names[] = {
AS102_REFERENCE_DESIGN,
AS102_PCTV_74E,
+AS102_NBOX,
AS102_ELGATO_EYETV_DTT_NAME,
NULL /* Terminating entry */
};
diff -Nur linux/drivers/media/dvb/as102/as102_usb_drv.h
linux-mine/drivers/media/dvb/as102/as102_usb_drv.h
--- as102/as102_usb_drv.h2011-07-20 21:37:33.925143297 +0200
+++ /usr/src/linux/drivers/media/dvb/as102/as102_usb_drv.h2011-07-20
20:39:46.0 +0200
@@ -36,6 +36,11 @@
#define PCTV_74E_USB_VID0x2013
#define PCTV_74E_USB_PID0x0246
+/* nBox DVB-T Stick */
+#define AS102_NBOXnBox DVB-T Stick
+#define NBOX_USB_VID0x0b89
+#define NBOX_USB_PID0x0007
+
/* Elgato: EyeTV DTT Deluxe */
#define AS102_ELGATO_EYETV_DTT_NAMEElgato EyeTV DTT Deluxe
#define ELGATO_EYETV_DTT_USB_VID0x0fd9
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb/as102 nBox DVB-T dongle
On Fri, Oct 14, 2011 at 8:36 AM, Piotr Chmura chmoor...@poczta.onet.pl wrote: Hi, There's licencing problem with as10x_cmd_cfg.c and as10x_cmd_stream.c files which are not GPL ( (c) Copyright Abilis Systems SARL 2005-2009 All rigths reserved \n www.abilis.com). Dunno if it's only Davin's Heitmueller oversight in changing licencing or a real problem. What about it Davin ? Yeah, those were an oversight on the part of Abilis. I already talked to them about it and got permission to fix the text. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
[PATCH] media: vb2: set buffer length correctly for all buffer types
v4l2_planes[plane].length field was not initialized for userptr buffers.
This patch fixes this issue.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index d8affb8..5656fdf 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -58,7 +58,6 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
/* Associate allocator private data with this plane */
vb-planes[plane].mem_priv = mem_priv;
- vb-v4l2_planes[plane].length = q-plane_sizes[plane];
}
return 0;
@@ -121,6 +120,7 @@ static void __setup_offsets(struct vb2_queue *q)
continue;
for (plane = 0; plane vb-num_planes; ++plane) {
+ vb-v4l2_planes[plane].length = q-plane_sizes[plane];
vb-v4l2_planes[plane].m.mem_offset = off;
dprintk(3, Buffer %d, plane %d offset 0x%08lx\n,
--
1.7.1.569.g6f426
--
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: PCTV 520e on Linux
Em 13-10-2011 20:19, Devin Heitmueller escreveu: On Thu, Oct 13, 2011 at 7:06 PM, Benjamin Larsson benja...@southpole.se wrote: On 10/13/2011 07:48 PM, Devin Heitmueller wrote: On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari cr...@iki.fi wrote: You were close: em2884, drx-k, xc5000, and for analog it uses the afv4910b. Then it should be peace of cake at least for digital side. I don't think we've ever done xc5000 on an em28xx before, so it's entirely possible that the xc5000 clock stretching will expose bugs in the em28xx i2c implementation (it uncovered bugs in essentially every other bridge driver I did work on). That, and we don't know how much is hard-coded into the drx-k driver making it specific to the couple of device it's currently being used with. But yeah, it shouldn't be rocket science. I added support for the board in my OSX driver and it only took me a couple of hours. Devin Eddi De Pieri has patches for the HVR-930C that works somewhat. The hardware in that stick is the same. MvH Benjamin Larsson While the basic chips used are different, they are completely different hardware designs and likely have different GPIO configurations as well as IF specs. The IF settings for xc5000 with DRX-K are solved with this patch: http://patchwork.linuxtv.org/patch/7932/ Basically, DRX-K will use whatever IF the tuner uses. I've sent to Eddi to get some feedback, but he never returned back. Devin -- 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: Support for Sveon STV22 (IT9137)
Em 09-10-2011 02:09, Leandro Terrés escreveu: This device identifies has IdProduct 0xe411 and is a clone of KWorld UB499-2T T09(IT9137). This patch simply adds support for this device. Patch applies ok, with just one small whitespace issue. However, you forgot to add your signed-off-by: on it. Also, it helps if you copy the driver's maintainer (Malcolm). Patchwork: http://patchwork.linuxtv.org/patch/8099/ WARNING: please, no space before tabs #24: FILE: drivers/media/dvb/dvb-usb/dvb-usb-ids.h:323: +#define USB_PID_SVEON_STV22_IT9137 ^I^I0xe411$ ERROR: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 29 lines checked -- 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: PCTV 520e on Linux
On Fri, Oct 14, 2011 at 9:19 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: While the basic chips used are different, they are completely different hardware designs and likely have different GPIO configurations as well as IF specs. The IF settings for xc5000 with DRX-K are solved with this patch: http://patchwork.linuxtv.org/patch/7932/ Basically, DRX-K will use whatever IF the tuner uses. While I fundamentally disagree with this change, I'm not going to nack it. That said, this wasn't the issue I was concerned with. My suggestion was simply that you cannot assume that all devices that happen to have a particular demod and tuner combo will always use the same IF configuration. The PCB layout can effect the optimal IF. This is one of those things that (like many tuners in the LinuxTV tree) will probably work good enough to get a signal lock for whoever added the board profile, but will result in poor tuning performance (and a failure to work in less-than-ideal reception conditions). All that said, if somebody actually intends to hack on it, I can look up what the correct IF is for the 520e. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
Re: PCTV 520e on Linux
Em 14-10-2011 10:28, Devin Heitmueller escreveu: On Fri, Oct 14, 2011 at 9:19 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: While the basic chips used are different, they are completely different hardware designs and likely have different GPIO configurations as well as IF specs. The IF settings for xc5000 with DRX-K are solved with this patch: http://patchwork.linuxtv.org/patch/7932/ Basically, DRX-K will use whatever IF the tuner uses. While I fundamentally disagree with this change, I'm not going to nack it. That said, this wasn't the issue I was concerned with. My suggestion was simply that you cannot assume that all devices that happen to have a particular demod and tuner combo will always use the same IF configuration. The PCB layout can effect the optimal IF. This is one of those things that (like many tuners in the LinuxTV tree) will probably work good enough to get a signal lock for whoever added the board profile, but will result in poor tuning performance (and a failure to work in less-than-ideal reception conditions). This patch doesn't prevent customizing the IF. It will just avoid the need of setting the IF on both xc5000 and drx-k. Basically, (some) DRX-K based boards use different IF's depending on the bandwidth and delivery system type. Instead of adding a complex logic that would allow such kind of IF adjustments on both, drx-k will simply inquire the tuner about what IF is currently used. All that said, if somebody actually intends to hack on it, I can look up what the correct IF is for the 520e. Devin -- 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: PCTV 520e on Linux
On Fri, Oct 14, 2011 at 10:01 AM, Sönke Brandt sbra...@pctvsystems.com wrote: Just a quick note: The 520e does use the TDA18271 tuner, not an XC5000. Soenke. Wow, how the hell did I screw that up? Of course Sönke is correct. I momentarily got the 520e confused with the HVR-930c (I've done work on both in the past). Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
bttv-gpio.c
Hi, I'm trying to understand how to control GPIOs on a bt878 card, as described in this earlier post: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/39342 I came across the file bttv-gpio.c in drivers/media/video/bt8xx, and the starting comment seems what I'm looking for: sysfs-based sub driver interface for bttv mainly intented for gpio access But I cannot understand how to enable this sysfs based access. Is there a kernel configuration somewhere? Where the gpios are supposed to show up in /sys? Thank you in advance for your help and excuse me if my question is trivial. -- Augusto Destrero, PhD -- 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 1/2] dma-buf: Introduce dma buffer sharing mechanism
On 14 October 2011 15:30, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
Hi Mr. Sumit Semwal,
Hello Mr. Tomasz Stanislawski :),
Thank you for taking care of the framework for buffer sharing.
The support of buffer sharing in V4L2, both exporting and importing was
posted in shrbuf proof-of-concept patch. It should be easy to port it to
dmabuf.
http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000485.html
I should thank you for the wonderful proof-of-concept patch, and the
idea behind it! I am currently working on the V4L2 side patch for it,
and would send out the RFC soon.
Also, thanks for a good review and some pertinent points; replies inline.
Please refer to the comments below:
On 10/11/2011 11:23 AM, Sumit Semwal wrote:
snip
+/**
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * with this buffer,so it can be exported.
+ * Also connect the allocator specific data and ops to the buffer.
+ *
+ * @priv: [in] Attach private data of allocator to this buffer
+ * @ops: [in] Attach allocator-defined dma buf ops to the new
buffer.
+ * @flags: [in] mode flags for the file.
What is the purpose of these flags? The file is not visible to any process
by any file system, is it?
These are the standard file mode flags, which can be used to do
file-level access-type control by the exporter, so for example
write-access can be denied for a buffer exported as a read-only
buffer.
+ *
+ * Returns, on success, a newly created dma_buf object, which wraps the
+ * supplied private data and operations for dma_buf_ops. On failure to
+ * allocate the dma_buf object, it can return NULL.
+ *
+ */
+struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
+ int flags)
+{
+ struct dma_buf *dmabuf;
+ struct file *file;
+
why priv is not allowed to be NULL?
priv will be used by the exporter to attach its own context to the dma
buf; I couldn't think of any case where it could be NULL?
+ BUG_ON(!priv || !ops);
+
snip
+ BUG_ON(!dmabuf-file);
+
+ fput(dmabuf-file);
+
return is not needed
Right; will correct this.
+ return;
+}
+EXPORT_SYMBOL(dma_buf_put);
+
+/**
+ * dma_buf_attach - Add the device to dma_buf's attachments list;
optionally,
+ * calls attach() of dma_buf_ops to allow device-specific attach
functionality
+ * @dmabuf: [in] buffer to attach device to.
+ * @dev: [in] device to be attached.
+ *
+ * Returns struct dma_buf_attachment * for this attachment; may return
NULL.
+ *
+ */
+struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+ struct device *dev)
+{
+ struct dma_buf_attachment *attach;
+ int ret;
+
+ BUG_ON(!dmabuf || !dev);
+
+ mutex_lock(dmabuf-lock);
+
There is no need to call kzalloc inside critical section protected by
dmabuf-lock. The code would be simpler if the allocation is moved outside
the section.
Yes, you're right; will correct it.
+ attach = kzalloc(sizeof(struct dma_buf_attachment), GFP_KERNEL);
+ if (attach == NULL)
+ goto err_alloc;
+
+ attach-dev = dev;
+ if (dmabuf-ops-attach) {
+ ret = dmabuf-ops-attach(dmabuf, dev, attach);
+ if (!ret)
+ goto err_attach;
+ }
+ list_add(attach-node,dmabuf-attachments);
+
+err_alloc:
+ mutex_unlock(dmabuf-lock);
+ return attach;
+err_attach:
+ kfree(attach);
+ mutex_unlock(dmabuf-lock);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(dma_buf_attach);
+
+/**
+ * dma_buf_detach - Remove the given attachment from dmabuf's attachments
list;
+ * optionally calls detach() of dma_buf_ops for device-specific detach
+ * @dmabuf: [in] buffer to detach from.
+ * @attach: [in] attachment to be detached; is free'd after this
call.
+ *
+ */
+void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment
*attach)
+{
+ BUG_ON(!dmabuf || !attach);
+
+ mutex_lock(dmabuf-lock);
+ list_del(attach-node);
+ if (dmabuf-ops-detach)
+ dmabuf-ops-detach(dmabuf, attach);
+
[as above]
Ok.
+ kfree(attach);
+ mutex_unlock(dmabuf-lock);
+ return;
+}
+EXPORT_SYMBOL(dma_buf_detach);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
new file mode 100644
index 000..5bdf16a
--- /dev/null
+++ b/include/linux/dma-buf.h
@@ -0,0 +1,162 @@
+/*
+ * Header file for dma buffer sharing framework.
+ *
+ * Copyright(C) 2011 Linaro Limited. All rights reserved.
+ * Author: Sumit Semwalsumit.sem...@ti.com
+ *
+ * Many thanks to linaro-mm-sig list, and specially
+ * Arnd Bergmanna...@arndb.de, Rob Clarkr...@ti.com and
+ * Daniel Vetterdan...@ffwll.ch for their support in creation and
+ * refining of this idea.
+ *
+ * This program
Re: [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote: +/** + * struct dma_buf_ops - operations possible on struct dma_buf + * @create: creates a struct dma_buf of a fixed size. Actual allocation + * does not happen here. The 'create' ops is not present in dma_buf_ops. + * @attach: allows different devices to 'attach' themselves to the given + * buffer. It might return -EBUSY to signal that backing storage + * is already allocated and incompatible with the requirements + * of requesting device. [optional] + * @detach: detach a given device from this buffer. [optional] + * @get_scatterlist: returns list of scatter pages allocated, increases + * usecount of the buffer. Requires atleast one attach to be + * called before. Returned sg list should already be mapped + * into _device_ address space. You must add a comment that this call 'may sleep'. I like the get_scatterlist idea. It allows the exported to create a valid scatterlist for a client in a elegant way. I do not like this whole attachment idea. The problem is that currently there is no support in DMA framework for allocation for multiple devices. As long as no such a support exists, there is no generic way to handle attribute negotiations and buffer allocations that involve multiple devices. So the exporter drivers would have to implement more or less hacky solutions to handle memory requirements and choosing the device that allocated memory. Currently, AFAIK there is even no generic way for a driver to acquire its own DMA memory requirements. Therefore all logic hidden beneath 'attachment' is pointless. I think that support for attach/detach (and related stuff) should be postponed until support for multi-device allocation is added to DMA framework. Imo we clearly need this to make the multi-device-driver with insane dma requirements work on arm. And rewriting the buffer handling in participating subsystem twice isn't really a great plan. I envision that on platforms where we need this madness, the driver must call back to the dma subsytem to create a dma_buf. The dma subsytem should be already aware of all the requirements and hence should be able to handle them.. I don't say the attachment list idea is wrong but adding attachment stuff creates an illusion that problem of multi-device allocations is somehow magically solved. We should not force the developers of exporter drivers to solve the problem that is not solvable yet. Well, this is why we need to create a decent support infrastructure for platforms (= arm madness) that needs this, so that device drivers and subsystem don't need to invent that wheel on their own. Which as you point out, they actually can't. The other problem are the APIs. For example, the V4L2 subsystem assumes that memory is allocated after successful VIDIOC_REQBUFS with V4L2_MEMORY_MMAP memory type. Therefore attach would be automatically followed by get_scatterlist, blocking possibility of any buffer migrations in future. Well, pardon to break the news, but v4l needs to rework the buffer handling. If you want to share buffers with a gpu driver, you _have_ to life with the fact that gpus do fully dynamic buffer management, meaning: - buffers get allocated and destroyed on the fly, meaning static reqbuf just went out the window (we obviously cache buffer objects and reuse them for performance, as long as the processing pipeline doesn't really change). - buffers get moved around in memory, meaning you either need full-blown sync-objects with a callback to drivers to tear-down mappings on-demand, or every driver needs to guarnatee to call put_scatterlist in a reasonable short time. The latter is probably the more natural thing for v4l devices. The same situation happens if buffer sharing is added to framebuffer API. You can fix that by using the gem/ttm infrastructure of drm (or whatever the blob gpu drivers are using). Which is why I think fb should just die, please. The buffer sharing mechanism is dedicated to improve cooperation between multiple APIs. Therefore the common denominator strategy should be applied that is buffer-creation == buffer-allocation. No. Really, there's just no way gpu's will be moving back to static buffer management. And I know, for many use-cases we could get away with a bunch of static buffers (e.g. a video processing pipe). But in drm-land even scanout-buffers can get moved around - currently only when they're not being used, but strictly speaking nothing prevents us from copying the scanout to a new location and issueing a pageflip and so even move the buffer around even when it's in use. But let's look quickly at an OpenCL usecase, moving Gb's of date per second around between the cpu and a bunch of add-on gpus (or other special purpose processing units). We'd also need to extend dma_buf with sync objects to make this work well, but there's
Re: [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Oct 14, 2011 at 5:00 AM, Tomasz Stanislawski
t.stanisl...@samsung.com wrote:
+ * @attach: allows different devices to 'attach' themselves to the given
+ * buffer. It might return -EBUSY to signal that backing storage
+ * is already allocated and incompatible with the requirements
+ * of requesting device. [optional]
+ * @detach: detach a given device from this buffer. [optional]
+ * @get_scatterlist: returns list of scatter pages allocated, increases
+ * usecount of the buffer. Requires atleast one attach
to be
+ * called before. Returned sg list should already be
mapped
+ * into _device_ address space.
You must add a comment that this call 'may sleep'.
I like the get_scatterlist idea. It allows the exported to create a valid
scatterlist for a client in a elegant way.
I do not like this whole attachment idea. The problem is that currently
there is no support in DMA framework for allocation for multiple devices. As
long as no such a support exists, there is no generic way to handle
attribute negotiations and buffer allocations that involve multiple devices.
So the exporter drivers would have to implement more or less hacky solutions
to handle memory requirements and choosing the device that allocated memory.
Currently, AFAIK there is even no generic way for a driver to acquire its
own DMA memory requirements.
dev-dma_params (struct device_dma_parameters).. for example
it would need to be expanded a bit to have a way to say it needs to
be physically contiguous..
Therefore all logic hidden beneath 'attachment' is pointless. I think that
support for attach/detach (and related stuff) should be postponed until
support for multi-device allocation is added to DMA framework.
I don't say the attachment list idea is wrong but adding attachment stuff
creates an illusion that problem of multi-device allocations is somehow
magically solved. We should not force the developers of exporter drivers to
solve the problem that is not solvable yet.
The other problem are the APIs. For example, the V4L2 subsystem assumes that
memory is allocated after successful VIDIOC_REQBUFS with V4L2_MEMORY_MMAP
memory type. Therefore attach would be automatically followed by
get_scatterlist, blocking possibility of any buffer migrations in future.
But this problem really only applies if v4l is your buffer allocator.
I don't think a v4l limitation is a valid argument to remove the
attachment stuff.
The same situation happens if buffer sharing is added to framebuffer API.
The buffer sharing mechanism is dedicated to improve cooperation between
multiple APIs. Therefore the common denominator strategy should be applied
that is buffer-creation == buffer-allocation.
I think it would be sufficient if buffer creators that cannot defer
the allocation just take a worst-case approach and allocate physically
contiguous buffers. No need to penalize other potential buffer
allocators. This allows buffer creators with more flexibility the
option for deferring the allocation until it knows whether the buffer
really needs to be contiguous.
+ * @put_scatterlist: decreases usecount of buffer, might deallocate
scatter
+ * pages.
+ * @mmap: memory map this buffer - optional.
+ * @release: release this buffer; to be called after the last
dma_buf_put.
+ * @sync_sg_for_cpu: sync the sg list for cpu.
+ * @sync_sg_for_device: synch the sg list for device.
+ */
+struct dma_buf_ops {
+ int (*attach)(struct dma_buf *, struct device *,
+ struct dma_buf_attachment *);
+
+ void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
+
+ /* For {get,put}_scatterlist below, any specific buffer attributes
+ * required should get added to device_dma_parameters accessible
+ * via dev-dma_params.
+ */
+ struct scatterlist * (*get_scatterlist)(struct dma_buf_attachment
*,
+ enum dma_data_direction,
+ int *nents);
+ void (*put_scatterlist)(struct dma_buf_attachment *,
+ struct scatterlist *,
+ int nents);
+ /* TODO: Add interruptible and interruptible_timeout versions */
I don't agree the interruptible and interruptible_timeout versions are
needed. I think that get_scatterlist should alway be interruptible. You can
add try_get_scatterlist callback that returns ERR_PTR(-EBUSY) if the call
would be blocking.
+
+ /* allow mmap optionally for devices that need it */
+ int (*mmap)(struct dma_buf *, struct vm_area_struct *);
The mmap is not needed for inital version. It could be added at any time in
the future. The dmabuf client should not be allowed to create mapping of the
dmabuf from the scatterlist.
fwiw, this wasn't
[media-ctl PATCH 1/1] Several printout fixes.
- There are sink and source pads, not input and output.
- Print also DYNAMIC flag.
- Don't print pad before pad number in some cases. The strings are more
usable for link parsing now.
- Don't print extra commas afterlink flags.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
src/main.c | 29 +
1 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/main.c b/src/main.c
index c04e12f..3c5fcb8 100644
--- a/src/main.c
+++ b/src/main.c
@@ -129,8 +129,8 @@ static const char *media_pad_type_to_string(unsigned flag)
__u32 flag;
const char *name;
} flags[] = {
- { MEDIA_PAD_FL_SINK, Input },
- { MEDIA_PAD_FL_SOURCE, Output },
+ { MEDIA_PAD_FL_SINK, Sink },
+ { MEDIA_PAD_FL_SOURCE, Source },
};
unsigned int i;
@@ -251,20 +251,33 @@ static void media_print_topology_text(struct media_device
*media)
struct media_link *link = entity-links[k];
struct media_pad *source = link-source;
struct media_pad *sink = link-sink;
+ int i, flags = link-flags;
+ struct {
+ int flag;
+ char *str;
+ } tbl[] = {
+ { MEDIA_LNK_FL_ENABLED, ENABLED },
+ { MEDIA_LNK_FL_IMMUTABLE, IMMUTABLE },
+ { MEDIA_LNK_FL_DYNAMIC, DYNAMIC },
+ };
if (source-entity == entity source-index
== j)
- printf(\t\t- '%s':pad%u [,
+ printf(\t\t- \%s\:%u [,
sink-entity-info.name,
sink-index);
else if (sink-entity == entity sink-index
== j)
- printf(\t\t- '%s':pad%u [,
+ printf(\t\t- \%s\:%u [,
source-entity-info.name,
source-index);
else
continue;
- if (link-flags MEDIA_LNK_FL_IMMUTABLE)
- printf(IMMUTABLE,);
- if (link-flags MEDIA_LNK_FL_ENABLED)
- printf(ACTIVE);
+ for (i = 0; i ARRAY_SIZE(tbl); i++) {
+ if (!(flags tbl[i].flag))
+ continue;
+ if (link-flags != flags)
+ printf(,);
+ printf(%s, tbl[i].str);
+ flags = ~tbl[i].flag;
+ }
printf(]\n);
}
--
1.7.2.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: PCTV 520e on Linux
Em 14-10-2011 11:04, Devin Heitmueller escreveu: On Fri, Oct 14, 2011 at 10:01 AM, Sönke Brandt sbra...@pctvsystems.com wrote: Just a quick note: The 520e does use the TDA18271 tuner, not an XC5000. The tda18271-dd/drx-k/em28xx combination works fine, provided that the GPIO initialization enables both tuner and demod during probe time. Currently, the device I used to add support for it (a Terratec H5) has a hack to enable the devices: it just replies whatever initialization the original driver does. When I have some time, I'll fix that, but I'm not urging doing so, because it just works ;) In order to add support for PCTV 520e, it is probably a matter of just set the GPIO's. Soenke. Wow, how the hell did I screw that up? Of course Sönke is correct. I momentarily got the 520e confused with the HVR-930c (I've done work on both in the past). Regards, Devin -- 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
help
-- 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
help
help -- 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: PCTV 520e on Linux
On Fri, Oct 14, 2011 at 12:14 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The tda18271-dd/drx-k/em28xx combination works fine, provided that the GPIO initialization enables both tuner and demod during probe time. Currently, the device I used to add support for it (a Terratec H5) has a hack to enable the devices: it just replies whatever initialization the original driver does. When I have some time, I'll fix that, but I'm not urging doing so, because it just works ;) In order to add support for PCTV 520e, it is probably a matter of just set the GPIO's. Complements of our friends at PCTV: 520e: GPIO02: Decoder Reset, active-low GPIO04: Decoder Suspend, active-low GPIO06: Demod Reset, active-low GPIO07: LED on, active-high Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
Re: Support for Sveon STV22 (IT9137)
2011/10/14 Mauro Carvalho Chehab mche...@redhat.com: Em 09-10-2011 02:09, Leandro Terrés escreveu: This device identifies has IdProduct 0xe411 and is a clone of KWorld UB499-2T T09(IT9137). This patch simply adds support for this device. Patch applies ok, with just one small whitespace issue. However, you forgot to add your signed-off-by: on it. Also, it helps if you copy the driver's maintainer (Malcolm). Patchwork: http://patchwork.linuxtv.org/patch/8099/ WARNING: please, no space before tabs #24: FILE: drivers/media/dvb/dvb-usb/dvb-usb-ids.h:323: +#define USB_PID_SVEON_STV22_IT9137 ^I^I0xe411$ ERROR: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 29 lines checked This is my first contribution and I don't know who to do that. Sorry. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] v4l: add support for selection api
On Wed, Oct 12, 2011 at 05:08:20PM +0200, Tomasz Stanislawski wrote:
On 10/12/2011 01:48 PM, Sakari Ailus wrote:
Hi Tomasz,
On Wed, Aug 31, 2011 at 02:28:20PM +0200, Tomasz Stanislawski wrote:
...
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..b7471fe 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,48 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE 0x0001
+#define V4L2_SEL_SIZE_LE 0x0002
A minor comment. If the patches have not been pulled yet, how about adding
FLAG_ to the flag names? I.e. V4L2_SEL_FLAG_SIZE_GE and
V4L2_SEL_FLAG_SIZE_LE.
Hi Sakari,
The idea is good. I preferred to avoid using long names if possible.
I agree that using _FLAGS_ produce more informative name.
I'll fix it in the new version of selection API.
Hi Tomasz,
I'd also have the same comment on the selection targets.
V4L2_SEL_TGT_CROP_ACTIVE, for example?
What do you think?
--
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
Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
Am Mittwoch, 5. Oktober 2011, 10:16:06 schrieb Oliver Neukum:
Am Mittwoch, 5. Oktober 2011, 08:19:10 schrieb Antti Palosaari:
On 10/05/2011 09:15 AM, Oliver Neukum wrote:
But, Greg, Antti makes a very valid point here. The generic code assumes
that
it owns intfdata, that is you cannot use it as is for access to anything
that lacks
its own interface. But this is not a fatal flaw. We can alter the generic
code to use
an accessor function the driver can provide and make it default to
get/set_intfdata
What do you think?
Oliver, I looked your old thread reply but I didn't catch how you meant
it to happen. Could you give some small example?
Hi,
here is the code I come up with at an early, extremely incomplete stage.
Just for your information because I'll stop working on this for a few days.
Regards
Oliver
diff --git a/drivers/media/dvb/dvb-usb/anysee.c
b/drivers/media/dvb/dvb-usb/anysee.c
index 2cbf19a..34c950a 100644
--- a/drivers/media/dvb/dvb-usb/anysee.c
+++ b/drivers/media/dvb/dvb-usb/anysee.c
@@ -31,6 +31,12 @@
* is highly welcome!
*/
+#include linux/kernel.h
+#include linux/tty_driver.h
+#include linux/tty.h
+#include linux/serial.h
+#include linux/usb.h
+#include linux/usb/serial.h
#include anysee.h
#include tda1002x.h
#include mt352.h
@@ -898,6 +904,8 @@ static int anysee_probe(struct usb_interface *intf,
if (ret)
return ret;
+ usb_serial_start(d-card_dev, intf);
+
return anysee_init(d);
}
@@ -973,6 +981,10 @@ static int __init anysee_module_init(void)
if (ret)
err(%s: usb_register failed. Error number %d, __func__, ret);
+ ret = usb_serial_register(anysee_card_driver);
+ if (ret)
+ usb_deregister(anysee_driver);
+
return ret;
}
diff --git a/drivers/media/dvb/dvb-usb/anysee.h
b/drivers/media/dvb/dvb-usb/anysee.h
index ad6ccd1..f1ca088 100644
--- a/drivers/media/dvb/dvb-usb/anysee.h
+++ b/drivers/media/dvb/dvb-usb/anysee.h
@@ -61,6 +61,9 @@ struct anysee_state {
u8 seq;
};
+static struct usb_serial_driver anysee_card_driver = {
+};
+
#define ANYSEE_HW_507T2 /* E30 */
#define ANYSEE_HW_507CD 6 /* E30 Plus */
#define ANYSEE_HW_507DC 10 /* E30 C Plus */
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb.h
b/drivers/media/dvb/dvb-usb/dvb-usb.h
index 7d35d07..5333c4d 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb.h
@@ -425,6 +425,7 @@ struct dvb_usb_device {
/* remote control */
struct rc_dev *rc_dev;
struct input_dev *input_dev;
+ struct usb_serial *card_dev;
char rc_phys[64];
struct delayed_work rc_query_work;
u32 last_event;
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index e4db5ad..4c387ab 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -175,6 +175,12 @@ int usb_serial_generic_prepare_write_buffer(struct
usb_serial_port *port,
return kfifo_out_locked(port-write_fifo, dest, size, port-lock);
}
+void usb_serial_generic_set_private_data(struct usb_interface *intf, struct
usb_serial *serial)
+{
+ usb_set_intfdata(intf, serial);
+}
+EXPORT_SYMBOL_GPL(usb_serial_generic_set_private_data);
+
/**
* usb_serial_generic_write_start - kick off an URB write
* @port: Pointer to the struct usb_serial_port data
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 1c03130..dd8cf75 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -707,19 +707,18 @@ static const struct tty_port_operations serial_port_ops =
{
.shutdown = serial_down,
};
-int usb_serial_probe(struct usb_interface *interface,
- const struct usb_device_id *id)
+int usb_serial_start(struct usb_serial *serial, struct usb_interface
*interface)
{
struct usb_device *dev = interface_to_usbdev(interface);
- struct usb_serial *serial = NULL;
- struct usb_serial_port *port;
+ struct usb_serial_driver *type = NULL;
struct usb_host_interface *iface_desc;
struct usb_endpoint_descriptor *endpoint;
struct usb_endpoint_descriptor *interrupt_in_endpoint[MAX_NUM_PORTS];
struct usb_endpoint_descriptor *interrupt_out_endpoint[MAX_NUM_PORTS];
struct usb_endpoint_descriptor *bulk_in_endpoint[MAX_NUM_PORTS];
struct usb_endpoint_descriptor *bulk_out_endpoint[MAX_NUM_PORTS];
- struct usb_serial_driver *type = NULL;
+ struct usb_serial_port *port;
+
int retval;
unsigned int minor;
int buffer_size;
@@ -731,28 +730,6 @@ int usb_serial_probe(struct usb_interface *interface,
int num_ports = 0;
int max_endpoints;
- mutex_lock(table_lock);
- type = search_serial_device(interface);
- if (!type) {
- mutex_unlock(table_lock);
-
Re: PCTV 520e on Linux
Em 14-10-2011 13:41, Devin Heitmueller escreveu: On Fri, Oct 14, 2011 at 12:14 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The tda18271-dd/drx-k/em28xx combination works fine, provided that the GPIO initialization enables both tuner and demod during probe time. Currently, the device I used to add support for it (a Terratec H5) has a hack to enable the devices: it just replies whatever initialization the original driver does. When I have some time, I'll fix that, but I'm not urging doing so, because it just works ;) In order to add support for PCTV 520e, it is probably a matter of just set the GPIO's. Complements of our friends at PCTV: 520e: GPIO02: Decoder Reset, active-low GPIO04: Decoder Suspend, active-low GPIO06: Demod Reset, active-low GPIO07: LED on, active-high What are the USB ID's for the device? I may try to do a patch for it during this weekend, if I found time to add support for a few other devices that Terratec gently donated me. Thanks! Mauro Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Oct 14 19:01:37 CEST 2011 git hash:e30528854797f057aa6ffb6dc9f890e923c467fd gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS 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-rc1-i686: 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-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The 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
Re: PCTV 520e on Linux
On Fri, Oct 14, 2011 at 1:39 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: What are the USB ID's for the device? I may try to do a patch for it during this weekend, if I found time to add support for a few other devices that Terratec gently donated me. 510e 2304:0242 520e 2013:0251, 2013:0252 Of course, you shouldn't just blindly check anything in. That said, seems there are people on this list who have at least some of these variants. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
Re: freeze/crash
On 10/14/11 07:10, semiRocket wrote: On Fri, 14 Oct 2011 01:51:37 +0200, James bjloc...@lockie.ca wrote: It always crashes when I access the hardware but the place it crashes is random. Maybe you would want to pass those crash logs for debugging purposes :) What crash logs? The kernel locks up, is there a log somewhere? It's possible for developers to track from them where the crash occurs in driver. It occurred to me to try the mythbuntu livedvd. :-) That didn't work so I tried my other PCIe slot (I had to disconnect stuff to make it fit :-() and it works now. -- 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: [GIT PATCHES FOR 3.2] cx23885 alsa cleaned and prepaired
Em 10-10-2011 11:52, Igor M. Liplianin escreveu: Hi Mauro and Steven, It's been a long time since cx23885-alsa pull was requested. To speed things up I created a git branch where I put the patches. Some patches merged, like introduce then correct checkpatch compliance or convert spinlock to mutex and back to spinlock, insert printk then remove printk as well. Minor corrections from me was silently merged, for major I created additional patches. Hope it helps. This patchset breaks git bisect. I tried to change the order of the initial patches, but I couldn't an order of applying therm without breaking compilation. The solution is to merge the first 6 patches into one. Igor, Steven, Could you both ack with this, please? Thanks! Mauro. From 9e44d63246a9c884900e56e2aa16fba94dee5f0c Mon Sep 17 00:00:00 2001 From: Mijhail Moreyra mijhail.more...@gmail.com Date: Mon, 10 Oct 2011 11:09:52 -0300 Subject: [PATCH] [media] cx23885: Add ALSA support [st...@kernellabs.com: add it to the makefile and fix snd_card binding] [liplia...@netup.ru: videobuf: Remove the videobuf_sg_dma_map/unmap functions] Signed-off-by: Mijhail Moreyra mijhail.more...@gmail.com Signed-off-by: Steven Toth st...@kernellabs.com Signed-off-by: Igor M. Liplianin liplia...@netup.ru Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/cx23885/Makefile b/drivers/media/video/cx23885/Makefile index 185cc01..f81f279 100644 --- a/drivers/media/video/cx23885/Makefile +++ b/drivers/media/video/cx23885/Makefile @@ -2,7 +2,7 @@ cx23885-objs:= cx23885-cards.o cx23885-video.o cx23885-vbi.o \ cx23885-core.o cx23885-i2c.o cx23885-dvb.o cx23885-417.o \ cx23885-ioctl.o cx23885-ir.o cx23885-av.o cx23885-input.o \ cx23888-ir.o netup-init.o cimax2.o netup-eeprom.o \ - cx23885-f300.o + cx23885-f300.o cx23885-alsa.o obj-$(CONFIG_VIDEO_CX23885) += cx23885.o obj-$(CONFIG_MEDIA_ALTERA_CI) += altera-ci.o diff --git a/drivers/media/video/cx23885/cx23885-alsa.c b/drivers/media/video/cx23885/cx23885-alsa.c new file mode 100644 index 000..31a89b3 --- /dev/null +++ b/drivers/media/video/cx23885/cx23885-alsa.c @@ -0,0 +1,535 @@ +/* + * + * Support for CX23885 analog audio capture + * + *(c) 2008 Mijhail Moreyra mijhail.more...@gmail.com + *Adapted from cx88-alsa.c + *(c) 2009 Steven Toth st...@kernellabs.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include linux/module.h +#include linux/init.h +#include linux/device.h +#include linux/interrupt.h +#include linux/vmalloc.h +#include linux/dma-mapping.h +#include linux/pci.h + +#include asm/delay.h + +#include sound/core.h +#include sound/pcm.h +#include sound/pcm_params.h +#include sound/control.h +#include sound/initval.h + +#include sound/tlv.h + + +#include cx23885.h +#include cx23885-reg.h + +#define AUDIO_SRAM_CHANNEL SRAM_CH07 + +#define dprintk(level, fmt, arg...)if (audio_debug = level) \ + printk(KERN_INFO %s/1: fmt, chip-dev-name , ## arg) + +#define dprintk_core(level, fmt, arg...) if (audio_debug = level) \ + printk(KERN_DEBUG %s/1: fmt, chip-dev-name , ## arg) + +/ + Module global static vars + / + +static unsigned int disable_analog_audio; +module_param(disable_analog_audio, int, 0644); +MODULE_PARM_DESC(disable_analog_audio, disable analog audio ALSA driver); + +static unsigned int audio_debug; +module_param(audio_debug, int, 0644); +MODULE_PARM_DESC(audio_debug, enable debug messages [analog audio]); + +/ + Board specific funtions + / + +/* Constants taken from cx88-reg.h */ +#define AUD_INT_DN_RISCI1 (1 0) +#define AUD_INT_UP_RISCI1 (1 1) +#define AUD_INT_RDS_DN_RISCI1 (1 2) +#define AUD_INT_DN_RISCI2 (1 4) /* yes, 3 is skipped */ +#define AUD_INT_UP_RISCI2 (1 5) +#define AUD_INT_RDS_DN_RISCI2 (1 6) +#define AUD_INT_DN_SYNC (1 12)
Re: [GIT PATCHES FOR 3.2] cx23885 alsa cleaned and prepaired
Em 10-10-2011 11:52, Igor M. Liplianin escreveu:
Hi Mauro and Steven,
It's been a long time since cx23885-alsa pull was requested.
To speed things up I created a git branch where I put the patches.
Some patches merged, like introduce then correct checkpatch compliance
or convert spinlock to mutex and back to spinlock, insert printk then remove
printk as well.
Minor corrections from me was silently merged, for major I created additional
patches.
Hope it helps.
The following changes since commit e30528854797f057aa6ffb6dc9f890e923c467fd:
[media] it913x-fe changes to power up and down of tuner (2011-10-08
08:03:27 -0300)
are available in the git repository at:
git://linuxtv.org/liplianin/media_tree.git cx23885-alsa-clean-2
Igor M. Liplianin (2):
cx23885: videobuf: Remove the videobuf_sg_dma_map/unmap functions
cx25840-audio: fix missing state declaration
Mijhail Moreyra (6):
cx23885: merge mijhail's header changes for alsa
cx23885: ALSA support
cx23885: core changes requireed for ALSA
cx23885: add definitions for HVR1500 to support audio
cx23885: correct the contrast, saturation and hue controls
cx23885: hooks the alsa changes into the video subsystem
patches/0009-cx23885-hooks-the-alsa-changes-into-the-video-subsys.patch
From ee1eadb6f02f9c1b6d14e049874ad883d752ea7e Mon Sep 17 00:00:00 2001
From: Mijhail Moreyra mijhail.more...@gmail.com
Date: Mon, 10 Oct 2011 17:09:53 +0300
Subject: cx23885: hooks the alsa changes into the video subsystem
Cc: Linux Media Mailing List linux-media@vger.kernel.org
Priority: normal
Signed-off-by: Mijhail Moreyra mijhail.more...@gmail.com
Signed-off-by: Steven Toth st...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/cx23885/cx23885-video.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 0c463f9..acd6e0c 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -37,6 +37,8 @@
#include cx23885-ioctl.h
#include tuner-xc2028.h
+#include media/cx25840.h
+
MODULE_DESCRIPTION(v4l2 driver module for cx23885 based TV cards);
MODULE_AUTHOR(Steven Toth st...@linuxtv.org);
MODULE_LICENSE(GPL);
@@ -884,8 +886,9 @@ static int cx23885_get_control(struct cx23885_dev *dev,
static int cx23885_set_control(struct cx23885_dev *dev,
struct v4l2_control *ctl)
{
- dprintk(1, %s() calling cx25840(VIDIOC_S_CTRL)
- (disabled - no action)\n, __func__);
+ dprintk(1, %s() calling cx25840(VIDIOC_S_CTRL)\n, __func__);
+ call_all(dev, core, s_ctrl, ctl);
+
return 0;
}
@@ -1220,11 +1223,9 @@ static int vidioc_g_tuner(struct file *file, void
*priv,
if (0 != t-index)
return -EINVAL;
+ memset(t, 0, sizeof(*t));
No. The V4L2 core already cleans the parameters that are meant to be
returned to userspace.
In particular, this will break part of the tuner logic, as now the V4L2 core
fills t-type, and tuner-core relies on that.
If the rest of the patches are ok, I'll add a patch on the series removing this.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.2] cx23885 alsa cleaned and prepaired
Em 10-10-2011 11:52, Igor M. Liplianin escreveu:
Hi Mauro and Steven,
It's been a long time since cx23885-alsa pull was requested.
To speed things up I created a git branch where I put the patches.
Some patches merged, like introduce then correct checkpatch compliance
or convert spinlock to mutex and back to spinlock, insert printk then remove
printk as well.
Minor corrections from me was silently merged, for major I created additional
patches.
Hope it helps.
Steven Toth (31):
cx23885: mute the audio during channel change
From 3241f9a7ba2505c48eaa608df7f2bd2a3e79eea0 Mon Sep 17 00:00:00 2001
From: Steven Toth st...@kernellabs.com
Date: Mon, 10 Oct 2011 11:09:53 -0300
Subject: [PATCH] [media] cx23885: mute the audio during channel change
Signed-off-by: Steven Toth st...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 58855b2..7e5342b 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -1264,18 +1264,30 @@ static int vidioc_g_frequency(struct file *file, void
*priv,
static int cx23885_set_freq(struct cx23885_dev *dev, struct v4l2_frequency
*f)
{
+ struct v4l2_control ctrl;
+
if (unlikely(UNSET == dev-tuner_type))
return -EINVAL;
if (unlikely(f-tuner != 0))
return -EINVAL;
+
mutex_lock(dev-lock);
dev-freq = f-frequency;
+ /* I need to mute audio here */
+ ctrl.id = V4L2_CID_AUDIO_MUTE;
+ ctrl.value = 1;
+ cx23885_set_control(dev, ctrl);
+
call_all(dev, tuner, s_frequency, f);
/* When changing channels it is required to reset TVAUDIO */
- msleep(10);
+ msleep(100);
+
+ /* I need to unmute audio here */
+ ctrl.value = 0;
+ cx23885_set_control(dev, ctrl);
mutex_unlock(dev-lock);
This patch has a weird side effect: If the user has muted the audio, changing
the channel will
unmute. The right thing to do here is to do a g_ctrl to check if the device is
muted. If it is
muted, don't touch at the mute.
I'll drop this one from my patch series.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.2] cx23885 alsa cleaned and prepaired
Em 10-10-2011 11:52, Igor M. Liplianin escreveu: Hi Mauro and Steven, It's been a long time since cx23885-alsa pull was requested. To speed things up I created a git branch where I put the patches. Some patches merged, like introduce then correct checkpatch compliance or convert spinlock to mutex and back to spinlock, insert printk then remove printk as well. Minor corrections from me was silently merged, for major I created additional patches. Hope it helps. The following changes since commit e30528854797f057aa6ffb6dc9f890e923c467fd: [media] it913x-fe changes to power up and down of tuner (2011-10-08 08:03:27 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git cx23885-alsa-clean-2 Ok, all the other patches look sane. I just had to do another patchset reorder, moving patch 39 to happen before patch 29, and folding one of the Igor's fixes with a patch sent by Steven. I'm assuming that all of you are ok with that. So, I'm pushing the changeset into my tree. Igor M. Liplianin (2): cx23885: videobuf: Remove the videobuf_sg_dma_map/unmap functions cx25840-audio: fix missing state declaration Mijhail Moreyra (6): cx23885: merge mijhail's header changes for alsa cx23885: ALSA support cx23885: core changes requireed for ALSA cx23885: add definitions for HVR1500 to support audio cx23885: correct the contrast, saturation and hue controls cx23885: hooks the alsa changes into the video subsystem Steven Toth (31): cx23885: prepare the cx23885 makefile for alsa support cx23885: convert from snd_card_new() to snd_card_create() cx23885: convert call clients into subdevices cx23885: minor function renaming to ensure uniformity cx23885: setup the dma mapping for raw audio support cx23885: mute the audio during channel change cx23885: add two additional defines to simplify VBI register bitmap handling cx23885: initial support for VBI with the cx23885 cx23885: initialize VBI support in the core, add IRQ support, register vbi device cx23885: minor printk cleanups and device registration cx25840: enable raw cc processing only for the cx23885 hardware cx23885: vbi line window adjustments cx23885: add vbi buffer formatting, window changes and video core changes cx23885: Ensure the VBI pixel format is established correctly. cx23885: ensure video is streaming before allowing vbi to stream cx23885: remove channel dump diagnostics when a vbi buffer times out. cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during streaming. cx23885: Name an internal i2c part and declare a bitfield by name cx25840: Enable support for non-tuner LR1/LR2 audio inputs cx23885: Enable audio line in support from the back panel cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. cx23885: Initial support for the MPX-885 mini-card cx23885: fixes related to maximum number of inputs and range checking cx23885: add generic functions for dealing with audio input selection cx23885: hook the audio selection functions into the main driver cx23885: v4l2 api compliance, set the audioset field correctly cx23885: Removed a spurious function cx23885_set_scale(). cx23885: Avoid stopping the risc engine during buffer timeout. cx23885: Avoid incorrect error handling and reporting cx23885: Stop the risc video fifo before reconfiguring it. cx23885: Allow the audio mux config to be specified on a per input basis. drivers/media/video/cx23885/Makefile|2 +- drivers/media/video/cx23885/cx23885-alsa.c | 535 +++ drivers/media/video/cx23885/cx23885-cards.c | 53 +++ drivers/media/video/cx23885/cx23885-core.c | 99 - drivers/media/video/cx23885/cx23885-i2c.c |1 + drivers/media/video/cx23885/cx23885-reg.h |3 + drivers/media/video/cx23885/cx23885-vbi.c | 72 +++- drivers/media/video/cx23885/cx23885-video.c | 373 --- drivers/media/video/cx23885/cx23885.h | 56 +++ drivers/media/video/cx25840/cx25840-audio.c | 10 +- drivers/media/video/cx25840/cx25840-core.c | 19 + 11 files changed, 1144 insertions(+), 79 deletions(-) create mode 100644 drivers/media/video/cx23885/cx23885-alsa.c -- 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
via-camera: scaling and RGB modes
Hi Jon, We're dealing with a via-camera issue from the Scratch application. The latest version of scratch uses libv4l2 and requests RGB24 images as that is what it uses internally. via-camera/ov7670 doesn't support RGB24 but libv4l2 kicks in with its format conversion and chooses RGB565, which we do support. The catch is that Scratch requests 320x240 video. You probably recall that you made via-camera only ever request 640x480 from ov7670, but you also made via-camera offer discontinuous sizes and you used the via-camera hardware to scale the image to the appropriate size (viacam_set_scale). This scaling seems to work fine with YUYV, but fails with RGBA. Test case: gst-launch v4l2src ! video/x-raw-rgb,bpp=16,width=320,height=240 ! ffmpegcolorspace ! xvimagesink The colours in the resultant image wrong (lots of green). Change to 640x480, everything fine. The only documentation I can find on this is the Chrome9 HCM Graphics Processor Programming Manual which really doesn't explain much about the camera hardware apart from a bare set of register descriptions. What algorithm does that scaling functionality use, how does it know which format the image is in? Is there further documentation or are we stuck with this? If we're stuck with it, we have the options of solving this either by disabling everything other than YUYV (which scales fine), or just by disabling the scaling and locking to 640x480. Thoughts/other ideas? Unless I'm missing something, there doesn't seem a way to express in the V4L2 API that RGB is only available at 640x480 while YUYV is available at a range of sizes. Thanks, Daniel -- 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: [GIT PATCHES FOR 3.2] cx23885 alsa cleaned and prepaired
В сообщении от 14 октября 2011 23:25:07 автор Mauro Carvalho Chehab написал: Em 10-10-2011 11:52, Igor M. Liplianin escreveu: Hi Mauro and Steven, It's been a long time since cx23885-alsa pull was requested. To speed things up I created a git branch where I put the patches. Some patches merged, like introduce then correct checkpatch compliance or convert spinlock to mutex and back to spinlock, insert printk then remove printk as well. Minor corrections from me was silently merged, for major I created additional patches. Hope it helps. The following changes since commit e30528854797f057aa6ffb6dc9f890e923c467fd: [media] it913x-fe changes to power up and down of tuner (2011-10-08 08:03:27 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git cx23885-alsa-clean-2 Ok, all the other patches look sane. I just had to do another patchset reorder, moving patch 39 to happen before patch 29, and folding one of the Igor's fixes with a patch sent by Steven. I'm assuming that all of you are ok with that. So, I'm pushing the changeset into my tree. Great. Thank you Mauro. Igor M. Liplianin (2): cx23885: videobuf: Remove the videobuf_sg_dma_map/unmap functions cx25840-audio: fix missing state declaration Mijhail Moreyra (6): cx23885: merge mijhail's header changes for alsa cx23885: ALSA support cx23885: core changes requireed for ALSA cx23885: add definitions for HVR1500 to support audio cx23885: correct the contrast, saturation and hue controls cx23885: hooks the alsa changes into the video subsystem Steven Toth (31): cx23885: prepare the cx23885 makefile for alsa support cx23885: convert from snd_card_new() to snd_card_create() cx23885: convert call clients into subdevices cx23885: minor function renaming to ensure uniformity cx23885: setup the dma mapping for raw audio support cx23885: mute the audio during channel change cx23885: add two additional defines to simplify VBI register bitmap handling cx23885: initial support for VBI with the cx23885 cx23885: initialize VBI support in the core, add IRQ support, register vbi device cx23885: minor printk cleanups and device registration cx25840: enable raw cc processing only for the cx23885 hardware cx23885: vbi line window adjustments cx23885: add vbi buffer formatting, window changes and video core changes cx23885: Ensure the VBI pixel format is established correctly. cx23885: ensure video is streaming before allowing vbi to stream cx23885: remove channel dump diagnostics when a vbi buffer times out. cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during streaming. cx23885: Name an internal i2c part and declare a bitfield by name cx25840: Enable support for non-tuner LR1/LR2 audio inputs cx23885: Enable audio line in support from the back panel cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. cx23885: Initial support for the MPX-885 mini-card cx23885: fixes related to maximum number of inputs and range checking cx23885: add generic functions for dealing with audio input selection cx23885: hook the audio selection functions into the main driver cx23885: v4l2 api compliance, set the audioset field correctly cx23885: Removed a spurious function cx23885_set_scale(). cx23885: Avoid stopping the risc engine during buffer timeout. cx23885: Avoid incorrect error handling and reporting cx23885: Stop the risc video fifo before reconfiguring it. cx23885: Allow the audio mux config to be specified on a per input basis. drivers/media/video/cx23885/Makefile|2 +- drivers/media/video/cx23885/cx23885-alsa.c | 535 +++ drivers/media/video/cx23885/cx23885-cards.c | 53 +++ drivers/media/video/cx23885/cx23885-core.c | 99 - drivers/media/video/cx23885/cx23885-i2c.c |1 + drivers/media/video/cx23885/cx23885-reg.h |3 + drivers/media/video/cx23885/cx23885-vbi.c | 72 +++- drivers/media/video/cx23885/cx23885-video.c | 373 --- drivers/media/video/cx23885/cx23885.h | 56 +++ drivers/media/video/cx25840/cx25840-audio.c | 10 +- drivers/media/video/cx25840/cx25840-core.c | 19 + 11 files changed, 1144 insertions(+), 79 deletions(-) create mode 100644 drivers/media/video/cx23885/cx23885-alsa.c -- 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
Re: freeze/crash
On Fri, 14 Oct 2011 20:38:46 +0200, James bjloc...@lockie.ca wrote: On 10/14/11 07:10, semiRocket wrote: On Fri, 14 Oct 2011 01:51:37 +0200, James bjloc...@lockie.ca wrote: It always crashes when I access the hardware but the place it crashes is random. Maybe you would want to pass those crash logs for debugging purposes What crash logs? The kernel locks up, is there a log somewhere? System log under /var/log/messages or command dmesg Also, if you keep your terminal window open crash should pop-up by itself so called kernel oops. For example see first post in the following link: http://stackoverflow.com/questions/316131/how-do-you-diagnose-a-kernel-oops -- 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
OMAP3 ISP - interlaced data incorrect
For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Note 2: I think I have explanations for much of the ghosting that has been observed: * Frame to frame tearing results from the fact that the frames are interlaced and the actual data changes from one half of the frame to the other. This would not be observed with traditional media, e.g. film, where nothing can move from one frame to the next because of the speed of shutters. In the purely digital capture case, every pixel has the opportunity to change constantly and to find some that change with the 33ms (NTSC) window (1 frame) is quite probable. You can see some of this in the [otherwise quite good] sequence of images http://www.mlbassoc.com/misc/nemo-swapped-1.png ... http://www.mlbassoc.com/misc/nemo-swapped-00062.png * Frames being skipped /or very stale data being reused - I think this is a [user] software problem. The ISP driver assumes that it always has an empty buffer to move captured data into. Depending on the [user] program which is consuming the data, this may or not be true. In the case of ffmpeg, if I capture raw images, ffmpeg can almost always keep up and there is always a free buffer. However, if I have ffmpeg turn the raw frames into compressed video (mp4), nearly 1/2 of the time, the ISP will run dry on buffers. I think I know how to fix this (untested) but it shows that some of the issues may be with the userland code we rely on. I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. Note 3: The image viewer found at http://djv.sourceforge.net/ works great for these analyses. Just run 'djv_view' and point at the first image in a sequence :-) n.b. I'm not associated with that project, but I really like it! -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [PATCHv16 0/9] Contiguous Memory Allocator
On Tue, 11 Oct 2011 15:52:04 +0200 Arnd Bergmann a...@arndb.de wrote: On Tuesday 11 October 2011, Andrew Morton wrote: Russell's going to hate me, but... I do know that he had substantial objections to at least earlier versions of this, and he is a guy who knows of what he speaks. So I would want to get a nod from rmk on this work before proceeding. If that nod isn't available then let's please identify the issues and see what we can do about them. I'm pretty sure that Russell's concerns were almost entirely about the ARM specific parts, which were extremely hard to figure out. The most important technical concern back in July was that the patch series at the time did not address the problem of conflicting pte flags when we remap memory as uncached on ARMv6. He had a patch to address this problem that was supposed to get merged in 3.1 and would have conflicted with the CMA patch set. Things have changed a lot since then. Russell had to revert his own patch because he found regressions using it on older machines. However, the current CMA on ARM patch AFAICT reliably fixes this problem now and does not cause the same regression on older machines. The solution used now is the one we agreed on after sitting together for a few hours with Russell, Marek, Paul McKenney and myself. If there are still concerns over the ARM specific portion of the patch series, I'm very confident that we can resolve these now (I was much less so before that meeting). What I would really want to hear from you is your opinion on the architecture independent stuff. Obviously, ARM is the most important consumer of the patch set, but I think the code has its merit on other architectures as well and most of them (maybe not parisc) should be about as simple as the x86 one that Marek posted now with v16. Having an x86 implementation is good. It would also be good to get some x86 drivers using CMA asap, so the thing gets some runtime testing from the masses. Can we think of anything we can do here? Regarding the core MM changes: Mel's the man for migration and compaction. I wouldn't want to proceed until he (and perferably Johannes) have spent some quality time with the code. I'm not seeing their reviewed-by's of acked-by's and I don't have a good recollection of their involvement? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] mm: move some functions from memory_hotplug.c to page_isolation.c
On Thu, 06 Oct 2011 15:54:41 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Memory hotplug is a logic for making pages unused in the specified range of pfn. So, some of core logics can be used for other purpose as allocating a very large contigous memory block. This patch moves some functions from mm/memory_hotplug.c to mm/page_isolation.c. This helps adding a function for large-alloc in page_isolation.c with memory-unplug technique. Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com [m.nazarewicz: reworded commit message] Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com [m.szyprowski: rebased and updated to Linux v3.0-rc1] Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com CC: Michal Nazarewicz min...@mina86.com Acked-by: Arnd Bergmann a...@arndb.de ... +/* + * For migration. + */ + +int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn); This is a rather poor function name. Given that we're now making it a global identifier, perhaps we should give it a better name. pages_in_single_zone()? +unsigned long scan_lru_pages(unsigned long start, unsigned long end); +int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn); ... --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -5,6 +5,9 @@ #include linux/mm.h #include linux/page-isolation.h #include linux/pageblock-flags.h +#include linux/memcontrol.h +#include linux/migrate.h +#include linux/mm_inline.h #include internal.h static inline struct page * @@ -139,3 +142,114 @@ int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn) spin_unlock_irqrestore(zone-lock, flags); return ret ? 0 : -EBUSY; } + + +/* + * Confirm all pages in a range [start, end) is belongs to the same zone. It would be good to fix up that sentence while we're touching it. Confirm that all pages ... belong to the same zone. ... -- 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: OMAP3 ISP - interlaced data incorrect
On 2011-10-14 17:07, Gary Thomas wrote: For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Note 2: I think I have explanations for much of the ghosting that has been observed: * Frame to frame tearing results from the fact that the frames are interlaced and the actual data changes from one half of the frame to the other. This would not be observed with traditional media, e.g. film, where nothing can move from one frame to the next because of the speed of shutters. In the purely digital capture case, every pixel has the opportunity to change constantly and to find some that change with the 33ms (NTSC) window (1 frame) is quite probable. To be clear, moving from film to video, there would be no change of data within a single frame between the two interleaved halves. I'm sure this was even true of old cameras, which were not digital capture devices being used to send interleaved analogue data. You can see some of this in the [otherwise quite good] sequence of images http://www.mlbassoc.com/misc/nemo-swapped-1.png ... http://www.mlbassoc.com/misc/nemo-swapped-00062.png * Frames being skipped /or very stale data being reused - I think this is a [user] software problem. The ISP driver assumes that it always has an empty buffer to move captured data into. Depending on the [user] program which is consuming the data, this may or not be true. In the case of ffmpeg, if I capture raw images, ffmpeg can almost always keep up and there is always a free buffer. However, if I have ffmpeg turn the raw frames into compressed video (mp4), nearly 1/2 of the time, the ISP will run dry on buffers. I think I know how to fix this (untested) but it shows that some of the issues may be with the userland code we rely on. In the case of ffmpeg capturing raw data, there were no times that the ISP driver wanted a buffer and failed to get one, at least when storing the frames in a RAM disk. If stored to a physical device like MMC card, this might not be true. However, when ffmpeg is used to create an MP4 image, even to RAM disk, nearly 1/2 of the time the ISP goes wanting, which certainly can't be good! I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. Note 3: The image viewer found at http://djv.sourceforge.net/ works great for these analyses. Just run 'djv_view' and point at the first image in a sequence :-) n.b. I'm not associated with that project, but I really like it! -- Gary Thomas | Consulting for the MLB Associates |Embedded world
Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added
On Thu, 06 Oct 2011 15:54:42 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
This commit introduces alloc_contig_freed_pages() function
The freed seems redundant to me. Wouldn't alloc_contig_pages be a
better name?
which allocates (ie. removes from buddy system) free pages
in range. Caller has to guarantee that all pages in range
are in buddy system.
Along with this function, a free_contig_pages() function is
provided which frees all (or a subset of) pages allocated
with alloc_contig_free_pages().
Michal Nazarewicz has modified the function to make it easier
to allocate not MAX_ORDER_NR_PAGES aligned pages by making it
return pfn of one-past-the-last allocated page.
...
+#if defined(CONFIG_SPARSEMEM) !defined(CONFIG_SPARSEMEM_VMEMMAP)
+/*
+ * Both PFNs must be from the same zone! If this function returns
+ * true, pfn_to_page(pfn1) + (pfn2 - pfn1) == pfn_to_page(pfn2).
+ */
+static inline bool zone_pfn_same_memmap(unsigned long pfn1, unsigned long
pfn2)
+{
+ return pfn_to_section_nr(pfn1) == pfn_to_section_nr(pfn2);
+}
+
+#else
+
+#define zone_pfn_same_memmap(pfn1, pfn2) (true)
Do this in C, please. It's nicer and can prevent unused-var warnings.
+#endif
+
...
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long
end,
+gfp_t flag)
+{
+ unsigned long pfn = start, count;
+ struct page *page;
+ struct zone *zone;
+ int order;
+
+ VM_BUG_ON(!pfn_valid(start));
+ page = pfn_to_page(start);
+ zone = page_zone(page);
+
+ spin_lock_irq(zone-lock);
+
+ for (;;) {
+ VM_BUG_ON(page_count(page) || !PageBuddy(page) ||
+ page_zone(page) != zone);
+
+ list_del(page-lru);
+ order = page_order(page);
+ count = 1UL order;
+ zone-free_area[order].nr_free--;
+ rmv_page_order(page);
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(long)count);
__mod_zone_page_state() generally shouldn't be used - it bypasses the
per-cpu magazines and can introduce high lock contentions.
That's hopefully not an issue on this callpath but it is still a red
flag. I'd suggest at least the addition of a suitably apologetic code
comment here - we don't want people to naively copy this code.
Plus such a comment would let me know why this was done ;)
+ pfn += count;
+ if (pfn = end)
+ break;
+ VM_BUG_ON(!pfn_valid(pfn));
+
+ if (zone_pfn_same_memmap(pfn - count, pfn))
+ page += count;
+ else
+ page = pfn_to_page(pfn);
+ }
+
+ spin_unlock_irq(zone-lock);
+
+ /* After this, pages in the range can be freed one be one */
+ count = pfn - start;
+ pfn = start;
+ for (page = pfn_to_page(pfn); count; --count) {
+ prep_new_page(page, 0, flag);
+ ++pfn;
+ if (likely(zone_pfn_same_memmap(pfn - 1, pfn)))
+ ++page;
+ else
+ page = pfn_to_page(pfn);
+ }
+
+ return pfn;
+}
+
+void free_contig_pages(unsigned long pfn, unsigned nr_pages)
+{
+ struct page *page = pfn_to_page(pfn);
+
+ while (nr_pages--) {
+ __free_page(page);
+ ++pfn;
+ if (likely(zone_pfn_same_memmap(pfn - 1, pfn)))
+ ++page;
+ else
+ page = pfn_to_page(pfn);
+ }
+}
You're sure these functions don't need EXPORT_SYMBOL()? Maybe the
design is that only DMA core calls into here (if so, that's good).
#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
--
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] mm: alloc_contig_range() added
On Thu, 06 Oct 2011 15:54:43 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit adds the alloc_contig_range() function which tries
to allocate given range of pages. It tries to migrate all
already allocated pages that fall in the range thus freeing them.
Once all pages in the range are freed they are removed from the
buddy system thus allocated for the caller to use.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: renamed some variables for easier code reading]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Acked-by: Arnd Bergmann a...@arndb.de
Where-is: Mel Gorman m...@csn.ul.ie
+#define MIGRATION_RETRY 5
+static int __alloc_contig_migrate_range(unsigned long start, unsigned long
end)
+{
+ int migration_failed = 0, ret;
+ unsigned long pfn = start;
+
+ /*
+ * Some code borrowed from KAMEZAWA Hiroyuki's
+ * __alloc_contig_pages().
+ */
+
+ /* drop all pages in pagevec and pcp list */
+ lru_add_drain_all();
+ drain_all_pages();
These operations are sometimes wrong ;) Have you confirmed that we
really need to perform them here? If so, a little comment explaining
why we're using them here would be good.
+ for (;;) {
+ pfn = scan_lru_pages(pfn, end);
+ if (!pfn || pfn = end)
+ break;
+
+ ret = do_migrate_range(pfn, end);
+ if (!ret) {
+ migration_failed = 0;
+ } else if (ret != -EBUSY
+ || ++migration_failed = MIGRATION_RETRY) {
Sigh, magic numbers.
Have you ever seen this retry loop actually expire in testing?
migrate_pages() tries ten times. This code tries five times. Is there
any science to all of this?
+ return ret;
+ } else {
+ /* There are unstable pages.on pagevec. */
+ lru_add_drain_all();
+ /*
+ * there may be pages on pcplist before
+ * we mark the range as ISOLATED.
+ */
+ drain_all_pages();
+ }
+ cond_resched();
+ }
+
+ if (!migration_failed) {
+ /* drop all pages in pagevec and pcp list */
+ lru_add_drain_all();
+ drain_all_pages();
hm.
+ }
+
+ /* Make sure all pages are isolated */
+ if (WARN_ON(test_pages_isolated(start, end)))
+ return -EBUSY;
+
+ return 0;
+}
+
+/**
+ * alloc_contig_range() -- tries to allocate given range of pages
+ * @start: start PFN to allocate
+ * @end: one-past-the-last PFN to allocate
+ * @flags: flags passed to alloc_contig_freed_pages().
+ *
+ * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
+ * aligned, hovewer it's callers responsibility to guarantee that we
however
however it is the caller's responsibility..
+ * are the only thread that changes migrate type of pageblocks the
+ * pages fall in.
+ *
+ * Returns zero on success or negative error code. On success all
+ * pages which PFN is in (start, end) are allocated for the caller and
+ * need to be freed with free_contig_pages().
+ */
...
--
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/9] mm: MIGRATE_CMA migration type added
On Thu, 06 Oct 2011 15:54:44 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
From: Michal Nazarewicz m.nazarew...@samsung.com
The MIGRATE_CMA migration type has two main characteristics:
(i) only movable pages can be allocated from MIGRATE_CMA
pageblocks and (ii) page allocator will never change migration
type of MIGRATE_CMA pageblocks.
This guarantees that page in a MIGRATE_CMA page block can
always be migrated somewhere else (unless there's no memory left
in the system).
It is designed to be used with Contiguous Memory Allocator
(CMA) for allocating big chunks (eg. 10MiB) of physically
contiguous memory. Once driver requests contiguous memory,
CMA will migrate pages from MIGRATE_CMA pageblocks.
To minimise number of migrations, MIGRATE_CMA migration type
is the last type tried when page allocator falls back to other
migration types then requested.
...
+#ifdef CONFIG_CMA_MIGRATE_TYPE
+# define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+# define is_migrate_cma(migratetype) false
+#endif
Implement in C, please.
...
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -115,6 +115,16 @@ static bool suitable_migration_target(struct page *page)
if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
return false;
+ /* Keep MIGRATE_CMA alone as well. */
+ /*
+ * XXX Revisit. We currently cannot let compaction touch CMA
+ * pages since compaction insists on changing their migration
+ * type to MIGRATE_MOVABLE (see split_free_page() called from
+ * isolate_freepages_block() above).
+ */
Talk to us about this.
How serious is this shortcoming in practice? What would a fix look
like? Is anyone working on an implementation, or planning to do so?
+ if (is_migrate_cma(migratetype))
+ return false;
+
/* If the page is a large free page, then allow migration */
if (PageBuddy(page) page_order(page) = pageblock_order)
return true;
...
+void __init init_cma_reserved_pageblock(struct page *page)
+{
+ struct page *p = page;
+ unsigned i = pageblock_nr_pages;
+
+ prefetchw(p);
+ do {
+ if (--i)
+ prefetchw(p + 1);
+ __ClearPageReserved(p);
+ set_page_count(p, 0);
+ } while (++p, i);
+
+ set_page_refcounted(page);
+ set_pageblock_migratetype(page, MIGRATE_CMA);
+ __free_pages(page, pageblock_order);
+ totalram_pages += pageblock_nr_pages;
+}
I wonder if the prefetches do any good. it doesn't seem very important
in an __init function.
+#endif
...
--
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: OMAP3 ISP - interlaced data incorrect
On Sat, Oct 15, 2011 at 1:07 AM, Gary Thomas g...@mlbassoc.com wrote: For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Just set the FINV bit (search for it in ispccdc.c), i tested it before and i had the opposite result (from a good looking nemo-swapped-like picture to a bad one). I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. I've tested it with the dsp and nothing changes, same problems. But i will be happy if proven wrong! Enrico -- 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: OMAP3 ISP - interlaced data incorrect
On Sat, Oct 15, 2011 at 1:23 AM, Gary Thomas g...@mlbassoc.com wrote: To be clear, moving from film to video, there would be no change of data within a single frame between the two interleaved halves. I'm sure this was even true of old cameras, which were not digital capture devices being used to send interleaved analogue data. You can see some of this in the [otherwise quite good] sequence of images http://www.mlbassoc.com/misc/nemo-swapped-1.png ... http://www.mlbassoc.com/misc/nemo-swapped-00062.png * Frames being skipped /or very stale data being reused - I think this is a [user] software problem. The ISP driver assumes that it always has an empty buffer to move captured data into. Depending on the [user] program which is consuming the data, this may or not be true. In the case of ffmpeg, if I capture raw images, ffmpeg can almost always keep up and there is always a free buffer. However, if I have ffmpeg turn the raw frames into compressed video (mp4), nearly 1/2 of the time, the ISP will run dry on buffers. I think I know how to fix this (untested) but it shows that some of the issues may be with the userland code we rely on. In the case of ffmpeg capturing raw data, there were no times that the ISP driver wanted a buffer and failed to get one, at least when storing the frames in a RAM disk. If stored to a physical device like MMC card, this might not be true. However, when ffmpeg is used to create an MP4 image, even to RAM disk, nearly 1/2 of the time the ISP goes wanting, which certainly can't be good! That is to be expected, it's not good but the worst thing that could happen is that you will lose some frames, not fields (unless you are losing interrupts too). So you will get laggy video, but with no ghosting. But i can't remember what the isp buffer code do when out of buffer so i'm assuming it will do a sane thing (drop the current frame). Enrico -- 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] it913x [VER 1.07] Support for single ITE 9135 devices
Support for single ITE 9135 device.
Only single devices have been tested. Dual ITE 9135 devices
should work, but have not been tested.
TODOs
support for ver 2 chip
config for other tuner types.
rework of firmware file.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/dvb-usb-ids.h |2 +
drivers/media/dvb/dvb-usb/it913x.c | 105 +++
2 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
index 7433261..31b4aa4 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -37,6 +37,7 @@
#define USB_VID_HAUPPAUGE 0x2040
#define USB_VID_HYPER_PALTEK 0x1025
#define USB_VID_INTEL 0x8086
+#define USB_VID_ITETECH0x048d
#define USB_VID_KWORLD 0xeb2a
#define USB_VID_KWORLD_2 0x1b80
#define USB_VID_KYE0x0458
@@ -126,6 +127,7 @@
#define USB_PID_GRANDTEC_DVBT_USB_COLD 0x0fa0
#define USB_PID_GRANDTEC_DVBT_USB_WARM 0x0fa1
#define USB_PID_INTEL_CE9500 0x9500
+#define USB_PID_ITETECH_IT9135 0x9135
#define USB_PID_KWORLD_399U0xe399
#define USB_PID_KWORLD_399U_2 0xe400
#define USB_PID_KWORLD_395U0xe396
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index f027a2c..c462261 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -60,6 +60,17 @@ struct it913x_state {
u8 id;
};
+struct ite_config {
+ u8 chip_ver;
+ u16 chip_type;
+ u32 firmware;
+ u8 tuner_id_0;
+ u8 tuner_id_1;
+ u8 dual_mode;
+};
+
+struct ite_config it913x_config;
+
static int it913x_bulk_write(struct usb_device *dev,
u8 *snd, int len, u8 pipe)
{
@@ -191,18 +202,23 @@ static int it913x_read_reg(struct usb_device *udev, u32
reg)
static u32 it913x_query(struct usb_device *udev, u8 pro)
{
int ret;
- u32 res = 0;
u8 data[4];
ret = it913x_io(udev, READ_LONG, pro, CMD_DEMOD_READ,
- 0x1222, 0, data[0], 1);
- if (data[0] == 0x1) {
- ret = it913x_io(udev, READ_SHORT, pro,
+ 0x1222, 0, data[0], 3);
+
+ it913x_config.chip_ver = data[0];
+ it913x_config.chip_type = (u16)(data[2] 8) + data[1];
+
+ info(Chip Version=%02x Chip Type=%04x, it913x_config.chip_ver,
+ it913x_config.chip_type);
+
+ ret |= it913x_io(udev, READ_SHORT, pro,
CMD_QUERYINFO, 0, 0x1, data[0], 4);
- res = (data[0] 24) + (data[1] 16) +
+
+ it913x_config.firmware = (data[0] 24) + (data[1] 16) +
(data[2] 8) + data[3];
- }
- return (ret 0) ? 0 : res;
+ return (ret 0) ? 0 : it913x_config.firmware;
}
static int it913x_pid_filter_ctrl(struct dvb_usb_adapter *adap, int onoff)
@@ -336,26 +352,35 @@ static int it913x_identify_state(struct usb_device *udev,
int *cold)
{
int ret = 0, firm_no;
- u8 reg, adap, ep, tun0, tun1;
+ u8 reg, remote;
firm_no = it913x_return_status(udev);
- ep = it913x_read_reg(udev, 0x49ac);
- adap = it913x_read_reg(udev, 0x49c5);
- tun0 = it913x_read_reg(udev, 0x49d0);
- info(No. Adapters=%x Endpoints=%x Tuner Type=%x, adap, ep, tun0);
+ /* checnk for dual mode */
+ it913x_config.dual_mode = it913x_read_reg(udev, 0x49c5);
+
+ /* TODO different remotes */
+ remote = it913x_read_reg(udev, 0x49ac); /* Remote */
+ if (remote == 0)
+ props-rc.core.rc_codes = NULL;
+
+ /* TODO at the moment tuner_id is always assigned to 0x38 */
+ it913x_config.tuner_id_0 = it913x_read_reg(udev, 0x49d0);
+
+ info(Dual mode=%x Remote=%x Tuner Type=%x, it913x_config.dual_mode
+ , remote, it913x_config.tuner_id_0);
if (firm_no 0) {
*cold = 0;
return 0;
}
- if (adap 2) {
- tun1 = it913x_read_reg(udev, 0x49e0);
+ if (it913x_config.dual_mode) {
+ it913x_config.tuner_id_1 = it913x_read_reg(udev, 0x49e0);
ret = it913x_wr_reg(udev, DEV_0, GPIOH1_EN, 0x1);
ret |= it913x_wr_reg(udev, DEV_0, GPIOH1_ON, 0x1);
ret |= it913x_wr_reg(udev, DEV_0, GPIOH1_O, 0x1);
- msleep(50); /* Delay noticed reset cycle ? */
+ msleep(50);
ret |= it913x_wr_reg(udev, DEV_0, GPIOH1_O, 0x0);
msleep(50);
reg = it913x_read_reg(udev, GPIOH1_O);
@@ -366,14 +391,19 @@ static int
Re: [PATCH 6/9] drivers: add Contiguous Memory Allocator
On Thu, 06 Oct 2011 15:54:46 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
The Contiguous Memory Allocator is a set of helper functions for DMA
mapping framework that improves allocations of contiguous memory chunks.
CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and
gives back to the system. Kernel is allowed to allocate movable pages
within CMA's managed memory so that it can be used for example for page
cache when DMA mapping do not use it. On dma_alloc_from_contiguous()
request such pages are migrated out of CMA area to free required
contiguous block and fulfill the request. This allows to allocate large
contiguous chunks of memory at any time assuming that there is enough
free memory available in the system.
This code is heavily based on earlier works by Michal Nazarewicz.
...
+#ifdef phys_to_pfn
+/* nothing to do */
+#elif defined __phys_to_pfn
+# define phys_to_pfn __phys_to_pfn
+#elif defined __va
+# define phys_to_pfn(x) page_to_pfn(virt_to_page(__va(x)))
+#else
+# error phys_to_pfn implementation needed
+#endif
Yikes!
This hackery should not be here, please. If we need a phys_to_pfn()
then let's write a proper one which lives in core MM and arch, then get
it suitably reviewed and integrated and then maintained.
+struct cma {
+ unsigned long base_pfn;
+ unsigned long count;
+ unsigned long *bitmap;
+};
+
+struct cma *dma_contiguous_default_area;
+
+#ifndef CONFIG_CMA_SIZE_ABSOLUTE
+#define CONFIG_CMA_SIZE_ABSOLUTE 0
+#endif
+
+#ifndef CONFIG_CMA_SIZE_PERCENTAGE
+#define CONFIG_CMA_SIZE_PERCENTAGE 0
+#endif
No, .c files should not #define CONFIG_ variables like this.
One approach is
#ifdef CONFIG_FOO
#define BAR CONFIG_FOO
#else
#define BAR 0
#endif
but that's merely cosmetic fluff. A superior fix is to get the Kconfig
correct, so CONFIG_FOO cannot ever be undefined if we're compiling this
.c file.
+static unsigned long size_abs = CONFIG_CMA_SIZE_ABSOLUTE * SZ_1M;
+static unsigned long size_percent = CONFIG_CMA_SIZE_PERCENTAGE;
+static long size_cmdline = -1;
Maybe a little documentation for these, explaining their role in
everything?
+static int __init early_cma(char *p)
+{
+ pr_debug(%s(%s)\n, __func__, p);
+ size_cmdline = memparse(p, p);
+ return 0;
+}
+early_param(cma, early_cma);
Did this get added to Documentation/kernel-parameters.txt?
+static unsigned long __init __cma_early_get_total_pages(void)
The leading __ seems unnecessay for a static function.
+{
+ struct memblock_region *reg;
+ unsigned long total_pages = 0;
+
+ /*
+ * We cannot use memblock_phys_mem_size() here, because
+ * memblock_analyze() has not been called yet.
+ */
+ for_each_memblock(memory, reg)
+ total_pages += memblock_region_memory_end_pfn(reg) -
+memblock_region_memory_base_pfn(reg);
+ return total_pages;
+}
+
+/**
+ * dma_contiguous_reserve() - reserve area for contiguous memory handling
+ *
+ * This funtion reserves memory from early allocator. It should be
+ * called by arch specific code once the early allocator (memblock or
bootmem)
+ * has been activated and all other subsystems have already
allocated/reserved
+ * memory.
+ */
Forgot to document the argument.
+void __init dma_contiguous_reserve(phys_addr_t limit)
+{
+ unsigned long selected_size = 0;
+ unsigned long total_pages;
+
+ pr_debug(%s(limit %08lx)\n, __func__, (unsigned long)limit);
+
+ total_pages = __cma_early_get_total_pages();
+ size_percent *= (total_pages PAGE_SHIFT) / 100;
+
+ pr_debug(%s: total available: %ld MiB, size absolute: %ld MiB, size
percentage: %ld MiB\n,
+ __func__, (total_pages PAGE_SHIFT) / SZ_1M,
+ size_abs / SZ_1M, size_percent / SZ_1M);
+
+#ifdef CONFIG_CMA_SIZE_SEL_ABSOLUTE
+ selected_size = size_abs;
+#elif defined(CONFIG_CMA_SIZE_SEL_PERCENTAGE)
+ selected_size = size_percent;
+#elif defined(CONFIG_CMA_SIZE_SEL_MIN)
+ selected_size = min(size_abs, size_percent);
+#elif defined(CONFIG_CMA_SIZE_SEL_MAX)
+ selected_size = max(size_abs, size_percent);
+#endif
geeze, what's all that stuff?
Whatever it's doing, it seems a bad idea to relegate these decisions to
Kconfig-time. The vast majority of users don't have control of their
kernel configuration! The code would be more flexible and generic if
this was done at runtime somehow.
+ if (size_cmdline != -1)
+ selected_size = size_cmdline;
+
+ if (!selected_size)
+ return;
+
+ pr_debug(%s: reserving %ld MiB for global area\n, __func__,
+ selected_size / SZ_1M);
+
+ dma_declare_contiguous(NULL, selected_size, 0, limit);
+};
+
...
+static struct cma *__cma_create_area(unsigned long base_pfn,
s/__//?
+ unsigned long count)
+{
+ int bitmap_size =
Re: OMAP3 ISP - interlaced data incorrect
On 2011-10-14 17:43, Enrico wrote: On Sat, Oct 15, 2011 at 1:07 AM, Gary Thomasg...@mlbassoc.com wrote: For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Just set the FINV bit (search for it in ispccdc.c), i tested it before and i had the opposite result (from a good looking nemo-swapped-like picture to a bad one). That works great, thanks. Maybe we need another user flag, like fldmode, for this? I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. I've tested it with the dsp and nothing changes, same problems. But i will be happy if proven wrong! I'll play with this a bit more tomorrow. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
