Re: V4L hg tree fails to compile against latest stable kernel 2.6.35
On Mon, Aug 2, 2010 at 11:36 PM, VDR User wrote: > Any idea when this will be fixed? Sorry, forgot to paste in the details: make -C /lib/modules/2.6.35.amd.080210.2/build SUBDIRS=/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-2.6.35' CC [M] /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvbdev.o CC [M] /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dmxdev.o CC [M] /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_demux.o CC [M] /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_filter.o CC [M] /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_ca_en50221.o CC [M] /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_frontend.o CC [M] /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.o /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1190: warning: 'struct dev_mc_list' declared inside parameter list /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1190: warning: its scope is only this definition or declaration, which is probably not what you want /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c: In function 'dvb_set_mc_filter': /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1197: error: dereferencing pointer to incomplete type /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c: In function 'wq_set_multicast_list': /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1247: error: 'struct net_device' has no member named 'mc_list' /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1249: error: dereferencing pointer to incomplete type /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1249: warning: left-hand operand of comma expression has no effect /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1249: warning: value computed is not used /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1250: warning: passing argument 2 of 'dvb_set_mc_filter' from incompatible pointer type /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1190: note: expected 'struct dev_mc_list *' but argument is of type 'struct dev_mc_list *' make[3]: *** [/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.o] Error 1 make[2]: *** [_module_/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.35' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l' make: *** [all] Error 2 -- 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
V4L hg tree fails to compile against latest stable kernel 2.6.35
Any idea when this will be fixed? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL REQUEST] IR and lirc updates for pre-2.6.36-rc1
Hey Mauro, First time trying this route out, so hopefully, I've gotten it right... ;) This tree was based on the linuxtv v4l-dvb.git staging/other branch as of the referenced commit, and should contain all the currently pending bits I've got. I believe the two staging/lirc fixes may already be merged (since they were to fix specific linux-next build breakages), but I don't believe the rest are, and as I understand it, you have handy-dandy scripts to filter out what's already merged anyway. On with the show... Hopefully, gmail's web ui doesn't butcher the output too badly... The following changes since commit 520d05b87c4b631fc9c4482c989adfd45f0a549c: V4L/DVB: staging/lirc: CodingStyle cleanups (2010-07-27 18:44:45 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-lirc.git staging Janne Grunau (1): V4L/DVB: staging/lirc: fix Kconfig dependencies Jarod Wilson (7): IR/imon: remove incorrect calls to input_free_device IR/imon: remove bad ir_input_dev use IR/mceusb: remove bad ir_input_dev use staging/lirc: fix non-CONFIG_MODULES build horkage IR/mceusb: less generic callback name and remove cruft staging/lirc: port lirc_streamzap to ir-core IR: put newly ported streamzap driver in proper home drivers/media/IR/Kconfig| 12 + drivers/media/IR/Makefile |1 + drivers/media/IR/imon.c | 20 +- drivers/media/IR/keymaps/Makefile |1 + drivers/media/IR/keymaps/rc-rc5-streamzap.c | 81 +++ drivers/media/IR/mceusb.c | 21 +- drivers/media/IR/streamzap.c| 741 drivers/staging/lirc/Kconfig| 23 +- drivers/staging/lirc/Makefile |1 - drivers/staging/lirc/lirc_it87.c|9 +- drivers/staging/lirc/lirc_parallel.c|4 +- drivers/staging/lirc/lirc_streamzap.c | 821 --- include/media/rc-map.h |1 + 13 files changed, 858 insertions(+), 878 deletions(-) create mode 100644 drivers/media/IR/keymaps/rc-rc5-streamzap.c create mode 100644 drivers/media/IR/streamzap.c delete mode 100644 drivers/staging/lirc/lirc_streamzap.c -- 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: [Q]: any DVB-S2 card which is 45MS/s capable?
Marko Ristola a écrit : Hi. I have written some Mantis bandwidth related DMA transfer optimizations on June/July this year. They are now waiting for approval by Manu Abraham. Those reduce CPU pressure, increasing the bandwidth that can be received from the DVB card. 45MS/s bandwidth support will surely benefit from those patches. Main features: 1. Do one CPU interrupt per 16KB data instead per 4KB data. My implementation benefits only Mantis cards. https://patchwork.kernel.org/patch/107036/ 2. Remove unnecessary big CPU overhead, when data is delivered from the DVB card's DMA buffer into Linux kernel's DVB subsystem. Number 2 reduces the CPU pressure by almost 50%. This implementation benefits many other Linux supported DVB cards too. http://patchwork.kernel.org/patch/108274/ Those helped with my older single CPU Core computer with 256-QAM, delivering HDTV channel into the network and watching the HDTV channel with a faster computer. The performance bottlenecks could be seen on the command line with "perf top". I had to increase PCI bus latency setting into 64 too from the BIOS. Moving DVB device into separate IRQ line with Ethernet card helped too, because Ethernet card did an interrupt per ethernet packet. So if the hardware can deliver 45MS/s data fast enough, software side can be optimized up to some point. My patches contain the most easy major optimizations that I found. If you can test some of those patches, it might help to get them into Linux kernel faster. Best regards, Marko Ristola OK these optimizations look like a step into the good direction. I guess what is also missing is a tuner which can handle that in DVB-S2, which does not seem obvious. The mantis card can do that? Thx Bye Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
On Tue, Aug 3, 2010 at 9:46 AM, Kukjin Kim wrote: > Russell King wrote: >> >> On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote: >> > >Russell King - ARM Linux wrote: >> > >On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: >> > >> Well, some of them are indeed unused, but it's not an uncommon > practice in >> > >> kernel and might help future developers. >> > > >> > >On the other hand, arch/arm is getting soo big that we need to do >> > >something about this - and one solution is to avoid unnecessary >> > >definitions that we're not using. >> > > >> > >Another good idea is to put definitions along side the drivers which >> > >they're relevant to - maybe in a local driver-name.h file which >> > >driver-name.c includes, or maybe even within driver-name.c if they're >> > >not excessive. This has the advantage of distributing the "bloat" to >> > >where its actually used, and means that the driver isn't dependent so >> > >much on arch/arm or even the SoC itself. >> > > >> > >Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and >> > >arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only >> > >two files which contain platform definitions which are actually used >> > >for Versatile Express. Compare that with >> > >arch/arm/mach-realview/include/mach/platform.h which contains lots >> > >more... >> > >> > So basically, what you and Mauro are recommending is that we move the > *.h >> > file with register definitions to drivers/media? >> >> What I'm suggesting is what's been pretty standard in Linux for a long >> time. Take a look at: drivers/net/3c503.[ch], or for a more recent >> driver, drivers/net/e1000/*.[ch]. Or drivers/mmc/host/mmci.[ch] >> > I agree with Russell's opinion. > I don't want to add unnecessary(or unavailable in arch/arm) definitions in > arch/arm/*/include > >> Putting definitions which are only used by one driver in > arch/arm/*/include >> is silly. I also happy with this method. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick
Hi Richard,
Em 02-08-2010 04:27, Richard Zidlicky escreveu:
> On Sun, Aug 01, 2010 at 05:17:18PM -0300, Mauro Carvalho Chehab wrote:
>> Add the proper gpio port for WinTV MiniStick, with the information provided
>> by Michael.
>>
>> Thanks-to: Michael Krufky
>> Signed-off-by: Mauro Carvalho Chehab
>>
>> diff --git a/drivers/media/dvb/siano/sms-cards.c
>> b/drivers/media/dvb/siano/sms-cards.c
>> index cff77e2..dcde606 100644
>> --- a/drivers/media/dvb/siano/sms-cards.c
>> +++ b/drivers/media/dvb/siano/sms-cards.c
>> @@ -67,6 +67,7 @@ static struct sms_board sms_boards[] = {
>> .board_cfg.leds_power = 26,
>> .board_cfg.led0 = 27,
>> .board_cfg.led1 = 28,
>> +.board_cfg.ir = 9,
>
>
> are you sure about this?
>
> I am using the value of 4 for the ir port and it definitely works.. confused.
I got this from a reliable source, and that worked perfectly my with a Model
55009
LF Rev B1F7. What's the model of your device?
> Thanks for looking at it, will test the patches as soon as I can.
I'd appreciate if you could test those patches, as the new implementation is
feature-rich,
as it uses the in-kernel decoders via RC subsystem.
>
> Richard
> --
> 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
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: [PATCH 1/2] staging/lirc: port lirc_streamzap to ir-core
On Mon, Aug 02, 2010 at 09:24:14PM -0300, Mauro Carvalho Chehab wrote: > Em 02-08-2010 19:35, Greg KH escreveu: > > On Mon, Aug 02, 2010 at 05:29:22PM -0400, Jarod Wilson wrote: > >> drivers/media/IR/keymaps/Makefile |1 + > > > > Uppercase "IR"? Any reason why you all picked that? > > Infra Red. Well, it were not probably a good idea ;) > > Anyway, I intend to rename it to "rc" (for Remote Controller), change lots of > internal structures and eventually move it to drivers/ or drivers/input, as > the > idea is to use the subsystem also to other kinds of remote controllers. > > I'll likely do it after finishing the merge of the pending patches, and send > upstream during this merge window. It seems better to rename during the merge > window. Renames are usually good for after -rc1 is out to help everyone sync up better. thanks, greg k-h > > > > Just curious. > > > > greg k-h > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > 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: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
Russell King wrote: > > On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote: > > >Russell King - ARM Linux wrote: > > >On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: > > >> Well, some of them are indeed unused, but it's not an uncommon practice in > > >> kernel and might help future developers. > > > > > >On the other hand, arch/arm is getting soo big that we need to do > > >something about this - and one solution is to avoid unnecessary > > >definitions that we're not using. > > > > > >Another good idea is to put definitions along side the drivers which > > >they're relevant to - maybe in a local driver-name.h file which > > >driver-name.c includes, or maybe even within driver-name.c if they're > > >not excessive. This has the advantage of distributing the "bloat" to > > >where its actually used, and means that the driver isn't dependent so > > >much on arch/arm or even the SoC itself. > > > > > >Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and > > >arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only > > >two files which contain platform definitions which are actually used > > >for Versatile Express. Compare that with > > >arch/arm/mach-realview/include/mach/platform.h which contains lots > > >more... > > > > So basically, what you and Mauro are recommending is that we move the *.h > > file with register definitions to drivers/media? > > What I'm suggesting is what's been pretty standard in Linux for a long > time. Take a look at: drivers/net/3c503.[ch], or for a more recent > driver, drivers/net/e1000/*.[ch]. Or drivers/mmc/host/mmci.[ch] > I agree with Russell's opinion. I don't want to add unnecessary(or unavailable in arch/arm) definitions in arch/arm/*/include > Putting definitions which are only used by one driver in arch/arm/*/include > is silly. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] staging/lirc: port lirc_streamzap to ir-core
Em 02-08-2010 19:35, Greg KH escreveu: > On Mon, Aug 02, 2010 at 05:29:22PM -0400, Jarod Wilson wrote: >> drivers/media/IR/keymaps/Makefile |1 + > > Uppercase "IR"? Any reason why you all picked that? Infra Red. Well, it were not probably a good idea ;) Anyway, I intend to rename it to "rc" (for Remote Controller), change lots of internal structures and eventually move it to drivers/ or drivers/input, as the idea is to use the subsystem also to other kinds of remote controllers. I'll likely do it after finishing the merge of the pending patches, and send upstream during this merge window. It seems better to rename during the merge window. > > Just curious. > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html 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: [PATCH 1/2] staging/lirc: port lirc_streamzap to ir-core
On Mon, Aug 02, 2010 at 05:29:22PM -0400, Jarod Wilson wrote: > drivers/media/IR/keymaps/Makefile |1 + Uppercase "IR"? Any reason why you all picked that? Just curious. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Avermedia Avertv DVB-T Super 007 PCI (M135D)
Hello all, I'm interested in buying a PCI DVB-T card that is available cheaply in NZ and is supported by Gnu/Linux and MythTV. I only need one DVB-T tuner, as I have a dual-tuner already and our region only has three multiplexes (so three will do everything with multirec). The best bet that I have found so far is the Avermedia Avertv DVB-T Super 007 PCI Digital Terrestrial Television Receiver Card (M135D): http://www.alphacity.co.nz/index.php?main_page=product_info&cPath=261&products_id=61014 Looking on the wikis: http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_DVB-T_Super_007 ( http://www.mythtv.org/wiki/AVerTV_DVB-T_Super_007 has virtually nothing) "It is currently not supported under Linux. However, experimental support exists (see below for details)." Lower down, it says that "As of January 25, 2008: DVB-T works fine with modules from the Mercurial (hg) repository. This is a DVB-T card only." I have searched Google for any update on this card, but the best that I could find was this: http://ubuntuforums.org/showthread.php?t=1537985 I had thought that, if the card worked fine with modules in testing back in 2008, the drivers may have made it into the main releases by now. Have they? If I want to use this card with MythTV (on Mythbuntu), will I have to pull down the Mercurial repository and compile the drivers myself from there as set out in that ubuntuforums post? Thanks in advance, Aaron -- 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] IR: put newly ported streamzap driver in proper home
Moves drivers/staging/lirc/lirc_streamzap.c to
drivers/media/IR/streamzap.c, along with making the requisite Kconfig
and Makefile changes.
Signed-off-by: Jarod Wilson
---
drivers/media/IR/Kconfig | 12 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/streamzap.c | 741 +
drivers/staging/lirc/Kconfig |6 -
drivers/staging/lirc/Makefile |1 -
drivers/staging/lirc/lirc_streamzap.c | 741 -
6 files changed, 754 insertions(+), 748 deletions(-)
create mode 100644 drivers/media/IR/streamzap.c
delete mode 100644 drivers/staging/lirc/lirc_streamzap.c
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index e557ae0..19a9003 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -102,3 +102,15 @@ config IR_MCEUSB
To compile this driver as a module, choose M here: the
module will be called mceusb.
+
+config IR_STREAMZAP
+ tristate "Streamzap PC Remote IR Receiver"
+ depends on USB_ARCH_HAS_HCD
+ depends on IR_CORE
+ select USB
+ ---help---
+ Say Y here if you want to use a Streamzap PC Remote
+ Infrared Receiver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called streamzap.
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 2ae4f3a..2566fb4 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
diff --git a/drivers/media/IR/streamzap.c b/drivers/media/IR/streamzap.c
new file mode 100644
index 000..058e29f
--- /dev/null
+++ b/drivers/media/IR/streamzap.c
@@ -0,0 +1,741 @@
+/*
+ * Streamzap Remote Control driver
+ *
+ * Copyright (c) 2005 Christoph Bartelmus
+ * Copyright (c) 2010 Jarod Wilson
+ *
+ * This driver was based on the work of Greg Wickham and Adrian
+ * Dewhurst. It was substantially rewritten to support correct signal
+ * gaps and now maintains a delay buffer, which is used to present
+ * consistent timing behaviour to user space applications. Without the
+ * delay buffer an ugly hack would be required in lircd, which can
+ * cause sluggish signal decoding in certain situations.
+ *
+ * Ported to in-kernel ir-core interface by Jarod Wilson
+ *
+ * This driver is based on the USB skeleton driver packaged with the
+ * kernel; copyright (C) 2001-2003 Greg Kroah-Hartman (g...@kroah.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
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "1.60"
+#define DRIVER_NAME"streamzap"
+#define DRIVER_DESC"Streamzap Remote Control driver"
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 1;
+#else
+static int debug;
+#endif
+
+#define USB_STREAMZAP_VENDOR_ID0x0e9c
+#define USB_STREAMZAP_PRODUCT_ID 0x
+
+/* table of devices that work with this driver */
+static struct usb_device_id streamzap_table[] = {
+ /* Streamzap Remote Control */
+ { USB_DEVICE(USB_STREAMZAP_VENDOR_ID, USB_STREAMZAP_PRODUCT_ID) },
+ /* Terminating entry */
+ { }
+};
+
+MODULE_DEVICE_TABLE(usb, streamzap_table);
+
+#define STREAMZAP_PULSE_MASK 0xf0
+#define STREAMZAP_SPACE_MASK 0x0f
+#define STREAMZAP_TIMEOUT0xff
+#define STREAMZAP_RESOLUTION 256
+
+/* number of samples buffered */
+#define SZ_BUF_LEN 128
+
+enum StreamzapDecoderState {
+ PulseSpace,
+ FullPulse,
+ FullSpace,
+ IgnorePulse
+};
+
+/* structure to hold our device specific stuff */
+struct streamzap_ir {
+
+ /* ir-core */
+ struct ir_dev_props *props;
+ struct ir_raw_event rawir;
+
+ /* core device info */
+ struct device *dev;
+ struct input_dev *idev;
+
+ /* usb */
+ struct usb_device *usbdev;
+ struct usb_interface*interface;
+ struct usb_endpoint_descriptor *endpoint;
+ struct urb *urb_in;
+
+ /* buffer & dma */
+ unsigned char *buf_in;
+ dma_addr_t dma_in;
[PATCH 1/2] staging/lirc: port lirc_streamzap to ir-core
This ports lirc_streamzap.c over to ir-core in-place, to be followed by
a patch moving the driver over to drivers/media/IR/streamzap.c and
enabling the proper Kconfig bits.
Presently, the in-kernel keymap doesn't work, as the stock Streamzap
remote uses an RC-5-like, but not-quite-RC-5 protocol, which the
in-kernel RC-5 decoder doesn't cope with. The remote can be used right
now with the lirc bridge driver though, and other remotes (at least an
RC-6(A) MCE remote) work perfectly with the driver.
I'll take a look at making the existing RC-5 decoder cope with this odd
duck, possibly implement another standalone decoder engine, or just
throw up my hands and say "meh, use lirc"... But the driver itself
should be perfectly sound.
Remaining items on the streamzap TODO list:
- add LIRC_SET_REC_TIMEOUT-alike support
- add LIRC_GET_M{AX,IN}_TIMEOUT-alike support
- add LIRC_GET_REC_RESOLUTION-alike support
All of the above should be trivial to add. There are patches pending to
add this support to ir-core from Maxim Levitsky, and I'll take care of
these once his patches get integrated. None of them are currently
essential though.
CC: Maxim Levitsky
CC: Christoph Bartelmus
Signed-off-by: Jarod Wilson
---
drivers/media/IR/keymaps/Makefile |1 +
drivers/media/IR/keymaps/rc-rc5-streamzap.c | 81 +++
drivers/staging/lirc/lirc_streamzap.c | 812 ---
include/media/rc-map.h |1 +
4 files changed, 449 insertions(+), 446 deletions(-)
create mode 100644 drivers/media/IR/keymaps/rc-rc5-streamzap.c
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 86d3d1f..af81224 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-purpletv.o \
rc-pv951.o \
rc-rc5-hauppauge-new.o \
+ rc-rc5-streamzap.o \
rc-rc5-tv.o \
rc-rc6-mce.o \
rc-real-audio-220-32-keys.o \
diff --git a/drivers/media/IR/keymaps/rc-rc5-streamzap.c
b/drivers/media/IR/keymaps/rc-rc5-streamzap.c
new file mode 100644
index 000..4c19c58
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-rc5-streamzap.c
@@ -0,0 +1,81 @@
+/* rc-rc5-streamzap.c - Keytable for Streamzap PC Remote, for use
+ * with the Streamzap PC Remote IR Receiver.
+ *
+ * Copyright (c) 2010 by Jarod Wilson
+ *
+ * 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
+
+static struct ir_scancode rc5_streamzap[] = {
+/*
+ * FIXME: The Streamzap remote isn't actually true RC-5, it has an extra
+ * bit in it, which presently throws the in-kernel RC-5 decoder for a loop.
+ * We either have to enhance the decoder to support it, add a new decoder,
+ * or just rely on lirc userspace decoding.
+ */
+ { 0x00, KEY_NUMERIC_0 },
+ { 0x01, KEY_NUMERIC_1 },
+ { 0x02, KEY_NUMERIC_2 },
+ { 0x03, KEY_NUMERIC_3 },
+ { 0x04, KEY_NUMERIC_4 },
+ { 0x05, KEY_NUMERIC_5 },
+ { 0x06, KEY_NUMERIC_6 },
+ { 0x07, KEY_NUMERIC_7 },
+ { 0x08, KEY_NUMERIC_8 },
+ { 0x0a, KEY_POWER },
+ { 0x0b, KEY_MUTE },
+ { 0x0c, KEY_CHANNELUP },
+ { 0x0d, KEY_VOLUMEUP },
+ { 0x0e, KEY_CHANNELDOWN },
+ { 0x0f, KEY_VOLUMEDOWN },
+ { 0x10, KEY_UP },
+ { 0x11, KEY_LEFT },
+ { 0x12, KEY_OK },
+ { 0x13, KEY_RIGHT },
+ { 0x14, KEY_DOWN },
+ { 0x15, KEY_MENU },
+ { 0x16, KEY_EXIT },
+ { 0x17, KEY_PLAY },
+ { 0x18, KEY_PAUSE },
+ { 0x19, KEY_STOP },
+ { 0x1a, KEY_BACK },
+ { 0x1b, KEY_FORWARD },
+ { 0x1c, KEY_RECORD },
+ { 0x1d, KEY_REWIND },
+ { 0x1e, KEY_FASTFORWARD },
+ { 0x20, KEY_RED },
+ { 0x21, KEY_GREEN },
+ { 0x22, KEY_YELLOW },
+ { 0x23, KEY_BLUE },
+
+};
+
+static struct rc_keymap rc5_streamzap_map = {
+ .map = {
+ .scan= rc5_streamzap,
+ .size= ARRAY_SIZE(rc5_streamzap),
+ .ir_type = IR_TYPE_RC5,
+ .name= RC_MAP_RC5_STREAMZAP,
+ }
+};
+
+static int __init init_rc_map_rc5_streamzap(void)
+{
+ return ir_register_map(&rc5_streamzap_map);
+}
+
+static void __exit exit_rc_map_rc5_streamzap(void)
+{
+ ir_unregister_map(&rc5_streamzap_map);
+}
+
+module_init(init_rc_map_rc5_streamzap)
+module_exit(exit_rc_map_rc5_streamzap)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jarod Wilson ");
diff --git a/drivers/staging/lirc/lirc_streamzap.c
b/drivers/staging/lirc/lirc_streamzap.c
index 5b46ac4..058e29f 100644
--- a/drivers/staging/lirc/lirc_streamzap.c
+++ b/drivers/staging/lirc/li
[announce] changes on my git tree
Dear developers and users, After merging patches directly on my git tree, I was impressed by the number of things I discovered that I should not do when handling it ;) Living and learning :) There are lots of trash there, due to the way patches get merged back from upstream. As reverting a patch there will break things for everybody that clones from my tree, I decided to go to an easier way: let's start from scratch. I've created a new tree, at: http://git.linuxtv.org/media_tree.git Currently, it is just a clone of Linus tree, all pointing to v2.6.35. I'll soon be adding more patches there. In order to avoid the same kind of troubles I had in the past, I intend to use the following guidelines: 1) branch "master" - will have the contents of Linus tree. 2) branch "staging/2.6.35" - will have patches for the current stable kernel; 2) branch "staging/2.6.36" - will have patches for the current development cycle; 3) branch "staging/2.6.37" - will have patches for linux-next On every new kernel release, I'll create another branch. No branches will be rebased, but I won't merge from a staging branch into master. If needed, I'll just update master to from Linus tree after having a changeset pulled there. As need arises, I'll be adding some development branches there with stuff that are already accepted, but there are still pending patches that are needed before sending that patch set upstream (for example, new internal/external API's added, while there's no driver actually using them). For those that already sent me pull requests, and for a few weeks, there's no action need. I'll be manually handling the tree differences for a while. Yet, the better is to rebase your trees using the new one as the basis. Except when needed (like depending on a third-party patch applied on my tree), the better is to have your local git trees always based on master. 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
[PATCH] IR/mceusb: less generic callback name and remove cruft
Signed-off-by: Jarod Wilson
---
drivers/media/IR/mceusb.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 65b0738..ac6bb2c 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -427,7 +427,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
}
}
-static void usb_async_callback(struct urb *urb, struct pt_regs *regs)
+static void mce_async_callback(struct urb *urb, struct pt_regs *regs)
{
struct mceusb_dev *ir;
int len;
@@ -476,7 +476,7 @@ static void mce_request_packet(struct mceusb_dev *ir,
/* outbound data */
usb_fill_int_urb(async_urb, ir->usbdev,
usb_sndintpipe(ir->usbdev, ep->bEndpointAddress),
- async_buf, size, (usb_complete_t) usb_async_callback,
+ async_buf, size, (usb_complete_t)mce_async_callback,
ir, ep->bInterval);
memcpy(async_buf, data, size);
@@ -919,7 +919,6 @@ static int __devinit mceusb_dev_probe(struct usb_interface
*intf,
struct usb_endpoint_descriptor *ep = NULL;
struct usb_endpoint_descriptor *ep_in = NULL;
struct usb_endpoint_descriptor *ep_out = NULL;
- struct usb_host_config *config;
struct mceusb_dev *ir = NULL;
int pipe, maxp, i;
char buf[63], name[128] = "";
@@ -929,7 +928,6 @@ static int __devinit mceusb_dev_probe(struct usb_interface
*intf,
dev_dbg(&intf->dev, ": %s called\n", __func__);
- config = dev->actconfig;
idesc = intf->cur_altsetting;
is_gen3 = usb_match_id(intf, gen3_list) ? 1 : 0;
--
1.7.2
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v3 06/10] media: Entities, pads and links enumeration
On Monday 02 August 2010 16:35:54 Laurent Pinchart wrote: > Hi Hans, > > On Sunday 01 August 2010 13:58:20 Hans Verkuil wrote: > > On Thursday 29 July 2010 18:06:39 Laurent Pinchart wrote: > > [snip] > > For subdevs you want to return a chip ident and revision field (same as > > VIDIOC_DBG_G_CHIP_IDENT does). > > Do we still need a chip ID when we now have a name ? Keeping the chip ID > registry updated is painful, it would be nice if we could do away with it. It's not that easy I think. The name of the subdev entity is set by the host (bridge) driver and that doesn't know the exact chip ID. E.g. the audio msp3400 subdev driver actually supports dozens of msp variants. Knowing which variant it is may actually be important information on an embedded system. Note also that the chip ID is optional: it is only required when using the debug ioctls to get/set registers and to obtain the chip ident. > A revision field is a very good idea, I'll add it. > > > Should we allow (possibly optional) names for pads? Or 'tooltip'-type > > descriptions that can be a lot longer than 32 chars? (Just brainstorming > > here). > > > > I am of course thinking of apps where the user can setup the media flow > > using a GUI. If the driver can provide more extensive descriptions of the > > various entities/pads, then that would make it much easier for the user to > > experiment. > > It would be nice to have, yes. Some kind of pad capabilities would be > interesting too. What sort of caps do you have in mind? > > Note that I also think that obtaining such detailed information might be > > better done through separate ioctls (e.g. MEDIA_IOC_G_PAD_INFO, etc.). > > I agree. So we can leave the additional pad information out for now and add > it > later if needed :-) > > > What is definitely missing and *must* be added is a QUERYCAP type ioctl > > that provides driver/versioning info. > > I'll create one. > > > Another thing that we need to figure out is how to tell the application > > which audio and video nodes belong together. > > What about adding a group ID field in media_entity ? It's a possibility, but it's always a bit of a hassle in an application to work with group IDs. I wonder if there is a more elegant method. > > Not only that, but we need to be able to inform the driver how audio is > > hooked up: through an audio loopback cable, an alsa device, > > Doesn't the loopback cable connect the audio signal to audio hardware that > exposes an ALSA device ? How will drivers be able to tell if the user has > connected a loopback cable and what he has connected it to ? If the audio is passed out from the card through a loopback cable, then the application knows that it has to ask the user for the alsa device. It is obviously impossible to know in advance which alsa device the card is hooked up to. > > part of an mpeg stream, > > In that case there will be no audio device. > > > or as a V4L2 audio device (ivtv can do that, and I think pvrusb2 does the > > same for radio). I'm not entirely sure we want to expose that last option as > > it is not really spec compliant. > > I'm not sure either :-) Why doesn't ivtv use an ALSA device ? With earlier firmwares the audio was out of sync with the video so you needed timestamps to sync them up. And alsa didn't (and doesn't) support this. > > Other things we may want to expose: is the video stream raw or compressed? > > I think that belongs to V4L2. V4L2 has something along these lines: VIDIOC_ENUM_FMT can set a COMPRESSED flag when enumerating formats. After thinking about this a bit more I've come to the conclusion that for now at least we should keep this in V4L2. > > What are the default video/audio/vbi streams? (That allows an app to find > > the default video device node if a driver has lots of them). > > What about adding a __u32 flags field to media_entity, and defining a > MEDIA_ENTITY_FLAG_DEFAULT bit ? I had the same idea. Not just useful for alsa, v4l and dvb nodes, but also for IR inputs. We should look at IR as well: it is nice if you can easily discover the IR input associated with the board. > > Some of this information should perhaps be exposed through the v4l2 API, > > but other parts definitely belong here. > > > > I've not thought about this in detail, but we need to set some time aside > > to brainstorm on how to provide this information in a logical and > > consistent manner. > > IRC ? A real meeting would be better, but the next scheduled one is in > November and that's a bit too far away. If there is enough to discuss, then an interim meeting might well be useful. Regards, Hans -- 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: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300
On Mon, Aug 2, 2010 at 11:59 PM, lawrence rust wrote: > On Mon, 2010-08-02 at 22:19 +1200, Shane Harrison wrote: > [snip] >> I am not ruling out initialisation problems with the WM8775 but I do >> always seem to get an I2S output from it that has data in it that >> reflects the input. However it could be the wrong variant of I2S or >> some other configuration that isn't set right. > > Currently in wm8775.c line 223, R11 is set to 0x21 which is 24-bit left > justified mode. This is wrong, it should be i2s mode (0x22). My patch > correctly sets this register and also disables ALC mode which is > irrelevant when setting input level via ALSA and can cause hiss during > quiet sections. > >> Strange how eventually >> I do get audio (albeit mixed with the TV source it appears) simply by >> looping thru and changing input sources with v4l2-ctl. > > Probably switching glitches eventually hit the right data > synchronisation format. > >> I note that the Nova-S doesn't have the hardware MPEG encoding > > Correct. > >> so >> still hoping someone can enlighten me on the audio path when using >> that chip. > > When a Blackbird cx23416 MPEG encoder is fitted, i2s audio data from the > wm8775 is routed through the cx23883. The i2s output of the cx23883 is > enabled by the function set_audio_finish() in cx88-tvaudio.c line 148. > The cx23416 can accept stereo Sony I2S format audio data when quoting > from the Conexant datasheet "running its AILR sync signal through an > inverting flip-flop, clocked by an inverted AICKIN". > > -- Lawrence Rust > > > Yes we had noticed that the WM8775 was in left justified rather than I2S and had corrected that already. Thanks for the audio path info. While you are on a roll, a few more questions ? 1) So do you know how the I2S input (from WM8775) is looped back to the I2S output that is fed to the MPEG encoder? I can only assume in software? I note that the driver has a comment re. using passthrough mode in the CX2388x but actually uses normal mode which isn't a loopback. Hence something else must generate the I2S output source. 2) I interpreted the following note in the CX23416 datasheet slightly differently than you: "The CX23416 audio input interface is designed to work with most commonly available audio analog-to-digital converters (ADCs) that are compatible with the Sony I2S data format. An I2S-compatible audio part can be supported by running its AILR sync signal through an inverting flip-flop, clocked by an inverted AICKIN, before passing it to the CX23416. I assumed it was saying it accepted standard Sony variant but you could connect to Philips I2S if you used a flip-flop to invert and synchronise with the AICKIN. I did notice that the HVR1300 board has a footprint for an IC that is connected to the I2S outputs in some manner. I wondered what this was - does something need to be fitted then to make these two devices talk directly? I also note that the driver sets the I2S input to be Philips (as output by the WM8775) and the I2S output as Sony which seems like an attempt to talk directly. A bit confused here. 3) Given I am getting audio sometimes in the MPEG2 stream, is it using another path into the CX23416. The idea of getting lucky on switching glitches seems improbable on the I2S interface since once I get audio I continue to have it until a hard reboot. Switching glitches and race conditions on the control interfaces being successful every so often I could buy. Still to try the patch - will let you know. Unfortunately our HVR-1300 is in the process of being swapped out since the supplier wanted to try swapping boards first :-( Cheers Shane -- 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: Remote that breaks current system
On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson wrote: > On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote: >> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus >> wrote: >> > Hi! >> > >> > Jon Smirl "jonsm...@gmail.com" wrote: >> > [...] >> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to >> >>> properly >> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way >> >>> ported over the weekend, but this remote just won't decode correctly >> >>> w/the >> >>> in-kernel RC5 decoder. >> > >> >> Manchester encoding may need a decoder that waits to get 2-3 edge >> >> changes before deciding what the first bit. As you decode the output >> >> is always a couple bits behind the current input data. >> >> >> >> You can build of a table of states >> >> L0 S1 S0 L1 - emit a 1, move forward an edge >> >> S0 S1 L0 L1 - emit a 0, move forward an edge >> >> >> >> By doing it that way you don't have to initially figure out the bit clock. >> >> >> >> The current decoder code may not be properly tracking the leading >> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00. >> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is >> >> off by 1/2 a bit cycle. >> >> >> >> Did you note the comment that Extended RC-5 has only a single start >> >> bit instead of two? >> > >> > It has nothing to do with start bits. >> > The Streamzap remote just sends 14 (sic!) bits instead of 13. >> > The decoder expects 13 bits. >> > Yes, the Streamzap remote does _not_ use standard RC-5. >> > Did I mention this already? Yes. ;-) >> >> If the remote is sending a weird protocol then there are several choices: >> 1) implement raw mode >> 2) make a Stream-Zap protocol engine (it would be a 14b version of >> RC-5). Standard RC5 engine will still reject the messages. >> 3) throw away your Stream-Zap remotes >> >> I'd vote for #3, but #2 will probably make people happier. > > Hm. Yeah, I know a few people who are quite attached to their Streamzap > remotes. I'm not a particularly big fan of it, I only got the thing off > ebay to have the hardware so I could work on the driver. :) So yeah, #3 is > probably not the best route. But I don't know that I'm a huge fan of #2 > either. Another decoder engine just for one quirky remote seems excessive, > and there's an option #4: > > 4) just keep passing data out to lirc by default. That's a decent idea. Implement the mainstream, standard protocols in the kernel and kick the weird stuff out to LIRC. We can avoid the whole world of raw mode, config files, etc. Let LIRC deal with all that. If the weird stuff gets enough users bring it in-kernel. Maybe StreamZap will suddenly sell a million units, you never know. It is easy to implement a StreamZap engine. Just copy the RC5 one. Rename everything and adjust it to require one more bit. You'll have to modify the RC5 to wait for a bit interval (timeout) before sending the data up. If you want to get fancy use a weak symbol in the StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then you can decide to wait the extra bit interval or not. > Let lircd handle the default remote in this case. If you want to use > another remote that actually uses a standard protocol, and want to use > in-kernel decoding for that, its just an ir-keytable call away. > > For giggles, I may tinker with implementing another decoder engine though, > if only to force myself to actually pay more attention to protocol > specifics. For the moment, I'm inclined to go ahead with the streamzap > port as it is right now, and include either an empty or not-empty, but > not-functional key table. > > -- > Jarod Wilson > ja...@redhat.com > > -- Jon Smirl jonsm...@gmail.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
[GIT PULL for 2.6.36] V4L/DVB updates
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_2.6.35 This is the LIRC pull request ;) After years of being maintained out-of-tree and being merged on almost all distros, it is finally ready for its addition upstream. The core got converted to work together with the Remote Controller subsystem, and one driver got ported to it, on this series (there are more to come on a next pull request). The drivers that are still waiting to be ported were at drivers/staging. It also removes several V4L1 drivers that were replaced by gspca. The net balance is that this series is removing 31665 lines, and adding "only" 27791 lines. So, lots of cleanups. The rest of this series are the usual improvements at V4L, DVB and RC (remote controllers), including a port of two DVB drivers to use the new RC core, and a few new drivers. --- The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51: Linux 2.6.35 (2010-08-01 15:11:14 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_2.6.35 Abylay Ospan (1): V4L/DVB: Fix kernel Oops when number of NetUP Dual DVB-S2-CI cards more than DVB_MAX_ADAPTERS limit Amerigo Wang (6): V4L/DVB: Remove usbvideo quickcam_messenger driver V4L/DVB: Remove obsolete ov511 driver V4L/DVB: Remove obsolete w9968cf v4l1 driver V4L/DVB: Remove obsolete ovcamchip sensor framework V4L/DVB: Remove obsolete stv680 v4l1 driver V4L/DVB: Remove obsolete zc0301 v4l driver Anatolij Gustschin (2): V4L/DVB: v4l: Add MPC5121e VIU video capture driver V4L/DVB: v4l2-dev: fix memory leak Andrew Morton (1): V4L/DVB: "dib3000mc: reduce large stack usage" fix Andy Walls (3): V4L/DVB: ivtv: Increment driver version due to firmware loading changes V4L/DVB: cx23885: Convert from struct card_ir to struct cx23885_ir_input for IR Rx V4L/DVB: cx23885: Convert cx23885-input to use new in kernel IR pulse decoders Antti Palosaari (7): V4L/DVB: af9013: add support for firmware 5.1.0.0 V4L/DVB: get_dvb_firmware: update af9015 V4L/DVB: af9015: support for AverMedia AVerTV Volar M (A815Mac) V4L/DVB: af9013: program tuner before demodulator V4L/DVB: af9013: af9013_read_status() refactoring V4L/DVB: af9013: output fw version as four digit long V4L/DVB: af9013: fix comments Arnd Bergmann (1): V4L/DVB: lirc: use unlocked_ioctl Ben Hutchings (2): V4L/DVB: mantis: Select correct frontends V4L/DVB: lgs8gxx: remove firmware for lgs8g75 Christian Dietrich (1): V4L/DVB: drivers/media/video: Remove dead CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE Christoph Egger (1): V4L/DVB: remove obsolete conditionalizing on DVB_DIBCOM_DEBUG Dan Carpenter (7): V4L/DVB: dvb-usb-init.c: white space changes in dvb-usb-init V4L/DVB: remove unneeded null check in anysee_probe() V4L/DVB: cpia_usb: remove unneeded variable V4L/DVB: media/radio: fix copy_to_user to user handling V4L/DVB: dvb_ca_en50221: return -EFAULT on copy_to_user errors V4L/DVB: media/IR: testing the wrong variable V4L/DVB: au0828: move dereference below sanity checks Daniel Mack (2): V4L/DVB: drivers/media/dvb/dvb-usb/dib0700: fix return values V4L/DVB: drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes David Härdeman (4): V4L/DVB: ir-core: convert mantis to not use ir-functions.c V4L/DVB: ir-core: convert em28xx to not use ir-functions.c V4L/DVB: ir-core: centralize sysfs raw decoder enabling/disabling V4L/DVB: ir-core: move decoding state to ir_raw_event_ctrl David Härdeman (2): V4L/DVB: ir-core: partially convert cx88 to not use ir-functions.c V4L/DVB: ir-core: partially convert ir-kbd-i2c.c to not use ir-functions.c Dean Anderson (1): V4L/DVB: s2255drv: cleanup of device structure Devin Heitmueller (2): V4L/DVB: Add closed captioning support for the HVR-950q V4L/DVB: Fix case where fields were not at the correct start location Dmitri Belimov (2): V4L/DVB: tm6000: Fix Video decoder initialization V4L/DVB: xc5000, rework xc_write_reg Guennadi Liakhovetski (9): V4L/DVB: sh_mobile_ceu_camera: fix debugging message V4L/DVB: V4L2: fix sh_vou.c compile breakage: #include V4L/DVB: mediabus: fix ambiguous pixel code names V4L/DVB: V4L2: mediabus: add 12-bit Bayer and YUV420 pixel formats V4L/DVB: V4L2: soc-camera: export soc-camera bus type for notifications V4L/DVB: V4L2: soc-camera: add a MIPI CSI-2 driver for SH-Mobile platforms V4L/DVB: V4L2: sh_mobile_camera_ceu: add support for CSI2 V4L/DVB: V4L2: sh_vou: VOU does support the full PAL resolution too V4L/DVB: rj54n1cb0c: fix a comment in the driver Guillaume Audirac (4): V4L/DVB: tda10048: fix the uncomplete function tda10048_read_ber
Re: [PATCH 3/7] V4L/DVB: dvb-usb: prepare drivers for using rc-core
On Sat, Jul 31, 2010 at 10:54 PM, Mauro Carvalho Chehab wrote: > This is a big patch, yet trivial. It just move the RC properties > to a separate struct, in order to prepare the dvb-usb drivers to > use rc-core. There's no change on the behavior of the drivers. > > With this change, it is possible to have both legacy and rc-core > based code inside the dvb-usb-remote, allowing a gradual migration > to rc-core, driver per driver. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Jarod Wilson -- 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 2/7] V4L/DVB: dvb-usb: get rid of struct dvb_usb_rc_key
On Sat, Jul 31, 2010 at 10:54 PM, Mauro Carvalho Chehab wrote: > dvb-usb has its own IR handle code. Now that we have a Remote > Controller subsystem, we should start using it. So, remove this > struct, in favor of the similar struct defined at the RC subsystem. > > This is a big, but trivial patch. It is a 3 line delect, plus > lots of rename on several dvb-usb files. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Jarod Wilson -- 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] IR keymap: Add print button for HP OEM version of MCE remote
On Sat, Jul 31, 2010 at 1:23 PM, Andy Walls wrote: > This patch adds a defintion for the "Print" button found on HP OEM > versions of the MCE remote. All of the other keys found on the HP OEM > version of the remote match the other keys as already defined. > > Because, who doesn't need "remote printing", while one is sitting on the > couch across from one's PC? ;) Hah, nice. Most Useful Remote Button Ever. > Signed-off-by: Andy Walls Acked-by: Jarod Wilson -- 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
[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 Aug 2 19:00:25 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 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/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
Re: Remote that breaks current system
On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote: > On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus > wrote: > > Hi! > > > > Jon Smirl "jonsm...@gmail.com" wrote: > > [...] > >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly > >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way > >>> ported over the weekend, but this remote just won't decode correctly w/the > >>> in-kernel RC5 decoder. > > > >> Manchester encoding may need a decoder that waits to get 2-3 edge > >> changes before deciding what the first bit. As you decode the output > >> is always a couple bits behind the current input data. > >> > >> You can build of a table of states > >> L0 S1 S0 L1 - emit a 1, move forward an edge > >> S0 S1 L0 L1 - emit a 0, move forward an edge > >> > >> By doing it that way you don't have to initially figure out the bit clock. > >> > >> The current decoder code may not be properly tracking the leading > >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00. > >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is > >> off by 1/2 a bit cycle. > >> > >> Did you note the comment that Extended RC-5 has only a single start > >> bit instead of two? > > > > It has nothing to do with start bits. > > The Streamzap remote just sends 14 (sic!) bits instead of 13. > > The decoder expects 13 bits. > > Yes, the Streamzap remote does _not_ use standard RC-5. > > Did I mention this already? Yes. ;-) > > If the remote is sending a weird protocol then there are several choices: > 1) implement raw mode > 2) make a Stream-Zap protocol engine (it would be a 14b version of > RC-5). Standard RC5 engine will still reject the messages. > 3) throw away your Stream-Zap remotes > > I'd vote for #3, but #2 will probably make people happier. Hm. Yeah, I know a few people who are quite attached to their Streamzap remotes. I'm not a particularly big fan of it, I only got the thing off ebay to have the hardware so I could work on the driver. :) So yeah, #3 is probably not the best route. But I don't know that I'm a huge fan of #2 either. Another decoder engine just for one quirky remote seems excessive, and there's an option #4: 4) just keep passing data out to lirc by default. Let lircd handle the default remote in this case. If you want to use another remote that actually uses a standard protocol, and want to use in-kernel decoding for that, its just an ir-keytable call away. For giggles, I may tinker with implementing another decoder engine though, if only to force myself to actually pay more attention to protocol specifics. For the moment, I'm inclined to go ahead with the streamzap port as it is right now, and include either an empty or not-empty, but not-functional key table. -- Jarod Wilson ja...@redhat.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: Remote that breaks current system
On Mon, Aug 02, 2010 at 06:42:00PM +0200, Christoph Bartelmus wrote: > Hi! > > Jon Smirl "jonsm...@gmail.com" wrote: > [...] > >> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly > >> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way > >> ported over the weekend, but this remote just won't decode correctly w/the > >> in-kernel RC5 decoder. > > > Manchester encoding may need a decoder that waits to get 2-3 edge > > changes before deciding what the first bit. As you decode the output > > is always a couple bits behind the current input data. > > > > You can build of a table of states > > L0 S1 S0 L1 - emit a 1, move forward an edge > > S0 S1 L0 L1 - emit a 0, move forward an edge > > > > By doing it that way you don't have to initially figure out the bit clock. > > > > The current decoder code may not be properly tracking the leading > > zero. In Manchester encoding it is illegal for a bit to be 11 or 00. > > They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is > > off by 1/2 a bit cycle. > > > > Did you note the comment that Extended RC-5 has only a single start > > bit instead of two? > > It has nothing to do with start bits. > The Streamzap remote just sends 14 (sic!) bits instead of 13. > The decoder expects 13 bits. > Yes, the Streamzap remote does _not_ use standard RC-5. > Did I mention this already? Yes. ;-) D'oh, yeah, sorry, completely forgot you already mentioned this. That would certainly explain why the rc5 decoder isn't happy with it. So the *receiver* itself is perfectly functional, its just a goofy IR protocol sent by its default remote. Blah. So yet another reason having ongoing lirc compatibility is a Good Thing. ;) -- Jarod Wilson ja...@redhat.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: Remote that breaks current system
On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus wrote: > Hi! > > Jon Smirl "jonsm...@gmail.com" wrote: > [...] >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way >>> ported over the weekend, but this remote just won't decode correctly w/the >>> in-kernel RC5 decoder. > >> Manchester encoding may need a decoder that waits to get 2-3 edge >> changes before deciding what the first bit. As you decode the output >> is always a couple bits behind the current input data. >> >> You can build of a table of states >> L0 S1 S0 L1 - emit a 1, move forward an edge >> S0 S1 L0 L1 - emit a 0, move forward an edge >> >> By doing it that way you don't have to initially figure out the bit clock. >> >> The current decoder code may not be properly tracking the leading >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00. >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is >> off by 1/2 a bit cycle. >> >> Did you note the comment that Extended RC-5 has only a single start >> bit instead of two? > > It has nothing to do with start bits. > The Streamzap remote just sends 14 (sic!) bits instead of 13. > The decoder expects 13 bits. > Yes, the Streamzap remote does _not_ use standard RC-5. > Did I mention this already? Yes. ;-) If the remote is sending a weird protocol then there are several choices: 1) implement raw mode 2) make a Stream-Zap protocol engine (it would be a 14b version of RC-5). Standard RC5 engine will still reject the messages. 3) throw away your Stream-Zap remotes I'd vote for #3, but #2 will probably make people happier. > > Christoph > -- Jon Smirl jonsm...@gmail.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 v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote: > >Russell King - ARM Linux wrote: > >On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: > >> Well, some of them are indeed unused, but it's not an uncommon practice in > >> kernel and might help future developers. > > > >On the other hand, arch/arm is getting soo big that we need to do > >something about this - and one solution is to avoid unnecessary > >definitions that we're not using. > > > >Another good idea is to put definitions along side the drivers which > >they're relevant to - maybe in a local driver-name.h file which > >driver-name.c includes, or maybe even within driver-name.c if they're > >not excessive. This has the advantage of distributing the "bloat" to > >where its actually used, and means that the driver isn't dependent so > >much on arch/arm or even the SoC itself. > > > >Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and > >arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only > >two files which contain platform definitions which are actually used > >for Versatile Express. Compare that with > >arch/arm/mach-realview/include/mach/platform.h which contains lots > >more... > > So basically, what you and Mauro are recommending is that we move the *.h > file with register definitions to drivers/media? What I'm suggesting is what's been pretty standard in Linux for a long time. Take a look at: drivers/net/3c503.[ch], or for a more recent driver, drivers/net/e1000/*.[ch]. Or drivers/mmc/host/mmci.[ch] Putting definitions which are only used by one driver in arch/arm/*/include is silly. -- 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: Remote that breaks current system
Hi! Jon Smirl "jonsm...@gmail.com" wrote: [...] >> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly >> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way >> ported over the weekend, but this remote just won't decode correctly w/the >> in-kernel RC5 decoder. > Manchester encoding may need a decoder that waits to get 2-3 edge > changes before deciding what the first bit. As you decode the output > is always a couple bits behind the current input data. > > You can build of a table of states > L0 S1 S0 L1 - emit a 1, move forward an edge > S0 S1 L0 L1 - emit a 0, move forward an edge > > By doing it that way you don't have to initially figure out the bit clock. > > The current decoder code may not be properly tracking the leading > zero. In Manchester encoding it is illegal for a bit to be 11 or 00. > They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is > off by 1/2 a bit cycle. > > Did you note the comment that Extended RC-5 has only a single start > bit instead of two? It has nothing to do with start bits. The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits. Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-) Christoph -- 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: Remote that breaks current system (was: IR: Port ene driver...) it.
On Mon, Aug 2, 2010 at 11:12 AM, Jarod Wilson wrote: > On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote: >> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls wrote: > ... >> > Since these two protocols have such close timings that systematic errors >> > can cause misclassification when using simple mark or space measurements >> > against fixed thresholds, it indicates that a more sophisticated >> > discrimination mechanism would be needed. Perhaps one that takes multiple >> > successive measurements into account? >> >> If we get to the point where we need more sophisticated >> classifications we can build it. But are we at that point yet? I'd >> prefer to initially leave everything pretty strict as a way of >> flushing out driver implementation bugs. >> >> Find some remotes and receivers that break the current system. > > Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly > decode in-kernel for the life of me. I got lirc_streamzap 99% of the way > ported over the weekend, but this remote just won't decode correctly w/the > in-kernel RC5 decoder. Manchester encoding may need a decoder that waits to get 2-3 edge changes before deciding what the first bit. As you decode the output is always a couple bits behind the current input data. You can build of a table of states L0 S1 S0 L1 - emit a 1, move forward an edge S0 S1 L0 L1 - emit a 0, move forward an edge By doing it that way you don't have to initially figure out the bit clock. The current decoder code may not be properly tracking the leading zero. In Manchester encoding it is illegal for a bit to be 11 or 00. They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is off by 1/2 a bit cycle. Did you note the comment that Extended RC-5 has only a single start bit instead of two? > > Working: > Streamzap receiver + RC6 (MCE) remote, in-kernel decoding > Streamzap receiver + RC5 (Streamzap) remote, lirc decoding > > Not working: > Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding > MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding > > Failure mode is identical between the two, leading me to believe my > streamzap port is good to go, we just have an issue to track down with rc5 > decoding. > > Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial > space provided by both receivers, then gets rolling with (I believe) the > first pulse. It then gets all the way to STATE_FINISHED, and bails, > because it should be on a space there, but its on a pulse. > > I've twiddled the decoder to proceed even if its a pulse, but the > resulting decoding is still no good, as multiple adjacent keys (which have > proper decoded values that only differ by 1, per lirc decoding) get > decoded to the same value as one another. > > Still poking around trying to figure out the problem, but here's what the > (slightly modified to not bail when it gets to STATE_FINISHED with a > pulse) rc5 decoder is seeing/doing: > > ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space) > ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space) > ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse) > ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse) > ir_rc5_decode: RC5(x) decode started at state 1 (896us space) > ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse) > ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse) > ir_rc5_decode: RC5(x) decode started at state 2 (1664us space) > ir_rc5_decode: RC5(x) decode started at state 1 (775us space) > ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse) > ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse) > ir_rc5_decode: RC5(x) decode started at state 2 (896us space) > ir_rc5_decode: RC5(x) decode started at state 1 (7us space) > ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse) > ir_rc5_decode: RC5(x) decode started at state 2 (896us space) > ir_rc5_decode: RC5(x) decode started at state 1 (7us space) > ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse) > ir_rc5_decode: RC5(x) decode started at state 2 (1664us space) > ir_rc5_decode: RC5(x) decode started at state 1 (775us space) > ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse) > ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse) > ir_rc5_decode: RC5(x) decode started at state 3 (896us space) > ir_rc5_decode: RC5(x) decode started at state 1 (896us space) > ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse) > ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse) > ir_rc5_decode: RC5(x) decode started at state 2 (1664us space) > ir_rc5_decode: RC5(x) decode started at state 1 (775us space) > ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse) > ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse) > ir_rc5_decode: RC5(x) decode started at state 2 (896us space) > ir_rc5_decode: RC5(x) decode started at state 1 (7us space) > ir_rc5_decode: RC5(
Re: [PATCH 09/13] IR: add helper function for hardware with small o/b buffer.
On Sun, Aug 01, 2010 at 10:11:01PM -0400, Andy Walls wrote:
> On Sat, 2010-07-31 at 17:59 +0300, Maxim Levitsky wrote:
...
> > struct ir_input_dev {
> > @@ -69,9 +81,10 @@ struct ir_input_dev {
> > char*driver_name; /* Name of the driver
> > module */
> > struct ir_scancode_tablerc_tab; /* scan/key table */
> > unsigned long devno; /* device number */
> > - const struct ir_dev_props *props; /* Device properties */
> > + struct ir_dev_props *props; /* Device properties */
>
> So I don't think the struct ir_dev_props structure is the right place to
> be storing current operating parameters. IMO, operating parameters
> stored in the ir_dev_props are "too far" from the lower level driver,
> and are essentially mirroring what the low level driver should be
> tracking internally as it's own state anyway.
>
>
> So in summary, I think we need to keep the opertions in struct
> ir_dev_props simple using ,get_parameters() and .set_parameters() to
> contol the lower level driver and to fetch, retrieve, and store
> parameters.
Yeah, I neglected to consider this change the first pass through an
earlier revision. Making props modifiable on the fly does feel like we're
mixing up hardware features with hardware state, and perhaps the
on-the-fly-modifiable state bits should be stored somewhere else.
--
Jarod Wilson
ja...@redhat.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: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
On Wednesday 28 July 2010 11:04:56 Marek Szyprowski wrote: Let me introduce one more example. As you may know we have 3 video-processor capture devices (Samsung FIMC) and a hardware codec (like Samsung MFC). FIMC can capture video data from camera sensor and accelerate common video processing tasks (like up/down scaling and color space conversion). Two FIMC and MFC are require for things like HD video encoding or decoding with online display/preview. This task require huge video buffers that are usually allocated and freed at the same time. The third FIMC can be used for gfx acceleration (color space conversion and scaling are quite common tasks in GUI). This latter task usually introduces a lot of memory fragmentation, as gfx surfaces are usually quite small (definitely smaller than HD frames or 8MPix picture from camera). It would be really wise to get that third FIMC device to use memory buffer that will be shared with 3D accelerator (which has quite similar usage scenarios and suffers from similar memory fragmentation). On Sun, 01 Aug 2010 15:26:13 +0200, Hans Verkuil wrote: OK, I understand. And I assume both gfx and 3D acceleration need to use a specific region? If they can use any type of memory, then this might be more appropriate for kmalloc and friends. I've been thinking about providing a "fake" region with a "fake" allocator which would allow in a generic way passing requests to kmalloc() and friends. Such regions could prove valuable for small allocations in things like 3D accelerator. But as you've said, it's better to provide something small first and later add to it so I'm postponing implementation of this feature. Note, however, that 3D accelerator does not operate only on small chunks of memory. A 1024x1024 texture is 1 Mipx. RGB makes it 3MiB. With mipmap it's 4MiB. Even 512x512 texture can reach 1MiB this way. It ma be impossible to allocate such chunks with just a kmalloc(). We don't want to allocate X buffers of Y MB memory each on boot. Instead we want to just reserve XX MB memory and then dynamically allocate buffers from it. This enables us to perform the following 2 tasks: 1. movie decoding in HD-quality (only one instance) 2. two instances of SD-quality movie decoding and SD-quality move encoding (example: video conference) We know that these two use cases are exclusive, so they can use the same reserved memory. When I said 'allocating X buffers of Y MB memory' I meant that you need to allocate a known amount of memory (X * Y MB in this case). So the boot args say e.g. dma=40MB and the driver just allocates X buffers from that region. But the point is that driver does not allocate memory at boot time. If video codec would allocate memory at boot time no one else could use it even if the codec is not used. The idea is to make other devices use the memory when codec is idle. For instance, one could work on huge JPEG images and need buffers for a hardware JPEG codec. Or have I misunderstood your point? Switching to SD quality requires releasing those buffers and instead allocating a number of smaller buffers from the same region. Our intention is that driver would allocate buffers only when needed so the buffers would be freed when video codec driver is released. So when the device is opened (whatever that would mean for a particular device) it would allocate enough memory for the requested task. For these use-cases the allocator can be very simple and probably covers most use-cases. Yes, this is our experience. The best-fit algorithm, even though simple, seem to handle use cases tested on our system with little fragmentation. Anyway, I'm no expert on memory allocators and people on the linux-mm list are no doubt much more qualified to discuss this. My main concern is that of trying to add too much for a first release. It is simply easier to start simple and extend as needed. That makes it easier to be accepted in the mainline. I'm trying to keep it as simple as possible :) still making it useful for us. In particular we need a way to specify where different regions reside (different memory banks, etc.) as well as specify which drivers should use which regions. What's more, we need the notion of a "kind" of memory as one driver may need memory buffers from different regions (ie. MFC needs to allocate buffers from both banks). +2. CMA allows a run-time configuration of the memory regions it + will use to allocate chunks of memory from. The set of memory + regions is given on command line so it can be easily changed + without the need for recompiling the kernel. + + Each region has it's own size, alignment demand, a start + address (physical address where it should be placed) and an + allocator algorithm assigned to the region. + + This means that there can be different algorithms running at + the same time, if different devices on the platform have + distinct memory usage
Re: Handling of large keycodes
On Mon, Aug 02, 2010 at 08:35:37AM -0300, Mauro Carvalho Chehab wrote: > Em 02-08-2010 05:02, Dmitry Torokhov escreveu: > > On Sat, Jul 31, 2010 at 10:23:45AM -0300, Mauro Carvalho Chehab wrote: > >> Hi Dmitry, > >> > >> Em 31-07-2010 06:19, Dmitry Torokhov escreveu: > >>> Hi Mauro, > >>> > >>> I finally got a chance to review the patches adding handling of large > >>> scancodes to input core and there are a few things with this approach > >>> that I do not like. > >> > >> Thanks for the review! > >> > >>> First of all I do not think that we should be working with scancode via > >>> a pointer as it requires additional compat handling when running 32-bit > >>> userspace on 64-bit kernel. We can use a static buffer of sufficient > >>> size (lets say 32 bytes) to move scancode around and simply increase its > >>> size if we come upon device that uses even bigger scancodes. As long as > >>> buffer is at the end we can handle this in a compatible way. > >> > >> Yes, this is the downside of using a pointer. I'm not aware of a Remote > >> Controller protocol using more than 256 bits for scancode, so 32 bits > >> should be ok. > >> > >>> The other issue is that interface is notsymmetrical, setting is done by > >>> scancode but retrieval is done by index. I think we should be able to > >>> use both scancode and index in both operations. > >> > >> Yes, this also bothered me. I was thinking to do something similar to your > >> approach of having a bool to select between them. This change is welcome. > >> > >>> The usefulnes of reserved data elements in the structure is doubtful, > >>> since we do not seem to require them being set to a particular value and > >>> so we'll be unable to distinguish betwee legacy and newer users. > >> > >> David proposed some parameters that we rejected on our discussions. As we > >> might need to add something similar, I decided to keep it on my approach, > >> since a set of reserved fields wouldn't hurt (and removing it on our > >> discussions > >> would be easy), but I'm ok on removing them. > >> > >>> I also concerned about the code very messy with regard to using old/new > >>> style interfaces instea dof converting old ones to use new > >>> insfrastructure, > >> > >> Good cleanup at the code! > >> > >>> I below is something that addresses these issues and seems to be working > >>> for me. It is on top of your patches and it also depends on a few > >>> changes in my tree that I have not publushed yet but plan on doing that > >>> tomorrow. I am also attaching patches converting sparse keymap and hid > >>> to the new style of getkeycode and setkeycode as examples. > >>> > >>> Please take a look and let me know if I missed something important. > >> > >> It seems to work for me. After you add the patches on your git tree, I'll > >> work on porting the RC core to the new approach, and change the ir-keycode > >> userspace program to work with, in order to be 100% sure that it will > >> work, > >> but I can't foresee any missing part on it. > >> > >> Currently, I'm not using my input patches, as I was waiting for your > >> review. I just patched the userspace application, in order to test the > >> legacy > >> mode. > >> > > > > OK, great. > > > > I want to fold all the patches from your tree plus this one into one and > > apply in one shpt (mentioning Jarod and Dan as authors of fixup patches > > in the changelog) - I do not believe we shoudl expose intermediate > > versions in the code that will go to Linus. Are you OK with this? > > I'm OK. If you want, you can add my ack on your patch: > > Acked-by: Mauro Carvalho Chehab Yeah, works for me too. -- Jarod Wilson ja...@redhat.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
Remote that breaks current system (was: IR: Port ene driver...) it.
On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls wrote: ... > > Since these two protocols have such close timings that systematic errors > > can cause misclassification when using simple mark or space measurements > > against fixed thresholds, it indicates that a more sophisticated > > discrimination mechanism would be needed. Perhaps one that takes multiple > > successive measurements into account? > > If we get to the point where we need more sophisticated > classifications we can build it. But are we at that point yet? I'd > prefer to initially leave everything pretty strict as a way of > flushing out driver implementation bugs. > > Find some remotes and receivers that break the current system. Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly decode in-kernel for the life of me. I got lirc_streamzap 99% of the way ported over the weekend, but this remote just won't decode correctly w/the in-kernel RC5 decoder. Working: Streamzap receiver + RC6 (MCE) remote, in-kernel decoding Streamzap receiver + RC5 (Streamzap) remote, lirc decoding Not working: Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding Failure mode is identical between the two, leading me to believe my streamzap port is good to go, we just have an issue to track down with rc5 decoding. Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial space provided by both receivers, then gets rolling with (I believe) the first pulse. It then gets all the way to STATE_FINISHED, and bails, because it should be on a space there, but its on a pulse. I've twiddled the decoder to proceed even if its a pulse, but the resulting decoding is still no good, as multiple adjacent keys (which have proper decoded values that only differ by 1, per lirc decoding) get decoded to the same value as one another. Still poking around trying to figure out the problem, but here's what the (slightly modified to not bail when it gets to STATE_FINISHED with a pulse) rc5 decoder is seeing/doing: ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space) ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space) ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse) ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse) ir_rc5_decode: RC5(x) decode started at state 1 (896us space) ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse) ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse) ir_rc5_decode: RC5(x) decode started at state 2 (1664us space) ir_rc5_decode: RC5(x) decode started at state 1 (775us space) ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse) ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse) ir_rc5_decode: RC5(x) decode started at state 2 (896us space) ir_rc5_decode: RC5(x) decode started at state 1 (7us space) ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse) ir_rc5_decode: RC5(x) decode started at state 2 (896us space) ir_rc5_decode: RC5(x) decode started at state 1 (7us space) ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse) ir_rc5_decode: RC5(x) decode started at state 2 (1664us space) ir_rc5_decode: RC5(x) decode started at state 1 (775us space) ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse) ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse) ir_rc5_decode: RC5(x) decode started at state 3 (896us space) ir_rc5_decode: RC5(x) decode started at state 1 (896us space) ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse) ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse) ir_rc5_decode: RC5(x) decode started at state 2 (1664us space) ir_rc5_decode: RC5(x) decode started at state 1 (775us space) ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse) ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse) ir_rc5_decode: RC5(x) decode started at state 2 (896us space) ir_rc5_decode: RC5(x) decode started at state 1 (7us space) ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse) ir_rc5_decode: RC5(x) decode started at state 2 (1664us space) ir_rc5_decode: RC5(x) decode started at state 1 (775us space) ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse) ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse) ir_rc5_decode: RC5 usually ends w/space, wtf? ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0) ir_getkeycode: unknown key for scancode 0x1129 This was for the OK button on the remote, which in lircd, decodes to scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons. At least, I think I'm decoding lircd.conf correctly. See here to be sure: http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap -- Jarod Wilson ja...@redhat.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
Re: [PATCH v2]Resend:videobuf_dma_sg: a new implementation for mmap
On Fri, 2010-07-30 at 19:39 +0800, Figo.zhang wrote: > On Fri, 2010-07-30 at 11:31 +0200, Laurent Pinchart wrote: > > Hi, > > > > On Friday 30 July 2010 02:08:02 Figo.zhang wrote: > > > a mmap issue for videobuf-dma-sg: it will alloc a new page for mmaping > > > when > > > it encounter page fault at video_vm_ops->fault(). pls see > > > http://www.spinics.net/lists/linux-media/msg21243.html > > > > > > a new implementation for mmap, it translate to vmalloc to page at > > > video_vm_ops->fault(). > > > > > > in v2, if mem->dma.vmalloc is NULL at video_vm_ops->fault(), it will alloc > > > memory by vmlloc_32(). > > > > You're replacing allocation in videobuf_vm_fault by allocationg in > > videobuf_vm_fault. I don't see the point. videobuf_vm_fault needs to go > > away > > completely. > in now videobuf code, the mmap alloc a new buf, the capture dma buffer > using vmalloc() alloc buffer, how is > relationship with them? in usrspace , the mmap region will not the > actual capture dma data, how is work? hmm, I understand with some mistake before.for mmap in videobuf-sg, it is not call vmalloc_32() to alloc memory, it call videobuf_dma_init_user_locked()->get_user_pages(), and the end, it will handle_mm_fault()-> vm_ops->fault(). Because in mmap(), it have assigned vaule for "baddr" variable. it is too obscure for videobuf-sg, hope for videbuf2. ~~ -- 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 v3 06/10] media: Entities, pads and links enumeration
Hi Hans,
On Sunday 01 August 2010 13:58:20 Hans Verkuil wrote:
> On Thursday 29 July 2010 18:06:39 Laurent Pinchart wrote:
[snip]
> > diff --git a/Documentation/media-framework.txt
> > b/Documentation/media-framework.txt index 6d680c6..1192feb 100644
> > --- a/Documentation/media-framework.txt
> > +++ b/Documentation/media-framework.txt
> > @@ -273,3 +273,134 @@ required, drivers don't need to provide a set_power
[snip]
> > +- struct media_entity_desc
> > +
> > +__u32 id Entity id, set by the application. When the id
> > is
> > + or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
> > + clears the flag and returns the first entity with a
> > + larger id.
> > +char name[32]Entity name. UTF-8 NULL-terminated string.
> > +__u32 typeEntity type.
> > +__u8 padsNumber of pads.
>
> Should be u16.
Thanks. Will fix.
[snip]
> > diff --git a/include/linux/media.h b/include/linux/media.h
> > new file mode 100644
> > index 000..9b8acc0
> > --- /dev/null
> > +++ b/include/linux/media.h
> > @@ -0,0 +1,77 @@
[snip]
> > +struct media_entity_desc {
> > + __u32 id;
> > + char name[32];
> > + __u32 type;
> > + __u8 pads;
>
> u16.
Thanks. Will fix.
[snip]
>
> > + __u32 links;
> > +
> > + __u32 reserved[4];
> > +
> > + union {
> > + /* Node specifications */
> > + struct {
> > + __u32 major;
> > + __u32 minor;
> > + } v4l;
> > + struct {
> > + __u32 major;
> > + __u32 minor;
> > + } fb;
> > + int alsa;
> > + int dvb;
> > +
> > + /* Sub-device specifications */
> > + /* Nothing needed yet */
> > + __u8 raw[64];
> > + };
> > +};
>
> Would there be anything else that we want to describe with these pad_desc
> and entity_desc structs?
Definitely. Thanks for reminding me :-)
> For subdevs you want to return a chip ident and revision field (same as
> VIDIOC_DBG_G_CHIP_IDENT does).
Do we still need a chip ID when we now have a name ? Keeping the chip ID
registry updated is painful, it would be nice if we could do away with it.
A revision field is a very good idea, I'll add it.
> Should we allow (possibly optional) names for pads? Or 'tooltip'-type
> descriptions that can be a lot longer than 32 chars? (Just brainstorming
> here).
>
> I am of course thinking of apps where the user can setup the media flow
> using a GUI. If the driver can provide more extensive descriptions of the
> various entities/pads, then that would make it much easier for the user to
> experiment.
It would be nice to have, yes. Some kind of pad capabilities would be
interesting too.
> Note that I also think that obtaining such detailed information might be
> better done through separate ioctls (e.g. MEDIA_IOC_G_PAD_INFO, etc.).
I agree. So we can leave the additional pad information out for now and add it
later if needed :-)
> What is definitely missing and *must* be added is a QUERYCAP type ioctl
> that provides driver/versioning info.
I'll create one.
> Another thing that we need to figure out is how to tell the application
> which audio and video nodes belong together.
What about adding a group ID field in media_entity ?
> Not only that, but we need to be able to inform the driver how audio is
> hooked up: through an audio loopback cable, an alsa device,
Doesn't the loopback cable connect the audio signal to audio hardware that
exposes an ALSA device ? How will drivers be able to tell if the user has
connected a loopback cable and what he has connected it to ?
> part of an mpeg stream,
In that case there will be no audio device.
> or as a V4L2 audio device (ivtv can do that, and I think pvrusb2 does the
> same for radio). I'm not entirely sure we want to expose that last option as
> it is not really spec compliant.
I'm not sure either :-) Why doesn't ivtv use an ALSA device ?
> Other things we may want to expose: is the video stream raw or compressed?
I think that belongs to V4L2.
> What are the default video/audio/vbi streams? (That allows an app to find
> the default video device node if a driver has lots of them).
What about adding a __u32 flags field to media_entity, and defining a
MEDIA_ENTITY_FLAG_DEFAULT bit ?
> Some of this information should perhaps be exposed through the v4l2 API,
> but other parts definitely belong here.
>
> I've not thought about this in detail, but we need to set some time aside
> to brainstorm on how to provide this information in a logical and
> consistent manner.
IRC ? A real meeting would be better, but the next scheduled one is in
November and that's a bit too far away.
--
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/
Re: [RFC/PATCH v3 03/10] media: Entities, pads and links
Hi Hans,
On Sunday 01 August 2010 13:32:50 Hans Verkuil wrote:
> On Thursday 29 July 2010 18:06:36 Laurent Pinchart wrote:
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > new file mode 100644
> > index 000..37a25bf
> > --- /dev/null
> > +++ b/include/media/media-entity.h
> > @@ -0,0 +1,85 @@
> > +#ifndef _MEDIA_ENTITY_H
> > +#define _MEDIA_ENTITY_H
> > +
> > +#include
> > +
> > +#define MEDIA_ENTITY_TYPE_NODE (1 << 16)
>
> I agree with Sakari that '16' should be a define.
Will do.
> > +#define MEDIA_ENTITY_TYPE_NODE_V4L (MEDIA_ENTITY_TYPE_NODE + 1)
> > +#define MEDIA_ENTITY_TYPE_NODE_FB (MEDIA_ENTITY_TYPE_NODE + 2)
> > +#define MEDIA_ENTITY_TYPE_NODE_ALSA(MEDIA_ENTITY_TYPE_NODE
> > + 3)
> > +#define MEDIA_ENTITY_TYPE_NODE_DVB (MEDIA_ENTITY_TYPE_NODE + 4)
> > +
> > +#define MEDIA_ENTITY_TYPE_SUBDEV (2 << 16)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER
> > (MEDIA_ENTITY_TYPE_SUBDEV +
> > 1)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_VID_ENCODER
> > (MEDIA_ENTITY_TYPE_SUBDEV +
> > 2)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_MISC
> > (MEDIA_ENTITY_TYPE_SUBDEV + 3)
+
> > +#define MEDIA_LINK_FLAG_ACTIVE (1 << 0)
> > +#define MEDIA_LINK_FLAG_IMMUTABLE (1 << 1)
> > +
> > +#define MEDIA_PAD_FLAG_INPUT (1 << 0)
> > +#define MEDIA_PAD_FLAG_OUTPUT (1 << 1)
> > +
> > +struct media_link {
> > + struct media_pad *source; /* Source pad */
> > + struct media_pad *sink; /* Sink pad */
> > + struct media_link *other; /* Link in the reverse direction */
>
> Why not rename 'other' to 'back' or 'backlink'? 'other' is not a good name
> IMHO.
For forward links other is the backlink, but for backlinks other is the
forward link. I'll rename it to reverse.
> > + unsigned long flags;/* Link flags (MEDIA_LINK_FLAG_*) */
> > +};
> > +
> > +struct media_pad {
> > + struct media_entity *entity;/* Entity this pad belongs to */
> > + u16 index; /* Pad index in the entity pads array */
> > + unsigned long flags;/* Pad flags (MEDIA_PAD_FLAG_*) */
> > +};
> > +
> > +struct media_entity {
> > + struct list_head list;
> > + struct media_device *parent;/* Media device this entity belongs to*/
> > + u32 id; /* Entity ID, unique in the parent media
> > +* device context */
> > + const char *name; /* Entity name */
> > + u32 type; /* Entity type (MEDIA_ENTITY_TYPE_*) */
> > +
> > + u8 num_pads;/* Number of input and output pads */
> > + u8 num_links; /* Number of existing links, both active
> > +* and inactive */
> > + u8 num_backlinks; /* Number of backlinks */
> > + u8 max_links; /* Maximum number of links */
> > +
> > + struct media_pad *pads; /* Pads array (num_pads elements) */
> > + struct media_link *links; /* Links array (max_links elements)*/
> > +
> > + union {
> > + /* Node specifications */
> > + struct {
> > + u32 major;
> > + u32 minor;
> > + } v4l;
> > + struct {
> > + u32 major;
> > + u32 minor;
> > + } fb;
> > + int alsa;
> > + int dvb;
> > +
> > + /* Sub-device specifications */
> > + /* Nothing needed yet */
> > + };
> > +};
> > +
> > +#define MEDIA_ENTITY_TYPE_MASK 0x
> > +#define MEDIA_ENTITY_SUBTYPE_MASK 0x
> > +
> > +#define media_entity_type(entity) \
> > + ((entity)->type & MEDIA_ENTITY_TYPE_MASK)
> > +#define media_entity_subtype(entity) \
> > + ((entity)->type & MEDIA_ENTITY_SUBTYPE_MASK)
>
> Make these inline functions to ensure correct typechecking.
OK.
> Since bit 31 of the entity ID is reserved for MEDIA_ENTITY_ID_FLAG_NEXT you
> probably should change the TYPE_MASK to 0x7fff. Actually, I would
> change the type mask to 0x00ff, that way all top 8 bits are available
> for the future.
Agreed.
> > +
> > +int media_entity_init(struct media_entity *entity, u8 num_pads,
> > + struct media_pad *pads, u8 extra_links);
> > +void media_entity_cleanup(struct media_entity *entity);
> > +int media_entity_create_link(struct media_entity *source, u8 source_pad,
> > + struct media_entity *sink, u8 sink_pad, u32 flags);
> > +
> > +#endif
--
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
[PATCH v7 4/5] V4L2: WL1273 FM Radio: Controls for the FM radio.
This driver implements V4L2 controls for the Texas Instruments
WL1273 FM Radio.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1972
drivers/mfd/Kconfig|6 +
drivers/mfd/Makefile |2 +
5 files changed, 1996 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..209fd37 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
found behind the Timberdale FPGA on the Russellville board.
Enabling this driver will automatically select the DSP and tuner.
+config RADIO_WL1273
+ tristate "Texas Instruments WL1273 I2C FM Radio"
+depends on I2C && VIDEO_V4L2 && SND
+ select FW_LOADER
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to "v4l2" programs may be found at
+ .
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..9c7f01f
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,1972 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) Nokia Corporation
+ * Author: Matti J. Aaltonen
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC "Wl1273 FM Radio - V4L2"
+
+#define WL1273_POWER_SET_OFF 0
+#define WL1273_POWER_SET_FM(1 << 0)
+#define WL1273_POWER_SET_RDS (1 << 1)
+#define WL1273_POWER_SET_RETENTION (1 << 4)
+
+#define WL1273_PUPD_SET_OFF0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION 0x10
+
+#define WL1273_FREQ(x) (x * 1 / 625)
+#define WL1273_INV_FREQ(x) (x * 625 / 1)
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, "Radio Nr");
+
+struct wl1273_device {
+ struct v4l2_device v4l2dev;
+ struct video_device videodev;
+ struct device *dev;
+ struct wl1273_core *core;
+ struct file *owner;
+ char *write_buf;
+ bool rds_on;
+};
+
+static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
+{
+ int r = 0;
+
+ if (freq < 76000) {
+ dev_err(&core->i2c_dev->dev,
+ "Frequency out of range: %d < %d\n",
+ freq, core->bands[core->band].bottom_frequency);
+ return -EDOM;
+ }
+
+ if (freq > 108000) {
+ dev_err(&core->i2c_dev->dev,
+ "Frequency out of range: %d > %d\n",
+ freq, core->bands[core->band].top_frequency);
+ return -EDOM;
+ }
+
+ /*
+* The driver works better with this msleep,
+* the documentation doesn't mention it.
+*/
+ msleep(5);
+ dev_dbg(&core->i2c_dev->dev, "%s: freq: %d kHz\n", __func__, freq);
+
+ INIT_COMPLETION(core->busy);
+ /* Set the current tx channel */
+ r = wl1273_fm_write_cmd(core, WL1273_CHANL_SET, freq / 10);
+ if (r)
+ return r;
+
+ /* wait for the FR IRQ */
+ r = wait_for_completion_timeout(&core->busy, msecs_to_jiffies(2
[PATCH v7 1/5] V4L2: Add seek spacing and FM RX class.
Add spacing field to v4l2_hw_freq_seek and also add FM RX class to
control classes.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/video/v4l2-common.c | 12
include/linux/videodev2.h | 15 ++-
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index cd1f21d..41b1bb2 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -351,6 +351,12 @@ const char **v4l2_ctrl_get_menu(u32 id)
"75 useconds",
NULL,
};
+ static const char *fm_band[] = {
+ "87.5 - 108. MHz",
+ "76. - 90. MHz, Japan",
+ "65. - 74. MHz, OIRT",
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -391,6 +397,8 @@ const char **v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_FM_BAND:
+ return fm_band;
default:
return NULL;
}
@@ -515,6 +523,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_PREEMPHASIS: return "Pre-emphasis settings";
case V4L2_CID_TUNE_POWER_LEVEL: return "Tune Power Level";
case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return "Tune Antenna Capacitor";
+ case V4L2_CID_FM_RX_CLASS: return "FM Radio Tuner
Controls";
+ case V4L2_CID_FM_BAND: return "FM Band";
default:
return NULL;
@@ -580,6 +590,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+ case V4L2_CID_FM_BAND:
qctrl->type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
@@ -591,6 +602,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
+ case V4L2_CID_FM_RX_CLASS:
qctrl->type = V4L2_CTRL_TYPE_CTRL_CLASS;
qctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 418dacf..26522cb 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -935,6 +935,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
+#define V4L2_CTRL_CLASS_FM_RX 0x009c /* FM Tuner control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1313,6 +1314,17 @@ enum v4l2_preemphasis {
#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FM_TX_CLASS_BASE +
113)
#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 114)
+/* FM Tuner class control IDs */
+#define V4L2_CID_FM_RX_CLASS_BASE (V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS (V4L2_CTRL_CLASS_FM_RX | 1)
+
+#define V4L2_CID_FM_BAND (V4L2_CID_FM_RX_CLASS_BASE + 1)
+enum v4l2_fm_band {
+ V4L2_FM_BAND_OTHER = 0,
+ V4L2_FM_BAND_JAPAN = 1,
+ V4L2_FM_BAND_OIRT = 2
+};
+
/*
* T U N I N G
*/
@@ -1377,7 +1389,8 @@ struct v4l2_hw_freq_seek {
enum v4l2_tuner_type type;
__u32 seek_upward;
__u32 wrap_around;
- __u32 reserved[8];
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
--
1.6.1.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 v7 3/5] ASoC: WL1273 FM Radio Digital audio codec.
The codec handles digital audio input to and output from the
WL1273 FM radio.
Signed-off-by: Matti J. Aaltonen
---
sound/soc/codecs/Kconfig |6 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/wl1273.c | 591 +
sound/soc/codecs/wl1273.h | 42
4 files changed, 641 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/wl1273.c
create mode 100644 sound/soc/codecs/wl1273.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 52b005f..c4769f2 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -35,6 +35,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
+ select SND_SOC_WL1273 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
select SND_SOC_WM8510 if SND_SOC_I2C_AND_SPI
@@ -161,6 +162,11 @@ config SND_SOC_UDA134X
config SND_SOC_UDA1380
tristate
+config SND_SOC_WL1273
+ tristate
+ select WL1273_CORE
+ default n
+
config SND_SOC_WM8350
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index dbaecb1..2a7c564 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -22,6 +22,7 @@ snd-soc-tlv320dac33-objs := tlv320dac33.o
snd-soc-twl4030-objs := twl4030.o
snd-soc-uda134x-objs := uda134x.o
snd-soc-uda1380-objs := uda1380.o
+snd-soc-wl1273-objs := wl1273.o
snd-soc-wm8350-objs := wm8350.o
snd-soc-wm8400-objs := wm8400.o
snd-soc-wm8510-objs := wm8510.o
@@ -78,6 +79,7 @@ obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o
obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o
+obj-$(CONFIG_SND_SOC_WL1273) += snd-soc-wl1273.o
obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o
obj-$(CONFIG_SND_SOC_WM8400) += snd-soc-wm8400.o
obj-$(CONFIG_SND_SOC_WM8510) += snd-soc-wm8510.o
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
new file mode 100644
index 000..2c0b89c
--- /dev/null
+++ b/sound/soc/codecs/wl1273.c
@@ -0,0 +1,591 @@
+/*
+ * ALSA SoC WL1273 codec driver
+ *
+ * Author: Matti Aaltonen,
+ *
+ * Copyright: (C) 2010 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "wl1273.h"
+
+static int snd_wl1273_fm_set_i2s_mode(struct wl1273_core *core,
+ int rate, int width)
+{
+ struct device *dev = &core->i2c_dev->dev;
+ int r = 0;
+ u16 mode;
+
+ dev_dbg(dev, "rate: %d\n", rate);
+ dev_dbg(dev, "width: %d\n", width);
+
+ mutex_lock(&core->lock);
+
+ mode = core->i2s_mode & ~WL1273_IS2_WIDTH & ~WL1273_IS2_RATE;
+
+ switch (rate) {
+ case 48000:
+ mode |= WL1273_IS2_RATE_48K;
+ break;
+ case 44100:
+ mode |= WL1273_IS2_RATE_44_1K;
+ break;
+ case 32000:
+ mode |= WL1273_IS2_RATE_32K;
+ break;
+ case 22050:
+ mode |= WL1273_IS2_RATE_22_05K;
+ break;
+ case 16000:
+ mode |= WL1273_IS2_RATE_16K;
+ break;
+ case 12000:
+ mode |= WL1273_IS2_RATE_12K;
+ break;
+ case 11025:
+ mode |= WL1273_IS2_RATE_11_025;
+ break;
+ case 8000:
+ mode |= WL1273_IS2_RATE_8K;
+ break;
+ default:
+ dev_err(dev, "Sampling rate: %d not supported\n", rate);
+ r = -EINVAL;
+ goto out;
+ }
+
+ switch (width) {
+ case 16:
+ mode |= WL1273_IS2_WIDTH_32;
+ break;
+ case 20:
+ mode |= WL1273_IS2_WIDTH_40;
+ break;
+ case 24:
+ mode |= WL1273_IS2_WIDTH_48;
+ break;
+ case 25:
+ mode |= WL1273_IS2_WIDTH_50;
+ break;
+ case 30:
+ mode |= WL1273_IS2_WIDTH_60;
+ break;
+ case 32:
+ mode |= WL1273_IS2_WIDTH_64;
+ break;
+ case 40:
+
[PATCH v7 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio.
This is a parent for two child drivers: a V4L2 driver and
an ALSA codec driver. The MFD part implements I2C communication
to the device and provides a couple of functions that are called
from both children.
Signed-off-by: Matti J. Aaltonen
---
drivers/mfd/wl1273-core.c | 612 +++
include/linux/mfd/wl1273-core.h | 314
2 files changed, 926 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..603b922
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,612 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Author: Matti Aaltonen
+ *
+ * Copyright: (C) 2010 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC "WL1273 FM Radio Core"
+
+#define WL1273_IRQ_MASK (WL1273_FR_EVENT | \
+ WL1273_POW_ENB_EVENT)
+
+static const struct band_info bands[] = {
+ /* USA & Europe */
+ {
+ .bottom_frequency = 87500,
+ .top_frequency = 108000,
+ .band = V4L2_FM_BAND_OTHER,
+ },
+ /* Japan */
+ {
+ .bottom_frequency = 76000,
+ .top_frequency = 9,
+ .band = V4L2_FM_BAND_JAPAN,
+ },
+};
+
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0 == USA-Europe, 1 == Japan. USA-Europe is the default.
+ */
+static unsigned char radio_band;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, "Band: 0=USA-Europe, 1=Japan");
+
+/*
+ * static unsigned int rds_buf - the number of RDS buffer blocks used.
+ *
+ * The default number is 100.
+ */
+static unsigned int rds_buf = 100;
+module_param(rds_buf, uint, 0);
+MODULE_PARM_DESC(rds_buf, "RDS buffer entries: *100*");
+
+int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+ struct i2c_client *client = core->i2c_dev;
+ u8 b[2];
+ int r;
+
+ r = i2c_smbus_read_i2c_block_data(client, reg, 2, b);
+ if (r != 2) {
+ dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
+ return -EREMOTEIO;
+ }
+
+ *value = (u16)b[0] << 8 | b[1];
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_read_reg);
+
+int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+ struct i2c_client *client = core->i2c_dev;
+ u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
+ int r;
+
+ r = i2c_smbus_write_i2c_block_data(client, cmd, 2, buf);
+ if (r) {
+ dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
+ return r;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_write_cmd);
+
+int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+ struct i2c_client *client = core->i2c_dev;
+ struct i2c_msg msg[1];
+ int r;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].buf = data;
+ msg[0].len = len;
+
+ r = i2c_transfer(client->adapter, msg, 1);
+
+ if (r != 1) {
+ dev_err(&client->dev, "%s: write error.\n", __func__);
+ return -EREMOTEIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_write_data);
+
+/**
+ * wl1273_fm_set_audio() - Set audio mode.
+ * @core: A pointer to the device struct.
+ * @new_mode: The new audio mode.
+ *
+ * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
+ */
+int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
+{
+ int r = 0;
+
+ if (core->mode == WL1273_MODE_OFF ||
+ core->mode == WL1273_MODE_SUSPENDED)
+ return -EPERM;
+
+ if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) {
+ r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
+ WL1273_PCM_DEF_MODE);
+ if (r)
+ goto out;
+
+ r = wl1273_fm_write_cmd(core, WL1273_I2S
[PATCH v7 0/5] TI WL1273 FM Radio driver.
Hello all,
and thanks for the comments Hans.
Now I've done a couple of iterations with the codec on the ALSA mailing
list and that still continues... I've removed all "#undef DEBUG" lines,
because the ALSA people didn't like them.
I'll go through the comments and the rest of the changes:
>> + tuner->capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_RDS |
>> + V4L2_TUNER_CAP_STEREO;
>> +
>
> audmode must be set even when the device is in TX mode. Best is to just set it
> to the last set audmode.
I added a state field for the audmode. I used a boolean variable because
that seemed to lead to clearer code than using an int. Other two valued
entities - like the digital/analog mode - could also be modeled with booleans
but I didn't do it because it could be condemned by the community :-)
Should there also be audmode for the modulator?
>> + if (val == WL1273_RX_MONO) {
>> + tuner->rxsubchans = V4L2_TUNER_SUB_MONO;
>> + tuner->audmode = V4L2_TUNER_MODE_MONO;
>> + } else {
>> + tuner->rxsubchans = V4L2_TUNER_SUB_STEREO;
>> + tuner->audmode = V4L2_TUNER_MODE_STEREO;
>> + }
>
> There are two separate things: detecting whether the signal is stereo or mono
> and selecting the audio mode (this is the format of the audio that is sent to
> userspace). The first is set in rxsubchans and is dynamic, the second is fixed
> and set by the application.
>
> If the device can detect mono vs stereo signals, then rxsubchans should be set
> accordingly. If the device cannot do this, then both mono and stereo should be
> specified in rxsubchans.
>
> The audmode field is like a control: it does not automatically change if the
> signal switches from mono to stereo or vice versa. Unless the hardware is
> unable to map a mono signal to a stereo audio stream or a stereo signal to a
> mono audio stream.
>
> The fact that the code above sets both rxsubchans and audmode suggests either
> that the hardware cannot map stereo to mono or vice versa, or a program bug.
> In the first case we need a comment here, in the second case it should be
> fixed.
I kind of new I was doing something wrong here... but then I thought: why
isn't there a control variable for the RDS? Anyway, now I've made the
distinction between subchans flags and the audmode field.
>> +
>> + if (core->rds_on)
>> + modulator->txsubchans |= V4L2_TUNER_SUB_RDS;
>> + else
>> + modulator->txsubchans &= ~V4L2_TUNER_SUB_RDS;
>
> This else is not needed.
Else removed...
> Just make this Hz. There is no need to restrict the precision to
> kHz. S_FREQUENCY supports units of 67.5 Hz, so using kHz for the
> spacing seems unnecessary.
>
> Alternatively the same resolution as S_FREQUENCY can be used (67.5 Hz
> or 67.5 kHz, depending on the CAP_LOW capability). Not sure which is
> best, though.
I think using Hz is the most straightforward policy here so I chose that.
Cheers,
Matti
Matti J. Aaltonen (5):
V4L2: Add seek spacing and FM RX class.
MFD: WL1273 FM Radio: MFD driver for the FM radio.
ASoC: WL1273 FM Radio Digital audio codec.
V4L2: WL1273 FM Radio: Controls for the FM radio.
Documentation: v4l: Add hw_seek spacing and FM_RX class
Documentation/DocBook/v4l/controls.xml | 71 +
.../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 +-
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1972
drivers/media/video/v4l2-common.c | 12 +
drivers/mfd/Kconfig|6 +
drivers/mfd/Makefile |2 +
drivers/mfd/wl1273-core.c | 612 ++
include/linux/mfd/wl1273-core.h| 314
include/linux/videodev2.h | 15 +-
sound/soc/codecs/Kconfig |6 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/wl1273.c | 591 ++
sound/soc/codecs/wl1273.h | 42 +
15 files changed, 3668 insertions(+), 3 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
create mode 100644 sound/soc/codecs/wl1273.c
create mode 100644 sound/soc/codecs/wl1273.h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 5/5] Documentation: v4l: Add hw_seek spacing and FM_RX class
Add a couple of words about the spacing field in ithe HW seek struct and about the new FM RX control class. Signed-off-by: Matti J. Aaltonen --- Documentation/DocBook/v4l/controls.xml | 71 .../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 ++- 2 files changed, 79 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index e1bdbb6..bba3f4d 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -2062,6 +2062,77 @@ manually or automatically if set to zero. Unit, range and step are driver-specif For more details about RDS specification, refer to document, from CENELEC. + + FM Tuner Control Reference + + The FM Tuner (FM_RX) class includes controls for common features of +devices that are capable of receiving FM transmissions. Currently this class includes a parameter +defining the FM radio band being used. + + + FM_RX Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_FM_RX_CLASS + class + The FM_RX class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class. + + + V4L2_CID_FM_RX_BAND + integer + + Configures the FM radio +frequency range being used. Currently there are three bands in use, see http://en.wikipedia.org/wiki/FM_broadcasting";>Wikipedia. +Usually 87.5 to 108.0 MHz is used, or some portion thereof, with a few exceptions: +In Japan, the band 76-90 MHz is used and in the former Soviet republics +and some Eastern European countries, the older 65-74 MHz band, +referred also to as the OIRT band, is still used. + +The enum v4l2_fm_rx_band defines possible values for the FM band. They are: + + + + + V4L2_FM_BAND_OTHER + Frequencies from 87.5 to 108.0 MHz + + + V4L2_FM_BAND_JAPAN + from 65 to 74 MHz + + + V4L2_FM_BAND_OIRT + from 65 to 74 MHz + + + + + + + + + + +
Re: [RFC/PATCH v3 03/10] media: Entities, pads and links
Hi Sakari,
On Friday 30 July 2010 16:00:31 Sakari Ailus wrote:
> Laurent Pinchart wrote:
[snip]
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > new file mode 100644
> > index 000..37a25bf
> > --- /dev/null
> > +++ b/include/media/media-entity.h
> > @@ -0,0 +1,85 @@
> > +#ifndef _MEDIA_ENTITY_H
> > +#define _MEDIA_ENTITY_H
> > +
> > +#include
> > +
> > +#define MEDIA_ENTITY_TYPE_NODE (1 << 16)
>
> About that 16 there, could that be replaced by a #define instead? Like
> MEDIA_ENTITY_TYPE_SHIFT? (I don't think we'd need
> MEDIA_ENTITY_SUBTYPE_SHIFT.)
Agreed.
> > +#define MEDIA_ENTITY_TYPE_NODE_V4L (MEDIA_ENTITY_TYPE_NODE + 1)
> > +#define MEDIA_ENTITY_TYPE_NODE_FB (MEDIA_ENTITY_TYPE_NODE + 2)
> > +#define MEDIA_ENTITY_TYPE_NODE_ALSA(MEDIA_ENTITY_TYPE_NODE
> > + 3)
> > +#define MEDIA_ENTITY_TYPE_NODE_DVB (MEDIA_ENTITY_TYPE_NODE + 4)
> > +
> > +#define MEDIA_ENTITY_TYPE_SUBDEV (2 << 16)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER
> > (MEDIA_ENTITY_TYPE_SUBDEV +
> > 1) +#define
> > MEDIA_ENTITY_TYPE_SUBDEV_VID_ENCODER(MEDIA_ENTITY_TYPE_SUBDEV + 2)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_MISC
> > (MEDIA_ENTITY_TYPE_SUBDEV + 3)
+
> > +#define MEDIA_LINK_FLAG_ACTIVE (1 << 0)
> > +#define MEDIA_LINK_FLAG_IMMUTABLE (1 << 1)
> > +
> > +#define MEDIA_PAD_FLAG_INPUT (1 << 0)
> > +#define MEDIA_PAD_FLAG_OUTPUT (1 << 1)
> > +
> > +struct media_link {
> > + struct media_pad *source; /* Source pad */
> > + struct media_pad *sink; /* Sink pad */
> > + struct media_link *other; /* Link in the reverse direction */
> > + unsigned long flags;/* Link flags (MEDIA_LINK_FLAG_*) */
> > +};
> > +
> > +struct media_pad {
> > + struct media_entity *entity;/* Entity this pad belongs to */
> > + u16 index; /* Pad index in the entity pads array */
> > + unsigned long flags;/* Pad flags (MEDIA_PAD_FLAG_*) */
> > +};
> > +
> > +struct media_entity {
> > + struct list_head list;
> > + struct media_device *parent;/* Media device this entity belongs to*/
> > + u32 id; /* Entity ID, unique in the parent media
> > +* device context */
> > + const char *name; /* Entity name */
> > + u32 type; /* Entity type (MEDIA_ENTITY_TYPE_*) */
> > +
> > + u8 num_pads;/* Number of input and output pads */
>
> Hans suggested u16 for pads. This is a kernel structure but still it'd
> be good to keep them the same IMO, even if that u16 was there for the
> future.
>
> u8 is used on some function arguments as well for these purposes.
Will fix.
> > + u8 num_links; /* Number of existing links, both active
> > +* and inactive */
> > + u8 num_backlinks; /* Number of backlinks */
> > + u8 max_links; /* Maximum number of links */
>
> Same for these.
Agreed. The number of links is expected to be >= number of pads. I'll change
num_links, num_backlinks and max_links to u16 as well.
> > + struct media_pad *pads; /* Pads array (num_pads elements) */
> > + struct media_link *links; /* Links array (max_links elements)*/
> > +
> > + union {
> > + /* Node specifications */
> > + struct {
> > + u32 major;
> > + u32 minor;
>
> How about dev_t here?
dev_t doesn't seem to be a public kernel type.
> > + } v4l;
> > + struct {
> > + u32 major;
> > + u32 minor;
>
> And here.
>
> > + } fb;
> > + int alsa;
> > + int dvb;
> > +
> > + /* Sub-device specifications */
> > + /* Nothing needed yet */
> > + };
> > +};
--
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: [RFC/PATCH v3 01/10] media: Media device node support
Hi Hans,
On Sunday 01 August 2010 13:14:18 Hans Verkuil wrote:
> On Thursday 29 July 2010 18:06:34 Laurent Pinchart wrote:
> > The media_devnode structure provides support for registering and
> > unregistering character devices using a dynamic major number. Reference
> > counting is handled internally, making device drivers easier to write
> > without having to solve the open/disconnect race condition issue over
> > and over again.
> >
> > The code is based on video/v4l2-dev.c.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/media/Makefile|8 +-
> > drivers/media/media-devnode.c | 326
> > + include/media/media-devnode.h
> > | 84 +++
> > 3 files changed, 416 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/media/media-devnode.c
> > create mode 100644 include/media/media-devnode.h
>
>
>
> > diff --git a/drivers/media/media-devnode.c
> > b/drivers/media/media-devnode.c new file mode 100644
> > index 000..6f5558c
> > --- /dev/null
> > +++ b/drivers/media/media-devnode.c
>
>
>
> > +/* Override for the open function */
> > +static int media_open(struct inode *inode, struct file *filp)
> > +{
> > + struct media_devnode *mdev;
> > + int ret;
> > +
> > + /* Check if the media device is available. This needs to be done with
> > +* the media_devnode_lock held to prevent an open/unregister race:
> > +* without the lock, the device could be unregistered and freed between
> > +* the media_devnode_is_registered() and get_device() calls, leading to
> > +* a crash.
> > +*/
> > + mutex_lock(&media_devnode_lock);
> > + mdev = container_of(inode->i_cdev, struct media_devnode, cdev);
> > + /* return ENODEV if the media device has been removed
> > + already or if it is not registered anymore. */
> > + if (!media_devnode_is_registered(mdev)) {
> > + mutex_unlock(&media_devnode_lock);
> > + return -ENODEV;
> > + }
> > + /* and increase the device refcount */
> > + get_device(&mdev->dev);
> > + mutex_unlock(&media_devnode_lock);
> > + if (mdev->fops->open) {
> > + ret = mdev->fops->open(filp);
> > + if (ret) {
> > + put_device(&mdev->dev);
> > + return ret;
> > + }
> > + }
> > +
> > + filp->private_data = mdev;
>
> This line should be moved up to before the if: that way the open op can
> rely on private_data being setup correctly.
Agreed, I'll fix that.
> > + return 0;
> > +}
--
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: [Q]: any DVB-S2 card which is 45MS/s capable?
Hi. I have written some Mantis bandwidth related DMA transfer optimizations on June/July this year. They are now waiting for approval by Manu Abraham. Those reduce CPU pressure, increasing the bandwidth that can be received from the DVB card. 45MS/s bandwidth support will surely benefit from those patches. Main features: 1. Do one CPU interrupt per 16KB data instead per 4KB data. My implementation benefits only Mantis cards. https://patchwork.kernel.org/patch/107036/ 2. Remove unnecessary big CPU overhead, when data is delivered from the DVB card's DMA buffer into Linux kernel's DVB subsystem. Number 2 reduces the CPU pressure by almost 50%. This implementation benefits many other Linux supported DVB cards too. http://patchwork.kernel.org/patch/108274/ Those helped with my older single CPU Core computer with 256-QAM, delivering HDTV channel into the network and watching the HDTV channel with a faster computer. The performance bottlenecks could be seen on the command line with "perf top". I had to increase PCI bus latency setting into 64 too from the BIOS. Moving DVB device into separate IRQ line with Ethernet card helped too, because Ethernet card did an interrupt per ethernet packet. So if the hardware can deliver 45MS/s data fast enough, software side can be optimized up to some point. My patches contain the most easy major optimizations that I found. If you can test some of those patches, it might help to get them into Linux kernel faster. Best regards, Marko Ristola 27.07.2010 18:11, VDR User wrote: On Tue, Jul 27, 2010 at 5:52 AM, Emmanuel wrote: VDR User a écrit : Look at the vp-1041 I think. From what I gathered it is not able to do 45MS/s for DVB-S2. Thanks anyway, You may want to ask Manu Abraham (author of the mantis driver) about that to be sure. It seems I recall him telling me it could quite some time ago. -- 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
[RFC 2/4] drivers:staging:ti-st: Sources for FM RX
From: Raja-Mani
This has implementation for FM RX functionality.
It communicates with FM V4l2 module and FM common module.
Signed-off-by: Pramodh AG
Signed-off-by: Raja-Mani
---
drivers/staging/ti-st/fmdrv_rx.c | 805 ++
drivers/staging/ti-st/fmdrv_rx.h | 56 +++
2 files changed, 861 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv_rx.c
create mode 100644 drivers/staging/ti-st/fmdrv_rx.h
diff --git a/drivers/staging/ti-st/fmdrv_rx.c b/drivers/staging/ti-st/fmdrv_rx.c
new file mode 100644
index 000..8d5b9e9
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_rx.c
@@ -0,0 +1,805 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM RX functionality.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+
+void fm_rx_reset_rds_cache(struct fmdrv_ops *fmdev)
+{
+ fmdev->rx.rds.flag = FM_RDS_DISABLE;
+ fmdev->rx.rds.last_block_index = 0;
+ fmdev->rx.rds.wr_index = 0;
+ fmdev->rx.rds.rd_index = 0;
+
+ if (fmdev->rx.af_mode == FM_RX_RDS_AF_SWITCH_MODE_ON)
+ fmdev->irq_info.mask |= FM_LEV_EVENT;
+
+}
+
+void fm_rx_reset_curr_station_info(struct fmdrv_ops *fmdev)
+{
+ fmdev->rx.cur_station_info.picode = FM_NO_PI_CODE;
+ fmdev->rx.cur_station_info.no_of_items_in_afcache = 0;
+ fmdev->rx.cur_station_info.af_list_max = 0;
+}
+
+int fm_rx_set_frequency(struct fmdrv_ops *fmdev, unsigned int freq_to_set)
+{
+ unsigned long timeleft;
+ unsigned short payload, curr_frq, frq_index;
+ unsigned int curr_frq_in_khz;
+ int ret, resp_len;
+
+ if (fmdev->curr_fmmode != FM_MODE_RX) {
+ ret = -EPERM;
+ goto exit;
+ }
+
+ if (freq_to_set < fmdev->rx.region.bottom_frequency ||
+ freq_to_set > fmdev->rx.region.top_frequency) {
+ pr_err("(fmdrv): Invalid frequency %d", freq_to_set);
+ ret = -EINVAL;
+ goto exit;
+ }
+ /* Set audio enable */
+ FM_STORE_LE16_TO_BE16(payload, FM_RX_FM_AUDIO_ENABLE_I2S_AND_ANALOG);
+ ret = fmc_send_cmd(fmdev, AUDIO_ENABLE_SET, &payload, sizeof(payload),
+ &fmdev->maintask_completion, NULL, NULL);
+ FM_CHECK_SEND_CMD_STATUS(ret);
+
+ /* Set hilo to automatic selection */
+ FM_STORE_LE16_TO_BE16(payload, FM_RX_IFFREQ_HILO_AUTOMATIC);
+ ret = fmc_send_cmd(fmdev, HILO_SET, &payload, sizeof(payload),
+ &fmdev->maintask_completion, NULL, NULL);
+ FM_CHECK_SEND_CMD_STATUS(ret);
+
+ /* Calculate frequency index to write */
+ frq_index = (freq_to_set - fmdev->rx.region.bottom_frequency) /
+ fmdev->rx.region.channel_spacing;
+
+ /* Set frequency index */
+ FM_STORE_LE16_TO_BE16(payload, frq_index);
+ ret = fmc_send_cmd(fmdev, FREQ_SET, &payload, sizeof(payload),
+ &fmdev->maintask_completion, NULL, NULL);
+ FM_CHECK_SEND_CMD_STATUS(ret);
+
+ /* Read flags - just to clear any pending interrupts if we had */
+ ret = fmc_send_cmd(fmdev, FLAG_GET, NULL, 2,
+ &fmdev->maintask_completion, NULL, NULL);
+ FM_CHECK_SEND_CMD_STATUS(ret);
+
+ /* Enable FR, BL interrupts */
+ fmdev->irq_info.mask |= (FM_FR_EVENT | FM_BL_EVENT);
+ FM_STORE_LE16_TO_BE16(payload, fmdev->irq_info.mask);
+ ret = fmc_send_cmd(fmdev, INT_MASK_SET, &payload, sizeof(payload),
+ &fmdev->maintask_completion, NULL, NULL);
+ FM_CHECK_SEND_CMD_STATUS(ret);
+
+ /* Start tune */
+ FM_STORE_LE16_TO_BE16(payload, FM_TUNER_PRESET_MODE);
+ ret = fmc_send_cmd(fmdev, TUNER_MODE_SET, &payload, sizeof(payload),
+ &fmdev->maintask_completion, NULL, NULL);
+ FM_CHECK_SEND_CMD_STATUS(ret);
+
+ /* Wait for tune ended interrupt */
+ init_completion(&fmdev->maintask_completion);
+ timeleft = wait_for_completion_timeout(&fmdev->maintask_completion,
+ FM_DRV_TX_TIMEOUT);
+ if (!timeleft) {
+ pr_e
[RFC 4/4] drivers:staging:ti-st: Sources for FM common header
From: Raja-Mani
This is a common header used in all FM submodules
(FM V4L2,FM common,FM Rx).
Signed-off-by: Pramodh AG
Signed-off-by: Raja-Mani
---
drivers/staging/ti-st/fmdrv.h | 225 +
1 files changed, 225 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv.h
diff --git a/drivers/staging/ti-st/fmdrv.h b/drivers/staging/ti-st/fmdrv.h
new file mode 100644
index 000..d560570
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv.h
@@ -0,0 +1,225 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ *
+ * Common header for all FM driver sub-modules.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef _FM_DRV_H
+#define _FM_DRV_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FM_DRV_VERSION"0.01"
+/* Should match with FM_DRV_VERSION */
+#define FM_DRV_RADIO_VERSION KERNEL_VERSION(0, 0, 1)
+#define FM_DRV_NAME "ti_fmdrv"
+#define FM_DRV_CARD_SHORT_NAME"TI FM Radio"
+#define FM_DRV_CARD_LONG_NAME "Texas Instruments FM Radio"
+
+/* Flag info */
+#define FM_INTTASK_RUNNING0
+#define FM_INTTASK_SCHEDULE_PENDING 1
+#define FM_FIRMWARE_DW_INPROGRESS 2
+#define FM_CORE_READY 3
+#define FM_CORE_TRANSPORT_READY 4
+#define FM_AF_SWITCH_INPROGRESS 5
+#define FM_CORE_TX_XMITING 6
+
+#define FM_DRV_TX_TIMEOUT (5*HZ) /* 5 seconds */
+#define FM_DRV_RX_SEEK_TIMEOUT (20*HZ) /* 20 seconds */
+
+#define NO_OF_ENTRIES_IN_ARRAY(array) (sizeof(array) / sizeof(array[0]))
+
+enum {
+ FM_MODE_OFF,
+ FM_MODE_TX,
+ FM_MODE_RX,
+ FM_MODE_ENTRY_MAX
+};
+
+#define FM_RX_RDS_INFO_FIELD_MAX 8 /* 4 Group * 2 Bytes */
+
+/* RX RDS data format */
+struct fm_rdsdata_format {
+ union {
+ struct {
+ unsigned char rdsbuff[FM_RX_RDS_INFO_FIELD_MAX];
+ } groupdatabuff;
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned char block_c_byte1;
+ unsigned char block_c_byte2;
+ unsigned char block_d_byte1;
+ unsigned char block_d_byte2;
+ } groupgeneral;
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned char firstaf;
+ unsigned char secondaf;
+ unsigned char firstpsbyte;
+ unsigned char secondpsbyte;
+ } group0A;
+
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned short pidata2;
+ unsigned char firstpsbyte;
+ unsigned char secondpsbyte;
+ } group0B;
+ } rdsdata;
+};
+
+/* FM region (Europe/US, Japan) info */
+struct region_info {
+ unsigned int channel_spacing;
+ unsigned int bottom_frequency;
+ unsigned int top_frequency;
+ unsigned char region_index;
+};
+
+typedef void (*int_handler_prototype) (void *);
+
+/* FM Interrupt processing related info */
+struct fm_irq {
+ unsigned char stage_index;
+ unsigned short flag;/* FM interrupt flag */
+ unsigned short mask;/* FM interrupt mask */
+ /* Interrupt process timeout handler */
+ struct timer_list int_timeout_timer;
+ unsigned char irq_service_timeout_retry;
+ int_handler_prototype *fm_int_handlers;
+};
+
+/* RDS info */
+struct fm_rds {
+ unsigned char flag; /* RX RDS on/off status */
+ unsigned char last_block_index; /* Last received RDS block */
+
+ /* RDS buffer */
+ wait_queue_head_t read_queue;
+ unsigned int buf_size; /* Size is always multiple of 3 */
+ unsigned int wr_index;
+ unsigned int rd_index;
+ unsigned char *buffer;
+};
+
+#define FM_RDS_MAX_AF_LIST 25
+
+/* Current RX chann
[RFC 3/4] drivers:staging:ti-st: Sources for FM V4L2 interfaces
From: Raja-Mani
This module interfaces V4L2 subsystem and FM common
module. It registers itself with V4L2 as Radio module.
Signed-off-by: Pramodh AG
Signed-off-by: Raja-Mani
---
drivers/staging/ti-st/fmdrv_v4l2.c | 550
drivers/staging/ti-st/fmdrv_v4l2.h | 32 ++
2 files changed, 582 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c
create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h
diff --git a/drivers/staging/ti-st/fmdrv_v4l2.c
b/drivers/staging/ti-st/fmdrv_v4l2.c
new file mode 100644
index 000..047bce5
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_v4l2.c
@@ -0,0 +1,550 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This file provides interfaces to V4L2 subsystem.
+ *
+ * This module registers with V4L2 subsystem as Radio
+ * data system interface (/dev/radio). During the registration,
+ * it will expose two set of function pointers to V4L2 subsystem.
+ *
+ *1) File operation related API (open, close, read, write, poll...etc).
+ *2) Set of V4L2 IOCTL complaint API.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_v4l2.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+/* TODO: Enable when FM TX is supported */
+/* #include "fmdrv_tx.h" */
+
+static struct video_device *gradio_dev;
+static unsigned char radio_disconnected;
+
+/* Query control */
+static struct v4l2_queryctrl fmdrv_v4l2_queryctrl[] = {
+ {
+.id = V4L2_CID_AUDIO_VOLUME,
+.type = V4L2_CTRL_TYPE_INTEGER,
+.name = "Volume",
+.minimum = FM_RX_VOLUME_MIN,
+.maximum = FM_RX_VOLUME_MAX,
+.step = 1,
+.default_value = FM_DEFAULT_RX_VOLUME,
+},
+ {
+.id = V4L2_CID_AUDIO_BALANCE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+ {
+.id = V4L2_CID_AUDIO_BASS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+ {
+.id = V4L2_CID_AUDIO_TREBLE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+ {
+.id = V4L2_CID_AUDIO_MUTE,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = "Mute",
+.minimum = 0,
+.maximum = 2,
+.step = 1,
+.default_value = FM_MUTE_OFF,
+},
+ {
+.id = V4L2_CID_AUDIO_LOUDNESS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+};
+
+/* -- V4L2 RADIO (/dev/radioX) device file operation interfaces --- */
+/* Read RX RDS data */
+static ssize_t fm_v4l2_fops_read(struct file *file, char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ unsigned char rds_mode;
+ int ret;
+ struct fmdrv_ops *fmdev;
+
+ fmdev = video_drvdata(file);
+
+ if (!radio_disconnected) {
+ pr_err("(fmdrv): FM device is already disconnected\n");
+ ret = -EIO;
+ goto exit;
+ }
+
+ /* Turn on RDS mode , if it is disabled */
+ ret = fm_rx_get_rds_mode(fmdev, &rds_mode);
+ if (ret < 0) {
+ pr_err("(fmdrv): Unable to read current rds mode");
+ goto exit;
+ }
+ if (rds_mode == FM_RDS_DISABLE) {
+ ret = fmc_set_rds_mode(fmdev, FM_RDS_ENABLE);
+ if (ret < 0) {
+ pr_err("(fmdrv): Failed to enable rds mode");
+ goto exit;
+ }
+ }
+ /* Copy RDS data from internal buffer to user buffer */
+ ret = fmc_transfer_rds_from_internal_buff(fmdev, file, buf, count);
+
+exit:
+ return ret;
+}
+
+/* Write RDS data.
+ * TODO: When FM TX support is added, use "V4L2_CID_RDS_TX_" codes,
+ * instead of write operation.
+ */
+static ssize_t fm_v4l2_fops_write(struct file *file, const char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ struct tx_rds rds;
+ int ret;
+ struct fmdrv_ops *fmdev;
+
+ ret = copy_from_user(&rds, buf, sizeof(rds));
+ pr_info("(fmdrv): (%d)type: %d, text %s, af %d",
+ ret, rds.text_type, rds.text, rds.af_freq);
+
+ fmdev = video_drvdata(file);
+ /* TODO: Enable when FM TX is supported */
+ /* fm_tx_set_radio_text(fmdev, rds.text, rds.text_type); */
+
[RFC 0/4] FM V4L2 driver for WL128x
From: Raja-Mani The following patches are FM V4L2-Radio drivers for WL128x (backward compatible for WL127x). This driver makes use of TI Shared Transport driver for its transport via UART/TTY. Only FM Rx is supported as of now. Any FM V4L2 Radio standard application can make use of the '/dev/radioX' interface exposed by this driver to communicate with the TI FM chip. This doesn't include the handling of audio path and has support for RDS, FM firmware download, HW Seek, Tune, Volume control,etc. Tested with internal FM app and as well as with open source gnome-radio application and verified on SDP4430, kernel 2.6.35-rc5. Note: The patches however are re-based to the Stephen Rothwell's linux-next's drivers/staging/ti-st since the latest version of ST drivers exist there. Raja-Mani (4): drivers:staging:ti-st: sources for FM common interfaces drivers:staging:ti-st: Sources for FM RX drivers:staging:ti-st: Sources for FM V4L2 interfaces drivers:staging:ti-st: Sources for FM common header drivers/staging/ti-st/fmdrv.h| 225 drivers/staging/ti-st/fmdrv_common.c | 2127 ++ drivers/staging/ti-st/fmdrv_common.h | 459 drivers/staging/ti-st/fmdrv_rx.c | 805 + drivers/staging/ti-st/fmdrv_rx.h | 56 + drivers/staging/ti-st/fmdrv_v4l2.c | 550 + drivers/staging/ti-st/fmdrv_v4l2.h | 32 + 7 files changed, 4254 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/ti-st/fmdrv.h create mode 100644 drivers/staging/ti-st/fmdrv_common.c create mode 100644 drivers/staging/ti-st/fmdrv_common.h create mode 100644 drivers/staging/ti-st/fmdrv_rx.c create mode 100644 drivers/staging/ti-st/fmdrv_rx.h create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
>Russell King - ARM Linux wrote: >On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: >> Well, some of them are indeed unused, but it's not an uncommon practice in >> kernel and might help future developers. > >On the other hand, arch/arm is getting soo big that we need to do >something about this - and one solution is to avoid unnecessary >definitions that we're not using. > >Another good idea is to put definitions along side the drivers which >they're relevant to - maybe in a local driver-name.h file which >driver-name.c includes, or maybe even within driver-name.c if they're >not excessive. This has the advantage of distributing the "bloat" to >where its actually used, and means that the driver isn't dependent so >much on arch/arm or even the SoC itself. > >Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and >arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only >two files which contain platform definitions which are actually used >for Versatile Express. Compare that with >arch/arm/mach-realview/include/mach/platform.h which contains lots >more... So basically, what you and Mauro are recommending is that we move the *.h file with register definitions to drivers/media? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
On Mon, Aug 02, 2010 at 08:51:06AM -0300, Mauro Carvalho Chehab wrote: > Em 02-08-2010 07:52, Russell King - ARM Linux escreveu: > > On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: > >> Well, some of them are indeed unused, but it's not an uncommon practice in > >> kernel and might help future developers. > > > > On the other hand, arch/arm is getting soo big that we need to do > > something about this - and one solution is to avoid unnecessary > > definitions that we're not using. > > > > Another good idea is to put definitions along side the drivers which > > they're relevant to - maybe in a local driver-name.h file which > > driver-name.c includes, or maybe even within driver-name.c if they're > > not excessive. This has the advantage of distributing the "bloat" to > > where its actually used, and means that the driver isn't dependent so > > much on arch/arm or even the SoC itself. > > Very much appreciated from my side. It is very hard to sync changes that > happen via arm trees when merging from my tree. There were several cases > in the past were I needed to coordinate with an ARM maintainer about when > he would merge from his tree, as the patches I had on media tree were > highly dependent on the patches at arch. That's a separate problem - one which occurs when there's platform code in arch/arm/ which shares a common data structure with driver code under drivers/. I don't think there's an easy resolution to that one, because if you split the arch/arm/ change (which may depend on other arch/arm/ changes) from the drivers/ change, someone ends up losing no matter where the header file with the common data structure is placed. One answer to that is to kill the idea that every ARM architecture needs to define their own watchdog platform data - and instead replace it with a shared watchdog_platform_data structure, much like the flash_platform_data structure in arch/arm/include/asm/mach/flash.h (which'd would be nice to be under include/linux ...) -- 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: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300
On Mon, 2010-08-02 at 22:19 +1200, Shane Harrison wrote: [snip] > Thanks Lawrence, will give that a whirl tomorrow and the muting idea > might be important in this case as well. Wierd you posted Saturday > the day after I last worked on this and looked at the archives :-) > > I am not ruling out initialisation problems with the WM8775 but I do > always seem to get an I2S output from it that has data in it that > reflects the input. However it could be the wrong variant of I2S or > some other configuration that isn't set right. Currently in wm8775.c line 223, R11 is set to 0x21 which is 24-bit left justified mode. This is wrong, it should be i2s mode (0x22). My patch correctly sets this register and also disables ALC mode which is irrelevant when setting input level via ALSA and can cause hiss during quiet sections. > Strange how eventually > I do get audio (albeit mixed with the TV source it appears) simply by > looping thru and changing input sources with v4l2-ctl. Probably switching glitches eventually hit the right data synchronisation format. > I note that the Nova-S doesn't have the hardware MPEG encoding Correct. > so > still hoping someone can enlighten me on the audio path when using > that chip. When a Blackbird cx23416 MPEG encoder is fitted, i2s audio data from the wm8775 is routed through the cx23883. The i2s output of the cx23883 is enabled by the function set_audio_finish() in cx88-tvaudio.c line 148. The cx23416 can accept stereo Sony I2S format audio data when quoting from the Conexant datasheet "running its AILR sync signal through an inverting flip-flop, clocked by an inverted AICKIN". -- Lawrence Rust -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
Em 02-08-2010 07:52, Russell King - ARM Linux escreveu: > On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: >> Well, some of them are indeed unused, but it's not an uncommon practice in >> kernel and might help future developers. > > On the other hand, arch/arm is getting soo big that we need to do > something about this - and one solution is to avoid unnecessary > definitions that we're not using. > > Another good idea is to put definitions along side the drivers which > they're relevant to - maybe in a local driver-name.h file which > driver-name.c includes, or maybe even within driver-name.c if they're > not excessive. This has the advantage of distributing the "bloat" to > where its actually used, and means that the driver isn't dependent so > much on arch/arm or even the SoC itself. Very much appreciated from my side. It is very hard to sync changes that happen via arm trees when merging from my tree. There were several cases in the past were I needed to coordinate with an ARM maintainer about when he would merge from his tree, as the patches I had on media tree were highly dependent on the patches at arch. On several cases, I suspect that we had git bisect breakages (compilation or driver miss-functioning) due to those sync issues between two trees. A per-driver *.h file makes things easier, as such header file can be merged/maintained together with the subsystem tree where the driver belongs. > Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and > arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only > two files which contain platform definitions which are actually used > for Versatile Express. Compare that with > arch/arm/mach-realview/include/mach/platform.h which contains lots > more... > -- > 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 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: Handling of large keycodes
Em 02-08-2010 05:02, Dmitry Torokhov escreveu: > On Sat, Jul 31, 2010 at 10:23:45AM -0300, Mauro Carvalho Chehab wrote: >> Hi Dmitry, >> >> Em 31-07-2010 06:19, Dmitry Torokhov escreveu: >>> Hi Mauro, >>> >>> I finally got a chance to review the patches adding handling of large >>> scancodes to input core and there are a few things with this approach >>> that I do not like. >> >> Thanks for the review! >> >>> First of all I do not think that we should be working with scancode via >>> a pointer as it requires additional compat handling when running 32-bit >>> userspace on 64-bit kernel. We can use a static buffer of sufficient >>> size (lets say 32 bytes) to move scancode around and simply increase its >>> size if we come upon device that uses even bigger scancodes. As long as >>> buffer is at the end we can handle this in a compatible way. >> >> Yes, this is the downside of using a pointer. I'm not aware of a Remote >> Controller protocol using more than 256 bits for scancode, so 32 bits >> should be ok. >> >>> The other issue is that interface is notsymmetrical, setting is done by >>> scancode but retrieval is done by index. I think we should be able to >>> use both scancode and index in both operations. >> >> Yes, this also bothered me. I was thinking to do something similar to your >> approach of having a bool to select between them. This change is welcome. >> >>> The usefulnes of reserved data elements in the structure is doubtful, >>> since we do not seem to require them being set to a particular value and >>> so we'll be unable to distinguish betwee legacy and newer users. >> >> David proposed some parameters that we rejected on our discussions. As we >> might need to add something similar, I decided to keep it on my approach, >> since a set of reserved fields wouldn't hurt (and removing it on our >> discussions >> would be easy), but I'm ok on removing them. >> >>> I also concerned about the code very messy with regard to using old/new >>> style interfaces instea dof converting old ones to use new >>> insfrastructure, >> >> Good cleanup at the code! >> >>> I below is something that addresses these issues and seems to be working >>> for me. It is on top of your patches and it also depends on a few >>> changes in my tree that I have not publushed yet but plan on doing that >>> tomorrow. I am also attaching patches converting sparse keymap and hid >>> to the new style of getkeycode and setkeycode as examples. >>> >>> Please take a look and let me know if I missed something important. >> >> It seems to work for me. After you add the patches on your git tree, I'll >> work on porting the RC core to the new approach, and change the ir-keycode >> userspace program to work with, in order to be 100% sure that it will work, >> but I can't foresee any missing part on it. >> >> Currently, I'm not using my input patches, as I was waiting for your >> review. I just patched the userspace application, in order to test the legacy >> mode. >> > > OK, great. > > I want to fold all the patches from your tree plus this one into one and > apply in one shpt (mentioning Jarod and Dan as authors of fixup patches > in the changelog) - I do not believe we shoudl expose intermediate > versions in the code that will go to Linus. Are you OK with this? I'm OK. If you want, you can add my ack on your patch: Acked-by: Mauro Carvalho Chehab 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: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
Hello, On Monday, August 02, 2010 12:52 PM Russell King wrote: > On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: > > Well, some of them are indeed unused, but it's not an uncommon practice > in > > kernel and might help future developers. > > On the other hand, arch/arm is getting soo big that we need to do > something about this - and one solution is to avoid unnecessary > definitions that we're not using. > > Another good idea is to put definitions along side the drivers which > they're relevant to - maybe in a local driver-name.h file which > driver-name.c includes, or maybe even within driver-name.c if they're > not excessive. This has the advantage of distributing the "bloat" to > where its actually used, and means that the driver isn't dependent so > much on arch/arm or even the SoC itself. Well, with FIMC driver we just followed the style from other Samsung drivers. Just take a look at video/s3c-fb or usb/gadget/s3c-hsotg.c. I personally like to keep the same style for all drivers for Samsung IPs. Changing the style of all of them requires some amount of work, that would delay this particular driver even more so we will definitely miss the merge window. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: > Well, some of them are indeed unused, but it's not an uncommon practice in > kernel and might help future developers. On the other hand, arch/arm is getting soo big that we need to do something about this - and one solution is to avoid unnecessary definitions that we're not using. Another good idea is to put definitions along side the drivers which they're relevant to - maybe in a local driver-name.h file which driver-name.c includes, or maybe even within driver-name.c if they're not excessive. This has the advantage of distributing the "bloat" to where its actually used, and means that the driver isn't dependent so much on arch/arm or even the SoC itself. Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only two files which contain platform definitions which are actually used for Versatile Express. Compare that with arch/arm/mach-realview/include/mach/platform.h which contains lots more... -- 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 09/13] IR: add helper function for hardware with small o/b buffer.
On Sun, 2010-08-01 at 22:11 -0400, Andy Walls wrote:
> On Sat, 2010-07-31 at 17:59 +0300, Maxim Levitsky wrote:
> > Some ir input devices have small buffer, and interrupt the host
> > each time it is full (or half full)
> >
> > Add a helper that automaticly handles timeouts, and also
> > automaticly merges samples of same time (space-space)
> > Such samples might be placed by hardware because size of
> > sample in the buffer is small (a byte for example).
> >
> > Also remove constness from ir_dev_props, because it now contains timeout
> > settings that driver might want to change
> >
> > Signed-off-by: Maxim Levitsky
> > Acked-by: Jarod Wilson
>
> Hi Maxim and Jarod,
>
> I've started looking at this patch, and patch 10/13, to work with them
> and build upon them. I have some comments, below:
>
>
> > ---
> > drivers/media/IR/ir-core-priv.h |1 +
> > drivers/media/IR/ir-keytable.c |2 +-
> > drivers/media/IR/ir-raw-event.c | 84
> > +++
> > include/media/ir-core.h | 23 +-
> > 4 files changed, 106 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/IR/ir-core-priv.h
> > b/drivers/media/IR/ir-core-priv.h
> > index be68172..8053e3b 100644
> > --- a/drivers/media/IR/ir-core-priv.h
> > +++ b/drivers/media/IR/ir-core-priv.h
> > @@ -41,6 +41,7 @@ struct ir_raw_event_ctrl {
> >
> > /* raw decoder state follows */
> > struct ir_raw_event prev_ev;
> > + struct ir_raw_event this_ev;
> > struct nec_dec {
> > int state;
> > unsigned count;
> > diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
> > index 94a8577..34b9c07 100644
> > --- a/drivers/media/IR/ir-keytable.c
> > +++ b/drivers/media/IR/ir-keytable.c
> > @@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
> > */
> > int __ir_input_register(struct input_dev *input_dev,
> > const struct ir_scancode_table *rc_tab,
> > - const struct ir_dev_props *props,
> > + struct ir_dev_props *props,
> > const char *driver_name)
> > {
> > struct ir_input_dev *ir_dev;
> > diff --git a/drivers/media/IR/ir-raw-event.c
> > b/drivers/media/IR/ir-raw-event.c
> > index d0c18db..43094e7 100644
> > --- a/drivers/media/IR/ir-raw-event.c
> > +++ b/drivers/media/IR/ir-raw-event.c
> > @@ -140,6 +140,90 @@ int ir_raw_event_store_edge(struct input_dev
> > *input_dev, enum raw_event_type typ
> > EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
> >
> > /**
> > + * ir_raw_event_store_with_filter() - pass next pulse/space to decoders
> > with some processing
> > + * @input_dev: the struct input_dev device descriptor
> > + * @type: the type of the event that has occurred
> > + *
> > + * This routine (which may be called from an interrupt context) works
> > + * in similiar manner to ir_raw_event_store_edge.
> > + * This routine is intended for devices with limited internal buffer
> > + * It automerges samples of same type, and handles timeouts
> > + */
>
> I think this comment might need to explain the filtering being performed
> a little more explicitly, because "handles timeouts" wasn't enough to go
> on.
>
> >From what I can tell, it performs
>
> a. space aggrregation
> b. auto "idle" of the receiver and some state
> c. gap measurment and gap space event generation
> d, decoder reset at the end of the gap
>
> (For my needs, c. is very useful, and a. & d. don't hurt.)
>
> What is idle supposed to do for hardware that provides interrupts?
In my case, I can program hardware not to interrupt host until it has
a sample that isn't a overflow sample
Exaplanation what overflow sample is:
Hardware stores samples in small 8 bytes buffer, and has a flag which
half of this buffer to read.
Each sample is 8 bits, out of which 7 are timing and 8th is pulse/space.
So larger sample is sample period * 127.
If hardware wants to send larger sample, it sends this sample, and
another.
When I enable idle mode, it won't send sample with 127 within them.
Note that this is only supported on my receiver. Newer receivers don't
have that function, but rather stop sending samples on their own after
about 250 ms.
>
> Aside from asking the hardware driver to do something, idle otherwise
> appears to be used to keep track of being in a gap or not.
> Did I get that all right?
Yes of course.
>
> > +int ir_raw_event_store_with_filter(struct input_dev *input_dev,
> > + struct ir_raw_event *ev)
> > +{
> > + struct ir_input_dev *ir = input_get_drvdata(input_dev);
> > + struct ir_raw_event_ctrl *raw = ir->raw;
> > +
> > + if (!raw || !ir->props)
> > + return -EINVAL;
> > +
> > + /* Ignore spaces in idle mode */
> > + if (ir->idle && !ev->pulse)
> > + return 0;
> > + else if (ir->idle)
> > + ir_raw_event_set_idle(input_dev, 0);
> > +
> > + if (!raw->this_ev.durat
Re: [PATCH 00/20] MT9M111/MT9M131
Hey Guennadi, Robert sorry for that lack of information to those patches. I also just have been slicing one big patch into several canonical and tried to get rid of most tofu. You see the result in that patchseries. But since some big changes i could not figure out correctly, i left them in the stack for review. I should have adding an RFC to the Subject on those. Since i still have no response from the original author of these patches and you also see no sense in some changes i will condense the stack to a managable amount and will repost this v2 series in short time. Thanks for your time, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
Hello, >Kukjin Kim wrote: >Sylwester Nawrocki wrote: >> >> Add register definitions for the camera interface/video postprocessor >> contained in Samsung's S5P SoC series. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> Reviewed-by: Pawel Osciak >> Reviewed-by: Marek Szyprowski >> --- >> arch/arm/plat-samsung/include/plat/regs-fimc.h | 294 >> >> 1 files changed, 294 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/plat-samsung/include/plat/regs-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..7f3141c >> --- /dev/null >> +++ b/arch/arm/plat-samsung/include/plat/regs-fimc.h >> @@ -0,0 +1,294 @@ >> +/* arch/arm/plat-s5p/include/plat/regs-fimc.h >> + * >> + * Register definition file for Samsung Camera Interface (FIMC) driver > >Looks ok...however, I'm still thinking whether really need all these >definitions. > >Hmm... > Well, some of them are indeed unused, but it's not an uncommon practice in kernel and might help future developers. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D 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
Fwd: No audio in HW Compressed MPEG2 container on HVR-1300
On Mon, Aug 2, 2010 at 9:32 PM, lawrence rust wrote: > > On Mon, 2010-08-02 at 14:15 +1200, Shane Harrison wrote: > > Hi There, > > > > I am having a problem with getting an audio stream present in the > > MPEG2 stream from an HVR-1300 card. > > [snip] > > > Problem > > ~~ > > The delivered MPEG-2 stream generally has no audio component. Mplayer > > reports "no audio found". > > > > The same problem exists for both TV input and composite input. By > > repeatedly switching between the TV input and the Composite input we > > can eventually get an audio component in the MPEG-2 stream. > > Thereafter we always get the audio component until a power off and > > restart. Simply rebooting (no power off) seems to still leave things > > in a state where the audio component is in the MPEG-2 stream. > > > > There is a second problem, the audio stream always contains white > > noise (I assume TV tuner noise - we don't have it tuned nor an aerial > > attached) mixed with the signal applied to the analog in ports. > > > > Analysis > > ~~ > > The most likely scenario is that the hardware is not being initialised > > correctly most of the time, once it is initialised correctly then it > > works thereafter. Unfortunately it is difficult to determine the > > actual audio path being used. Clearly the audio comes into the WM8775 > > (DAC) via a bus switch that switches between the composite/audio on > > the back panel and the white header. It then enters the CX2388x via > > the I2S input pins. We initially assumed that the audio was then > > routed through to the CX23416 (MPEG Encoder) via the I2S output pins > > of the CX2388x, but we have begun to doubt this assumption since the > > CX2388x is set in normal mode by the drivers and the captured audio > > doesn't reflect the bit patterns we see on the I2S Data Out line using > > an oscilloscope. That is, when we apply *no* signal to the analog > > input, the I2S Dout line is "quiet" yet we hear white noise. > > > > Questions > > > > 1) Anyone have any similar experiences? > > This sounds very much like the problems that I had with my Nova-S-plus > card while developing a patch to capture line-in audio with composite > video. Looking at the docs for the wm8775 it appeared that it wasn't > being correctly initialised. I also found need to change the cx88 code > to mute/un-mute audio in. Maybe you should try applying this patch, I > posted it to this group on Saturday - see. > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg21030.html > > -- Lawrence Rust > > Thanks Lawrence, will give that a whirl tomorrow and the muting idea might be important in this case as well. Wierd you posted Saturday the day after I last worked on this and looked at the archives :-) I am not ruling out initialisation problems with the WM8775 but I do always seem to get an I2S output from it that has data in it that reflects the input. However it could be the wrong variant of I2S or some other configuration that isn't set right. Strange how eventually I do get audio (albeit mixed with the TV source it appears) simply by looping thru and changing input sources with v4l2-ctl. I note that the Nova-S doesn't have the hardware MPEG encoding so still hoping someone can enlighten me on the audio path when using that chip. Cheers Shane -- 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
STK7700D id is 1164:0871 on Toshiba A660 laptops, conflicts with Yuan MC770
Hello all, I am running Ubuntu 10.04 on a Toshiba A660-14x laptop. The hybrid tuner is being reported in Windows 7 as based on the STK7700D. Both tuners (dvb & analog) work correctly there. However, it's usb vendor & device strings are 1164:0871, see the output of hwinfo below. This makes the dvb modules configure it as if it where a "Yuan High-Tech MC770" This results in Linux only seeing the DVB tuner, which works fine. The analog one isn't used, so I am missing all the analog channels (there are still some :-) ) I can catch from my location. Is there any module options I could pass to "force" it to be seen as a STK770D ? Best regards, Olivier 09: USB 00.0: Unclassified device [Created at usb.122] UDI: /org/freedesktop/Hal/devices/usb_device_1164_871_01_if0 Unique ID: VBUu.DOCYvzmCULD Parent ID: ADDn.0j9+vWlqL56 SysFS ID: /devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0 SysFS BusID: 1-1.5:1.0 Hardware Class: unknown Model: "YUAN High-Tech Development STK7700D" Hotplug: USB Vendor: usb 0x1164 "YUAN High-Tech Development Co., Ltd" Device: usb 0x0871 "STK7700D" Revision: "1.00" Serial ID: "01" Driver: "dvb_usb_dib0700" Driver Modules: "dvb_usb_dib0700" Speed: 480 Mbps Module Alias: "usb:v1164p0871d0100dc00dsc00dp00icFFisc00ip00" Driver Info #0: Driver Status: dvb_usb_dib0700 is active Driver Activation Cmd: "modprobe dvb_usb_dib0700" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #5 (Hub) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] V4L/DVB: radio-si4713: Release i2c adapter in driver cleanup paths
On Mon, 05 Jul 2010 16:28:30 -0300 Mauro Carvalho Chehab wrote: > Hi Eduardo, > > Could you please review those two patches? > Hmm.. are these two patches already late for 2.6.36? I have two another patches to arch/arm/mach-omap2/board-rx51-peripherals.c and sound/soc/omap/rx51.c that are pending from patch 2/2. -- Jarkko -- 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: No audio in HW Compressed MPEG2 container on HVR-1300
On Mon, 2010-08-02 at 14:15 +1200, Shane Harrison wrote: > Hi There, > > I am having a problem with getting an audio stream present in the > MPEG2 stream from an HVR-1300 card. [snip] > Problem > ~~ > The delivered MPEG-2 stream generally has no audio component. Mplayer > reports "no audio found". > > The same problem exists for both TV input and composite input. By > repeatedly switching between the TV input and the Composite input we > can eventually get an audio component in the MPEG-2 stream. > Thereafter we always get the audio component until a power off and > restart. Simply rebooting (no power off) seems to still leave things > in a state where the audio component is in the MPEG-2 stream. > > There is a second problem, the audio stream always contains white > noise (I assume TV tuner noise - we don't have it tuned nor an aerial > attached) mixed with the signal applied to the analog in ports. > > Analysis > ~~ > The most likely scenario is that the hardware is not being initialised > correctly most of the time, once it is initialised correctly then it > works thereafter. Unfortunately it is difficult to determine the > actual audio path being used. Clearly the audio comes into the WM8775 > (DAC) via a bus switch that switches between the composite/audio on > the back panel and the white header. It then enters the CX2388x via > the I2S input pins. We initially assumed that the audio was then > routed through to the CX23416 (MPEG Encoder) via the I2S output pins > of the CX2388x, but we have begun to doubt this assumption since the > CX2388x is set in normal mode by the drivers and the captured audio > doesn't reflect the bit patterns we see on the I2S Data Out line using > an oscilloscope. That is, when we apply *no* signal to the analog > input, the I2S Dout line is "quiet" yet we hear white noise. > > Questions > > 1) Anyone have any similar experiences? This sounds very much like the problems that I had with my Nova-S-plus card while developing a patch to capture line-in audio with composite video. Looking at the docs for the wm8775 it appeared that it wasn't being correctly initialised. I also found need to change the cx88 code to mute/un-mute audio in. Maybe you should try applying this patch, I posted it to this group on Saturday - see. http://www.mail-archive.com/linux-media@vger.kernel.org/msg21030.html -- Lawrence Rust -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 1/3] v4l: Add multi-planar API definitions to the V4L2 API
Hi Pawel!
> Hi Hans,
> thank you for the review.
>
>>Hans Verkuil wrote:
>>On Friday 30 July 2010 10:49:41 Pawel Osciak wrote:
>
>
>
>>> @@ -157,9 +158,23 @@ enum v4l2_buf_type {
>>> /* Experimental */
>>> V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
>>> #endif
>>> + V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 17,
>>> + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 18,
>>
>>Why 17 and 18 instead of 9 and 10?
>>
>
> To be able to test for "mplane" versions with a bit operation,
> (type & 0x10), and to leave some space for future extensions
> to "old" formats. I can go back to 9, 10 though if you prefer.
I prefer 9, 10. I would agree with you if there was some sort
of numbering scheme already, but it is just an enum with no particular
order.
>
>
>>> + *
>>> + * Multi-planar buffers consist of one or more planes, e.g. an YCbCr
>>buffer
>>> + * with two planes can have one plane for Y, and another for
>>> interleaved
>>CbCr
>>> + * components. Each plane can reside in a separate memory buffer, or
>>> even
>>in
>>> + * a completely separate memory node (e.g. in embedded devices).
>>> + */
>>> +struct v4l2_plane {
>>> + __u32 bytesused;
>>> + __u32 length;
>>> + union {
>>> + __u32 mem_offset;
>>> + unsigned long userptr;
>>> + } m;
>>> + __u32 data_offset;
>>> + __u32 reserved[11];
>>> +};
>>> +
>>> +/**
>>> + * struct v4l2_buffer - video buffer info
>>> + * @index: id number of the buffer
>>> + * @type: buffer type (type == *_MPLANE for multiplanar buffers)
>>> + * @bytesused: number of bytes occupied by data in the buffer
>>> (payload);
>>> + * unused (set to 0) for multiplanar buffers
>>> + * @flags: buffer informational flags
>>> + * @field: field order of the image in the buffer
>>> + * @timestamp: frame timestamp
>>> + * @timecode: frame timecode
>>> + * @sequence: sequence count of this frame
>>> + * @memory:the method, in which the actual video data is passed
>>> + * @offset:for non-multiplanar buffers with memory ==
>>V4L2_MEMORY_MMAP;
>>> + * offset from the start of the device memory for this
>>> plane,
>>> + * (or a "cookie" that should be passed to mmap() as
>>> offset)
>>> + * @userptr: for non-multiplanar buffers with memory ==
>>V4L2_MEMORY_USERPTR;
>>> + * a userspace pointer pointing to this buffer
>>> + * @planes:for multiplanar buffers; userspace pointer to the array
>>of plane
>>> + * info structs for this buffer
>>> + * @length:size in bytes of the buffer (NOT its payload) for
>>> single-
>>plane
>>> + * buffers (when type != *_MPLANE); number of planes (and
>>> number
>>> + * of elements in the planes array) for multi-plane buffers
>>
>>This is confusing. Just write "number of elements in the planes array".
>>
>>> + * @input: input number from which the video data has has been
>>> captured
>>> + *
>>> + * Contains data exchanged by application and driver using one of the
>>Streaming
>>> + * I/O methods.
>>> + */
>>> struct v4l2_buffer {
>>> __u32 index;
>>> enum v4l2_buf_type type;
>>> @@ -529,6 +606,7 @@ struct v4l2_buffer {
>>> union {
>>> __u32 offset;
>>> unsigned long userptr;
>>> + struct v4l2_plane *planes;
>>
>>Should use the __user attribute.
>>
>
> We discussed this already, just for others: since we use the "planes"
> pointer
> both as __user and kernel pointer, it's not worth it. We'd have to do some
> obscure #ifdef magic and redefine the struct for parts of kernel code.
> The same thing goes for controls pointer in v4l2_ext_controls.
Indeed. This is also the reason why there is no __user in v4l2_ext_controls.
Regards,
Hans
--
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: [PATCH v5 2/3] v4l: Add multi-planar ioctl handling code
Hi,
>Hans Verkuil wrote:
>On Friday 30 July 2010 10:49:42 Pawel Osciak wrote:
>> static long __video_do_ioctl(struct file *file,
>> unsigned int cmd, void *arg)
>> {
>> struct video_device *vfd = video_devdata(file);
>> const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
>> void *fh = file->private_data;
>> +struct v4l2_format f_copy;
>> long ret = -EINVAL;
>>
>> if (ops == NULL) {
>> @@ -720,6 +822,11 @@ static long __video_do_ioctl(struct file *file,
>> if (ops->vidioc_enum_fmt_vid_cap)
>> ret = ops->vidioc_enum_fmt_vid_cap(file, fh, f);
>> break;
>> +case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>> +if (ops->vidioc_enum_fmt_vid_cap_mplane)
>> +ret = ops->vidioc_enum_fmt_vid_cap_mplane(file,
>> +fh, f);
>> +break;
>> case V4L2_BUF_TYPE_VIDEO_OVERLAY:
>> if (ops->vidioc_enum_fmt_vid_overlay)
>> ret = ops->vidioc_enum_fmt_vid_overlay(file,
>> @@ -729,6 +836,11 @@ static long __video_do_ioctl(struct file *file,
>> if (ops->vidioc_enum_fmt_vid_out)
>> ret = ops->vidioc_enum_fmt_vid_out(file, fh, f);
>> break;
>> +case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>> +if (ops->vidioc_enum_fmt_vid_out_mplane)
>> +ret = ops->vidioc_enum_fmt_vid_out_mplane(file,
>> +fh, f);
>> +break;
>> case V4L2_BUF_TYPE_PRIVATE:
>> if (ops->vidioc_enum_fmt_type_private)
>> ret = ops->vidioc_enum_fmt_type_private(file,
>> @@ -757,22 +869,79 @@ static long __video_do_ioctl(struct file *file,
>>
>> switch (f->type) {
>> case V4L2_BUF_TYPE_VIDEO_CAPTURE:
>> -if (ops->vidioc_g_fmt_vid_cap)
>> +if (ops->vidioc_g_fmt_vid_cap) {
>> ret = ops->vidioc_g_fmt_vid_cap(file, fh, f);
>> +} else if (ops->vidioc_g_fmt_vid_cap_mplane) {
>> +if (fmt_sp_to_mp(f, &f_copy))
>> +break;
>> +ret = ops->vidioc_g_fmt_vid_cap_mplane(file, fh,
>> +
>> &f_copy);
>> +/* Driver is currently in multi-planar format,
>> + * we can't return it in single-planar API*/
>> +if (f_copy.fmt.pix_mp.num_planes > 1) {
>
>Only do this if ret == 0.
>
Good point, thanks. Driver-produced errors should take precedence over EBUSY.
Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 1/3] v4l: Add multi-planar API definitions to the V4L2 API
Hi Hans,
thank you for the review.
>Hans Verkuil wrote:
>On Friday 30 July 2010 10:49:41 Pawel Osciak wrote:
>> @@ -157,9 +158,23 @@ enum v4l2_buf_type {
>> /* Experimental */
>> V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
>> #endif
>> +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 17,
>> +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 18,
>
>Why 17 and 18 instead of 9 and 10?
>
To be able to test for "mplane" versions with a bit operation,
(type & 0x10), and to leave some space for future extensions
to "old" formats. I can go back to 9, 10 though if you prefer.
>> + *
>> + * Multi-planar buffers consist of one or more planes, e.g. an YCbCr
>buffer
>> + * with two planes can have one plane for Y, and another for interleaved
>CbCr
>> + * components. Each plane can reside in a separate memory buffer, or even
>in
>> + * a completely separate memory node (e.g. in embedded devices).
>> + */
>> +struct v4l2_plane {
>> +__u32 bytesused;
>> +__u32 length;
>> +union {
>> +__u32 mem_offset;
>> +unsigned long userptr;
>> +} m;
>> +__u32 data_offset;
>> +__u32 reserved[11];
>> +};
>> +
>> +/**
>> + * struct v4l2_buffer - video buffer info
>> + * @index: id number of the buffer
>> + * @type: buffer type (type == *_MPLANE for multiplanar buffers)
>> + * @bytesused: number of bytes occupied by data in the buffer
>> (payload);
>> + * unused (set to 0) for multiplanar buffers
>> + * @flags: buffer informational flags
>> + * @field: field order of the image in the buffer
>> + * @timestamp: frame timestamp
>> + * @timecode: frame timecode
>> + * @sequence: sequence count of this frame
>> + * @memory: the method, in which the actual video data is passed
>> + * @offset: for non-multiplanar buffers with memory ==
>V4L2_MEMORY_MMAP;
>> + * offset from the start of the device memory for this plane,
>> + * (or a "cookie" that should be passed to mmap() as offset)
>> + * @userptr:for non-multiplanar buffers with memory ==
>V4L2_MEMORY_USERPTR;
>> + * a userspace pointer pointing to this buffer
>> + * @planes: for multiplanar buffers; userspace pointer to the array
>of plane
>> + * info structs for this buffer
>> + * @length: size in bytes of the buffer (NOT its payload) for single-
>plane
>> + * buffers (when type != *_MPLANE); number of planes (and number
>> + * of elements in the planes array) for multi-plane buffers
>
>This is confusing. Just write "number of elements in the planes array".
>
>> + * @input: input number from which the video data has has been captured
>> + *
>> + * Contains data exchanged by application and driver using one of the
>Streaming
>> + * I/O methods.
>> + */
>> struct v4l2_buffer {
>> __u32 index;
>> enum v4l2_buf_type type;
>> @@ -529,6 +606,7 @@ struct v4l2_buffer {
>> union {
>> __u32 offset;
>> unsigned long userptr;
>> +struct v4l2_plane *planes;
>
>Should use the __user attribute.
>
We discussed this already, just for others: since we use the "planes" pointer
both as __user and kernel pointer, it's not worth it. We'd have to do some
obscure #ifdef magic and redefine the struct for parts of kernel code.
The same thing goes for controls pointer in v4l2_ext_controls.
Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D 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
TeVii S470 periodically fails to tune/lock - needs poweroff
Hello Guys, I have been using my TeVii S470 DVBS2 card for about one month . I am using it with mythtv on fedora 12 using latest kernel , and compiled the latest v4l drivers . The sensitivity and picture is very good both on dvbs and dvbs2 transponders , very happy with that . However several times already when trying to watch live tv on myth the channel failed to tune . Usually happens in the morning after box was running 24x7 for a few days . The only way to restore functionality is to do a power off and wait a couple of mins . If I just do a reboot , this does not help . Strange thing is that I see nothing in the mythtv logs or dmesg or messages log . When the card is in this no-lock state , it will not tune into any channel even when I run scandvb . After power off everything works again for a few more days . Any info welcome . Best Regards Milorad -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 0/3] Multi-planar video format and buffer support for the V4L2 API
Hi, thanks for the review. >Karicheri, Muralidharan wrote: > >> >> >>7. Format conversion >>-- >>v4l2 core ioctl handling includes a simple conversion layer that allows >>translation - when possible - between multi-planar and single-planar APIs, >>transparently to drivers and applications. >> >>The table below summarizes conversion behavior for cases when driver and >>application use different API versions: >> >>--- >> | Application MP --> Driver SP --> Application MP >> G_FMT |always OK | always OK >> S_FMT |-EINVAL | always OK >> TRY_FMT |-EINVAL | always OK >>--- >> | Application SP --> Driver MP --> Application SP >> G_FMT |always OK | -EBUSY >> S_FMT |always OK | -EBUSY and WARN() >> TRY_FMT |always OK | -EBUSY and WARN() >> > >What is the logic behind using -EBUSY for this? Why not -EINVAL? Also why use >WARN()? > We think that it's better to return EBUSY from a G_FMT call to say: "Your call is valid, but I cannot tell you the format now, but may be able to later" (i.e. after I switch back to a single-planar format). EINVAL just says "Your call is invalid", i.e. no point in retrying. Also, EINVAL doesn't really make sense for G_FMT. WARN because, as explained below, we think of it as a bug in driver to adjust a 1-plane format to a >1-plane format on S/TRY. >>Legend: >>- SP - single-planar API used (NOT format!) >>- MP - multi-planar API used (NOT format!) >>- always OK - conversion is always valid irrespective of number of planes >>- -EINVAL - if an MP application tries to TRY or SET a format with more >>than 1 plane, EINVAL is returned from the conversion function >>(of course, 1-plane multi-planar formats work and are >>converted) >>- -EBUSY - if an MP driver returns a more than 1-plane format to an SP >> application, the conversion layer returns EBUSY to the >>application; >> this is useful in cases when the driver is currently set to a >>more >> than 1-plane format, SP application would not be able to >>understand >> it) >>- -EBUSY and WARN() - there is only one reason for which SET or TRY from an >>SP >> application would result in a driver returning a more than 1- >>plane >> format - when the driver adjusts a 1-plane format to a more than >> 1-plane format. This should not happen and is a bug in driver, >>hence >> a WARN_ON(). Application receives EBUSY. >> >> > >Suppose, S_FMT/TRY_FMT is called with UYVY format and driver supports only >NV12 (2 plane) only, then for > >Application SP --> Driver MP --> Application SP > >I guess in this case, new drivers that supports multi-plane format would have >to return old NV12 format code (for backward compatibility). Is >this handled by driver or translation layer? > Not really. If a driver supports a 2-plane format only, an SP application won't be able to use it (unless we copy video data from two separate memory buffers into one and back on each QBUF/DQBUF in core ioctl handling, I don't think we want to go that far). The app expects one buffer, not two. So this is an EINVAL. >Application MP --> Driver SP --> Application MP > >In this case, new driver would return new NV12 format code and have no issue. >Not sure what translation layer does in this scenario. > Again, not really. If an MP application requests a 2-plane format, the driver cannot support it (it can support 1-plane formats only). So this is also an EINVAL. Overall, we do not convert v4l2_buffers, we only convert format structs (not the actual formats). > > >> >>=== >>V. Using ioctl()s and mmap() >>=== >> >>* Format calls (VIDIOC_S/TRY/G_FMT) are converted transparently across APIs >> by the ioctl handling code, where possible. Conversion from single-planar >> to multi-planar cannot fail, but the other way around is possible only >>for >> 1-plane formats. >> Possible errors in conversion are described below. >> > >Could you explain what you mean by conversion of formats? The idea of the >translation layer functionality is not clear to me. An example would help. > I guess this needs to be rephrased: It doesn't convert the actual formats, it only converts between APIs, i.e. between different format structs. So it's a conversion between struct v4l2_pix_format_mplane and struct v4l2_pix_format. It's not a conversion of formats, the format stays completely identical. So basically an NV12 format can be passed as well in a v4l2_pix_format struct as in v4l2_pix_format_mplane. Fourccs and other fields will be exactly the same. Only the location of those fields will differ, a v4l2_pix
Re: Handling of large keycodes
On Sat, Jul 31, 2010 at 01:03:26PM +0200, Stefan Richter wrote:
> Dmitry Torokhov wrote:
> > --- a/include/linux/input.h
> > +++ b/include/linux/input.h
> > @@ -56,22 +56,35 @@ struct input_absinfo {
> > __s32 resolution;
> > };
> >
> > -struct keycode_table_entry {
> > - __u32 keycode; /* e.g. KEY_A */
> > - __u32 index;/* Index for the given scan/key table, on
> > EVIOCGKEYCODEBIG */
> > - __u32 len; /* Length of the scancode */
> > - __u32 reserved[2]; /* Reserved for future usage */
> > - char *scancode; /* scancode, in machine-endian */
> > +/**
> > + * struct keymap_entry - used by EVIOCGKEYCODE/EVIOCSKEYCODE ioctls
> > + * @scancode: scancode represented in machine-endian form.
> > + * @len: length of the scancode that resides in @scancode buffer.
> > + * @index: index in the keymap, may be used instead of scancode
> > + * @by_index: boolean value indicating that kernel should perform
> > + * lookup in keymap by @index instead of @scancode
> > + * @keycode: key code assigned to this scancode
> > + *
> > + * The structure is used to retrieve and modify keymap data. Users have
> > + * of performing lookup either by @scancode itself or by @index in
> > + * keymap entry. EVIOCGKEYCODE will also return scancode or index
> > + * (depending on which element was used to perform lookup).
> > + */
> > +struct keymap_entry {
> > + __u8 len;
> > + __u8 by_index;
> > + __u16 index;
> > + __u32 keycode;
> > + __u8 scancode[32];
> > };
>
> I agree with Dimitry; don't put a pointer typed member into a userspace
> ABI struct.
>
> Two remarks:
>
> - Presently, defines three structs named input_... for
> userspace, two structs named input_... for kernelspace, and a few
> structs named ff_... specially for force-feedback stuff. How about
> calling struct keymap_entry perhaps struct input_keymap_entry
> instead, to keep namespaces tidy?
Good idea, changed.
>
> - I take it from your description that scan codes are fundamentally
> variable-length data. How about defining it as __u8 scancode[0]?
In addition to difficulty in adding members (as you mentioned) it also
makes it more difficult for users to allocate such variables on stack or
make them global (anything but malloc with additional memory buffer)...
--
Dmitry
--
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: Handling of large keycodes
On Sat, Jul 31, 2010 at 10:23:45AM -0300, Mauro Carvalho Chehab wrote: > Hi Dmitry, > > Em 31-07-2010 06:19, Dmitry Torokhov escreveu: > > Hi Mauro, > > > > I finally got a chance to review the patches adding handling of large > > scancodes to input core and there are a few things with this approach > > that I do not like. > > Thanks for the review! > > > First of all I do not think that we should be working with scancode via > > a pointer as it requires additional compat handling when running 32-bit > > userspace on 64-bit kernel. We can use a static buffer of sufficient > > size (lets say 32 bytes) to move scancode around and simply increase its > > size if we come upon device that uses even bigger scancodes. As long as > > buffer is at the end we can handle this in a compatible way. > > Yes, this is the downside of using a pointer. I'm not aware of a Remote > Controller protocol using more than 256 bits for scancode, so 32 bits > should be ok. > > > The other issue is that interface is notsymmetrical, setting is done by > > scancode but retrieval is done by index. I think we should be able to > > use both scancode and index in both operations. > > Yes, this also bothered me. I was thinking to do something similar to your > approach of having a bool to select between them. This change is welcome. > > > The usefulnes of reserved data elements in the structure is doubtful, > > since we do not seem to require them being set to a particular value and > > so we'll be unable to distinguish betwee legacy and newer users. > > David proposed some parameters that we rejected on our discussions. As we > might need to add something similar, I decided to keep it on my approach, > since a set of reserved fields wouldn't hurt (and removing it on our > discussions > would be easy), but I'm ok on removing them. > > > I also concerned about the code very messy with regard to using old/new > > style interfaces instea dof converting old ones to use new > > insfrastructure, > > Good cleanup at the code! > > > I below is something that addresses these issues and seems to be working > > for me. It is on top of your patches and it also depends on a few > > changes in my tree that I have not publushed yet but plan on doing that > > tomorrow. I am also attaching patches converting sparse keymap and hid > > to the new style of getkeycode and setkeycode as examples. > > > > Please take a look and let me know if I missed something important. > > It seems to work for me. After you add the patches on your git tree, I'll > work on porting the RC core to the new approach, and change the ir-keycode > userspace program to work with, in order to be 100% sure that it will work, > but I can't foresee any missing part on it. > > Currently, I'm not using my input patches, as I was waiting for your > review. I just patched the userspace application, in order to test the legacy > mode. > OK, great. I want to fold all the patches from your tree plus this one into one and apply in one shpt (mentioning Jarod and Dan as authors of fixup patches in the changelog) - I do not believe we shoudl expose intermediate versions in the code that will go to Linus. Are you OK with this? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick
On Sun, Aug 01, 2010 at 05:17:18PM -0300, Mauro Carvalho Chehab wrote:
> Add the proper gpio port for WinTV MiniStick, with the information provided
> by Michael.
>
> Thanks-to: Michael Krufky
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/media/dvb/siano/sms-cards.c
> b/drivers/media/dvb/siano/sms-cards.c
> index cff77e2..dcde606 100644
> --- a/drivers/media/dvb/siano/sms-cards.c
> +++ b/drivers/media/dvb/siano/sms-cards.c
> @@ -67,6 +67,7 @@ static struct sms_board sms_boards[] = {
> .board_cfg.leds_power = 26,
> .board_cfg.led0 = 27,
> .board_cfg.led1 = 28,
> + .board_cfg.ir = 9,
are you sure about this?
I am using the value of 4 for the ir port and it definitely works.. confused.
Thanks for looking at it, will test the patches as soon as I can.
Richard
--
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
