[PATCH 01/10 v2] ARM: Samsung: Add FIMC register and platform definitions
FIMC device is a camera interface embedded in S3C/S5P Samsung SOC series.
It supports ITU-R BT.601/656 and MIPI-CSI2 standards, memory to memory
operations, color conversion, resizing and rotation.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/plat-samsung/include/plat/fimc.h | 31 ++
arch/arm/plat-samsung/include/plat/regs-fimc.h | 361
2 files changed, 392 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-samsung/include/plat/fimc.h
create mode 100644 arch/arm/plat-samsung/include/plat/regs-fimc.h
diff --git a/arch/arm/plat-samsung/include/plat/fimc.h
b/arch/arm/plat-samsung/include/plat/fimc.h
new file mode 100644
index 000..be1e853
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/fimc.h
@@ -0,0 +1,31 @@
+/* linux/arch/arm/plat-samsung/include/plat/fimc.h
+ *
+ * Platform header file for FIMC driver
+ *
+ * Copyright (c) 2010 Samsung Electronics
+ *
+ * Sylwester Nawrocki, s.nawro...@samsung.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.
+ */
+
+#ifndef FIMC_H_
+#define FIMC_H_
+
+#include linux/device.h
+#include linux/platform_device.h
+
+
+#define FIMC_MAX_FIFO_TARGETS 1
+#define FIMC_LCD_FIFO_TARGET 0
+
+struct s3c_fifo_link;
+
+struct samsung_plat_fimc {
+ struct s3c_fifo_link*fifo_targets[FIMC_MAX_FIFO_TARGETS];
+};
+
+#endif /* FIMC_H_ */
+
diff --git a/arch/arm/plat-samsung/include/plat/regs-fimc.h
b/arch/arm/plat-samsung/include/plat/regs-fimc.h
new file mode 100644
index 000..6946a93
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/regs-fimc.h
@@ -0,0 +1,361 @@
+/* arch/arm/plat-s5p/include/plat/regs-fimc.h
+ *
+ * Register definition file for Samsung Camera Interface (FIMC) driver
+ *
+ * Copyright (c) 2010 Samsung Electronics
+ *
+ * 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.
+ */
+
+#ifndef REGS_FIMC_H_
+#define REGS_FIMC_H_
+
+#define S5P_CIOYSA(__x)(0x18 + (__x) * 4)
+#define S5P_CIOCBSA(__x) (0x28 + (__x) * 4)
+#define S5P_CIOCRSA(__x) (0x38 + (__x) * 4)
+
+/* Input source format */
+#define S5P_CISRCFMT 0x00
+/* Window offset */
+#define S5P_CIWDOFST 0x04
+/* Global control */
+#define S5P_CIGCTRL0x08
+/* Window offset 2 */
+#define S5P_CIWDOFST2 0x14
+/* Output DMA Y 1st frame start address */
+#define S5P_CIOYSA10x18
+/* Output DMA Y 2nd frame start address */
+#define S5P_CIOYSA20x1c
+/* Output DMA Y 3rd frame start address */
+#define S5P_CIOYSA30x20
+/* Output DMA Y 4th frame start address */
+#define S5P_CIOYSA40x24
+/* Output DMA Cb 1st frame start address */
+#define S5P_CIOCBSA1 0x28
+/* Output DMA Cb 2nd frame start address */
+#define S5P_CIOCBSA2 0x2c
+/* Output DMA Cb 3rd frame start address */
+#define S5P_CIOCBSA3 0x30
+/* Output DMA Cb 4th frame start address */
+#define S5P_CIOCBSA4 0x34
+/* Output DMA Cr 1st frame start address */
+#define S5P_CIOCRSA1 0x38
+/* Output DMA Cr 2nd frame start address */
+#define S5P_CIOCRSA2 0x3c
+/* Output DMA Cr 3rd frame start address */
+#define S5P_CIOCRSA3 0x40
+/* Output DMA Cr 4th frame start address */
+#define S5P_CIOCRSA4 0x44
+/* Target image format */
+#define S5P_CITRGFMT 0x48
+/* Output DMA control */
+#define S5P_CIOCTRL0x4c
+/* Pre-scaler control 1 */
+#define S5P_CISCPRERATIO 0x50
+/* Pre-scaler control 2 */
+#define S5P_CISCPREDST 0x54
+/* Main scaler control */
+#define S5P_CISCCTRL 0x58
+/* Target area */
+#define S5P_CITAREA0x5c
+/* Status */
+#define S5P_CISTATUS 0x64
+/* Image capture enable command */
+#define S5P_CIIMGCPT 0xc0
+/* Capture sequence */
+#define S5P_CICPTSEQ 0xc4
+/* Image effects */
+#define S5P_CIIMGEFF 0xd0
+/* Y frame start address for input DMA */
+#define S5P_CIIYSA00xd4
+/* Cb frame start address for input DMA */
+#define S5P_CIICBSA0 0xd8
+/* Cr frame start address for input DMA */
[PATCH 03/10 v2] ARM: Samsung: Add platform definitions for local FIMC/FIMD fifo path
From: Marek Szyprowski m.szyprow...@samsung.com
Add a common s3c_fifo_link structure that describes a local path link
between 2 multimedia devices (like FIMC and FrameBuffer).
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/plat-samsung/include/plat/fifo.h | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-samsung/include/plat/fifo.h
diff --git a/arch/arm/plat-samsung/include/plat/fifo.h
b/arch/arm/plat-samsung/include/plat/fifo.h
new file mode 100644
index 000..84d242b
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/fifo.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (c) 2010 Samsung Electronics
+ *
+ * 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.
+ */
+
+#ifndef FIFO_H_
+#define FIFO_H_
+
+#include linux/device.h
+#include media/v4l2-subdev.h
+
+/*
+ * The multimedia devices contained in Samsung S3C/S5P SoC series
+ * like framebuffer, camera interface or tv scaler can transfer data
+ * directly between each other through hardware fifo channels.
+ * s3c_fifo_link data structure is an abstraction for such links,
+ * it allows to define V4L2 device drivers hierarchy according to
+ * the hardware structure. Fifo links are mostly unidirectional, exclusive
+ * data buses. To control data transfer in fifo mode synchronization is
+ * is required between drivers at both ends of the fifo channel
+ * (master_dev, slave_dev). s3c_fifo_link:sub_dev is intended to export
+ * in a consistent way all the functionality of the slave device required
+ * at master device driver to enable transfer through fifo channel.
+ * master_dev and slave_dev is to be setup by the platform code whilst
+ * sub_dev entry will mostly be initlized during slave_dev probe().
+ */
+struct s3c_fifo_link {
+ struct device *master_dev;
+ struct device *slave_dev;
+ struct v4l2_subdev *sub_dev;
+};
+
+#endif /* FIFO_H_ */
+
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] TeVii S470 Tunning Issue (Kernel 2.6.27-21)
Hi Hans, Thanks for your quick feedback. Any other suggestions guys ? . Thanks in advance. Hamza Ferrag. On 13/07/2010 20:57, Hans Houwaard wrote: I don't really know why, but it happens sometimes on my machine with the same card as well. When I have problems, I power off the computer and then restart it again. The card will not properly load or function untill I do. There is probably some hardware lock that needs to be reset by powering off the card. The loading of the firmware sometimes takes a couple of seconds in my machine, it's not very fast. Besides check if the card, which is on a PCI-1x slot, doesn't share an IRQ with the onboard soundcard. That will seriously effect the performance of both the card and the sound. Good luck, Hans Op 13-07-10 20:28, Hamza Ferrag schreef: Hi all, I am trying to install a 'Tevii S470' card from TeVii technology as described here http://linuxtv.org/wiki/index.php/TeVii_S470. My configuration is : - intel x86 platform - Kernel 2.6.27-21 - tevii_ds3000.tar.gz (firmware archive from http://tevii.com/tevii_ds3000.tar.gz ), - s2-liplianin mercurial sources ( from http://mercurial.intuxication.org/hg/s2-liplianin)last changes at 05/29/2010, All work fine i.e drivers/firmware installation after madprobe a right modules. # lsmod Module Size Used by Not tainted cx23885 82416 0 tveeprom 9348 1 cx23885 btcx_risc 1928 1 cx23885 cx2341x 7748 1 cx23885 ir_common 23936 1 cx23885 videobuf_dma_sg 5060 1 cx23885 ir_core 3596 2 cx23885,ir_common v4l2_common 8896 2 cx23885,cx2341x videodev 25376 2 cx23885,v4l2_common videobuf_dvb 2820 1 cx23885 videobuf_core 8388 3 cx23885,videobuf_dma_sg,videobuf_dvb lnbp21 1024 0 dvb_core 54832 2 cx23885,videobuf_dvb ds3000 9668 1 # dmesg Linux video capture interface: v2.00 cx23885 driver version 0.0.2 loaded CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470 [card=15,autodetected] cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card DS3000 chip version: 0.192 attached. DVB: registering new adapter (cx23885[0]) DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... cx23885_dev_checkrevision() Hardware revision = 0xb0 cx23885[0]/0: found at :03:00.0, rev: 2, irq: 11, latency: 0, mmio: 0xdf80 cx23885 :03:00.0: setting latency timer to 64 tun: Universal TUN/TAP device driver, 1.6 A problem appear when tunning card using szap-s2 : # szap-s2 szap-s2 -c /root/channels.conf -x -M 5 -C 89 -l 9750 -S 1 MyCh reading channels from file '/root/channels.conf' zapping to 1 'MyCh': delivery DVB-S2, modulation 8PSK sat 0, frequency 8420 MHz V, symbolrate 2940, coderate 8/9,rolloff 0.35 vpid 0x0286, apid 0x1fff, sid 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... firmware: requesting dvb-fe-ds3000.fw ds3000_firmware_ondemand: Waiting for firmware upload(2)... ds3000_firmware_ondemand: No firmware uploaded (timeout or file not found?) ds3000_tune: Unable initialise the firmware Apparently it can't locate a firmware file, yet : # ls -l /lib/firmware/ -rwxr-xr-x 1 root root 8192 May 3 07:09 dvb-fe-ds3000.fw Any ideas why this happens? Thanks and best regards, Hamza Ferrag ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: [PATCHv6] mx2_camera: Add soc_camera support for i.MX25/i.MX27
Hi,
On Sun, Jul 04, 2010 at 07:55:10AM +0300, Baruch Siach wrote:
This is the soc_camera support developed by Sascha Hauer for the i.MX27. Alan
Carvalho de Assis modified the original driver to get it working on more
recent
kernels. I modified it further to add support for i.MX25. This driver has been
tested on i.MX25 and i.MX27 based platforms.
Signed-off-by: Baruch Siach bar...@tkos.co.il
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Ping?
I'm currently working on a series of some small fixes and tweaks, but first I
want to see the main code getting into mainline.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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
A handful of USB sticks without analog audio
Hi,
This problem has been reported several times,
(see eg.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg10580.html
http://www.mail-archive.com/linux-media@vger.kernel.org/msg00339.html)
and AFAIK concerns a number of people around with the following devices:
{ USB_DEVICE(0xeb1a, 0xe300),
.driver_info = EM2861_BOARD_KWORLD_PVRTV_300U },
{ USB_DEVICE(0xeb1a, 0xe305),
.driver_info = EM2880_BOARD_KWORLD_DVB_305U },
{ USB_DEVICE(0xeb1a, 0xe310),
.driver_info = EM2880_BOARD_KWORLD_DVB_310U },
{ USB_DEVICE(0xeb1a, 0xe320),
.driver_info = EM2880_BOARD_MSI_DIGIVOX_AD_II },
but it seems to persists ever since.
In the (in)famous, 'unofficial' em28xx-new stuff, in which this problem
was solved with a dedicated module, there is this about these devices:
em28xx-audioep.c:
* em28xx alsa driver for devices which are set to vendor specific audio on
interface 1, in that case snd-usb-audio will not attach to the interface and
em28xx-audioep will be needed
Is there any hope that there will be some solution in the official v4l-dvb
tree, and beside analog video, audio will also be supported?
For one of these devices i attach the dmesg from the most recent v4l-dvb tree,
and the output of lsusb -v.
Thanks for any help in advance,
best,
o.cs.
Bus 001 Device 003: ID eb1a:e320 eMPIA Technology, Inc.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0xeb1a eMPIA Technology, Inc.
idProduct 0xe320
bcdDevice1.00
iManufacturer 0
iProduct1 USB 2881 Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 345
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes1
Transfer TypeIsochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes1
Transfer TypeIsochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 1
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes1
Transfer TypeIsochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes1
Transfer Type
[libdvben50221] stack leaks resources on non-MMI session reconnect
The issue was, that LIBDVBEN50221 did not allow a CAM to re-establish
the session holding non-MMI resources if using the lowlevel interface.
The session_number was recorded on open, but not freed on close (which
IMO is an bug in the code, I attach the scaled down hg changeset). With
this change, the SMIT CAM with a showtime card works fine according to
tests so far.
The effect was, that the CAM tried to constantly close and re-open the
session and the LIBDVBEN50221 kept telling it, that the resource is
already allocated to a different session. Additionally this caused the
library to use the _old_ session number in communications with the CAM,
which did not even exist anymore, so caused all writes of CA PMTs to
fail with EINTR.
Stephan
P.S. If there is a better place to report user-space library bugs for
linuxtv, please let me know.
# HG changeset patch
# User Stephan Trebels step...@trebels.com
# Date 1279192697 -3600
# Node ID 12928658e57ea046b35dfab485f23559b3036d42
# Parent 4ba933ff13fbd619be9bdbbf097b8dbfe0fbf679
Correctly free resources when a session is closed. This allows a CAM module to
re-open a session.
diff -r 4ba933ff13fb -r 12928658e57e lib/libdvben50221/en50221_stdcam_llci.c
--- a/lib/libdvben50221/en50221_stdcam_llci.c Sat Jul 03 15:25:16 2010 +0200
+++ b/lib/libdvben50221/en50221_stdcam_llci.c Thu Jul 15 12:18:17 2010 +0100
@@ -374,14 +374,21 @@
} else if (resource_id == EN50221_APP_MMI_RESOURCEID) {
llci-stdcam.mmi_session_number = session_number;
}
+ break;
+ case S_SCALLBACK_REASON_CLOSE:
+ if (resource_id == EN50221_APP_MMI_RESOURCEID) {
+ llci-stdcam.mmi_session_number = -1;
+ } else if (resource_id == EN50221_APP_DATETIME_RESOURCEID) {
+ llci-datetime_session_number = -1;
+ } else if (resource_id == EN50221_APP_AI_RESOURCEID) {
+ llci-stdcam.ai_session_number = -1;
+ } else if (resource_id == EN50221_APP_CA_RESOURCEID) {
+ llci-stdcam.ca_session_number = -1;
+ } else if (resource_id == EN50221_APP_MMI_RESOURCEID) {
+ llci-stdcam.mmi_session_number = -1;
+ }
break;
-case S_SCALLBACK_REASON_CLOSE:
-if (resource_id == EN50221_APP_MMI_RESOURCEID) {
-llci-stdcam.mmi_session_number = -1;
-}
-
-break;
}
return 0;
}
signature.asc
Description: This is a digitally signed message part
RE: [RFC/PATCH 02/10] media: Media device
Hi Laurent,
Very minor comment below.
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Wednesday, July 14, 2010 8:30 AM
To: linux-media@vger.kernel.org
Cc: sakari.ai...@maxwell.research.nokia.com
Subject: [RFC/PATCH 02/10] media: Media device
The media_device structure abstracts functions common to all kind of
media devices (v4l2, dvb, alsa, ...). It manages media entities and
offers a userspace API to discover and configure the media device
internal topology.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/media-framework.txt | 68
drivers/media/Makefile|2 +-
drivers/media/media-device.c | 77
+
include/media/media-device.h | 53 +
4 files changed, 199 insertions(+), 1 deletions(-)
create mode 100644 Documentation/media-framework.txt
create mode 100644 drivers/media/media-device.c
create mode 100644 include/media/media-device.h
snip
diff --git a/include/media/media-device.h b/include/media/media-device.h
new file mode 100644
index 000..6c1fc4a
--- /dev/null
+++ b/include/media/media-device.h
@@ -0,0 +1,53 @@
+/*
+ * Media device support header.
+ *
+ * Copyright (C) 2010 Laurent Pinchart
laurent.pinch...@ideasonboard.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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
+ */
+
+#ifndef _MEDIA_DEVICE_H
+#define _MEDIA_DEVICE_H
+
+#include linux/device.h
+#include linux/list.h
+
+#include media/media-devnode.h
+
+/* Each instance of a media device should create the media_device struct,
+ * either stand-alone or embedded in a larger struct.
+ *
+ * It allows easy access to sub-devices (see v4l2-subdev.h) and provides
+ * basic media device-level support.
+ */
+
+#define MEDIA_DEVICE_NAME_SIZE (20 + 16)
Where does above numbers come from ??
Regards,
Sergio
+
+struct media_device {
+ /* dev-driver_data points to this struct.
+ * Note: dev might be NULL if there is no parent device
+ * as is the case with e.g. ISA devices.
+ */
+ struct device *dev;
+ struct media_devnode devnode;
+
+ /* unique device name, by default the driver name + bus ID */
+ char name[MEDIA_DEVICE_NAME_SIZE];
+};
+
+int __must_check media_device_register(struct media_device *mdev);
+void media_device_unregister(struct media_device *mdev);
+
+#endif
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 02/10] media: Media device
Hi Laurent,
Other comment I missed to mention...
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Wednesday, July 14, 2010 8:30 AM
To: linux-media@vger.kernel.org
Cc: sakari.ai...@maxwell.research.nokia.com
Subject: [RFC/PATCH 02/10] media: Media device
The media_device structure abstracts functions common to all kind of
media devices (v4l2, dvb, alsa, ...). It manages media entities and
offers a userspace API to discover and configure the media device
internal topology.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/media-framework.txt | 68
drivers/media/Makefile|2 +-
drivers/media/media-device.c | 77
+
include/media/media-device.h | 53 +
4 files changed, 199 insertions(+), 1 deletions(-)
create mode 100644 Documentation/media-framework.txt
create mode 100644 drivers/media/media-device.c
create mode 100644 include/media/media-device.h
snip
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
new file mode 100644
index 000..a4d3db5
--- /dev/null
+++ b/drivers/media/media-device.c
@@ -0,0 +1,77 @@
+/*
+ * Media device support.
+ *
+ * Copyright (C) 2010 Laurent Pinchart
laurent.pinch...@ideasonboard.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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
+ */
+
+#include linux/types.h
+#include linux/ioctl.h
+
+#include media/media-device.h
+#include media/media-devnode.h
+
+static const struct media_file_operations media_device_fops = {
+ .owner = THIS_MODULE,
+};
+
+static void media_device_release(struct media_devnode *mdev)
+{
+}
+
+/**
+ * media_device_register - register a media device
+ * @mdev:The media device
+ *
+ * The caller is responsible for initializing the media device before
+ * registration. The following fields must be set:
+ *
+ * - dev should point to the parent device. The field can be NULL when no
+ * parent device is available (for instance with ISA devices).
+ * - name should be set to the device name. If the name is empty a parent
+ * device must be set. In that case the name will be set to the parent
+ * device driver name followed by a space and the parent device name.
+ */
+int __must_check media_device_register(struct media_device *mdev)
+{
+ /* If dev == NULL, then name must be filled in by the caller */
+ if (mdev-dev == NULL WARN_ON(!mdev-name[0]))
If mdev == NULL, you'll have a kernel panic here.
Regards,
Sergio
--
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 03/10] media: Entities, pads and links
Hi Laurent, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Wednesday, July 14, 2010 8:30 AM To: linux-media@vger.kernel.org Cc: sakari.ai...@maxwell.research.nokia.com Subject: [RFC/PATCH 03/10] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil hverk...@xs4all.nl initial work. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/media-framework.txt | 125 drivers/media/Makefile|2 +- drivers/media/media-device.c | 53 ++ drivers/media/media-entity.c | 145 + include/media/media-device.h | 16 include/media/media-entity.h | 79 6 files changed, 419 insertions(+), 1 deletions(-) create mode 100644 drivers/media/media-entity.c create mode 100644 include/media/media-entity.h diff --git a/Documentation/media-framework.txt b/Documentation/media- framework.txt index b942c8f..4a8f379 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -35,6 +35,30 @@ belong to userspace. The media kernel API aims at solving those problems. +Abstract media device model +--- + +Discovering a device internal topology, and configuring it at runtime, is one +of the goals of the media framework. To achieve this, hardware devices are +modeled as an oriented graph of building blocks called entities connected +through pads. + +An entity is a basic media hardware building block. It can correspond to +a large variety of logical blocks such as physical hardware devices +(CMOS sensor for instance), logical hardware devices (a building block +in a System-on-Chip image processing pipeline), DMA channels or physical +connectors. + +A pad is a connection endpoint through which an entity can interact with +other entities. Data (not restricted to video) produced by an entity +flows from the entity's output to one or more entity inputs. Pads should +not be confused with physical pins at chip boundaries. + +A link is a point-to-point oriented connection between two pads, either +on the same entity or on different entities. Data flows from a source +pad to a sink pad. + + Media device @@ -66,3 +90,104 @@ Drivers unregister media device instances by calling Unregistering a media device that hasn't been registered is *NOT* safe. + +Entities, pads and links + + +- Entities + +Entities are represented by a struct media_entity instance, defined in +include/media/media-entity.h. The structure is usually embedded into a +higher-level structure, such as a v4l2_subdev or video_device instance, +although drivers can
[PATCH] added support for DM040832731 DVB-S USB BOX
DVB USB Driver for DM04 LME2510 + LG TDQY - P001F =(TDA8263 + TDA10086H)
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
diff -r 9652f85e688a linux/drivers/media/dvb/dvb-usb/Kconfig
--- a/linux/drivers/media/dvb/dvb-usb/Kconfig Thu May 27 02:02:09 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/Kconfig Thu Jul 15 18:45:47 2010 +0100
@@ -346,3 +346,13 @@
select DVB_STB6100 if !DVB_FE_CUSTOMISE
help
Say Y here to support the AZ6027 device
+
+config DVB_USB_LME2510
+ tristate LME DM04 (LME 2510 + TDQY-P001F) DVB-S USB2.0 support
+ depends on DVB_USB
+ select DVB_TDA10086 if !DVB_FE_CUSTOMISE
+ select DVB_TDA826X if !DVB_FE_CUSTOMISE
+ help
+ Say Y here to support the LME DM04 DVB-S USB2.0 .
+
+
diff -r 9652f85e688a linux/drivers/media/dvb/dvb-usb/Makefile
--- a/linux/drivers/media/dvb/dvb-usb/Makefile Thu May 27 02:02:09 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/Makefile Thu Jul 15 18:45:47 2010 +0100
@@ -88,6 +88,9 @@
dvb-usb-az6027-objs = az6027.o
obj-$(CONFIG_DVB_USB_AZ6027) += dvb-usb-az6027.o
+dvb-usb-lmedm04-objs = lmedm04.o
+obj-$(CONFIG_DVB_USB_LME2510) += dvb-usb-lmedm04.o
+
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/
# due to tuner-xc3028
EXTRA_CFLAGS += -Idrivers/media/common/tuners
diff -r 9652f85e688a linux/drivers/media/dvb/dvb-usb/lmedm04.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/dvb-usb/lmedm04.c Thu Jul 15 18:45:47 2010 +0100
@@ -0,0 +1,908 @@
+/* DVB USB compliant linux driver for
+ *
+ * DM040832731 DVB-S USB BOX (LME 2510 + TDQY-P001F)
+ *
+ * MV001F LG TDQY - P001F =(TDA8263 + TDA10086H)
+ *
+ * I2C addresses:
+ * 0x0e - TDA10086 - Demodulator
+ * 0x60 - TDA8263- Tuner
+ *
+ * ***Please Note***
+ * There are other variants of the DM04
+ * ***NOT SUPPORTED***
+ * MVB0001F (LME2510C+LGTDQT-P001F)
+ * MV0194 (LME2510+SHARP0194)
+ * MVB0194 (LME2510C+SHARP0194)
+ * MVB7395 (LME2510C+SHARP:BS2F7HZ7395)
+ *
+ * The VID of 3344 and PID of 1122 has not been set until it is known not
+ * to be generic.
+ *
+ *
+ * Copyright (C) 2010 Malcolm Priestley (tvbox...@gmail.com)
+ * LME2510 (C) Leaguerme (Shenzhen) MicroElectronics Co., Ltd.
+ *
+ * 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, version 2.
+ *
+ *
+ * see Documentation/dvb/README.dvb-usb for more information
+ *
+ * Known Issue :
+ * Non Intel USB chipsets fail to maintain High Speed on Boot or Hot Plug
+ *
+ */
+#define DVB_USB_LOG_PREFIX LME2510
+#include linux/usb.h
+#include linux/usb/input.h
+#include dvb-usb.h
+#include lmedm04.h
+#include tda826x.h
+#include tda10086.h
+
+/* debug */
+static int dvb_usb_lme2510_debug;
+#define l_dprintk(var, level, args...) \
+ do { if ((var = level)) info(args); } while (0)
+#define deb_info(level, args...) l_dprintk(dvb_usb_lme2510_debug,
level, args)
+#define debug_data_snipet(level, name, p) \
+deb_info(level, name (%02x%02x%02x%02x%02x%02x%02x%02x), \
+ *p, *(p+1), *(p+2), *(p+3), *(p+4), \
+ *(p+5), *(p+6), *(p+7));
+
+
+module_param_named(debug, dvb_usb_lme2510_debug, int, 0644);
+MODULE_PARM_DESC(debug, set debugging level (1=info (or-able)).
+ DVB_USB_DEBUG_STATUS);
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+
+struct lme2510_state {
+ u8 id;
+ u8 signal_lock;
+ u8 signal_level;
+ u8 signal_sn;
+ u8 time_key;
+ u8 i2c_talk_onoff;
+ u16 pid_table[64];
+ u8 pid_count;
+ u8 pid_flag_enable;
+ u8 filter_data[256];
+ void *buffer;
+ struct urb *lme_urb;
+
+};
+
+static int lme2510_bulk_write(struct usb_device *dev, u8 *snd, int
len, u8 pipe)
+{
+ int ret, actual_l;
+ ret = usb_bulk_msg(dev, usb_sndbulkpipe(dev, pipe),
+ snd, len , actual_l, 500);
+ return ret;
+}
+
+static int lme2510_bulk_read(struct usb_device *dev, u8 *rev, int len, u8 pipe)
+{
+ int ret, actual_l;
+ ret = usb_bulk_msg(dev, usb_rcvbulkpipe(dev, pipe),
+rev, len , actual_l, 500);
+ return ret;
+}
+
+static int lme2510_usb_talk(struct dvb_usb_device *d,
+ u8 *wbuf, int wlen, u8 *rbuf, int rlen)
+{
+ u8 s[wlen+4], r[rlen+4];
+ int ret = 0;
+ memset(s, 0, wlen);
+ memset(r, 0, rlen);
+ memcpy(s[0], wbuf, wlen);
+
+ ret = mutex_lock_interruptible(d-usb_mutex);
+
+ if (ret 0)
+ return -EAGAIN;
+
+ ret += usb_clear_halt(d-udev, usb_sndbulkpipe(d-udev, 0x01));
+ msleep(5);
+ ret += lme2510_bulk_write(d-udev, s, wlen , 0x1);
+
+ msleep(5);
+ ret += usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x1));
+
+
[PATCH 24/25] video/ivtv: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: Peter Huewe peterhu...@gmx.de
This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
.subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
PCI_VDEVICE macro, and thus improves readability.
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
drivers/media/video/ivtv/ivtv-driver.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 90daa6e..8e73ab9 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -69,10 +69,8 @@ int ivtv_first_minor;
/* add your revision and whatnot here */
static struct pci_device_id ivtv_pci_tbl[] __devinitdata = {
- {PCI_VENDOR_ID_ICOMP, PCI_DEVICE_ID_IVTV15,
-PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_ICOMP, PCI_DEVICE_ID_IVTV16,
-PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_VDEVICE(ICOMP, PCI_DEVICE_ID_IVTV15), 0},
+ {PCI_VDEVICE(ICOMP, PCI_DEVICE_ID_IVTV16), 0},
{0,}
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Thu Jul 15 19:00:25 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS 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: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Bugreport for libv4l: error out on webcam: error parsing JPEG header: Bogus jpeg format
I use Logitech QuickCam Deluxe on FreeBSD-8.1. It shows the image for a while but after 20sec-5min it errors out with the message from libv4l, see below. Could this be a bug in libv4l or it maybe it should be passed some tolerance to errors option? --- log --- pwcview -s vga Webcam set to: 640x480 (vga) at 5 fps libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Bogus jpeg format Error reading from webcam: Input/output error -- 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 24/25] video/ivtv: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
On Thu, 2010-07-15 at 21:08 +0200, Peter Huewe wrote:
From: Peter Huewe peterhu...@gmx.de
This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
.subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
PCI_VDEVICE macro, and thus improves readability.
Hi Peter,
I have to disagree. The patch may improve typesetting, but it degrades
clarity and maintainability from my perspective.
a. PCI_ANY_ID indicates to the reader a wildcard match is being
performed. The PCI_VDEVICE() macro hides that to some degree.
b. PCI_VENDOR_ID_ICOMP clearly indicates that ICOMP is a vendor.
ICOMP alone does not hint to the reader that is stands for a company
(the now defunct Internext Compression, Inc.).
IMO, macros, for things other than named constants, should only be used
for constructs that the C language does not express clearly or compactly
in the context. This structure initialization being done in file scope,
where white space and line feeds are cheap, will only be obfuscated by
macros, not clarified.
So I'm going to NAK this for ivtv, unless someone can help me understand
any big picture benefit that I may not see from my possibly myopic
perspective.
BTW, I have not seen a similar patch come in my mailbox for
cx18-driver.c. Why propose the change for ivtv and not cx18?
Regards,
Andy
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
drivers/media/video/ivtv/ivtv-driver.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 90daa6e..8e73ab9 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -69,10 +69,8 @@ int ivtv_first_minor;
/* add your revision and whatnot here */
static struct pci_device_id ivtv_pci_tbl[] __devinitdata = {
- {PCI_VENDOR_ID_ICOMP, PCI_DEVICE_ID_IVTV15,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_ICOMP, PCI_DEVICE_ID_IVTV16,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_VDEVICE(ICOMP, PCI_DEVICE_ID_IVTV15), 0},
+ {PCI_VDEVICE(ICOMP, PCI_DEVICE_ID_IVTV16), 0},
{0,}
};
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/25] video/ivtv: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
Am Donnerstag 15 Juli 2010 23:43:20 schrieb Andy Walls: ... use the PCI_VDEVICE macro, and thus improves readability. I have to disagree. The patch may improve typesetting, but it degrades clarity and maintainability from my perspective. ... So I'm going to NAK this for ivtv, unless someone can help me understand any big picture benefit that I may not see from my possibly myopic perspective. Hi Andy, absolutely no problem ;) - I thing that is one of the great things about open source that people can have different opinions and discuss them. Patches are proposals only, and if I spark a discussion which brings the development process further or from which I can learn something, I'm a lucky guy ;) PCI_ANY_ID indicates to the reader a wildcard match is being performed. Yeah, but I get absolutely no information out of the 0, 0, parameters either - unless I look up the function - but then I could also look up the Macro. BTW, I have not seen a similar patch come in my mailbox for cx18-driver.c. Why propose the change for ivtv and not cx18? That might be the case since I picked out several different locations using cscope (by gut instinct) - so the patchset is not comprehensive. There are still a lot of places that are not converted, I just picked some at random and stopped at 25 patches. The reason behind this was that I almost expected some kind of controversy and discussion about the changes - and since I'm getting some NACKs I guess this was a smart move - imagine I had converted the whole kernel source just to get a simple NACK ;) Thanks, Peter -- 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 24/25] video/ivtv: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
On Thu, Jul 15, 2010 at 5:43 PM, Andy Walls awa...@md.metrocast.net wrote: On Thu, 2010-07-15 at 21:08 +0200, Peter Huewe wrote: From: Peter Huewe peterhu...@gmx.de This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the PCI_VDEVICE macro, and thus improves readability. Hi Peter, I have to disagree. The patch may improve typesetting, but it degrades clarity and maintainability from my perspective. a. PCI_ANY_ID indicates to the reader a wildcard match is being performed. The PCI_VDEVICE() macro hides that to some degree. b. PCI_VENDOR_ID_ICOMP clearly indicates that ICOMP is a vendor. ICOMP alone does not hint to the reader that is stands for a company (the now defunct Internext Compression, Inc.). Personally, I'm a fan of comments around things like this to describe *exactly* what device(s) they're referring to. Then ICOMP being all alone without the prefix isn't really much of an issue (though it could still be easily mistaken for something other than a pci vendor id, I suppose). -- Jarod Wilson ja...@wilsonet.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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Dear Kuninori,
Am Donnerstag, den 15.07.2010, 14:37 +0900 schrieb Kuninori Morimoto:
Dear hermann
Is there any documentation and how can a user know about it?
Ecovec board which I and Guennadi were talking about is an evaluation board.
If you buy this board, you can find DVD including manual in its box.
Please check
${DVD}/hardware/user's_manual/eng/rej10j2027-0101_R0P7724LC001121RL_um_1.03.pdf
on that stage it is now, you can't call me to crawl the web or buy any
evaluation board, likely high priced, still not even providing a link.
If you use GNU/Linux, free of charge, you have to provide acceptable
documentation too.
dip-switch settings is wrote in
3.4 Switch Specification
If you don't have this board,
but have kernel source code,
you can watch explain comment on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Best regards
--
Kuninori Morimoto
This is lame. I do want to know what is out in the markets already and
no fall back on initial dip-switch comments. Comparable sensors ship
from China directly for some 5 Euros and less here.
This is a change (chance?) in culture too, and was already discussed in
1976 by some, but was at least public for all those a little bit more
interested since, let's say, 1982.
This is going on for a long time now, it did not hit the linuxtv.org
wiki at all until today, but introduces most relevant API changes. To
stop to provide support for older devices, in favor of the like of such
stuff, was mentioned several times already to get quicker to the
bonanza.
All major hardware manufacturers, and/or those claiming to be codec
possessors, have hired linux devel teams around the globe to move this
forward.
What it means, that everyone likely can film his life soon with two HD
cameras on mobile devices at once, let's say with 1080p for now, one
following his view to the outside world, the other one pointing to
him/her at the same time, about that, there is no word on this list.
It is not about missing some dip switch settings on an evaluation board.
It is about missing documentation, but much more about missing
reflection, if GNU/Linux should give the vehicle for such.
And it obviously does, even without any further comments.
Cheers,
Hermann
--
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
