Re: mantis crashes
Den 21.08.2010 21:11, skrev Hans van den Bogert: > Vidar Tyldum Hansen tyldum.com> writes: > >> So now I will revert to stock Lucid kernel and give your patch a go. But >> I have a feeling this has something might be some incompatibility or bug >> between the card and the motherboard (Asus P5N7A-VM). This, though is >> beyond me... >> > > Late reply, but > Probably is nvidia/bios/asus incompatibility, I used a M3N78-pro > > No further luck getting this to work? No, I gave up in the end. Mucking around with this also messes with my V4L so I decided to wait for Ubuntu to ship the module. -- Vidar Tyldum vi...@tyldum.com PGP: 0x3110AA98 signature.asc Description: OpenPGP digital signature
cx23885: Message Signaled Interrupts issue
I was wondering, if someone tried 2.6.36-rc kernels with PCIe MSI enabled. With TeVii s470 after rmmod cx23885 && insmod cx23885 then szap some channel I have 'No irq handler for vector' message. After reboot it's OK. I think it's A/V core interrupts involved. i...@useri:~$ szap -l10750 bridge-tv -p reading channels from file '/home/igor/.szap/channels.conf' zapping to 5 'bridge-tv': sat 1, frequency = 12303 MHz H, symbolrate 2750, vpid = 0x0134, apid = 0x0100 sid = 0x003b using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' Message from sysl...@localhost at Tue Aug 31 00:55:32 2010 ... localhost kernel: do_IRQ: 1.137 No irq handler for vector (irq -1) Message from sysl...@localhost at Tue Aug 31 00:55:33 2010 ... localhost kernel: do_IRQ: 0.137 No irq handler for vector (irq -1) Message from sysl...@localhost at Tue Aug 31 00:55:34 2010 ... localhost kernel: do_IRQ: 1.137 No irq handler for vector (irq -1) Message from sysl...@localhost at Tue Aug 31 00:55:35 2010 ... localhost kernel: do_IRQ: 0.137 No irq handler for vector (irq -1) It is similar issue with NetUP DVB-S2 , but CI involved through GPIO interrupts. Compro e650f works well, though it uses neither A/V core interrupts nor GPIO interrupts. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx23885: Support for IR-Remote on boad TBV-6920
Hello! I am trying to get the remote control of my DVB 6920 (cx23885) to work. I found out that the wiring of the sensor is the same as on the TiVii S470, so there is little work to be done. Unfortunately, the IR part of cx23885 driver inside the kernel is buggy. You fixed that, right? Could you please give me access to your current cx23885 driver? Best regards, Simon Waid -- 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: Problems with Freecom USB DVB-T dongles
In message <+ay15vcwvxdmf...@echelon.upsilon.org.uk>, dave cunningham wrote Hi, I'm having problems with a pair of Freecom USB dongles and am wondering if anyone has any pointers? In dmesg at boot I see one message for each device "dvb-usb: recv bulk message failed: -110" Other than this everything seems OK. The system is running MythTV Backend (0.23) and I can have them both recording simultaneously as I would expect. At some point however I start to get floods of messages to the console (repeats of "dvb-usb: recv bulk message failed: -110") and the system slows down to a crawl. I'm still looking for any suggestions. From a brief look at the source this message seems to be coming from a call to usb_bulk_msg. Given that the dongles are OK in a via system does this likely suggest a compatibility issue with the USB host controller on the AMD 760G board? I'm I likely to get anywhere trying to debug the code or will a USB analyser be required to work out what's going on? -- Dave Cunningham dave at upsilon org uk PGP KEY ID: 0xA78636DC -- 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.26 and up: 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 30 19:00:05 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15138:a4c762698bcb 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: ERRORS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS 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: WARNINGS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS 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: WARNINGS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: OK sparse: 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: [PATCH] drm, video: fix use-before-NULL-check
On Fri, 27 Aug 2010 14:07:19 -0700
Kees Cook wrote:
> Fix potential crashes due to use-before-NULL situations.
>
> Signed-off-by: Kees Cook
> ---
> drivers/gpu/drm/drm_fb_helper.c |3 ++-
> drivers/media/video/em28xx/em28xx-video.c |3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index de82e20..8dd7e6f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -94,10 +94,11 @@ static bool
> drm_fb_helper_connector_parse_command_line(struct drm_fb_helper_conn
> int i;
> enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
> struct drm_fb_helper_cmdline_mode *cmdline_mode;
> - struct drm_connector *connector = fb_helper_conn->connector;
> + struct drm_connector *connector;
>
> if (!fb_helper_conn)
> return false;
> + connector = fb_helper_conn->connector;
>
> cmdline_mode = &fb_helper_conn->cmdline_mode;
> if (!mode_option)
> diff --git a/drivers/media/video/em28xx/em28xx-video.c
> b/drivers/media/video/em28xx/em28xx-video.c
> index 7b9ec6e..95a4b60 100644
> --- a/drivers/media/video/em28xx/em28xx-video.c
> +++ b/drivers/media/video/em28xx/em28xx-video.c
> @@ -277,12 +277,13 @@ static void em28xx_copy_vbi(struct em28xx *dev,
> {
> void *startwrite, *startread;
> int offset;
> - int bytesperline = dev->vbi_width;
> + int bytesperline;
>
> if (dev == NULL) {
> em28xx_isocdbg("dev is null\n");
> return;
> }
> + bytesperline = dev->vbi_width;
>
> if (dma_q == NULL) {
> em28xx_isocdbg("dma_q is null\n");
Look fine to me.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio.
Matti/Hans, --- On Mon, 30/8/10, Matti J. Aaltonen wrote: > From: Matti J. Aaltonen > Subject: Re: [PATCH v4 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio. > To: "ext Hans Verkuil" > Cc: "ext Pavan Savoy" , "Mauro Carvalho Chehab" > , "linux-media@vger.kernel.org" > , "Valentin Eduardo (Nokia-MS/Helsinki)" > , petri.karh...@nokia.com > Date: Monday, 30 August, 2010, 5:14 PM > Hello. > > On Sat, 2010-08-28 at 11:29 +0200, ext Hans Verkuil wrote: > > On Thursday, August 26, 2010 09:39:45 Matti J. > Aaltonen wrote: > > > Hi. > > > > > > On Wed, 2010-08-25 at 23:20 +0200, ext Pavan > Savoy wrote: > > > > > > > > > I'm sorry for not answering to you > earlier. But I don't > > > > > have my own > > > > > public repository. But to create the > whole thing is > > > > > extremely simple: > > > > > just take the current mainline tree and > apply my patches on > > > > > top of it... > > > > > > > > Yep, that I can do, the reason I asked for > was, we've pushed a few patches of our own for WL1283 over > shared transport/UART (Not HCI-VS, but I2C like commands, > packed in a CH8 protocol format). > > > > The FM register set in both chip are a > match, with only transport being the difference (i2c vs. > UART). > > > > Also we have the Tx version of driver ready > too, it just needs a bit of cleanup and more conformance to > already existing V4L2 TX Class.. > > > > > > > > So I was wondering, although there is no > problem with WL1273 with I2C and WL1283 with UART being > there on the kernel (whenever that happens), but it would be > way more cooler if the transport was say abstracted out .. > > > > > > > > what do you say? just an idea... > > > > > > I think it's a good idea. And the WL1273 ship can > also used with a UART > > > connection, we just chose I2C when the driver > development started etc... > > > > Making a completely bus-independent driver is actually > possible. It would require > > that the driver uses the subdev API > (include/media/v4l2-subdev.h). Any register > > read or writes can be done by calling the v4l2_device > notify() callback and the > > bridge/host driver can then translate the callback to > either i2c or uart read > > or writes. > > > > Both v4l2_device and v4l2_subdev structs are > completely abstract structs (i.e. > > they do not rely on any particular bus), so it should > be possible to implement > > this. > > > > I had this scenario in the back of my mind when I > designed these APIs, but this > > would be the first driver where this would actually > apply to. > > > > That sounds interesting. I think that after the driver gets > accepted in > its current form we can start to work according to the > above scenario... Please have a look at the patches at http://www.mail-archive.com/linux-media@vger.kernel.org/msg21477.html which are for Wl128x/UART transport. also here's a tree where the other set of patches would come from, http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-omap-2.6.32 We are trying to make the drivers listed above conform to other V4L2 drivers and then post patches. Please comment ... Thanks in advance... > Cheers, > Matti > > > > > > > -- 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: IR code autorepeat issue?
Em 29-08-2010 22:26, Andy Walls escreveu:
> How about a keycode sensitive repeat delay?
> A short delay for vol+/-, ch+/-, etc.
> A medium delay for digits, fast forward, rewind, pause, play, stop, etc.
> A long delay for power, mute, etc.
There are two separate things here:
1) we need to fix a bug introduced for some remotes;
2) We may improve the repeat code at rc subsystem.
For (1), a simple trivial patch is enough/desired. Let's first fix it, and then
think on improvements.
About a keycode sensitive delay, it might be a good idea, but there are some
aspects to consider:
- a few remotes already do it. I have one or two remotes here that,
instead of using the remote protocol standard for key repeat for all keys,
they simply implement their own logic, allowing repeat events only on a few
keys, (like vol and channel keys). So, conflicts may rise with hardware-driven
logic;
- evdev already allows reading/replacing the repeat settings with
EVIOCGREP/EVIOCSREP;
- to do a per-key repeat events, it is needed to disable the
input repeat handling at the input subsystem and to implement our own logic
inside
rc-core, or to use some ugly workarounds. It is needed to take some care when
reinventing
the wheel. Several old IR codes at drivers/media did some sort of their own
repeat logic,
some of them using a very odd logic;
- it is needed to clearly define what's a short/medium/long delay, in
terms of
two parameters: delay for starting to produce repeat key events and number of
repeat events per second;
- it is needed to define what key will use the each delay timings, and
what should be done with the other keys that don't match any delay lists;
- a new API set of calls will be needed to set/get the delay timings
lists,
and to associate a keycode with a specified delay time.
IMHO, this would add too much complexity for not much gain.
>
> Regards,
> Andy
>
> Mauro Carvalho Chehab wrote:
>
>> Em 29-08-2010 03:40, Anton Blanchard escreveu:
>>>
>>> I'm seeing double IR events on 2.6.36-rc2 and a DViCO FusionHDTV DVB-T Dual
>>> Express. I enabled some debug and it looks like we are only getting one IR
>>> event from the device as expected:
>>>
>>> [ 1351.032084] ir_keydown: i2c IR (FusionHDTV): key down event, key 0x0067,
>>> scancode 0x0051
>>> [ 1351.281284] ir_keyup: keyup key 0x0067
>>>
>>> ie one key down event and one key up event 250ms later. I wonder if the
>>> input
>>> layer software autorepeat is the culprit. It seems to set autorepeat to
>>> start
>>> at 250ms:
>>>
>>> /*
>>> * If delay and period are pre-set by the driver, then autorepeating
>>> * is handled by the driver itself and we don't do it in input.c.
>>> */
>>> init_timer(&dev->timer);
>>> if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
>>> dev->timer.data = (long) dev;
>>> dev->timer.function = input_repeat_key;
>>> dev->rep[REP_DELAY] = 250;
>>> dev->rep[REP_PERIOD] = 33;
>>> }
>>>
>>> If I shorten the IR key up events to 100ms via the patch below the problem
>>> goes away. I guess the other option would be to initialise REP_DELAY and
>>> REP_PERIOD so the input layer autorepeat doesn't cut in at all. Thoughts?
>>
>>> Anton
>>> --
>>>
>>> diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
>>> index 7e82a9d..cf44d5a 100644
>>> --- a/drivers/media/IR/ir-keytable.c
>>> +++ b/drivers/media/IR/ir-keytable.c
>>> @@ -22,7 +22,7 @@
>>> #define IR_TAB_MAX_SIZE8192
>>>
>>> /* FIXME: IR_KEYPRESS_TIMEOUT should be protocol specific */
>>> -#define IR_KEYPRESS_TIMEOUT 250
>>> +#define IR_KEYPRESS_TIMEOUT 100
>>
>> Yes, 250ms is too high, if we want to use REP_DELAY = 250ms.
>>
>> There's one issue on touching on this constant: it is currently just one
>> global
>> timeout value that will be used by all protocols. This timeout should be
>> enough to
>> retrieve and proccess the repeat key event on all protocols, and on all
>> devices, or
>> we'll need to do a per-protocol (and eventually per device) timeout init.
>> From
>> http://www.sbprojects.com/knowledge/ir/ir.htm, we see that NEC prococol uses
>> 110 ms
>> for repeat code, and we need some aditional time to wake up the decoding
>> task. I'd
>> say that anything lower than 150-180ms would risk to not decode repeat
>> events with
>> NEC.
>>
>> I got exactly the same problem when adding RC CORE support at the dib0700
>> driver. At
>> that driver, there's an additional time of sending/receiving URB's from USB.
>> So, we
>> probably need a higher timeout. Even so, I tried to reduce the timeout to
>> 200ms or 150ms
>> (not sure), but it didn't work. So, I ended by just patching the dibcom
>> driver to do
>> dev->rep[REP_DELAY] = 500:
>>
>> commit 8dc09004978538d211ccc36b5046919489e30a55
>> Author: Mauro Carvalho Chehab
>> Date: Sat Jul 31 23:37:19 2010 -0300
Re: [PATCH v4 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio.
Hello. On Sat, 2010-08-28 at 11:29 +0200, ext Hans Verkuil wrote: > On Thursday, August 26, 2010 09:39:45 Matti J. Aaltonen wrote: > > Hi. > > > > On Wed, 2010-08-25 at 23:20 +0200, ext Pavan Savoy wrote: > > > > > > > I'm sorry for not answering to you earlier. But I don't > > > > have my own > > > > public repository. But to create the whole thing is > > > > extremely simple: > > > > just take the current mainline tree and apply my patches on > > > > top of it... > > > > > > Yep, that I can do, the reason I asked for was, we've pushed a few > > > patches of our own for WL1283 over shared transport/UART (Not HCI-VS, but > > > I2C like commands, packed in a CH8 protocol format). > > > The FM register set in both chip are a match, with only transport being > > > the difference (i2c vs. UART). > > > Also we have the Tx version of driver ready too, it just needs a bit of > > > cleanup and more conformance to already existing V4L2 TX Class.. > > > > > > So I was wondering, although there is no problem with WL1273 with I2C and > > > WL1283 with UART being there on the kernel (whenever that happens), but > > > it would be way more cooler if the transport was say abstracted out .. > > > > > > what do you say? just an idea... > > > > I think it's a good idea. And the WL1273 ship can also used with a UART > > connection, we just chose I2C when the driver development started etc... > > Making a completely bus-independent driver is actually possible. It would > require > that the driver uses the subdev API (include/media/v4l2-subdev.h). Any > register > read or writes can be done by calling the v4l2_device notify() callback and > the > bridge/host driver can then translate the callback to either i2c or uart read > or writes. > > Both v4l2_device and v4l2_subdev structs are completely abstract structs (i.e. > they do not rely on any particular bus), so it should be possible to implement > this. > > I had this scenario in the back of my mind when I designed these APIs, but > this > would be the first driver where this would actually apply to. > That sounds interesting. I think that after the driver gets accepted in its current form we can start to work according to the above scenario... Cheers, Matti -- 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 v9 2/4] 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..9fa3850
--- /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 v9 3/4] 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 | 1935
drivers/mfd/Kconfig|5 +
drivers/mfd/Makefile |2 +
5 files changed, 1958 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..aa1eeed
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,1935 @@
+/*
+ * 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
+#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_ctrl_handler ctrl_handler;
+ struct v4l2_device v4l2dev;
+ struct video_device videodev;
+ struct device *dev;
+ struct wl1273_core *core;
+ struct file *owner;
+ char *write_buf;
+ unsigned int rds_users;
+};
+
+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 -ERANGE;
+ }
+
+ if (freq > 108000) {
+ dev_err(&core->i2c_dev->dev,
+ "Frequency out of range: %d > %d\n",
+ freq, core->bands[core->band].top_frequency);
+ return -ERANGE;
+ }
+
+ /*
+* The driver works better with this sleep,
+* the documentation doesn't mention it.
+*/
+ usleep_range(5000, 1);
+
+ 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;
+
+
[PATCH v9 4/4] Documentation: v4l: Add hw_seek spacing and FM_RX class
Add a couple of words about the spacing field in the HW seek struct, about the V4L2_CAP_RAW_RDS_ONLY capability flag and about the new FM RX control class. Signed-off-by: Matti J. Aaltonen --- Documentation/DocBook/v4l/controls.xml | 71 Documentation/DocBook/v4l/dev-rds.xml |5 ++ .../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 ++- 3 files changed, 84 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 8408caa..e9512eb 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -2088,6 +2088,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 + + + + + + + + + + +
[PATCH v9 0/4] FM Radio driver.
Hi again,
and thanks for the comments.
I've left the audio codec out of this patch set.
Hans wrote:
> > In principle yes, but we haven't yet decided to implement those now, at
> > the moment the RDS interpretation is left completely to user space
> > applications.
>
> Matti, is it even possible to use the current FM TX RDS API for this chip?
> That API expects that the chip can generate the correct RDS packets based on
> high-level data. If the chip can only handle 'raw' RDS packets (requiring a
> userspace RDS encoder), then that API will never work.
>
> But if this chip can indeed handle raw RDS only, then we need to add some
> capability flags to signal that to userspace.
It is possible to use the current FM TX RDS API, the chip supports at least
most of it. I just haven't implemented the support into the driver yet,
for a multiple of reasons. I'm planning of adding that in the relatively
near future.
Anyhow, I've now added a way of telling that only raw RDS is supported.
Can we use one bit it the capability field for that?
> > + struct wl1273_device *radio = ctrl->priv;
>
> No need to use priv for this. You can use this instead:
>
> static inline struct wl1273_device *to_radio(struct v4l2_ctrl *ctrl)
> {
> return container_of(ctrl->handler, struct wl1273_device,
> ctrl_handler);
> }
Fixed. I just didn't come to think that it can be done like this.
> > + dev_dbg(radio->dev, "%s\n", __func__);
> > + return r;
> > +}
>
> Was the documentation on the control handler understandable enough? Any
> comments on how to improve the API or documentation? It's very new, so
> I'm interested in hearing about your experiences implementing this API.
I think the documentation is OK. But I didn't have time to dwell on it,
but on the other hand I remember thinking that the new API is better
than the previous one...
But what's the motivation behind having subdevices? You'll hardly
have several FM radios and want to do the same things on each
one at the same time?
> No need to use priv.
...
> First V4L2_CID_FM_BAND using new_std instead of new_std_menu (which it should
be).
...
> And a second?!
>
> > + if (ctrl) {
> > + ctrl->is_volatile = 1;
> > + ctrl->priv = radio;
> > + }
>
> And it is volatile? I thought that the ANTENNA_CAPACITOR was volatile.
> Something is messed up here.
Fixed. Yes, that was completely messed up...
Thanks...
Matti
Matti J. Aaltonen (4):
V4L2: Add seek spacing and FM RX class.
MFD: WL1273 FM Radio: MFD driver for the FM radio.
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 +
Documentation/DocBook/v4l/dev-rds.xml |5 +
.../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 | 1935
drivers/media/video/v4l2-ctrls.c | 12 +
drivers/mfd/Kconfig|5 +
drivers/mfd/Makefile |2 +
drivers/mfd/wl1273-core.c | 612 +++
include/linux/mfd/wl1273-core.h| 314
include/linux/videodev2.h | 16 +-
12 files changed, 2995 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
--
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 v9 1/4] V4L2: Add seek spacing and FM RX class.
Add spacing field to v4l2_hw_freq_seek, add V4L2_CAP_RAW_RDS_ONLY
to driver capabilities and also add FM RX class to control classes.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/video/v4l2-ctrls.c | 12
include/linux/videodev2.h| 16 +++-
2 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index ea8d32c..15749f1 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -216,6 +216,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:
@@ -256,6 +262,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;
}
@@ -386,6 +394,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;
@@ -448,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+ case V4L2_CID_FM_BAND:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
@@ -458,6 +469,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
+ case V4L2_CID_FM_RX_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 61490c6..7d6511e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -244,6 +244,7 @@ struct v4l2_capability {
#define V4L2_CAP_VIDEO_OUTPUT_OVERLAY 0x0200 /* Can do video output
overlay */
#define V4L2_CAP_HW_FREQ_SEEK 0x0400 /* Can do hardware
frequency seek */
#define V4L2_CAP_RDS_OUTPUT0x0800 /* Is an RDS encoder */
+#define V4L2_CAP_RAW_RDS_ONLY 0x1000 /* Does not interpret RDS
data */
#define V4L2_CAP_TUNER 0x0001 /* has a tuner */
#define V4L2_CAP_AUDIO 0x0002 /* has audio support */
@@ -930,6 +931,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)
@@ -1328,6 +1330,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
*/
@@ -1392,7 +1405,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
Current status of cx23885-alsa
Hello, I'm working at adding support of GotView PCIe tuner to cx23885 driver, I'm quite successful in it for now but I found that audio part of this driver (cx23885-alsa) is currently not in the main kernel tree and is maintained in a separate tree. Does anybody now, what its actual status is and why it is still not in the main tree? Maybe it has some serious problems? Perhaps I could help its development somehow. Thanks in advance, Alexey Chernov -- 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
Oops seen in dvb_usb_dib0700 when running 2.6.36-rc3
Just got up the courage to try the 2.6.36 series (indeed 2.6.36-rc3) and saw an oops from the dvb_usb_dib0700 module on startup. This is a Hauppauge Nova-T 500 card in a Compaq Alpha. Have never seen this when running 2.6.35 series or prior kernels. [ 29.259750] dib0700: loaded with support for 15 different device-types [ 29.261703] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. [ 29.261703] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 29.263656] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) [ 29.290024] PCI: Setting latency timer of device :01:00.1 to 64 [ 29.374008] DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)... [ 29.416000] MT2060: successfully identified (IF1 = 1217) [ 29.898422] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 29.899398] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) [ 29.910140] DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... [ 29.916000] MT2060: successfully identified (IF1 = 1226) [ 30.107406] ieee1394: Host added: ID:BUS[0-00:1023] GUID[303c0009c6d0] [ 30.423812] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. [ 30.423812] Unable to handle kernel paging request at virtual address 0138 [ 30.423812] modprobe(617): Oops 1 [ 30.423812] pc = [] ra = [] ps = Not tainted [ 30.423812] pc is at dib0700_probe+0xf0/0x150 [dvb_usb_dib0700] [ 30.423812] ra is at dib0700_probe+0xb4/0x150 [dvb_usb_dib0700] [ 30.423812] v0 = 0010 t0 = t1 = 01f4 [ 30.423812] t2 = t3 = t4 = a9ba [ 30.423812] t5 = t6 = t7 = fc003e26 [ 30.424789] s0 = fc003e1ee340 s1 = fffc0098a27c s2 = fc003f592000 [ 30.424789] s3 = fffc0097c430 s4 = fc003e263d38 s5 = fffc0097d368 [ 30.424789] s6 = 000120022080 [ 30.424789] a0 = a1 = fc00010c87a8 a2 = fc003e047a60 [ 30.424789] a3 = fffc0031902c a4 = fc003e10c068 a5 = [ 30.424789] t8 = t9 = t10= 0010 [ 30.424789] t11= pv = fc3a3e90 at = 0003 [ 30.424789] gp = fffc00982d42 sp = fc003e263ce8 [ 30.424789] Disabling lock debugging due to kernel taint [ 30.424789] Trace: [ 30.424789] [] driver_probe_device+0xa4/0x220 [ 30.425765] [] __driver_attach+0xfc/0x100 [ 30.425765] [] bus_for_each_dev+0x78/0xd0 [ 30.425765] [] __driver_attach+0x0/0x100 [ 30.425765] [] driver_attach+0x2c/0x40 [ 30.425765] [] bus_add_driver+0xe8/0x350 [ 30.425765] [] kobj_bcast_filter+0x0/0xa0 [ 30.426742] [] driver_register+0x78/0x1b0 [ 30.426742] [] kobj_bcast_filter+0x0/0xa0 [ 30.426742] [] do_one_initcall+0x38/0x200 [ 30.426742] [] SyS_init_module+0xfc/0x2b0 [ 30.426742] [] entSys+0xa4/0xc0 [ 30.426742] [ 30.427718] Code: a43e0050 205f0001 384101c0 a43e0050 205f01f4 a4211c58 a61e0050 Cheers Michael. -- 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 7/7] ENE: add support for carrier reports
Signed-off-by: Maxim Levitsky
---
drivers/media/IR/ene_ir.c | 47 +++-
1 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index c7bbbca..dfb822b 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -224,6 +224,7 @@ void ene_rx_sense_carrier(struct ene_device *dev)
{
int period = ene_read_reg(dev, ENE_CIRCAR_PRD);
int hperiod = ene_read_reg(dev, ENE_CIRCAR_HPRD);
+ struct ir_raw_event ev = ir_new_event;
int carrier, duty_cycle;
@@ -238,19 +239,23 @@ void ene_rx_sense_carrier(struct ene_device *dev)
dbg("RX: hardware carrier period = %02x", period);
dbg("RX: hardware carrier pulse period = %02x", hperiod);
-
carrier = 200 / period;
duty_cycle = (hperiod * 100) / period;
dbg("RX: sensed carrier = %d Hz, duty cycle %d%%",
- carrier, duty_cycle);
-
- /* TODO: Send carrier & duty cycle to IR layer */
+ carrier, duty_cycle);
+ if (dev->carrier_detect_enabled) {
+ ev.carrier_report = true;
+ ev.carrier = carrier;
+ ev.duty_cycle = duty_cycle;
+ ir_raw_event_store(dev->idev, &ev);
+ }
}
/* determine which input to use*/
static void ene_rx_set_inputs(struct ene_device *dev)
{
- int learning_mode = dev->learning_enabled;
+ int learning_mode = dev->learning_enabled ||
+ dev->carrier_detect_enabled;
dbg("RX: setup receiver, learning mode = %d", learning_mode);
@@ -281,9 +286,17 @@ static void ene_rx_set_inputs(struct ene_device *dev)
ene_enable_cir_engine(dev, true);
ene_select_rx_input(dev, !dev->hw_use_gpio_0a);
- /* Enable carrier detection & demodulation */
+ /* Enable demodulation */
ene_set_reg_mask(dev, ENE_CIRCFG, ENE_CIRCFG_CARR_DEMOD);
- ene_set_reg_mask(dev, ENE_CIRCFG2, ENE_CIRCFG2_CARR_DETECT);
+
+ /* Enable carrier detect if asked to */
+ if (dev->carrier_detect_enabled || debug)
+ ene_set_reg_mask(dev, ENE_CIRCFG2,
+ ENE_CIRCFG2_CARR_DETECT);
+ else
+ ene_clear_reg_mask(dev, ENE_CIRCFG2,
+ ENE_CIRCFG2_CARR_DETECT);
+
/* disable learning mode */
@@ -726,7 +739,7 @@ static irqreturn_t ene_isr(int irq, void *data)
dbg_verbose("RX interrupt");
- if (dev->carrier_detect_enabled || debug)
+ if (dev->hw_learning_and_tx_capable)
ene_rx_sense_carrier(dev);
/* On hardware that don't support extra buffer we need to trust
@@ -796,7 +809,6 @@ static void ene_setup_settings(struct ene_device *dev)
let user set it with LIRC_SET_REC_CARRIER */
dev->learning_enabled =
(learning_mode && dev->hw_learning_and_tx_capable);
-
}
/* outside interface: called on first open*/
@@ -902,6 +914,21 @@ static int ene_set_learning_mode(void *data, int enable)
return 0;
}
+static int ene_set_carrier_report(void *data, int enable)
+{
+ struct ene_device *dev = (struct ene_device *)data;
+ unsigned long flags;
+
+ if (enable == dev->carrier_detect_enabled)
+ return 0;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ dev->carrier_detect_enabled = enable;
+ ene_rx_set_inputs(dev);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+ return 0;
+}
+
/* outside interface: enable or disable idle mode */
static void ene_rx_set_idle(void *data, int idle)
{
@@ -1043,7 +1070,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
ir_props->s_tx_carrier = ene_set_tx_carrier;
ir_props->s_tx_duty_cycle = ene_set_tx_duty_cycle;
ir_props->tx_resolution = sample_period * 1000;
- /* ir_props->s_carrier_report = ene_set_carrier_report; */
+ ir_props->s_carrier_report = ene_set_carrier_report;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] ene_ir: updates
* Add support for newer firmware versions with different
buffer format. Makes hardware work for many users
* Register name updates + refactoring
* Lots of fixes as a result of full testing
Every feature of the driver is now well tested.
Signed-off-by: Maxim Levitsky
---
drivers/media/IR/ene_ir.c | 795 +++--
drivers/media/IR/ene_ir.h | 223 -
2 files changed, 618 insertions(+), 400 deletions(-)
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index 5447750..8e3e0c8 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -1,5 +1,5 @@
/*
- * driver for ENE KB3926 B/C/D CIR (pnp id: ENE0XXX)
+ * driver for ENE KB3926 B/C/D/E/F CIR (pnp id: ENE0XXX)
*
* Copyright (C) 2010 Maxim Levitsky
*
@@ -17,6 +17,17 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
* USA
+ *
+ * Special thanks to:
+ * Sami R. for lot of help in debbuging and therefore
+ *bringing to life suppport for transmition & learning mode.
+ *
+ * Charlie Andrews for lots of help in
+ * bringing up the support of new firmware buffer that is popular
+ * on latest notebooks
+ *
+ * ENE for partial device documentation
+ *
*/
#include
@@ -33,49 +44,49 @@
static int sample_period = -1;
-static int enable_idle = 1;
-static int input = 1;
+static bool enable_idle = true;
+static bool learning_mode;
static int debug;
-static int txsim;
+static bool txsim;
-static int ene_irq_status(struct ene_device *dev);
+static void ene_set_reg_addr(struct ene_device *dev, u16 reg)
+{
+ outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
+ outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
+}
/* read a hardware register */
-static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
+static u8 ene_read_reg(struct ene_device *dev, u16 reg)
{
u8 retval;
- outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
- outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
+ ene_set_reg_addr(dev, reg);
retval = inb(dev->hw_io + ENE_IO);
-
- ene_dbg_verbose("reg %04x == %02x", reg, retval);
+ dbg_regs("reg %04x == %02x", reg, retval);
return retval;
}
/* write a hardware register */
-static void ene_hw_write_reg(struct ene_device *dev, u16 reg, u8 value)
+static void ene_write_reg(struct ene_device *dev, u16 reg, u8 value)
{
- outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
- outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
+ dbg_regs("reg %04x <- %02x", reg, value);
+ ene_set_reg_addr(dev, reg);
outb(value, dev->hw_io + ENE_IO);
-
- ene_dbg_verbose("reg %04x <- %02x", reg, value);
}
-/* change specific bits in hardware register */
-static void ene_hw_write_reg_mask(struct ene_device *dev,
- u16 reg, u8 value, u8 mask)
+/* Set bits in hardware register */
+static void ene_set_reg_mask(struct ene_device *dev, u16 reg, u8 mask)
{
- u8 regvalue;
-
- outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
- outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
-
- regvalue = inb(dev->hw_io + ENE_IO) & ~mask;
- regvalue |= (value & mask);
- outb(regvalue, dev->hw_io + ENE_IO);
+ dbg_regs("reg %04x |= %02x", reg, mask);
+ ene_set_reg_addr(dev, reg);
+ outb(inb(dev->hw_io + ENE_IO) | mask, dev->hw_io + ENE_IO);
+}
- ene_dbg_verbose("reg %04x <- %02x (mask=%02x)", reg, value, mask);
+/* Clear bits in hardware register */
+static void ene_clear_reg_mask(struct ene_device *dev, u16 reg, u8 mask)
+{
+ dbg_regs("reg %04x &= ~%02x ", reg, mask);
+ ene_set_reg_addr(dev, reg);
+ outb(inb(dev->hw_io + ENE_IO) & ~mask, dev->hw_io + ENE_IO);
}
/* detect hardware features */
@@ -83,22 +94,19 @@ static int ene_hw_detect(struct ene_device *dev)
{
u8 chip_major, chip_minor;
u8 hw_revision, old_ver;
- u8 tmp;
- u8 fw_capabilities;
+ u8 fw_reg2, fw_reg1;
int pll_freq;
- tmp = ene_hw_read_reg(dev, ENE_HW_UNK);
- ene_hw_write_reg(dev, ENE_HW_UNK, tmp & ~ENE_HW_UNK_CLR);
-
- chip_major = ene_hw_read_reg(dev, ENE_HW_VER_MAJOR);
- chip_minor = ene_hw_read_reg(dev, ENE_HW_VER_MINOR);
+ ene_clear_reg_mask(dev, ENE_HW_UNK, ENE_HW_UNK_CLR);
+ chip_major = ene_read_reg(dev, ENE_HW_VER_MAJOR);
+ chip_minor = ene_read_reg(dev, ENE_HW_VER_MINOR);
+ ene_set_reg_mask(dev, ENE_HW_UNK, ENE_HW_UNK_CLR);
- ene_hw_write_reg(dev, ENE_HW_UNK, tmp);
- hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
- old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
+ hw_revision = ene_read_reg(dev, ENE_HW_VERSION);
+ old_ver = ene_read_reg(dev, ENE_HW_VER_OLD);
- pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
- (ene_hw_read_reg(dev, ENE_PLLFRL) >> 4);
+ pll_freq = (ene_read_reg(dev, ENE_PLLFRH) << 4) +
+
[PATCH 6/7] IR: extend ir_raw_event and do refactoring
Add new event types for timeout & carrier report
Move timeout handling from ir_raw_event_store_with_filter to
ir-lirc-codec, where it is really needed.
Now lirc bridge ensures proper gap handling.
Extend lirc bridge for carrier & timeout reports
Note: all new ir_raw_event variables now should be initialized
like that:
struct ir_raw_event ev = ir_new_event;
Signed-off-by: Maxim Levitsky
---
drivers/media/IR/ene_ir.c |2 +-
drivers/media/IR/ene_ir.h |2 +-
drivers/media/IR/ir-core-priv.h| 11 +-
drivers/media/IR/ir-jvc-decoder.c |5 ++-
drivers/media/IR/ir-lirc-codec.c | 66
drivers/media/IR/ir-nec-decoder.c |5 ++-
drivers/media/IR/ir-raw-event.c| 41 +-
drivers/media/IR/ir-rc5-decoder.c |5 ++-
drivers/media/IR/ir-rc6-decoder.c |5 ++-
drivers/media/IR/ir-sony-decoder.c |5 ++-
drivers/media/IR/mceusb.c |2 +-
drivers/media/IR/streamzap.c |6 ++--
include/media/ir-core.h| 26 --
13 files changed, 121 insertions(+), 60 deletions(-)
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index 8e3e0c8..c7bbbca 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -699,7 +699,7 @@ static irqreturn_t ene_isr(int irq, void *data)
unsigned long flags;
irqreturn_t retval = IRQ_NONE;
struct ene_device *dev = (struct ene_device *)data;
- struct ir_raw_event ev;
+ struct ir_raw_event ev = ir_new_event;
spin_lock_irqsave(&dev->hw_lock, flags);
diff --git a/drivers/media/IR/ene_ir.h b/drivers/media/IR/ene_ir.h
index 69a0ae0..27b2eb0 100644
--- a/drivers/media/IR/ene_ir.h
+++ b/drivers/media/IR/ene_ir.h
@@ -188,7 +188,7 @@
* And there is nothing to change this setting
*/
-#define ENE_MAXGAP (0xFFF * 0x61)
+#define ENE_MAXGAP 2
#define ENE_MINGAP (127 * sample_period)
/**/
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 5d7e08f..a287373 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -82,6 +82,10 @@ struct ir_raw_event_ctrl {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
int carrier_low;
+ ktime_t timeout_start;
+ bool timeout;
+ bool send_timeout_reports;
+
} lirc;
};
@@ -109,9 +113,14 @@ static inline void decrease_duration(struct ir_raw_event
*ev, unsigned duration)
ev->duration -= duration;
}
+/* Returns true if event is normal pulse/space event */
+static inline bool is_timing_event(struct ir_raw_event ev)
+{
+ return !ev.carrier_report && !ev.reset;
+}
+
#define TO_US(duration)DIV_ROUND_CLOSEST((duration),
1000)
#define TO_STR(is_pulse) ((is_pulse) ? "pulse" : "space")
-#define IS_RESET(ev) (ev.duration == 0)
/*
* Routines from ir-sysfs.c - Meant to be called only internally inside
* ir-core
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 77a89c4..63dca6e 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -50,8 +50,9 @@ static int ir_jvc_decode(struct input_dev *input_dev, struct
ir_raw_event ev)
if (!(ir_dev->raw->enabled_protocols & IR_TYPE_JVC))
return 0;
- if (IS_RESET(ev)) {
- data->state = STATE_INACTIVE;
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data->state = STATE_INACTIVE;
return 0;
}
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index e63f757..e6ca7a3 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -32,7 +32,9 @@
static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
{
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+ struct lirc_codec *lirc = &ir_dev->raw->lirc;
int sample;
+ int duration_msec;
if (!(ir_dev->raw->enabled_protocols & IR_TYPE_LIRC))
return 0;
@@ -40,21 +42,56 @@ static int ir_lirc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!ir_dev->raw->lirc.drv || !ir_dev->raw->lirc.drv->rbuf)
return -EINVAL;
- if (IS_RESET(ev))
+ duration_msec = DIV_ROUND_CLOSEST(ev.duration, 1000);
+
+ if (ev.reset)
return 0;
- IR_dprintk(2, "LIRC data transfer started (%uus %s)\n",
- TO_US(ev.duration), TO_STR(ev.pulse));
+ if (ev.carrier_report) {
+ /* TODO: send RX duty cycle */
+ sample = LIRC_FREQUENCY(ev.carrier);
+
+ } else if (ev.timeout) {
+
[PATCH 4/7] IR: fix keys beeing stuck down forever.
The logic in ir_timer_keyup was inverted. In case that values aren't equal, the meaning of the time_is_after_eq_jiffies(ir->keyup_jiffies) is that ir->keyup_jiffies is after the the jiffies or equally that that jiffies are before the the ir->keyup_jiffies which is exactly the situation we want to avoid (that the timeout is in the future) Confusing Eh? Signed-off-by: Maxim Levitsky --- drivers/media/IR/ir-keytable.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c index 3f0dd80..b5addb8 100644 --- a/drivers/media/IR/ir-keytable.c +++ b/drivers/media/IR/ir-keytable.c @@ -319,7 +319,7 @@ static void ir_timer_keyup(unsigned long cookie) * a keyup event might follow immediately after the keydown. */ spin_lock_irqsave(&ir->keylock, flags); - if (time_is_after_eq_jiffies(ir->keyup_jiffies)) + if (time_is_before_eq_jiffies(ir->keyup_jiffies)) ir_keyup(ir); spin_unlock_irqrestore(&ir->keylock, flags); } -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] IR: plug races in handling threads.
Unfortunelly (my fault) the kernel thread that now handles IR processing
has classical races in regard to wakeup and stop.
This patch hopefully closes them all.
Tested with module reload running in a loop, while receiver is blasted
with IR data for 10 minutes.
Signed-off-by: Maxim Levitsky
---
drivers/media/IR/ir-core-priv.h |2 ++
drivers/media/IR/ir-raw-event.c | 34 +-
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index a85a8c7..761e7f4 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -17,6 +17,7 @@
#define _IR_RAW_EVENT
#include
+#include
#include
struct ir_raw_handler {
@@ -33,6 +34,7 @@ struct ir_raw_handler {
struct ir_raw_event_ctrl {
struct list_headlist; /* to keep track of raw
clients */
struct task_struct *thread;
+ spinlock_t lock;
struct kfifokfifo; /* fifo for the
pulse/space durations */
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 43094e7..56797be 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -39,22 +39,34 @@ static int ir_raw_event_thread(void *data)
struct ir_raw_event ev;
struct ir_raw_handler *handler;
struct ir_raw_event_ctrl *raw = (struct ir_raw_event_ctrl *)data;
+ int retval;
while (!kthread_should_stop()) {
- try_to_freeze();
- mutex_lock(&ir_raw_handler_lock);
+ spin_lock_irq(&raw->lock);
+ retval = kfifo_out(&raw->kfifo, &ev, sizeof(ev));
+
+ if (!retval) {
+ set_current_state(TASK_INTERRUPTIBLE);
- while (kfifo_out(&raw->kfifo, &ev, sizeof(ev)) == sizeof(ev)) {
- list_for_each_entry(handler, &ir_raw_handler_list, list)
- handler->decode(raw->input_dev, ev);
- raw->prev_ev = ev;
+ if (kthread_should_stop())
+ set_current_state(TASK_RUNNING);
+
+ spin_unlock_irq(&raw->lock);
+ schedule();
+ continue;
}
- mutex_unlock(&ir_raw_handler_lock);
+ spin_unlock_irq(&raw->lock);
- set_current_state(TASK_INTERRUPTIBLE);
- schedule();
+
+ BUG_ON(retval != sizeof(ev));
+
+ mutex_lock(&ir_raw_handler_lock);
+ list_for_each_entry(handler, &ir_raw_handler_list, list)
+ handler->decode(raw->input_dev, ev);
+ raw->prev_ev = ev;
+ mutex_unlock(&ir_raw_handler_lock);
}
return 0;
@@ -232,11 +244,14 @@ EXPORT_SYMBOL_GPL(ir_raw_event_set_idle);
void ir_raw_event_handle(struct input_dev *input_dev)
{
struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ unsigned long flags;
if (!ir->raw)
return;
+ spin_lock_irqsave(&ir->raw->lock, flags);
wake_up_process(ir->raw->thread);
+ spin_unlock_irqrestore(&ir->raw->lock, flags);
}
EXPORT_SYMBOL_GPL(ir_raw_event_handle);
@@ -275,6 +290,7 @@ int ir_raw_event_register(struct input_dev *input_dev)
return rc;
}
+ spin_lock_init(&ir->raw->lock);
ir->raw->thread = kthread_run(ir_raw_event_thread, ir->raw,
"rc%u", (unsigned int)ir->devno);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] IR: make sure we register input device when it safe to do so.
As soon as input device is registered, it might be accessed (and it is)
This can trigger hardware interrupts for example that in turn
can access not yet initialized ir->raw.
Can be reproduced by holding down a remote button and reloading the module.
And always crashes the systems where hardware decides to send and interrupt
right at the moment it is enabled.
Signed-off-by: Maxim Levitsky
---
drivers/media/IR/ir-core-priv.h |1 +
drivers/media/IR/ir-keytable.c |2 ++
drivers/media/IR/ir-sysfs.c | 27 +--
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 761e7f4..5d7e08f 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -116,6 +116,7 @@ static inline void decrease_duration(struct ir_raw_event
*ev, unsigned duration)
* Routines from ir-sysfs.c - Meant to be called only internally inside
* ir-core
*/
+int ir_register_input(struct input_dev *input_dev);
int ir_register_class(struct input_dev *input_dev);
void ir_unregister_class(struct input_dev *input_dev);
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 7e82a9d..3f0dd80 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -505,6 +505,8 @@ int __ir_input_register(struct input_dev *input_dev,
goto out_event;
}
+ rc = ir_register_input(input_dev);
+
IR_dprintk(1, "Registered input device on %s for %s remote%s.\n",
driver_name, rc_tab->name,
(ir_dev->props && ir_dev->props->driver_type ==
RC_DRIVER_IR_RAW) ?
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 96dafc4..c0075f1 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -251,8 +251,6 @@ static struct device_type rc_dev_type = {
*/
int ir_register_class(struct input_dev *input_dev)
{
- int rc;
- const char *path;
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
int devno = find_first_zero_bit(&ir_core_dev_number,
IRRCV_NUM_DEVICES);
@@ -261,17 +259,28 @@ int ir_register_class(struct input_dev *input_dev)
return devno;
ir_dev->dev.type = &rc_dev_type;
+ ir_dev->devno = devno;
ir_dev->dev.class = &ir_input_class;
ir_dev->dev.parent = input_dev->dev.parent;
+ input_dev->dev.parent = &ir_dev->dev;
dev_set_name(&ir_dev->dev, "rc%d", devno);
dev_set_drvdata(&ir_dev->dev, ir_dev);
- rc = device_register(&ir_dev->dev);
- if (rc)
- return rc;
+ return device_register(&ir_dev->dev);
+};
+
+/**
+ * ir_register_input - registers ir input device with input subsystem
+ * @input_dev: the struct input_dev descriptor of the device
+ */
+
+int ir_register_input(struct input_dev *input_dev)
+{
+ struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+ int rc;
+ const char *path;
- input_dev->dev.parent = &ir_dev->dev;
rc = input_register_device(input_dev);
if (rc < 0) {
device_del(&ir_dev->dev);
@@ -287,11 +296,9 @@ int ir_register_class(struct input_dev *input_dev)
path ? path : "N/A");
kfree(path);
- ir_dev->devno = devno;
- set_bit(devno, &ir_core_dev_number);
-
+ set_bit(ir_dev->devno, &ir_core_dev_number);
return 0;
-};
+}
/**
* ir_unregister_class() - removes the sysfs for sysfs for
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] IR: fix duty cycle capability
Due to typo lirc bridge enabled wrong capability. Signed-off-by: Maxim Levitsky --- drivers/media/IR/ir-lirc-codec.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c index 77b5946..e63f757 100644 --- a/drivers/media/IR/ir-lirc-codec.c +++ b/drivers/media/IR/ir-lirc-codec.c @@ -267,7 +267,7 @@ static int ir_lirc_register(struct input_dev *input_dev) features |= LIRC_CAN_SET_SEND_CARRIER; if (ir_dev->props->s_tx_duty_cycle) - features |= LIRC_CAN_SET_REC_DUTY_CYCLE; + features |= LIRC_CAN_SET_SEND_DUTY_CYCLE; } if (ir_dev->props->s_rx_carrier_range) -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Many fixes for in-kernel decoding + ENE driver
Hi, I did a lot of debug work on this, including a debug session with two users. I was able to test and fix support for all features ene driver supports. The patch #1 fixes a bug I introduced The patch #2 fixes a nasty bug that crashes the system The patch #3 fixes another small bug in my code The patch #4 fixes a nasty but that appears as a stuck down forever key The patch #5 adds a lot of bugfixes, refactoring and support for latest firmware that without it driver dosn't work. Driver is fully tested, and works. in the patch #6 I finally decided to extend ir_raw_event, and encode additional flags to it. This way I can signal the decoders about last space and yet not show it up on lirc interface. Timeout hangling is now moved in lirc bridge where it belongs. While at it, I also added support for carrier report events, and patch #6 adds that support to ene driver (tested too). Best regards, Maxim Levitsky -- 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/RFCv4 0/6] The Contiguous Memory Allocator framework
Andrew Morton wrote: > It would help (a lot) if we could get more attention and buyin and > fedback from the potential clients of this code. rmk's feedback is > valuable. Have we heard from the linux-media people? What other > subsystems might use it? ieee1394 perhaps? All FireWire controllers are OHCI and use scatter-gather lists. Most USB controllers require continuous memory for USB packets; the USB framework has its own DMA buffer cache. Some sound cards have no IOMMU; the ALSA framework preallocates buffers for those. Regards, Clemens -- 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: Snapshot with the OMAP
Hi Lane, On Sunday 29 August 2010 07:24:31 Lane Brooks wrote: > Laurent, > > Suppose I am streaming 2048x1536 YUV images from a sensor into the OMAP. > I am piping it through the resizer to drop it to 640x480 for display. So > I am reading from /dev/video6 (resizer) and have the media bus links > setup appropriately. Now the user presses the shutter button. What is > the recommended way to read a single full resolution image? > > It seems there are several options: > > 1. Reconfigure the media bus and read a single single full resolution > image out of the CCDC output on /dev/video2 and then > reconfigure it back to video mode. > > 2. Reconfigure the resizer to stop downsampling but instead output the > full resolution image for a single frame. > > Do I need to stop the stream while doing either option? Both options require you to stop the stream. Reconfiguring the pipeline or changing formats can't be done during streaming (for completeness' sake, note that changing the crop rectangle at the resizer input can be done during streaming, but that won't solve your problem). > These seem like clunky and slow options, though. > > Is there a way to setup the media bus links so that I can actually have > handles to /dev/video2 and /dev/video6 open simultaneously? Then I can > normally read from /dev/video6 and then read single frames from > /dev/video2 whenever the user presses the shutter button? Not at the moment, but I'd be very happy to receive a patch that implements that feature :-) > I have noticed there is a some ISP_PIPELINE_STREAM_SINGLESHOT streaming > states in the isp code, but I don't what it is for or how to use it. Is > it related to my questions at all? No. They're used for memory-to-memory operation that requires the ISP to operate in single-shot mode. > It gets even more complex if I want the streaming the video out of the > sensor at a lower resolution (for higher video rates) and want to change > the resolution of the sensor for the snapshot. You will need to stop the pipeline, change the formats and restart it. There's no alternative at the moment. -- 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
