[alsa-devel] Lockups reading from i.MX51 SSI registers
Hi,
I'm trying to use -next to test AC'97 register I/O on an i.MX51 board but I'm seeing the CPU hang during probe at:
lreg = (reg & 0x7f) << 12 ; writel(lreg, base + SSI_SACADD);
in imx_ssi_ac97_read(). I'm somewhat suspicious this might be because the IP block isn't clocked properly, I do notice the recent conversion to the clock API which looks rather involved but it's possible something else broke. Does anyone have any bright ideas what might be going on here? The board doesn't have the reste functions defined so this is the first interaction with the hardware block AFAICT.
Thanks, Mark
On Fri, Aug 10, 2012 at 08:50:08PM +0100, Mark Brown wrote:
Hi,
I'm trying to use -next to test AC'97 register I/O on an i.MX51 board but I'm seeing the CPU hang during probe at:
lreg = (reg & 0x7f) << 12 ; writel(lreg, base + SSI_SACADD);
in imx_ssi_ac97_read(). I'm somewhat suspicious this might be because the IP block isn't clocked properly, I do notice the recent conversion to the clock API which looks rather involved but it's possible something else broke. Does anyone have any bright ideas what might be going on here? The board doesn't have the reste functions defined so this is the first interaction with the hardware block AFAICT.
No idea currently, just adding Uwe to Cc because I think he has seen something similar on an i.MX35 board recently.
Sascha
Hi,
On Fri, Aug 10, 2012 at 09:56:38PM +0200, Sascha Hauer wrote:
On Fri, Aug 10, 2012 at 08:50:08PM +0100, Mark Brown wrote:
I'm trying to use -next to test AC'97 register I/O on an i.MX51 board but I'm seeing the CPU hang during probe at:
lreg = (reg & 0x7f) << 12 ; writel(lreg, base + SSI_SACADD);
in imx_ssi_ac97_read(). I'm somewhat suspicious this might be because the IP block isn't clocked properly, I do notice the recent conversion to the clock API which looks rather involved but it's possible something else broke. Does anyone have any bright ideas what might be going on here? The board doesn't have the reste functions defined so this is the first interaction with the hardware block AFAICT.
No idea currently, just adding Uwe to Cc because I think he has seen something similar on an i.MX35 board recently.
I havn't debugged that yet, but one issue I think needs to be solved is that since the clk conversion there are two ssi clocks. And from a quick look the ssi driver only handles one of them.
Uwe
On Fri, Aug 10, 2012 at 10:14:56PM +0200, Uwe Kleine-König wrote:
Hi,
On Fri, Aug 10, 2012 at 09:56:38PM +0200, Sascha Hauer wrote:
On Fri, Aug 10, 2012 at 08:50:08PM +0100, Mark Brown wrote:
I'm trying to use -next to test AC'97 register I/O on an i.MX51 board but I'm seeing the CPU hang during probe at:
lreg = (reg & 0x7f) << 12 ; writel(lreg, base + SSI_SACADD);
in imx_ssi_ac97_read(). I'm somewhat suspicious this might be because the IP block isn't clocked properly, I do notice the recent conversion to the clock API which looks rather involved but it's possible something else broke. Does anyone have any bright ideas what might be going on here? The board doesn't have the reste functions defined so this is the first interaction with the hardware block AFAICT.
No idea currently, just adding Uwe to Cc because I think he has seen something similar on an i.MX35 board recently.
I havn't debugged that yet, but one issue I think needs to be solved is that since the clk conversion there are two ssi clocks. And from a quick look the ssi driver only handles one of them.
One clock is for the bus which must be turned on. The other is for the bitclock which we currently can ignore since we only support clock slave mode. On an i.MX5 ssi[123]_ipg_gate must be turned on by the ssi driver. From a quick look to the clock code it looks correct.
Sascha
On Fri, Aug 10, 2012 at 6:06 PM, Sascha Hauer s.hauer@pengutronix.de wrote:
One clock is for the bus which must be turned on. The other is for the bitclock which we currently can ignore since we only support clock slave mode. On an i.MX5 ssi[123]_ipg_gate must be turned on by the ssi driver. From a quick look to the clock code it looks correct.
I tested audio playback on a mx51evk board last week using linux-next and it worked fine (it has a sgtl5000).
I don't have any hardware with ac97 to try it.
Also, for the playback to work you need to install the SDMA firmware.
Regards,
Fabio Estevam
On Fri, Aug 17, 2012 at 7:27 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Aug 17, 2012 at 04:08:47PM -0300, Fabio Estevam wrote:
Also, for the playback to work you need to install the SDMA firmware.
This is deadlocking during boot, I'm getting nowhere near trying playback.
Are you running a dt or non-dt kernel? In case of a dt kernel, can you share the dts file?
On Fri, 2012-08-17 at 20:35 -0300, Fabio Estevam wrote:
On Fri, Aug 17, 2012 at 7:27 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Aug 17, 2012 at 04:08:47PM -0300, Fabio Estevam wrote:
Also, for the playback to work you need to install the SDMA firmware.
This is deadlocking during boot, I'm getting nowhere near trying playback.
Are you running a dt or non-dt kernel? In case of a dt kernel, can you share the dts file?
I suppose Mark means an i.MX35 not an i.MX51.
On 8/20/12, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Aug 17, 2012 at 08:35:49PM -0300, Fabio Estevam wrote:
Are you running a dt or non-dt kernel? In case of a dt kernel, can you share the dts file?
Non-DT.
Please try this patch: http://www.spinics.net/lists/arm-kernel/msg190040.html
Regards,
Fabio Estevam
On Fri, Aug 17, 2012 at 11:27:38PM +0100, Mark Brown wrote:
On Fri, Aug 17, 2012 at 04:08:47PM -0300, Fabio Estevam wrote:
Also, for the playback to work you need to install the SDMA firmware.
This is deadlocking during boot, I'm getting nowhere near trying playback.
You're on i.MX35, right. I had to add
clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0");
to arch/arm/mach-imx/clk-imx35.c to be able to access the codec. (Obviously this is a hack, and to do it better, you'd need to change
clk_register_clkdev(clk[ssi1_div_post], "per", "imx-ssi.0");
to use ssi1_gate and fix the ssi-driver to be aware that there are two clocks to handle.)
Best regards Uwe
On Sat, Aug 18, 2012 at 4:42 AM, Uwe Kleine-König u.kleine-koenig@pengutronix.de wrote:
You're on i.MX35, right. I had to add
clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0");
Ah, ok. This is the same we have on arch/arm/mach-imx/clk-imx31.c ,
and mx31 audio playback is functional in next, so it looks like this will fix Mark's issue on mx35.
Uwe, would you like to send this patch for clk-imx35.c ?
Regards,
Fabio Estevam
participants (5)
-
Christoph Fritz -
Fabio Estevam -
Mark Brown -
Sascha Hauer -
Uwe Kleine-König