Re: [GIT PATCHES FOR 2.6.35] More _fmt to _mbus_fmt conversions
On Sunday 09 May 2010 15:30:24 Hans Verkuil wrote: The following changes since commit 08b8618ac4dbcd05ec1886853b1d865798d26e1d: Devin Heitmueller (1): V4L/DVB: ngene: Add lgdt3303 and mt2131 deps to Kconfig are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git mbus1 Tested with ivtv, cx18, saa7134-empress and pvrusb2. This is the first patch series of driver conversions. These are all pretty trivial and basically just replace enum/try/g/s_fmt with enum/try/g/s_mbus_fmt. There will be two or three more patch series but some need to be reviewed first. The goal is to get rid of enum/try/g/s_fmt in the video ops. It's the wrong API at that level and as long as it is in the video ops people will misuse it. Now that I received the Ack from Guennadi I've also added this patch to the pull request: v4l2-subdev.h: fix enum_mbus_fmt prototype Guennadi: I've changed unsigned to unsigned int. Regards, Hans Hans Verkuil (21): V4L2 Spec: Improve the VIDIOC_QUERY_DV_PRESET description saa7115: add s_mbus_fmt op cx25840: add support for s_mbus_fmt saa717x: add support for s_mbus_fmt ivtv: convert to use s_mbus_fmt cx18: add s_mbus_fmt support cx18: remove old g/s_fmt from the cx18_av subdev saa7127: remove obsolete g_fmt support saa717x: remove obsolete s_fmt op v4l2-mediabus.h: add two helper functions saa6752hs: add g/s_mbus_fmt support saa7134: convert to use the new mbus API pvrusb2: convert to s_mbus_fmt cx23885: convert to s_mbus_fmt cx231xx: convert to s_mbus_fmt cx24850: remove obsolete g/s_fmt ops saa7115: remove obsolete g/s_fmt ops v4l2-mediabus.h: added V4L2_MBUS_FMT_SGRBG8_1X8 mt9v011: add enum/try/s_mbus_fmt support tvp5150: remove obsolete g/s_fmt ops au8522_decoder: g/s_fmt doesn't do anything: remove. .../DocBook/v4l/vidioc-query-dv-preset.xml |6 +- drivers/media/dvb/frontends/au8522_decoder.c | 26 drivers/media/video/cx18/cx18-av-core.c| 125 +--- drivers/media/video/cx18/cx18-controls.c | 11 +- drivers/media/video/cx18/cx18-ioctl.c |8 +- drivers/media/video/cx231xx/cx231xx-video.c|5 +- drivers/media/video/cx23885/cx23885-video.c|5 +- drivers/media/video/cx25840/cx25840-core.c | 99 +++- drivers/media/video/ivtv/ivtv-controls.c | 10 +- drivers/media/video/ivtv/ivtv-ioctl.c |6 +- drivers/media/video/mt9v011.c | 37 +++--- drivers/media/video/pvrusb2/pvrusb2-hdw.c | 12 +- drivers/media/video/saa7115.c | 19 +-- drivers/media/video/saa7127.c |8 -- drivers/media/video/saa7134/saa6752hs.c| 46 --- drivers/media/video/saa7134/saa7134-empress.c |9 +- drivers/media/video/saa717x.c | 38 --- drivers/media/video/tvp5150.c | 20 --- include/media/v4l2-mediabus.h | 21 19 files changed, 233 insertions(+), 278 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: Status of the patches under review (85 patches) and some misc notes about the devel procedures
From: Mauro Carvalho Chehab mche...@redhat.com == New or updated patches starting from May, 5 or newer - not handled yet == May, 5 2010: [-next] media/mem2mem: dereferencing free memory http://patchwork.kernel.org/patch/96984 This one is obvious, but might as well: Reviewed-by: Pawel Osciak p.osc...@samsung.com Acked-by: Pawel Osciak p.osc...@samsung.com Best regards -- Pawel Osciak 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
[GIT PATCHES FOR 2.6.35] Convert bw-qcam and c-qcam to V4L2
I had hoped to get hardware to test it with, but no such luck (yet). But there seems to be no sense in holding these patches back on the off-chance that I can get hardware. Gerard, you mentioned earlier that you actually had a c-qcam. It would be nice if you can test this. Regards, Hans The following changes since commit 08b8618ac4dbcd05ec1886853b1d865798d26e1d: Devin Heitmueller (1): V4L/DVB: ngene: Add lgdt3303 and mt2131 deps to Kconfig are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git v4l1 Hans Verkuil (2): bw-qcam: convert to V4L2 c-qcam: convert to V4L2 drivers/media/video/Kconfig |4 +- drivers/media/video/bw-qcam.c | 759 ++--- drivers/media/video/bw-qcam.h | 69 drivers/media/video/c-qcam.c | 634 ++ 4 files changed, 746 insertions(+), 720 deletions(-) delete mode 100644 drivers/media/video/bw-qcam.h -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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] S-1500 + CI
Le lundi 10 mai 2010 11:24:49, Ahmad Issa a écrit : Maybe it's a limitation in Linux drivers No, it's not. I'm able to decrypt up to 12 channels with an Aston Pro CAM (24 pids), so i think it's rather a limitation of your CAM. -- Christophe Thommeret -- 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/7] [RFC] Move VIDIOC_G/S_PRIORITY handling to the V4L core
Hi Hans, On Sunday 09 May 2010 21:29:05 Hans Verkuil wrote: Few drivers implement VIDIOC_G/S_PRIORITY and those that do often implement it incorrectly. Now that we have a v4l2_fh struct it is easy to add support for priority handling to the v4l core framework. There are three types of drivers: 1) Those that use v4l2_fh. There the local priority can be stored in the v4l2_fh struct. 2) Those that do not have an open or release function defined in v4l2_file_ops. That means that file-private_data will never be filled and so we can use that to store the local priority in. 3) Others. In all other cases we leave it to the driver. Of course, the goal is to eventually move the 'others' into type 1 or 2. This patch series shows how it is done and converts ivtv to rely on the core framework instead of doing it manually. Comments? I don't think this is right. You're moving the priority ioctls support to v4l2_device, while it would make more sense to move it to video_device. If a device can capture two independent video streams simultaneously, your patches would prevent it from working at all. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: setting up a tevii s660
On 10 мая 2010 00:29:13 Tim Coote wrote: Thanks, Igor. I was using that set of drivers (if I understood the Babelfish translation.) My issue was that my hardware was broken (I was using a VMWare VM that didn't emulate usb properly). It's always hard to work out what's broken when you load up some new package and it doesn't work. I'd confirmed that the s660 worked from windows, but I had to build a windows vm to demonstrate that it was VMWare that was broken. Meanwhile, I kept stumbling across what seemed to be similar breakages to what I was seeing. I don't know how feasible it would be, but when I used to write device drivers, I'd pull together simple programs to test that the hardware was working as I'd expect as I spent so much time debugging changing hardware designs :-( I would say that the tevii drivers have both new code compared to the tip of the driver that you manage, and also seem to be missing some code. So called TeVii drivers is simply a snapshot from linuxtv, so OK, they are useable. thanks again for your help. Now all I've got to do is get mythtv to work... Tim On 9 May 2010, at 19:46, Igor M. Liplianin wrote: On 6 мая 2010 02:07:38 Tim Coote wrote: [snip] Hi! Read this: http://forum.free-x.de/wbb/index.php?page=ThreadthreadID=601pageNo=6 Useful to translate from Russian: http://babelfish.yahoo.com/translate_txt Best regards -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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 Tim Coote t...@coote.org +44 (0)7866 479 760 -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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/6] [RFC] tvp514x fixes
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Sunday, May 09, 2010 7:27 PM To: linux-media@vger.kernel.org Cc: Hiremath, Vaibhav Subject: [PATCH 0/6] [RFC] tvp514x fixes Hi Vaibhav, While working on the *_fmt to *_mbus_fmt video op conversion I noticed that tvp514x is confusing the current select TV standard with the detected TV standard leading to horrible side-effects where called TRY_FMT can actually magically change the TV standard. I fixed this and I also simplified the format handling in general. Basically removing the format list table and realizing that since there is only one supported format, you can just return that format directly. This will also make the next step much easier where enum/try/s/g_fmt is replaced by enum/try/s/g_mbus_fmt. However, I have no way of testing this. Can you review this code and let me know if it is OK? [Hiremath, Vaibhav] Sorry Hans for delayed response on this, actually today almost whole day I had to spend collecting docs for VISA application and stuff. Thanks for working on this and changing the driver, I will take a look at it (Also I will validate it here at my end) and update you on this. Thanks, Vaibhav Regards, Hans Hans Verkuil (6): tvp514x: do NOT change the std as a side effect tvp514x: make std_list const tvp514x: there is only one supported format, so simplify the code tvp514x: add missing newlines tvp514x: remove obsolete fmt_list tvp514x: simplify try/g/s_fmt handling drivers/media/video/tvp514x.c | 223 -- --- 1 files changed, 40 insertions(+), 183 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stv090x vs stv0900
Le dimanche 09 mai 2010 à 21:34 +0300, Igor M. Liplianin a écrit : On 6 мая 2010 11:46:17 Pascal Terjan wrote: Hi, I was adding support for a non working version of DVBWorld HD 2104 It is listed on http://www.linuxtv.org/wiki/index.php/DVBWorld_HD_2104_FTA_USB_Box as : = for new solution : 2104B (Sharp0169 Tuner) * STV6110A tuner * ST0903 demod * Cyrix CY7C68013A USB controller = The 2104A is supposed to be working and also have ST0903 but uses stv0900, so I tried using it too but did not manage to get it working. But it working. I have the device and test it succesfully. OK, but the B does not here while it seems to work with stv090x All I get in log with femon is stv0900_read_status: 7DEMOD LOCK FAIL 6stv0900_get_rf_level 6stv0900_get_rf_level: RFLevel = -100 6stv0900_carr_get_quality And with scandvb : stv0900_read_status: 7DEMOD LOCK FAIL stv0900_read_status: 7DEMOD LOCK FAIL stv0900_read_status: 7DEMOD LOCK FAIL stv0900_read_status: 7DEMOD LOCK FAIL 6stv0900_search: 7stv0900_set_tuner: Frequency=1939000 stv0900_set_tuner: Bandwidth=7200 6stv0900_activate_s2_modcode 6Search Fail stv0900_read_status: 7DEMOD LOCK FAIL So modprobe dvb-usb-dw2102 demod=2 brings DVBWorld 2104A to you on golden plate. Yes but this one is 2104B -- 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] S-1500 + CI
6 channels with SMIT? You are lucky, the most I have ever gotten is 5 ( actually 11 pids ). Aston claims they can do 12 services (24 pids) the most I have ever gotten out of them is 17 pids (actually 16 pids working well and one more glitching pid) I have also tested PowerCAM - same story, can actually do about 2/3 of what they claim. -original message- Subject: [linux-dvb] S-1500 + CI From: Ahmad Issa issa@gmail.com Date: 10/05/2010 17:24 I have S-1500 + CI installed at openSuse PC , used with SMIT Pro CAM thats suppose to descramble 8 channels at same time. I am not able to get more than 6 channels. Smit claimed that is a limitation of the CI, I also tried OneCam Infinite (8 channels too), same results. I have contact technoTrend and below is their reply: *it's not a limitation of the CI, as it's a silly device, just parsing the stream over CAM. Maybe it's a limitation in Linux drivers, which we don't support, due to open source. Maybe you get in touch with the Linux community first ...* Any Body can help? Thanks aissa ___ 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: Status of the patches under review (85 patches) and some misc notes about the devel procedures
Hi, Mauro Carvalho Chehab mche...@redhat.com wrote: == Videobuf patches - Need more tests before committing it - Volunteers? == Apr,21 2010: [v1, 1/2] v4l: videobuf: Add support for out-of-order buffer dequeuing http://patchwork.kernel.org/patch/93901 Apr,21 2010: [v1, 2/2] v4l: vivi: adapt to out-of-order buffer dequeuing in videobu http://patchwork.kernel.org/patch/93903 it'd be great if there was a driver/device that would be benefiting from this, i.e. that may want to: - return buffers in a different order than queued, - process them in parallel, - process them in a different order, or anybody interested in those features. Is anybody aware of any such devices in the V4L tree? This is also the first step to simplifying videobuf and making it lighter by removing superficial (to my best knowledge) waitqueues in every videobuf_buffer structure, as discussed at the Oslo meeting. Best regards -- Pawel Osciak 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: Status of the patches under review (85 patches) and some misc notes about the devel procedures
On Sat, May 08, 2010 at 03:45:41PM -0700, Mauro Carvalho Chehab wrote: Jean-Francois Moine wrote: On Fri, 7 May 2010 09:39:16 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: == Gspca patches - Waiting Jean-Francois Moine moin...@free.fr submission/review == Feb,24 2010: gspca pac7302: add USB PID range based on heuristics http://patchwork.kernel.org/patch/81612 May, 3 2010: gspca: Try a less bandwidth-intensive alt setting. http://patchwork.kernel.org/patch/96514 Hello Mauro, I don't think the patch about pac7302 should be applied. The patch about the gspca main is in my last git pull request. (c/c Sarah) I also didn't like this patch strategy. It seems a sort of workaround for xHCI, instead of a proper fix. I'll mark this patch as rejected, and wait for a proper fix. This isn't a work around for a bug in the xHCI host. The bandwidth checking is a feature. It allows the host to reject a new interface if other devices are already taking up too much of the bus bandwidth. I expect that all drivers that use interrupt or isochronous will have to fall back to a different alternate interface setting if they can. Now, Alan Stern and I have been talking about making a different API for drivers to request a specific polling rate and frame list length for an endpoint. However, I expect that the call would have to be either before or part of the call to usb_set_interface(), because of how the xHCI hardware tracks endpoints. So even if we had the ideal interface, the drivers would still need code like this to fall back to less-bandwidth intensive alternate settings. Is there a different way you think we should handle running out of bandwidth? Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: S5PC100: Add FIMC driver platform helpers
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mach-s5pc100/Kconfig| 21 +
arch/arm/mach-s5pc100/Makefile |4
arch/arm/mach-s5pc100/include/mach/map.h |8
arch/arm/mach-s5pc100/mach-smdkc100.c|9 +
arch/arm/mach-s5pc100/setup-fimc0.c | 27 +++
arch/arm/mach-s5pc100/setup-fimc1.c | 27 +++
arch/arm/mach-s5pc100/setup-fimc2.c | 27 +++
7 files changed, 123 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pc100/setup-fimc0.c
create mode 100644 arch/arm/mach-s5pc100/setup-fimc1.c
create mode 100644 arch/arm/mach-s5pc100/setup-fimc2.c
diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig
index 092925b..c6f8adf 100644
--- a/arch/arm/mach-s5pc100/Kconfig
+++ b/arch/arm/mach-s5pc100/Kconfig
@@ -36,6 +36,21 @@ config S5PC100_SETUP_SDHCI_GPIO
help
Common setup code for SDHCI gpio.
+config S5PC100_SETUP_FIMC0
+ bool
+ help
+ Setup code for FIMC controller 0
+
+config S5PC100_SETUP_FIMC1
+ bool
+ help
+ Setup code for FIMC controller 1
+
+config S5PC100_SETUP_FIMC2
+ bool
+ help
+ Setup code for FIMC controller 2
+
config MACH_SMDKC100
bool SMDKC100
select CPU_S5PC100
@@ -48,6 +63,12 @@ config MACH_SMDKC100
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
select S3C_DEV_HSMMC2
+ select S5P_DEV_FIMC0
+ select S5PC100_SETUP_FIMC0
+ select S5P_DEV_FIMC1
+ select S5PC100_SETUP_FIMC1
+ select S5P_DEV_FIMC2
+ select S5PC100_SETUP_FIMC2
help
Machine support for the Samsung SMDKC100
diff --git a/arch/arm/mach-s5pc100/Makefile b/arch/arm/mach-s5pc100/Makefile
index 7a7de14..db17a0d 100644
--- a/arch/arm/mach-s5pc100/Makefile
+++ b/arch/arm/mach-s5pc100/Makefile
@@ -21,6 +21,10 @@ obj-$(CONFIG_S5PC100_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S5PC100_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_S5PC100_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
+obj-$(CONFIG_S5PC100_SETUP_FIMC0) += setup-fimc0.o
+obj-$(CONFIG_S5PC100_SETUP_FIMC1) += setup-fimc1.o
+obj-$(CONFIG_S5PC100_SETUP_FIMC2) += setup-fimc2.o
+
# machine support
obj-$(CONFIG_MACH_SMDKC100)+= mach-smdkc100.o
diff --git a/arch/arm/mach-s5pc100/include/mach/map.h
b/arch/arm/mach-s5pc100/include/mach/map.h
index 9e49dcc..40452cc 100644
--- a/arch/arm/mach-s5pc100/include/mach/map.h
+++ b/arch/arm/mach-s5pc100/include/mach/map.h
@@ -68,6 +68,11 @@
#define S5P_PA_SDRAM S5PC100_PA_SDRAM
+/* FIMC */
+#define S5PC100_PA_FIMC0 (0xEE20)
+#define S5PC100_PA_FIMC1 (0xEE30)
+#define S5PC100_PA_FIMC2 (0xEE40)
+
/* compatibiltiy defines. */
#define S3C_PA_UARTS5PC100_PA_UART
#define S3C_PA_IIC S5PC100_PA_IIC0
@@ -79,5 +84,8 @@
#define S3C_PA_HSMMC0 S5PC100_PA_HSMMC0
#define S3C_PA_HSMMC1 S5PC100_PA_HSMMC1
#define S3C_PA_HSMMC2 S5PC100_PA_HSMMC2
+#define S5P_PA_FIMC0 S5PC100_PA_FIMC0
+#define S5P_PA_FIMC1 S5PC100_PA_FIMC1
+#define S5P_PA_FIMC2 S5PC100_PA_FIMC2
#endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-s5pc100/mach-smdkc100.c
b/arch/arm/mach-s5pc100/mach-smdkc100.c
index 1668dba..a7fdabc 100644
--- a/arch/arm/mach-s5pc100/mach-smdkc100.c
+++ b/arch/arm/mach-s5pc100/mach-smdkc100.c
@@ -41,6 +41,7 @@
#include plat/s5pc100.h
#include plat/fb.h
#include plat/iic.h
+#include plat/fimc.h
#define UCON (S3C2410_UCON_DEFAULT | S3C2410_UCON_UCLK)
#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE | S3C2410_LCON_STOPB)
@@ -147,6 +148,9 @@ static struct platform_device *smdkc100_devices[]
__initdata = {
s3c_device_hsmmc1,
s3c_device_hsmmc2,
s3c_device_onenand,
+ s5p_device_fimc0,
+ s5p_device_fimc1,
+ s5p_device_fimc2,
};
static void __init smdkc100_map_io(void)
@@ -166,6 +170,11 @@ static void __init smdkc100_machine_init(void)
s3c_fb_set_platdata(smdkc100_lcd_pdata);
+ /* FIMC */
+ s5p_fimc0_set_platdata(NULL);
+ s5p_fimc1_set_platdata(NULL);
+ s5p_fimc2_set_platdata(NULL);
+
/* LCD init */
gpio_request(S5PC100_GPD(0), GPD);
gpio_request(S5PC100_GPH0(6), GPH0);
diff --git a/arch/arm/mach-s5pc100/setup-fimc0.c
b/arch/arm/mach-s5pc100/setup-fimc0.c
new file mode 100644
index 000..00693d2
--- /dev/null
+++ b/arch/arm/mach-s5pc100/setup-fimc0.c
@@ -0,0 +1,27 @@
+/* linux/arch/arm/mach-s5pc100/setup-fimc0.c
+ *
+ * Copyright (c) 2010 Samsung Electronics
+ *
+ * S5PC100 - setup and capabilities definitions for S5P FIMC device 0
+ *
+ * This program is free software; you can redistribute
[PATCH/RFC v2 0/3] [ARM] Add Samsung S5P camera interface driver
Hello, This is a second version of my patch series adding v4l2 driver of the camera interface (FIMC) contained in the Samsung S5PC100 and S5PV210 SoCs. The changes comparing to previous version: - removed null power management ops - multiple minor coding style corrections - corrected clock handling (missing clk_put) - pruned included headers list - removed changes for arch/arm/mach-s5pv210/mach-aquila.c The following patches implement memory to memory mode and require v4l2-mem2mem framework, which has already been merged into the v4l tree. This driver was tested on SMDKC100 system and our custom board based on Samsung S5PV210 SOC. I'm open to any comments and suggestions. This series contains: [PATCH v2 1/3] ARM: Samsung S5P: Add FIMC driver register definition and platform helpers [PATCH v2 2/3] ARM: S5PC100: Add FIMC driver platform helpers [PATCH v2 3/3] ARM: Samsung S5P: Add Camera Interface (video postprocessor) driver Best regards, -- Sylwester Nawrocki Samsung Poland RD Center, Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: Samsung S5P: Add FIMC driver register definition and platform helpers
FIMC device is a camera interface embedded in S5P Samsung SOC
series. It supports ITU-R BT.601/656 and MIPI(CSI) standards,
memory to memory operations, color conversion, resizing and rotation.
On most of the SOCs there are multiple FIMC entities available which
can be deployed in camera capture/preview or video encoding chains.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mach-s5pv210/Kconfig | 22 ++
arch/arm/mach-s5pv210/Makefile |4 +
arch/arm/mach-s5pv210/clock.c | 30 +++
arch/arm/mach-s5pv210/include/mach/map.h |8 +
arch/arm/mach-s5pv210/setup-fimc0.c| 27 +++
arch/arm/mach-s5pv210/setup-fimc1.c| 27 +++
arch/arm/mach-s5pv210/setup-fimc2.c| 27 +++
arch/arm/plat-s5p/Kconfig | 17 ++
arch/arm/plat-s5p/Makefile |8 +
arch/arm/plat-s5p/dev-fimc0.c | 57 +
arch/arm/plat-s5p/dev-fimc1.c | 56 +
arch/arm/plat-s5p/dev-fimc2.c | 56 +
arch/arm/plat-s5p/include/plat/fimc.h | 52 +
arch/arm/plat-s5p/include/plat/irqs.h |4 +
arch/arm/plat-s5p/include/plat/regs-fimc.h | 339
15 files changed, 734 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv210/setup-fimc0.c
create mode 100644 arch/arm/mach-s5pv210/setup-fimc1.c
create mode 100644 arch/arm/mach-s5pv210/setup-fimc2.c
create mode 100644 arch/arm/plat-s5p/dev-fimc0.c
create mode 100644 arch/arm/plat-s5p/dev-fimc1.c
create mode 100644 arch/arm/plat-s5p/dev-fimc2.c
create mode 100644 arch/arm/plat-s5p/include/plat/fimc.h
create mode 100644 arch/arm/plat-s5p/include/plat/regs-fimc.h
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 3048a21..f65c698 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -49,6 +49,22 @@ config S5PC110_DEV_ONENAND
help
Compile in platform device definition for OneNAND1 controller
+config S5PV210_SETUP_FIMC0
+ bool
+ help
+ Setup code for FIMC controller 0
+
+config S5PV210_SETUP_FIMC1
+ bool
+ help
+ Setup code for FIMC controller 1
+
+config S5PV210_SETUP_FIMC2
+ bool
+ help
+ Setup code for FIMC controller 2
+
+
config MACH_SMDKV210
bool SMDKV210
select CPU_S5PV210
@@ -77,6 +93,12 @@ config MACH_AQUILA
select S3C_DEV_HSMMC2
select S3C_DEV_RTC
select S3C_DEV_USB_HS_UDC
+ select S5P_DEV_FIMC0
+ select S5PV210_SETUP_FIMC0
+ select S5P_DEV_FIMC1
+ select S5PV210_SETUP_FIMC1
+ select S5P_DEV_FIMC2
+ select S5PV210_SETUP_FIMC2
help
Machine support for the Samsung Aquila target based on S5PC110 SoC
diff --git a/arch/arm/mach-s5pv210/Makefile b/arch/arm/mach-s5pv210/Makefile
index 91323e9..da545a6 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -25,6 +25,10 @@ obj-$(CONFIG_S5PV210_SETUP_SDHCI_GPIO) +=
setup-sdhci-gpio.o
obj-$(CONFIG_S5PC110_DEV_ONENAND) += dev-onenand.o
+obj-$(CONFIG_S5PV210_SETUP_FIMC0) += setup-fimc0.o
+obj-$(CONFIG_S5PV210_SETUP_FIMC1) += setup-fimc1.o
+obj-$(CONFIG_S5PV210_SETUP_FIMC2) += setup-fimc2.o
+
# machine support
obj-$(CONFIG_MACH_SMDKV210)+= mach-smdkv210.o
diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index f1e2b9d..ceb9af8 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -361,6 +361,36 @@ static struct clksrc_clk clksrcs[] = {
.sources = clkset_default,
.reg_src = { .reg = S5P_CLK_SRC4, .shift = 16, .size = 4 },
.reg_div = { .reg = S5P_CLK_DIV4, .shift = 16, .size = 4 },
+ }, {
+ .clk= {
+ .name = fimc,
+ .id = 0,
+ .ctrlbit= (124),
+ .enable = s5pv210_clk_ip0_ctrl,
+ },
+ .sources = clkset_default,
+ .reg_src = { .reg = S5P_CLK_SRC3, .shift = 12, .size = 4, },
+ .reg_div = { .reg = S5P_CLK_DIV3, .shift = 12, .size = 4, },
+ }, {
+ .clk= {
+ .name = fimc,
+ .id = 1,
+ .ctrlbit= (125),
+ .enable = s5pv210_clk_ip0_ctrl,
+ },
+ .sources = clkset_default,
+ .reg_div = { .reg = S5P_CLK_DIV3, .shift = 16, .size = 4, },
+ .reg_src = { .reg = S5P_CLK_SRC3, .shift = 16, .size = 4, },
+ }, {
+ .clk= {
+
[PATCH 1/2] tm6000: bugfix tuner callback
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 6143e20..9f6160b 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -563,7 +563,7 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
switch (dev-tuner_type) {
case TUNER_XC2028:
- tun_setup.tuner_callback = tm6000_tuner_callback;;
+ tun_setup.tuner_callback = tm6000_tuner_callback;
break;
case TUNER_XC5000:
tun_setup.tuner_callback = tm6000_xc5000_callback;
--
1.7.0.3
--
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] tm6000: add extension
From: Stefan Ringel stefan.rin...@arcor.de
add extension
add module init over tm6000 extension
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-alsa.c | 25 +-
drivers/staging/tm6000/tm6000-cards.c |7 +++
drivers/staging/tm6000/tm6000-core.c | 92 +
drivers/staging/tm6000/tm6000.h | 23 -
4 files changed, 145 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-alsa.c
b/drivers/staging/tm6000/tm6000-alsa.c
index bc89f9d..ce081cd 100644
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@ -410,5 +410,28 @@ error:
snd_card_free(card);
return rc;
}
-EXPORT_SYMBOL_GPL(tm6000_audio_init);
+static int tm6000_audio_fini(struct tm6000_core *dev)
+{
+ return 0;
+}
+
+struct tm6000_ops audio_ops = {
+ .id = TM6000_AUDIO,
+ .name = TM6000 Audio Extension,
+ .init = tm6000_audio_init,
+ .fini = tm6000_audio_fini,
+};
+
+static int __init tm6000_alsa_register(void)
+{
+ return tm6000_register_extension(audio_ops);
+}
+
+static void __exit tm6000_alsa_unregister(void)
+{
+ tm6000_unregister_extension(audio_ops);
+}
+
+module_init(tm6000_alsa_register);
+module_exit(tm6000_alsa_unregister);
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 9f6160b..33b134b 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -692,6 +692,10 @@ static int tm6000_init_dev(struct tm6000_core *dev)
if (rc 0)
goto err;
+ tm6000_add_into_devlist(dev);
+
+ tm6000_init_extension(dev);
+
if (dev-caps.has_dvb) {
dev-dvb = kzalloc(sizeof(*(dev-dvb)), GFP_KERNEL);
if (!dev-dvb) {
@@ -931,6 +935,9 @@ static void tm6000_usb_disconnect(struct usb_interface
*interface)
usb_put_dev(dev-udev);
+ tm6000_remove_from_devlist(dev);
+ tm6000_close_extension(dev);
+
mutex_unlock(dev-lock);
kfree(dev);
}
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index bfbc53b..1259ae5 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -600,3 +600,95 @@ printk(Original value=%d\n,val);
return val;
}
EXPORT_SYMBOL_GPL(tm6000_set_audio_bitrate);
+
+static LIST_HEAD(tm6000_devlist);
+static DEFINE_MUTEX(tm6000_devlist_mutex);
+
+/*
+ * tm6000_realease_resource()
+ */
+
+void tm6000_remove_from_devlist(struct tm6000_core *dev)
+{
+ mutex_lock(tm6000_devlist_mutex);
+ list_del(dev-devlist);
+ mutex_unlock(tm6000_devlist_mutex);
+};
+
+void tm6000_add_into_devlist(struct tm6000_core *dev)
+{
+ mutex_lock(tm6000_devlist_mutex);
+ list_add_tail(dev-devlist, tm6000_devlist);
+ mutex_unlock(tm6000_devlist_mutex);
+};
+
+/*
+ * Extension interface
+ */
+
+static LIST_HEAD(tm6000_extension_devlist);
+static DEFINE_MUTEX(tm6000_extension_devlist_lock);
+
+int tm6000_register_extension(struct tm6000_ops *ops)
+{
+ struct tm6000_core *dev = NULL;
+
+ mutex_lock(tm6000_devlist_mutex);
+ mutex_lock(tm6000_extension_devlist_lock);
+ list_add_tail(ops-next, tm6000_extension_devlist);
+ list_for_each_entry(dev, tm6000_devlist, devlist) {
+ if (dev)
+ ops-init(dev);
+ }
+ printk(KERN_INFO tm6000: Initialized (%s) extension\n, ops-name);
+ mutex_unlock(tm6000_extension_devlist_lock);
+ mutex_unlock(tm6000_devlist_mutex);
+ return 0;
+}
+EXPORT_SYMBOL(tm6000_register_extension);
+
+void tm6000_unregister_extension(struct tm6000_ops *ops)
+{
+ struct tm6000_core *dev = NULL;
+
+ mutex_lock(tm6000_devlist_mutex);
+ list_for_each_entry(dev, tm6000_devlist, devlist) {
+ if (dev)
+ ops-fini(dev);
+ }
+
+ mutex_lock(tm6000_extension_devlist_lock);
+ printk(KERN_INFO tm6000: Remove (%s) extension\n, ops-name);
+ list_del(ops-next);
+ mutex_unlock(tm6000_extension_devlist_lock);
+ mutex_unlock(tm6000_devlist_mutex);
+}
+EXPORT_SYMBOL(tm6000_unregister_extension);
+
+void tm6000_init_extension(struct tm6000_core *dev)
+{
+ struct tm6000_ops *ops = NULL;
+
+ mutex_lock(tm6000_extension_devlist_lock);
+ if (!list_empty(tm6000_extension_devlist)) {
+ list_for_each_entry(ops, tm6000_extension_devlist, next) {
+ if (ops-init)
+ ops-init(dev);
+ }
+ }
+ mutex_unlock(tm6000_extension_devlist_lock);
+}
+
+void tm6000_close_extension(struct tm6000_core *dev)
+{
+ struct tm6000_ops *ops = NULL;
+
+ mutex_lock(tm6000_extension_devlist_lock);
+ if (!list_empty(tm6000_extension_devlist)) {
+ list_for_each_entry(ops,
Re: Status of the patches under review (85 patches) and some misc notes about the devel procedures
Sarah Sharp wrote: On Sat, May 08, 2010 at 03:45:41PM -0700, Mauro Carvalho Chehab wrote: Jean-Francois Moine wrote: On Fri, 7 May 2010 09:39:16 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: == Gspca patches - Waiting Jean-Francois Moine moin...@free.fr submission/review == Feb,24 2010: gspca pac7302: add USB PID range based on heuristics http://patchwork.kernel.org/patch/81612 May, 3 2010: gspca: Try a less bandwidth-intensive alt setting. http://patchwork.kernel.org/patch/96514 Hello Mauro, I don't think the patch about pac7302 should be applied. The patch about the gspca main is in my last git pull request. (c/c Sarah) I also didn't like this patch strategy. It seems a sort of workaround for xHCI, instead of a proper fix. I'll mark this patch as rejected, and wait for a proper fix. This isn't a work around for a bug in the xHCI host. The bandwidth checking is a feature. It allows the host to reject a new interface if other devices are already taking up too much of the bus bandwidth. I expect that all drivers that use interrupt or isochronous will have to fall back to a different alternate interface setting if they can. Now, Alan Stern and I have been talking about making a different API for drivers to request a specific polling rate and frame list length for an endpoint. However, I expect that the call would have to be either before or part of the call to usb_set_interface(), because of how the xHCI hardware tracks endpoints. So even if we had the ideal interface, the drivers would still need code like this to fall back to less-bandwidth intensive alternate settings. Is there a different way you think we should handle running out of bandwidth? Sarah, A loop like the above doesn't work for video streams. The point is that the hardware got programmed to some resolution and frame rate. For example, a typical case is to program the hardware to do 640x480x30fps. Assuming a device with 16 bits per pixel, this means a bandwidth of 18.432 Mbps. With V4L API, the resolution is configured before starting stream (so, before the place where usb_set_interface is called). After having all video stream parameters configured via several different ioctls, a call to VIDIOC_REQBUFS is done, causing the allocation of the streaming buffers and the corresponding USB interface setup. On that moment, it is too late to negotiate the bandwidth. So, if xHCI is not capable of supporting at least 18.432 Mbps (assuming my example), the call should simply fail. In thesis, all V4L/DVB USB drivers have a code where it plays with USB interface alternates, until they found the minimum alternate that is capable of handing the bandwidth needed by the stream. As there's no standard way, at USB core, to set an isoc bandwidth [1], each driver has its own logic for doing that, and maybe some strategies are better than the others. I'm not sure if it would be simpler or possible, but an alternative way would be to have something like usb_request_bandwidth(), where the USB core would have the logic to set the interface alternates to fulfill the bandwidth needs, or return -EINVAL if it is not possible. The advantage is that you won't need to fix all the different logics used by the V4L/DVB drivers. [1] On some devices, even needing a constant bandwitdh, they only support bulk transfers, due to hardware limitation, but, from the driver's perspective, the seek for the alternate has an identical need. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review (85 patches) and some misc notes about the devel procedures
On Mon, 10 May 2010 13:25:00 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Sarah Sharp wrote: On Sat, May 08, 2010 at 03:45:41PM -0700, Mauro Carvalho Chehab wrote: Jean-Francois Moine wrote: On Fri, 7 May 2010 09:39:16 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: == Gspca patches - Waiting Jean-Francois Moine moin...@free.fr submission/review == Feb,24 2010: gspca pac7302: add USB PID range based on heuristics http://patchwork.kernel.org/patch/81612 May, 3 2010: gspca: Try a less bandwidth-intensive alt setting. http://patchwork.kernel.org/patch/96514 Hello Mauro, I don't think the patch about pac7302 should be applied. The patch about the gspca main is in my last git pull request. (c/c Sarah) I also didn't like this patch strategy. It seems a sort of workaround for xHCI, instead of a proper fix. I'll mark this patch as rejected, and wait for a proper fix. This isn't a work around for a bug in the xHCI host. The bandwidth checking is a feature. It allows the host to reject a new interface if other devices are already taking up too much of the bus bandwidth. I expect that all drivers that use interrupt or isochronous will have to fall back to a different alternate interface setting if they can. Now, Alan Stern and I have been talking about making a different API for drivers to request a specific polling rate and frame list length for an endpoint. However, I expect that the call would have to be either before or part of the call to usb_set_interface(), because of how the xHCI hardware tracks endpoints. So even if we had the ideal interface, the drivers would still need code like this to fall back to less-bandwidth intensive alternate settings. Is there a different way you think we should handle running out of bandwidth? Sarah, A loop like the above doesn't work for video streams. The point is that the hardware got programmed to some resolution and frame rate. For example, a typical case is to program the hardware to do 640x480x30fps. Assuming a device with 16 bits per pixel, this means a bandwidth of 18.432 Mbps. With V4L API, the resolution is configured before starting stream (so, before the place where usb_set_interface is called). After having all video stream parameters configured via several different ioctls, a call to VIDIOC_REQBUFS is done, causing the allocation of the streaming buffers and the corresponding USB interface setup. On that moment, it is too late to negotiate the bandwidth. So, if xHCI is not capable of supporting at least 18.432 Mbps (assuming my example), the call should simply fail. In thesis, all V4L/DVB USB drivers have a code where it plays with USB interface alternates, until they found the minimum alternate that is capable of handing the bandwidth needed by the stream. As there's no standard way, at USB core, to set an isoc bandwidth [1], each driver has its own logic for doing that, and maybe some strategies are better than the others. I'm not sure if it would be simpler or possible, but an alternative way would be to have something like usb_request_bandwidth(), where the USB core would have the logic to set the interface alternates to fulfill the bandwidth needs, or return -EINVAL if it is not possible. The advantage is that you won't need to fix all the different logics used by the V4L/DVB drivers. [1] On some devices, even needing a constant bandwitdh, they only support bulk transfers, due to hardware limitation, but, from the driver's perspective, the seek for the alternate has an identical need. Hi Mauro, Contrary to other webcam drivers, gspca already has a fallback to a different altsetting. Actually, this is done at URB submit time and it works correctly, mainly with USB-1.1. It seems that the bandwidth may be now checked when setting the altsetting. The proposed patch does not change the gspca logic at all. Maybe it could be done in a clearer way. A first problem with webcams is that the bandwidth is not fully known when starting the capture. The frame rate may be changed during streaming either by direct video control (rare) or by changing the exposure time (manual or automatic - AEC). Also, the video stream is often compressed and the compression ratio is not well known (some webcams automatically change the JPEG quality). The second problem is the USB interface. If a driver could calculate a good estimation of the needed bandwidth, it cannot actually tell it to the USB subsystem. The USB subsystem uses the packet length and the message interval to calculate the bandwidth that the device will use. This is indeed not correct because the device does not send data at the full interface speed. In an other way, a driver could search the alternate setting which matches the best its estimated bandwidth, but I am not sure that this will not slow down the frame rate (more USB packets for the same data
Re: [hg:v4l-dvb] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 10.05.2010 06:40, Patch from Klaus Schmidinger wrote: The patch number 14692 was added via Douglas Schilling Landgraf dougsl...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org This patch should not have been applied, as was decided in the original thread. I'm still waiting for any response to my new patch, posted in [PATCH] Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices) which replaces my original suggestion. Klaus -- From: Klaus Schmidinger klaus.schmidin...@tvdr.de Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. Priority: normal Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com Acked-by: Manu Abraham m...@linuxtv.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c |2 +- linux/drivers/media/dvb/frontends/cx24116.c |2 +- linux/include/linux/dvb/frontend.h |1 + 3 files changed, 3 insertions(+), 2 deletions(-) diff -r 31df1af24206 -r 0eabd1e76386 linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c --- a/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c Mon May 10 01:31:11 2010 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c Mon May 10 01:32:52 2010 -0300 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 +FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8 }, .release = gp8psk_fe_release, diff -r 31df1af24206 -r 0eabd1e76386 linux/drivers/media/dvb/frontends/cx24116.c --- a/linux/drivers/media/dvb/frontends/cx24116.c Mon May 10 01:31:11 2010 -0300 +++ b/linux/drivers/media/dvb/frontends/cx24116.c Mon May 10 01:32:52 2010 -0300 @@ -1496,7 +1496,7 @@ FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_2G_MODULATION | - FE_CAN_QPSK | FE_CAN_RECOVER +FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8 }, .release = cx24116_release, diff -r 31df1af24206 -r 0eabd1e76386 linux/include/linux/dvb/frontend.h --- a/linux/include/linux/dvb/frontend.h Mon May 10 01:31:11 2010 -0300 +++ b/linux/include/linux/dvb/frontend.h Mon May 10 01:32:52 2010 -0300 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB= 0x40, FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8= 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING= 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- Patch is available at: http://linuxtv.org/hg/v4l-dvb/rev/0eabd1e76386c37db6cef0a608901d3dd04a301f -- 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
Analog FM radio support for dib0700
Hi, I am working on project for monitoring analog FM radio stations in our Country and I need to find USB device which is supported under Linux including FM radio. I can't find such device for very long time (6 months), only AverTV Volar HX with binary drivers and very unstable linux drivers. So I am considering to pay for analog FM radio support for dib0700 devices. + I need this support in next 25 days, later is too late. + I can pay for adding FM radio maximum 1000 USD or 800 EUR (it depends on many factors such as accepting patches by linuxtv tree). If there is anyone intereseted please write me message. Miroslav Slugen Czech Republic thunde...@email.cz -- 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:Mon May 10 19:00:21 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14707:82a84ed1d76b git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 08b8618ac4dbcd05ec1886853b1d865798d26e1d 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: ERRORS linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
[PATCH] saa7134: add RM-K6 remote control support for Avermedia M135A
This change adds support for one more remote control type for Avermedia
M135A (model RM-K6), shipped with Positivo machines.
Signed-off-by: Herton Ronaldo Krzesinski her...@mandriva.com.br
---
drivers/media/IR/keymaps/Makefile |2 +-
.../media/IR/keymaps/rc-avermedia-m135a-rm-jx.c| 90
drivers/media/IR/keymaps/rc-avermedia-m135a.c | 147
drivers/media/video/saa7134/saa7134-input.c|2 +-
include/media/rc-map.h |2 +-
5 files changed, 150 insertions(+), 93 deletions(-)
delete mode 100644 drivers/media/IR/keymaps/rc-avermedia-m135a-rm-jx.c
create mode 100644 drivers/media/IR/keymaps/rc-avermedia-m135a.c
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 585f75c..aea649f 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -6,7 +6,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-avermedia.o \
rc-avermedia-cardbus.o \
rc-avermedia-dvbt.o \
- rc-avermedia-m135a-rm-jx.o \
+ rc-avermedia-m135a.o \
rc-avermedia-m733a-rm-k6.o \
rc-avertv-303.o \
rc-behold.o \
diff --git a/drivers/media/IR/keymaps/rc-avermedia-m135a-rm-jx.c
b/drivers/media/IR/keymaps/rc-avermedia-m135a-rm-jx.c
deleted file mode 100644
index 101e7ea..000
--- a/drivers/media/IR/keymaps/rc-avermedia-m135a-rm-jx.c
+++ /dev/null
@@ -1,90 +0,0 @@
-/* avermedia-m135a-rm-jx.h - Keytable for avermedia_m135a_rm_jx Remote
Controller
- *
- * keymap imported from ir-keymaps.c
- *
- * Copyright (c) 2010 by Mauro Carvalho Chehab mche...@redhat.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.
- */
-
-#include media/rc-map.h
-
-/*
- * Avermedia M135A with IR model RM-JX
- * The same codes exist on both Positivo (BR) and original IR
- * Mauro Carvalho Chehab mche...@infradead.org
- */
-
-static struct ir_scancode avermedia_m135a_rm_jx[] = {
- { 0x0200, KEY_POWER2 },
- { 0x022e, KEY_DOT },/* '.' */
- { 0x0201, KEY_MODE }, /* TV/FM or SOURCE */
-
- { 0x0205, KEY_1 },
- { 0x0206, KEY_2 },
- { 0x0207, KEY_3 },
- { 0x0209, KEY_4 },
- { 0x020a, KEY_5 },
- { 0x020b, KEY_6 },
- { 0x020d, KEY_7 },
- { 0x020e, KEY_8 },
- { 0x020f, KEY_9 },
- { 0x0211, KEY_0 },
-
- { 0x0213, KEY_RIGHT }, /* - or L */
- { 0x0212, KEY_LEFT }, /* - or R */
-
- { 0x0217, KEY_SLEEP }, /* Capturar Imagem or Snapshot */
- { 0x0210, KEY_SHUFFLE },/* Amostra or 16 chan prev */
-
- { 0x0303, KEY_CHANNELUP },
- { 0x0302, KEY_CHANNELDOWN },
- { 0x021f, KEY_VOLUMEUP },
- { 0x021e, KEY_VOLUMEDOWN },
- { 0x020c, KEY_ENTER }, /* Full Screen */
-
- { 0x0214, KEY_MUTE },
- { 0x0208, KEY_AUDIO },
-
- { 0x0203, KEY_TEXT }, /* Teletext */
- { 0x0204, KEY_EPG },
- { 0x022b, KEY_TV2 },/* TV2 or PIP */
-
- { 0x021d, KEY_RED },
- { 0x021c, KEY_YELLOW },
- { 0x0301, KEY_GREEN },
- { 0x0300, KEY_BLUE },
-
- { 0x021a, KEY_PLAYPAUSE },
- { 0x0219, KEY_RECORD },
- { 0x0218, KEY_PLAY },
- { 0x021b, KEY_STOP },
-};
-
-static struct rc_keymap avermedia_m135a_rm_jx_map = {
- .map = {
- .scan= avermedia_m135a_rm_jx,
- .size= ARRAY_SIZE(avermedia_m135a_rm_jx),
- .ir_type = IR_TYPE_NEC,
- .name= RC_MAP_AVERMEDIA_M135A_RM_JX,
- }
-};
-
-static int __init init_rc_map_avermedia_m135a_rm_jx(void)
-{
- return ir_register_map(avermedia_m135a_rm_jx_map);
-}
-
-static void __exit exit_rc_map_avermedia_m135a_rm_jx(void)
-{
- ir_unregister_map(avermedia_m135a_rm_jx_map);
-}
-
-module_init(init_rc_map_avermedia_m135a_rm_jx)
-module_exit(exit_rc_map_avermedia_m135a_rm_jx)
-
-MODULE_LICENSE(GPL);
-MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
diff --git a/drivers/media/IR/keymaps/rc-avermedia-m135a.c
b/drivers/media/IR/keymaps/rc-avermedia-m135a.c
new file mode 100644
index 000..e4471fb
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-avermedia-m135a.c
@@ -0,0 +1,147 @@
+/* avermedia-m135a.c - Keytable for Avermedia M135A Remote Controllers
+ *
+ * Copyright (c) 2010 by Mauro Carvalho Chehab mche...@redhat.com
+ * Copyright (c) 2010 by Herton Ronaldo Krzesinski her...@mandriva.com.br
+ *
+ * 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
Re: Status of the patches under review (85 patches) and some misc notes about the devel procedures
Em Sáb 08 Mai 2010, às 19:41:32, Mauro Carvalho Chehab escreveu: Herton Ronaldo Krzesinski wrote: Em Sex 07 Mai 2010, às 09:39:16, Mauro Carvalho Chehab escreveu: == Patch(broken) - waiting for Herton Ronaldo Krzesinski her...@mandriva.com.br new submission == Apr, 5 2010: saa7134: add support for Avermedia M733A http://patchwork.kernel.org/patch/90692 Hi, I submitted now a new fixed version of the patch to mailing list, under title [PATCH v2] saa7134: add support for Avermedia M733A OK, thanks! Mar,19 2010: saa7134: add support for one more remote control for Avermedia M135A http://patchwork.kernel.org/patch/86989 This was the addition of RM-K6 remote control to M135A too, I think we can drop this, since adding this to the kernel is deprecated now in favour of assigning keymaps in userspace (keytable tool from v4l-utils), right? For now, I prefer to add the keytab there, since there are some scripts that syncs v4l-util keytables with the kernel ones. If you prefer, you may the put RM-K6 table together with the other M135A keytable. I intend to group the non-conflicting keytables soon, and it makes kense to group both the original and the RM-K6 into the same table, in order to provide an easier hot-plug support for this device. Ok, I updated and tested a new patch now, and sent with title [PATCH] saa7134: add RM-K6 remote control support for Avermedia M135A -- []'s Herton -- 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: Status of the patches under review (85 patches) and some misc notes about the devel procedures
Herton Ronaldo Krzesinski wrote: Em Sáb 08 Mai 2010, às 19:41:32, Mauro Carvalho Chehab escreveu: Herton Ronaldo Krzesinski wrote: Em Sex 07 Mai 2010, às 09:39:16, Mauro Carvalho Chehab escreveu: == Patch(broken) - waiting for Herton Ronaldo Krzesinski her...@mandriva.com.br new submission == Apr, 5 2010: saa7134: add support for Avermedia M733A http://patchwork.kernel.org/patch/90692 Hi, I submitted now a new fixed version of the patch to mailing list, under title [PATCH v2] saa7134: add support for Avermedia M733A OK, thanks! Mar,19 2010: saa7134: add support for one more remote control for Avermedia M135A http://patchwork.kernel.org/patch/86989 This was the addition of RM-K6 remote control to M135A too, I think we can drop this, since adding this to the kernel is deprecated now in favour of assigning keymaps in userspace (keytable tool from v4l-utils), right? For now, I prefer to add the keytab there, since there are some scripts that syncs v4l-util keytables with the kernel ones. If you prefer, you may the put RM-K6 table together with the other M135A keytable. I intend to group the non-conflicting keytables soon, and it makes kense to group both the original and the RM-K6 into the same table, in order to provide an easier hot-plug support for this device. Ok, I updated and tested a new patch now, and sent with title [PATCH] saa7134: add RM-K6 remote control support for Avermedia M135A Thanks! -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [hg:v4l-dvb] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
Klaus Schmidinger wrote: On 10.05.2010 06:40, Patch from Klaus Schmidinger wrote: The patch number 14692 was added via Douglas Schilling Landgraf dougsl...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org This patch should not have been applied, as was decided in the original thread. Douglas is synchronizing with git. As the revert patch is a separate patch, he'll probably apply it later, after finishing sync with -git. I'm still waiting for any response to my new patch, posted in [PATCH] Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices) which replaces my original suggestion. Your new patch is already queued at Patchwork. In order to avoid the risk of applying it earlier, I'm waiting for some more acks/comments before applying it. If nothing happens, I'll queue it for 2.6.35, since, for me your new patch is ok. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Analog FM radio support for dib0700
On Mon, May 10, 2010 at 8:11 PM, Mirek Slugeň thunde...@email.cz wrote: Hi, I am working on project for monitoring analog FM radio stations in our Country and I need to find USB device which is supported under Linux including FM radio. I can't find such device for very long time (6 months), only AverTV Volar HX with binary drivers and very unstable linux drivers. So I am considering to pay for analog FM radio support for dib0700 devices. + I need this support in next 25 days, later is too late. + I can pay for adding FM radio maximum 1000 USD or 800 EUR (it depends on many factors such as accepting patches by linuxtv tree). If there is anyone intereseted please write me message. * FM Radio (including RDS) * Analog TV * Digital TV http://support.sundtek.com/index.php/topic,4.0.html Those devices are also used in the industrial field, depending on the volume we can also provide FM Radio USB dongles only (USB Audio Class based) That way you can get started quickly with your project. Best Regards, Markus Rechberger -- 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: Confusing mediabus formats
(added Laurent to CC as he once asked me about these on IRC too) On Sun, 9 May 2010, Hans Verkuil wrote: Hi Guennadi, I'm preparing a patch series that replaces enum/g/try/s_fmt with enum/g/try/s/_mbus_fmt in all subdevs. While doing that I stumbled on a confusing definition of the YUV mediabus formats. Currently we have these: V4L2_MBUS_FMT_YUYV8_2X8_LE, V4L2_MBUS_FMT_YVYU8_2X8_LE, V4L2_MBUS_FMT_YUYV8_2X8_BE, V4L2_MBUS_FMT_YVYU8_2X8_BE, The meaning of 2X8 is defined as: 'one pixel is transferred in two 8-bit samples'. This is confusing since you cannot really say that a Y and U pair constitutes one pixel. And is it Y or U/V which constitutes the 'most-significant bits' in such a 16-bit number? To recap, as we discussed it earlier this notation was one of your suggestions: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/12830/focus=13394 Yes, I certainly agree, that LE and BE notations are not necessarily very logical here, as you say, they don't make much sense in the YUV case. But they do, e.g., in RGB565 case, as we discussed this with Laurent on IRC. Basically, the information we want to include in the name is: pixel format family (YUYV8) number of samples, that constitute one pixel (*) and bits per sample order of samples in pixel (*) pixel is not necessarily a complete pixel, i.e., might not carry all colours in it. E.g., in YUYV pixel refers to any of the YU and YV pairs. In other words, this is just = frame size * 8 / number of pixels / bits-per-sample. In my particular case I have to translate a V4L2_PIX_FMT_UYVY to a suitable mediabus format. I think it would map to V4L2_MBUS_FMT_YUYV8_2X8_LE, but frankly I'm not sure. My suggestion is to rename these mediabus formats to: V4L2_MBUS_FMT_YUYV8_1X8, V4L2_MBUS_FMT_YVYU8_1X8, V4L2_MBUS_FMT_UYVY8_1X8, V4L2_MBUS_FMT_VYUY8_1X8, But what do you do with, e.g., RGB565? You have to differentiate between rggb bggr gggrbggg gggbrggg with the current notation they are RGB565_2X8_BE BGR565_2X8_BE BGR565_2X8_LE RGB565_2X8_LE and how would you call them? And what do you do with Y10_2X8_LE and _BE (padding omitted for simplicity)? Also, Laurent has suggested V4L2_MBUS_FMT_YUYV8_2X8, V4L2_MBUS_FMT_YVYU8_2X8, V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_VYUY8_2X8, and I like that better, than 1X8, but still it doesn't resolve my above doubts. Ideas? Suggestions? Here it is immediately clear what is going on. This scheme is also used with the Bayer formats, so it would be consistent with that as well. However, does V4L2_MBUS_FMT_YUYV8_2X8_LE map to V4L2_MBUS_FMT_YUYV8_1X8 or to V4L2_MBUS_FMT_UYVY8_1X8? I still don't know. What do you think? 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: [hg:v4l-dvb] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On Mon, May 10, 2010 at 9:45 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 10.05.2010 06:40, Patch from Klaus Schmidinger wrote: The patch number 14692 was added via Douglas Schilling Landgraf dougsl...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org This patch should not have been applied, as was decided in the original thread. I'm still waiting for any response to my new patch, posted in [PATCH] Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices) which replaces my original suggestion. I did a reply but that happened to be on another thread on patchwork, but here it is again. Reviewed-by: Manu Abraham manu at linuxtv.org Acked-by: Manu Abraham manu at linuxtv.org -- 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: [hg:v4l-dvb] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
Hello Klaus, On Mon, May 10, 2010 at 2:45 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 10.05.2010 06:40, Patch from Klaus Schmidinger wrote: The patch number 14692 was added via Douglas Schilling Landgraf dougsl...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org This patch should not have been applied, as was decided in the original thread. The patch was reverted yesterday during the hg - git sync. http://linuxtv.org/hg/v4l-dvb/rev/9b6b81d5efbd Thanks Douglas -- 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] soc_camera_platform: Add necessary v4l2_subdev_video_ops method
These function are needed to use camera.
This patch was tested with sh_mobile_ceu_camera
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
drivers/media/video/soc_camera_platform.c | 39 +
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_camera_platform.c
b/drivers/media/video/soc_camera_platform.c
index 10b003a..d36f732 100644
--- a/drivers/media/video/soc_camera_platform.c
+++ b/drivers/media/video/soc_camera_platform.c
@@ -83,10 +83,49 @@ static int soc_camera_platform_enum_fmt(struct v4l2_subdev
*sd, int index,
return 0;
}
+static int soc_camera_platform_g_crop(struct v4l2_subdev *sd, struct v4l2_crop
*a)
+{
+ struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
+
+ a-c.left = 0;
+ a-c.top= 0;
+ a-c.width = p-format.width;
+ a-c.height = p-format.height;
+ a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+
+ return 0;
+}
+
+static int soc_camera_platform_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
+{
+ struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
+
+ a-bounds.left = 0;
+ a-bounds.top = 0;
+ a-bounds.width = p-format.width;
+ a-bounds.height= p-format.height;
+ a-defrect = a-bounds;
+ a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ a-pixelaspect.numerator= 1;
+ a-pixelaspect.denominator = 1;
+
+ return 0;
+}
+
+static int soc_camera_platform_s_fmt(struct v4l2_subdev *sd,
+struct v4l2_mbus_framefmt *mf)
+{
+ return 0;
+}
+
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
+ .cropcap= soc_camera_platform_cropcap,
+ .g_crop = soc_camera_platform_g_crop,
+ .g_mbus_fmt = soc_camera_platform_try_fmt,
+ .s_mbus_fmt = soc_camera_platform_s_fmt,
};
static struct v4l2_subdev_ops platform_subdev_ops = {
--
1.6.3.3
--
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
