October 2009 - e3-hacking

[PATCH] ASoC: Amstrad Delta: add info about the line discipline requirement to Kconfig help text
by Janusz Krzysztofik 25 Oct '09

25 Oct '09

I thought it could be usefull to add some information on how to get the device fully supported by loading a line discipline on the modem line. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- As you could probably notice, I am not a native English, so please feel free to correct my poor language if desired. --- linux-2.6.32-rc5/sound/soc/omap/Kconfig.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/Kconfig 2009-10-24 00:01:26.000000000 +0200 @@ -21,7 +21,18 @@ config SND_OMAP_SOC_AMS_DELTA select SND_OMAP_SOC_MCBSP select SND_SOC_CX20442 help - Say Y if you want to add support for SoC audio on Amstrad Delta. + Say Y if you want to add support for SoC audio device connected to + a handset and a speakerphone found on Amstrad E3 (Delta) videophone. + + Note that in order to get those devices fully supported, you have to + build the kernel with standard serial port driver included and + configured for at least 4 ports. Then, from userspace, you must load + a line discipline #19 on the modem (ttyS3) serial line. The simplest + way to achieve this is to install util-linux-ng and use the included + ldattach utility. This can be started automatically from udev, + a simple rule like this one should do the trick (it does for me): + ACTION=="add", KERNEL=="controlC0", \ + RUN+="/usr/sbin/ldattach 19 /dev/ttyS3" config SND_OMAP_SOC_OSK5912 tristate "SoC Audio support for omap osk5912"

2 1

[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