August 2009 - e3-hacking

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

[PATCH 0/2] Give the N_AMSDELTA line discipline more generic name
by Janusz Krzysztofik 07 Aug '09

07 Aug '09

This series of patches renames the N_AMSDELTA line discipline, used by the Amstrad Delta ASoC machine driver and the CX20442 ASoC codec driver for controlling the CX20442 voice codec over the CX81801 voice modem, giving it a more generic name: N_V253. The name has been chosen after the voice modem standard codename V.253. I think that even if the code of the line discipline is currently implemented inside those two specific drivers, the idea, if not the code, could be reused with other similar hardware configurations, if necessary. As the line discipline is conceived to be registered from a machine driver, there should be no conflicts, even if used by several different drivers that happen to be be built-in side-by-side. [PATCH 1/2] TTY: Rename N_AMSDELTA line discipline to N_V253 [PATCH 2/2] ASoC: AMS_DELTA: Use updated line discipline name Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl>

2 1

[PATCH 2/2] ASoC: AMS_DELTA: Use updated line discipline name
by Janusz Krzysztofik 06 Aug '09

06 Aug '09

This patch updates the tty line discipline name used in the Amstrad Delta machine driver. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.31-rc5/sound/soc/omap/ams-delta.c.orig 2009-08-05 21:44:35.000000000 +0200 +++ linux-2.6.31-rc5/sound/soc/omap/ams-delta.c 2009-08-05 23:30:53.000000000 +0200 @@ -519,7 +519,7 @@ static int ams_delta_cx20442_init(struct } /* Register optional line discipline for over the modem control */ - ret = tty_register_ldisc(N_AMSDELTA, &cx81801_ops); + ret = tty_register_ldisc(N_V253, &cx81801_ops); if (ret) { dev_warn(card->dev, "Failed to register line discipline, " @@ -644,9 +644,9 @@ static void __exit ams_delta_module_exit } } - if (tty_unregister_ldisc(N_AMSDELTA) != 0) + if (tty_unregister_ldisc(N_V253) != 0) dev_warn(&ams_delta_audio_platform_device->dev, - "failed to unregister AMSDELTA line discipline\n"); + "failed to unregister V253 line discipline\n"); snd_soc_jack_free_gpios(&ams_delta_hook_switch, ARRAY_SIZE(ams_delta_hook_switch_gpios),

1 0

[PATCH 1/2] TTY: Rename N_AMSDELTA line discipline to N_V253
by Janusz Krzysztofik 06 Aug '09

06 Aug '09

The patch changes the line discipline name registered in include/linux/tty.h Signed-off-by: Janusz Krzysztofik --- --- linux-2.6.31-rc5/include/linux/tty.h.orig 2009-08-05 21:44:33.000000000 +0200 +++ linux-2.6.31-rc5/include/linux/tty.h 2009-08-05 22:54:12.000000000 +0200 @@ -47,7 +47,7 @@ #define N_SLCAN 17 /* Serial / USB serial CAN Adaptors */ #define N_PPS 18 /* Pulse per Second */ -#define N_AMSDELTA 19 /* codec control over modem, board specific */ +#define N_V253 19 /* Codec control over voice modem */ /* * This character is the same as _POSIX_VDISABLE: it cannot be used as

1 0

[PATCH 0/2] ASoC: CX2044: full duplex mode fix
by Janusz Krzysztofik 06 Aug '09

06 Aug '09

This series of patches tries to solve the problem of audio mode changes not working correctly while in full duplex mode. [PATCH 1/2] ASoC: CX20442: add some debugging [PATCH 2/2] ASoC: CX20442: simplify codec controller usage Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl>

2 1

[PATCH 2/2] ASoC: CX20442: simplify codec controller usage
by Janusz Krzysztofik 06 Aug '09

06 Aug '09

This patch is a workaround for the problem of several subsequent control statements not being applied correctly to the codec controller (modem). In order to follow the hook switch state change from handset to handsfree while in full duplex mode, two consecutive +VLS control commands were sent to the modem. The first one was M1 (microphone only), the seconds one was M1S1 (both microphone and speaker). As there was no real modem handshaking procedure implemented, neither in the codec nor in the machine driver part of the line discipline, the modem was having the second command missed. Since a possibility to switch to microphone only mode (and speaker only mode as well) seams of no value, I have modified the code to issue single M1S1 command only for any of those cases. Tested on my Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.31-rc5/sound/soc/codecs/cx20442.c.orig 2009-08-04 23:41:03.000000000 +0200 +++ linux-2.6.31-rc5/sound/soc/codecs/cx20442.c 2009-08-05 00:56:30.000000000 +0200 @@ -138,9 +138,7 @@ static int cx20442_pm_to_v253_vls(u8 val case 0: return V253_VLS_T; case (1 << CX20442_SPKOUT): - return V253_VLS_S1; case (1 << CX20442_MIC): - return V253_VLS_M1; case (1 << CX20442_SPKOUT) | (1 << CX20442_MIC): return V253_VLS_M1S1; case (1 << CX20442_TELOUT):

1 0

[PATCH 1/2] ASoC: CX20442: add some debugging
by Janusz Krzysztofik 06 Aug '09

06 Aug '09

This patch adds debugging statement that can help in tracing how the driver is trying to control the codec device. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.31-rc5/sound/soc/codecs/cx20442.c.orig 2009-08-04 23:41:03.000000000 +0200 +++ linux-2.6.31-rc5/sound/soc/codecs/cx20442.c 2009-08-05 00:56:30.000000000 +0200 @@ -203,6 +201,7 @@ static int cx20442_write(struct snd_soc_ if (unlikely(len > (ARRAY_SIZE(buf) - 1))) return -ENOMEM; + dev_dbg(codec->dev, "%s: %s\n", __func__, buf); if (codec->hw_write(codec->control_data, buf, len) != len) return -EIO;

1 0

Re: [E3-hacking] [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
by Janusz Krzysztofik 06 Aug '09

06 Aug '09

Wednesday 05 August 2009 10:42:54 Jarkko Nikula wrote: > On Wed, 5 Aug 2009 10:21:49 +0300 > Jarkko Nikula <jhnikula(a)gmail.com> wrote: > > > If my analysis is correct, the best solution I can see would be > > > starting McBSP transfer for one direction only, not both, so the > > > opposite direction can be started when needed. That requires deeper and > > > wider OMAP knowledge and a change in omap_mcbsp_start() API though. I > > > am not in a position to deal with this myself, I'm afraid. > > > > I favor this change. Actually I remember I was thinking shortly to > > change API of omap_mcbsp_start and _stop more than year back or so but > > didn't find it necessary back then. > > > > I think change will be trivial. Basically two new arguments indicating > > are the TX/RX active and let the first/last caller to deal with > > sample-rate generator and frame sync activation/de-activation. > > I hacked a patch below. Can you test does it help? Yes, it does. Works as expected in all possible combinations I have tried: start recording while playing, start playing while recording, start recording and playing simultaneously. Thanks. Tested-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl>

1 0