Skip to contentSkip to conversation

Lockups reading from i.MX51 SSI registers

DISCUSSION Mark Brown 5 participants 12 messages Aug 10, 2012 – Aug 20, 2012

lore
Share & tools
lore

Mark Brown

author
#0 lore raw

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

#1 lore raw
Quoted 8 lines · Mark Brown

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);
Quoted 6 lines

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

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#2 lore raw

Hi,

Quoted 14 lines · Sascha Hauer
Quoted 6 lines · Mark Brown

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);
Quoted 6 lines

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.

Quoted 2 lines

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

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
#3 lore raw
Quoted 17 lines · Uwe Kleine-König

Hi,

Quoted 14 lines · Sascha Hauer
Quoted 12 lines · Mark Brown

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.

Quoted 5 lines
Quoted 2 lines

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

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#4 lore raw
Quoted 5 lines · Sascha Hauer

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

author
#5 lore raw
Quoted 1 line · Fabio Estevam

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.

#6 lore raw
Quoted 6 lines · Mark Brown
Quoted 1 line · Fabio Estevam

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?

#7 lore raw
Quoted 11 lines · Fabio Estevam
Quoted 6 lines · Mark Brown
Quoted 1 line · Fabio Estevam

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.

#10 lore raw
In reply to Mark Brown
Quoted 6 lines · Mark Brown
Quoted 1 line · Fabio Estevam

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

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
#11 lore raw
Quoted 3 lines · Uwe Kleine-König

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
_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel