Re: I wonder the difference with mbus_pixelcode and v4l2_colorspace.
Thanks Guennadi, Actually, I have been confused between MC MB. Including this, the link of Laurent is very helpful for me to make M5MOLS subdev driver. Regard, HeungJun Kim 2010-12-08 오후 4:23, Guennadi Liakhovetski 쓴 글: Hi On Wed, 8 Dec 2010, Kim, HeungJun wrote: Hi Guennadi, I wonder the difference with pixelcode mediabus and v4l2_colorspace. In mt9m001.c subdev driver, the format seems be determined using the combination pixelcode colorspace. In the previous kernel version(before using Media Controller), somtimes the pixelformat is used for defining format of isp device. But, I gonna change to use Media Controller. The change to mediabus pixelcodes has happened a while ago, whereas media controller is still not in the mainline. Mediabus is physically a bus between various parts of the media (video) subsystem, e.g., between a sensor and an SoC, or between resizers, format converters, etc., as long as data between them is exchanged directly over a set of data and sync lines, and not via mamory buffers. Original V4L2 fourcc codes on the other side describe data format in _memory_. The use of a pixelcode and a colorspace has been selected for the new mediabus API, so, that's what we have to use now in drivers, using this API. So, can you tell me where I find about Media Controller, especially pixelcode and colorspace? Again - these are not directly related things. The MC API has adopted, extended and is using the mediabus API, Laurent has documented many things wonderfully, have a look at http://www.ideasonboard.org/media/media/subdev.html#v4l2-mbus-format Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH v4 1/4] Changes in include/linux/videodev2.h for MFC 5.1
Hi, From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Em 10-12-2010 01:32, 박정태 escreveu: Hi, Kamil What do you think modification of codec class control ID for MFC as following. 1. Define the CID base for MFC 2. Separate decode encode controls 3. Separate common codec-specific controls Add fourcc values for compressed video stream formats and V4L2_CTRL_CLASS_CODEC. Also adds controls used by MFC 5.1 driver. This is a very bad idea. As much as possible, controls should be generic enough to avoid us to have the same control provided by two different hardware. The only case were a control should be per-driver, is when the control is for some very specific implementation detail on that hardware, that it is unlikely that other chipsets will implement it at the same way. I agree with Mauro. The point of having a general class for codecs (V4L2_CID_CODEC_CLASS) is reusing same controls for different hardware. I think that most controls, maybe all, could be used by other hw codecs. (snip) Best regards, -- Kamil Debski Linux Platform Group 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
RE: [RFC/PATCH v4 2/4] MFC: Add MFC 5.1 driver to plat-s5p
Hi,
From: Kukjin Kim [mailto:kgene@samsung.com]
Kamil Debski wrote:
Would be better if you could keep the subject style...
Ok, I'll make the comment more consistent.
(snip)
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h
b/arch/arm/mach-
s5pv210/include/mach/map.h
index 0982443..8f887c4 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -107,6 +107,9 @@
#define S5PV210_PA_DMC0(0xF000)
#define S5PV210_PA_DMC1(0xF140)
+/* MFC */
No need useless comment.
Just above the place, where I have added MFC, there are defines
for AC97, PCM, I2S etc. and all of them have such comment before
( /* AC97 */ for AC97 codec). As such I wanted to keep the style.
I agree that it is not necessary, but removing it could make the
file less consistent. Are you sure you want me to remove it?
+#define S5PV210_PA_MFC (0xF170)
+
/* compatibiltiy defines. */
#define S3C_PA_UARTS5PV210_PA_UART
#define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0)
@@ -123,6 +126,7 @@
#define S5P_PA_FIMC0 S5PV210_PA_FIMC0
#define S5P_PA_FIMC1 S5PV210_PA_FIMC1
#define S5P_PA_FIMC2 S5PV210_PA_FIMC2
+#define S5P_PA_MFC S5PV210_PA_MFC
#define SAMSUNG_PA_ADC S5PV210_PA_ADC
#define SAMSUNG_PA_CFCON S5PV210_PA_CFCON
diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
index 9755df9..c7a048e 100644
--- a/arch/arm/plat-s5p/Kconfig
+++ b/arch/arm/plat-s5p/Kconfig
@@ -5,6 +5,11 @@
#
# Licensed under GPLv2
+config S5P_DEV_MFC
+ bool
+ help
+ Compile in platform device definitions for MFC
+
config PLAT_S5P
bool
depends on (ARCH_S5P64X0 || ARCH_S5P6442 || ARCH_S5PC100 ||
ARCH_S5PV210 || ARCH_S5PV310)
diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
index df65cb7..ed0f33d 100644
--- a/arch/arm/plat-s5p/Makefile
+++ b/arch/arm/plat-s5p/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PM) += pm.o
obj-$(CONFIG_PM) += irq-pm.o
# devices
+obj-$(CONFIG_S5P_DEV_MFC) += dev-mfc5.o
Do we really need to distinguish mfc version in file name?
So why did you use just CONFIG_S5P_DEV_MFC as config name?
I mean don't use mixed name in there.
Right, I think removing the version number is ok. Another way would be
adding
v5 everywhere. But I don't think it is necessary.
+obj-$(CONFIG_S5P_DEV_MFC5) += dev-mfc5.o
Or
+obj-$(CONFIG_S5P_DEV_MFC)+= dev-mfc.o
I prefer the latter...because no need to separate the hardware version
in
platform data now.
Ok.
obj-$(CONFIG_S5P_DEV_FIMC0)+= dev-fimc0.o
obj-$(CONFIG_S5P_DEV_FIMC1)+= dev-fimc1.o
diff --git a/arch/arm/plat-s5p/dev-mfc5.c b/arch/arm/plat-s5p/dev-
mfc5.c
new file mode 100644
index 000..c06ea97
--- /dev/null
+++ b/arch/arm/plat-s5p/dev-mfc5.c
@@ -0,0 +1,37 @@
+/* Base S3C64XX mfc resource and device definitions */
+
+
Where is the GPL license?
This is very important...
The file lacks a proper comment altogether. Thanks for pointing
this out, indeed it is important.
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/ioport.h
+
+#include mach/map.h
+#include plat/map-base.h
Do we _really_ need plat/map-base.h inclusion?
NO.
Right.
+#include plat/devs.h
+#include plat/irqs.h
+
+/* MFC controller */
No need above comment.
Ok.
+static struct resource s5p_mfc_resource[] = {
+ [0] = {
+ .start = S5P_PA_MFC,
+ .end= S5P_PA_MFC + SZ_64K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_MFC,
+ .end= IRQ_MFC,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+struct platform_device s5p_device_mfc5 = {
+ .name = s5p-mfc5,
+ .id= -1,
+ .num_resources = ARRAY_SIZE(s5p_mfc_resource),
+ .resource = s5p_mfc_resource,
+};
+
+EXPORT_SYMBOL(s5p_device_mfc5);
+
+
No need useless 2 empty lines here.
Ok.
(snip)
Thank you for your comments.
Best regards,
--
Kamil Debski
Linux Platform Group
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
Re: [PATCH 1/6] [media] gspca/sn9c20x: Test if sensor is really an ov9650
On Thu, 9 Dec 2010 18:42:34 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: Instead of just assuming a ov9650 sensor based on USB ID, double-check it, by reading the sensor ID. Hi Mauro, In the patch, you check that the sensor is an OmniVision one, but not the ov9650. So, if the test succeeds, it could also be any of ov9655, ov7660 or ov7670, which could be treated, but will not work, or some other OmniVision sensor. The sensor type is defined by the sensor registers 0x0a and 0x0b. But, if it is enough for you, it is OK for me. Acked-by: Jean-Francois Moine moin...@free.fr Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] [media] gspca/sn9c20x: Get rid of scale magic numbers
On Thu, 9 Dec 2010 18:42:35 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: Use macros for the supported scales, instead of using magic numbers from 0 to 3. Code become cleaner by using macros for it. Acked-by: Jean-Francois Moine moin...@free.fr -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 0/2] OMAP1: amsdelta: reserve memory for videobuf_contig
Friday 10 December 2010 02:29:09 Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [101205 10:19]: Latest developements seem to allow for reserving a block of memory on boot to be used as a device dedicated dma coherent memory. This may be required for videobuf_config based video drivers avoid problems with allocating dma coherent memory after system memory gets fragmented. This set extends the OMAP1 camera resource initialization code with a function that can be used for reserving a block of memory early, then declared as the camera device dedicated dma coherent memory. An example use case is provided for Amstrad Delta camera. These look good to me, however, can you please also Cc linux-arm-kernel list as otherwise I will need to repost these before merging. Sure. Perhaps that first submission should rather go as an RFC, now that there are no requests for changes, I'll repost with Cc linux-arm-kernel. Thanks, Janusz -- 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/6] [media] gspca core: Fix regressions gspca breaking devices with audio
On Thu, 9 Dec 2010 18:42:36 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: Changeset 35680ba broke several devices: - Sony Playstation Eye (1415:2000); - Gigaware model 25-234 (0c45:628f); - Logitech Messenger Plus (046d:08f6). Probably more devices were broken by this change. What happens is that several devices don't need to save some bandwidth for audio. Also, as pointed by Hans de Goede hdego...@redhat.com, the logic that implements the bandwidth reservation for audio is broken, since it will reduce the alt number twice, on devices with audio. So, let's just revert the broken logic, and think on a better solution for usb 1.1 devices with audio that can't use the maximum packetsize. Acked-by: Jean-Francois Moine moin...@free.fr -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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/6] [media] gspca/sn9c20x: Fix support for mt9m001 (mi1300) sensor
On Thu, 9 Dec 2010 18:42:37 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: Support for mt9m001 (mi1300) is broken: - Table is incomplete; - Only one resolution is currently supported by the driver; - Resolution is incomplete; - it complains about broken JPEG headers. Use the same init found on em28xx driver, and properly report the output format as 8-bits GRAY. Acked-by: Jean-Francois Moine moin...@free.fr -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 5/6] [media] gspca/sonixj: Fix support for sn9c105+0v7660
On Thu, 9 Dec 2010 18:42:38 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: This bug were very tricky to discover. Basically, replying the webcam initialization sequence, after the capture is running make it works. After several researches, I discovered that the sensor were in powerdown mode, when the init sequence was sent. As result, the sensor were never initialized. The right fix would be to map the cases where the powerdown logic is inverted, and add it at some per-device init table. While we don't have it at sonixj, just add a variable to the bridge_init (where the sensor is also initialized), properly handling the case where the logic is not inverted for this specific device. Hi Mauro, I looked again at the USB traces I have with this sensor, and a problem was raised every time I found a webcam with the opposite setting of the powerdown mode. The last webcams I fixed were the Microsoft's VX1000 and VX3000 were the power mode is inverted. Indeed, this change broke most of the other ov7660 based webcams. So, the correct patch is to define the power mode in the device table. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
[RESEND] [PATCH 0/2] OMAP1: amsdelta: reserve memory for videobuf_contig
Since there were no request for changes, I'm resending the set, this time Cc linux-arm-kernel. Sunday 05 December 2010 19:29:05 Janusz Krzysztofik wrote: Latest developements seem to allow for reserving a block of memory on boot to be used as a device dedicated dma coherent memory. This may be required for videobuf_config based video drivers avoid problems with allocating dma coherent memory after system memory gets fragmented. This set extends the OMAP1 camera resource initialization code with a function that can be used for reserving a block of memory early, then declared as the camera device dedicated dma coherent memory. An example use case is provided for Amstrad Delta camera. arch/arm/mach-omap1/board-ams-delta.c | 12 +- arch/arm/mach-omap1/devices.c | 36 ++ arch/arm/mach-omap1/include/mach/camera.h |1 3 files changed, 48 insertions(+), 1 deletion(-) Thanks, Janusz -- 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
[RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
OMAP1 camera driver, when starting up in its videobuf_contig mode, may have
problems with allocating dma coherent memory after system memory gets
fragmented if there is no dedicated memory declared as a dma coherent memory
block associated with the device. To solve this issue, allow for removing a
block of memory from system memory early on boot, then, if reserved this way,
declare it as the device dedicated dma coherent memory.
An example use case on Amstrad Delta will be provided with patch 2/2.
Created and tested against linux-2.6.37-rc4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/devices.c | 36 ++
arch/arm/mach-omap1/include/mach/camera.h |1
2 files changed, 37 insertions(+)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c.orig 2010-12-04
18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c 2010-12-04
22:22:13.0 +0100
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/memblock.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -222,13 +223,48 @@ static struct platform_device omap1_came
.resource = omap1_camera_resources,
};
+static phys_addr_t omap1_camera_phys_mempool_base;
+static phys_addr_t omap1_camera_phys_mempool_size;
+
+void __init omap1_camera_reserve(phys_addr_t size)
+{
+ phys_addr_t paddr;
+
+ if (!size)
+ return;
+
+ paddr = memblock_alloc(size, SZ_1M);
+
+ if (!paddr) {
+ pr_err(%s: failed to reserve %x bytes\n, __func__, size);
+ return;
+ }
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
+
+ omap1_camera_phys_mempool_base = paddr;
+ omap1_camera_phys_mempool_size = size;
+}
+
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr, size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
+ pr_info(%s: reserved %d bytes camera buffer memory\n,
+ __func__, size);
+ else
+ pr_warn(%s: cannot reserve camera buffer memory\n,
+ __func__);
+ }
+
ret = platform_device_register(dev);
if (ret)
dev_err(dev-dev, unable to register device: %d\n, ret);
--- linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h.orig
2010-12-04 18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h 2010-12-04
22:26:23.0 +0100
@@ -3,6 +3,7 @@
#include media/omap1_camera.h
+void omap1_camera_reserve(phys_addr_t);
void omap1_camera_init(void *);
static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP1: Amstrad Delta: reserve memory for camera
Patch 1/2 from this set provides a possibility to reserve a block of memory
for use as the OMAP1 camera dedicated dma coherent memory. Use this
functionality to avoid the camera driver switching form videobuf_contig mode
to less efficient videobuf_sg mode in case of dma coherent memory allocation
failure after system memory gets fragmented.
Created and tested against linux-2.6.27-rc4 on top of patch 1/2.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c.orig 2010-12-04
18:05:25.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c 2010-12-04
22:19:39.0 +0100
@@ -262,6 +262,16 @@ static struct omap1_cam_platform_data am
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+void __init amsdelta_reserve(void)
+{
+#if defined(CONFIG_VIDEO_OMAP1) || defined(CONFIG_VIDEO_OMAP1_MODULE)
+ omap1_camera_reserve(PAGE_SIZE get_order(352 * 288 * 2 *
+ OMAP1_CAMERA_MIN_BUF_COUNT(OMAP1_CAM_DMA_CONTIG)));
+#endif
+
+ omap_reserve();
+}
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
@@ -366,7 +376,7 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (De
/* Maintainer: Jonathan McDowell nood...@earth.li */
.boot_params= 0x1100,
.map_io = ams_delta_map_io,
- .reserve= omap_reserve,
+ .reserve= amsdelta_reserve,
.init_irq = ams_delta_init_irq,
.init_machine = ams_delta_init,
.timer = omap_timer,
--
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: Old patches sent via the Mailing list
Pazartesi 18 Ekim 2010 günü (saat 00:20:31) Mauro Carvalho Chehab şunları yazmıştı: Hi, Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules http://patchwork.kernel.org/patch/107147 Manu This was first spotted by me in February 2010 in this list. Then several people in this list spotted that the modules were missing MODULE_DEVICE_TABLE. Well I thought that it should already be merged during the last 10 months but I'm surprised to see that it's not. Note that without this patch those drivers are not automatically loaded by udev so all other efforts of improving the mantis stuff stays insignificant for end-users. Can this be fixed ASAP? Thanks, --- Ozan Çağlayan TUBITAK/UEKAE - Pardus Linux http://www.pardus.org.tr/eng -- 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: Old patches sent via the Mailing list
Ozan Çağlayan o...@pardus.org.tr writes: Pazartesi 18 Ekim 2010 günü (saat 00:20:31) Mauro Carvalho Chehab şunları yazmıştı: Hi, Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules http://patchwork.kernel.org/patch/107147 Manu This was first spotted by me in February 2010 in this list. Then several people in this list spotted that the modules were missing MODULE_DEVICE_TABLE. Well I thought that it should already be merged during the last 10 months but I'm surprised to see that it's not. Note that without this patch those drivers are not automatically loaded by udev so all other efforts of improving the mantis stuff stays insignificant for end-users. well, the excellent Debian kernel team actually accepted this patch when adding the backported mantis driver to their 2.6.32 kernel, so at least Debian end users do get auto loading: bj...@nemi:~$ modinfo mantis filename: /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/mantis/mantis.ko license:GPL author: Manu Abraham description:MANTIS driver alias: pci:v1822d4E35sv1822sd0024bc*sc*i* alias: pci:v1822d4E35sv153Bsd1178bc*sc*i* alias: pci:v1822d4E35sv1AE4sd0002bc*sc*i* alias: pci:v1822d4E35sv1822sd0043bc*sc*i* alias: pci:v1822d4E35sv1822sd0008bc*sc*i* alias: pci:v1822d4E35sv153Bsd1179bc*sc*i* alias: pci:v1822d4E35sv1AE4sd0003bc*sc*i* alias: pci:v1822d4E35sv1AE4sd0001bc*sc*i* alias: pci:v1822d4E35sv1822sd0031bc*sc*i* alias: pci:v1822d4E35sv1822sd0014bc*sc*i* alias: pci:v1822d4E35sv1822sd0016bc*sc*i* depends: mantis_core,stv0299,i2c-core,stb0899,zl10353,tda10023,tda10021,stb6100,mb86a16,lnbp21,tda665x vermagic: 2.6.32-5-amd64 SMP mod_unload modversions parm: verbose:verbose startup messages, default is 1 (yes) (int) bj...@nemi:~$ dpkg -S /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/mantis/mantis.ko linux-image-2.6.32-5-amd64: /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/mantis/mantis.ko bj...@nemi:~$ apt-cache policy linux-image-2.6.32-5-amd64 linux-image-2.6.32-5-amd64: Installed: 2.6.32-28 Candidate: 2.6.32-28 Version table: *** 2.6.32-28 0 990 http://ftp.no.debian.org/debian/ squeeze/main amd64 Packages 600 http://ftp.no.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status (Note that the extensive depends shows that it's still missing one of the other critical patches) Can this be fixed ASAP? At least it's now queued for 2.6.38: bj...@canardo:/usr/local/src/git/linux-2.6$ git shortlog origin..media_tree/staging/for_v2.6.38 drivers/media/dvb/mantis/ Ben Hutchings (1): [media] Mantis: Rename gpio_set_bits to mantis_gpio_set_bits Bjørn Mork (1): [media] Mantis: use dvb_attach to avoid double dereferencing on module removal David Härdeman (1): [media] ir-core: make struct rc_dev the primary interface Manu Abraham (1): [media] Mantis, hopper: use MODULE_DEVICE_TABLE Marko Ristola (1): [media] Mantis: append tasklet maintenance for DVB stream delivery Mauro Carvalho Chehab (4): [media] rc: rename the remaining things to rc_core [media] rc: Rename remote controller type to rc_type instead of ir_type [media] rc: Name RC keymap tables as rc_map_table [media] rc: use rc_map_ prefix for all rc map tables And I will submit it to stable as soon as it's in Linus' tree, unless someone beats me to it... Bjørn -- 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] zoran: bit-wise vs logical and
zr-frame_num is a counter and was intended here instead of .
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/zoran/zoran_device.c
b/drivers/media/video/zoran/zoran_device.c
index b02007e..e8a2784 100644
--- a/drivers/media/video/zoran/zoran_device.c
+++ b/drivers/media/video/zoran/zoran_device.c
@@ -1523,7 +1523,7 @@ zoran_irq (int irq,
zr-JPEG_missed 25 ||
zr-JPEG_error == 1 ||
((zr-codec_mode == BUZ_MODE_MOTION_DECOMPRESS)
-(zr-frame_num (zr-JPEG_missed
zr-jpg_settings.field_per_buff {
+(zr-frame_num (zr-JPEG_missed
zr-jpg_settings.field_per_buff {
error_handler(zr, astat, stat);
}
--
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
[RESEND][PATCH for stable 2.6.36 REGRESSION] cx25840: Prevent device probe failure due to volume control ERANGE error]
Resending, since this didn't appear to make its way into in 2.6.36.2.
This patch fixes a regression that breaks analog video and audio on
boards supported by the ivtv, pvrusb2, cx231xx, and cx23885 drivers.
The regression also breaks IR on boards supported by the cx23885
driver.
Regards,
Andy
The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values. Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: Andy Walls awa...@md.metrocast.net
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: sta...@kernel.org
---
drivers/media/video/cx25840/cx25840-core.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-core.c
b/drivers/media/video/cx25840/cx25840-core.c
index f5a3e74..b9a2f18 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1991,8 +1991,23 @@ static int cx25840_probe(struct i2c_client *client,
v4l2_ctrl_new_std(state-hdl, cx25840_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
if (!is_cx2583x(state)) {
- default_volume = 228 - cx25840_read(client, 0x8d4);
- default_volume = ((default_volume / 2) + 23) 9;
+ default_volume = cx25840_read(client, 0x8d4);
+ /*
+* Enforce the legacy PVR-350/MSP3400 to PVR-150/CX25843 volume
+* scale mapping limits to avoid -ERANGE errors when
+* initializing the volume control
+*/
+ if (default_volume 228) {
+ /* Bottom out at -96 dB, v4l2 vol range 0x2e00-0x2fff */
+ default_volume = 228;
+ cx25840_write(client, 0x8d4, 228);
+ }
+ else if (default_volume 20) {
+ /* Top out at + 8 dB, v4l2 vol range 0xfe00-0x */
+ default_volume = 20;
+ cx25840_write(client, 0x8d4, 20);
+ }
+ default_volume = (((228 - default_volume) 1) + 23) 9;
state-volume = v4l2_ctrl_new_std(state-hdl,
cx25840_audio_ctrl_ops, V4L2_CID_AUDIO_VOLUME,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] bttv: call mutex_init() on newly allocated lock
On Fri, Dec 10, 2010 at 10:20:30AM +0300, Sergej Pupykin wrote: Hi, it looks better. Now only 3 oopses. Heh. Yeah. Looking at it now, I can see why my patch was wrong. That mutex is supposed to get initialized in videobuf_queue_sg_init(). But we also can't use the lock until after it's initialized. This bug was introduced in: commit c37db91fd0d42d27141b6c49b768070df29e1c5e Author: Mauro Carvalho Chehab mche...@redhat.com Date: Wed Sep 15 08:18:31 2010 -0300 V4L/DVB: bttv: fix driver lock and remove explicit calls to BKL Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com I'm taking off for the weekend, so I won't be able to look at this more until Monday. See you then. :) regards, dan carpenter -- 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: Old patches sent via the Mailing list
Cuma 10 Aralık 2010 günü (saat 14:38:21) Bjørn Mork şunları yazmıştı: At least it's now queued for 2.6.38: Thanks :) --- Ozan Çağlayan TUBITAK/UEKAE - Pardus Linux http://www.pardus.org.tr/eng -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 6/6] davinci vpbe: Build infrastructure for VPBE driver
Sergei, Thank you for your comments. Will send a corrected pacth. -Manju On Thu, Dec 09, 2010 at 17:42:00, Sergei Shtylyov wrote: Hello. On 02-12-2010 15:39, Manjunath Hadli wrote: This patch adds the build infra-structure for Davinci VPBE dislay driver Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Signed-off-by: Muralidharan Karicherim-kariche...@ti.com [...] diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..dab32d5 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE +tristate DM644X VPBE HW module +select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG Please use tabs uniformly to indent. diff --git a/drivers/media/video/davinci/davinci_vpbe_readme.txt b/drivers/media/video/davinci/davinci_vpbe_readme.txt new file mode 100644 index 000..e7aabba --- /dev/null +++ b/drivers/media/video/davinci/davinci_vpbe_readme.txt @@ -0,0 +1,100 @@ + +VPBE V4L2 driver design + + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of following (in the same order as the list under file ^ the missing. + partitioning):- + + 1. V4L2 display driver +Implements video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up venc, osd and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the venc or external sub devices. It also provides +a device object to access the services from osd sub device +using sub device ops. The connection of external encoders to venc LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connetected to an external encoder, vpbe controller is also responsible +for setting up the interface between venc and external encoders based on +board specific settings (specified in board-xxx-evm.c). This + allowes Only allows. +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in venc for a specific display resolution.As + of this Space missing after period. +patch series, the interconnection and enabling ans setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. Venc sub device +Responsible for setting outputs provides Provided? through internal dacs and also DACs. +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the venc. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry ( i.e add the LogicPD Space not needed after (. +output name to board-xxx-evm.c). A table of timings for various LCDs +supported cab Can? be maintained in the board specific setup file to support +various LCD displays. + + 4. osd sub device OSD? What doesn it mean BTW? +Osd sub device implements all osd layer management and hardware specific +features. In the legacy drivers (LSPxxx), the hardware specific features +are configured
[PATCH v18 1/2] MFD: WL1273 FM Radio: MFD driver for the FM radio.
This is the core of the WL1273 FM radio driver, it connects
the two child modules. The two child drivers are
drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.
The radio-wl1273 driver implements the V4L2 interface and communicates
with the device. The ALSA codec offers digital audio, without it only
analog audio is available.
Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
drivers/mfd/Kconfig | 10 ++
drivers/mfd/Makefile|1 +
drivers/mfd/wl1273-core.c | 148
include/linux/mfd/wl1273-core.h | 288 +++
4 files changed, 447 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3a1493b..05ccab6 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -606,6 +606,16 @@ config MFD_VX855
VIA VX855/VX875 south bridge. You will need to enable the vx855_spi
and/or vx855_gpio drivers for this to do anything useful.
+config MFD_WL1273_CORE
+ tristate
+ depends on I2C
+ select MFD_CORE
+ default n
+ help
+ This is the core driver for the TI WL1273 FM radio. This MFD
+ driver connects the radio-wl1273 V4L2 module and the wl1273
+ audio codec.
+
endif # MFD_SUPPORT
menu Multimedia Capabilities Port drivers
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f54b365..ae2f915 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -81,3 +81,4 @@ obj-$(CONFIG_MFD_JANZ_CMODIO) += janz-cmodio.o
obj-$(CONFIG_MFD_JZ4740_ADC) += jz4740-adc.o
obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855)+= vx855.o
+obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..d2ecc24
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,148 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Author: Matti Aaltonen matti.j.aalto...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/mfd/wl1273-core.h
+#include linux/slab.h
+
+#define DRIVER_DESC WL1273 FM Radio Core
+
+static struct i2c_device_id wl1273_driver_id_table[] = {
+ { WL1273_FM_DRIVER_NAME, 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, wl1273_driver_id_table);
+
+static int wl1273_core_remove(struct i2c_client *client)
+{
+ struct wl1273_core *core = i2c_get_clientdata(client);
+
+ dev_dbg(client-dev, %s\n, __func__);
+
+ mfd_remove_devices(client-dev);
+ i2c_set_clientdata(client, NULL);
+ kfree(core);
+
+ return 0;
+}
+
+static int __devinit wl1273_core_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct wl1273_fm_platform_data *pdata = client-dev.platform_data;
+ struct wl1273_core *core;
+ struct mfd_cell *cell;
+ int children = 0;
+ int r = 0;
+
+ dev_dbg(client-dev, %s\n, __func__);
+
+ if (!pdata) {
+ dev_err(client-dev, No platform data.\n);
+ return -EINVAL;
+ }
+
+ if (!(pdata-children WL1273_RADIO_CHILD)) {
+ dev_err(client-dev, Cannot function without radio child.\n);
+ return -EINVAL;
+ }
+
+ core = kzalloc(sizeof(*core), GFP_KERNEL);
+ if (!core)
+ return -ENOMEM;
+
+ core-pdata = pdata;
+ core-client = client;
+ mutex_init(core-lock);
+
+ i2c_set_clientdata(client, core);
+
+ dev_dbg(client-dev, %s: Have V4L2.\n, __func__);
+
+ cell = core-cells[children];
+ cell-name = wl1273_fm_radio;
+ cell-platform_data = core;
+ cell-data_size = sizeof(core);
+ children++;
+
+ if (pdata-children WL1273_CODEC_CHILD) {
+ cell = core-cells[children];
+
+ dev_dbg(client-dev, %s: Have codec.\n, __func__);
+ cell-name = wl1273-codec;
+ cell-platform_data = core;
+ cell-data_size = sizeof(core);
+ children++;
+ }
+
+ dev_dbg(client-dev, %s: number of children: %d.\n,
+
[PATCH v18 0/2] WL1273 FM Radio driver...
Hi. Thank you for the comments and the conditional ACK. On Thu, 2010-12-09 at 15:17 +0100, ext Samuel Ortiz wrote: with the device. The ALSA codec offers digital audio, without it only analog audio is available. The driver looks much better now. If that goes through Mauro's tree, please add my: Acked-by: Samuel Ortiz sa...@linux.intel.com OK. \ No newline at end of file Please add a new line here. Added... Cheers, Matti Matti J. Aaltonen (2): MFD: WL1273 FM Radio: MFD driver for the FM radio. V4L2: WL1273 FM Radio: TI WL1273 FM radio driver drivers/media/radio/Kconfig| 16 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-wl1273.c | 2331 drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile |1 + drivers/mfd/wl1273-core.c | 148 +++ include/linux/mfd/wl1273-core.h| 288 + 7 files changed, 2795 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-wl1273.c create mode 100644 drivers/mfd/wl1273-core.c create mode 100644 include/linux/mfd/wl1273-core.h -- 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 v18 1/2] MFD: WL1273 FM Radio: MFD driver for the FM radio.
Hi Matti, On Fri, Dec 10, 2010 at 04:41:33PM +0200, Matti J. Aaltonen wrote: This is the core of the WL1273 FM radio driver, it connects the two child modules. The two child drivers are drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c. The radio-wl1273 driver implements the V4L2 interface and communicates with the device. The ALSA codec offers digital audio, without it only analog audio is available. Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Mark and others! Mark Brown wrote: On Tue, Dec 07, 2010 at 07:11:39PM +0100, Hans Verkuil wrote: Ah, now I understand what you mean. Would 'activated' be better than 'active'? Better, yes, though it still sounds a bit like something should be actively (IYSWIM) happening. In the absence of better ideas I could go with this. Activated, to me, sounds like that it has happened as a consequence of something, and primarily not as a result of a user request. This flag is also set using MEDIA_IOC_SETUP_LINK ioctl and setting the flags field would be something like this: media_link_desc.flags |= MEDIA_LINK_ACTIVATED; I'd prefer ACTIVE over ACTIVATED, since this may also be set (and is mostly set) by the user. But reading this discussion, ACTIVE has not received unanimous approval either... :\ Or perhaps just say: the link 'is on' or the link 'is switched on'? So: ...LINK_SWITCHED_ON (sorry, forgot what the prefix is). Actually, I think 'switched on' is a pretty good description of what is going on in the hardware. I prefer activated, this makes me think of power. Bear in mind that for most audio the power is a big portion of the control - either the audio is analogue or it looks like it. What would you think about ENABLED? It's simple, quite generic and thus doesn't explicitly suggest what is the exact effect it has on the level of the underlying device. I don't completely like it myself since it would be best to have an adjective (like active) but there's none for the word enable, so it bears the same issues than activated. Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
dvb-apps: update DVB-T intial tuning files for Finland (fi-*)
Moi Christoph, Updates all Finnish channels as today. I accidentally removed first fi-Smedsbole file since that was not generated by my scripts. Actually it is for the autonomy island named Åland [1] between Finland and Sweden. They have even own top level domain - ax. I think correct name for that is ax-Smedsbole instead of fi. [1] http://en.wikipedia.org/wiki/%C3%85land_Islands Antti -- http://palosaari.fi/ changeset: 1407:d38a19ce8521 tag: tip user:Antti Palosaari cr...@iki.fi date:Fri Dec 10 18:32:39 2010 +0200 summary: dvb-apps: update DVB-T intial tuning files for Finland (fi-*) diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Aanekoski --- a/util/scan/dvb-t/fi-Aanekoski Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Aanekoski Fri Dec 10 18:32:39 2010 +0200 @@ -2,5 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 61000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 73000 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 82600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 53000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 68200 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Aanekoski_Konginkangas --- a/util/scan/dvb-t/fi-Aanekoski_Konginkangas Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Aanekoski_Konginkangas Fri Dec 10 18:32:39 2010 +0200 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 69000 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 60200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 76200 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Enontekio_Ahovaara_Raattama --- a/util/scan/dvb-t/fi-Enontekio_Ahovaara_RaattamaSun Nov 28 21:24:42 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 + @@ -1,4 +0,0 @@ -# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 57000 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Enontekio_Raattama --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/fi-Enontekio_Raattama Fri Dec 10 18:32:39 2010 +0200 @@ -0,0 +1,4 @@ +# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 57000 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Hameenkyro_Kyroskoski --- a/util/scan/dvb-t/fi-Hameenkyro_Kyroskoski Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Hameenkyro_Kyroskoski Fri Dec 10 18:32:39 2010 +0200 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 49000 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 77000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 77800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Haukela --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/fi-HaukelaFri Dec 10 18:32:39 2010 +0200 @@ -0,0 +1,5 @@ +# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 62600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 58600 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Hossa --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/fi-Hossa Fri Dec 10 18:32:39 2010 +0200 @@ -0,0 +1,4 @@ +# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 67400 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Hyrynsalmi_Paljakka --- a/util/scan/dvb-t/fi-Hyrynsalmi_PaljakkaSun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Hyrynsalmi_PaljakkaFri Dec 10 18:32:39 2010 +0200 @@ -2,3 +2,4 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 48200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 52200 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 67400 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Jamsa_Kaipola --- a/util/scan/dvb-t/fi-Jamsa_Kaipola Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Jamsa_Kaipola Fri Dec 10 18:32:39 2010 +0200 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 60200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 69800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 53800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr, size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
For OMAP1, which is ARMv5 or lower, device memory becomes 'uncacheable,
unbufferable' which is luckily what is used for the DMA coherent
memory on those platforms - so no technical problem here.
However, on ARMv6 and later, ioremapped memory is device memory, which
has different ordering wrt normal memory mappings, and may appear on
different busses on the CPU's interface. So, this is something I don't
encourage as it's unclear that the hardware will work.
Essentially, dma_declare_coherent_memory() on ARM with main SDRAM should
be viewed as a 'it might work, it might not, and it might stop working
in the future' kind of interface. In other words, there is no guarantee
that this kind of thing will be supported in the future.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] davinci vpbe: dm6446 v4l2 driver
Hans Verkuil hverk...@xs4all.nl writes: version4 : addressed Hans's comments on: 1. replaced mutex_lock_interruptible() with mutex_lock() 2. replaced ntsc and pal macros with new equivalent macros 3. simplifying the code in the if-else condition 4. minor code corrections For the whole patch series: Acked-by: Hans Verkuil hverk...@xs4all.nl Hans, can you take patches 1-4 and 6 through the linux-media tree? I will queue the patch 5 (the only mach-davinci change) in davinci git for 2.6.38. Manjunath, can rebase patch 5 on top of current davinci-next (or davinci master) as this patch doesn't currently apply there. Thanks, Kevin Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: Build infrastructure for VPBE driver arch/arm/mach-davinci/board-dm644x-evm.c | 79 +- arch/arm/mach-davinci/dm644x.c | 164 ++- arch/arm/mach-davinci/include/mach/dm644x.h|4 + drivers/media/video/davinci/Kconfig| 22 + drivers/media/video/davinci/Makefile |2 + .../media/video/davinci/davinci_vpbe_readme.txt| 100 + drivers/media/video/davinci/vpbe.c | 837 drivers/media/video/davinci/vpbe_display.c | 2099 drivers/media/video/davinci/vpbe_osd.c | 1211 +++ drivers/media/video/davinci/vpbe_osd_regs.h| 389 drivers/media/video/davinci/vpbe_venc.c| 574 ++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 ++ include/media/davinci/vpbe.h | 186 ++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 include/media/davinci/vpbe_types.h | 93 + include/media/davinci/vpbe_venc.h | 38 + 17 files changed, 6511 insertions(+), 19 deletions(-) create mode 100644 drivers/media/video/davinci/davinci_vpbe_readme.txt create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- 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: [stable] [RESEND][PATCH for stable 2.6.36 REGRESSION] cx25840: Prevent device probe failure due to volume control ERANGE error]
On Fri, Dec 10, 2010 at 08:19:57AM -0500, Andy Walls wrote: Resending, since this didn't appear to make its way into in 2.6.36.2. That's because it's not in Linus's tree, right? I have to wait for that to happen before I can add it to a stable tree. thanks, greg k-h -- 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] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Dec 10 19:00:06 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 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: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK 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: [stable] [RESEND][PATCH for stable 2.6.36 REGRESSION] cx25840: Prevent device probe failure due to volume control ERANGE error]
On Fri, 2010-12-10 at 10:16 -0800, Greg KH wrote: On Fri, Dec 10, 2010 at 08:19:57AM -0500, Andy Walls wrote: Resending, since this didn't appear to make its way into in 2.6.36.2. That's because it's not in Linus's tree, right? I have to wait for that to happen before I can add it to a stable tree. Greg, I wasn't aware of that constraint in the process, but it makes sense to me. Mauro, My understanding is that the patch has to be in one of your trees first, and then tested in linux-next for a reasonable length of time, before Linus will pull it into his tree. Could you please expedite handling of this patch for 2.6.37: https://patchwork.kernel.org/patch/376612/ so that the regression can be fixed in 2.6.36? Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr, size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
For OMAP1, which is ARMv5 or lower, device memory becomes 'uncacheable,
unbufferable' which is luckily what is used for the DMA coherent
memory on those platforms - so no technical problem here.
However, on ARMv6 and later, ioremapped memory is device memory, which
has different ordering wrt normal memory mappings, and may appear on
different busses on the CPU's interface. So, this is something I don't
encourage as it's unclear that the hardware will work.
Essentially, dma_declare_coherent_memory() on ARM with main SDRAM should
be viewed as a 'it might work, it might not, and it might stop working
in the future' kind of interface. In other words, there is no guarantee
that this kind of thing will be supported in the future.
I was affraid of an unswer of this kind. I'm not capable of comming out with
any better, alternative solutions. Any hints other than giving up with that
old videobuf-contig, coherent memory based interface? Or can we agree on
that 'luckily uncacheable, unbufferable, SDRAM based DMA coherent memory'
solution for now?
Thanks,
Janusz
--
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: PCI: make pci_restore_state return void
On Tue, 30 Nov 2010 17:43:26 -0600 Jon Mason jon.ma...@exar.com wrote: pci_restore_state only ever returns 0, thus there is no benefit in having it return any value. Also, a large majority of the callers do not check the return code of pci_restore_state. Make the pci_restore_state a void return and avoid the overhead. Signed-off-by: Jon Mason jon.ma...@exar.com --- Applied to linux-next, thanks. -- Jesse Barnes, Intel Open Source Technology 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
budget_av and high load
Hello everybody on the list, I have a KNC-1 DVB-S card running under kernel 2.6.36 and mythtv. I experience high load values in top like mentioned ages ago in this thread: http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026509.html. My card has no CI-Module installed and the high load was CI-Module related, so I decided to give it a try and completely disable ciintf_init() in the kernel module which helped a lot. Load decreased by 50-80%. So I decided to add a module parameter to disable ciintf_init() on demand. Here is the diff: 65,69d64 int budget_init_ci=1; module_param_named(init_ci, budget_init_ci, int, 0644); MODULE_PARM_DESC(init_ci, Turn on(1)/off(0) ci initializing (default:on).); 1519,1520c1514 if (budget_init_ci) ciintf_init(budget_av); --- ciintf_init(budget_av); I don't know if this is useful at all so please be patient with me. If you have comments or anything else, please do answer to my mail-address too, as I'm not subscribed to the list. Kind regards, Andreas-- 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: [OpenKinect] Kinect sensor and Linux kernel driver.
(Resending with reply-all, sorry for that) Hi, a first, very simplified, linux kernel driver for the Kinect sensor device is now available, so you now can use it as a ridiculously expensive webcam with any v4l2 application. Good work! Here are my thoughts on the kernel driver: As you can see this driver is just some advanced copypaste from libfreenect, plus reducing the packets scan routine to the bare minimum. Taking some code from libfreenect should be OK as it comes under GPLv2 (dual-licensed with an Apache license) but let me know if you think there could be any issues. This is actually precisely the reason why I made sure we had GPLv2 as an option :) Now the hard part begins, here's a loose TODO-list: - Discuss the fragmentation problem: * the webcam kernel driver and the libusb backend of libfreenect are not going to conflict each other in practice, but code duplication could be avoided to some degree; we could start listing the advantages and disadvantages of a v4l2 backend opposed to a libusb backend for video data in libfreenct (don't think in terms of userspace/kernelspace for now). I don't think we should exclusively move over Kinect support to current standard kernel interfaces (v4l, input, ALSA...), as they are too generic and people like to experiment with and use the features of the Kinect to their fullest. However, kernel drivers do have their advantages, and of course people also want to use the Kinect as a standard input device where it makes sense. I think the best solution would be to have a kernel driver that implements the basics of the kinect (v4l RGB video for webcam use, mainly, and possibly a simple depth feed), as well as provides the streaming layer for libfreenect to use (iso packet header parsing and frame reassembly, but no data processing). Libfreenect would hook into this as a backend (the current abstraction is at the USB level but this could be changed) and therefore get the benefits of kernel-side iso handling and streaming (probably 10x less context switching and more reliable performance for loaded systems) while still letting the lib handle configuration and letting us experiment with the different modes and formats without messing with the kernel code. And without libfreenect, users get to use the Kinect as a regular webcam. I'm not sure what this power kernel interface would look like, but it could be v4l2 as long as we can make sure we can expose all the Kinect specifics at a lower level (basically weird/compressed/packed frame formats, the timestamps, and raw control commands/responses). Also, I haven't checked, but I assume v4l2 supports select()/poll() for frames (this is critical in order to interoperate with the way libusb does things, for our other subdevices). Another advantage of not exposing all the Kinect functionality at high level via v4l2 methods is that we don't have to duplicate that code in the kernel (otherwise libfreenect would just become one huge switch at the high level to select between doing most everything in the kernel and doing most everything in userspace, and then what's the point). The goal would be a thin kernel driver in libfreenect mode, plus a thick but basic mode for general compatibility with other v4l apps. * Would exposing the accelerometer as an input device make sense too? The only reason for that is to use the data in already existing applications. And what about led and motor? I'm not sure we need an accelerometer kernel driver, but if someone has a use case for accelerometer data delivered via evdev with existing code it could be done. There's not much point in making libfreenect talk to it though, for that subdevice we should just ask libusb to unbind the kernel driver if one gets written. - Decide if we want two separate video nodes, or a combined RGB-D data stream coming from a single video device node. (I haven't even looked at the synchronization logic yet). A combined video stream is hard because the sources aren't framelocked, not to mention the video streams aren't aligned (and as far as I can tell, no, the Kinect's standard firmware cannot either of these, even though its chipset can). I think figuring out how to align things both temporally and spatially belongs squarely in userspace, so the Kinect should show up as two v4l2 devices: one for video, and one for depth. This also lets us play with RGB/IR and depth parameters fully independently (they really are two separate streams) and makes perfect logical sense given how the Kinect hardware is implemented. Audio is still up in the air, but an ALSA driver would of course make sense for general microphone use; once we figure out what we want to do with audio this will become clearer. I suspect that getting echo cancellation to work at all will be near impossible without a hard realtime framework extending outside the kernel (i.e. JACK), and that won't play
Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ?
Hi, I wonder that a index should be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case. If it isn't needed, should driver return virtual address gotten from application on the fly with the VIDIOC_DQBUF ioctl ? Best regards, Jonghun Han, -- 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
How to control streaming in non-periodic system ?
Hi,
I'm looking for a general solution in camera preview application.
When I use the following sequence, there is no problem in normal case.
Normally application sleeps in poll and then will be waked up by Camera VSYNC.
while (1) {
poll
DQBUF
memcpy to FB
QBUF
}
But sometimes there is non-periodic long delay more than 1sec in application.
So before calling poll some buffers has been already passed to outgoing queue.
So in a single time quantum(schedule) many memcpy operations are done
on FB like:
poll - DQBUF - memcpy - QBUF - poll(no sleep) - DQBUF - memcpy...
So preview isn't unnatural owing to memcpy without delay.
In that case what is a general solution ?
In my opinion frame drop can be a solution.
So now I changed the sequence as below.
open device with non-block flag.
while (1) {
while (ret != -EAGAIN) {
idx = dp_idx;
ret = DQBUF(dq_idx);
}
if (idx -1) {
poll
DQBUF(idx)
}
memcpy to FB
QBUF
}
Best regards,
Jonghun Han,
--
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
