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.
