Janusz Krzysztofik wrote:
So I am going to restart with checking if the original patch still works with the latest kernel version supporting omap-alsa.
The original patch ported to linux-omap-2.6.27, the last omap release with omap-alsa support, gives me a working sound driver on ams-delta.
Jarkko Nikula wrote:
Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. ... Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls.
Peter Ujfalusi wrote:
This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec. Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct.
My port of the original driver is still very generic. There are no mux setups. It containes only two simple hardware pin setup calls that make it working, those are invoked from two callback functions, omap_alsa_codec_config.codec_clock_on() and omap_alsa_codec_config.codec_clock_off(), as below:
----------------------------------- int vc_clock_on(void) { if (clk_get_usecount(vc_mclk) > 0) { /* MCLK is already in use */ printk(KERN_WARNING "MCLK in use at %d Hz. We change it to %d Hz\n", (uint) clk_get_rate(vc_mclk), CODEC_CLOCK); } clk_enable(vc_mclk);
printk(KERN_DEBUG "MCLK = %d [%d], usecount = %d\n", (uint) clk_get_rate(vc_mclk), CODEC_CLOCK, clk_get_usecount(vc_mclk));
/* Now turn the audio on */ ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH2_MODEM_NRESET); return 0; }
int vc_clock_off(void) { if (clk_get_usecount(vc_mclk) > 0) { if (clk_get_rate(vc_mclk) != CODEC_CLOCK) { printk(KERN_WARNING "MCLK for audio should be %d Hz. But is %d Hz\n", (uint) clk_get_rate(vc_mclk), CODEC_CLOCK); }
clk_disable(vc_mclk); }
ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH2_MODEM_CODEC); return 0; } ... static int __init snd_omap_alsa_vc_probe(struct platform_device *pdev) { ... struct omap_alsa_codec_config *codec_cfg; ... codec_cfg->codec_clock_on = vc_clock_on; codec_cfg->codec_clock_off = vc_clock_off; ... }
static struct platform_driver omap_alsa_driver = { .probe = snd_omap_alsa_vc_probe, ... };
static int __init omap_alsa_vc_init(void) { int err;
err = platform_driver_register(&omap_alsa_driver); return err; } ----------------------------------
Jarkko Nikula wrote:
OMAP1510 doesn't support DMA chaining so there are few cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I think I have only simulated using OMAP2420.
To make the original driver work stable, I had to patch the omap-alsa framework to restore the original way that lack of dma chaining problem had been solved in the original patch (see below), so maybe there is a similiar issue in the currect ASoC McBSP framework?
---------------------------------- diff -uprN linux-2.6.27/sound/arm/omap/omap-alsa.c linux-2.6.27-sound/sound/arm/omap/omap-alsa.c --- linux-2.6.27/sound/arm/omap/omap-alsa.c 2009-05-30 21:27:09.000000000 +0000 +++ linux-2.6.27-sound/sound/arm/omap/omap-alsa.c 2009-05-30 22:12:12.000000000 +0000 @@ -52,6 +52,8 @@ #include <mach/omap-alsa.h> #include "omap-alsa-dma.h"
+#include <asm/mach-types.h> + MODULE_AUTHOR("Mika Laitio"); MODULE_AUTHOR("Daniel Petrini"); MODULE_AUTHOR("David Cohen"); @@ -210,7 +212,7 @@ static int audio_start_dma_chain(struct * irq from DMA after the first transfered/played buffer. * (invocation of callback_omap_alsa_sound_dma() method). */ - if (cpu_is_omap1510()) + if (cpu_is_omap1510() && !machine_is_ams_delta()) omap_stop_alsa_sound_dma(s);
dma_start_pos = (dma_addr_t)runtime->dma_area + offset; diff -uprN linux-2.6.27/sound/arm/omap/omap-alsa-dma.c linux-2.6.27-sound/sound/arm/omap/omap-alsa-dma.c --- linux-2.6.27/sound/arm/omap/omap-alsa-dma.c 2009-05-30 21:27:09.000000000 +0000 +++ linux-2.6.27-sound/sound/arm/omap/omap-alsa-dma.c 2009-05-30 22:12:12.000000000 +0000 @@ -70,6 +70,8 @@
#include <asm/arch/omap-alsa.h>
+#include <asm/mach-types.h> + #undef DEBUG
#define ERR(ARGS...) printk(KERN_ERR "{%s}-ERROR: ", __FUNCTION__);printk(ARGS); @@ -350,7 +352,7 @@ static int audio_start_dma_chain(struct omap_start_dma(channel); s->started = 1; s->hw_start(); /* start McBSP interface */ - } else if (cpu_is_omap310()) + } else if (cpu_is_omap310() || machine_is_ams_delta()) omap_start_dma(channel); /* else the dma itself will progress forward with out our help */ FN_OUT(0); ----------------------------------
My asoc based patch is also very generic and contains no more that the same two ams_delta_latch2_write() hardware related operations, called from inside snd_soc_dai_link.ops.startup() and snd_soc_dai_link.ops.shutdown() callback functions:
---------------------------------- static int ams_delta_startup(struct snd_pcm_substream *substream) { ams_delta_latch2_write(AMS_DELTA_LATCH_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH_MODEM_NRESET); return clk_enable(cx20442_mclk); }
static void ams_delta_shutdown(struct snd_pcm_substream *substream) { clk_disable(cx20442_mclk); ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH2_MODEM_CODEC); } ... static struct snd_soc_ops ams_delta_ops = { .startup = ams_delta_startup, .hw_params = ams_delta_hw_params, .shutdown = ams_delta_shutdown, }; ... /* Digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link ams_delta_dai = { ... .ops = &ams_delta_ops, };
/* Audio machine driver */ static struct snd_soc_card snd_soc_card_ams_delta = { .name = "AMS_DELTA", .platform = &omap_soc_platform, .dai_link = &ams_delta_dai, .num_links = 1, };
/* Audio subsystem */ static struct snd_soc_device ams_delta_snd_devdata = { .card = &snd_soc_card_ams_delta, .codec_dev = &soc_codec_dev_cx20442, }; -----------------------------------------------------
When applied on top of linux-2.6.27, omap or mainline, my patch causes system hangup on sound device first access, exactly as I have already reported it for linux-omap.git revision 90e758af52ba803cba233fabee81176d99589f09.
However, when applied on top of linux-2.6.30-rc5, I still get a working system with non-functional sound device. DMA interrupt counters stay at 0.
My conclusuions so far:
1. If the new OMAP McBSP ASoC framework provides all the functionality of the depreciated OMAP Alsa under a different API, the only reason of my driver not working I can imagine is that I have put these two lines of hardware related code in wrong places. If this is the case, could someone please point me into the right direction?
2. Maybe the original ams-delta sound driver should not in theory work as is? Maybe Mark Underwood was just lucky enough to get it working without any real hardware setup?
3. Otherwise, there must be a significant difference in (alsa) MsBSP handling code that I am not able to identify and resolve myself. I can only say that I have seen much more mcbsp_...() stuff in the old omap-alsa framework than in the current one. The differece can be significant for OMAP15XX, or OMAP5910, or even ams-delta only.
4. Base (not alsa related) McBSP framework did not change since 2.6.16 (the original patch base) up to 2.6.27 in a way that could break the original patch. If my problem was related to base McBSP handling, changes should be looked for after 2.6.27, if any.
Jarkko Nikula wrote:
It would be nice to get this working since it would be the first OMAP5910 == OMAP1510 based machine driver.
I am personally interested in this, as I have bought two E3's recently in hope I can make use of them as IP phones. But for now, I have no idea what else I could try. I have noticed that Andrew de Quincey is going to fix sound on Nokia 770, maybe he finds something related.
Cheers, Janusz
-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html