[PATCH 0/3] aic23 sound driver fixes

[PATCH 0/3] aic23 sound driver fixes

[lamikr]

Following patch set should fix the broken method references to from Alsa
and OSS drivers to tlv320aic23 i2c drivers that has been reported.
In addition the 3:rd patch contains the platform driver code that the
innovator requires if it wants to use alsa driver.

I do not own myself the innovator or aic23 drivers so it would be nice
if someone else could test these.

Mika

Re: [PATCH 0/3] aic23 sound driver fixes

[James Selvam]

Hi Mika/All,

I am working on OMAP1510 Innovator (kernel 2.6.16.13+omap1). I applied the
patches sent here, but the second hunk containing the change of function
calls to "aic23_write_value" were not defined so I changed them back to
"tlv320aic23_write_value". But the platform related patch was applied in
toto.

The kernel then recognised the AIC23 codec at bootup (which it was not doing
before). Also the I2C has set the MCBSP clocks 1 and 3. But ALSA did throw
up an error:

Clock enabled to MCBSP1 & 3
tlv320aic23 powering up
tlv320aic23_init_power() done
TLV320AIC23 I2C version 1.8 (10-Feb-2006)

Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04
08:57:20 2006 UTC).
Cannot set MCLK for AIC23 CODEC
audio support initialized
ALSA device list:
  #0: OMAP Innovator AIC23

Thereafter if we try to run an application it promts the same error "Cannot
set MCLK for AIC23 CODEC" and fails to recognise the device present.

Certain clarifications are required:
1) Where is the definition of the function "aic23_write_value" - specified
in the first two patches?
2) The MCLK not being set; the MCBSP clocks are set all right during the
bootup. Why then does it crib now?
3) Are the MCLK and the MCBSP clocks one and the same?

We have cross-compiled the ALSA utils (aplay, arec & speaker-test) as also
ALSA libraries separately & included the same in the file-system. Does ALSA
require any configuration before we can use the utils?

-James.

On 5/3/06, lamikr <lamikr@cc.jyu.fi> wrote:
>
> Following patch set should fix the broken method references to from Alsa
> and OSS drivers to tlv320aic23 i2c drivers that has been reported.
> In addition the 3:rd patch contains the platform driver code that the
> innovator requires if it wants to use alsa driver.
>
> I do not own myself the innovator or aic23 drivers so it would be nice
> if someone else could test these.
>
> Mika
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Re: [PATCH 0/3] aic23 sound driver fixes

[lamikr]

[-- Attachment #1: Type: text/plain, Size: 3095 bytes --]

Hi

James Selvam wrote:

> Hi Mika/All,
>
> I am working on OMAP1510 Innovator (kernel 2.6.16.13+omap1). I applied
> the patches sent here, but the second hunk containing the change of
> function calls to "aic23_write_value" were not defined so I changed
> them back to "tlv320aic23_write_value". But the platform related patch
> was applied in toto.

Yes, the patch-set was meant for the linux-omap git head as the
drivers/i2c/chips/tlv320aic23.c used by the aic23 ALSA and OSS drivers
has changed in git repository after the 2.6.16 omap kernel version.

But if you are using 2.6.16 then you should just take the 3/3 of
patchset. From 1/3 and 2/3 patches you may consider for taking the
KConfig changes by hand as
the I2C, I2C-OMAP and tlv320aic23 i2c drivers must always be selected if
AIC23 alsa or oss driver is selected.
 

> The kernel then recognised the AIC23 codec at bootup (which it was not
> doing before). Also the I2C has set the MCBSP clocks 1 and 3. But ALSA
> did throw up an error:
>
> Clock enabled to MCBSP1 & 3
> tlv320aic23 powering up
> tlv320aic23_init_power() done
> TLV320AIC23 I2C version 1.8 (10-Feb-2006)
>
> Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04
> 08:57:20 2006 UTC).
> Cannot set MCLK for AIC23 CODEC
> audio support initialized
> ALSA device list:
>   #0: OMAP Innovator AIC23
>
> Thereafter if we try to run an application it promts the same error
> "Cannot set MCLK for AIC23 CODEC" and fails to recognise the device
> present.

That's propaply because the clock rate is already ok, or the clock rate
is fixed and can not be changed.
Could you check whether the attached patch will work for you? If it
works, I will submit it in separate mail to be applied to
git repository.

>
> Certain clarifications are required:
> 1) Where is the definition of the function "aic23_write_value" -
> specified in the first two patches?

In OMAP git repository head following driver
drivers/i2c/chips/tlv320aic23.c

> 2) The MCLK not being set; the MCBSP clocks are set all right during
> the bootup. Why then does it crib now?

The attached patch should fix it, as it will check whether the clock is
already using the correct rate.
In future there may be need to change the alsa code a little bit more,
so that the clock rate can be defined in the board code instead of
hardcoding in the alsa driver as Menon Nishant suggested some time ago.

> 3) Are the MCLK and the MCBSP clocks one and the same?

It might help you to check arch/arm/mach-omap1/clock.h for seeing the
definition of different kind of clocks that are available for omap boards.

> We have cross-compiled the ALSA utils (aplay, arec & speaker-test) as
> also ALSA libraries separately & included the same in the file-system.
> Does ALSA require any configuration before we can use the utils?

I have only used the tsc2101 omap-alsa driver my self but there I do not
need any configuration for basic play testing.
I just use "alsamixer" for selecting the playback target and volume and
then "aplay music.wav" to play it. speaker-test should give some kind of
noice :-)

Mika

[-- Attachment #2: aic23_omap_alsa_clock_fix.patch --]
[-- Type: text/x-patch, Size: 887 bytes --]

diff -Naur ../1/sound/arm/omap/omap-alsa-aic23.c sound/arm/omap/omap-alsa-aic23.c
--- ../1/sound/arm/omap/omap-alsa-aic23.c	2006-05-03 21:44:17.000000000 +0300
+++ sound/arm/omap/omap-alsa-aic23.c	2006-05-03 22:12:42.000000000 +0300
@@ -212,6 +212,8 @@
  */
 int aic23_clock_on(void)
 {
+	uint	curRate;
+
 	if (clk_get_usecount(aic23_mclk) > 0) {
 		/* MCLK is already in use */
 		printk(KERN_WARNING
@@ -219,11 +221,13 @@
 		       (uint) clk_get_rate(aic23_mclk),
 		       CODEC_CLOCK);
 	}
-	
-	if (clk_set_rate(aic23_mclk, CODEC_CLOCK)) {
-		printk(KERN_ERR
-		       "Cannot set MCLK for AIC23 CODEC\n");
-		return -ECANCELED;
+	curRate	= (uint)clk_get_rate(aic23_mclk);
+	if (curRate != CODEC_CLOCK) {
+		if (clk_set_rate(aic23_mclk, CODEC_CLOCK)) {
+			printk(KERN_ERR
+			       "Cannot set MCLK for AIC23 CODEC\n");
+			return -ECANCELED;
+		}
 	}
 
 	clk_enable(aic23_mclk);

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 0/3] aic23 sound driver fixes

[James Selvam]

Hi Mika/All,

The patch set the MCLK error all right. It infact took the right CLK freq of
12 MHz:

Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04
08:57:20
2006 UTC).
MCLK = 12000000 [12000000], usecount = 1
audio support initialized
ALSA device list:
  #0: OMAP Innovator AIC23

But aplay -l still fails. It fails to recognise and list the hardware
present:

**** List of PLAYBACK Hardware Devices ****
ALSA lib control.c:818:(snd_ctl_open_noupdate) Invalid CTL hw:0
aplay: device_list:232: control open (0): No such file or directory

I then tried to do a simple "cat raw_file > /dev/dsp" (OSS emulation
enabled). It just gave me some noise. Another player "bplay" cross-compiled
for ARM gave similar results.

Clarifications:
1)  The ALSA is recognising the AIC23 hardware at bootup. But we find that
it is not accessible as can be seen from the aplay output.
2) Is there an explicit configuration of ALSA required before we can start
using it?
3) Does this configuraton involve manual binding of the hardware with the
application? If so then how?

Thanks,
James.

On 5/4/06, lamikr <lamikr@cc.jyu.fi> wrote:
>
> Hi
>
> James Selvam wrote:
>
> > Hi Mika/All,
> >
> > I am working on OMAP1510 Innovator (kernel 2.6.16.13+omap1). I applied
> > the patches sent here, but the second hunk containing the change of
> > function calls to "aic23_write_value" were not defined so I changed
> > them back to "tlv320aic23_write_value". But the platform related patch
> > was applied in toto.
>
> Yes, the patch-set was meant for the linux-omap git head as the
> drivers/i2c/chips/tlv320aic23.c used by the aic23 ALSA and OSS drivers
> has changed in git repository after the 2.6.16 omap kernel version.
>
> But if you are using 2.6.16 then you should just take the 3/3 of
> patchset. From 1/3 and 2/3 patches you may consider for taking the
> KConfig changes by hand as
> the I2C, I2C-OMAP and tlv320aic23 i2c drivers must always be selected if
> AIC23 alsa or oss driver is selected.
>
>
> > The kernel then recognised the AIC23 codec at bootup (which it was not
> > doing before). Also the I2C has set the MCBSP clocks 1 and 3. But ALSA
> > did throw up an error:
> >
> > Clock enabled to MCBSP1 & 3
> > tlv320aic23 powering up
> > tlv320aic23_init_power() done
> > TLV320AIC23 I2C version 1.8 (10-Feb-2006)
> >
> > Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04
> > 08:57:20 2006 UTC).
> > Cannot set MCLK for AIC23 CODEC
> > audio support initialized
> > ALSA device list:
> >   #0: OMAP Innovator AIC23
> >
> > Thereafter if we try to run an application it promts the same error
> > "Cannot set MCLK for AIC23 CODEC" and fails to recognise the device
> > present.
>
> That's propaply because the clock rate is already ok, or the clock rate
> is fixed and can not be changed.
> Could you check whether the attached patch will work for you? If it
> works, I will submit it in separate mail to be applied to
> git repository.
>
> >
> > Certain clarifications are required:
> > 1) Where is the definition of the function "aic23_write_value" -
> > specified in the first two patches?
>
> In OMAP git repository head following driver
> drivers/i2c/chips/tlv320aic23.c
>
> > 2) The MCLK not being set; the MCBSP clocks are set all right during
> > the bootup. Why then does it crib now?
>
> The attached patch should fix it, as it will check whether the clock is
> already using the correct rate.
> In future there may be need to change the alsa code a little bit more,
> so that the clock rate can be defined in the board code instead of
> hardcoding in the alsa driver as Menon Nishant suggested some time ago.
>
> > 3) Are the MCLK and the MCBSP clocks one and the same?
>
> It might help you to check arch/arm/mach-omap1/clock.h for seeing the
> definition of different kind of clocks that are available for omap boards.
>
> > We have cross-compiled the ALSA utils (aplay, arec & speaker-test) as
> > also ALSA libraries separately & included the same in the file-system.
> > Does ALSA require any configuration before we can use the utils?
>
> I have only used the tsc2101 omap-alsa driver my self but there I do not
> need any configuration for basic play testing.
> I just use "alsamixer" for selecting the playback target and volume and
> then "aplay music.wav" to play it. speaker-test should give some kind of
> noice :-)
>
> Mika
>
>
>

Re: [PATCH 0/3] aic23 sound driver fixes

[lamikr]

James Selvam wrote:

> Hi Mika/All,
>
> The patch set the MCLK error all right. It infact took the right CLK
> freq of 12 MHz:
>
> Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04
> 08:57:20
> 2006 UTC).
> MCLK = 12000000 [12000000], usecount = 1
> audio support initialized
> ALSA device list:
>   #0: OMAP Innovator AIC23
>
> But aplay -l still fails. It fails to recognise and list the hardware
> present:

Hmm, do you have udev installed and do you get nodes created to /dev/snd
directory?

>
> **** List of PLAYBACK Hardware Devices ****
> ALSA lib control.c:818:(snd_ctl_open_noupdate) Invalid CTL hw:0
> aplay: device_list:232: control open (0): No such file or directory
>
> I then tried to do a simple "cat raw_file > /dev/dsp" (OSS emulation
> enabled). It just gave me some noise. Another player "bplay"
> cross-compiled for ARM gave similar results.

So, you were able to hear something? I had some DMA problems with my
OMAP1510 based h6300 and therefore the omap-alsa.c has
#ifdef CONFIG_MACH_OMAP_H6300 in one place. You could try to enable that
also in your board?
For Daniel the AIC23 alsa code however worked with the OSK board without
need for the modifications.

Mika

Re: [PATCH 0/3] aic23 sound driver fixes

[James Selvam]

Hi Mika/All,

I have all the relavant nodes created in /dev/snd directory. This includes
controlCx, hwCxDy, midiCxDy, pcmCxDyc, pcmCxDyc, seq & timer.

I have also put the following three lines:

        spin_lock_irqsave(&s->dma_lock, flags);
        omap_stop_alsa_sound_dma(s);
        spin_unlock_irqrestore(&s->dma_lock, flags);

Any ideas about how to get this working? Is there something else missing?

Thanks,
James.



On 5/5/06, lamikr <lamikr@cc.jyu.fi> wrote:
>
> James Selvam wrote:
>
> > Hi Mika/All,
> >
> > The patch set the MCLK error all right. It infact took the right CLK
> > freq of 12 MHz:
> >
> > Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04
> > 08:57:20
> > 2006 UTC).
> > MCLK = 12000000 [12000000], usecount = 1
> > audio support initialized
> > ALSA device list:
> >   #0: OMAP Innovator AIC23
> >
> > But aplay -l still fails. It fails to recognise and list the hardware
> > present:
>
> Hmm, do you have udev installed and do you get nodes created to /dev/snd
> directory?
>
> >
> > **** List of PLAYBACK Hardware Devices ****
> > ALSA lib control.c:818:(snd_ctl_open_noupdate) Invalid CTL hw:0
> > aplay: device_list:232: control open (0): No such file or directory
> >
> > I then tried to do a simple "cat raw_file > /dev/dsp" (OSS emulation
> > enabled). It just gave me some noise. Another player "bplay"
> > cross-compiled for ARM gave similar results.
>
> So, you were able to hear something? I had some DMA problems with my
> OMAP1510 based h6300 and therefore the omap-alsa.c has
> #ifdef CONFIG_MACH_OMAP_H6300 in one place. You could try to enable that
> also in your board?
> For Daniel the AIC23 alsa code however worked with the OSK board without
> need for the modifications.
>
> Mika
>

Re: [PATCH 0/3] aic23 sound driver fixes

[James Selvam]

Hi Mika/All,

Im happy to inform you that the patches you sent have been tested and they
are found to be working fine on my Innovator 1510. There should be no
problem with it going into the git.

I was bogged down by a hardware snag on my Innovator kit which delayed the
verification. But I see its fine now. :-) .

Thanx for the help.

Regards,
James.


On 5/3/06, lamikr <lamikr@cc.jyu.fi> wrote:
>
> Following patch set should fix the broken method references to from Alsa
> and OSS drivers to tlv320aic23 i2c drivers that has been reported.
> In addition the 3:rd patch contains the platform driver code that the
> innovator requires if it wants to use alsa driver.
>
> I do not own myself the innovator or aic23 drivers so it would be nice
> if someone else could test these.
>
> Mika
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Re: [PATCH 0/3] aic23 sound driver fixes

[lamikr]

James

Thanks for the info, I have been quite busy but in Finland we have today
holiday so I have now time again to
prepare a new set of patches. Can you verify some issues that have
remained open.
Is it working for you without these lines in the audio_process_dma()
function. (in omap_alsa.c)

        spin_lock_irqsave(&s->dma_lock, flags);
        omap_stop_alsa_sound_dma(s);
        spin_unlock_irqrestore(&s->dma_lock, flags);

At least you added those lines once for there for testing. (I need to
use those with my omap1510 based device)

Mika

James Selvam wrote:

> Hi Mika/All,
>
> Im happy to inform you that the patches you sent have been tested and
> they are found to be working fine on my Innovator 1510. There should
> be no problem with it going into the git.
>
> I was bogged down by a hardware snag on my Innovator kit which delayed
> the verification. But I see its fine now. :-) .
>
> Thanx for the help.
>
> Regards,
> James.
>
>
> On 5/3/06, *lamikr* <lamikr@cc.jyu.fi <mailto:lamikr@cc.jyu.fi>> wrote:
>
>     Following patch set should fix the broken method references to
>     from Alsa
>     and OSS drivers to tlv320aic23 i2c drivers that has been reported.
>     In addition the 3:rd patch contains the platform driver code that the
>     innovator requires if it wants to use alsa driver.
>
>     I do not own myself the innovator or aic23 drivers so it would be nice
>     if someone else could test these.
>
>     Mika
>     _______________________________________________
>     Linux-omap-open-source mailing list
>     Linux-omap-open-source@linux.omap.com
>     <mailto:Linux-omap-open-source@linux.omap.com>
>     http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>     <http://linux.omap.com/mailman/listinfo/linux-omap-open-source>
>
>

Re: [PATCH 0/3] aic23 sound driver fixes

[James Selvam]

Hi Mika

> James
>
> Thanks for the info, I have been quite busy but in Finland we have today
> holiday so I have now time again to
> prepare a new set of patches.


Good to have you back... :-)


Can you verify some issues that have
> remained open.
> Is it working for you without these lines in the audio_process_dma()
> function. (in omap_alsa.c)
>
>         spin_lock_irqsave(&s->dma_lock, flags);
>         omap_stop_alsa_sound_dma(s);
>         spin_unlock_irqrestore(&s->dma_lock, flags);


I had to add these lines to get it to work. It does not work without these
lines. I had added these lines while testing the patches you had sent.

At least you added those lines once for there for testing. (I need to
> use those with my omap1510 based device)


I think it is not a h6300 specific requirement (as present in the code) but
a more generic OMAP 1510 requirement (atleast Innovator OMAP 1510 definitely
requires it).

Mika


James.

James Selvam wrote:
>
> > Hi Mika/All,
> >
> > Im happy to inform you that the patches you sent have been tested and
> > they are found to be working fine on my Innovator 1510. There should
> > be no problem with it going into the git.
> >
> > I was bogged down by a hardware snag on my Innovator kit which delayed
> > the verification. But I see its fine now. :-) .
> >
> > Thanx for the help.
> >
> > Regards,
> > James.
> >
> >
> > On 5/3/06, *lamikr* <lamikr@cc.jyu.fi <mailto:lamikr@cc.jyu.fi>> wrote:
> >
> >     Following patch set should fix the broken method references to
> >     from Alsa
> >     and OSS drivers to tlv320aic23 i2c drivers that has been reported.
> >     In addition the 3:rd patch contains the platform driver code that
> the
> >     innovator requires if it wants to use alsa driver.
> >
> >     I do not own myself the innovator or aic23 drivers so it would be
> nice
> >     if someone else could test these.
> >
> >     Mika
> >     _______________________________________________
> >     Linux-omap-open-source mailing list
> >     Linux-omap-open-source@linux.omap.com
> >     <mailto:Linux-omap-open-source@linux.omap.com>
> >     http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> >     <http://linux.omap.com/mailman/listinfo/linux-omap-open-source>
> >
> >
>
>

Re: [PATCH 0/3] aic23 sound driver fixes

[lamikr]

>
>
>     Can you verify some issues that have remained open.
>     Is it working for you without these lines in the audio_process_dma()
>     function. (in omap_alsa.c)
>
>             spin_lock_irqsave(&s->dma_lock, flags);
>             omap_stop_alsa_sound_dma(s);
>             spin_unlock_irqrestore(&s->dma_lock, flags);
>
>
> I had to add these lines to get it to work. It does not work without
> these lines. I had added these lines while testing the patches you had
> sent.
>
>     At least you added those lines once for there for testing. (I need to
>     use those with my omap1510 based device) 
>
>
> I think it is not a h6300 specific requirement (as present in the
> code) but a more generic OMAP 1510 requirement (atleast Innovator OMAP
> 1510 definitely requires it).

Thanks for the info, I will send patch immediately. Or does others have
any better idea to handle this in omap1510?

Mika