2009-01-27 03:31:38 uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 68375

We occasionally see the following sound quality problem with AD1980 AC97 codec, connected to ADSP-BF537 processor under uClinux. We have in total 13 different prototype boards, designed the same exact way as BF-537-STAMP and all of them some times show this problem. We are using the kernel from uClinux-dist-2008R1-RC8. Schematic (ac97 interconnections) is attached to this post.

1) Occasionally the sound quality becomes very bad (seems that the high and low bytes of the 16bit data get muddled up, or one sending packet for one frame sync gets lost).

2) At that time the volume becomes 0, and the registers contain default values (not all of them though, the 16bit slots still are switched on), while no reset usage. See table below.

Could you describe to us, what is happening with the codec? Is it a problem with the frame sync active-high pulse width (it should be 1.3us according to the datasheet, but we observe 81.6ns - its 16 times shorter), and if yes how could we fix it? Is it possible to setup SPORT in multichannel mode and TFS width equal to 16 serial cycles? What can be a reason of the registers resetting during the playback?

The registers states before volume loss and after the failure:

# before after

0 90 90

2 202 8000

4 0 8000

6 0 8000

8 0 0

a 0 0

c 0 8008

e 8008 8008

10 909 8808

12 8808 8808

14 0 0

16 8808 8808

18 606 8808

1a 404 0

1c f0f 8000

1e 0 0

20 0 0

22 0 0

24 0 0

26 f f

28 3c3 3c3

2a 1f0 1f0

2c bb80 bb80

2e bb80 bb80

30 bb80 bb80

32 bb80 bb80

34 0 0

36 404 8080

38 101 8080

3a 2000 2000

3c 0 0

3e 0 0

40 0 0

42 0 0

44 0 0

46 0 0

48 0 0

4a 0 0

4c 0 0

4e 0 0

50 0 0

52 0 0

54 0 0

56 0 0

58 0 0

5a 0 0

5c 0 0

5e 0 0

60 8080 8080

62 0 0

64 0 0

66 0 0

68 0 0

6a 0 0

6c 0 0

6e 0 0

70 0 0

72 0 0

74 9000 9000

76 0 0

78 0 0

7a 0 0

7c 4144 4144

7e 5370 5370

AC97part.pdf

QuoteReplyEditDelete

2009-01-27 07:46:19 Re: uClinux+BF537+problems with AC97 codec

Robin Getz (UNITED STATES)

Message: 68394

Pavel:

Try putting a cap (like ~30pF) on the frame sync, and the clock lines - and see if that helps.

Otherwise our SPORT/AC97 guru is out for this week on holidays.

-Robin

QuoteReplyEditDelete

2009-01-27 10:23:46 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 68406

Thank you, we will try this solution. One another problem, that we have on other board (may be the same problem?): while coping data from /dev/dsp (linein) to /dev/dsp (pcm) for a long time we have got kernel crush.

bf5xx_ac97_write enter 0x36:0x1d1d

sport_send_and_recv enter, out_data:00259d0c, in_data:00000000 len:20

tcr1:0x0200, tcr2:0x000f, tclkdiv:0x0000, tfsdiv:0x00ff

mcmc1:0x1000, mcmc2:0x101c

sport status:0x0008

sport status:0x0055

sport_tx_start: tx_run:0, rx_run:0

sport_config_rx_dma buf:01ea0000, frag:16, fragsize:0xa000

sport_config_rx_dma(x_count:0x5000, y_count:0x0)

setup desc: desc0=01f43000, next0=1f43012, desc1=01f43012,next1=1f43024

x_count=5000,y_count=0,addr=0x1ea0000,cfs=0x7987

Apbk pafsed:5Got xadeix 0 2_00 [a5]c97_write enter 0x38:0x9c9c

sport->tx_buf:01e00000, nextfrag:0x3 nextwrite:01e1e000, cmd_count:8

ac97_sport: Inserting 38/9c9c into fragment 1 1 tag=0x6000 cmdcount8

sport_rx_start enter

bf5xx_ac97_write enter 0x38:0x1c1c

sport_send_and_recv enter, out_data:00259d0c, in_data:00000000 len:20

tcr1:0x0201, tcr2:0x000f, tclkdiv:0x0000, tfsdiv:0x00ff

mcmc1:0x1000, mcmc2:0x101c

tx dma is already stopped

err_handler

sport status error: TUVF

DMA status:0x000a

MA status:0x000a

DMA status:0x000a

...

DMA status:0x000a

sport_config_tx_dma buf:01e00000, fragcount:16, fragsize:0xa000

sport_config_tx_dma x_count:0x5000, y_count:0x0

setup desc: desc0=01f42000, next0=1f42012, desc1=01f42012,next1=1f42024

x_count=5000,y_count=0,addr=0x1e00000,cfs=0x7985

sport_tx_start: tx_run:0, rx_run:1

ac97_write enter 0x38:0x1b1b6_0

...nextfrag:0x195ce nextwrite:ff80c000, cmd_count:0

External Memory Addressing Error

Kernel OOPS in progress

HW Error context

CURRENT PROCESS:

COMM=Apek PID=228

TEXT = 0x01be8000-0x01be99ec DATA = 0x0025b9ec-0x0025bd20

BSS = 0x0025bd20-0x00260000 USER-STACK = 0x0027fed0

return address: [0x000f1a72]; contents of:

0x000f1a50: 4e46 5e8a 9110 b130 e140 0018 e100 8324

0x000f1a60: e3f8 e12a 9161 af32 42ed 5e91 9152 5e92

0x000f1a70: 5e95 [e490] 0001 9911 4f40 5608 e121 6000

0x000f1a80: 5608 9b10 4e40 e690 0001 af32 6000 5e91

SEQUENCER STATUS: Not tainted

SEQSTAT: 0000e03f IPEND: 8030 SYSCFG: 0006

HWERRCAUSE: 0x3

EXCAUSE : 0x3f

physical IVG15 asserted : <0xffa00e14> { _evt_system_call + 0x0 }

logical irq 6 mapped : <0xffa00364> { _timer_interrupt + 0x0 }

logical irq 12 mapped : <0x000f1ff4> { _rx_handler + 0x0 }

logical irq 13 mapped : <0x000f1f94> { _tx_handler + 0x0 }

logical irq 18 mapped : <0x000acbbc> { _bfin_serial_dma_rx_int + 0x0 }

logical irq 19 mapped : <0x000acb28> { _bfin_serial_dma_tx_int + 0x0 }

logical irq 20 mapped : <0x000acbbc> { _bfin_serial_dma_rx_int + 0x0 }

logical irq 21 mapped : <0x000acb28> { _bfin_serial_dma_tx_int + 0x0 }

logical irq 24 mapped : <0x000b4f90> { _bfin_mac_interrupt + 0x0 }

logical irq 45 mapped : <0x000f339c> { _err_handler + 0x0 }

logical irq 54 mapped : <0x01aab0bc> { :gpio_keys:_show_reset_state + 0x38 }

logical irq 55 mapped : <0x01aab0bc> { :gpio_keys:_show_reset_state + 0x38 }

logical irq 56 mapped : <0x01aab0bc> { :gpio_keys:_show_reset_state + 0x38 }

logical irq 57 mapped : <0x01aab0bc> { :gpio_keys:_show_reset_state + 0x38 }

logical irq 58 mapped : <0x01aab0bc> { :gpio_keys:_show_reset_state + 0x38 }

logical irq 59 mapped : <0x01aab0bc> { :gpio_keys:_show_reset_state + 0x38 }

logical irq 74 mapped : <0x000c9624> { _usb_hcd_irq + 0x0 }

logical irq 76 mapped : <0x01b9106c> { :bf537_trackball:_init_module + 0xabc6c }

logical irq 77 mapped : <0x01b9106c> { :bf537_trackball:_init_module + 0xabc6c }

logical irq 78 mapped : <0x01aab0bc> { :gpio_keys:_show_reset_state + 0x38 }

RETE: <0x00000000> /* Maybe null pointer? */

RETN: <0x0025a000> /* unknown address */

RETX: <0x0040de00> [ /lib/libuClibc-0.9.29.so + 0xde00 ]

RETS: <0x000f1a64> { _bf5xx_ac97_write + 0x94 }

PC : <0x000f1a72> { _bf5xx_ac97_write + 0xa2 }

PROCESSOR STATE:

R0 : 0000004c R1 : 00000001 R2 : 0000001f R3 : 0000001f

R4 : 000195cc R5 : 00001b1b R6 : 00000038 R7 : 00259d28

P0 : 0000000a P1 : 01a91000 P2 : ff80c000 P3 : 019790a0

P4 : 001afa58 P5 : ff80c000 FP : 00259e7c SP : 00259c1c

LB0: ffa018a8 LT0: ffa01888 LC0: 00000000

LB1: 000945ac LT1: 000945a0 LC1: 00000000

B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 0000000f

B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 00000000

B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 0000001b

B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000

A0.w: 05da872b A0.x: 00000000 A1.w: 0000304f A1.x: 00000000

USP : 0027fc00 ASTAT: 02002040

Hardware Trace:

0 Target : <0x000045a4> { _trap_c + 0x0 }

Source : <0xffa00d42> { _evt_ivhw + 0x7e }

1 Target : <0xffa00cc4> { _evt_ivhw + 0x0 }

Source : <0x000f1a70> { _bf5xx_ac97_write + 0xa0 }

2 Target : <0x000f1a64> { _bf5xx_ac97_write + 0x94 }

Source : <0x0000dcca> { _printk + 0x16 }

3 Target : <0x0000dcc6> { _printk + 0x12 }

Source : <0x0000db7c> { _vprintk + 0x1b8 }

4 Target : <0x0000db70> { _vprintk + 0x1ac }

Source : <0xffa00cc2> { __common_int_entry + 0xca }

5 Target : <0xffa00c60> { __common_int_entry + 0x68 }

Source : <0xffa00ac2> { _return_from_int + 0x4e }

6 Target : <0xffa00ac2> { _return_from_int + 0x4e }

Source : <0xffa00aa2> { _return_from_int + 0x2e }

7 Target : <0xffa00a74> { _return_from_int + 0x0 }

Source : <0xffa00c5c> { __common_int_entry + 0x64 }

8 Target : <0xffa00c5a> { __common_int_entry + 0x62 }

Source : <0xffa00330> { _asm_do_IRQ + 0x6c }

9 Target : <0xffa00328> { _asm_do_IRQ + 0x64 }

Source : <0x00011d16> { __local_bh_enable + 0x3e }

10 Target : <0x00011cd8> { __local_bh_enable + 0x0 }

Source : <0x00011e20> { ___do_softirq + 0x94 }

11 Target : <0x00011e18> { ___do_softirq + 0x8c }

Source : <0x00011df8> { ___do_softirq + 0x6c }

12 Target : <0x00011dec> { ___do_softirq + 0x60 }

Source : <0x00011f00> { _tasklet_action + 0x7c }

13 Target : <0x00011efa> { _tasklet_action + 0x76 }

Source : <0x00011ed6> { _tasklet_action + 0x52 }

14 Target : <0x00011ed4> { _tasklet_action + 0x50 }

Source : <0x000a392a> { _tty_wakeup + 0x2a }

15 Target : <0x000a3924> { _tty_wakeup + 0x24 }

Source : <0x000097b8> { ___wake_up + 0x2c }

Stack from 00259bfc:

00000000 ffa00d46 ff80c000 00259d28 00000038 0000000f 0027fc00 001b4ff0

0040de00 00008030 0000e03f 00000000 0025a000 0040de00 000f1a72 000f1a64

0000004c 02002040 000945ac ffa018a8 000945a0 ffa01888 00000000 00000000

0000304f 00000000 05da872b 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 0000001b 00000000 0000000f 0027fc00 00259e7c ff80c000 001afa58

Call Trace:

[<00001b1b>] _arch_ptrace+0x9b/0x494

[<000195cc>] _sys_reboot+0x110/0x180

[<000195ce>] _sys_reboot+0x112/0x180

[<00001c1c>] _arch_ptrace+0x19c/0x494

[<000408f4>] _core_sys_select+0x124/0x224

[<000195ce>] _sys_reboot+0x112/0x180

[<000f0ebe>] _ac97_write+0x22/0x3c

[<00001b1b>] _arch_ptrace+0x9b/0x494

[<00001f1f>] _get_vco+0xb/0x2c

[<0013ec84>] _mutex_lock+0xc/0x40

[<000ee7c2>] _snd_soc_update_bits+0x46/0x5c

[<000099a4>] ___wake_up_sync+0x24/0x44

[<000117ac>] _current_fs_time+0x14/0x1c

[<000ee8c6>] _snd_soc_put_volsw+0x7e/0x88

[<00001b00>] _arch_ptrace+0x80/0x494

[<00033e10>] _kmem_cache_alloc+0x50/0x6c

[<000e747a>] _snd_mixer_oss_conv2+0x12/0x18

[<00001b1b>] _arch_ptrace+0x9b/0x494

[<000e8676>] _snd_mixer_oss_put_volume1_vol+0xba/0xf8

[<000e875c>] _snd_mixer_oss_put_volume1+0xa8/0x144

[<000a9f68>] _uart_start+0xc/0x28

[<000e75a6>] _snd_mixer_oss_ioctl1+0x7e/0x638

[<000a5b8e>] _write_chan+0x162/0x29c

[<000097a0>] ___wake_up+0x14/0x30

[<0000ffff>] _do_wait+0x99b/0xa08

[<0000a0cc>] _default_wake_function+0x0/0x10

[<000a1e6a>] _tty_write_unlock+0x26/0x30

[<00005da0>] _do_gettimeofday+0x30/0xa0

[<0003fa4a>] _do_ioctl+0x1a/0x4c

[<0003fac8>] _vfs_ioctl+0x4c/0x1e4

[<0001fc54>] _ktime_get_ts+0x20/0x4c

[<0003fc88>] _sys_ioctl+0x28/0x54

[<0003fc60>] _sys_ioctl+0x0/0x54

[<0001ca6e>] _sys_clock_gettime+0x46/0x98

[<0000fffe>] _do_wait+0x99a/0xa08

[<00008000>] __l1_sram_free+0x7c/0xb4

[<00002000>] _get_sclk+0x10/0x58

[<0000304f>] _do_signal+0x3ff/0xcd0

Thanks for any guess-work.

QuoteReplyEditDelete

2009-01-27 23:18:08 Re: uClinux+BF537+problems with AC97 codec

Robin Getz (UNITED STATES)

Message: 68446

Pavel:

If something is going wrong with the hardware - it could cause the driver to do unexpected things.

That being said - it still shouldn't cause the kernel to randomly crash...

However - The developer who did all the AC97 work is out for the rest of this week -- and will be back on Monday.

-Robin

QuoteReplyEditDelete

2009-02-01 21:39:23 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 68645

Pavel,

Would you please tell me your detailed test cases which cause the codec to reset state,and if it also occurs on BF537-STAMP?

Thanks

Cliff

QuoteReplyEditDelete

2009-02-03 05:26:31 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 68718

Our board is based on bf537-stamp, but instead of original audio codec ad1980 was installed on SPORT0 (like on bf548ez-kit). We are using our applications: one of them is plaing music using /dev/dsp (44100KHz, Stereo, 16bit), sometimes it swithed to plaing music from line-in (48000KHz, Stereo, 16bit) i.e. coping data from /dev/dsp and writing to /dev/dsp. Another our application uses /dev/mixer to make fadein/fadeout for vol, pcm, linein channels between songs. It works ok, and iven when volume losses, mixer vol, mixer pcm, mixer line show us one state, while the real states of ac97 codec registers have the different values. Our aplication, that uses /dev/mixer dosn't change some regisers, that become wrong.

QuoteReplyEditDelete

2009-02-13 05:22:13 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 69410 I have tried rc filter (33 Ohm and 30pF) on clock and frame. But it didn't help me. Sometimes we still have register reseting. It takes place on last svn kernel too. As a temporarily fix, I make registers update after each track, and removed checking for registers change in snd_soc_update_bits() function to be sure that real value will be written.

QuoteReplyEditDelete

2009-03-12 23:45:06 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 70901

1.I have a question about the AUDIO_RST line on your schematic,does it be connected to the reset pin of SPORT?

2.it's quite stange that long time record/play will call bf5xx_ac97_write in your crash case.

Cliff

QuoteReplyEditDelete

2009-03-13 03:41:14 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 70928 AUDIO_RST connected to PG9 pin (it is selected properly in linux .config file and hardware reset works) of bf537 and Reset pin of ad1980. It was investigated, that no glitches and noise on AUDIO_RST.

QuoteReplyEditDelete

2009-03-13 04:14:17 Re: uClinux+BF537+problems with AC97 codec

Sonic Zhang (CHINA)

Message: 70930

Do you have a simple test application for us to replicate your proble on our bf537-stamp board?

QuoteReplyEditDelete

2009-03-13 04:21:43 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 70943

Pavel,

I think it's hard to guess what causes this problem.

I have a BF537-STAMP and a AD1981 add-on card in hand,Only if I'm able to reproduce your problem, then I will try to sovle it,So you'd better tell me your detailed test cases,that I can run them on my board.

Thanks

Cliff

QuoteReplyEditDelete

2009-03-13 05:39:29 Re: uClinux+BF537+problems with AC97 codec

Sonic Zhang (CHINA)

Message: 70944

Did you run the other sound control application concurrently with recording and playing?

We tested the similar test case "arecord | aplay" against ad1980 and bf537-stamp for at least one day without your crash.

QuoteReplyEditDelete

2009-03-13 06:03:03 Re: uClinux+BF537+problems with AC97 codec

Sonic Zhang (CHINA)

Message: 70945

Could you paste your mixer C code here? Or at least list the detail command line steps?

Such as:

root:/> arecord -t wav -c 2 -f format -r rate -d 50 | aplay &

root:/> mixer mic 50

QuoteReplyEditDelete

2009-03-13 07:21:04 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 70947 No, I haven't. Our application uses wma decoder, so it is impossible to send. I will prepare test version next week, will try to reproduce such behavior, and i'll give you souces or/and applications and cases how to reproduce. Thank you.

QuoteReplyEditDelete

2009-03-13 07:31:36 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 70948 No. /dev/dsp opened only ones. I tryed to reproduce it by script, that makes arecord|aplay and in parallel changing mixer vol. It caused crashes too. Now for us this problem not so critical. In furure if I have time, I will turn to this problem. Thanks.

QuoteReplyEditDelete

2009-03-13 07:32:55 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 70949 I will prepare test version next week, will try to reproduce such behavior, and i'll give you souces or/and applications and cases how to reproduce. Thank you.

QuoteReplyEditDelete

2009-03-20 10:49:53 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 71308

Helo.

I'm sending tar.gz, that contains:

1) Apek - application, used to control /dev/mixer (volume setting, fadein, fadeout) by commands sending to /tmp/Apek_pipe fifo. It sould be run in background.

2) codectest - during make procedure it produces 3 applications:

codectest: 44100Hz playback emulation and swithing to 48000Hz plaback from linein

codectest1: the same, but in addition it uses Apek to fade in/out sound (the most close to our situation when registers resets)

codectest2: the same as codectest, but without fix; It always hangs up kernel without any debug information.

3) sound.diff - changes in sound driver, mostly to enable playback on 3 outputs.

Thank you for your help.

PS: codectest should be started for about 24h to see volume loss. Somtimes this test results in bad quallity while playing from linein. Could you say why?

test.tar.gz

QuoteReplyEditDelete

2009-03-22 23:48:40 Re: uClinux+BF537+problems with AC97 codec

Sonic Zhang (CHINA)

Message: 71357

You changed a lot to the ad1980 driver. We will try your applications on our SVN tree without your patch against the drvier. If there is no problem for 24 hours. The issue may be in your driver patch.

QuoteReplyEditDelete

2009-03-25 06:22:46 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 71515

The Apek and codectest1 has been running on my borad now.Trying to turn down the input for linein to see if the bad quality case still happen.

The crash may be caused by some code in sport driver

just commet following code in bf5xx_sport.c:

in sport_tx_start()

bf5xx_ac97_write(NULL, 0x02, (u16)cache[0x02 >> 1]);

bf5xx_ac97_write(NULL, 0x18, (u16)cache[0x18 >> 1]);

in sport_tx_stop()

bf5xx_ac97_write(NULL, 0x02, 0x8000);

bf5xx_ac97_write(NULL, 0x18, 0x8000);

and they have been removed from 08r1.5

I've added some printks in the driver,hope it can tell us what has happened when codec reset.

By the way, I didn't select "Enable True MMAP Support " in Kconfig.

Cliff

QuoteReplyEditDelete

2009-03-25 07:07:45 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 71518 I'm using 8r1.5, so there is no such code in bf5xx_sport.c and "Enable True MMAP Support" not selected too. I will repeat tests with the original sound drivers. Thank you.

QuoteReplyEditDelete

2009-03-25 22:39:09 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 71567

But your patch can't be applied to 08r1.5.I just apply it to 08r1-rc8.

I've run the applications a whole night and the SPORT got underrun and kernel rebooted at last.

I will remove sleep after write in your test code and try again.

One more thing,since you've changed the ac97_frame,some related code is needed to be changed as well,I guess this is the cause of bad quality.I will check in the change.

Cliff

QuoteReplyEditDelete

2009-03-26 14:04:17 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 71617

Please could you try this changes in soc bf5xx driver:

bf5xx-ac97.c:

void bf5xx_ac97_pcm32_to_frame(struct ac97_frame *dst, const __u32 *src, \

size_t count)

{

while (count--) {

dst->ac97_tag = TAG_VALID | TAG_PCM | TAG_PCM2;

(dst)->ac97_pcm = *src;

(dst)->ac97_slot6 = (*src)&0x0FFFF;

(dst)->ac97_slot9 = (*src)>>16;

(dst)->ac97_pcm2 = *src;

dst++;

src++;

}

void bf5xx_ac97_frame_to_pcm32(const struct ac97_frame *src, __u32 *dst, \

size_t count)

{

while (count--) {

*(dst) = src->ac97_pcm;

dst++;

src++;

}

and instead of sport_set_multichannel(sport_handle, 16, 0x1F, 1); I use sport_set_multichannel(sport_handle, 16, 0x3FF, 1); to enable additional slots.

bf5xx-ac97.h:

struct ac97_frame {

u16 ac97_tag; /* slot 0 */

u16 ac97_addr; /* slot 1 */

u16 ac97_data; /* slot 2 */

u32 ac97_pcm; /* slot 3 and 4: left and right pcm data */

u16 ac97_slot5; /* slot 5 */

u16 ac97_slot6; /* slot 6 */

u32 ac97_pcm2; /* slot 7 and 8*/

u16 ac97_slot9; /* slot 5 */

} __attribute__ ((packed));

#define TAG_VALID 0x8000

#define TAG_CMD 0x6000

#define TAG_PCM_LEFT 0x1000

#define TAG_PCM_RIGHT 0x0800

#define TAG_PCM (TAG_PCM_LEFT | TAG_PCM_RIGHT)

#define TAG_SLOT5 0x0400

#define TAG_SLOT6 0x0200

#define TAG_PCM2_RIGHT 0x0100

#define TAG_PCM2_LEFT 0x0080

#define TAG_SLOT9 0x0040

#define TAG_PCM2 (TAG_PCM2_LEFT | TAG_PCM2_RIGHT | TAG_SLOT5 | TAG_SLOT6 | TAG_SLOT9)

bf5xx-sport.c: in sport_init() function:

dummy_dst->ac97_tag = TAG_VALID | TAG_PCM | TAG_PCM2;

Thank you.

QuoteReplyEditDelete

2009-03-30 05:39:29 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 71775

Pavel,

I've added this problem to bug tracker.see:https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=5025

I will update it as soon as I get any new idea.

Cliff

QuoteReplyEditDelete

2009-04-02 09:35:27 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 72047 I've postet new problem with quallity losses, that very close to this problem https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&forum_id=39&_forum_action=ForumMessageBrowse&thread_id=33360 It takes place during reseting and reconfiguring AD1980.

QuoteReplyEditDelete

2009-04-25 11:57:01 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 73226

Now I have some additional information about codec reset and quallity losses (adter switching sample rate).

1) I wrote test application that generates sin to the ad1980's out; reading from linein(signal loopback should be connected from output to linein); calculating fft and analysing differences to original sin; ones per ~5 sec I swith frequency from 44100 to 48000 Hz.

2) I've got volume losses on my old linux revision: volume become zero, it seems to be codec warm reset.

3) On kernel revision 6039 (sound/soc - the same revision without my changes), I havent such problem, but I still have problem with quallity - white noise instead of sin.

4) When I looked to Frame/Data signals on codec pins, I notised that data slots were moved.

You can see it in attachment - one of data slot was on the place where slot configuration should be present, and slod configuration was moved to slot1. Sometimes It's appered with ROVF error flag in driver, but sometines without any error. OriginalSignal.png and BadSignal.png are attached to show original signal and corrupded waveforms.

5) In addition I'll send my application (losstest). It shows Passed message in case of good signal. And asking about continue to test in case when left and right channels have wrong signal (waiting 5 min or pressing "y" will continue test). In such situation you can hear wrong signal and see strange frame/dataout (but sometimes test makes a mistake in determining wrong situation).

Have you any ideas about problems? Thanks a lot.

OriginalSignal.PNG

losstest.tar.gz

BadSignal.PNG

QuoteReplyEditDelete

2009-04-26 22:21:39 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 73244

Pavel,

Thanks,it seems srtaight forward to me that ,there is unwanted remaining data in the tx fifo.

I will check it,and let you know the result.

Cliff

QuoteReplyEditDelete

2009-05-04 04:52:16 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 73551 Could you give me some hints what to do or where to look for, please. I haven't time to wait for fixes/commits. Thanks.

QuoteReplyEditDelete

2009-05-04 07:55:04 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 73560

Pavel,

I haven't got a solution for this problem yet.

The way I've tried these days is :sending up remaining data in tx fifo after stopping sport, and these remaining data should be all 0.

Since we pack the ac97 frames in memory,I think it's safe to sent "0" ac97 frames to codec before we want to stop playback.

attched file shows the places to look for.

Cliff

08r1_ad1980.patch

QuoteReplyEditDelete

2009-05-04 09:40:38 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 73563 Thank you for your patch. We are testing audio driver behaviour (with old kernel 08r1 and rev6039). It seems to be better - now there was not quallity problem. Now I have one question, that is not directly connected with this thread: Is it correct to call sport_set_multichannel(sport_handle, 16, 0x1F, 1) in multichannel mode? I am using sport_set_multichannel(sport_handle, 16, 0x3DF, 1) to enable slot0-slot4 and slot6-slot9. Best regards. Pavel

QuoteReplyEditDelete

2009-05-04 21:31:33 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 73599

Pavel,

According to the spec of sport,among the multichannle related registers,only the MTCSn and MRCSn are allowed to be configured on the fly.So,I think,you'd better implement a new function to do the channels selection job.

Cliff

QuoteReplyEditDelete

2009-05-11 10:21:30 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 73951

With you patch it was notices that kernel crashes after vpay or tone and then changing volume:

> tone

> mixer vol 80

Stack info:

SP: [0x0045bf24]

Memory from 0x0045bf20 to 0045c000

0045bf20: 00000005 [0060dd78] 00008000 00000000 00000000 0045c000 0060dd78 0060dd78

0045bf40:<00bceef6><ffa00d1c> 02000020 00bcf123 006224a7 00bcf122 00622494 00000000

0045bf60: fffffffd 000036c5 00000000 0406e979 00000000 00000000 00000000 00000000

0045bf80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0045bfa0: 00000000 00000000 00000000 006fd1a8 00639fdc 0047fc00 0047fc10 006fcc34

0045bfc0: 006fcb70 00449470 00bcf96c 0060dd64 00000036 00000000 00000000 00000005

0045bfe0: 00000000 00000005 0047fc3c c0044d03 00000005 00000005 00000036 00000006

0045c000: a9398009

Return addresses in stack:

address :

Modules linked in: bf537_trackball gpio_keys

Kernel panic - not syncing: Kernel exception

When I run tone& and mixer vol 80 in parallel - everything works ok.

Thanks.

Pavel.

QuoteReplyEditDelete

2009-05-11 15:22:28 Re: uClinux+BF537+problems with AC97 codec

Robin Getz (UNITED STATES)

Message: 73962

Pavel:

Is that all the crash info? there should be more...

-Robin

QuoteReplyEditDelete

2009-05-11 22:37:35 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 73971

Pavel:

Please try the new patch.

Cliff

08r1_ad1980_2nd.patch

QuoteReplyEditDelete

2009-05-27 04:14:19 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 74633

I noticed one strange behaviour: In my case there are a lot ot change volume commands to ac97codec. After 4-5 testing hours, all retriements to change volume while playback started didn't affect to real volume (so enqueue_cmd didn't work) When I looked to cmd_count[...] it value was near 40000. In code this counters always increased and can exceed value of (nextfrag*sport->tx_fragsize). What is the right solution for this bug? I tried to limit all cmd_count[nextfrag] by nextfrag * sport->tx_fragsize, and set it to zero on exceed. It helps to change volumes during playback (after 6-12 hours), but still some commands not affect on ac97 codec and somtimes I hear jerks during smooth volume changing.

Thanks.

QuoteReplyEditDelete

2009-05-30 19:37:12 Re: uClinux+BF537+problems with AC97 codec

Robin Getz (UNITED STATES)

Message: 74825

Pavel:

Just FYI:

According to:

www.analog.com/en/audiovideo-products/audio-codecs/ad1981b/products/product.html

www.analog.com/en/audiovideo-products/audio-codecs/ad1981bl/products/product.html

www.analog.com/en/audiovideo-products/audio-codecs/ad1980/products/product.html

www.analog.com/en/audiovideo-products/audio-codecs/ad1986/products/product.html

www.analog.com/en/audiovideo-products/audio-codecs/ad1819b/products/product.html

They have all been obsoleted. I would try to pick a different ADI codec (I2S).

Non-ADI AC'97 codecs will not work - since the driver used them in a non-standard slot 16-mode (which no one else supports).

Sorry.

-Robin

QuoteReplyEditDelete

2009-06-01 02:04:59 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 74887 Yes, we are using AD1980. Any other ideas? May be after some test I will provide one fix for enqueue_cmd.

QuoteReplyEditDelete

2009-06-01 04:42:53 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 74911 Cliff, I've tested your patch a lot. It really fixes the bug with quallity loss. Thanks. But I still have problem with volume losses.

QuoteReplyEditDelete

2009-06-01 09:31:43 Re: uClinux+BF537+problems with AC97 codec

Robin Getz (UNITED STATES)

Message: 74918

Pavel:

What functions on the 1980 are you using - just 6 out?

QuoteReplyEditDelete

2009-06-01 10:21:29 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 74923 It is small description of ad1980 usage on my board with BF537: I am using 3 output. My application playing tracks for a long period. At the end of track, application is making fade out on all 3 output using /dev/mixer (approximately 90 ioctls to set volume). At beginning of the track application is makeing fade in (~90 ioctls). So I have a lot of enqueue_cmd function calls that can cause to cmd_count[nextfrag] overflow. Pavel.

QuoteReplyEditDelete

2009-06-01 14:16:23 Re: uClinux+BF537+problems with AC97 codec

Robin Getz (UNITED STATES)

Message: 74930

Pavel:

So -- no need for inputs?

Why not just use the AD1836A?

-Robin

QuoteReplyEditDelete

2009-06-02 04:37:10 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 75005 Sorry, I didn't understand your hint to use I2S. Some times application swithes to playback from line in. Another reason to use ad1980 codec is to comply with customer's requirements (using ac97 codec). Pavel.

QuoteReplyEditDelete

2009-06-06 12:53:58 Re: uClinux+BF537+problems with AC97 codec

Robin Getz (UNITED STATES)

Message: 75298

Pavel:

>Another reason to use ad1980 codec is to comply with customer's requirements (using ac97 codec).

The reason to specify "AC97" is in order that you can replace one vendor with another. The issue at hand is -- you can't do tha with the existing hardware/driver - we don't drive the codec with a AC'97 bitstream - it is not possible to do with the SPORT. - the bitstream which comes out is a slot-16 mode. - the only codecs which support this are all being obsoleted. You (and your customer) will not be able to purchase them after November 6, 2009. You can't replace them with any other AC'97 codec -- since no one else suppports the bitstream that comes out of the SPORT.

Understand?

If the customer _requires_ AC97 - you can't use the Blackfin anymore.

If they just want audio - use an I2S codec.

-Robin

QuoteReplyEditDelete

2009-06-08 02:40:47 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 75306 Thank you for such detailed description. Last week we tried to find a solution with our customer for this reason.

QuoteReplyEditDelete

2009-06-19 17:35:19 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 76063 Again, here is my previous unanswered question: I noticed one strange behavior: I observe a lot of commands sent to to ac97codec for the volume change, used for fade-in and fade-out. After 4-5 hours of testing all attempts to change the volume while playback has been started do not affect any volume changes (in this case enqueue_cmd does not work). When I looked at cmd_count[...], its value was near 40000. In your driver code this counter is always incremented and can exceed the value of (nextfrag*sport->tx_fragsize). What is the correct solution for this problem? I tried to limit all cmd_count[nextfrag] by nextfrag * sport->tx_fragsize, and set it to zero when this value has been exceed. It helps to change the volume during the playback (after 6-12 hours), but still some commands do not affect the ac97 codec and sometimes the hiccups in the sound stream are heard during the smooth volume change (such as fade-in and out). Secondly I've made this fix into bf5xx-ac97.c (it helps to change volumes during playback for a long time): static int lastfrag = 0; // variable to save previously used fragment (to witch commands will be enqueued) static void enqueue_cmd(struct snd_ac97 *ac97, __u16 addr, __u16 data) { struct sport_device *sport = sport_handle; int nextfrag = sport_tx_curr_frag(sport); struct ac97_frame *nextwrite; sport_incfrag(sport, &nextfrag, 1); if(lastfrag != nextfrag) // in case of changing current fragment - clearing cmd_count { cmd_count[lastfrag] = 0; lastfrag = nextfrag; // saving current fragment to compare it with the next one // (on next mixer changing) } nextwrite = (struct ac97_frame *)(sport->tx_buf + nextfrag * sport->tx_fragsize); pr_debug("sport->tx_buf:%p, nextfrag:0x%x nextwrite:%p, cmd_count:%d\n", sport->tx_buf, nextfrag, nextwrite, cmd_count[nextfrag]); nextwrite[cmd_count[nextfrag]].ac97_tag |= TAG_CMD; nextwrite[cmd_count[nextfrag]].ac97_addr = addr; nextwrite[cmd_count[nextfrag]].ac97_data = data; ++cmd_count[nextfrag]; pr_debug("ac97_sport: Inserting %02x/%04x into fragment %d\n", addr >> 8, data, nextfrag); } After the above changes we still sometimes notice that the volume control functionality becomes unavailable (mixer pcm doesn't change the real volume while it reports that the volume has been changed). The digital signals can be observed on the ad1980 leads, and all of them are filled with the normal data, while the analog output stays always at zero level. It can be fixed only by re-setting the BF537. Therefore my next question is: “Do you know any other locations in the code, where (as well as in previous example) in the soc driver where the variables can exceed their declared length? Thank you in advance for your fast response. Best regards, Pavel Frolov.

QuoteReplyEditDelete

2009-06-23 05:37:00 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 76181

Pavel,

Do you still have interest in this problem?if So,I will spend some time digging into it.

Cliff

QuoteReplyEditDelete

2009-06-23 10:15:44 Re: uClinux+BF537+problems with AC97 codec

Pavel Frolov (BELARUS)

Message: 76191 Cliff. Yes, I really need your help. Now I am epxerencing not understandable volume losses, And after this i cann't change volume at all. mixer vol/pcm XX doesn't influence on real volume, and I saw with osciloscope that no commands/data on ad1980 pins when playback has been stopped. When playback has been started, all digital data in all slots (cann't trigger command slot) exist on pins). Thank you for your attention to my problem, and I hope you will give me hints to exclude it. Best regards, Pavel.

QuoteReplyEditDelete

2009-06-24 03:42:33 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 76219

Pavel,

There is a workaround to reset the codec when open the codec device.See attached patch,I think working together with your modification in enqueue_cmd will sovle your problem.Otherwise, we need to go back to have a look at the enqueue_cmd again.

Cliff

ad1980_reset_codec.patch

QuoteReplyEditDelete

2009-06-24 21:08:32 Re: uClinux+BF537+problems with AC97 codec

Cliff Cai (CHINA)

Message: 76279

Pavel,

Here is my change of the enqueue_cmd,I've tested over 15 hours with changing volume every 1 second,it works well till to now.

static void enqueue_cmd(struct snd_ac97 *ac97, __u16 addr, __u16 data)

{

struct sport_device *sport = sport_handle;

int nextfrag = sport_tx_curr_frag(sport);