[PATCH] nuvoton-cir: add proper rx fifo overrun handling
Per discussion with Andy Walls on irc, rx fifo overruns are not all that
uncommon on a busy system, and the initial posting of the nuvoton-cir
driver doesn't handle them well enough. With this addition, we'll drain
the hw fifo, attempt to process any ir pulse trains completed with that
flush, then we'll issue a hw rx fifo clear and reset the raw ir sample
kfifo and start over collecting raw ir data.
Also slightly refactors the cir interrupt enabling so that we always get
consistent flags set and only have to modify them in one place, should
they need to be altered.
Signed-off-by: Jarod Wilson
---
drivers/media/IR/nuvoton-cir.c | 37 +
1 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/media/IR/nuvoton-cir.c b/drivers/media/IR/nuvoton-cir.c
index 1ce9359..fdb280e 100644
--- a/drivers/media/IR/nuvoton-cir.c
+++ b/drivers/media/IR/nuvoton-cir.c
@@ -339,6 +339,15 @@ static void nvt_clear_tx_fifo(struct nvt_dev *nvt)
nvt_cir_reg_write(nvt, val | CIR_FIFOCON_TXFIFOCLR, CIR_FIFOCON);
}
+/* enable RX Trigger Level Reach and Packet End interrupts */
+static void nvt_set_cir_iren(struct nvt_dev *nvt)
+{
+ u8 iren;
+
+ iren = CIR_IREN_RTR | CIR_IREN_PE;
+ nvt_cir_reg_write(nvt, iren, CIR_IREN);
+}
+
static void nvt_cir_regs_init(struct nvt_dev *nvt)
{
/* set sample limit count (PE interrupt raised when reached) */
@@ -363,8 +372,8 @@ static void nvt_cir_regs_init(struct nvt_dev *nvt)
/* clear any and all stray interrupts */
nvt_cir_reg_write(nvt, 0xff, CIR_IRSTS);
- /* and finally, enable RX Trigger Level Read and Packet End interrupts
*/
- nvt_cir_reg_write(nvt, CIR_IREN_RTR | CIR_IREN_PE, CIR_IREN);
+ /* and finally, enable interrupts */
+ nvt_set_cir_iren(nvt);
}
static void nvt_cir_wake_regs_init(struct nvt_dev *nvt)
@@ -639,12 +648,22 @@ static void nvt_process_rx_ir_data(struct nvt_dev *nvt)
nvt_dbg_verbose("%s done", __func__);
}
+static void nvt_handle_rx_fifo_overrun(struct nvt_dev *nvt)
+{
+ nvt_pr(KERN_WARNING, "RX FIFO overrun detected, flushing data!");
+
+ nvt->pkts = 0;
+ nvt_clear_cir_fifo(nvt);
+ ir_raw_event_reset(nvt->rdev);
+}
+
/* copy data from hardware rx fifo into driver buffer */
static void nvt_get_rx_ir_data(struct nvt_dev *nvt)
{
unsigned long flags;
u8 fifocount, val;
unsigned int b_idx;
+ bool overrun = false;
int i;
/* Get count of how many bytes to read from RX FIFO */
@@ -652,11 +671,10 @@ static void nvt_get_rx_ir_data(struct nvt_dev *nvt)
/* if we get 0xff, probably means the logical dev is disabled */
if (fifocount == 0xff)
return;
- /* this would suggest a fifo overrun, not good... */
+ /* watch out for a fifo overrun condition */
else if (fifocount > RX_BUF_LEN) {
- nvt_pr(KERN_WARNING, "fifocount %d over fifo len (%d)!",
- fifocount, RX_BUF_LEN);
- return;
+ overrun = true;
+ fifocount = RX_BUF_LEN;
}
nvt_dbg("attempting to fetch %u bytes from hw rx fifo", fifocount);
@@ -682,6 +700,9 @@ static void nvt_get_rx_ir_data(struct nvt_dev *nvt)
nvt_process_rx_ir_data(nvt);
+ if (overrun)
+ nvt_handle_rx_fifo_overrun(nvt);
+
spin_unlock_irqrestore(&nvt->nvt_lock, flags);
}
@@ -886,7 +907,7 @@ static void nvt_enable_cir(struct nvt_dev *nvt)
nvt_cir_reg_write(nvt, 0xff, CIR_IRSTS);
/* enable interrupts */
- nvt_cir_reg_write(nvt, CIR_IREN_RTR | CIR_IREN_PE, CIR_IREN);
+ nvt_set_cir_iren(nvt);
}
static void nvt_disable_cir(struct nvt_dev *nvt)
@@ -1155,7 +1176,7 @@ static int nvt_resume(struct pnp_dev *pdev)
nvt_dbg("%s called", __func__);
/* open interrupt */
- nvt_cir_reg_write(nvt, CIR_IREN_RTR | CIR_IREN_PE, CIR_IREN);
+ nvt_set_cir_iren(nvt);
/* Enable CIR logical device */
nvt_efm_enable(nvt);
--
1.7.1
--
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
[PATCH] IR: add driver for Nuvoton w836x7hg integrated CIR
This is a new ir-core pnp driver for the Nuvoton w836x7hg integrated CIR function. The chip is found on at least the ASRock ION 330HT boxes and apparently, on a number of Intel DP55-series motherboards: http://www.asrock.com/nettop/overview.asp?Model=ION%20330HT http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17685&lang=eng This driver was made possible by a hardware donation from Nuvoton, along with sample code (in the form of an lirc driver) and datasheet, so huge thanks to them for supporting this effort. Note that this driver constitutes a massive rewrite, porting from the lirc interfaces to the ir-core interfaces, and restructuring the driver to look more like Maxim Levitsky's ene_ir driver (as well as generally making it look more like kernel code). There's some work left to be done on this driver, to fully support the range of functionality possible, but receive and IR power-on/wake are both functional (may require setting wake key under another OS atm). The hardware I've got (one of the ASRock boxes) only supports RX, so TX is completely untested as of yet. Certain RX parameters, like sample resolution and RX IRQ sample length trigger level could possibly stand to be made tweakable via modparams or sysfs nodes, but the current values work well enough for me w/an MCE RC6A remote. The original lirc driver carried support for the Windows MCE IR keyboard/mouse device, which I plan to add back generically, in a way that should be usable by any raw IR receiver (or at least by this driver and the mceusb driver). Suspend and resume have also been tested, the power button on my remote can be used to wake the machine, and CIR functionality resumes just fine. Module unload/reload has also been tested, though not extensively or repetitively. Also tested to work with the lirc bridge plugin for userspace decoding. Signed-off-by: Jarod Wilson --- drivers/media/IR/Kconfig | 13 + drivers/media/IR/Makefile |1 + drivers/media/IR/nuvoton-cir.c | 1216 drivers/media/IR/nuvoton-cir.h | 408 ++ 4 files changed, 1638 insertions(+), 0 deletions(-) create mode 100644 drivers/media/IR/nuvoton-cir.c create mode 100644 drivers/media/IR/nuvoton-cir.h diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index 152000d..364514a 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -113,6 +113,19 @@ config IR_IMON To compile this driver as a module, choose M here: the module will be called imon. +config IR_NUVOTON + tristate "Nuvoton w836x7hg Consumer Infrared Transceiver" + depends on PNP + depends on IR_CORE + ---help--- + Say Y here to enable support for integrated infrared receiver + /transciever made by Nuvoton (formerly Winbond). This chip is + found in the ASRock ION 330HT, as well as assorted Intel + DP55-series motherboards (and of course, possibly others). + + To compile this driver as a module, choose M here: the + module will be called nuvoton-cir. + config IR_MCEUSB tristate "Windows Media Center Ed. eHome Infrared Transceiver" depends on USB_ARCH_HAS_HCD diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile index 953c6c4..f9574ad 100644 --- a/drivers/media/IR/Makefile +++ b/drivers/media/IR/Makefile @@ -17,5 +17,6 @@ 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_NUVOTON) += nuvoton-cir.o obj-$(CONFIG_IR_ENE) += ene_ir.o obj-$(CONFIG_IR_STREAMZAP) += streamzap.o diff --git a/drivers/media/IR/nuvoton-cir.c b/drivers/media/IR/nuvoton-cir.c new file mode 100644 index 000..1ce9359 --- /dev/null +++ b/drivers/media/IR/nuvoton-cir.c @@ -0,0 +1,1216 @@ +/* + * Driver for Nuvoton Technology Corporation w83667hg/w83677hg-i CIR + * + * Copyright (C) 2010 Jarod Wilson + * Copyright (C) 2009 Nuvoton PS Team + * + * Special thanks to Nuvoton for providing hardware, spec sheets and + * sample code upon which portions of this driver are based. Indirect + * thanks also to Maxim Levitsky, whose ene_ir driver this driver is + * modeled after. + * + * 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, I
Re: [PATCH] lirc: Make struct file_operations pointer const
On Thu, Sep 30, 2010 at 09:55:07PM +0200, Geert Uytterhoeven wrote: > struct file_operations was made const in the drivers, but not in struct > lirc_driver: > > drivers/staging/lirc/lirc_it87.c:365: warning: initialization discards > qualifiers from pointer target type > drivers/staging/lirc/lirc_parallel.c:571: warning: initialization discards > qualifiers from pointer target type > drivers/staging/lirc/lirc_serial.c:1073: warning: initialization discards > qualifiers from pointer target type > drivers/staging/lirc/lirc_sir.c:482: warning: initialization discards > qualifiers from pointer target type > drivers/staging/lirc/lirc_zilog.c:1284: warning: assignment discards > qualifiers from pointer target type > > Signed-off-by: Geert Uytterhoeven Whoops, yeah, obvious fix. Acked-by: Jarod Wilson -- 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: [GIT PATCHES FOR 2.6.37] Remove v4l2-i2c-drv.h and most of i2c-id.h
On Sat, Sep 25, 2010 at 03:09:04AM -0300, Mauro Carvalho Chehab wrote:
> Em 23-09-2010 03:14, Hans Verkuil escreveu:
> > On Thursday, September 23, 2010 06:18:37 Mauro Carvalho Chehab wrote:
> >> Em 15-09-2010 17:00, Hans Verkuil escreveu:
> >>> Mauro, Jean, Janne,
> >>
> >>> After applying this patch series I get the following if I grep for
> >>> I2C_HW_ in the kernel sources:
> >>>
> >>>
> >>> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> >>> drivers/staging/lirc/lirc_zilog.c: if (ir->c_rx.adapter->id
> >>> == I2C_HW_B_HDPVR) {
> >>> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> >>> drivers/staging/lirc/lirc_zilog.c: if (ir->c_rx.adapter->id ==
> >>> I2C_HW_B_HDPVR)
> >>
> >> Those are with Janne ;)
> >
> > Since I2C_HW_B_HDPVR is not actually set anywhere and because it's staging,
> > I'd
> > propose that we just ignore this. It's under an #ifdef, so removing
> > i2c-id.h will
> > not affect this code.
> >
> >>> drivers/video/riva/rivafb-i2c.c:chan->adapter.id=
> >>> I2C_HW_B_RIVA;
> >>
> >> No idea about this one.
> >
> > This can be removed.
> >
> >>
> >>> drivers/media/video/ir-kbd-i2c.c: if (ir->c->adapter->id ==
> >>> I2C_HW_SAA7134 && ir->c->addr == 0x30)
> >>> drivers/media/video/saa7134/saa7134-i2c.c: .id=
> >>> I2C_HW_SAA7134,
> >>
> >> Those are easy: just add the polling interval into the platform_data. If
> >> zero,
> >> uses the default value. I'll write a patch for it.
> >
> > Nice!
> >
> >>> drivers/media/video/ir-kbd-i2c.c: if (adap->id ==
> >>> I2C_HW_B_CX2388x) {
> >>
> >> This is not hard to solve. I' ll write a patch for it.
> >
> > Nice!
> >
> >>> drivers/staging/lirc/lirc_i2c.c:if (adap->id ==
> >>> I2C_HW_B_CX2388x)
> >>> drivers/staging/lirc/lirc_i2c.c:if (adap->id ==
> >>> I2C_HW_B_CX2388x) {
> >>> drivers/media/video/cx88/cx88-i2c.c:core->i2c_adap.id =
> >>> I2C_HW_B_CX2388x;
> >>> drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c->adap.id =
> >>> I2C_HW_B_CX2388x;
> >>
> >> We need to solve lirc_i2c.c issues before being able to remove those. As
> >> lirc_i2c has
> >> the same implementation as ir-kbd-i2c, it is probably easier to just get
> >> rid of it,
> >> and then remove those two references. Jarod is working on it.
> >>
> >> While touching it, I'll move PV951 to bttv driver, and move all IR
> >> initialization code to
> >> bttv-input and cx88-input on those two drivers. This will make life easier
> >> when porting
> >> the code to rc-core, as everything that needs to be changed will be at the
> >> same file.
>
> The above were already merged.
> >
> > So after my pending tvaudio/tda8425 patch goes in and your patches, then
> > the only
> > remaining user of I2C_HW_B_ is lirc_i2c.c, right? Jean will like that :-)
>
> Patch applied. The remaining places are:
>
> drivers/media/video/cx88/cx88-i2c.c: core->i2c_adap.id =
> I2C_HW_B_CX2388x;
> drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c->adap.id =
> I2C_HW_B_CX2388x;
> drivers/staging/lirc/lirc_i2c.c: if (adap->id == I2C_HW_B_CX2388x)
> drivers/staging/lirc/lirc_i2c.c: if (adap->id == I2C_HW_B_CX2388x) {
> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> drivers/staging/lirc/lirc_zilog.c:if (ir->c_rx.adapter->id ==
> I2C_HW_B_HDPVR) {
> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> drivers/staging/lirc/lirc_zilog.c:if (ir->c_rx.adapter->id ==
> I2C_HW_B_HDPVR)
> drivers/video/riva/rivafb-i2c.c: chan->adapter.id=
> I2C_HW_B_RIVA;
>
> I'll try to review lirc_i2c. Maybe we can just remove it entirely, and then
> remove the entries
> on cx88 driver.
With lirc_i2c, I think the only hardware we *really* care about is the
Hauppague PVR-150 (variants w/o the zilog chip that includes tx
abilities), PVR-250 and PVR-350. Given that ir-kbd-i2c supports all of
those cards right now, I'm entirely in favor of lirc_i2c just going away.
--
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
[GIT PULL REQUEST] misc IR fixes and enhancements for 2.6.37
Hi Mauro, Please grab these IR fixes and enhancements. There's a patch that inches us closer to being able to remove lirc_i2c entirely, courtesy of Aris Rozanski, an added safety check in the lirc_dev unregister path which prevents a possible oops, and David Härdeman's patch to split out imon mouse events onto their own input device, which will facilitate his later enhancements to the remote control device interface. Also bundled in are a few other imon fixes and enhancements on top of David's patch, prompted by a kernel.org bugzilla and some feedback on the lirc mailing list. The following changes since commit 991403c594f666a2ed46297c592c60c3b9f4e1e2: V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0) (2010-09-11 11:58:01 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-lirc.git/ staging Aristeu Rozanski (1): IR: add support to Asus TV-Box to ir-kbd-i2c driver David Härdeman (1): imon: split mouse events to a separate input dev Jarod Wilson (4): IR: export ir_keyup so imon driver can use it directly IR/imon: protect ictx's kc and last_keycode w/spinlock IR/imon: set up mce-only devices w/mce keytable IR/lirc_dev: check for valid irctl in unregister path drivers/media/IR/imon.c | 583 + drivers/media/IR/ir-keytable.c|3 +- drivers/media/IR/keymaps/Makefile |1 + drivers/media/IR/keymaps/rc-asus-tv-box.c | 75 drivers/media/IR/lirc_dev.c |5 + drivers/media/video/ir-kbd-i2c.c | 77 include/media/ir-core.h |1 + include/media/rc-map.h|1 + 8 files changed, 503 insertions(+), 243 deletions(-) create mode 100644 drivers/media/IR/keymaps/rc-asus-tv-box.c -- 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: IR code autorepeat issue?
On Mon, Sep 20, 2010 at 6:55 PM, Anton Blanchard wrote: > > Hi, > >> > > I'm seeing double IR events on 2.6.36-rc2 and a DViCO FusionHDTV DVB-T >> > > Dual Express. >> > >> > 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: >> >> Ok, just sent a patch adding it to rc-core, and removing from dib0700 driver. > > Thanks, tested and confirmed to work! > > I originally hit this on Ubuntu Maverick. Would you be OK if I submit it for > backport to 2.6.35 stable? Nb: both Fedora 14's and Ubuntu 10.10's 2.6.35 kernels have a considerably newer IR stack than upstream 2.6.35, but this patch should still be relevant to both, since I don't see it yet in the Fedora tree, and the Ubuntu patches are more or less identical to at least the first round of IR stack update patches in the Fedora kernel. (Hm, I should actually give the Ubuntu folks some updated patches, but I think they may be pretty well frozen already...) I'll take care of updating the IR bits in the Fedora kernel, and will point some Ubuntu folks in this direction as well. -- 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/4] imon: split mouse events to a separate input dev
On Thu, Sep 16, 2010 at 03:43:42PM +0200, David Härdeman wrote: > On Thu, September 16, 2010 15:34, Jarod Wilson wrote: > > On Thu, Sep 16, 2010 at 01:32:07PM +0200, David Härdeman wrote: > >> On Thu, September 16, 2010 07:22, Jarod Wilson wrote: > >> > This is a stab at separating the mouse (and front panel/knob) events > >> > out to a separate input device. This is necessary in preparation for > >> > the next patch which makes the rc-core input dev opaque to rc > >> > drivers. > >> > > >> > I can't verify the correctness of the patch beyond the fact that it > >> > compiles without warnings. The driver has resisted most of my > >> > attempts at understanding it properly...for example, the double calls > >> > to le64_to_cpu() and be64_to_cpu() which are applied in > >> > imon_incoming_packet() and imon_panel_key_lookup() would amount > >> > to a bswab64() call, irregardless of the cpu endianness, and I think > >> > the code wouldn't have worked on a big-endian machine... > >> > > >> > Signed-off-by: David Härdeman > >> > > >> > - Minor alterations to apply with minimal core IR changes > >> > - Use timer for imon keys too, since its entirely possible for the > >> > receiver to miss release codes (either by way of another key being > >> > pressed while the first is held or by the remote pointing away from > >> > the recevier when the key is release. yes, I know, its ugly). > >> > >> Where's the additional timer usage exactly? I can't see any in the > >> patch... > > > > For ktype == IMON_KEY_IMON in your original patch, keys were submitted > > with ir_keydown_notimeout, and in this version, they're submitted with > > plain old ir_keydown, which has a built-in timeout. > > Oh, I see. But since you're not adding any timer to the driver code itself > I do not consider the use of plain ir_keydown to be ugly at all (contrary > to what your comment indicated). Oh, sorry, that rant was about the receiver hardware, not the actual code -- yes, the code gets much much cleaner here. :) > Maybe a keyup hardware event is generated (handled via ir_keyup, good), > maybe it isnt't (handled via ir-core timeout which calls ir_keyup > eventually, good). Yeah, its behaving much better for the specific cases Anssi mentioned in the bug now. We also get the automatic release of a key that wasn't released before pressing a second key, by way of the ir_keyup call in ir_keydown. -- 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: [PATCH 2/4] imon: split mouse events to a separate input dev
On Thu, Sep 16, 2010 at 01:32:07PM +0200, David Härdeman wrote: > On Thu, September 16, 2010 07:22, Jarod Wilson wrote: > > This is a stab at separating the mouse (and front panel/knob) events > > out to a separate input device. This is necessary in preparation for > > the next patch which makes the rc-core input dev opaque to rc > > drivers. > > > > I can't verify the correctness of the patch beyond the fact that it > > compiles without warnings. The driver has resisted most of my > > attempts at understanding it properly...for example, the double calls > > to le64_to_cpu() and be64_to_cpu() which are applied in > > imon_incoming_packet() and imon_panel_key_lookup() would amount > > to a bswab64() call, irregardless of the cpu endianness, and I think > > the code wouldn't have worked on a big-endian machine... > > > > Signed-off-by: David Härdeman > > > > - Minor alterations to apply with minimal core IR changes > > - Use timer for imon keys too, since its entirely possible for the > > receiver to miss release codes (either by way of another key being > > pressed while the first is held or by the remote pointing away from > > the recevier when the key is release. yes, I know, its ugly). > > Where's the additional timer usage exactly? I can't see any in the patch... For ktype == IMON_KEY_IMON in your original patch, keys were submitted with ir_keydown_notimeout, and in this version, they're submitted with plain old ir_keydown, which has a built-in timeout. -- 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: [PATCH 4/4] IR/imon: set up mce-only devices w/mce keytable
On Thu, Sep 16, 2010 at 10:11:16AM +0200, Anders Eriksson wrote: > > > > ja...@redhat.com said: > > > + /* iMON LCD, MCE IR */ > > + case 0x9e: > > + dev_info(ictx->dev, "0xffdc iMON VFD, MCE IR"); > > + detected_display_type = IMON_DISPLAY_TYPE_VFD; > > + allowed_protos = IR_TYPE_RC6; + break; > > + /* iMON LCD, MCE IR */ +case 0x9f: > > > > That "LCD" in the comment should be VFD. Ah, dammit, copy-paste fail. Will fix, thanks! -- 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
[PATCH 4/4] IR/imon: set up mce-only devices w/mce keytable
>From 321eb136b4c933a6a2e6583ccf110c22874c02fe Mon Sep 17 00:00:00 2001
From: Jarod Wilson
Date: Tue, 14 Sep 2010 23:28:41 -0400
Subject: [PATCH 4/4] IR/imon: set up mce-only devices w/mce keytable
Currently, they get set up with the pad keytable, which they can't
actually use at all. Also add another variant of volume scancodes from
another 0xffdc device, and properly set up the 0x9e 0xffdc device as an
iMON VFD w/MCE proto IR.
Based on data and a prior patch from Anders Eriksson on the lirc list.
Signed-off-by: Jarod Wilson
---
drivers/media/IR/imon.c | 264 --
1 files changed, 138 insertions(+), 126 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index 4b73b8e..ef81d38 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -292,6 +292,9 @@ static const struct {
{ 0x0001ffeell, KEY_VOLUMEUP },
{ 0x0100ffeell, KEY_VOLUMEDOWN },
{ 0x0100ffeell, KEY_MUTE },
+ /* 0xffdc iMON MCE VFD */
+ { 0x0001ffeell, KEY_VOLUMEUP },
+ { 0x0100ffeell, KEY_VOLUMEDOWN },
/* iMON Knob values */
{ 0x000100eell, KEY_VOLUMEUP },
{ 0x01eell, KEY_VOLUMEDOWN },
@@ -1701,11 +1704,128 @@ static void usb_rx_callback_intf1(struct urb *urb)
usb_submit_urb(ictx->rx_urb_intf1, GFP_ATOMIC);
}
+/*
+ * The 0x15c2:0xffdc device ID was used for umpteen different imon
+ * devices, and all of them constantly spew interrupts, even when there
+ * is no actual data to report. However, byte 6 of this buffer looks like
+ * its unique across device variants, so we're trying to key off that to
+ * figure out which display type (if any) and what IR protocol the device
+ * actually supports. These devices have their IR protocol hard-coded into
+ * their firmware, they can't be changed on the fly like the newer hardware.
+ */
+static void imon_get_ffdc_type(struct imon_context *ictx)
+{
+ u8 ffdc_cfg_byte = ictx->usb_rx_buf[6];
+ u8 detected_display_type = IMON_DISPLAY_TYPE_NONE;
+ u64 allowed_protos = IR_TYPE_OTHER;
+
+ switch (ffdc_cfg_byte) {
+ /* iMON Knob, no display, iMON IR + vol knob */
+ case 0x21:
+ dev_info(ictx->dev, "0xffdc iMON Knob, iMON IR");
+ ictx->display_supported = false;
+ break;
+ /* iMON 2.4G LT (usb stick), no display, iMON RF */
+ case 0x4e:
+ dev_info(ictx->dev, "0xffdc iMON 2.4G LT, iMON RF");
+ ictx->display_supported = false;
+ ictx->rf_device = true;
+ break;
+ /* iMON VFD, no IR (does have vol knob tho) */
+ case 0x35:
+ dev_info(ictx->dev, "0xffdc iMON VFD + knob, no IR");
+ detected_display_type = IMON_DISPLAY_TYPE_VFD;
+ break;
+ /* iMON VFD, iMON IR */
+ case 0x24:
+ case 0x85:
+ dev_info(ictx->dev, "0xffdc iMON VFD, iMON IR");
+ detected_display_type = IMON_DISPLAY_TYPE_VFD;
+ break;
+ /* iMON LCD, MCE IR */
+ case 0x9e:
+ dev_info(ictx->dev, "0xffdc iMON VFD, MCE IR");
+ detected_display_type = IMON_DISPLAY_TYPE_VFD;
+ allowed_protos = IR_TYPE_RC6;
+ break;
+ /* iMON LCD, MCE IR */
+ case 0x9f:
+ dev_info(ictx->dev, "0xffdc iMON LCD, MCE IR");
+ detected_display_type = IMON_DISPLAY_TYPE_LCD;
+ allowed_protos = IR_TYPE_RC6;
+ break;
+ default:
+ dev_info(ictx->dev, "Unknown 0xffdc device, "
+"defaulting to VFD and iMON IR");
+ detected_display_type = IMON_DISPLAY_TYPE_VFD;
+ break;
+ }
+
+ printk(KERN_CONT " (id 0x%02x)\n", ffdc_cfg_byte);
+
+ ictx->display_type = detected_display_type;
+ ictx->props->allowed_protos = allowed_protos;
+ ictx->ir_type = allowed_protos;
+}
+
+static void imon_set_display_type(struct imon_context *ictx)
+{
+ u8 configured_display_type = IMON_DISPLAY_TYPE_VFD;
+
+ /*
+* Try to auto-detect the type of display if the user hasn't set
+* it by hand via the display_type modparam. Default is VFD.
+*/
+
+ if (display_type == IMON_DISPLAY_TYPE_AUTO) {
+ switch (ictx->product) {
+ case 0xffdc:
+ /* set in imon_get_ffdc_type() */
+ configured_display_type = ictx->display_type;
+ break;
+ case 0x0034:
+ case 0x0035:
+ configured_display_type = IMON_DISPLAY_TYPE_VGA;
+ break;
+ case 0
[PATCH 3/4] IR/imon: protect ictx's kc and last_keycode w/spinlock
>From 1fd62121d93ca507ec6f2f692121f853a2c46889 Mon Sep 17 00:00:00 2001
From: Jarod Wilson
Date: Wed, 15 Sep 2010 14:56:03 -0400
Subject: [PATCH 3/4] IR/imon: protect ictx's kc and last_keycode w/spinlock
Lest we get our keycodes wrong... Thus far, in practice, I've not found
it to actually matter, but its one of the issues raised in
https://bugzilla.kernel.org/show_bug.cgi?id=16351 that wasn't addressed
by converting to using native IR keydown/up functions.
Signed-off-by: Jarod Wilson
---
drivers/media/IR/imon.c | 52 +-
1 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index d36fe72..4b73b8e 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -1,7 +1,7 @@
/*
* imon.c: input and display driver for SoundGraph iMON IR/VFD/LCD
*
- * Copyright(C) 2009 Jarod Wilson
+ * Copyright(C) 2010 Jarod Wilson
* Portions based on the original lirc_imon driver,
* Copyright(C) 2004 Venky Raju(d...@venky.ws)
*
@@ -125,6 +125,7 @@ struct imon_context {
struct input_dev *idev; /* input device for panel & IR mouse */
struct input_dev *touch;/* input device for touchscreen */
+ spinlock_t kc_lock; /* make sure we get keycodes right */
u32 kc; /* current input keycode */
u32 last_keycode; /* last reported input keycode */
u32 rc_scancode;/* the computed remote scancode */
@@ -1210,6 +1211,9 @@ static bool imon_mouse_event(struct imon_context *ictx,
u8 right_shift = 1;
bool mouse_input = true;
int dir = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&ictx->kc_lock, flags);
/* newer iMON device PAD or mouse button */
if (ictx->product != 0xffdc && (buf[0] & 0x01) && len == 5) {
@@ -1241,6 +1245,8 @@ static bool imon_mouse_event(struct imon_context *ictx,
} else
mouse_input = false;
+ spin_unlock_irqrestore(&ictx->kc_lock, flags);
+
if (mouse_input) {
dev_dbg(ictx->dev, "sending mouse data via input subsystem\n");
@@ -1255,7 +1261,9 @@ static bool imon_mouse_event(struct imon_context *ictx,
buf[1] >> right_shift & 0x1);
}
input_sync(ictx->idev);
+ spin_lock_irqsave(&ictx->kc_lock, flags);
ictx->last_keycode = ictx->kc;
+ spin_unlock_irqrestore(&ictx->kc_lock, flags);
}
return mouse_input;
@@ -1278,6 +1286,7 @@ static void imon_pad_to_keys(struct imon_context *ictx,
unsigned char *buf)
char rel_x = 0x00, rel_y = 0x00;
u16 timeout, threshold;
u32 scancode = KEY_RESERVED;
+ unsigned long flags;
/*
* The imon directional pad functions more like a touchpad. Bytes 3 & 4
@@ -1301,7 +1310,11 @@ static void imon_pad_to_keys(struct imon_context *ictx,
unsigned char *buf)
dir = stabilize((int)rel_x, (int)rel_y,
timeout, threshold);
if (!dir) {
+ spin_lock_irqsave(&ictx->kc_lock,
+ flags);
ictx->kc = KEY_UNKNOWN;
+ spin_unlock_irqrestore(&ictx->kc_lock,
+ flags);
return;
}
buf[2] = dir & 0xFF;
@@ -1363,7 +1376,9 @@ static void imon_pad_to_keys(struct imon_context *ictx,
unsigned char *buf)
dir = stabilize((int)rel_x, (int)rel_y,
timeout, threshold);
if (!dir) {
+ spin_lock_irqsave(&ictx->kc_lock, flags);
ictx->kc = KEY_UNKNOWN;
+ spin_unlock_irqrestore(&ictx->kc_lock, flags);
return;
}
buf[2] = dir & 0xFF;
@@ -1392,8 +1407,11 @@ static void imon_pad_to_keys(struct imon_context *ictx,
unsigned char *buf)
}
}
- if (scancode)
+ if (scancode) {
+ spin_lock_irqsave(&ictx->kc_lock, flags);
ictx->kc = imon_remote_key_lookup(ictx, scancode);
+ spin_unlock_irqrestore(&ictx->kc_lock, flags);
+ }
}
/**
@@ -1405,6 +1423,9 @@ static int imon_parse_press_type(struct imon_context
*ictx,
u
[PATCH 2/4] imon: split mouse events to a separate input dev
>From 4ceb1642b756e7a11753c6fae645806d2514c54a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?David=20H=C3=A4rdeman?=
Date: Wed, 15 Sep 2010 14:42:07 -0400
Subject: [PATCH 2/4] imon: split mouse events to a separate input dev
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is a stab at separating the mouse (and front panel/knob) events
out to a separate input device. This is necessary in preparation for
the next patch which makes the rc-core input dev opaque to rc
drivers.
I can't verify the correctness of the patch beyond the fact that it
compiles without warnings. The driver has resisted most of my
attempts at understanding it properly...for example, the double calls
to le64_to_cpu() and be64_to_cpu() which are applied in
imon_incoming_packet() and imon_panel_key_lookup() would amount
to a bswab64() call, irregardless of the cpu endianness, and I think
the code wouldn't have worked on a big-endian machine...
Signed-off-by: David Härdeman
- Minor alterations to apply with minimal core IR changes
- Use timer for imon keys too, since its entirely possible for the
receiver to miss release codes (either by way of another key being
pressed while the first is held or by the remote pointing away from
the recevier when the key is release. yes, I know, its ugly).
- Bump driver version number, since this is a fairly significant change
(for the much much better).
Tested successfully w/an imon knob receiver.
Signed-off-by: Jarod Wilson
---
drivers/media/IR/imon.c | 273 +++---
1 files changed, 160 insertions(+), 113 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index c185422..d36fe72 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -44,7 +44,7 @@
#define MOD_AUTHOR "Jarod Wilson "
#define MOD_DESC "Driver for SoundGraph iMON MultiMedia IR/Display"
#define MOD_NAME "imon"
-#define MOD_VERSION"0.9.1"
+#define MOD_VERSION"0.9.2"
#define DISPLAY_MINOR_BASE 144
#define DEVICE_NAME"lcd%d"
@@ -121,21 +121,25 @@ struct imon_context {
u16 vendor; /* usb vendor ID */
u16 product;/* usb product ID */
- struct input_dev *idev; /* input device for remote */
+ struct input_dev *rdev; /* input device for remote */
+ struct input_dev *idev; /* input device for panel & IR mouse */
struct input_dev *touch;/* input device for touchscreen */
u32 kc; /* current input keycode */
u32 last_keycode; /* last reported input keycode */
+ u32 rc_scancode;/* the computed remote scancode */
+ u8 rc_toggle; /* the computed remote toggle bit */
u64 ir_type;/* iMON or MCE (RC6) IR protocol? */
- u8 mce_toggle_bit; /* last mce toggle bit */
bool release_code; /* some keys send a release code */
u8 display_type;/* store the display type */
bool pad_mouse; /* toggle kbd(0)/mouse(1) mode */
+ char name_rdev[128];/* rc input device name */
+ char phys_rdev[64]; /* rc input device phys path */
+
char name_idev[128];/* input device name */
char phys_idev[64]; /* input device phys path */
- struct timer_list itimer; /* input device timer, need for rc6 */
char name_touch[128]; /* touch screen name */
char phys_touch[64];/* touch screen phys path */
@@ -956,17 +960,6 @@ static void usb_tx_callback(struct urb *urb)
}
/**
- * mce/rc6 keypresses have no distinct release code, use timer
- */
-static void imon_mce_timeout(unsigned long data)
-{
- struct imon_context *ictx = (struct imon_context *)data;
-
- input_report_key(ictx->idev, ictx->last_keycode, 0);
- input_sync(ictx->idev);
-}
-
-/**
* report touchscreen input
*/
static void imon_touch_display_timeout(unsigned long data)
@@ -1006,9 +999,6 @@ int imon_ir_change_protocol(void *priv, u64 ir_type)
dev_dbg(dev, "Configuring IR receiver for MCE protocol\n");
ir_proto_packet[0] = 0x01;
pad_mouse = false;
- init_timer(&ictx->itimer);
- ictx->itimer.data = (unsigned long)ictx;
- ictx->itimer.function = imon_mce_timeout;
break;
case IR_TYPE_UNKNOWN:
case IR_TYPE_OTHER:
@@ -1147,20 +1137,21 @@ static int stabilize(int a, int b, u16 timeout, u16
threshold)
return result;
}
-static u32 imon_remote_key_lookup(struct imon_context *ictx, u32 hw_code)
+static u32 imon_remote_key_lookup(struct imon_context
[PATCH 1/4] IR: export ir_keyup so imon driver can use it directly
>From d31919ac08ba9a203bd673bbed18e78293ceaa68 Mon Sep 17 00:00:00 2001
From: Jarod Wilson
Date: Wed, 15 Sep 2010 14:31:12 -0400
Subject: [PATCH 1/4] IR: export ir_keyup so imon driver can use it directly
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The imon driver currently reimplements its own version of ir_keyup
(along with key release timer functionality also already present in the
core IR code). A follow-up imon patch will make use of ir_keyup and the
IR stack's key release code.
Trivial extraction from David Härdeman's pending rc-core merge and
device interface abstraction patchset to facilitate merging a patch
based on his imon input dev split patch ahead of the larger churn, which
is slated for post-2.6.37-rc1 (after Dmitry's large keycode patches are
merged in mainline).
Signed-off-by: Jarod Wilson
---
drivers/media/IR/ir-keytable.c |3 ++-
include/media/ir-core.h|1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 7961d59..59510cd 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -285,7 +285,7 @@ EXPORT_SYMBOL_GPL(ir_g_keycode_from_table);
* This routine is used to signal that a key has been released on the
* remote control. It reports a keyup input event via input_report_key().
*/
-static void ir_keyup(struct ir_input_dev *ir)
+void ir_keyup(struct ir_input_dev *ir)
{
if (!ir->keypressed)
return;
@@ -295,6 +295,7 @@ static void ir_keyup(struct ir_input_dev *ir)
input_sync(ir->input_dev);
ir->keypressed = false;
}
+EXPORT_SYMBOL_GPL(ir_keyup);
/**
* ir_timer_keyup() - generates a keyup event after a timeout
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index eb7fddf..4dd43d4 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -157,6 +157,7 @@ void ir_input_unregister(struct input_dev *input_dev);
void ir_repeat(struct input_dev *dev);
void ir_keydown(struct input_dev *dev, int scancode, u8 toggle);
+void ir_keyup(struct ir_input_dev *ir);
u32 ir_g_keycode_from_table(struct input_dev *input_dev, u32 scancode);
/* From ir-raw-event.c */
--
1.7.2.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
[PATCH 0/4] IR/imon: split out mouse events and fix bugs
These patches make the imon driver slightly less distasteful. The meat of the changes are from David's patch to split the IR mouse mode and panel/knob events out onto their own input device, leaving just IR keys to come through the IR device. This facilitates further abstraction of the ir/rc-core interface, but allows us to get these patches in ahead of David's major reshuffle that is targeted for post-2.6.37-rc1 (basically, after Dmitry's large keycode patches are merged in mainline). Additionally, while David's patch unknowingly addressed many of the issues in https://bugzilla.kernel.org/show_bug.cgi?id=16351, there are a few more issues addressed by the spinlock patch (at least, in theory, since in practice, it doesn't really seem to matter much to me, but Anssi suggested that some locking may be a good idea in the bug :). Finally, there's a bit of reshuffling of auto-config bits for the 0xffdc imon devices so the mce-only ones get set up w/the mce key table by default instead of the imon pad one (based on input from Anders Eriksson over on the lirc list). David Härdeman (1): imon: split mouse events to a separate input dev Jarod Wilson (3): IR: export ir_keyup so imon driver can use it directly IR/imon: protect ictx's kc and last_keycode w/spinlock IR/imon: set up mce-only devices w/mce keytable drivers/media/IR/imon.c| 583 +++- drivers/media/IR/ir-keytable.c |3 +- include/media/ir-core.h|1 + 3 files changed, 344 insertions(+), 243 deletions(-) -- 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: [PATCH] ir-core: Fix null dereferences in the protocols sysfs interface
On Wed, Sep 15, 2010 at 05:57:10AM -0700, Brian Rogers wrote: > On 09/08/2010 07:16 AM, Jarod Wilson wrote: > >On Wed, Sep 08, 2010 at 07:04:03AM -0700, Brian Rogers wrote: > >>ir_dev->raw is also null. If I check these pointers before using > >>them, and bail out if both are null, then I get a working lircd, but > >>of course the file /sys/devices/virtual/rc/rc0/protocols no longer > >>does anything. On 2.6.35.4, the system never creates the > >>/sys/class/rc/rc0/current_protocol file. Is it the case that the > >>'protocols' file should never appear, because my card can't support > >>this feature? > >Hm... So protocols is indeed intended for hardware that handles raw IR, as > >its a list of raw IR decoders available/enabled/disabled for the receiver. > >But some devices that do onboard decoding and deal with scancodes still > >need to support changing protocols, as they can be told "decode rc5" or > >"decode nec", etc... My memory is currently foggy on how it was exactly > >that it was supposed to be donee though. :) (Yet another reason I really > >need to poke at the imon driver code again). > > How about the attached patch? Does this look like a reasonable > solution for 2.6.36? > > Brian > > From 7937051c5e2c8b5b0410172d48e62d54bd1906ee Mon Sep 17 00:00:00 2001 > From: Brian Rogers > Date: Wed, 8 Sep 2010 05:33:34 -0700 > Subject: [PATCH] ir-core: Fix null dereferences in the protocols sysfs > interface > > For some cards, ir_dev->props and ir_dev->raw are both NULL. These cards are > using built-in IR decoding instead of raw, and can't easily be made to switch > protocols. > > So upon reading /sys/class/rc/rc?/protocols on such a card, return 'builtin' > as > the supported and enabled protocol. Return -EINVAL on any attempts to change > the protocol. And most important of all, don't crash. > > Signed-off-by: Brian Rogers > --- > drivers/media/IR/ir-sysfs.c | 17 +++-- > 1 files changed, 11 insertions(+), 6 deletions(-) Yeah, this looks pretty sane for 2.6.36, would just be a short-lived panic preventer until David's interface changes get merged after 2.6.37-rc1. Acked-by: Jarod Wilson -- 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: [PATCH 0/6] Large scancode handling
On Wed, Sep 8, 2010 at 11:34 AM, Dmitry Torokhov
wrote:
> On Wed, Sep 08, 2010 at 10:31:21AM -0400, Jarod Wilson wrote:
>> On Wed, Sep 08, 2010 at 12:41:38AM -0700, Dmitry Torokhov wrote:
...
>> > Ville, do you still have the hardware to try our ati_remote2 changes?
>>
>> If not, I've got the hardware. (Speaking of which, porting ati_remote*
>> over to {ir,rc}-core is also on the TODO list, albeit with very very
>> low priority at the moment).
>
> Ok, then we'' pencil you in for testing if we do not hear from Ville ;)
We've heard from Ville, but I went ahead and did some testing anyway.
My RWII with the default mode (didn't try any of the others) works
just fine after applying this patch atop 2.6.36-rc3-git1, as do my
imon and mceusb receivers. Ran into some problems with streamzap, but
I'm fairly sure they're not the fault of this patchset.
--
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 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Fri, Sep 10, 2010 at 11:35:23AM +0300, Maxim Levitsky wrote: > On Thu, 2010-09-09 at 22:01 -0400, Jarod Wilson wrote: > > On Thu, Sep 09, 2010 at 12:34:27AM -0400, Jarod Wilson wrote: > > ... > > > >> For now, I've applied patches 3, 4 and 5, as it is nice to have > > > >> Jarod's review also. > > > > > > > > I've finally got them all applied atop current media_tree > > > > staging/v2.6.37, > > > > though none of the streamzap bits in patch 7 are applicable any longer. > > > > Will try to get through looking and commenting (and testing) of the rest > > > > of them tonight. > > > > > > Also had to make a minor addition to the rc5-sz decoder (same change > > > as in the other decoders). Almost have all the requisite test kernels > > > for David's, Maxim's and Dmitry's patchsets built and installed, wish > > > my laptop was faster... Probably would have been faster to use a lab > > > box and copy data over. Oh well. So functional testing to hopefully > > > commence tomorrow morning. > > > > Wuff. None of the three builds is at all stable on my laptop, but I can't > > actually point the finger at any of the three patchsets, since I'm getting > > spontaneous lockups doing nothing at all before even plugging in a > > receiver. I did however get occasional periods of a non-panicking (not > > starting X seems to help a lot). Initial results: > > > > Btw, my printk blackbox patch could help you a lot. > I can't count how many times it helped me. > I just enable softlockup, hardlockup, and nmi watchdog, and let system > panic on oopses, and reboot. Or if you have hardware reboot button, you > can just use it. The point is that most BIOSES don't clear the ram, and > I take advantage of that. Interesting. I was thinking perhaps I'd give a go at trying kdump on my laptop, but I've had pretty mixed results with kdump working correctly on random kernels (generally works quite well in RHEL, notsomuch in Fedora). My hope is that this is something already fixed in later Linus' kernels, so I'll try a current Linus snap before I try looking any deeper. I'll file this away for consideration though! -- 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: [PATCH 5/8] IR: extend MCE keymap.
On Fri, Sep 10, 2010 at 10:27:02AM +0200, David Härdeman wrote: > On Fri, September 10, 2010 03:37, Jarod Wilson wrote: > > I think for mythtv, we're going to end up having a daemon process with > > elevated privs that reads directly from input devices to get around > > this annoyance, until such time as the annoyance is gone. > > A similar approach could work for XBMC since it already has input plugins > (e.g. for using a Nintendo Wii controller, etc). While attempting to drift off to sleep last night, it occurred to me that lircd already has support for attaching to input devices, so it might be an option to extend lircd and the lirc client library to have a "pass raw keycodes" mode. Both xmbc and mythtv already have options to build in lirc client support, so it'd just be minor extension of its use in both cases, at least in theory... -- 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: [PATCH 5/8] IR: extend MCE keymap.
On Fri, Sep 10, 2010 at 11:40:31AM +0300, Maxim Levitsky wrote: > On Thu, 2010-09-09 at 21:37 -0400, Jarod Wilson wrote: > > On Thu, Sep 9, 2010 at 8:40 PM, Maxim Levitsky > > wrote: > > > On Wed, 2010-09-08 at 10:47 -0400, Jarod Wilson wrote: > > >> On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky > > >> wrote: > > >> > These keys are found on remote bundled with > > >> > Toshiba Qosmio F50-10q. > > >> > > > >> > Found and tested by, Sami R > > >> > > > >> > Signed-off-by: Maxim Levitsky > > >> > --- > > >> > drivers/media/IR/keymaps/rc-rc6-mce.c |3 +++ > > >> > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > > > Tommorow I will resend that patch with even more scancodes. > > > > Saw the discussion on irc. Feel your pain big-time on the X server > > limitation on keycodes. Its put a big damper on efforts to add native > > support to mythtv. Peter Hutterer's libXi2 cookbook tutorials talk a > > good game about how libXi2 supports 32-bit keycodes, but neglects to > > mention that the X server still gobbles up anything above 248 or 255 > > or whatever it is, and remedying that is no small task. :( > > > > I think for mythtv, we're going to end up having a daemon process with > > elevated privs that reads directly from input devices to get around > > this annoyance, until such time as the annoyance is gone. > > Btw, indeed Xi2 still doesn't pass > 248 keycodes, just tested that with > -git versions of X stack from about 2 months ago. > However this can be fixed relatively easily. > Maybe even I could do that. > > The big problem is however about ability to map extended keycodes to > actions, thing that should be provided by XKB2, which we will see > probably when DNF is released on Phantom console... > Also this will need lots of changes in toolkits. > Thats the problem I don't have resources to fix. Yeah, that's exactly what I got from Peter when I was asking him about this issue on irc -- X server can be modified fairly easily, but there's the arduous and undesirable task of making all the toolkits and whatnot behave again, and nobody in their right mind really *wants* to dig into xkb. :) -- 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: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Fri, Sep 10, 2010 at 10:08:24AM +0200, David Härdeman wrote: > On Fri, September 10, 2010 04:01, Jarod Wilson wrote: > > Wuff. None of the three builds is at all stable on my laptop, but I can't > > actually point the finger at any of the three patchsets, since I'm getting > > spontaneous lockups doing nothing at all before even plugging in a > > receiver. I did however get occasional periods of a non-panicking (not > > starting X seems to help a lot). Initial results: > > If you get lockups without even plugging in a receiver, does that mean > that the rc-core driver hasn't even been loaded at that point? Correct, no rc-core bits loaded at all at this point. -- 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: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Thu, Sep 09, 2010 at 12:34:27AM -0400, Jarod Wilson wrote: ... > >> For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's > >> review also. > > > > I've finally got them all applied atop current media_tree staging/v2.6.37, > > though none of the streamzap bits in patch 7 are applicable any longer. > > Will try to get through looking and commenting (and testing) of the rest > > of them tonight. > > Also had to make a minor addition to the rc5-sz decoder (same change > as in the other decoders). Almost have all the requisite test kernels > for David's, Maxim's and Dmitry's patchsets built and installed, wish > my laptop was faster... Probably would have been faster to use a lab > box and copy data over. Oh well. So functional testing to hopefully > commence tomorrow morning. Wuff. None of the three builds is at all stable on my laptop, but I can't actually point the finger at any of the three patchsets, since I'm getting spontaneous lockups doing nothing at all before even plugging in a receiver. I did however get occasional periods of a non-panicking (not starting X seems to help a lot). Initial results: Dmitry's patchset: - all good for imon, streamzap and mceusb David's patchset: - all good for mceusb, as expected, since David has mce hardware himself, did not try the others yet Maxim's patchset: - all good for mceusb and imon - streamzap decoding fails miserably. I have an inkling why, but will need to get a stable testing platform before I can really properly dig into it. Still working on that stable testing platform, which is "backport current ir-core to the latest Fedora 14 kernel", which is 2.6.35.4-based and rock-solid on this machine. After that, will start applying patchsets. (I have yet to really look at the lockups, they look like random memory corruption though). -- 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: [PATCH 5/8] IR: extend MCE keymap.
On Thu, Sep 9, 2010 at 8:40 PM, Maxim Levitsky wrote: > On Wed, 2010-09-08 at 10:47 -0400, Jarod Wilson wrote: >> On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky >> wrote: >> > These keys are found on remote bundled with >> > Toshiba Qosmio F50-10q. >> > >> > Found and tested by, Sami R >> > >> > Signed-off-by: Maxim Levitsky >> > --- >> > drivers/media/IR/keymaps/rc-rc6-mce.c | 3 +++ >> > 1 files changed, 3 insertions(+), 0 deletions(-) > > Tommorow I will resend that patch with even more scancodes. Saw the discussion on irc. Feel your pain big-time on the X server limitation on keycodes. Its put a big damper on efforts to add native support to mythtv. Peter Hutterer's libXi2 cookbook tutorials talk a good game about how libXi2 supports 32-bit keycodes, but neglects to mention that the X server still gobbles up anything above 248 or 255 or whatever it is, and remedying that is no small task. :( I think for mythtv, we're going to end up having a daemon process with elevated privs that reads directly from input devices to get around this annoyance, until such time as the annoyance is gone. -- 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/5] rc-core: remove remaining users of the ir-functions keyhandlers
On Tue, Sep 7, 2010 at 5:51 PM, David Härdeman wrote: > This patch removes the remaining usages of the ir_input_nokey() and > ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c > by using the corresponding functionality in rc-core directly instead. > > Signed-off-by: David Härdeman Killing off legacy crud is a good thing. For a moment, I was confused by all the ir_type bits being removed, thinking those were still needed to populate allowed_protocols, but from reading through the patch in more detail, none of them are used for that. Then it dawned on me that (all of?) these are drivers that deal in scancodes, and allowed_protocols only really matters for raw IR drivers and scancode drivers that have a change_protocol function wired up. The only drivers that have that which the patch touches are saa7134-input.c and tm6000-input.c, and they're left intact, so all the ir_type bits removed are indeed completely unnecessary. That was a long-winded way of saying: 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 1/5] rc-code: merge and rename ir-core
On Wed, Sep 8, 2010 at 5:42 PM, David Härdeman wrote: > On Wed, Sep 08, 2010 at 10:42:10AM -0300, Mauro Carvalho Chehab wrote: >> Em 07-09-2010 18:51, David Härdeman escreveu: >> > This patch merges the files which makes up ir-core and renames the >> > resulting module to rc-core. IMHO this makes it much easier to hack >> > on the core module since all code is in one file. >> > >> > This also allows some simplification of ir-core-priv.h as fewer internal >> > functions need to be exposed. >> >> I'm not sure about this patch. Big files tend to be harder to maintain, >> as it takes more time to find the right functions inside it. Also, IMO, >> it makes sense to keep the raw-event code on a separate file. > > I don't find "big" files difficult (note: we're talking about 1300 lines > here). Rather the opposite, no hesitation about which files a given > function originates from and all related code in one nice file. evdev.c > and input.c are good precedents. But of course, it all boils down to a > matter of personal taste. I think I have to finally admit that my personal taste tends toward one "big" file in this particular case. >> Anyway, if we apply this patch right now, it will cause merge conflicts with >> the input tree, due to the get/setkeycodebig patches, and with some other >> patches that are pending merge/review. The better is to apply such patch >> just after the release of 2.6.37-rc1, after having all those conflicts >> solved. > > I agree that the big scancode patches from the input tree should go > first. I keep updating my patchset as the media_tree (staging/v2.6.37 > branch) changes so I have no problem sending an updated patchset at a > suitable time in the future. Please feel free to add this to the subsequent refreshes: 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 4/5] rc-core: make struct rc_dev the primary interface for rc drivers
On Tue, Sep 7, 2010 at 5:51 PM, David Härdeman wrote: > This patch merges the ir_input_dev and ir_dev_props structs into a single > struct called rc_dev. The drivers and various functions in rc-core used > by the drivers are also changed to use rc_dev as the primary interface > when dealing with rc-core. > > This means that the input_dev is abstracted away from the drivers which > is necessary if we ever want to support multiple input devs per rc device. > > The new API is similar to what the input subsystem uses, i.e: > rc_device_alloc() > rc_device_free() > rc_device_register() > rc_device_unregister() > > Signed-off-by: David Härdeman I've only looked at the core pieces of the patch and spot-checked the drivers and decoders I'm most familiar with thus far, but I'm *very* much in favor of this patch. The parts I've looked at are a very nice improvement that greatly simplifies the interface, and should eliminate multiple possible coding failure points and reduce duplication (a few sections of imon, mceusb and streamzap all looked pretty damned similar, this patch removes the bulk of that duplication and abstracts it away). With the caveat that I haven't actually functionally tested it yet, nor looked at every single bit of it: 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 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Wed, Sep 8, 2010 at 6:42 PM, Jarod Wilson wrote: > On Wed, Sep 08, 2010 at 06:54:02PM -0300, Mauro Carvalho Chehab wrote: >> Em 06-09-2010 18:26, Maxim Levitsky escreveu: >> > Hi, >> > >> > Here is full overview of my patches: >> > >> > Patch #1 fixes races in ir thread. >> > It fixes the case when ktherad_stop waits forever for the thread. >> > This happens on module unload and therefore it never finishes. >> > Sorry for introducing this bug. >> > >> > Patch #2, fixes a crash on my module load. >> > It happens because ir core initializes the input device a bit early, >> > therefore it could be accessed while still not set up. >> > >> > Patch #3 fixes a small typo in lirc code that makes it impossible to use >> > tx duty cycle setting. >> > >> > Patch #4 fixes a problem seen on my system that results in stuck down >> > forever key. >> > >> > Patch #5 adds few keys to MCE keymap that were found on laptop of an user >> > I tested this driver with >> > >> > Patch #6, is a combined update ti my driver. It contains lot of >> > refactoring thanks to docs I have now, >> > and lot of fixes, and supports latest version of firmware (and I have 4 >> > users asking for that) >> > It is quite huge, but it would be a tedios job to break it up. This can't >> > introduce regressions >> > because the ene_ir was never released. In addition to that it was tested >> > by me and another two users. >> > >> > Patch #7 the really only patch that touches drivers I don't have does >> > touch the ir-core. >> > It is quite small, and it adds a proper solution to dilema about what to >> > do with huge space between keypresses. >> > Now this space is just truncated by the driver with timeout flag. >> > The lirc codec then ensures that right sample is send to the lircd. >> > Please review and test it. >> > >> > Patch #8 is very simple. It just builds on top of patch #7 and adds >> > carrier reports to ene driver. >> >> For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's >> review also. > > I've finally got them all applied atop current media_tree staging/v2.6.37, > though none of the streamzap bits in patch 7 are applicable any longer. > Will try to get through looking and commenting (and testing) of the rest > of them tonight. Also had to make a minor addition to the rc5-sz decoder (same change as in the other decoders). Almost have all the requisite test kernels for David's, Maxim's and Dmitry's patchsets built and installed, wish my laptop was faster... Probably would have been faster to use a lab box and copy data over. Oh well. So functional testing to hopefully commence tomorrow morning. -- 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/8] IR: make sure we register the input device when it is safe to do so.
On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky wrote: > As soon as input device is registered, it might be accessed (and it is) > This can trigger a hardware interrupt that can access > not yet initialized ir->raw, (by sending a sample) > > This can be reproduced by holding down a remote button and reloading the > module. > And this always crashes the systems where hardware decides to send an > interrupt > right at the moment it is enabled. > > Signed-off-by: Maxim Levitsky Finally got my head wrapped around this one too, and I do see the problem, and this fix looks good to me. 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 1/8] IR: plug races in IR raw thread.
On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky wrote: > 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 Took a while to unwind everything in ir_raw_event_thread() in my head, but now that I think I have it sorted out, yeah, that looks like the processing logic all remains the same, with the addition of locking that should prevent the race (also heavily supported by your testing). 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 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Wed, Sep 08, 2010 at 06:54:02PM -0300, Mauro Carvalho Chehab wrote: > Em 06-09-2010 18:26, Maxim Levitsky escreveu: > > Hi, > > > > Here is full overview of my patches: > > > > Patch #1 fixes races in ir thread. > > It fixes the case when ktherad_stop waits forever for the thread. > > This happens on module unload and therefore it never finishes. > > Sorry for introducing this bug. > > > > Patch #2, fixes a crash on my module load. > > It happens because ir core initializes the input device a bit early, > > therefore it could be accessed while still not set up. > > > > Patch #3 fixes a small typo in lirc code that makes it impossible to use tx > > duty cycle setting. > > > > Patch #4 fixes a problem seen on my system that results in stuck down > > forever key. > > > > Patch #5 adds few keys to MCE keymap that were found on laptop of an user I > > tested this driver with > > > > Patch #6, is a combined update ti my driver. It contains lot of refactoring > > thanks to docs I have now, > > and lot of fixes, and supports latest version of firmware (and I have 4 > > users asking for that) > > It is quite huge, but it would be a tedios job to break it up. This can't > > introduce regressions > > because the ene_ir was never released. In addition to that it was tested by > > me and another two users. > > > > Patch #7 the really only patch that touches drivers I don't have does touch > > the ir-core. > > It is quite small, and it adds a proper solution to dilema about what to do > > with huge space between keypresses. > > Now this space is just truncated by the driver with timeout flag. > > The lirc codec then ensures that right sample is send to the lircd. > > Please review and test it. > > > > Patch #8 is very simple. It just builds on top of patch #7 and adds carrier > > reports to ene driver. > > For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's > review also. I've finally got them all applied atop current media_tree staging/v2.6.37, though none of the streamzap bits in patch 7 are applicable any longer. Will try to get through looking and commenting (and testing) of the rest of them tonight. -- 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: [PATCH 0/6] Large scancode handling
On Wed, Sep 08, 2010 at 09:56:07AM -0700, Dmitry Torokhov wrote: > On Wed, Sep 08, 2010 at 12:09:08PM -0400, Jarod Wilson wrote: > > On Wed, Sep 08, 2010 at 05:25:13PM +0200, Jiri Kosina wrote: > > > On Wed, 8 Sep 2010, Jarod Wilson wrote: > > > > > > > > > It'll conflict a little bith with the tivo slide patch I posted > > > > > > yesterday, > > > > > > but mostly just minor context changes. I can redo that patch on top > > > > > > of > > > > > > these changes if that's preferred. > > > > > > > > > > I can handle those context changes when merging the patches at > > > > > linux-next and > > > > > when merging upstream. We just need to sync in a way that Dmitry send > > > > > his patch > > > > > series before mine when sending them to Linus, and I'll take care of > > > > > fixing the > > > > > merge conflicts. > > > > > > > > Ah, the specific conflicts I was referring here are confined to > > > > drivers/hid/hid-input.c, and I sent the patch thinking it would go in > > > > via > > > > the hid tree. It *is* for a remote, but its a pure HID device in this > > > > case. > > > > > > Umm, what patch are you talking about please? I don't seem to have > > > anything from you in my queue. > > > > Gah. I suck. Forgot to cc you on it. > > > > http://www.spinics.net/lists/linux-input/msg11007.html > > > > Can resend and/or bounce you a copy if need be. > > > > Hmm, I do not see anything in there that would conflict with my > changes... Sorry, yeah, it *should* be solely context conflicts due to line offsets and other misc drift, no functional conflicts with your changes. -- 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: [PATCH 7/8] IR: extend ir_raw_event and do refactoring
On Wed, Sep 08, 2010 at 12:50:46PM -0400, Andy Walls wrote:
> On Wed, 2010-09-08 at 11:26 -0400, Jarod Wilson wrote:
> > On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky
> > wrote:
> > > 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: DEFINE_IR_RAW_EVENT(ev);
> > >
> > > To clean an existing event, use init_ir_raw_event(&ev);
> > >
> > > Signed-off-by: Maxim Levitsky
> > > ---
> > > drivers/media/IR/ene_ir.c |4 +-
> > > drivers/media/IR/ir-core-priv.h| 13 ++-
> > > drivers/media/IR/ir-jvc-decoder.c |5 +-
> > > drivers/media/IR/ir-lirc-codec.c | 78
> > > +++-
> > > drivers/media/IR/ir-nec-decoder.c |5 +-
> > > drivers/media/IR/ir-raw-event.c| 45 +++-
> > > 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 |3 +-
> > > drivers/media/IR/streamzap.c |8 ++-
> > > include/media/ir-core.h| 40 ---
> > > 12 files changed, 153 insertions(+), 63 deletions(-)
> > ...
> > > @@ -162,22 +164,48 @@ u32 ir_g_keycode_from_table(struct input_dev
> > > *input_dev, u32 scancode);
> > > /* From ir-raw-event.c */
> > >
> > > struct ir_raw_event {
> > > - unsignedpulse:1;
> > > - unsignedduration:31;
> > > + union {
> > > + u32 duration;
> > > +
> > > + struct {
> > > + u32 carrier;
> > > + u8 duty_cycle;
> > > + };
> > > + };
> > > +
> > > + unsignedpulse:1;
> > > + unsignedreset:1;
> > > + unsignedtimeout:1;
> > > + unsignedcarrier_report:1;
> > > };
> >
> > I'm generally good with this entire patch, but the union usage looks a
> > bit odd, as the members aren't of the same size, which is generally
> > what I've come to expect looking at other code.
>
> Having a union with different sized members is perfectly valid C code.
>
> Just look at the definition of the XEvent in Xlib.h. The "int type;" is
> smaller than everything, and the XAnyEvent is smaller than the other
> event types.
>
> The size of the union will be the size of its largest member.
Yeah, no, I know that it'll work, just that most of the unions I've
actually paid any attention to had members all of the same size. Seemed
like sort of an unwritten rule for in-kernel use. But its probably just
fine.
> > I'd be inclined to
> > simply move duty_cycle out of the union and leave just duration and
> > carrier in it.
>
> That's not necessary and it could be confusing depending on where you
> put duty_cycle.
There's that. But without having code that actually uses duty_cycle in a
meaningful way yet, its hard to say for sure. If carrier and duty_cycle
were only being sent out in their own events, you might actually want a
union of duration, carrier and duty_cycle. Though I suspect we'll probably
want to pass along carrier and duty_cycle at the same time.
--
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: [PATCH 0/6] Large scancode handling
On Wed, Sep 08, 2010 at 05:25:13PM +0200, Jiri Kosina wrote: > On Wed, 8 Sep 2010, Jarod Wilson wrote: > > > > > It'll conflict a little bith with the tivo slide patch I posted > > > > yesterday, > > > > but mostly just minor context changes. I can redo that patch on top of > > > > these changes if that's preferred. > > > > > > I can handle those context changes when merging the patches at linux-next > > > and > > > when merging upstream. We just need to sync in a way that Dmitry send his > > > patch > > > series before mine when sending them to Linus, and I'll take care of > > > fixing the > > > merge conflicts. > > > > Ah, the specific conflicts I was referring here are confined to > > drivers/hid/hid-input.c, and I sent the patch thinking it would go in via > > the hid tree. It *is* for a remote, but its a pure HID device in this > > case. > > Umm, what patch are you talking about please? I don't seem to have > anything from you in my queue. Gah. I suck. Forgot to cc you on it. http://www.spinics.net/lists/linux-input/msg11007.html Can resend and/or bounce you a copy if need be. -- 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: [PATCH 7/8] IR: extend ir_raw_event and do refactoring
On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky wrote:
> 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: DEFINE_IR_RAW_EVENT(ev);
>
> To clean an existing event, use init_ir_raw_event(&ev);
>
> Signed-off-by: Maxim Levitsky
> ---
> drivers/media/IR/ene_ir.c | 4 +-
> drivers/media/IR/ir-core-priv.h | 13 ++-
> drivers/media/IR/ir-jvc-decoder.c | 5 +-
> drivers/media/IR/ir-lirc-codec.c | 78
> +++-
> drivers/media/IR/ir-nec-decoder.c | 5 +-
> drivers/media/IR/ir-raw-event.c | 45 +++-
> 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 | 3 +-
> drivers/media/IR/streamzap.c | 8 ++-
> include/media/ir-core.h | 40 ---
> 12 files changed, 153 insertions(+), 63 deletions(-)
...
> @@ -162,22 +164,48 @@ u32 ir_g_keycode_from_table(struct input_dev
> *input_dev, u32 scancode);
> /* From ir-raw-event.c */
>
> struct ir_raw_event {
> - unsigned pulse:1;
> - unsigned duration:31;
> + union {
> + u32 duration;
> +
> + struct {
> + u32 carrier;
> + u8 duty_cycle;
> + };
> + };
> +
> + unsigned pulse:1;
> + unsigned reset:1;
> + unsigned timeout:1;
> + unsigned carrier_report:1;
> };
I'm generally good with this entire patch, but the union usage looks a
bit odd, as the members aren't of the same size, which is generally
what I've come to expect looking at other code. I'd be inclined to
simply move duty_cycle out of the union and leave just duration and
carrier in it. However, as discussed on irc and upon looking at the
code, we don't actually do anything useful with duty_cycle yet, so
perhaps just cut it out entirely for the moment, and add it later when
its of use.
--
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 0/6] Large scancode handling
On Wed, Sep 08, 2010 at 12:15:06PM -0300, Mauro Carvalho Chehab wrote: > Em 08-09-2010 11:24, Jarod Wilson escreveu: > > On Wed, Sep 08, 2010 at 11:48:50AM +0200, Jiri Kosina wrote: > >> On Wed, 8 Sep 2010, Dmitry Torokhov wrote: > >> > >>> Hi Mauro, > >>> > >>> I guess I better get off my behind and commit the changes to support large > >>> scancodes, or they will not make to 2.6.37 either... There isn't much > >>> changes, except I followed David's suggestion and changed boolean index > >>> field into u8 flags field. Still, please glance it over once again and > >>> shout if you see something you do not like. > >>> > >>> Jiri, how do you want to handle the changes to HID? I could either push > >>> them through my tree together with the first patch or you can push through > >>> yours once the first change hits mainline. > >> > >> I think that there will unlikely be any conflict in .37 merge window in > >> this area (and if there were, I'll sort it out). > >> > >> So please add > >> > >>Acked-by: Jiri Kosina > >> > >> to the hid-input.c bits and feel free to take it through your tree, if it > >> is convenient for you. > > > > It'll conflict a little bith with the tivo slide patch I posted yesterday, > > but mostly just minor context changes. I can redo that patch on top of > > these changes if that's preferred. > > I can handle those context changes when merging the patches at linux-next and > when merging upstream. We just need to sync in a way that Dmitry send his > patch > series before mine when sending them to Linus, and I'll take care of fixing > the > merge conflicts. Ah, the specific conflicts I was referring here are confined to drivers/hid/hid-input.c, and I sent the patch thinking it would go in via the hid tree. It *is* for a remote, but its a pure HID device in this case. -- 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: [PATCH 5/8] IR: extend MCE keymap.
On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky wrote: > These keys are found on remote bundled with > Toshiba Qosmio F50-10q. > > Found and tested by, Sami R > > Signed-off-by: Maxim Levitsky > --- > drivers/media/IR/keymaps/rc-rc6-mce.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) 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 4/8] IR: fix keys beeing stuck down forever.
On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky wrote:
> 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?
Yeah, seen time_is_{before,after}_jiffies use accidentally inverted a
couple of times... Kinda hints that we could use better names and/or
descriptions of the functions, but maybe people just need to read more
carefully (dunno, haven't looked to see what's there for usage
descriptions already)... Anyway.
> Signed-off-by: Maxim Levitsky
> ---
> drivers/media/IR/ir-keytable.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
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 3/8] IR: fix duty cycle capability
On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky wrote: > 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(-) 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 0/6] Large scancode handling
On Wed, Sep 08, 2010 at 12:41:38AM -0700, Dmitry Torokhov wrote:
> Hi Mauro,
>
> I guess I better get off my behind and commit the changes to support large
> scancodes, or they will not make to 2.6.37 either... There isn't much
> changes, except I followed David's suggestion and changed boolean index
> field into u8 flags field. Still, please glance it over once again and
> shout if you see something you do not like.
>
> Jiri, how do you want to handle the changes to HID? I could either push
> them through my tree together with the first patch or you can push through
> yours once the first change hits mainline.
>
> Mauro, the same question goes for media/IR patch.
>
> David, I suppose you still have the winbond remote so you could test
> changes to winbond-cir driver.
This'll be fun. :) David recently posted a patchset that among other
things, ports winbond-cir over to {ir,rc}-core to the tune of ~700 less
lines in winbond-cir.c. It also touches a fair amount of core bits, as
does a patchset posted by Maxim... I suspect this series should probably
go in first though.
> Ville, do you still have the hardware to try our ati_remote2 changes?
If not, I've got the hardware. (Speaking of which, porting ati_remote*
over to {ir,rc}-core is also on the TODO list, albeit with very very
low priority at the moment).
--
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: [PATCH 0/6] Large scancode handling
On Wed, Sep 08, 2010 at 11:48:50AM +0200, Jiri Kosina wrote: > On Wed, 8 Sep 2010, Dmitry Torokhov wrote: > > > Hi Mauro, > > > > I guess I better get off my behind and commit the changes to support large > > scancodes, or they will not make to 2.6.37 either... There isn't much > > changes, except I followed David's suggestion and changed boolean index > > field into u8 flags field. Still, please glance it over once again and > > shout if you see something you do not like. > > > > Jiri, how do you want to handle the changes to HID? I could either push > > them through my tree together with the first patch or you can push through > > yours once the first change hits mainline. > > I think that there will unlikely be any conflict in .37 merge window in > this area (and if there were, I'll sort it out). > > So please add > > Acked-by: Jiri Kosina > > to the hid-input.c bits and feel free to take it through your tree, if it > is convenient for you. It'll conflict a little bith with the tivo slide patch I posted yesterday, but mostly just minor context changes. I can redo that patch on top of these changes if that's preferred. -- 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: [PATCH 1/2] ir-core: centralize sysfs raw decoder enabling/disabling
> [ 601.632580] CR2: CR3: 7b19f000 CR4:
> 06f0
> [ 601.632601] DR0: DR1: DR2:
>
> [ 601.632623] DR3: DR6: 0ff0 DR7:
> 0400
> [ 601.632644] Process cat (pid: 2928, threadinfo 88007bb92000,
> task 88007bcd2dc0)
> [ 601.632675] Stack:
> [ 601.632689] a00f5ee0 88007bb93f48
> 8000
> [ 601.632713] <0> 0246d000 88007c8798a0
> 88007bb93e98 813816e7
> [ 601.632750] <0> 88007bb93e88 8110681e
> 88007bb93e98 88007c8798c0
> [ 601.632797] Call Trace:
> [ 601.632819] [] dev_attr_show+0x27/0x50
> [ 601.632842] [] ? __get_free_pages+0xe/0x50
> [ 601.632864] [] sysfs_read_file+0xd1/0x1c0
> [ 601.632886] [] vfs_read+0xc5/0x190
> [ 601.632906] [] sys_read+0x51/0x90
> [ 601.632928] [] system_call_fastpath+0x16/0x1b
> [ 601.632947] Code: eb 04 90 90 90 90 55 48 89 e5 41 57 41 56 41 55
> 41 54 53 48 83 ec 08 0f 1f 44 00 00 49 89 d4 e8 12 0e 29 e1 48 8b 90
> 90 02 00 00 <44> 8b 0a 45 85 c9 0f 85 af 00 00 00 4c 8b a8 70 02 00
> 00 48 8b
> [ 601.633112] RIP [] show_protocols+0x25/0x120 [ir_core]
> [ 601.633136] RSP
> [ 601.633152] CR2:
> [ 601.633448] ---[ end trace 0dbd0f2ee839a90b ]---
>
> A similar problem exists in store_protocols and makes lircd oops and
> die at startup.
>
> >+enabled = ir_dev->rc_tab.ir_type;
> >+allowed = ir_dev->props->allowed_protos;
> >+} else {
> >+enabled = ir_dev->raw->enabled_protocols;
>
> ir_dev->raw is also null. If I check these pointers before using
> them, and bail out if both are null, then I get a working lircd, but
> of course the file /sys/devices/virtual/rc/rc0/protocols no longer
> does anything. On 2.6.35.4, the system never creates the
> /sys/class/rc/rc0/current_protocol file. Is it the case that the
> 'protocols' file should never appear, because my card can't support
> this feature?
Hm... So protocols is indeed intended for hardware that handles raw IR, as
its a list of raw IR decoders available/enabled/disabled for the receiver.
But some devices that do onboard decoding and deal with scancodes still
need to support changing protocols, as they can be told "decode rc5" or
"decode nec", etc... My memory is currently foggy on how it was exactly
that it was supposed to be donee though. :) (Yet another reason I really
need to poke at the imon driver code again).
--
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: [PATCH 1/5] rc-code: merge and rename ir-core
On Wed, Sep 08, 2010 at 10:42:10AM -0300, Mauro Carvalho Chehab wrote: > Em 07-09-2010 18:51, David Härdeman escreveu: > > This patch merges the files which makes up ir-core and renames the > > resulting module to rc-core. IMHO this makes it much easier to hack > > on the core module since all code is in one file. > > > > This also allows some simplification of ir-core-priv.h as fewer internal > > functions need to be exposed. > > I'm not sure about this patch. Big files tend to be harder to maintain, > as it takes more time to find the right functions inside it. Also, IMO, > it makes sense to keep the raw-event code on a separate file. There's definitely a balance to be struck between file size and file count. Having all the relevant code in one file definitely has its advantage in that its easier to jump around from function to function and trace code paths taken, but I can see the argument for isolating the raw event handling code a bit too, especially if its going to be further expanded, which I believe is likely the case. So I guess I'm on the fence here. :) > Anyway, if we apply this patch right now, it will cause merge conflicts with > the input tree, due to the get/setkeycodebig patches, and with some other > patches that are pending merge/review. The better is to apply such patch > just after the release of 2.6.37-rc1, after having all those conflicts > solved. The imon patch that moves mouse/panel/knob input to its own input device should be possible to take in advance of everything else, more or less, though I need to finish actually testing it out (and should probably make some further imon fixes for issues listed in a kernel.org bugzilla, the number of which escapes me at the moment). -- 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
[GIT PULL REQUEST] IR updates for 2.6.36
Hi Mauro, Please pull the streamzap in-kernel decoding support patch and a trivial mceusb driver patch that just adds two new device IDs in for 2.6.36. The following changes since commit 67ac062a5138ed446a821051fddd798a01478f85: V4L/DVB: Fix regression for BeholdTV Columbus (2010-08-24 10:39:32 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-lirc.git staging Jarod Wilson (2): IR/streamzap: functional in-kernel decoding mceusb: add two new ASUS device IDs drivers/media/IR/Kconfig| 12 + drivers/media/IR/Makefile |1 + drivers/media/IR/ir-core-priv.h |6 + drivers/media/IR/ir-rc5-sz-decoder.c| 153 drivers/media/IR/ir-sysfs.c |1 + drivers/media/IR/keymaps/Makefile |2 +- drivers/media/IR/keymaps/rc-rc5-streamzap.c | 81 -- drivers/media/IR/keymaps/rc-streamzap.c | 82 ++ drivers/media/IR/mceusb.c |4 + drivers/media/IR/streamzap.c| 358 +++ include/media/rc-map.h |5 +- 11 files changed, 356 insertions(+), 349 deletions(-) create mode 100644 drivers/media/IR/ir-rc5-sz-decoder.c delete mode 100644 drivers/media/IR/keymaps/rc-rc5-streamzap.c create mode 100644 drivers/media/IR/keymaps/rc-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
[PATCH] IR/mceusb: add an ASUS device ID
Reported in lirc sf.net tracker
Signed-off-by: Jarod Wilson
---
drivers/media/IR/mceusb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index ac6bb2c..f0b7e42 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -120,6 +120,8 @@ static struct usb_device_id mceusb_dev_table[] = {
{ USB_DEVICE(VENDOR_PHILIPS, 0x0613) },
/* Philips eHome Infrared Transceiver */
{ USB_DEVICE(VENDOR_PHILIPS, 0x0815) },
+ /* Philips/Spinel plus IR transceiver for ASUS */
+ { USB_DEVICE(VENDOR_PHILIPS, 0x2088) },
/* Realtek MCE IR Receiver */
{ USB_DEVICE(VENDOR_REALTEK, 0x0161) },
/* SMK/Toshiba G83C0004D410 */
--
1.7.2.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: [PATCH 0/3] Proposed ir-core (rc-core) changes
On Fri, Aug 27, 2010 at 11:55:47AM -0400, Andy Walls wrote: > Heh. Between "where's the current base?", > 1 hour rebuild times for the > whole kernel, and continual retooling of the IR core stuff, I can't keep up > with the time I have available. > > Mauro did make an announcement a few weeks back. I thought it was the > media.git tree. Yeah, the most recent patch I've done was against media_tree.git, branch staging/v2.6.36. http://git.linuxtv.org/media_tree.git?a=shortlog;h=refs/heads/staging/v2.6.36 I believe there's a slightly updated mceusb.c in there vs. what this patchset was against, and there are also streamzap.c and ene_ir.c in there, ported from lirc to ir-core in there that would also need to be updated for these changes. (Nb: there's a fairly major streamzap.c patch still pending, wouldn't start working on that port until it gets merged.) > David Härdeman wrote: > > >On Thu, August 26, 2010 21:14, Jarod Wilson wrote: > >> On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote: > >>> The following series merges the different files that currently make up > >>> the ir-core module into a single-file rc-core module. > >>> > >>> In addition, the ir_input_dev and ir_dev_props structs are replaced > >>> by a single rc_dev struct with an API similar to that of the input > >>> subsystem. > >>> > >>> This allows the removal of all knowledge of any input devices from the > >>> rc drivers and paves the way for allowing multiple input devices per > >>> rc device in the future. The namespace conversion from ir_* to rc_* > >>> should mostly be done for the drivers with this patchset. > >>> > >>> I have intentionally not signed off on the patches yet since they > >>> haven't > >>> been tested. I'd like your feedback on the general approach before I > >>> spend > >>> the time to properly test the result. > >>> > >>> Also, the imon driver is not converted (and will thus break with this > >>> patchset). The reason is that the imon driver wants to generate mouse > >>> events on the input dev under the control of rc-core. I was hoping that > >>> Jarod would be willing to convert the imon driver to create a separate > >>> input device for sending mouse events to userspace :) > >> > >> Yeah, I could be persuaded to do that. Means that the imon driver, when > >> driving one of the touchscreen devices, will bring up 3 separate input > >> devices, but oh well. (I'd actually considered doing that when porting to > >> ir-core in the first place, but went the lazy route. ;) > > > >That would be good. I'm pretty certain that the split will be necessary > >sooner or later. > > > >>> Comments please... > >> > >> Haven't tried it out at all yet or done more than a quick skim through the > >> patches, but at first glance, I do like the idea of further abstracting > >> away the input layer. I know I tanked a few things the first go 'round, > >> thinking I needed to do both some rc-layer and input-layer setup and/or > >> teardown. It becomes more cut and dry if you don't see anything > >> input-related anywhere at all. > > > >Not to mention we will have a more consistent user experience. For > >example: some of the current hardware drivers are fiddling with the repeat > >values of the input dev...something which should be the same across the > >entire subsystem (you wouldn't expect the repetition rate for the exact > >same remote control to change just because you change the receiver). > > > >Also, it's necessary for any future support of multiple input devices (one > >per physical remote control being one example)...and it gives us more > >flexibility to make changes in rc-core when drivers do not muck around in > >subdevices (input devices that is). > > > >> One thing I did note with the patches is that a lot of bits were altered > >> from ir-foo to rc-foo, but not all of them... If we're going to make the > >> change, why no go whole hog? (Or was it only things relevant to ir > >> specifically right now that didn't get renamed?) > > > >The rule of thumb I followed was to rename stuff that I touched but leave > >unchanged code alone. Renaming the remaining functions can be done in > >later, separate, patches (some of them will be more invasive as file names > >need changing as well). > > > >On a related not
Re: [PATCH 0/3] Proposed ir-core (rc-core) changes
On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote: > The following series merges the different files that currently make up > the ir-core module into a single-file rc-core module. > > In addition, the ir_input_dev and ir_dev_props structs are replaced > by a single rc_dev struct with an API similar to that of the input > subsystem. > > This allows the removal of all knowledge of any input devices from the > rc drivers and paves the way for allowing multiple input devices per > rc device in the future. The namespace conversion from ir_* to rc_* > should mostly be done for the drivers with this patchset. > > I have intentionally not signed off on the patches yet since they haven't > been tested. I'd like your feedback on the general approach before I spend > the time to properly test the result. > > Also, the imon driver is not converted (and will thus break with this > patchset). The reason is that the imon driver wants to generate mouse > events on the input dev under the control of rc-core. I was hoping that > Jarod would be willing to convert the imon driver to create a separate > input device for sending mouse events to userspace :) Yeah, I could be persuaded to do that. Means that the imon driver, when driving one of the touchscreen devices, will bring up 3 separate input devices, but oh well. (I'd actually considered doing that when porting to ir-core in the first place, but went the lazy route. ;) > Comments please... Haven't tried it out at all yet or done more than a quick skim through the patches, but at first glance, I do like the idea of further abstracting away the input layer. I know I tanked a few things the first go 'round, thinking I needed to do both some rc-layer and input-layer setup and/or teardown. It becomes more cut and dry if you don't see anything input-related anywhere at all. One thing I did note with the patches is that a lot of bits were altered from ir-foo to rc-foo, but not all of them... If we're going to make the change, why no go whole hog? (Or was it only things relevant to ir specifically right now that didn't get renamed?) -- 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 16, 2010 at 11:30 PM, Mauro Carvalho Chehab wrote: > Em 16-08-2010 21:14, Jarod Wilson escreveu: > >>> Just one minor nitpick. >>> You could 'use' the original RC5 decoder, but add a knob to it to make >>> it accept 15 bits instead of 14. >>> However, this will require some interface changes. >> >> Well, I think that still falls down if someone, for some reason, wants >> to use both an old RC5 remote and the Streamzap remote at the same >> time. I think a parallel decoder is probably the best situation for >> the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded >> simultaneously. > > One option could be to change rc5 decoder to work with 3 different modes, > controlled by a sysfs node: > 1) just 14 bits code; > 2) just 15 bits code; > 3) both 14 and 15 bits code. > > For (3), it will need a timeout logic for a short period (like 2T), for the > 15th bit. If nothing happens, it will assume it is 14 bits, producing a code > and resetting the finite-state machine. > > By default, it would be working on 14-bits mode for normal RC decoders, and > on 15-bits mode for Streamzap. > > Yet, IMHO, the better is to commit what you have currently. Just my 2 cents. Yeah, I don't doubt that we *could* come up with some way to make them coexist in the same decoder, but I think its probably not worth the effort or added complexity over simply having a separate parallel decoder (which is only loaded by default if the receiver bundled with the funky remote is plugged in). -- 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: Remote that breaks current system
On Mon, Aug 16, 2010 at 4:41 PM, Maxim Levitsky wrote: > On Mon, 2010-08-16 at 00:04 -0400, Jarod Wilson wrote: >> On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus >> wrote: >> ... >> >> So I spent a while beating on things the past few nights for giggles >> >> (and for a sanity break from "vacation" with too many kids...). I >> >> ended up doing a rather large amount of somewhat invasive work to the >> >> streamzap driver itself, but the end result is functional in-kernel >> >> decoding, and lirc userspace decode continues to behave correctly. RFC >> >> patch here: >> >> >> >> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch >> >> >> >> Core changes to streamzap.c itself: >> >> >> >> - had to enable reporting of a long space at the conclusion of each >> >> signal (which is what the lirc driver would do w/timeout_enabled set), >> >> otherwise I kept having issues with key bounce and/or old data being >> >> buffered (i.e., press up, cursor moves up. push down, cursor moves up >> >> then down, press left, it moves down, then left, etc.). Still not >> >> quite sure what the real problem is there, the lirc userspace decoder >> >> has no problems with it either way. >> >> >> >> - removed streamzap's internal delay buffer, as the ir-core kfifo >> >> seems to provide the necessary signal buffering just fine by itself. >> >> Can't see any significant difference in decode performance either >> >> in-kernel or via lirc with it removed, anyway. (Christoph, can you >> >> perhaps expand a bit on why the delay buffer was originally needed/how >> >> to reproduce the problem it was intended to solve? Maybe I'm just not >> >> triggering it yet.) >> > >> > Should be fine. Current lircd with timeout support shouldn't have a >> > problem with that anymore. I was already thinking of suggesting to remove >> > the delay buffer. >> >> Cool, sounds like a plan then, I'll go ahead with it. >> >> >> Other fun stuff to note: >> >> >> >> - currently, loading up an rc5-sz decoder unconditionally, have >> >> considered only auto-loading it from the streamzap driver itself. Its >> >> a copy of the rc5 decoder with relatively minor tweaks to deal with >> >> the extra bit and resulting slightly different bit layout. Might >> >> actually be possible to merge back into the rc5 decoder itself, >> >> haven't really looked into that yet (should be entirely doable if >> >> there's an easy way to figure out early on if we need to grab 14 >> >> bits). >> > >> > There is no way until you see the 14th bit. >> >> Hm. Was afraid of that. I gave it a shot to see if I could make that >> work, pretty shaky results. About 2/3 of the keys get decoded as >> 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't >> match anything in the keytable (and often duplicate one another). So >> it looks like at least for the time being, a separate parallel decoder >> is the way to go. I'm thinking that I like the approach of only >> explicitly loading it from the streamzap driver though. > > Just one minor nitpick. > You could 'use' the original RC5 decoder, but add a knob to it to make > it accept 15 bits instead of 14. > However, this will require some interface changes. Well, I think that still falls down if someone, for some reason, wants to use both an old RC5 remote and the Streamzap remote at the same time. I think a parallel decoder is probably the best situation for the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded simultaneously. -- 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
[PATCH] IR/streamzap: enable functional in-kernel decoding
This patch makes in-kernel decoding with the stock Streamzap PC Remote
work out of the box. There are quite a few things going on in this
patch, all (mostly) related to getting this working:
1) I had to enable reporting of a long space at the end of each signal,
or I had weird buffering and keybounce issues.
2) The keymap has been reworked slightly to match actual decoded values,
the first edition was missing the pre-data bits present in the lirc
config file for this remote.
3) There's a whole new decoder included, specifically for the
not-quite-RC5 15-bit protocol variant used by the Streamzap PC
Remote. The decoder, while usable with other recievers (tested with
an mceusb receiver), will only be loaded by the streamzap driver, as
its likely not of use in almost all other situations. This can be
revisited if/when all keytable loading (and disabling of unneeded
protocol decoder engines) is moved to userspace, but for now, I think
this makes the most sense.
Note that I did try to enable handling the streamzap RC5-ish protocol in
the current RC5 decoder, but there's no particularly easy way to tell if
its 14-bit RC5 or 15-bit Streamzap until we see bit 14, and even then,
in testing an attempted decoder merge, only 2/3 of the keys were
properly recognized as being the 15-bit variant and decoded correctly,
the rest were close enough to compliant with 14-bit that they were
decoded as such (but they have overlap with one another, and thus we
can't just shrug and use the 14-bit decoded values).
Also of note in this patch is the removal of the streamzap driver's
internal delay buffer. Per discussion w/Christoph, it shouldn't be
needed by lirc any longer anyway, and it doesn't seem to make any
difference to the in-kernel decoder engine. That being the case, I'm
yanking it all out, as it greatly simplifies the driver code (net result
is that streamzap.c is now 252 lines less than lirc_streamzap.c was).
Signed-off-by: Jarod Wilson
---
drivers/media/IR/Kconfig| 12 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/ir-core-priv.h |6 +
drivers/media/IR/ir-rc5-sz-decoder.c| 153
drivers/media/IR/ir-sysfs.c |1 +
drivers/media/IR/keymaps/Makefile |2 +-
drivers/media/IR/keymaps/rc-rc5-streamzap.c | 81 --
drivers/media/IR/keymaps/rc-streamzap.c | 82 ++
drivers/media/IR/streamzap.c| 358 +++
include/media/rc-map.h |5 +-
10 files changed, 352 insertions(+), 349 deletions(-)
create mode 100644 drivers/media/IR/ir-rc5-sz-decoder.c
delete mode 100644 drivers/media/IR/keymaps/rc-rc5-streamzap.c
create mode 100644 drivers/media/IR/keymaps/rc-streamzap.c
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index 490c57c..152000d 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -79,6 +79,18 @@ config IR_SONY_DECODER
Enable this option if you have an infrared remote control which
uses the Sony protocol, and you need software decoding support.
+config IR_RC5_SZ_DECODER
+ tristate "Enable IR raw decoder for the RC-5 (streamzap) protocol"
+ depends on IR_CORE
+ select BITREVERSE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-5 (streamzap) protocol,
+ and if the IR is decoded in software. (The Streamzap PC Remote
+ uses an IR protocol that is almost standard RC-5, but not quite,
+ as it uses an additional bit).
+
config IR_LIRC_CODEC
tristate "Enable IR to LIRC bridge"
depends on IR_CORE
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 5367683..953c6c4 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
+obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o
obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index a85a8c7..0ad8ea3 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,6 +76,12 @@ struct ir_raw_event_ctrl {
bool first;
bool toggle;
} jvc;
+ struct rc5_sz_dec {
+ int state;
+ u32 bits;
+ unsigned count;
+ unsigned wanted_bits;
+ } rc5_sz;
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
diff --git a/drivers/media/IR/ir-rc5-sz-decoder.c
b/drivers/media/IR/ir-rc5-sz-decoder.c
new file
Re: Remote that breaks current system
On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus wrote: ... >> So I spent a while beating on things the past few nights for giggles >> (and for a sanity break from "vacation" with too many kids...). I >> ended up doing a rather large amount of somewhat invasive work to the >> streamzap driver itself, but the end result is functional in-kernel >> decoding, and lirc userspace decode continues to behave correctly. RFC >> patch here: >> >> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch >> >> Core changes to streamzap.c itself: >> >> - had to enable reporting of a long space at the conclusion of each >> signal (which is what the lirc driver would do w/timeout_enabled set), >> otherwise I kept having issues with key bounce and/or old data being >> buffered (i.e., press up, cursor moves up. push down, cursor moves up >> then down, press left, it moves down, then left, etc.). Still not >> quite sure what the real problem is there, the lirc userspace decoder >> has no problems with it either way. >> >> - removed streamzap's internal delay buffer, as the ir-core kfifo >> seems to provide the necessary signal buffering just fine by itself. >> Can't see any significant difference in decode performance either >> in-kernel or via lirc with it removed, anyway. (Christoph, can you >> perhaps expand a bit on why the delay buffer was originally needed/how >> to reproduce the problem it was intended to solve? Maybe I'm just not >> triggering it yet.) > > Should be fine. Current lircd with timeout support shouldn't have a > problem with that anymore. I was already thinking of suggesting to remove > the delay buffer. Cool, sounds like a plan then, I'll go ahead with it. >> Other fun stuff to note: >> >> - currently, loading up an rc5-sz decoder unconditionally, have >> considered only auto-loading it from the streamzap driver itself. Its >> a copy of the rc5 decoder with relatively minor tweaks to deal with >> the extra bit and resulting slightly different bit layout. Might >> actually be possible to merge back into the rc5 decoder itself, >> haven't really looked into that yet (should be entirely doable if >> there's an easy way to figure out early on if we need to grab 14 >> bits). > > There is no way until you see the 14th bit. Hm. Was afraid of that. I gave it a shot to see if I could make that work, pretty shaky results. About 2/3 of the keys get decoded as 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't match anything in the keytable (and often duplicate one another). So it looks like at least for the time being, a separate parallel decoder is the way to go. I'm thinking that I like the approach of only explicitly loading it from the streamzap driver though. -- 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: ir-raw-event: null pointer dereference
- Dan Carpenter wrote: > The original code dereferenced ir->raw after freeing it and setting it > to NULL. > > Signed-off-by: Dan Carpenter Acked-by: Jarod Wilson -- 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 4:42 PM, Jon Smirl wrote: > 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: ... >>> > 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. The other thought I had was to not load the engine by default, and only auto-load it from the streamzap driver itself. >> 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. So I spent a while beating on things the past few nights for giggles (and for a sanity break from "vacation" with too many kids...). I ended up doing a rather large amount of somewhat invasive work to the streamzap driver itself, but the end result is functional in-kernel decoding, and lirc userspace decode continues to behave correctly. RFC patch here: http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch Core changes to streamzap.c itself: - had to enable reporting of a long space at the conclusion of each signal (which is what the lirc driver would do w/timeout_enabled set), otherwise I kept having issues with key bounce and/or old data being buffered (i.e., press up, cursor moves up. push down, cursor moves up then down, press left, it moves down, then left, etc.). Still not quite sure what the real problem is there, the lirc userspace decoder has no problems with it either way. - removed streamzap's internal delay buffer, as the ir-core kfifo seems to provide the necessary signal buffering just fine by itself. Can't see any significant difference in decode performance either in-kernel or via lirc with it removed, anyway. (Christoph, can you perhaps expand a bit on why the delay buffer was originally needed/how to reproduce the problem it was intended to solve? Maybe I'm just not triggering it yet.) Other fun stuff to note: - currently, loading up an rc5-sz decoder unconditionally, have considered only auto-loading it from the streamzap driver itself. Its a copy of the rc5 decoder with relatively minor tweaks to deal with the extra bit and resulting slightly different bit layout. Might actually be possible to merge back into the rc5 decoder itself, haven't really looked into that yet (should be entirely doable if there's an easy way to figure out early on if we need to grab 15 bits). - not sure the decoder is 100% correct, but it does get to the same scancodes as the lirc userspace now (with both a streamzap and mceusb receiver). -- 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 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick
On Tue, Aug 3, 2010 at 9:32 AM, Mauro Carvalho Chehab
wrote:
> Em 03-08-2010 10:05, Richard Zidlicky escreveu:
>> Hi,
>>
>>> 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?
>>
>> mine says
>>
>> Aug 3 14:58:10 localhost kernel: [149778.591862] usb 5-5: New USB device
>> found, idVendor=2040, idProduct=5500
>> Aug 3 14:58:10 localhost kernel: [149778.591865] usb 5-5: New USB device
>> strings: Mfr=1, Product=2, SerialNumber=3
>> Aug 3 14:58:10 localhost kernel: [149778.591868] usb 5-5: Product: WinTV
>> MiniStick
>> Aug 3 14:58:10 localhost kernel: [149778.591870] usb 5-5: Manufacturer:
>> Hauppauge Computer Works
>> Aug 3 14:58:10 localhost kernel: [149778.591872] usb 5-5: SerialNumber:
>> f069684c
>>
>> not sure what else to report.
>
> The model number is on a label at the back of the stick (at least, mine have
> it).
>
>> I will compile and try a new kernel tonight.
>>
>> Wondering - is this
>> http://git.sliepen.org/browse?p=inputlirc
>> usefull to feed the input events to LIRC when trying the new driver with a
>> slightly older
>> LIRC based distro?
>
> The in-kernel lirc support need a new version of LIRC since a few ioctls
> numbers were changed,
> to avoid needing to write a code in kernel to handle compatibility between 32
> and 64 bit kernels.
> If you're running a 32 bits kernel, it may work.
Should also be able to skirt around the issue if you don't use the
/dev/lircX interface to get data out of the receiver. For example, one
could use the lircd devinput driver, a la "lircd -H devinput -d
/dev/input/by-id/", and I don't think the
ioctl changes should matter.
--
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
[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
[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 *bu
[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/d
[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: [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
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: [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: 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 "unsubscri
Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver
On Thu, Jul 29, 2010 at 5:28 PM, Jarod Wilson wrote: > On Thu, Jul 29, 2010 at 11:04:47PM +0300, Maxim Levitsky wrote: >> On Thu, 2010-07-29 at 21:35 +0200, Christoph Bartelmus wrote: >> > Hi! >> > >> > Maxim Levitsky "maximlevit...@gmail.com" wrote: >> > [...] >> > >>>>> Could you explain exactly how timeout reports work? >> > [...] >> > >>> So, timeout report is just another sample, with a mark attached, that >> > >>> this is last sample? right? >> > >> >> > >> No, a timeout report is just an additional hint for the decoder that a >> > >> specific amount of time has passed since the last pulse _now_. >> > >> >> > >> [...] >> > >>> In that case, lets do that this way: >> > >>> >> > >>> As soon as timeout is reached, I just send lirc the timeout report. >> > >>> Then next keypress will start with pulse. >> > >> >> > >> When timeout reports are enabled the sequence must be: >> > >> >> > >> where is optional. >> > >> >> > >> lircd will not work when you leave out the space. It must know the exact >> > >> time between the pulses. Some hardware generates timeout reports that >> > >> are >> > >> too short to distinguish between spaces that are so short that the next >> > >> sequence can be interpreted as a repeat or longer spaces which indicate >> > >> that this is a new key press. >> > >> > > Let me give an example to see if I got that right. >> > > >> > > >> > > Suppose we have this sequence of reports from the driver: >> > > >> > > 500 (pulse) >> > > 20 (timeout) >> > > 1 (space) >> > > 500 (pulse) >> > > >> > > >> > > Is that correct that time between first and second pulse is >> > > '10020' ? >> > >> > No, it's 1. The timeout is optional and just a hint to the decoder >> > how much time has passed already since the last pulse. It does not change >> > the meaning of the next space. >> >> its like a carrier report then I guess. >> Its clear to me now. >> >> So, I really don't need to send/support timeout reports because hw >> doesn't support that. >> >> I can however support timeout (LIRC_SET_REC_TIMEOUT) and and use it to >> adjust threshold upon which I stop the hardware, and remember current >> time. >> I can put that in generic function for ene like hardware >> (hw that sends small packs of samples very often) > > So... I presume this means a v3 patchset? And/or, is it worth merging > patches 1, 2, 3, 6 and 7 now, then having you work on top of that? This branch is a as-of-a-few-minutes-ago, up-to-date linuxtv staging/other plus a few outstanding patches and your patches 1, 2, 3, 6 and 7: http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/staging -- 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 0/9 v2] IR: few fixes, additions and ENE driver
On Thu, Jul 29, 2010 at 11:04:47PM +0300, Maxim Levitsky wrote: > On Thu, 2010-07-29 at 21:35 +0200, Christoph Bartelmus wrote: > > Hi! > > > > Maxim Levitsky "maximlevit...@gmail.com" wrote: > > [...] > > >>>>> Could you explain exactly how timeout reports work? > > [...] > > >>> So, timeout report is just another sample, with a mark attached, that > > >>> this is last sample? right? > > >> > > >> No, a timeout report is just an additional hint for the decoder that a > > >> specific amount of time has passed since the last pulse _now_. > > >> > > >> [...] > > >>> In that case, lets do that this way: > > >>> > > >>> As soon as timeout is reached, I just send lirc the timeout report. > > >>> Then next keypress will start with pulse. > > >> > > >> When timeout reports are enabled the sequence must be: > > >> > > >> where is optional. > > >> > > >> lircd will not work when you leave out the space. It must know the exact > > >> time between the pulses. Some hardware generates timeout reports that are > > >> too short to distinguish between spaces that are so short that the next > > >> sequence can be interpreted as a repeat or longer spaces which indicate > > >> that this is a new key press. > > > > > Let me give an example to see if I got that right. > > > > > > > > > Suppose we have this sequence of reports from the driver: > > > > > > 500 (pulse) > > > 20 (timeout) > > > 1 (space) > > > 500 (pulse) > > > > > > > > > Is that correct that time between first and second pulse is > > > '10020' ? > > > > No, it's 1. The timeout is optional and just a hint to the decoder > > how much time has passed already since the last pulse. It does not change > > the meaning of the next space. > > its like a carrier report then I guess. > Its clear to me now. > > So, I really don't need to send/support timeout reports because hw > doesn't support that. > > I can however support timeout (LIRC_SET_REC_TIMEOUT) and and use it to > adjust threshold upon which I stop the hardware, and remember current > time. > I can put that in generic function for ene like hardware > (hw that sends small packs of samples very often) So... I presume this means a v3 patchset? And/or, is it worth merging patches 1, 2, 3, 6 and 7 now, then having you work on top of that? -- 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: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver
On Thu, Jul 29, 2010 at 06:58:00PM +0200, Christoph Bartelmus wrote: > Hi Maxim, > > on 29 Jul 10 at 17:41, Maxim Levitsky wrote: > [...] > >>> Note that I send timeout report with zero value. > >>> I don't think that this value is importaint. > >> > >> This does not sound good. Of course the value is important to userspace > >> and 2 spaces in a row will break decoding. > >> > >> Christoph > > > Could you explain exactly how timeout reports work? > > It all should be documented in the interface description. Jarod probably > can point you where it can be found. There's a start to interface documentation at Documentation/DocBook/v4l/lirc_device_interface.xml, and it does cover timeout report usage. (Side note: I forgot, Mauro asked if we could flesh out that document even further with descriptions of the assorted defines beyond just the ioctls. I'm going to scribble that on my TODO list right now...) -- 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
[PATCH] staging/lirc: fix non-CONFIG_MODULES build horkage
Fix when CONFIG_MODULES is not enabled:
drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of
function 'module_refcount'
drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function
'module_refcount'
drivers/built-in.o: In function `it87_probe':
lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev'
lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev'
drivers/built-in.o: In function `lirc_it87_exit':
lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev'
Its a quick hack and untested beyond building, since I don't have the
hardware, but it should do the trick.
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_it87.c |9 ++---
drivers/staging/lirc/lirc_parallel.c |4 ++--
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lirc/lirc_it87.c b/drivers/staging/lirc/lirc_it87.c
index 781abc3..72f07f1 100644
--- a/drivers/staging/lirc/lirc_it87.c
+++ b/drivers/staging/lirc/lirc_it87.c
@@ -109,6 +109,7 @@ static DECLARE_WAIT_QUEUE_HEAD(lirc_read_queue);
static DEFINE_SPINLOCK(hardware_lock);
static DEFINE_SPINLOCK(dev_lock);
+static bool device_open;
static int rx_buf[RBUF_LEN];
unsigned int rx_tail, rx_head;
@@ -147,10 +148,11 @@ static void drop_port(void);
static int lirc_open(struct inode *inode, struct file *file)
{
spin_lock(&dev_lock);
- if (module_refcount(THIS_MODULE)) {
+ if (device_open) {
spin_unlock(&dev_lock);
return -EBUSY;
}
+ device_open = true;
spin_unlock(&dev_lock);
return 0;
}
@@ -158,6 +160,9 @@ static int lirc_open(struct inode *inode, struct file *file)
static int lirc_close(struct inode *inode, struct file *file)
{
+ spin_lock(&dev_lock);
+ device_open = false;
+ spin_unlock(&dev_lock);
return 0;
}
@@ -363,7 +368,6 @@ static struct lirc_driver driver = {
};
-#ifdef MODULE
static int init_chrdev(void)
{
driver.minor = lirc_register_driver(&driver);
@@ -380,7 +384,6 @@ static void drop_chrdev(void)
{
lirc_unregister_driver(driver.minor);
}
-#endif
/* SECTION: Hardware */
diff --git a/drivers/staging/lirc/lirc_parallel.c
b/drivers/staging/lirc/lirc_parallel.c
index df12e7b..04ce97713 100644
--- a/drivers/staging/lirc/lirc_parallel.c
+++ b/drivers/staging/lirc/lirc_parallel.c
@@ -240,7 +240,7 @@ static void irq_handler(void *blah)
unsigned int level, newlevel;
unsigned int timeout;
- if (!module_refcount(THIS_MODULE))
+ if (!is_open)
return;
if (!is_claimed)
@@ -515,7 +515,7 @@ static long lirc_ioctl(struct file *filep, unsigned int
cmd, unsigned long arg)
static int lirc_open(struct inode *node, struct file *filep)
{
- if (module_refcount(THIS_MODULE) || !lirc_claim())
+ if (is_open || !lirc_claim())
return -EBUSY;
parport_enable_irq(pport);
--
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: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver
On Thu, Jul 29, 2010 at 06:30:28PM +0300, Maxim Levitsky wrote: > On Wed, 2010-07-28 at 23:52 -0400, Jarod Wilson wrote: > > On Thu, Jul 29, 2010 at 02:40:43AM +0300, Maxim Levitsky wrote: > > > Hi, > > > This is second version of the patchset. > > > Hopefully, I didn't forget to address all comments. > > > > > > In addition to comments, I changed helper function that processes samples > > > so it sends last space as soon as timeout is reached. > > > This breaks somewhat lirc, because now it gets 2 spaces in row. > > > However, if it uses timeout reports (which are now fully supported) > > > it will get such report in middle. > > > > > > Note that I send timeout report with zero value. > > > I don't think that this value is importaint. > > > > I just patched the entire series into a branch here and tested, no > > regressions with an mceusb transceiver with in-kernel decode, lirc decode > > or lirc tx. Only issue I had (which I neglected to mention earlier) was > > some pedantic issues w/whitespace. Here's the tree I built and tested: > > > > http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/maxim > > > > 7486d6ae3 addresses all the whitespace/formatting issues I had. Could > > either merge that into your patches, or I can just send it along as an > > additional patch after the fact. In either case, for 1-7 v2: > About whitespace, I usually fix what checkpacth.pl tells me. > Nothing beyond that :-) Yeah, I don't think any of them violate checkpatch.pl's rules, they were more for consistency with the rest of the code being patched. -- 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: linux-next: Tree for July 28 (lirc #2)
On Thu, Jul 29, 2010 at 8:39 AM, Janne Grunau wrote: > On Thu, Jul 29, 2010 at 12:27:01AM -0400, Jarod Wilson wrote: >> On Wed, Jul 28, 2010 at 6:27 PM, Jarod Wilson wrote: >> > On Wed, Jul 28, 2010 at 6:16 PM, Randy Dunlap >> > wrote: >> >> On 07/28/10 15:04, Janne Grunau wrote: >> >>> On Wed, Jul 28, 2010 at 10:24:17AM -0700, Randy Dunlap wrote: >> >>>> On Wed, 28 Jul 2010 16:28:55 +1000 Stephen Rothwell wrote: >> >>>> >> >>>>> Hi all, >> >>>>> >> >>>>> Changes since 20100727: >> >>>> >> >>>> >> >>>> When USB_SUPPORT is not enabled and MEDIA_SUPPORT is not enabled: >> >>>> >> >>> >> >>> following patch should fix it >> >>> >> >>> Janne >> >> >> >> Acked-by: Randy Dunlap >> >> >> >> Thanks. >> > >> > Acked-by: Jarod Wilson >> > >> > Indeed, thanks much, Janne! >> >> D'oh, I should have looked a bit closer... What if instead of making >> all the drivers depend on both LIRC && LIRC_STAGING, LIRC_STAGING just >> depends on LIRC? > > I started adding LIRC to each driver by one. Adding LIRC as LIRC_STAGING > dependency is simpler. See updated patch. > >> And there are a few depends lines with duplicate >> USB's in them and LIRC_IMON should have USB added to it (technically, > > D'oh, I've must have stopped reading after LIRC_STAG... > > fixed and added additional dependencies Yeah, that looks better, thanks! (And this time I looked more carefully). 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: linux-next: Tree for July 28 (lirc #2)
On Wed, Jul 28, 2010 at 6:27 PM, Jarod Wilson wrote: > On Wed, Jul 28, 2010 at 6:16 PM, Randy Dunlap wrote: >> On 07/28/10 15:04, Janne Grunau wrote: >>> On Wed, Jul 28, 2010 at 10:24:17AM -0700, Randy Dunlap wrote: >>>> On Wed, 28 Jul 2010 16:28:55 +1000 Stephen Rothwell wrote: >>>> >>>>> Hi all, >>>>> >>>>> Changes since 20100727: >>>> >>>> >>>> When USB_SUPPORT is not enabled and MEDIA_SUPPORT is not enabled: >>>> >>> >>> following patch should fix it >>> >>> Janne >> >> Acked-by: Randy Dunlap >> >> Thanks. > > Acked-by: Jarod Wilson > > Indeed, thanks much, Janne! D'oh, I should have looked a bit closer... What if instead of making all the drivers depend on both LIRC && LIRC_STAGING, LIRC_STAGING just depends on LIRC? And there are a few depends lines with duplicate USB's in them and LIRC_IMON should have USB added to it (technically, I think ene0100 should also have a PNP, but we already have patches pending that move it from staging to an ir-core driver). -- 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 0/9 v2] IR: few fixes, additions and ENE driver
On Thu, Jul 29, 2010 at 02:40:43AM +0300, Maxim Levitsky wrote: > Hi, > This is second version of the patchset. > Hopefully, I didn't forget to address all comments. > > In addition to comments, I changed helper function that processes samples > so it sends last space as soon as timeout is reached. > This breaks somewhat lirc, because now it gets 2 spaces in row. > However, if it uses timeout reports (which are now fully supported) > it will get such report in middle. > > Note that I send timeout report with zero value. > I don't think that this value is importaint. I just patched the entire series into a branch here and tested, no regressions with an mceusb transceiver with in-kernel decode, lirc decode or lirc tx. Only issue I had (which I neglected to mention earlier) was some pedantic issues w/whitespace. Here's the tree I built and tested: http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/maxim 7486d6ae3 addresses all the whitespace/formatting issues I had. Could either merge that into your patches, or I can just send it along as an additional patch after the fact. In either case, for 1-7 v2: Tested-by: Jarod Wilson I have no ene hardware to actually test with, but it did build. :) For 1-9 v2: Acked-by: Jarod Wilson -- 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: [PATCH] IR/mceusb: remove bad ir_input_dev use
On Tue, Jul 27, 2010 at 10:24 PM, Jarod Wilson wrote:
> The ir_input_dev gets filled in by __ir_input_register, the one
> allocated in mceusb_init_input_dev was being overwritten by the correct
> one shortly after it was initialized (ultimately resulting in a memory
> leak). This bug was inherited from imon.c, and was pointed out to me by
> Maxim Levitsky.
D'oh, there's a minor errorlet in this patch...
> CC: Maxim Levitsky
> Signed-off-by: Jarod Wilson
> ---
> drivers/media/IR/mceusb.c | 15 +--
> 1 files changed, 1 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
> index 78bf7f7..9a7da32 100644
> --- a/drivers/media/IR/mceusb.c
> +++ b/drivers/media/IR/mceusb.c
> @@ -228,7 +228,6 @@ static struct usb_device_id std_tx_mask_list[] = {
> /* data structure for each usb transceiver */
> struct mceusb_dev {
> /* ir-core bits */
> - struct ir_input_dev *irdev;
> struct ir_dev_props *props;
> struct ir_raw_event rawir;
>
> @@ -739,7 +738,7 @@ static void mceusb_dev_recv(struct urb *urb, struct
> pt_regs *regs)
>
> if (ir->send_flags == RECV_FLAG_IN_PROGRESS) {
> ir->send_flags = SEND_FLAG_COMPLETE;
> - dev_dbg(&ir->irdev->dev, "setup answer received %d bytes\n",
> + dev_dbg(&ir->dev, "setup answer received %d bytes\n",
This should be dev_dbg(ir->dev, ... (i.e., without the ampersand).
Mauro, shall I resend this, or can you fix that at commit time?
--
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: linux-next: Tree for July 28 (lirc #2)
On Wed, Jul 28, 2010 at 6:16 PM, Randy Dunlap wrote: > On 07/28/10 15:04, Janne Grunau wrote: >> On Wed, Jul 28, 2010 at 10:24:17AM -0700, Randy Dunlap wrote: >>> On Wed, 28 Jul 2010 16:28:55 +1000 Stephen Rothwell wrote: >>> >>>> Hi all, >>>> >>>> Changes since 20100727: >>> >>> >>> When USB_SUPPORT is not enabled and MEDIA_SUPPORT is not enabled: >>> >> >> following patch should fix it >> >> Janne > > Acked-by: Randy Dunlap > > Thanks. Acked-by: Jarod Wilson Indeed, thanks much, Janne! >> From 7d1cc98c19a6c27dd74a28f04dfe4248a0b335ce Mon Sep 17 00:00:00 2001 >> From: Janne Grunau >> Date: Wed, 28 Jul 2010 23:53:35 +0200 >> Subject: [PATCH 1/2] staging/lirc: fix Kconfig dependencies >> >> Signed-off-by: Janne Grunau >> --- >> drivers/staging/lirc/Kconfig | 28 ++-- >> 1 files changed, 14 insertions(+), 14 deletions(-) >> >> diff --git a/drivers/staging/lirc/Kconfig b/drivers/staging/lirc/Kconfig >> index 968c2ade..3981a4a 100644 >> --- a/drivers/staging/lirc/Kconfig >> +++ b/drivers/staging/lirc/Kconfig >> @@ -13,13 +13,13 @@ if LIRC_STAGING >> >> config LIRC_BT829 >> tristate "BT829 based hardware" >> - depends on LIRC_STAGING >> + depends on LIRC && LIRC_STAGING >> help >> Driver for the IR interface on BT829-based hardware >> >> config LIRC_ENE0100 >> tristate "ENE KB3924/ENE0100 CIR Port Reciever" >> - depends on LIRC_STAGING >> + depends on LIRC && LIRC_STAGING >> help >> This is a driver for CIR port handled by ENE KB3924 embedded >> controller found on some notebooks. >> @@ -27,20 +27,20 @@ config LIRC_ENE0100 >> >> config LIRC_I2C >> tristate "I2C Based IR Receivers" >> - depends on LIRC_STAGING >> + depends on I2C && LIRC && LIRC_STAGING >> help >> Driver for I2C-based IR receivers, such as those commonly >> found onboard Hauppauge PVR-150/250/350 video capture cards >> >> config LIRC_IGORPLUGUSB >> tristate "Igor Cesko's USB IR Receiver" >> - depends on LIRC_STAGING && USB >> + depends on USB && LIRC && LIRC_STAGING && USB >> help >> Driver for Igor Cesko's USB IR Receiver >> >> config LIRC_IMON >> tristate "Legacy SoundGraph iMON Receiver and Display" >> - depends on LIRC_STAGING >> + depends on LIRC && LIRC_STAGING >> help >> Driver for the original SoundGraph iMON IR Receiver and Display >> >> @@ -48,31 +48,31 @@ config LIRC_IMON >> >> config LIRC_IT87 >> tristate "ITE IT87XX CIR Port Receiver" >> - depends on LIRC_STAGING >> + depends on LIRC && LIRC_STAGING >> help >> Driver for the ITE IT87xx IR Receiver >> >> config LIRC_ITE8709 >> tristate "ITE8709 CIR Port Receiver" >> - depends on LIRC_STAGING && PNP >> + depends on LIRC && LIRC_STAGING && PNP >> help >> Driver for the ITE8709 IR Receiver >> >> config LIRC_PARALLEL >> tristate "Homebrew Parallel Port Receiver" >> - depends on LIRC_STAGING && !SMP >> + depends on LIRC && LIRC_STAGING && !SMP >> help >> Driver for Homebrew Parallel Port Receivers >> >> config LIRC_SASEM >> tristate "Sasem USB IR Remote" >> - depends on LIRC_STAGING >> + depends on USB && LIRC && LIRC_STAGING >> help >> Driver for the Sasem OnAir Remocon-V or Dign HV5 HTPC IR/VFD Module >> >> config LIRC_SERIAL >> tristate "Homebrew Serial Port Receiver" >> - depends on LIRC_STAGING >> + depends on LIRC && LIRC_STAGING >> help >> Driver for Homebrew Serial Port Receivers >> >> @@ -85,25 +85,25 @@ config LIRC_SERIAL_TRANSMITTER >> >> config LIRC_SIR >> tristate "Built-in SIR IrDA port" >> - depends on LIRC_STAGING >> + depends on LIRC && LIRC_STAGING >> help >> Driver for the SIR IrDA port >> >> config LIRC_STREAMZAP >> tristate "Streamzap PC Receiver" >> - depends on LIRC_STAGING >> + depends on USB && LIRC && LIRC_STAGING >> help >> Driver for the Streamzap PC Receiver >> >> config LIRC_TTUSBIR >> tristate "Technotrend USB IR Receiver" >> - depends on LIRC_STAGING && USB >> + depends on USB && LIRC && LIRC_STAGING && USB >> help >> Driver for the Technotrend USB IR Receiver >> >> config LIRC_ZILOG >> tristate "Zilog/Hauppauge IR Transmitter" >> - depends on LIRC_STAGING >> + depends on I2C && LIRC && LIRC_STAGING >> help >> Driver for the Zilog/Hauppauge IR Transmitter, found on >> PVR-150/500, HVR-1200/1250/1700/1800, HD-PVR and other cards > > > -- > ~Randy > *** Remember to use Documentation/SubmitChecklist when testing your code *** > -- 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 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
On Wed, Jul 28, 2010 at 01:46:27PM -0400, Jarod Wilson wrote: > On Wed, Jul 28, 2010 at 06:14:06PM +0300, Maxim Levitsky wrote: > > Signed-off-by: Maxim Levitsky > > With the caveat of requiring an improved changelog, per Mauro's suggestion: > > Acked-by: Jarod Wilson > > I suspect at least some of this code may be of use to the streamzap driver > as well (which I started looking at porting last night, despite my > insistence that I was going to work on lirc_zilog first...). One other note: idle looks like it can happily exist as a bool instead of as an int, no? -- 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: [PATCH 5/9] IR: extend interfaces to support more device settings
On Wed, Jul 28, 2010 at 06:14:07PM +0300, Maxim Levitsky wrote: > Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MODE > (LIRC_SET_LEARN_MODE will start carrier reports if possible, and > tune receiver to wide band mode) > > This IOCTL isn't yet used by lirc, so this won't break userspace. Plus, once lirc 0.8.7 is released (Real Soon Now), we'll start working on lirc 0.9.0 with the express goal of it being built against lirc.h as provided by the kernel. These all generally look good and sane to me, and I'll make use of the LEARN_MODE bits for mceusb after something along these lines is committed. I like the simplifications Mauro suggested for the ioctl handling. In addition to those, there's a bit of whitespace damage in lirc.h that I'd like to see cleaned up for v2. -- 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: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 03:08:13PM -0300, Mauro Carvalho Chehab wrote: > Em 28-07-2010 14:04, Jon Smirl escreveu: > > On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab > > wrote: > >> Em 28-07-2010 11:41, Jon Smirl escreveu: > >> > >>> It's possible to build a Linux IR decoder engine that can be loaded > >>> with the old LIRC config files. > >> > >> I think it is a good idea to have a decoder that works with such files > >> anyway. > > > > The recorder should use the Linux IR system to record the data. It > > would confusing to mix the systems. Users need to be really sure that > > the standard protocol decoders don't understand their protocol before > > resorting to this. Any one in this situation should post their > > recorded data so we can check for driver implementation errors. > > > > An example: if you use irrecord on Sony remotes lirc always records > > them in raw mode. The true problem here is that irrecord doesn't > > understand that Sony remotes mix different flavors of the Sony > > protocol on a single remote. This leads you to think that the Sony > > protocol engine is broken when it really isn't. It's the irrecord tool > > that is broken. The kernel IR system will decode these remotes > > correctly without resorting to raw mode. > > A decoder like that should be a last-resort decoder, only in the > cases where there's no other option. > > >> There are some good reasons for that, as it would allow in-kernel support > >> for > >> protocols that may have some patent restrictions on a few countries that > >> allow > >> patents on software. > > > > Are there any IR protocols less than 20 (or 17) years old? > > Yes. This protocol is brand new: > https://www.smkusa.com/usa/technologies/qp/ > > And several new devices are starting to accept it. The US patent appears to have been filed in 1995 and granted in 1997, so "brand new" is relative. ;) http://www.freepatentsonline.com/5640160.html We do have a few more years of being encumbered by it here in the US though. :( -- 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: [PATCH 6/9] IR: actually allow not to compile keymaps in..
On Wed, Jul 28, 2010 at 06:14:08PM +0300, Maxim Levitsky wrote: > Currntly, ir device registration fails if keymap requested by driver is not > found... > Fix that by always compiling in the empty keymap, and using it as a failback > > Signed-off-by: Maxim Levitsky I like this one, useful improvement, I think. We even get meaningful output logged as well -- get_rc_map() will let us know the initially requested keymap failed to load, and then will let us know whether or not the empty keymap loaded. Acked-by: Jarod Wilson -- 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: [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
On Wed, Jul 28, 2010 at 06:14:06PM +0300, Maxim Levitsky wrote: > Signed-off-by: Maxim Levitsky With the caveat of requiring an improved changelog, per Mauro's suggestion: Acked-by: Jarod Wilson I suspect at least some of this code may be of use to the streamzap driver as well (which I started looking at porting last night, despite my insistence that I was going to work on lirc_zilog first...). -- 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: [PATCH 3/9] IR: replace spinlock with mutex.
On Wed, Jul 28, 2010 at 07:32:58PM +0300, Maxim Levitsky wrote: > On Wed, 2010-07-28 at 13:03 -0300, Mauro Carvalho Chehab wrote: > > Em 28-07-2010 12:14, Maxim Levitsky escreveu: > > > Some handlers (lirc for example) allocates memory on initialization, > > > doing so in atomic context is cumbersome. > > > Fixes warning about sleeping function in atomic context. > > > > You should not replace it by a mutex, as the decoding code may happen during > > IRQ time on several drivers. > I though decoding code is run by a work queue? Yeah, it is. (INIT_WORK(&ir->raw->rx_work, ir_raw_event_work); in ir_raw_event_register). > I don't see any atomic codepath here... I think the ir_raw_event_store variants are the only things that are run from an interrupt context, and none of them touch ir_raw_handler_lock. That lock is advertised as being for the protection of ir_raw_handler_list and ir_raw_client_list, which are primarily manipulated by register/unregister functions, and we just lock them when doing actual IR decode work (via said work queue) so we don't feed raw IR somewhere that we shouldn't. I think Maxim is correct here, we should be okay with changing this to a mutex, unless I'm missing something 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: [PATCH 2/9] IR: minor fixes:
On Wed, Jul 28, 2010 at 06:14:04PM +0300, Maxim Levitsky wrote: > * lirc: Don't propagate reset event to userspace > * lirc: Remove strange logic from lirc that would make first sample always be > pulse > * Make TO_US macro actualy print what it should. > > Signed-off-by: Maxim Levitsky For the ir-lirc-codec-specific bits: Acked-by: Jarod Wilson I'm inclined to pull them into my tree now, and the IR_dprintk and TO_US portions can be handled separately. -- 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: [PATCH 8/9] IR: Add ENE input driver.
On Wed, Jul 28, 2010 at 08:13:35PM +0300, Maxim Levitsky wrote: > On Wed, 2010-07-28 at 14:10 -0300, Mauro Carvalho Chehab wrote: > > Em 28-07-2010 12:14, Maxim Levitsky escreveu: > > > Signed-off-by: Maxim Levitsky > > > > Please, instead of patch 9/9, do a patch moving ENE driver from staging > > into > > drivers/media/IR, and then a patch porting it into rc-core. This will allow > > us > > to better understand what were done to convert it to rc-core, being an > > example > > for others that may work on porting the other drivers to rc-core. > > The version in staging is outdated. D'oh, sorry about that. > Should I first update it, and then move? Yeah, that sounds sane to me. -- 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: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 10:41:27AM -0400, Jon Smirl wrote: > On Wed, Jul 28, 2010 at 10:24 AM, Maxim Levitsky ... > > You are right that my remote has JVC protocol. (at least I am sure now > > it hasn't NEC, because repeat looks differently). > > > > My remote now actually partially works with JVC decoder, it decodes > > every other keypress. > > > > Still, no repeat is supported. > > It probably isn't implemented yet. Jarod has been focusing more on > getting the basic decoders to work. More specifically, getting the basic decoders to work with very specific hardware -- i.e., the mceusb transceivers, and primarily focused only on RC-6(A) decode w/the mceusb bundled remotes. That, and getting the lirc bridge driver working for both rx and tx. Basically, my plan of attack has been to get enough bits in place that we have a "reference implementation", if you will, of a driver that supports all in-kernel decoders and the lirc interface, complete with the ability to do tx[*], and from there, then we can really dig into the in-kernel decoders and/or work on porting additional drivers to ir-core. I'm more focused on porting additional drivers to ir-core at the moment than I am on testing all of the protocol decoders right now. [*] we still don't have an ir-core "native" tx method, but tx on the mceusb works quite well using the lirc bridge plugin -- 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: Can I expect in-kernel decoding to work out of box?
On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl wrote: > On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky > wrote: >> On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote: >>> Hi, >>> >>> I ported my ene driver to in-kernel decoding. >>> It isn't yet ready to be released, but in few days it will be. >>> >>> Now, knowing about wonders of in-kernel decoding, I try to use it, but >>> it just doesn't work. >>> >>> Mind you that lircd works with this remote. >>> (I attach my lircd.conf) >>> >>> Here is the output of mode2 for a single keypress: > > 8850 4350 525 1575 525 1575 > 525 450 525 450 525 450 > 525 450 525 1575 525 450 > 525 1575 525 450 525 1575 > 525 450 525 450 525 1575 > 525 450 525 450 525 23625 > > That decodes as: > 1100 0010 1010 0100 > > In the NEC protocol the second word is supposed to be the inverse of > the first word and it isn't. The timing is too short for NEC protocol > too. > > Valid NEC... > 1100 0011 1010 0101 > > Maybe JVC protocol but it is longer than normal. > > The JVC decoder was unable to get started decoding it. I don't think > the JVC decoder has been tested much. Take a look at it and see why it > couldn't get out of state 0. Personally, I haven't really tried much of anything but RC-6(A) and RC-5 while working on mceusb, so they're the only ones I can really vouch for myself at the moment. It seems that I don't have many remotes that aren't an RC-x variant, outside of universals, which I have yet to get around to programming for various other modes to test any of the protocol decoders. I assume that David Hardeman already did that much before submitting each of the ir protocol decoders with his name one them (which were, if I'm not mistaken, based at least partially on Jon's earlier work), but its entirely possible there are slight variants of each that aren't handled properly just yet. That right there is one of the major reasons I saw for writing the lirc bridge driver plugin in the first place -- the lirc userspace decoder has been around for a LOT longer, and thus is likely to know how to handle more widely varying IR signals. -- 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
[PATCH] IR/mceusb: remove bad ir_input_dev use
The ir_input_dev gets filled in by __ir_input_register, the one
allocated in mceusb_init_input_dev was being overwritten by the correct
one shortly after it was initialized (ultimately resulting in a memory
leak). This bug was inherited from imon.c, and was pointed out to me by
Maxim Levitsky.
CC: Maxim Levitsky
Signed-off-by: Jarod Wilson
---
drivers/media/IR/mceusb.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 78bf7f7..9a7da32 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -228,7 +228,6 @@ static struct usb_device_id std_tx_mask_list[] = {
/* data structure for each usb transceiver */
struct mceusb_dev {
/* ir-core bits */
- struct ir_input_dev *irdev;
struct ir_dev_props *props;
struct ir_raw_event rawir;
@@ -739,7 +738,7 @@ static void mceusb_dev_recv(struct urb *urb, struct pt_regs
*regs)
if (ir->send_flags == RECV_FLAG_IN_PROGRESS) {
ir->send_flags = SEND_FLAG_COMPLETE;
- dev_dbg(&ir->irdev->dev, "setup answer received %d bytes\n",
+ dev_dbg(&ir->dev, "setup answer received %d bytes\n",
buf_len);
}
@@ -861,7 +860,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
{
struct input_dev *idev;
struct ir_dev_props *props;
- struct ir_input_dev *irdev;
struct device *dev = ir->dev;
int ret = -ENODEV;
@@ -878,12 +876,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
goto props_alloc_failed;
}
- irdev = kzalloc(sizeof(struct ir_input_dev), GFP_KERNEL);
- if (!irdev) {
- dev_err(dev, "remote ir input dev allocation failed\n");
- goto ir_dev_alloc_failed;
- }
-
snprintf(ir->name, sizeof(ir->name), "Media Center Ed. eHome "
"Infrared Remote Transceiver (%04x:%04x)",
le16_to_cpu(ir->usbdev->descriptor.idVendor),
@@ -902,9 +894,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
props->tx_ir = mceusb_tx_ir;
ir->props = props;
- ir->irdev = irdev;
-
- input_set_drvdata(idev, irdev);
ret = ir_input_register(idev, RC_MAP_RC6_MCE, props, DRIVER_NAME);
if (ret < 0) {
@@ -915,8 +904,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
return idev;
irdev_failed:
- kfree(irdev);
-ir_dev_alloc_failed:
kfree(props);
props_alloc_failed:
input_free_device(idev);
--
1.7.1.1
--
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
[PATCH] IR/imon: remove bad ir_input_dev use
The ir_input_dev gets filled in by __ir_input_register, the one
allocated in imon_init_idev was being overwritten by the correct one
shortly after it was initialized (ultimately resulting in a memory
leak). Additionally, there was an ill-advised memcpy into that
extraneous ir_input_dev which gets fixed by this.
Ill-advised memcpy pointed out by Dmitry Torokhov, bad usage of
ir_input_dev pointed out by Maxim Levitsky (in mceusb.c, which copied the
bug from here).
CC: Dmitry Torokhov
CC: Maxim Levitsky
Signed-off-by: Jarod Wilson
---
drivers/media/IR/imon.c | 15 ---
1 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index 08dff8c..433dca6 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -87,7 +87,6 @@ static ssize_t lcd_write(struct file *file, const char *buf,
struct imon_context {
struct device *dev;
struct ir_dev_props *props;
- struct ir_input_dev *ir;
/* Newer devices have two interfaces */
struct usb_device *usbdev_intf0;
struct usb_device *usbdev_intf1;
@@ -1656,7 +1655,6 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
{
struct input_dev *idev;
struct ir_dev_props *props;
- struct ir_input_dev *ir;
int ret, i;
idev = input_allocate_device();
@@ -1671,12 +1669,6 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
goto props_alloc_failed;
}
- ir = kzalloc(sizeof(struct ir_input_dev), GFP_KERNEL);
- if (!ir) {
- dev_err(ictx->dev, "remote ir input dev allocation failed\n");
- goto ir_dev_alloc_failed;
- }
-
snprintf(ictx->name_idev, sizeof(ictx->name_idev),
"iMON Remote (%04x:%04x)", ictx->vendor, ictx->product);
idev->name = ictx->name_idev;
@@ -1706,14 +1698,9 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
props->change_protocol = imon_ir_change_protocol;
ictx->props = props;
- ictx->ir = ir;
- memcpy(&ir->dev, ictx->dev, sizeof(struct device));
-
usb_to_input_id(ictx->usbdev_intf0, &idev->id);
idev->dev.parent = ictx->dev;
- input_set_drvdata(idev, ir);
-
ret = ir_input_register(idev, RC_MAP_IMON_PAD, props, MOD_NAME);
if (ret < 0) {
dev_err(ictx->dev, "remote input dev register failed\n");
@@ -1723,8 +1710,6 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
return idev;
idev_register_failed:
- kfree(ir);
-ir_dev_alloc_failed:
kfree(props);
props_alloc_failed:
input_free_device(idev);
--
1.7.1.1
--
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: [PATCH 0/15] STAGING: add lirc device drivers
On Tue, Jul 27, 2010 at 12:51:50PM -0700, Greg KH wrote: > On Tue, Jul 27, 2010 at 04:33:32PM -0300, Mauro Carvalho Chehab wrote: > > Em 27-07-2010 15:24, Jarod Wilson escreveu: > > > On Tue, Jul 27, 2010 at 09:09:56AM -0700, Greg KH wrote: > > >> On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: > > >>> Em 26-07-2010 20:25, Jarod Wilson escreveu: > > >> > > >> Hm, Jarod, you forgot to cc: the staging maintainer, so I missed these > > >> :) > > > > > > D'oh, sorry, yeah, realized that about 10 minutes after I sent everything. > > > Figured I'd ping you if you hadn't said anything about 'em in a day or > > > three. > > > > > >>> Greg, > > >>> > > >>> It is probably simpler to merge those files via my tree, as they depend > > >>> on some changes scheduled for 2.6.36. > > >>> > > >>> Would it be ok for you if I merge them from my tree? > > >> > > >> No objection from me for them to go through your tree. > > > > Ok, thanks. I'll merge the patches on my tree. > > > > >> > > >> Do you want me to handle the cleanup and other fixes after they go into > > >> the tree, or do you want to also handle them as well (either is fine > > >> with me.) > > > > > > Note that I've got a git tree I've been maintaining the lirc drivers in > > > for a while, so whomever is ultimately the gateway, I can also stage > > > cleanups there -- I'll certainly be pushing any cleanups I do on the lirc > > > drivers there prior to sending along for upstream, or else I'm liable to > > > lose track of them... :) > > > > > > http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git > > > > > > > Well, maybe the easiest way would be if I handle the first merge, to be > > sure that > > they'll reach linux-next and 2.6.36 at the right time, avoiding conflicts > > with some > > core changes. After the merge, Jerod can handle it via his own tree. > > Well, Jerod needs to send me the patches for inclusion in linux-next and > Linus's tree from his tree as I will need to coordinate them after the > initial merge from Mauro happens. Not a problem, I can do that. With luck, most of them will be "remove this driver from drivers/staging/lirc/ and add its replacement ir-core driver over in drivers/media/IR/, where Greg doesn't have to worry about it (as much) any longer". :) -- 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: [PATCH 0/15] STAGING: add lirc device drivers
On Tue, Jul 27, 2010 at 09:09:56AM -0700, Greg KH wrote: > On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: > > Em 26-07-2010 20:25, Jarod Wilson escreveu: > > Hm, Jarod, you forgot to cc: the staging maintainer, so I missed these > :) D'oh, sorry, yeah, realized that about 10 minutes after I sent everything. Figured I'd ping you if you hadn't said anything about 'em in a day or three. > > Greg, > > > > It is probably simpler to merge those files via my tree, as they depend > > on some changes scheduled for 2.6.36. > > > > Would it be ok for you if I merge them from my tree? > > No objection from me for them to go through your tree. > > Do you want me to handle the cleanup and other fixes after they go into > the tree, or do you want to also handle them as well (either is fine > with me.) Note that I've got a git tree I've been maintaining the lirc drivers in for a while, so whomever is ultimately the gateway, I can also stage cleanups there -- I'll certainly be pushing any cleanups I do on the lirc drivers there prior to sending along for upstream, or else I'm liable to lose track of them... :) http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git -- 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: [PATCH 0/15] STAGING: add lirc device drivers
On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: > Em 26-07-2010 20:25, Jarod Wilson escreveu: > > This patch series adds the remaining lirc_foo device drivers to the staging > > tree. > > drivers/staging/lirc/TODO |8 + ^^^ > Hi Jarod, > > Please add a TODO file at staging/lirc, describing what's needed for > the drivers to move to the IR branch. See above. :) It could use some further fleshing out though, particularly, some "known issues that must be fixed in this specific driver" type things. > Greg, > > It is probably simpler to merge those files via my tree, as they depend > on some changes scheduled for 2.6.36. The patches were created against yesterday's linux-next tree, so I'd assumed they could go in via staging for 2.6.36, but... > Would it be ok for you if I merge them from my tree? ...it certainly doesn't matter to me if they go in this way instead. -- 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
[PATCH 15/15] staging/lirc: wire up Kconfig and Makefile bits
Make the bits under staging/lirc/ buildable, and add a TODO note. Signed-off-by: Jarod Wilson --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/lirc/Kconfig | 110 + drivers/staging/lirc/Makefile | 19 +++ drivers/staging/lirc/TODO |8 +++ 5 files changed, 140 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/lirc/Kconfig create mode 100644 drivers/staging/lirc/Makefile create mode 100644 drivers/staging/lirc/TODO diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 9fc196d..fad88fb 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -155,5 +155,7 @@ source "drivers/staging/tidspbridge/Kconfig" source "drivers/staging/quickstart/Kconfig" +source "drivers/staging/lirc/Kconfig" + endif # !STAGING_EXCLUDE_BUILD endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 26942aa..27bb127 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -58,3 +58,4 @@ obj-$(CONFIG_EASYCAP) += easycap/ obj-$(CONFIG_SOLO6X10) += solo6x10/ obj-$(CONFIG_TIDSPBRIDGE) += tidspbridge/ obj-$(CONFIG_ACPI_QUICKSTART) += quickstart/ +obj-$(CONFIG_LIRC_STAGING) += lirc/ diff --git a/drivers/staging/lirc/Kconfig b/drivers/staging/lirc/Kconfig new file mode 100644 index 000..968c2ad --- /dev/null +++ b/drivers/staging/lirc/Kconfig @@ -0,0 +1,110 @@ +# +# LIRC driver(s) configuration +# +menuconfig LIRC_STAGING + bool "Linux Infrared Remote Control IR receiver/transmitter drivers" + help + Say Y here, and all supported Linux Infrared Remote Control IR and + RF receiver and transmitter drivers will be displayed. When paired + with a remote control and the lirc daemon, the receiver drivers + allow control of your Linux system via remote control. + +if LIRC_STAGING + +config LIRC_BT829 +tristate "BT829 based hardware" + depends on LIRC_STAGING + help + Driver for the IR interface on BT829-based hardware + +config LIRC_ENE0100 + tristate "ENE KB3924/ENE0100 CIR Port Reciever" + depends on LIRC_STAGING + help + This is a driver for CIR port handled by ENE KB3924 embedded + controller found on some notebooks. + It appears on PNP list as ENE0100. + +config LIRC_I2C + tristate "I2C Based IR Receivers" + depends on LIRC_STAGING + help + Driver for I2C-based IR receivers, such as those commonly + found onboard Hauppauge PVR-150/250/350 video capture cards + +config LIRC_IGORPLUGUSB + tristate "Igor Cesko's USB IR Receiver" + depends on LIRC_STAGING && USB + help + Driver for Igor Cesko's USB IR Receiver + +config LIRC_IMON + tristate "Legacy SoundGraph iMON Receiver and Display" + depends on LIRC_STAGING + help + Driver for the original SoundGraph iMON IR Receiver and Display + + Current generation iMON devices use the input layer imon driver. + +config LIRC_IT87 + tristate "ITE IT87XX CIR Port Receiver" + depends on LIRC_STAGING + help + Driver for the ITE IT87xx IR Receiver + +config LIRC_ITE8709 + tristate "ITE8709 CIR Port Receiver" + depends on LIRC_STAGING && PNP + help + Driver for the ITE8709 IR Receiver + +config LIRC_PARALLEL + tristate "Homebrew Parallel Port Receiver" + depends on LIRC_STAGING && !SMP + help + Driver for Homebrew Parallel Port Receivers + +config LIRC_SASEM + tristate "Sasem USB IR Remote" + depends on LIRC_STAGING + help + Driver for the Sasem OnAir Remocon-V or Dign HV5 HTPC IR/VFD Module + +config LIRC_SERIAL + tristate "Homebrew Serial Port Receiver" + depends on LIRC_STAGING + help + Driver for Homebrew Serial Port Receivers + +config LIRC_SERIAL_TRANSMITTER + bool "Serial Port Transmitter" + default y + depends on LIRC_SERIAL + help + Serial Port Transmitter support + +config LIRC_SIR + tristate "Built-in SIR IrDA port" + depends on LIRC_STAGING + help + Driver for the SIR IrDA port + +config LIRC_STREAMZAP + tristate "Streamzap PC Receiver" + depends on LIRC_STAGING + help + Driver for the Streamzap PC Receiver + +config LIRC_TTUSBIR + tristate "Technotrend USB IR Receiver" + depends on LIRC_STAGING && USB + help + Driver for the Technotrend USB IR Receiver + +config LIRC_ZILOG + tristate "Zilog/Hauppauge IR Transmitter" + depends on LIRC_STAGING + help + Driver for the Zilog
[PATCH 14/15] staging/lirc: add lirc_zilog driver
Commonly found on several Hauppauge video capture devices.
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_zilog.c | 1387 +
1 files changed, 1387 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_zilog.c
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
new file mode 100644
index 000..1b013bf
--- /dev/null
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -0,0 +1,1387 @@
+/*
+ * i2c IR lirc driver for devices with zilog IR processors
+ *
+ * Copyright (c) 2000 Gerd Knorr
+ * modified for PixelView (BT878P+W/FM) by
+ * Michal Kochanowicz
+ * Christoph Bartelmus
+ * modified for KNC ONE TV Station/Anubis Typhoon TView Tuner by
+ * Ulrich Mueller
+ * modified for Asus TV-Box and Creative/VisionTek BreakOut-Box by
+ * Stefan Jahn
+ * modified for inclusion into kernel sources by
+ * Jerome Brock
+ * modified for Leadtek Winfast PVR2000 by
+ * Thomas Reitmayr (treitm...@yahoo.com)
+ * modified for Hauppauge PVR-150 IR TX device by
+ * Mark Weaver
+ * changed name from lirc_pvr150 to lirc_zilog, works on more than pvr-150
+ * Jarod Wilson
+ *
+ * parts are cut&pasted from the lirc_i2c.c driver
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+struct IR {
+ struct lirc_driver l;
+
+ /* Device info */
+ struct mutex ir_lock;
+ int open;
+
+ /* RX device */
+ struct i2c_client c_rx;
+ int have_rx;
+
+ /* RX device buffer & lock */
+ struct lirc_buffer buf;
+ struct mutex buf_lock;
+
+ /* RX polling thread data */
+ struct completion *t_notify;
+ struct completion *t_notify2;
+ int shutdown;
+ struct task_struct *task;
+
+ /* RX read data */
+ unsigned char b[3];
+
+ /* TX device */
+ struct i2c_client c_tx;
+ int need_boot;
+ int have_tx;
+};
+
+/* Minor -> data mapping */
+static struct IR *ir_devices[MAX_IRCTL_DEVICES];
+
+/* Block size for IR transmitter */
+#define TX_BLOCK_SIZE 99
+
+/* Hauppauge IR transmitter data */
+struct tx_data_struct {
+ /* Boot block */
+ unsigned char *boot_data;
+
+ /* Start of binary data block */
+ unsigned char *datap;
+
+ /* End of binary data block */
+ unsigned char *endp;
+
+ /* Number of installed codesets */
+ unsigned int num_code_sets;
+
+ /* Pointers to codesets */
+ unsigned char **code_sets;
+
+ /* Global fixed data template */
+ int fixed[TX_BLOCK_SIZE];
+};
+
+static struct tx_data_struct *tx_data;
+static struct mutex tx_data_lock;
+
+#define zilog_notify(s, args...) printk(KERN_NOTICE KBUILD_MODNAME ": " s, \
+ ## args)
+#define zilog_error(s, args...) printk(KERN_ERR KBUILD_MODNAME ": " s, ## args)
+
+#define ZILOG_HAUPPAUGE_IR_RX_NAME "Zilog/Hauppauge IR RX"
+#define ZILOG_HAUPPAUGE_IR_TX_NAME "Zilog/Hauppauge IR TX"
+
+/* module parameters */
+static int debug; /* debug output */
+static int disable_rx; /* disable RX device */
+static int disable_tx; /* disable TX device */
+static int minor = -1; /* minor number */
+
+#define dprintk(fmt, args...) \
+ do {\
+ if (debug) \
+ printk(KERN_DEBUG KBUILD_MODNAME ": " fmt, \
+## args); \
+ } while (0)
+
+static int add_to_buf(struct IR *ir)
+{
+ __u16 code;
+ unsigned char codes[2];
+ unsigned char keybuf[6];
+ int got_data = 0;
+ int ret;
+ int failures = 0;
+ unsigned char sendbuf[1] = { 0 };
+
+ if (lirc_buffer_full(&ir->buf)) {
+ dprintk("buffer overflow\n");
+ return -EOVERFLOW;
+ }
+
+ /*
+
[PATCH 13/15] staging/lirc: add lirc_ttusbir driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_ttusbir.c | 397 +++
1 files changed, 397 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_ttusbir.c
diff --git a/drivers/staging/lirc/lirc_ttusbir.c
b/drivers/staging/lirc/lirc_ttusbir.c
new file mode 100644
index 000..1f1da47
--- /dev/null
+++ b/drivers/staging/lirc/lirc_ttusbir.c
@@ -0,0 +1,397 @@
+/*
+ * lirc_ttusbir.c
+ *
+ * lirc_ttusbir - LIRC device driver for the TechnoTrend USB IR Receiver
+ *
+ * Copyright (C) 2007 Stefan Macher
+ *
+ * This LIRC driver provides access to the TechnoTrend USB IR Receiver.
+ * The receiver delivers the IR signal as raw sampled true/false data in
+ * isochronous USB packets each of size 128 byte.
+ * Currently the driver reduces the sampling rate by factor of 8 as this
+ * is still more than enough to decode RC-5 - others should be analyzed.
+ * But the driver does not rely on RC-5 it should be able to decode every
+ * IR signal that is not too fast.
+ */
+
+/*
+ * 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
+#include
+
+#include
+#include
+
+MODULE_DESCRIPTION("TechnoTrend USB IR device driver for LIRC");
+MODULE_AUTHOR("Stefan Macher (st_maker-l...@yahoo.de)");
+MODULE_LICENSE("GPL");
+
+/* #define DEBUG */
+#ifdef DEBUG
+#define DPRINTK printk
+#else
+#define DPRINTK(_x_, a...)
+#endif
+
+/* function declarations */
+static int probe(struct usb_interface *intf, const struct usb_device_id *id);
+static void disconnect(struct usb_interface *intf);
+static void urb_complete(struct urb *urb);
+static int set_use_inc(void *data);
+static void set_use_dec(void *data);
+
+static int num_urbs = 2;
+module_param(num_urbs, int, S_IRUGO);
+MODULE_PARM_DESC(num_urbs,
+"Number of URBs in queue. Try to increase to 4 in case "
+"of problems (default: 2; minimum: 2)");
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_id_table[] = {
+ /* TechnoTrend USB IR Receiver */
+ { USB_DEVICE(0x0B48, 0x2003) },
+ /* Terminating entry */
+ { }
+};
+MODULE_DEVICE_TABLE(usb, device_id_table);
+
+/* USB driver definition */
+static struct usb_driver usb_driver = {
+ .name = "TTUSBIR",
+ .id_table = &(device_id_table[0]),
+ .probe = probe,
+ .disconnect = disconnect,
+};
+
+/* USB device definition */
+struct ttusbir_device {
+ struct usb_driver *usb_driver;
+ struct usb_device *udev;
+ struct usb_interface *interf;
+ struct usb_class_driver class_driver;
+ unsigned int ifnum; /* Interface number to use */
+ unsigned int alt_setting; /* alternate setting to use */
+ unsigned int endpoint; /* Endpoint to use */
+ struct urb **urb; /* num_urb URB pointers*/
+ char **buffer; /* 128 byte buffer for each URB */
+ struct lirc_buffer rbuf; /* Buffer towards LIRC */
+ struct lirc_driver driver;
+ int minor;
+ int last_pulse; /* remembers if last received byte was pulse or space */
+ int last_num; /* remembers how many last bytes appeared */
+ int opened;
+};
+
+/*** LIRC specific functions ***/
+static int set_use_inc(void *data)
+{
+ int i, retval;
+ struct ttusbir_device *ttusbir = data;
+
+ DPRINTK("Sending first URBs\n");
+ /* @TODO Do I need to check if I am already opened */
+ ttusbir->opened = 1;
+
+ for (i = 0; i < num_urbs; i++) {
+ retval = usb_submit_urb(ttusbir->urb[i], GFP_KERNEL);
+ if (retval) {
+ err("%s: usb_submit_urb failed on urb %d",
+ __func__, i);
+ return retval;
+ }
+ }
+ return 0;
+}
+
+static void set_use_dec(void *data)
+{
+ struct ttusbir_device *ttusbir = data;
+
+ DPRINTK("Device closed\n");
+
+ ttusbir->opened = 0;
+}
+
+/*** USB specific functions ***/
+
+/*
+ * This mapping table is used to do a very simple filtering of the
+ * input signal.
+ * For a value with at least 4 bits set it returns 0xFF otherwise
[PATCH 12/15] staging/lirc: add lirc_streamzap driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_streamzap.c | 821 +
1 files changed, 821 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_streamzap.c
diff --git a/drivers/staging/lirc/lirc_streamzap.c
b/drivers/staging/lirc/lirc_streamzap.c
new file mode 100644
index 000..5b46ac4
--- /dev/null
+++ b/drivers/staging/lirc/lirc_streamzap.c
@@ -0,0 +1,821 @@
+/*
+ * Streamzap Remote Control driver
+ *
+ * Copyright (c) 2005 Christoph Bartelmus
+ *
+ * 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.
+ *
+ * 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
+#include
+#include
+#include
+
+#include
+#include
+
+#define DRIVER_VERSION "1.28"
+#define DRIVER_NAME"lirc_streamzap"
+#define DRIVER_DESC"Streamzap Remote Control driver"
+
+static int debug;
+
+#define USB_STREAMZAP_VENDOR_ID0x0e9c
+#define USB_STREAMZAP_PRODUCT_ID 0x
+
+/* Use our own dbg macro */
+#define dprintk(fmt, args...) \
+ do {\
+ if (debug) \
+ printk(KERN_DEBUG DRIVER_NAME "[%d]: " \
+ fmt "\n", ## args); \
+ } while (0)
+
+/* 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 STREAMZAP_BUF_LEN 128
+
+enum StreamzapDecoderState {
+ PulseSpace,
+ FullPulse,
+ FullSpace,
+ IgnorePulse
+};
+
+/* Structure to hold all of our device specific stuff
+ *
+ * some remarks regarding locking:
+ * theoretically this struct can be accessed from three threads:
+ *
+ * - from lirc_dev through set_use_inc/set_use_dec
+ *
+ * - from the USB layer throuh probe/disconnect/irq
+ *
+ * Careful placement of lirc_register_driver/lirc_unregister_driver
+ * calls will prevent conflicts. lirc_dev makes sure that
+ * set_use_inc/set_use_dec are not being executed and will not be
+ * called after lirc_unregister_driver returns.
+ *
+ * - by the timer callback
+ *
+ * The timer is only running when the device is connected and the
+ * LIRC device is open. Making sure the timer is deleted by
+ * set_use_dec will make conflicts impossible.
+ */
+struct usb_streamzap {
+
+ /* usb */
+ /* save off the usb device pointer */
+ struct usb_device *udev;
+ /* the interface for this device */
+ struct usb_interface*interface;
+
+ /* buffer & dma */
+ unsigned char *buf_in;
+ dma_addr_t dma_in;
+ unsigned intbuf_in_len;
+
+ struct usb_endpoint_descriptor *endpoint;
+
+ /* IRQ */
+ struct urb *urb_in;
+
+ /* lirc */
+ struct lirc_driver *driver;
+ struct lirc_buffer *delay_buf;
+
+ /* timer used to support delay buffering */
+ struct timer_list delay_timer;
+ int timer_running;
+ spinlock_t timer_lock;
+
+ /* tracks whether we are currently receiving some signal */
+ int idle;
+ /* sum of signal lengths received since signal start */
+ unsign
[PATCH 11/15] staging/lirc: add lirc_sir driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_sir.c | 1282 +++
1 files changed, 1282 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_sir.c
diff --git a/drivers/staging/lirc/lirc_sir.c b/drivers/staging/lirc/lirc_sir.c
new file mode 100644
index 000..97146d1
--- /dev/null
+++ b/drivers/staging/lirc/lirc_sir.c
@@ -0,0 +1,1282 @@
+/*
+ * LIRC SIR driver, (C) 2000 Milan Pikula
+ *
+ * lirc_sir - Device driver for use with SIR (serial infra red)
+ * mode of IrDA on many notebooks.
+ *
+ * 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
+ *
+ *
+ * 2000/09/16 Frank Przybylski :
+ * added timeout and relaxed pulse detection, removed gap bug
+ *
+ * 2000/12/15 Christoph Bartelmus :
+ * added support for Tekram Irmate 210 (sending does not work yet,
+ * kind of disappointing that nobody was able to implement that
+ * before),
+ * major clean-up
+ *
+ * 2001/02/27 Christoph Bartelmus :
+ * added support for StrongARM SA1100 embedded microprocessor
+ * parts cut'n'pasted from sa1100_ir.c (C) 2000 Russell King
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef LIRC_ON_SA1100
+#include
+#ifdef CONFIG_SA1100_COLLIE
+#include
+#include
+#endif
+#endif
+
+#include
+
+#include
+#include
+
+/* SECTION: Definitions */
+
+/*** Tekram dongle ***/
+#ifdef LIRC_SIR_TEKRAM
+/* stolen from kernel source */
+/* definitions for Tekram dongle */
+#define TEKRAM_115200 0x00
+#define TEKRAM_57600 0x01
+#define TEKRAM_38400 0x02
+#define TEKRAM_19200 0x03
+#define TEKRAM_9600 0x04
+#define TEKRAM_2400 0x08
+
+#define TEKRAM_PW 0x10 /* Pulse select bit */
+
+/* 10bit * 1s/115200bit in milliseconds = 87ms*/
+#define TIME_CONST (1000ul/115200ul)
+
+#endif
+
+#ifdef LIRC_SIR_ACTISYS_ACT200L
+static void init_act200(void);
+#elif defined(LIRC_SIR_ACTISYS_ACT220L)
+static void init_act220(void);
+#endif
+
+/*** SA1100 ***/
+#ifdef LIRC_ON_SA1100
+struct sa1100_ser2_registers {
+ /* HSSP control register */
+ unsigned char hscr0;
+ /* UART registers */
+ unsigned char utcr0;
+ unsigned char utcr1;
+ unsigned char utcr2;
+ unsigned char utcr3;
+ unsigned char utcr4;
+ unsigned char utdr;
+ unsigned char utsr0;
+ unsigned char utsr1;
+} sr;
+
+static int irq = IRQ_Ser2ICP;
+
+#define LIRC_ON_SA1100_TRANSMITTER_LATENCY 0
+
+/* pulse/space ratio of 50/50 */
+static unsigned long pulse_width = (13-LIRC_ON_SA1100_TRANSMITTER_LATENCY);
+/* 100/freq-pulse_width */
+static unsigned long space_width = (13-LIRC_ON_SA1100_TRANSMITTER_LATENCY);
+static unsigned int freq = 38000; /* modulation frequency */
+static unsigned int duty_cycle = 50; /* duty cycle of 50% */
+
+#endif
+
+#define RBUF_LEN 1024
+#define WBUF_LEN 1024
+
+#define LIRC_DRIVER_NAME "lirc_sir"
+
+#define PULSE '['
+
+#ifndef LIRC_SIR_TEKRAM
+/* 9bit * 1s/115200bit in milli seconds = 78.125ms*/
+#define TIME_CONST (900ul/115200ul)
+#endif
+
+
+/* timeout for sequences in jiffies (=5/100s), must be longer than TIME_CONST
*/
+#define SIR_TIMEOUT(HZ*5/100)
+
+#ifndef LIRC_ON_SA1100
+#ifndef LIRC_IRQ
+#define LIRC_IRQ 4
+#endif
+#ifndef LIRC_PORT
+/* for external dongles, default to com1 */
+#if defined(LIRC_SIR_ACTISYS_ACT200L) || \
+defined(LIRC_SIR_ACTISYS_ACT220L) || \
+defined(LIRC_SIR_TEKRAM)
+#define LIRC_PORT 0x3f8
+#else
+/* onboard sir ports are typically com3 */
+#define LIRC_PORT 0x3e8
+#endif
+#endif
+
+static int io = LIRC_PORT;
+static int irq = LIRC_IRQ;
+static int threshold = 3;
+#endif
+
+static DEFINE_SPINLOCK(timer_lock);
+static struct timer_list timerlist;
+/* time of last signal change detected */
+static struct timeval last_tv = {0, 0};
+/* time of last UART data ready interrupt */
+static struct timeval last_intr_tv = {0, 0};
+static int last_value;
+
+static DECLARE_WAIT_QUEUE_HEAD(lirc_read_queue);
+
+static DEFINE_SPINLOCK(hardware_lock);
+
+static int rx_buf[RBUF_LEN];
+static unsigned int rx_tail, rx_head;
+
+static int deb
[PATCH 10/15] staging/lirc: add lirc_serial driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_serial.c | 1313
1 files changed, 1313 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_serial.c
diff --git a/drivers/staging/lirc/lirc_serial.c
b/drivers/staging/lirc/lirc_serial.c
new file mode 100644
index 000..d2ea3f0
--- /dev/null
+++ b/drivers/staging/lirc/lirc_serial.c
@@ -0,0 +1,1313 @@
+/*
+ * lirc_serial.c
+ *
+ * lirc_serial - Device driver that records pulse- and pause-lengths
+ *(space-lengths) between DDCD event on a serial port.
+ *
+ * Copyright (C) 1996,97 Ralph Metzler
+ * Copyright (C) 1998 Trent Piepho
+ * Copyright (C) 1998 Ben Pfaff
+ * Copyright (C) 1999 Christoph Bartelmus
+ * Copyright (C) 2007 Andrei Tanas (suspend/resume support)
+ * 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
+ *
+ */
+
+/*
+ * Steve's changes to improve transmission fidelity:
+ * - for systems with the rdtsc instruction and the clock counter, a
+ * send_pule that times the pulses directly using the counter.
+ * This means that the LIRC_SERIAL_TRANSMITTER_LATENCY fudge is
+ * not needed. Measurement shows very stable waveform, even where
+ * PCI activity slows the access to the UART, which trips up other
+ * versions.
+ * - For other system, non-integer-microsecond pulse/space lengths,
+ * done using fixed point binary. So, much more accurate carrier
+ * frequency.
+ * - fine tuned transmitter latency, taking advantage of fractional
+ * microseconds in previous change
+ * - Fixed bug in the way transmitter latency was accounted for by
+ * tuning the pulse lengths down - the send_pulse routine ignored
+ * this overhead as it timed the overall pulse length - so the
+ * pulse frequency was right but overall pulse length was too
+ * long. Fixed by accounting for latency on each pulse/space
+ * iteration.
+ *
+ * Steve Davies July 2001
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_LIRC_SERIAL_NSLU2
+#include
+#endif
+/* From Intel IXP42X Developer's Manual (#252480-005): */
+/* ftp://download.intel.com/design/network/manuals/25248005.pdf */
+#define UART_IE_IXP42X_UUE 0x40 /* IXP42X UART Unit enable */
+#define UART_IE_IXP42X_RTOIE 0x10 /* IXP42X Receiver Data Timeout int.enable */
+
+#include
+#include
+
+#define LIRC_DRIVER_NAME "lirc_serial"
+
+struct lirc_serial {
+ int signal_pin;
+ int signal_pin_change;
+ u8 on;
+ u8 off;
+ long (*send_pulse)(unsigned long length);
+ void (*send_space)(long length);
+ int features;
+ spinlock_t lock;
+};
+
+#define LIRC_HOMEBREW 0
+#define LIRC_IRDEO 1
+#define LIRC_IRDEO_REMOTE 2
+#define LIRC_ANIMAX3
+#define LIRC_IGOR 4
+#define LIRC_NSLU2 5
+
+/*** module parameters ***/
+static int type;
+static int io;
+static int irq;
+static int iommap;
+static int ioshift;
+static int softcarrier = 1;
+static int share_irq;
+static int debug;
+static int sense = -1; /* -1 = auto, 0 = active high, 1 = active low */
+static int txsense;/* 0 = active high, 1 = active low */
+
+#define dprintk(fmt, args...) \
+ do {\
+ if (debug) \
+ printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \
+ fmt, ## args); \
+ } while (0)
+
+/* forward declarations */
+static long send_pulse_irdeo(unsigned long length);
+static long send_pulse_homebrew(unsigned long length);
+static void send_space_irdeo(long length);
+static void send_space_homebrew(long length);
+
+static struct lirc_serial hardware[] = {
+ [LIRC_HOMEBREW] = {
+ .signal_pin= UART_MSR_DCD,
+ .signal_pin_change = UART_MSR_DDCD,
+ .on = (UART_MCR_RTS | UART_MCR_OUT2 | UART_MCR_DTR),
+ .off = (UART_MCR_RTS | UART_MCR_OUT2
[PATCH 09/15] staging/lirc: add lirc_sasem driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_sasem.c | 933 +
1 files changed, 933 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_sasem.c
diff --git a/drivers/staging/lirc/lirc_sasem.c
b/drivers/staging/lirc/lirc_sasem.c
new file mode 100644
index 000..9e516a1
--- /dev/null
+++ b/drivers/staging/lirc/lirc_sasem.c
@@ -0,0 +1,933 @@
+/*
+ * lirc_sasem.c - USB remote support for LIRC
+ * Version 0.5
+ *
+ * Copyright (C) 2004-2005 Oliver Stabel
+ * Tim Davies
+ *
+ * This driver was derived from:
+ * Venky Raju
+ * "lirc_imon - "LIRC/VFD driver for Ahanix/Soundgraph IMON IR/VFD"
+ * Paul Miller 's 2003-2004
+ * "lirc_atiusb - USB remote support for LIRC"
+ * Culver Consulting Services 's 2003
+ * "Sasem OnAir VFD/IR USB driver"
+ *
+ *
+ * NOTE - The LCDproc iMon driver should work with this module. More info at
+ * http://www.frogstorm.info/sasem
+ */
+
+/*
+ * 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
+#include
+
+#include
+#include
+
+
+#define MOD_AUTHOR "Oliver Stabel , " \
+ "Tim Davies "
+#define MOD_DESC "USB Driver for Sasem Remote Controller V1.1"
+#define MOD_NAME "lirc_sasem"
+#define MOD_VERSION"0.5"
+
+#define VFD_MINOR_BASE 144 /* Same as LCD */
+#define DEVICE_NAME"lcd%d"
+
+#define BUF_CHUNK_SIZE 8
+#define BUF_SIZE 128
+
+#define IOCTL_LCD_CONTRAST 1
+
+/*** P R O T O T Y P E S ***/
+
+/* USB Callback prototypes */
+static int sasem_probe(struct usb_interface *interface,
+ const struct usb_device_id *id);
+static void sasem_disconnect(struct usb_interface *interface);
+static void usb_rx_callback(struct urb *urb);
+static void usb_tx_callback(struct urb *urb);
+
+/* VFD file_operations function prototypes */
+static int vfd_open(struct inode *inode, struct file *file);
+static long vfd_ioctl(struct file *file, unsigned cmd, unsigned long arg);
+static int vfd_close(struct inode *inode, struct file *file);
+static ssize_t vfd_write(struct file *file, const char *buf,
+ size_t n_bytes, loff_t *pos);
+
+/* LIRC driver function prototypes */
+static int ir_open(void *data);
+static void ir_close(void *data);
+
+/* Driver init/exit prototypes */
+static int __init sasem_init(void);
+static void __exit sasem_exit(void);
+
+/*** G L O B A L S ***/
+#define SASEM_DATA_BUF_SZ 32
+
+struct sasem_context {
+
+ struct usb_device *dev;
+ int vfd_isopen; /* VFD port has been opened */
+ unsigned int vfd_contrast; /* VFD contrast*/
+ int ir_isopen; /* IR port has been opened */
+ int dev_present;/* USB device presence */
+ struct mutex ctx_lock; /* to lock this object */
+ wait_queue_head_t remove_ok;/* For unexpected USB disconnects */
+
+ struct lirc_driver *driver;
+ struct usb_endpoint_descriptor *rx_endpoint;
+ struct usb_endpoint_descriptor *tx_endpoint;
+ struct urb *rx_urb;
+ struct urb *tx_urb;
+ unsigned char usb_rx_buf[8];
+ unsigned char usb_tx_buf[8];
+
+ struct tx_t {
+ unsigned char data_buf[SASEM_DATA_BUF_SZ]; /* user data buffer
*/
+ struct completion finished; /* wait for write to finish */
+ atomic_t busy; /* write in progress*/
+ int status; /* status of tx completion */
+ } tx;
+
+ /* for dealing with repeat codes (wish there was a toggle bit!) */
+ struct timeval presstime;
+ char lastcode[8];
+ int codesaved;
+};
+
+/* VFD file operations */
+static struct file_operations vfd_fops = {
+ .owner = THIS_MODULE,
+ .open = &vfd_open,
+ .write = &vfd_write,
+ .unlocked_ioctl = &vfd_ioctl,
+ .release= &vfd_close,
+};
+
+/* USB Device ID for Sasem USB Control Board */
+stati
[PATCH 08/15] staging/lirc: add lirc_parallel driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_parallel.c | 705 ++
drivers/staging/lirc/lirc_parallel.h | 26 ++
2 files changed, 731 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_parallel.c
create mode 100644 drivers/staging/lirc/lirc_parallel.h
diff --git a/drivers/staging/lirc/lirc_parallel.c
b/drivers/staging/lirc/lirc_parallel.c
new file mode 100644
index 000..df12e7b
--- /dev/null
+++ b/drivers/staging/lirc/lirc_parallel.c
@@ -0,0 +1,705 @@
+/*
+ * lirc_parallel.c
+ *
+ * lirc_parallel - device driver for infra-red signal receiving and
+ * transmitting unit built by the author
+ *
+ * Copyright (C) 1998 Christoph Bartelmus
+ *
+ * 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
+ *
+ */
+
+/*** Includes ***/
+
+#ifdef CONFIG_SMP
+#error "--- Sorry, this driver is not SMP safe. ---"
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include "lirc_parallel.h"
+
+#define LIRC_DRIVER_NAME "lirc_parallel"
+
+#ifndef LIRC_IRQ
+#define LIRC_IRQ 7
+#endif
+#ifndef LIRC_PORT
+#define LIRC_PORT 0x378
+#endif
+#ifndef LIRC_TIMER
+#define LIRC_TIMER 65536
+#endif
+
+/*** Global Variables ***/
+
+static int debug;
+static int check_pselecd;
+
+unsigned int irq = LIRC_IRQ;
+unsigned int io = LIRC_PORT;
+#ifdef LIRC_TIMER
+unsigned int timer;
+unsigned int default_timer = LIRC_TIMER;
+#endif
+
+#define RBUF_SIZE (256) /* this must be a power of 2 larger than 1 */
+
+static int rbuf[RBUF_SIZE];
+
+DECLARE_WAIT_QUEUE_HEAD(lirc_wait);
+
+unsigned int rptr;
+unsigned int wptr;
+unsigned int lost_irqs;
+int is_open;
+
+struct parport *pport;
+struct pardevice *ppdevice;
+int is_claimed;
+
+unsigned int tx_mask = 1;
+
+/*** Internal Functions ***/
+
+static unsigned int in(int offset)
+{
+ switch (offset) {
+ case LIRC_LP_BASE:
+ return parport_read_data(pport);
+ case LIRC_LP_STATUS:
+ return parport_read_status(pport);
+ case LIRC_LP_CONTROL:
+ return parport_read_control(pport);
+ }
+ return 0; /* make compiler happy */
+}
+
+static void out(int offset, int value)
+{
+ switch (offset) {
+ case LIRC_LP_BASE:
+ parport_write_data(pport, value);
+ break;
+ case LIRC_LP_CONTROL:
+ parport_write_control(pport, value);
+ break;
+ case LIRC_LP_STATUS:
+ printk(KERN_INFO "%s: attempt to write to status register\n",
+ LIRC_DRIVER_NAME);
+ break;
+ }
+}
+
+static unsigned int lirc_get_timer(void)
+{
+ return in(LIRC_PORT_TIMER) & LIRC_PORT_TIMER_BIT;
+}
+
+static unsigned int lirc_get_signal(void)
+{
+ return in(LIRC_PORT_SIGNAL) & LIRC_PORT_SIGNAL_BIT;
+}
+
+static void lirc_on(void)
+{
+ out(LIRC_PORT_DATA, tx_mask);
+}
+
+static void lirc_off(void)
+{
+ out(LIRC_PORT_DATA, 0);
+}
+
+static unsigned int init_lirc_timer(void)
+{
+ struct timeval tv, now;
+ unsigned int level, newlevel, timeelapsed, newtimer;
+ int count = 0;
+
+ do_gettimeofday(&tv);
+ tv.tv_sec++; /* wait max. 1 sec. */
+ level = lirc_get_timer();
+ do {
+ newlevel = lirc_get_timer();
+ if (level == 0 && newlevel != 0)
+ count++;
+ level = newlevel;
+ do_gettimeofday(&now);
+ } while (count < 1000 && (now.tv_sec < tv.tv_sec
+|| (now.tv_sec == tv.tv_sec
+&& now.tv_usec < tv.tv_usec)));
+
+ timeelapsed = ((now.tv_sec + 1 - tv.tv_sec)*100
++ (now.tv_usec - tv.tv_usec));
+ if (count >= 1000 && timeelapsed > 0) {
+ if (default_timer == 0) {
+ /* autodetect timer */
+ newtimer = (100*count)/timeelapsed;
+ printk(KERN_INFO "%s: %u Hz timer dete
[PATCH 07/15] staging/lirc: add lirc_ite8709 driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_ite8709.c | 542 +++
1 files changed, 542 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_ite8709.c
diff --git a/drivers/staging/lirc/lirc_ite8709.c
b/drivers/staging/lirc/lirc_ite8709.c
new file mode 100644
index 000..9352f45
--- /dev/null
+++ b/drivers/staging/lirc/lirc_ite8709.c
@@ -0,0 +1,542 @@
+/*
+ * LIRC driver for ITE8709 CIR port
+ *
+ * Copyright (C) 2008 Grégory Lardière
+ *
+ * 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
+
+#include
+#include
+
+#define LIRC_DRIVER_NAME "lirc_ite8709"
+
+#define BUF_CHUNK_SIZE sizeof(int)
+#define BUF_SIZE (128*BUF_CHUNK_SIZE)
+
+/*
+ * The ITE8709 device seems to be the combination of IT8512 superIO chip and
+ * a specific firmware running on the IT8512's embedded micro-controller.
+ * In addition of the embedded micro-controller, the IT8512 chip contains a
+ * CIR module and several other modules. A few modules are directly accessible
+ * by the host CPU, but most of them are only accessible by the
+ * micro-controller. The CIR module is only accessible by the micro-controller.
+ * The battery-backed SRAM module is accessible by the host CPU and the
+ * micro-controller. So one of the MC's firmware role is to act as a bridge
+ * between the host CPU and the CIR module. The firmware implements a kind of
+ * communication protocol using the SRAM module as a shared memory. The IT8512
+ * specification is publicly available on ITE's web site, but the communication
+ * protocol is not, so it was reverse-engineered.
+ */
+
+/* ITE8709 Registers addresses and values (reverse-engineered) */
+#define ITE8709_MODE 0x1a
+#define ITE8709_REG_ADR0x1b
+#define ITE8709_REG_VAL0x1c
+#define ITE8709_IIR0x1e /* Interrupt identification register */
+#define ITE8709_RFSR 0x1f /* Receiver FIFO status register */
+#define ITE8709_FIFO_START 0x20
+
+#define ITE8709_MODE_READY 0X00
+#define ITE8709_MODE_WRITE 0X01
+#define ITE8709_MODE_READ 0X02
+#define ITE8709_IIR_RDAI 0x02 /* Receiver data available interrupt */
+#define ITE8709_IIR_RFOI 0x04 /* Receiver FIFO overrun interrupt */
+#define ITE8709_RFSR_MASK 0x3f /* FIFO byte count mask */
+
+/*
+ * IT8512 CIR-module registers addresses and values
+ * (from IT8512 E/F specification v0.4.1)
+ */
+#define IT8512_REG_MSTCR 0x01 /* Master control register */
+#define IT8512_REG_IER 0x02 /* Interrupt enable register */
+#define IT8512_REG_CFR 0x04 /* Carrier frequency register */
+#define IT8512_REG_RCR 0x05 /* Receive control register */
+#define IT8512_REG_BDLR0x08 /* Baud rate divisor low byte
register */
+#define IT8512_REG_BDHR0x09 /* Baud rate divisor high byte
register */
+
+#define IT8512_MSTCR_RESET 0x01 /* Reset registers to default value */
+#define IT8512_MSTCR_FIFOCLR 0x02 /* Clear FIFO */
+#define IT8512_MSTCR_FIFOTL_7 0x04 /* FIFO threshold level : 7 */
+#define IT8512_MSTCR_FIFOTL_25 0x0c /* FIFO threshold level : 25 */
+#define IT8512_IER_RDAIE 0x02 /* Enable data interrupt request */
+#define IT8512_IER_RFOIE 0x04 /* Enable FIFO overrun interrupt req */
+#define IT8512_IER_IEC 0x80 /* Enable interrupt request */
+#define IT8512_CFR_CF_36KHZ0x09 /* Carrier freq : low speed, 36kHz */
+#define IT8512_RCR_RXDCR_1 0x01 /* Demodulation carrier range : 1 */
+#define IT8512_RCR_RXACT 0x08 /* Receiver active */
+#define IT8512_RCR_RXEN0x80 /* Receiver enable */
+#define IT8512_BDR_6 6 /* Baud rate divisor : 6 */
+
+/* Actual values used by this driver */
+#define CFG_FIFOTL IT8512_MSTCR_FIFOTL_25
+#define CFG_CR_FREQIT8512_CFR_CF_36KHZ
+#define CFG_DCRIT8512_RCR_RXDCR_1
+#define CFG_BDRIT8512_BDR_6
+#define CFG_TIMEOUT10 /* Rearm interrupt when a space is > 100 ms */
+
+static int debug;
+
+struct ite8709_device {
+ int use_count;
+ int io;
+ int irq;
+ spinlock_t hardware_lock;
+ unsigned long long
[PATCH 06/15] staging/lirc: add lirc_it87 driver
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_it87.c | 1019 ++
drivers/staging/lirc/lirc_it87.h | 116 +
2 files changed, 1135 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_it87.c
create mode 100644 drivers/staging/lirc/lirc_it87.h
diff --git a/drivers/staging/lirc/lirc_it87.c b/drivers/staging/lirc/lirc_it87.c
new file mode 100644
index 000..781abc3
--- /dev/null
+++ b/drivers/staging/lirc/lirc_it87.c
@@ -0,0 +1,1019 @@
+/*
+ * LIRC driver for ITE IT8712/IT8705 CIR port
+ *
+ * Copyright (C) 2001 Hans-Gunter Lutke Uphues
+ *
+ * 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
+ *
+ * ITE IT8705 and IT8712(not tested) and IT8720 CIR-port support for lirc based
+ * via cut and paste from lirc_sir.c (C) 2000 Milan Pikula
+ *
+ * Attention: Sendmode only tested with debugging logs
+ *
+ * 2001/02/27 Christoph Bartelmus :
+ * reimplemented read function
+ * 2005/06/05 Andrew Calkin implemented support for Asus Digimatrix,
+ * based on work of the following member of the Outertrack Digimatrix
+ * Forum: Art103
+ * 2009/12/24 James Edwards implemeted support
+ * for ITE8704/ITE8718, on my machine, the DSDT reports 8704, but the
+ * chip identifies as 18.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include "lirc_it87.h"
+
+#ifdef LIRC_IT87_DIGIMATRIX
+static int digimatrix = 1;
+static int it87_freq = 36; /* kHz */
+static int irq = 9;
+#else
+static int digimatrix;
+static int it87_freq = 38; /* kHz */
+static int irq = IT87_CIR_DEFAULT_IRQ;
+#endif
+
+static unsigned long it87_bits_in_byte_out;
+static unsigned long it87_send_counter;
+static unsigned char it87_RXEN_mask = IT87_CIR_RCR_RXEN;
+
+#define RBUF_LEN 1024
+
+#define LIRC_DRIVER_NAME "lirc_it87"
+
+/* timeout for sequences in jiffies (=5/100s) */
+/* must be longer than TIME_CONST */
+#define IT87_TIMEOUT (HZ*5/100)
+
+/* module parameters */
+static int debug;
+#define dprintk(fmt, args...) \
+ do {\
+ if (debug) \
+ printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \
+ fmt, ## args); \
+ } while (0)
+
+static int io = IT87_CIR_DEFAULT_IOBASE;
+/* receiver demodulator default: off */
+static int it87_enable_demodulator;
+
+static int timer_enabled;
+static DEFINE_SPINLOCK(timer_lock);
+static struct timer_list timerlist;
+/* time of last signal change detected */
+static struct timeval last_tv = {0, 0};
+/* time of last UART data ready interrupt */
+static struct timeval last_intr_tv = {0, 0};
+static int last_value;
+
+static DECLARE_WAIT_QUEUE_HEAD(lirc_read_queue);
+
+static DEFINE_SPINLOCK(hardware_lock);
+static DEFINE_SPINLOCK(dev_lock);
+
+static int rx_buf[RBUF_LEN];
+unsigned int rx_tail, rx_head;
+
+static struct pnp_driver it87_pnp_driver;
+
+/* SECTION: Prototypes */
+
+/* Communication with user-space */
+static int lirc_open(struct inode *inode, struct file *file);
+static int lirc_close(struct inode *inode, struct file *file);
+static unsigned int lirc_poll(struct file *file, poll_table *wait);
+static ssize_t lirc_read(struct file *file, char *buf,
+size_t count, loff_t *ppos);
+static ssize_t lirc_write(struct file *file, const char *buf,
+ size_t n, loff_t *pos);
+static long lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long
arg);
+static void add_read_queue(int flag, unsigned long val);
+static int init_chrdev(void);
+static void drop_chrdev(void);
+/* Hardware */
+static irqreturn_t it87_interrupt(int irq, void *dev_id);
+static void send_space(unsigned long len);
+static void send_pulse(unsigned long len);
+static void init_send(void);
+static void terminate_send(unsigned long len);
+static int init_hardware(void);
+static void drop_hardware(void);
+/* Initialisation */
+static int init_port(void);
+static void drop_port(void);
+
+
+/* SECTION:
[PATCH 05/15] staging/lirc: add lirc_imon driver
Nb: this is a very trimmed-down lirc_imon, which only supports the
oldest generation of imon devices that don't do onboard signal decoding
like the most recent generation imon devices -- those are now supported
by the ir-core imon driver.
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_imon.c | 1058 ++
1 files changed, 1058 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/lirc/lirc_imon.c
diff --git a/drivers/staging/lirc/lirc_imon.c b/drivers/staging/lirc/lirc_imon.c
new file mode 100644
index 000..43856d6
--- /dev/null
+++ b/drivers/staging/lirc/lirc_imon.c
@@ -0,0 +1,1058 @@
+/*
+ * lirc_imon.c: LIRC/VFD/LCD driver for SoundGraph iMON IR/VFD/LCD
+ *including the iMON PAD model
+ *
+ * Copyright(C) 2004 Venky Raju(d...@venky.ws)
+ * Copyright(C) 2009 Jarod Wilson
+ *
+ * lirc_imon 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+
+#define MOD_AUTHOR "Venky Raju "
+#define MOD_DESC "Driver for SoundGraph iMON MultiMedia IR/Display"
+#define MOD_NAME "lirc_imon"
+#define MOD_VERSION"0.8"
+
+#define DISPLAY_MINOR_BASE 144
+#define DEVICE_NAME"lcd%d"
+
+#define BUF_CHUNK_SIZE 4
+#define BUF_SIZE 128
+
+#define BIT_DURATION 250 /* each bit received is 250us */
+
+/*** P R O T O T Y P E S ***/
+
+/* USB Callback prototypes */
+static int imon_probe(struct usb_interface *interface,
+ const struct usb_device_id *id);
+static void imon_disconnect(struct usb_interface *interface);
+static void usb_rx_callback(struct urb *urb);
+static void usb_tx_callback(struct urb *urb);
+
+/* suspend/resume support */
+static int imon_resume(struct usb_interface *intf);
+static int imon_suspend(struct usb_interface *intf, pm_message_t message);
+
+/* Display file_operations function prototypes */
+static int display_open(struct inode *inode, struct file *file);
+static int display_close(struct inode *inode, struct file *file);
+
+/* VFD write operation */
+static ssize_t vfd_write(struct file *file, const char *buf,
+size_t n_bytes, loff_t *pos);
+
+/* LIRC driver function prototypes */
+static int ir_open(void *data);
+static void ir_close(void *data);
+
+/* Driver init/exit prototypes */
+static int __init imon_init(void);
+static void __exit imon_exit(void);
+
+/*** G L O B A L S ***/
+#define IMON_DATA_BUF_SZ 35
+
+struct imon_context {
+ struct usb_device *usbdev;
+ /* Newer devices have two interfaces */
+ int display;/* not all controllers do */
+ int display_isopen; /* display port has been opened */
+ int ir_isopen; /* IR port open */
+ int dev_present;/* USB device presence */
+ struct mutex ctx_lock; /* to lock this object */
+ wait_queue_head_t remove_ok;/* For unexpected USB disconnects */
+
+ int vfd_proto_6p; /* some VFD require a 6th packet */
+
+ struct lirc_driver *driver;
+ struct usb_endpoint_descriptor *rx_endpoint;
+ struct usb_endpoint_descriptor *tx_endpoint;
+ struct urb *rx_urb;
+ struct urb *tx_urb;
+ unsigned char usb_rx_buf[8];
+ unsigned char usb_tx_buf[8];
+
+ struct rx_data {
+ int count; /* length of 0 or 1 sequence */
+ int prev_bit; /* logic level of sequence */
+ int initial_space; /* initial space flag */
+ } rx;
+
+ struct tx_t {
+ unsigned char data_buf[IMON_DATA_BUF_SZ]; /* user data buffer */
+ struct completion finished; /* wait for write to finish */
+ atomic_t busy; /* write in progress */
+ int status; /* status of tx completion */
+ } tx;
+};
+
+static struct file_operations display_fops = {
+ .owner = THIS_MODULE,
+ .open = &display_open,
+ .write = &vfd_write,
+ .release= &display_close
+};
+
+/*
+ * USB Device ID for iMON USB Contr
