- e3-hacking - earth.li

[PATCH] OMAP1: AMS_DELTA: Fix DSP public peripherals support
by Janusz Krzysztofik 22 Oct '09

22 Oct '09

DSP public peripherals used to work on OMAP1510 based (or all OMAP1 class?) machines as long as old dspgateway code were present in the l-o tree. For several months it is no longer included, breaking support for McBSP1 based audio on Amstrad Delta, for example. This patch, derived from the old dspgateway code, corrects the problem for the board by simply taking the DSP out of reset state, I guess. That way, things should not break when a new dsp code is added to the tree, and the change can be reverted then. If there are any reports on McBSP1 or other DSP public peripherals not working for other OMAP1 machines (I've not heard of any for now), I can prepare a more general patch providing an extra include file with a helper function defined. Created and tested against linux-2.6.32-rc5 Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/arch/arm/mach-omap1/board-ams-delta.c.orig 2009-10-22 00:55:49.000000000 +0200 +++ linux-2.6.32-rc5/arch/arm/mach-omap1/board-ams-delta.c 2009-10-22 01:46:39.000000000 +0200 @@ -235,6 +235,8 @@ static void __init ams_delta_init(void) omap_usb_init(&ams_delta_usb_config); platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices)); + + omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1); } static struct plat_serial8250_port ams_delta_modem_ports[] = {

2 4

[PATCH] OMAP: Fix broken omap-keypad
by Janusz Krzysztofik 22 Oct '09

22 Oct '09

Hi, Commit 4f5433324d1e29cf234d5b1b14782c0fc2948298 had made machines that use new matrix_keypad based drivers happy while breaking those that still use old omap-keypad driver. The patch fixes omap-keypad device for my Amstrad Delta (tested) and probably 11 more OMAP1 based machines. It leaves a potential similiar problem on OMAP2 H4 machine not addressed. I would say that those new, matrix_keypad based drivers should be corrected to simply not include arch/arm/plat-omap/include/mach/keypad.h, which should keep serving omap-keypad based machines until they are all upgraded to use matrix_keypad. Created against linux-2.6.32-rc5 Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/arch/arm/plat-omap/include/mach/keypad.h.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/arch/arm/plat-omap/include/mach/keypad.h 2009-10-21 15:32:37.000000000 +0200 @@ -10,7 +10,9 @@ #ifndef ASMARM_ARCH_KEYPAD_H #define ASMARM_ARCH_KEYPAD_H +#ifndef CONFIG_ARCH_OMAP1 #include <linux/input/matrix_keypad.h> +#endif struct omap_kp_platform_data { int rows; @@ -38,5 +40,11 @@ struct omap_kp_platform_data { #define KEY_PERSISTENT 0x00800000 #define KEYNUM_MASK 0x00EFFFFF +#ifdef CONFIG_ARCH_OMAP1 +#define KEY(col, row, val) (((col) << 28) | ((row) << 24) | (val)) +#define PERSISTENT_KEY(col, row) (((col) << 28) | ((row) << 24) | \ + KEY_PERSISTENT) +#endif + #endif

2 3

[PATCH] Fix broken NAND on Amstrad Delta
by Janusz Krzysztofik 22 Oct '09

22 Oct '09

Hi, I found that with commit 15ac408ee5a509053a765b816e9179515329369f, "OMAP: UART: drop OMAP_TAG_UART, enable all UARTs, auto-disabled on idle", NAND got not accessible on Amstrad Delta (E3). That seems to be caused by unnecessary omap_cfg_reg() calls for UART ports 2 and 3, that were never used on that machine before and now are initilalized and supposed to be auto-disabled. I can suspect that similiar problems may exist for other OMAP1510 based boards. Furthermore, since mux code is going to be reorganized, the right solution would probably be to remove those cpu_is_omap1510() specific bits completely from arch/arm/mach-omap1/serial.c and push them into board specific files where applicable. However, not being familiar with any OMAP hardware other that my amsdelta, I provide a patch that solves the problem for that machine only. I have locked out the bits for UART1 as well as those look not really required, as far as I can understand http://focus.ti.com/lit/ds/symlink/omap5910.pdf. Created and tested against linux-2.6.32-r5. Thanks, Janusz Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/arch/arm/mach-omap1/serial.c.orig 2009-10-20 22:38:38.000000000 +0200 +++ linux-2.6.32-rc5/arch/arm/mach-omap1/serial.c 2009-10-21 01:26:51.000000000 +0200 @@ -143,7 +143,7 @@ void __init omap_serial_init(void) if (cpu_is_omap15xx()) clk_set_rate(uart1_ck, 12000000); } - if (cpu_is_omap15xx()) { + if (cpu_is_omap15xx() && !(machine_is_ams_delta())) { omap_cfg_reg(UART1_TX); omap_cfg_reg(UART1_RTS); if (machine_is_omap_innovator()) { @@ -165,7 +165,7 @@ void __init omap_serial_init(void) else clk_set_rate(uart2_ck, 48000000); } - if (cpu_is_omap15xx()) { + if (cpu_is_omap15xx() && !(machine_is_ams_delta())) { omap_cfg_reg(UART2_TX); omap_cfg_reg(UART2_RTS); if (machine_is_omap_innovator()) { @@ -185,7 +185,7 @@ void __init omap_serial_init(void) if (cpu_is_omap15xx()) clk_set_rate(uart3_ck, 12000000); } - if (cpu_is_omap15xx()) { + if (cpu_is_omap15xx() && !(machine_is_ams_delta())) { omap_cfg_reg(UART3_TX); omap_cfg_reg(UART3_RX); }

2 5

[PATCH] ASoC: OMAP: Don't try to set unsupported OMAP_DMA_DATA_BURST_16 on OMAP1
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

Wednesday 21 October 2009 20:09:54 Mark Brown napisał(a): > This is fine by me but I'd like a proper changelog Yes, sir. ---------------------- After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, omap_pcm_prepare() unconditionally calls: omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); Current implementation of those two functions found in arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 at all, so they both end with BUG() on that machine. That results in ASoC being completely unusable, at least on my OMAP5910 based Amstrad Delta. The patch corrects the problem by not calling those two functions when run on OMAP1 class based machines. Created against linux-2.6.32-rc5. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.000000000 +0200 @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ); + if (cpu_class_is_omap1()) + return 0; + omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16);

2 1

Fwd: [PATCH] Re: [alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

I forgot to CC e3-hacking, here it is. Janusz ---------- Forwarded message ---------- Subject: [PATCH] Re: [alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1 Date: środa 21 październik 2009 From: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> To: Jarkko Nikula <jhnikula(a)gmail.com> Wednesday 21 October 2009 09:16:37 Jarkko Nikula napisał(a): > Hi > > On Wed, 21 Oct 2009 05:11:06 +0200 > > Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> wrote: > > Hi, > > After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, > > omap_pcm_prepare() unconditionally calls: > > > > omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > > > AFAICS, current implementation of those two functions found in > > arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 > > at all, so they both end with BUG() on that machine. That seems to result > > in ASoC being completely unusable, at least on my OMAP5910 based Amstrad > > Delta. > > Thanks for reporting the issue. Nobody didn't realize when those calls > were added that indeed they will end up to BUG() in > arch/arm/plat-omap/dma.c on OMAP1. > > > Is calling BUG() for OMAP1 from those functions intentional? > > > > If not intentional, can those be corrected by simply putting break; > > before defalut:? > > I'd let it on as it is as it will point out immediately invalid > argument for OMAP1 and those functions do not have return value. > > > If intentional, can those function calls be conditionally omited, at > > least for OMAP1510, in sound/soc/omap/omap-pcm.c? > > Yep, just put cpu_class_is_omap1() test in sound/soc/omap/omap-pcm.c > since we should not try to set unsupported burst size for OMAP1. Here you are. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.000000000 +0200 @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ); + if (cpu_class_is_omap1()) + return 0; + omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16);

1 0

Amstrad E3 USB power supply has 45mA current limit
by witek mark 08 Oct '09

08 Oct '09

1 0

Re: [E3-hacking] [RFC][PATCH] ARM: OMAP: McBSP: Use register cache
by Janusz Krzysztofik 05 Sep '09

05 Sep '09

Friday 04 September 2009 07:39:36 Eero Nurkkala wrote: > > Register values should not get corrupted. Could you please point out the > registers that may get corrupted? Do they get corrupted during audio > play? I haven't seen corrupted register values. > Hi Eero, Please have a look at some debug log lines below. Those were generated on my Amstrad Delta videophone, using an application (asterisk softpbx with alsa channel) that can restart a receiver of a prevoiusly requested McBSP by calling omap_mcbsp_start() on user request. As you can see, corrupted values can happen to get read from any register that is expected to return predictable results. Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: **** McBSP1 regs **** Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: DRR2: 0x1000 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: DRR1: 0x009d Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: DXR2: 0x3000 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: DXR1: 0x7da1 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: SPCR2: 0x02f0 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: SPCR1: 0x7031 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: RCR2: 0x0045 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: RCR1: 0x0040 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: XCR2: 0x1045 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: XCR1: 0x0040 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: SRGR2: 0x310f Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: SRGR1: 0x0000 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: PCR0: 0x0003 Sep 4 08:21:17 amsdelta user.debug kernel: [309910.170000] omap-mcbsp omap-mcbsp.1: mcbsp: *********************** Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: **** McBSP1 regs **** Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: DRR2: 0x0000 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: DRR1: 0x1086 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: DXR2: 0x0000 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: DXR1: 0x7da1 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: SPCR2: 0x02f0 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: SPCR1: 0x0031 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: RCR2: 0x1045 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: RCR1: 0x1040 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: XCR2: 0x3045 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: XCR1: 0x1040 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: SRGR2: 0x000f Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: SRGR1: 0x0000 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: PCR0: 0x1003 Sep 4 08:21:19 amsdelta user.debug kernel: [309912.050000] omap-mcbsp omap-mcbsp.1: mcbsp: *********************** Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: **** McBSP1 regs **** Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: DRR2: 0x1000 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: DRR1: 0x109e Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: DXR2: 0x1000 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: DXR1: 0x7da1 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: SPCR2: 0x02f0 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: SPCR1: 0x1031 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: RCR2: 0x1045 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: RCR1: 0x1040 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: XCR2: 0x2045 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: XCR1: 0x1040 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: SRGR2: 0x100f Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: SRGR1: 0x1000 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: PCR0: 0x2003 Sep 4 08:21:21 amsdelta user.debug kernel: [309913.950000] omap-mcbsp omap-mcbsp.1: mcbsp: *********************** Those corruptions, even if should never happen, were actually caused by a wireless adapter connected to the machine USB port. Extra piece of hardware, very usefull in some cases, but obviously not taken into account while the machine was being designed. While playback seems unaffected, WiFi noise in capture stream prevents from using the videophone in speakerphone mode, but in normal (handset) mode, the noise level seems still acceptable. The only missing piece of a puzzle is my patch, that prevents the kernel driver from putting corrupted values into the McBSP control registers. That learned, please reconsider: 1. Can my patch break anything, related or not? 2. How does it affect performance of otherwise unaffected machines? 3. Is correcting a poorly designed machine behaviour worth of the change? Thanks, Janusz

4 3

HOWTO: test your E3 audio
by Janusz Krzysztofik 03 Sep '09

03 Sep '09

David Reynolds wrote: > Janusz, > > Any chance of a step by step of how you set up your E3 as a soft phone? Things are not stable yet, but for those impatient: 1. Ensure you are able to access E3 serial console. In case of problems, try with different serial ports, including different usb_serial adapters. An FTDI based one worked for me, a Prolific one did not. For more info, use http://wiki.earth.li/E3 as your starting point. 2. Ensure you are able to install and run http://the.earth.li/pub/e3/E3_release_v2.tar.gz on your E3. There is a README included. 3. On your linux PC, install OpenEmbedded and bitbake (http://www.openembedded.org) Read OE documentation. Switch to 2009/stable branch (I'm not sure if really necessary). 4. Configure your OE. In local.conf, set: MACHINE = "amsdelta" KERNEL_IMAGETYPE = "uImage" DISTRO = "amsdelta-oe" ANGSTROMLIBC = "uclibc" Try building minimal-image. This should break on u-boot. 5. For better results, you'll have to modify several OE files. The best way is to set up local OE overlay. Get copies of required files/directories from OE tree and modify them. 6. Modify conf/machine/amsdelta.conf: - change PREFERRED_PROVIDER_virtual/kernel to "linux" ("linux-omap" and "linux-omap-pm" worked for me too), - comment out EXTRA_IMAGEDEPENDS, - increase IMAGE_ROOTFS_SIZE_ext2{,.gz} to "16384", - in IMAGE_FSTYPES replace "tar.bz2" with "tar.gz". 7. Wait for linux-2.6.32 or later integrated into OE ;), that should already contain official audio support for ams-delta, or if you really can't wait, create your own recipes/linux/linux-2.6.31[-rcx].bb recipe and include all ams-delta audio related patches published here lately. 8. Run "bitbake -c configure linux". Go to tmp/work/amsdelta-angstrom-linux-uclibcgnueabi/linux-your.package.version/linux-your.kernel.version/, run "ARCH=arm make defconfig_amsdelta", then "ARCH=arm make menuconfig" to finetune your kernel configuration. Don't forget to turn on Drivers -> Sound -> ALSA -> ASoC -> OMAP -> Amsdelta ;). Now you can save your .config as defconfig under recipes/linux/linux-your.kernel.version/ directory for future reuse. Finally, get back to your build/ directory and bitbake minimal-image. 9. Use http://the.earth.li/pub/e3/E3_release_v2.tar.gz to boot your E3 into install mode and reinstall it with newly created images transfered to your usb stick. Use tmp/deploy/uclibc/images/amsdelta/Angstrom-minimalist-image-uclibc-ipk-your.oe.version-amsdelta.rootfs.tar.gz as root.tar.gz and tmp/work/amsdelta-angstrom-linux-uclibcgnueabi/linux-your.package.version/linux-your.kernel.version/arch/arm/boot/uImage as uImage. Keep u-boot.bin and ldr.img unchanged. 10. Verify if it works. To test audio, you can install several packages found in tmp/deploy/uclibc/ipk/armv4t/, like alsa-utils-aplay and alsa-utils-alsamixer or alsa-utils-amixer. You can also try to build and install madplay in order to play your favourite MP3s. After you are done: - feel free to use this text as a base for E3 Wiki update, - prepare and submit a patch against OE ;). More to come. Thanks, Janusz

1 1

[PATCH] chan_alsa: fix channel signalling
by Janusz Krzysztofik 18 Aug '09

18 Aug '09

Hi, I am one of those probably few Asterisk users who decided to give it a try as a soft phone. I have installed it on my ARM/OMAP based Amstrad E3 (Delta) videophone and get quite good results. For now I use 1.4.26, since I was not yet able to build 1.6 with OpenEmbedded. My sound driver is ALSA, so I started with chan_alsa. It's behaviour was not very bad, but there were random problems with incorrect signalling, not acceptable for a common user. After switching to chan_oss, I found that during some operations it was consuming all processor power. So it appeared not to be an option either. I got back to chan_alsa, investigated the problem and found a solution that works for me. In fact, I have followed corresponding bits from chan_oss to get it working. Created and tested against asterisk-1.4.26. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- asterisk-1.4.26/channels/chan_alsa.c.orig 2009-03-18 03:09:13.000000000 +0100 +++ asterisk-1.4.26/channels/chan_alsa.c 2009-08-14 23:09:04.000000000 +0200 @@ -750,7 +750,7 @@ static int alsa_fixup(struct ast_channel static int alsa_indicate(struct ast_channel *chan, int cond, const void *data, size_t datalen) { - int res = 0; + int res = -1; ast_mutex_lock(&alsalock); @@ -763,6 +763,7 @@ static int alsa_indicate(struct ast_chan break; case AST_CONTROL_RINGING: case AST_CONTROL_PROGRESS: + res = 0; break; case -1: res = -1;

1 0

[PATCH] devinput: fix EV_SW handling
by Janusz Krzysztofik 18 Aug '09

18 Aug '09

Hi, Maybe my LIRC application is not very common, but it behaves very well. I use lircd/lircexec with devinput driver on my ARM/OMAP based Amstrad E3 (Delta) videophone for controlling Asterisk PBX daemon from the machine (phone) keypad (and not from a remote, like most of LIRC users). That works almost out of the box, with some reasonable effort on lircexec configuration. However, the machine is equipped with one more source of input events except keypad: a phone hook switch. It is different from a key or a button in that it generates events of type EV_SW. Since it is a switch, not a toggle key, both ON (press) and OFF (release) events are equally important to my application. Unfortunately, for events of type EV_SW, devinput driver doesn't translate different state changes to distinctive codes, like it does for EV_KEY, so I was not able to distinguish going off-hook from on-hook without patching the driver. The patch that works for me follows. I hope you accept it even if my application may be the only one that needs it, as there are probably not many remotes equipped with switches, not buttons :). Created and tested against lirc-0.8.5. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- lirc-0.8.5/daemons/hw_devinput.c.orig 2009-08-18 18:57:53.000000000 +0200 +++ lirc-0.8.5/daemons/hw_devinput.c 2009-08-18 18:59:13.000000000 +0200 @@ -279,7 +279,8 @@ char *devinput_rec(struct ir_remote *rem event.time.tv_sec, event.time.tv_usec, event.type, event.code, event.value); - code = (event.type == EV_KEY && event.value != 0) ? 0x80000000 : 0; + code = ((event.type == EV_KEY || event.type == EV_SW) && + event.value != 0) ? 0x80000000 : 0; code |= ((event.type & 0x7fff) << 16); code |= event.code;

1 0