2010-01-29 07:04:47     AD73311 with actual SVN trunk

Document created by Aaronwu Employee on Aug 22, 2013
Version 1Show Document
  • View in full screen mode

2010-01-29 07:04:47     AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 85324   

 

Having performed a leap from a mid-2009 trunk, I encounter ignorance of AD73311 driver. Boot log excerpt:

 

Advanced Linux Sound Architecture Driver Version 1.0.21.

No device for DAI AD73311

ALSA device list:

No soundcards found.

 

A bit investigation showed that driver code (ad73311.c and bf5xx-ad73311.c) have not changed since a couple of months). My question: May an update of driver code be necessary at this time or change in kernel config related to former state?

 

- Rob

QuoteReplyEditDelete

 

 

2010-01-29 08:51:06     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 85325   

 

Comparing to old bootlog (2.6.28.9)...

 

Advanced Linux Sound Architecture Driver Version 1.0.18rc3.

ASoC version 0.13.2

dma rx:3 tx:4, err irq:45, regs:ffc00800

dma_alloc_init: dma_page @ 0x01a9a000 - 256 pages at 0x01f00000

asoc: AD73311 <-> bf5xx-i2s mapping ok

ALSA device list:

#0: bf5xx_ad73311 (AD73311)

 

... the problem seems to be related to the absense of ASoC. However, configuration options are the same as before.

QuoteReplyEditDelete

 

 

2010-01-29 09:41:27     Re: AD73311 with actual SVN trunk

Robin Getz (UNITED STATES)

Message: 85326   

 

Rob:

 

If the driver couldn't probe properly - what you are seeing is expected.

 

Cliff will need to have a look. I think he has some hardware to test on.

 

-Robin

QuoteReplyEditDelete

 

 

2010-01-29 11:45:29     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 85338   

 

Intermediate follow-up: I'm going to take board files from trunk instead of my "old" customized boardfiles. At first glance there was only little difference - the file compare utility used seems to make massive problems under certain conditions - will be continued after board file reconstruction.

QuoteReplyEditDelete

 

 

2010-01-31 23:34:30     Re: AD73311 with actual SVN trunk

Sonic Zhang (CHINA)

Message: 85382   

 

Why not use the 2009R1.1 release kernel other than the arbitary one on SVN trunk? The AD73311 driver in the release passed regression test.

QuoteReplyEditDelete

 

 

2010-02-01 02:01:08     Re: AD73311 with actual SVN trunk

Cliff Cai (CHINA)

Message: 85389   

 

I guess the ad73311 config file doesn't exist in your alsa-lib-1.0.21(src/conf/cards/AD73311.conf),just copy one from 1.0.18.

 

 

 

Cliff

QuoteReplyEditDelete

 

 

2010-02-01 05:06:13     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 85408   

 

Cliff: I'm wondering why userspace lib should influence driver probing during kernel start-up. But to answer the question. In lib/alsa-lib/.... there are no 1.0.21 sources.  The 1.0.18 contains AD73311.conf

QuoteReplyEditDelete

 

 

2010-02-01 05:08:30     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 85409   

 

Sonic: Well, I'm probably going to modify spidev userspace driver due to some requirements, and there are some significant changes entered in the past three months. Moreover: TCM-BF518 (my next step) is supported until very recently.

QuoteReplyEditDelete

 

 

2010-02-01 05:26:07     Re: AD73311 with actual SVN trunk

Sonic Zhang (CHINA)

Message: 85411   

 

We just check the regression log of the SVN trunk head kernel. AD73311 can be detected properly on bf537-stamp. Please try the head source again.

QuoteReplyEditDelete

 

 

2010-02-01 11:10:54     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 85418   

 

Intermediate report: I have deleted sound related directories and then SVN updated them again, in order to ensure that no merging from former code takes place. Indeed the behaviour was different. However, also a bug in .../soc/codecs/ad73311.c was found:

 

struct snd_soc_dai ad73311_dai = {

        .name = "DRV_NAME",

 

Of course, DRV_NAME is not a string! (DRV_NAME appeared into the kernel boot log....). Note that naming had been correct yesterday due to merging effects.

 

After correcting this, probing is still unsuccessful. I'm further doing experiments, e.g. compiling 2009R1 kernel for TCM-BF537.

 

-Rob

QuoteReplyEditDelete

 

 

2010-02-01 23:41:25     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 85440   

 

ive fixed the DRV_NAME typo in trunk, thanks

QuoteReplyEditDelete

 

 

2010-07-18 12:06:46     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91408   

 

Well, further attempt to have AD73311 operate well with SVN trunk. I noticed that trunk has been verified to to this. Alas not with my system. Meanwhile I have found a problem area: SPORT.

 

SPORT is neither listed in /proc/interrupts nor in /proc/dma.

 

sport0 and sport1 are present under /dev.

 

So I tried to execute  sport_test "Failed to open /dev/sport0".

 

Any hints on how to localize the problem are appreciated.

 

 

 

BTW: even wenn sport_test would initialize correctly, it would not operate correctly after init, because of usage of obsolete SIMPLE_GPIO.

QuoteReplyEditDelete

 

 

2010-07-23 03:11:24     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91637   

 

...

QuoteReplyEditDelete

 

 

2010-07-23 03:24:08     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91650   

 

pins arent acquired until the device is actually opened (by design), and then they're released when the device is closed.  so you would never see anything in /proc/ if you havent actually opened it.

 

the error you report from sport_test isnt helpful in narrowing things down.  run it through strace to see the actual errno returned by the open() call and then it should be easy to correlate that to the driver source.

QuoteReplyEditDelete

 

 

2010-07-25 15:33:42     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91693   

 

Mike, the open() call gives not that detail info that helped me to localize the problem:

 

root: /> strace sport_test -t /dev/sport0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x1b77000

stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=1516, ...}) = 0

open("/etc/ld.so.cache", O_RDONLY)      = 3

mmap2(NULL, 1516, PROT_READ, MAP_PRIVATE, 3, 0) = 0x36e000

close(3)                                = 0

open("/lib/libgcc_s.so.1", O_RDONLY)    = 3

fstat(3, {st_mode=S_IFREG|0755, st_size=62416, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x1b7e000

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0j\0\1\0\0\0\324#\0\0004\0\0\0"..., 4096) = 4096

mmap2(NULL, 57256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE|MAP_EXECUTABLE, 3, 0) = 0x1b20000

mmap2(NULL, 8184, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x1b2e000

pread(3, "\17d\325/\0h\5h;/"..., 8024, 228698418577408) = 8024

close(3)                                = 0

munmap(0x1b7e000, 4096)                 = 0

open("/lib/libc.so.0", O_RDONLY)        = 3

fstat(3, {st_mode=S_IFREG|0755, st_size=229796, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x1b7e000

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0j\0\1\0\0\0l\274\0\0004\0\0\0"..., 4096) = 4096

mmap2(NULL, 221964, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE|MAP_EXECUTABLE, 3, 0) = 0x1bc0000

mmap2(NULL, 15680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x1b1c000

pread(3, "hijklmnopqrstuvwxyz\0/dev/pts/\0\0\0"..., 7164, 949978046398464) = 7164

close(3)                                = 0

munmap(0x1b7e000, 4096)                 = 0

open("/lib/libc.so.0", O_RDONLY)        = 3

fstat(3, {st_mode=S_IFREG|0755, st_size=229796, ...}) = 0

close(3)                                = 0

munmap(0x36e000, 1516)                  = 0

stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=20396, ...}) = 0

ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 opost isig icanon echo ...}) = 0

ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 opost isig icanon echo ...}) = 0

open("/dev/sport0", O_RDWR)             = -1 ENXIO (No such device or address)

write(2, "Failed to open /dev/sport0", 26Failed to open /dev/sport0) = 26

_exit(-1)                               = ?

root: /> ls /dev/sp*

/dev/spi /dev/sport0 /dev/sport1

 

(using static device nodes)

 

 

 

I also have redefined sport and ad73311 soc-driver as module, both with trunk (2.6.34) and my production trunk (2.6.28.9), and then have executed

 

strace modprobe snd-ad73311

 

Since I'm not familiar with the details of device initialisation algorithm, I only can compare them with the strace output in the 2.6.28 system, where I know that it works correclty. Main difference to my opinion: changed order of module dependencies, which is defined as follows in 2.6.34 (modules.dep):

 

kernel/sound/soc/blackfin/snd-ad73311.ko: \

    kernel/sound/soc/blackfin/snd-soc-bf5xx-i2s.ko \

    kernel/sound/soc/codecs/snd-soc-ad73311.ko \

    kernel/sound/soc/blackfin/snd-bf5xx-i2s.ko \

    kernel/sound/soc/blackfin/snd-soc-bf5xx-sport.ko

kernel/sound/soc/blackfin/snd-bf5xx-i2s.ko: \

    kernel/sound/soc/blackfin/snd-soc-bf5xx-sport.ko

kernel/sound/soc/codecs/snd-soc-ad73311.ko:

kernel/sound/soc/blackfin/snd-soc-bf5xx-sport.ko:

kernel/sound/soc/blackfin/snd-soc-bf5xx-i2s.ko: \

    kernel/sound/soc/blackfin/snd-soc-bf5xx-sport.ko

 

strace command invocation and output in 2.6.28 as well as 2.6.34 case are both attached.

 

What should I do to narrow the problem area?

 

strace2634

strace2628

QuoteReplyEditDelete

 

 

2010-07-25 15:39:09     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91694   

 

just because you do `mknod` doesnt mean the device suddenly exists.  use proper dynamic device nodes instead of static ones.

 

/dev/sport* interfaces are only for the simple bfin_sport driver.  it has no relationship whatsoever to any ALSA driver.  if you actually want to use the ALSA driver, then you need to use the ALSA interfaces to do things with sound, not the raw sport device nodes.

QuoteReplyEditDelete

 

 

2010-07-25 15:54:52     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91695   

 

regarding the simple bfin_sport driver: I'm aware of all what you mentioned in your reply. It was included for the sport_test. I'm 100% sure that the ALSA/SoC settings are identical to that of 2.6.28 config.

 

Test with dynamic nodes is my next step.

QuoteReplyEditDelete

 

 

2010-07-25 15:58:10     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91696   

 

my point was that even if all your ALSA settings are the same and/or working, it doesnt mean the bfin_sport driver is loaded ...

QuoteReplyEditDelete

 

 

2010-07-25 16:26:59     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91697   

 

Am I stupid, or did I overlook anything which causes bfin_sport being loaded with 2.6.28 without any noticeable difference in kernel configuration, but not with 2.6.34? When ad73311 is modprobed, the strace shows that sport is initialised (without detail info about possible trouble)...

 

Meanwhile I have selected dynamic nodes and activated busybox mdev, which indeed autopopulates devices.

QuoteReplyEditDelete

 

 

2010-07-25 16:33:33     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91698   

 

the bfin_sport driver should print out "registered sport#" for every sport it registers and should be available via /dev/sport#

 

if you dont see that message, then the driver isnt registered and the device node doesnt matter

QuoteReplyEditDelete

 

 

2010-07-25 16:36:01     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91699   

 

also, the exact device major/minor used in 2009R1 vs trunk may have changed.  so static device nodes arent going to work if trunk is always using a dynamic #.

QuoteReplyEditDelete

 

 

2010-07-25 16:45:48     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91700   

 

Sports have been registered always until now (during boot). Extracts from boot output (where ad73311 returned to be a fixed kernel driver):

 

...

Advanced Linux Sound Architecture Driver Version 1.0.22.1.

...

bfin_sport: registered sport0

bfin_sport: registered sport

...

No device for DAI AD73311

ALSA device list:

   #0: Dummy 1

 

QuoteReplyEditDelete

 

 

2010-07-25 16:50:31     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91701   

 

also, the exact device major/minor used in 2009R1 vs trunk may have changed.  so static device nodes arent going to work if trunk is always using a dynamic #.

 

---

 

Hm, to be precise: kernel "Dynamic device file minor numbers" (SND_DYNAMIC_MINORS) is not set.

QuoteReplyEditDelete

 

 

2010-07-25 16:57:40     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91702   

 

once again, the ALSA settings have no bearing whatsoever on the bfin_sport driver

QuoteReplyEditDelete

 

 

2010-07-25 17:19:46     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91703   

 

I recall your "my point was that even if all your ALSA settings are the same and/or working, it doesnt mean the bfin_sport driver is loaded ...".

 

Okay, the driver is registered. It is in /dev. It is NOT in /proc/interrupts, but as you said, interrupt assignments are present after OPENing the device. Well, my intermediate "strace modprobe snd-ad73311" showed that

 

open("kernel/sound/soc/blackfin/snd-soc-bf5xx-sport.ko", O_RDONLY) = 3

 

which suggests, that the sport driver is opened.

QuoteReplyEditDelete

 

 

2010-07-25 17:36:18     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91704   

 

that is the ALSA driver.  it has nothing to do with the bfin_sport driver nor /dev/sport#.

QuoteReplyEditDelete

 

 

2010-07-25 18:00:39     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91705   

 

Well, the hierarchy is as follows, is'nt it?:

 

- sound/soc/codecs/ad73311.c   - ALSA level interface

- sound/soc/blackfin/bf5xx-ad73311.c  - hardware driver

 

The latter should use lowest level SPORT/I2S resources.

 

I'm checking bf5xx-sport.c source now, because of an issue with port G and EMAC usage.

QuoteReplyEditDelete

 

 

2010-07-25 18:11:47     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91706   

 

yes, but those drivers have nothing to do with the drivers/char/bfin_sport driver or the device nodes that it produces (/dev/sport#)

 

if you want to do sound, you use the ALSA library.  you dont access device nodes directly.

QuoteReplyEditDelete

 

 

2010-07-25 18:24:31     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91707   

 

I am aware of the fact that drivers/char/bfin_sport has nothing to do with ALSA. I had activated this only with the goal of testing with the sport_test program. In order to ensure that in this respect no more confusion should persist, I have deselected the char device in the kernel config (as expected: still no AD73311 DAI created).

QuoteReplyEditDelete

 

 

2010-07-25 19:30:03     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91708   

 

Definitely, sport_init (bf5xx-sport.c) is not called, in contrast to earlier linux versions. Apparently, the runtime indirect function call is not properly assigned. I'd suggest that this is called through init_module. In contrast to a linux with correclty initialized sport, init_module() has the same first argument upon call, regardless which item is called (extract from strace modprobe snd-ad73311 follows):

 

open("modules.dep", O_RDONLY)           = 3

ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x3ffa48) = -1 ENOTTY (Inappropriate ioctl for device)

read(3, "kernel/sound/soc/blackfin/snd-ad"..., 256) = 256

close(3)                                = 0

open("kernel/sound/soc/blackfin/snd-soc-bf5xx-sport.ko", O_RDONLY) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=14920, ...}) = 0

mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x1a3c000

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0j\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 15360) = 14920

read(3, "", 440)                        = 0

close(3)                                = 0

init_module(0x1a3c004, 14920, "")       = 0

open("kernel/sound/soc/blackfin/snd-bf5xx-i2s.ko", O_RDONLY) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=5116, ...}) = 0

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0j\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 5120) = 5116

read(3, "", 4)                          = 0

close(3)                                = 0

init_module(0x1a3c004, 5116, "")        = 0

open("kernel/sound/soc/codecs/snd-soc-ad73311.ko", O_RDONLY) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=3440, ...}) = 0

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0j\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 3440

read(3, "", 656)                        = 0

close(3)                                = 0

init_module(0x1a3c004, 3440, ""No device for DAI AD73311

)        = 0

open("kernel/sound/soc/blackfin/snd-soc-bf5xx-i2s.ko", O_RDONLY) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=4740, ...}) = 0

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0j\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 5120) = 4740

read(3, "", 380)                        = 0

close(3)                                = 0

init_module(0x1a3c004, 4740, "")        = 0

open("kernel/sound/soc/blackfin/snd-ad73311.ko", O_RDONLY) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=3912, ...}) = 0

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0j\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 3912

read(3, "", 184)                        = 0

close(3)                                = 0

init_module(0x1a3c004, 3912, "") = 0

 

QuoteReplyEditDelete

 

 

2010-07-25 19:42:37     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91709   

 

did you update your platform resources accordingly ?  look at the bf537-stamp as an example.

QuoteReplyEditDelete

 

 

2010-07-26 01:07:00     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91711   

 

Mike, must make a pause for 1,5 days now due to actual priorities - check needs some investigation in model and in common directory. However, this topic has been inspected in january, too. Now I'll also take care of mdev.conf and some other small things.

QuoteReplyEditDelete

 

 

2010-07-27 15:10:49     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91784   

 

I have taken care of checking differences in (vendor) board/platform files and performed some updates. Also mdev.conf is activated in busybox.  The kernel board file has been compared to stamp.c, and no apparent anomalies are found (of course, big differences are present). Moreover, the kernel board file has nothing to do with alsa devices.

 

Still I become "No device for DAI AD73311".

 

Sonic or Cliff: can anyone of you provide a log file that contains "strace modprobe snd-ad73311" output log using trunk? I think that this would help narrowing the cause of my problems.

QuoteReplyEditDelete

 

 

2010-07-27 15:17:36     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91786   

 

stracing of module loading isnt useful information.  it merely shows the module being read and sent to the kernel.  it doesnt show what the kernel does with the module.

 

look at svn rev 8949 in trunk

QuoteReplyEditDelete

 

 

2010-07-27 15:39:38     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91787   

 

Are you suggesting to checkout this revision and build this?

QuoteReplyEditDelete

 

 

2010-07-27 15:42:34     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91788   

 

look at the commit contents

QuoteReplyEditDelete

 

 

2010-07-27 16:13:17     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91790   

 

Yes, I already did this, but wondered about Altera Nios comment, until I checked the kernel SVN. Now I updated my board file with any new entries regarding I2S, tdm and AC97 and indeed the driver is initialized:

 

ASoC version (this is temporary text of mine)

No device for DAI AD73311

sport_init enter (this is temporary text of mine)

dma rx:3 tx:4, err irq:45, regs:ffc00800

dma_alloc_init: dma_page @ 0x01930000 - 256 pages at 0x01f00000

asoc: AD73311 <-> bf5xx-i2s mapping ok

ALSA device list:

  #0: bf5xx_ad73311 (AD73311)

 

Currently, /dev/dsp is not found and aplay yields OOPS kernel error, but nevertheless, this is a big leap. To be continued... (and thanks Mike, for this hint).

Curiously, the boot log still shows up "No device for DAI AD73311".

 

Question to learn about: how did you exactly refer to rev. 8949? Search result? Some (fabulous) Mike-brains database?

QuoteReplyEditDelete

 

 

2010-07-27 16:22:22     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91791   

 

use the SVN link on the left side of every forum page ?  and then type in the # in the field in the middle of that page ?

QuoteReplyEditDelete

 

 

2010-07-27 16:43:39     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91792   

 

Sticky Revision. But this does not answer the question about how you obtained 8949. Now, instead of doing svn log -v -r8949 I used web based "browse commits", and here I could search for "audio" using the browser search function, but in this case the second entry already shows "add audio....".

 

This experience should help me to find relevant changes when a bigger leap from one certain revision to an actual revision is being carried out.  

 

QuoteReplyEditDelete

 

 

2010-07-27 16:55:49     Re: AD73311 with actual SVN trunk

Mike Frysinger (UNITED STATES)

Message: 91793   

 

i recalled someone hitting the same problem with the bf561-ezkit, so i looked at the history of that particular file

QuoteReplyEditDelete

 

 

2010-07-28 03:44:47     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 91807   

 

Recalling the actual state of the boot info, since sound is not yet operable:

 

...

ASoC version (this is temporary text of mine)

No device for DAI AD73311

sport_init enter (this is temporary text of mine)

dma rx:3 tx:4, err irq:45, regs:ffc00800

dma_alloc_init: dma_page @ 0x01930000 - 256 pages at 0x01f00000

asoc: AD73311 <-> bf5xx-i2s mapping ok

ALSA device list:

  #0: bf5xx_ad73311 (AD73311)

...

 

Curiously, the boot log still shows up "No device for DAI AD73311". Because of the apparently proper initialisation and creation of the device instance, it seems that this message could be ignored. Is this true? The message is given, when dai->dev is NULL. DAI can be I2S or PCM (or AC97). Is it PCM that makes problem, or is only I2S used, also with OSS emulation?

 

When I compare some /proc/asound information with a former linux, pcm0c and pcm0p are not present, as well as a small difference in /proc/asound/pcm (I2S) is present:

 

2.6.28:

 

root: /> cat /proc/asound/pcm

00-00: AD73311 AD73311-I2S-0 : : playback 1 : capture 1

root: /> cat /proc/asound/version

Advanced Linux Sound Architecture Driver Version 1.0.18rc3.

root: /> ls /proc/asound/card0

id oss_mixer pcm0c pcm0p

 

2.6.34:

 

root: /> cat /proc/asound/pcm

00-00: AD73311 AD73311-0 : : playback 1 : capture 1

root: /> cat /proc/asound/version

Advanced Linux Sound Architecture Driver Version 1.0.22.1.

root: /> ls /proc/asound/card0

id oss_mixer

 

Due to not being able to open /dev/dsp, tone does not work. How should I target the problem area?

 

For the sake of completeness I have to add that native alsa makes trouble, for the case that one can say that the dsp problem outlined are a consequence of this behaviour:

 

root: /> aplay root/1.wav

ALSA lib /home/uClinux/trunk_new_test/lib/alsa-lib/alsa-lib-1.0.18/src/pcm/pcm_dmix.c:1008:

(NULL pointer access

...

 

 

QuoteReplyEditDelete

 

 

2010-08-30 20:27:43     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 92941   

 

I have updated my local test-trunk once again (now based on 2.6.34.6 instead of 2.6.34) and AD73311 is operating now.

 

Tone also operates, but only when the -f8000 option is specified. I forgot this, because I modified and enhanced tone formerly - not yet updated to local test-trunk (-> thread_id=32875).

 

Still I'm interested if it is okay when "No device for DAI AD73311" appears on boot.

QuoteReplyEditDelete

 

 

2010-08-31 07:29:58     Re: AD73311 with actual SVN trunk

Bob Liu (CHINA)

Message: 92962   

 

It's okay.

 

Because ad73311 device maybe init later.

QuoteReplyEditDelete

 

 

2010-09-02 03:47:52     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 93065   

 

OK - thanks for that information.

 

After I succeeded in getting audible sound, I found that the effective sample rate ("tone -f8000" test) wasn't correct. Since my codec files contains some other modifications, and other resources, too, I decided to report this after having prepared a new local repo based on the git mirror. Goal: test with as least own modifications as necessary, mainly my specifically updated boardfile tcm-bf537.c with the entries for I2S etc. as Mike showed me in this thread.

 

tone effectively generates 500 Hz, half the nominal frequency. I verified that the codec clock is indeed 8 kHz. When I enter

 

.rates = SNDRV_PCM_RATE_16000

 

in ad73311.c, the frequency is correct, but of course this is not the correct way. I need some hints of how to localize the problem.

 

-Rob

QuoteReplyEditDelete

 

 

2010-09-02 05:14:03     Re: AD73311 with actual SVN trunk

Bob Liu (CHINA)

Message: 93068   

 

Hi, Rob

 

Could you please try this patch ? Thanks.

 

Index: linux-2.6.x/sound/soc/blackfin/bf5xx-ad73311.c

===================================================================

--- linux-2.6.x/sound/soc/blackfin/bf5xx-ad73311.c    (revision 9120)

+++ linux-2.6.x/sound/soc/blackfin/bf5xx-ad73311.c    (working copy)

@@ -87,7 +87,7 @@

      * Sample Rate = DMCLK/2048  = 8 KHz

      */

     ctrl_regs[0] = AD_CONTROL | AD_WRITE | CTRL_REG_B | REGB_MCDIV(0) | \

-            REGB_SCDIV(0) | REGB_DIRATE(0);

+            REGB_SCDIV(1) | REGB_DIRATE(0);

     ctrl_regs[1] = AD_CONTROL | AD_WRITE | CTRL_REG_C | REGC_PUDEV | \

             REGC_PUADC | REGC_PUDAC | REGC_PUREF | REGC_REFUSE ;

     ctrl_regs[2] = AD_CONTROL | AD_WRITE | CTRL_REG_D | REGD_OGS(2) | \

QuoteReplyEditDelete

 

 

2010-09-02 09:31:02     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 93076   

 

Patch makes no difference.

 

BTW: the sine wave is distorted (of course, regardless patched or not). Let me summarize, also using attached screenshots of scope images.

 

The first attachment is created using kernel 2.6.28.9 (my production state). Actually the codec sample rate is 16ksmps because this is desired for the application. This image serves as a reference with clean sine wave.

 

The second attachment also shows 600 Hz, but while generated using "tone 1200 -f8000". Quite heavy harmonics presence.

 

The third argument is while having set  REGB_DIRATE(1), i.e. ad73311 sample clock 16 kHz. In this case tone 600 creates 600 Hz. But still a slight distortion is visible - clearly worse than the first screenshot shows. Note that in the case of my production kernel, the codec struct matches the hardware rate:

 

      .rates = SNDRV_PCM_RATE_16000,

 

but is left at _8000 with 2.6.34.6, in order to get the intended frequency.

 

I'm wondering whether the latest change in trunk:

 

      .channels_max = 2,

 

has a responsibility in this respect. But when I restore the value to 1, an error is generated when I invoke tone:

 

ERROR: failed to open DAC device /dev/dsp

 

 

600Hz-2.6.34.6-16ksmps.png

600Hz-2.6.34.6.png

600Hz-2.6.28.9.png

QuoteReplyEditDelete

 

 

2010-09-06 04:38:50     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 93174   

 

Anybody out there who is able to confirm sine wave cleanliness with trunk, especially with AD73311?

QuoteReplyEditDelete

 

 

2010-09-09 15:49:11     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 93311   

 

Yes, it's me. I have found what causes the sine wave distortion. Thanks to a local git three I was able to find a crosspoint where AD73311 operates correct, and where it does not operate correct.

 

With 2.6.31.2 operation is fully OK (can be combined with root file system derived from trunk - simplifies tests), and with 2.6.31.5 an error is reported when I invoke tone:

 

root: /> tone

ERROR: failed to open DAC device /dev/dsp

root: /> cat /proc/version

Linux version 2.6.31.5-ADI-2010R1-pre (rob@rob-desktop) (gcc version 4.3.5 (ADI-trunk/git-08d8861) ) #242 PREEMPT Thu Sep 9 21:07:03 CEST 2010

 

When I apply the changes as proposed by Mike in Message 91709 (to check stamp.c a few posts above), this does not help. When I apply the patch that results from bug #6193 (let max_channels_max be 2 instead of 1) it is going well, however with the distortion as shown (and with half the frequency).

 

When I return to 2.6.31.2, modified and unmodified ad73311.c both do the job. This opens the opportunity do to a simple test. In the first case where channels_max = 1, all is OK, in the other case: half frequency and distortion.

 

Of course, hard to believe that others also have half frequency experience. So somewhere else must be a difference. AD73311.conf probably not (I verified), perhaps some detail in the stamp board file that must also be transferred to my tcm-bf537 boardfile?. I'll check it and return here when I have found something - or anybody has a valueable hint for me -highly appreciated...

 

QuoteReplyEditDelete

 

 

2010-09-09 19:10:32     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 93314   

 

Probable solution:

 

file: bf5xx-i2s.c (snippet):

 

struct snd_soc_dai bf5xx_i2s_dai = {

.name = "bf5xx-i2s",

.id = 0,

.suspend = bf5xx_i2s_suspend,

.resume = bf5xx_i2s_resume,

.playback = {

.channels_min = 1,

.channels_max = 1,

.rates = BF5XX_I2S_RATES,

.formats = BF5XX_I2S_FORMATS,},

.capture = {

.channels_min = 1,

.channels_max = 1,

.rates = BF5XX_I2S_RATES,

.formats = BF5XX_I2S_FORMATS,},

.ops = &bf5xx_i2s_ dai_ops, };

 

 

 

Channels_min/max restored to 1. According to history this has been more than once a topic (e.g. linux-kernel/trunk@9097 rollback...). ADI, please pay attention to this.

 

In my case: only when ALL 4 assignments above are 1, I get perfect sound with proper sample rate, regardless whether channels_max in ad73311.c is 1 or 2.

 

 

 

QuoteReplyEditDelete

 

 

2010-09-09 22:22:08     Re: AD73311 with actual SVN trunk

Bob Liu (CHINA)

Message: 93315   

 

Hi, Rob

 

Would you please test with

 

file: bf5xx-i2s.c (snippet):

struct snd_soc_dai bf5xx_i2s_dai = {

.name = "bf5xx-i2s",

.id = 0,

.suspend = bf5xx_i2s_suspend,

.resume = bf5xx_i2s_resume,

.playback = {

.channels_min = 1,

.channels_max = 2,

.rates = BF5XX_I2S_RATES,

.formats = BF5XX_I2S_FORMATS,},

.capture = {

.channels_min = 1,

.channels_max = 2,

.rates = BF5XX_I2S_RATES,

.formats = BF5XX_I2S_FORMATS,},

.ops = &bf5xx_i2s_ dai_ops, };

 

I think it's linux-kernel/trunk@8885 cause this problem.

 

I will take a look at the code soon.

 

Thanks a lot for your work.

QuoteReplyEditDelete

 

 

2010-09-10 03:21:09     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 93324   

 

Bob, I wrote: ALL four assignments 1. Your proposal with differring 1/2 does not work, is tested yesterday. And: for me crucial: letting good old 1 in the ad73311 driver makes the driver not appear at all.

 

I think that latest patch in ad73311.c where channels_max had become 2 is per se a symptom-type of bugfix. Indeed the ad73311 has one channel, so the original settings should hold true (Basta! as the dutch or germans would say).

 

I'd appreciate it to compare my findings with your or others findings having an AD73311 board, too - simply because it seems curious that it's only me having the half playback frequency perception until this fix.

 

-Rob

QuoteReplyEditDelete

 

 

2010-09-10 04:25:08     Re: AD73311 with actual SVN trunk

Rob Maris (GERMANY)

Message: 93325   

 

Bob: small amendment. I have checked the min/max constellations once again. Your proposal has indeed already been tested, but apparently not for the case where channels_min/max in the ad73311.c are both 1, as was the original state. To be precise:

 

ad73311.c:

 

.channels_min = 1,

.channels_max = 1,

 

bf5xx-i2c.s:

 

.channels_min = 1,

.channels_max = 2,

 

This works OK, and I think - should be compatible with all other sound card constellations.

 

linux-kernel/trunk@8885 definitely has nothing to do with the problem, since it arose quite long before that point. To be precise: my investigations showed that the break is exactly after linux-kernel@7598!

 

But that was due to bugs introduced in bf5xx-i2s.c! linux-trunk@7608 presented a fix (one line, which I had to apply on another source line, too in order to let it build correctly - but still did not work).

 

My problems all that time seems to originate from channels_min/max both 2 in bf5xx-i2s.c. I already mentioned 9097, but this was a rollback from 9096. My question: how can I quickly find the (git) history before that point where channels_min/max had been changed from 1 to 2? Meanwhile I have found that my production code (trunk from early 2009) has the correct settings (i.e. min=1 and max=2).

QuoteReplyEditDelete

 

 

2010-09-10 06:22:17     Re: AD73311 with actual SVN trunk

Bob Liu (CHINA)

Message: 93330   

 

Yes, I also think this should be the correct way. I will update the code soon. Thanks

 

ad73311.c:

 

.channels_min = 1,

.channels_max = 1,

 

bf5xx-i2c.s:

 

 

.channels_min = 1,

.channels_max = 2,

 

====

 

> channels_min/max had been changed from 1 to 2

 

Sorry, What I mean is svn kernel commit 8885 around 2010/06/03 (you can use 'svn log bf5xx-i2s.c' find it ) but not trunk version. And I have no git version.

Outcomes