* I2C bus issues on MPC8248
From: Heiko Schocher @ 2006-05-19 16:37 UTC (permalink / raw)
To: linuxppc-embedded
Hello Laurent,
on Thu, 18 May 2006 14:33:58, Laurent Pinchart wrote:
> I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The
> mailing
> list archives mention a driver for the MPC8260
> (http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I
> modified to reflect the memory map differences between the MPC8260 and the
> MPC8248, as mentionned in the e-mail.
>
> The good news is that the driver works. The bad news is that it doesn't work
OK.
> correctly.
:-(
> The Linux I2C layer probes the I2C bus for peripherals when drivers are
> loaded. The probing function writes a single byte with the device address and
> check if the data is acked. I monitored the SCL and SDA lines using an
[...]
> Using that code, no data is sent on the bus, the BD_SC_READY bit is never
> cleared and no interrupt is generated. Once again I suspected a CPM bug when
> writing a single byte on the bus, so I increased cbd_datlen to 2:
>
> tbdf[0].cbd_bufaddr = __pa(tb);
> tbdf[0].cbd_datlen = 2;
> tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
> BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
> BD_SC_LAST | BD_SC_WRAP;
>
> This worked, and two bytes were written on the bus, leading me to believe that
> the CPM was at fault.
I don t know, if this is a CPM Bug, but it seems so to me ...
> Has anyone noticed the same behaviour ? Is there a workaround available ? I
> tried searching Freescale's website for CPM microcode updates but haven't
> found anything related to the I2C controller.
Yes, Holger Speck had the same problem. He solved it by doing the following:
If the cpm_iic_write is called with count = 0. He made a read with count = 1
I think this is safer than writing 2 Bytes to the Slave.
Could you try this?
Best regards
Heiko
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Linas Vepstas @ 2006-05-19 16:23 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605181456p3c1726e2n56942dfbd4217f70@mail.gmail.com>
On Thu, May 18, 2006 at 02:56:31PM -0700, Srinivas Murthy wrote:
> Hi,
>
> We have a ppc host with a PCI root-complex across which there are multiple
> PCI end points.
>
> An application running on the ppc host reading one of the device memory
> regions (not DMA access but direct CPU read) causes a parity error on the
> PCI interface controller.
>
> We think that the error should be propagated up as a machine-check which is
> considered a non-recoverable system-wide error. However with multiple PCI
> devices present we think that this is too generic and could be reduced to be
> a critical-error which could be recovered from.
The "PCI Error Recovery" API was created to deal with this kind of a
situation. See Documentation/pci-error-recovery.txt
In breif: if something like a PCI parity error is detected by the
hardware, then some arch-specific code runs; for example,
arch/powerpc/platforms/pseries/eeh.c.
This code notifies the PCI device driver (via generic callbacks in
include/linux/pci.h) about the error. The device driver may ask the
arch to have the pci device/bus/link/etc/ get reset, or not. If/when
the PCI bus/link is back to normal, the PCI device driver is notified
via callback, and resumes normal operation.
If you have questions/suggestions, let me know, I've been maintaining
this code, and am interested in seeing how well it can be adapted
to a broader range of hardware.
--linas
^ permalink raw reply
* To connect USB Bluetooth Dongle with embedded linux platform MPC 5200 Lite
From: jabir.kannath @ 2006-05-19 15:53 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
=0D
We are in need of re-building Linux kernel 2.4.25 to support USB
Bluetooth Dongle for the embedded platform MPC 5200 Lite.
=0D
With the new kernel running and on connecting USB Bluetooth Dongle to
icecube (MPC5200 Lite EVM) running embedded Linux from Denx, error "USB
device not accepting new address". We would appreciate any kind of help
towards solving the issue.
=0D
We added USB and Bluetooth support with the configurations available in
the file icecube_5200_defconfig and rebuild the kernel using 'make
uImage'. For USB setting, we have referred icecube_5200_CoralPdefconfig
file. Kindly help us in identifying the reason for the issue.
=0D
Please see the boot up log as follows:
=0D
........................................................................
..................
=0D
=0D
=0D
U-Boot 1.1.3 (May 20 2005 - 18:29:54)
=0D
=0D
=0D
CPU: MPC5200 v1.2 at 396 MHz
=0D
Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
=0D
Board: Motorola MPC5200 (IceCube)
=0D
I2C: 85 kHz, ready
=0D
DRAM: 64 MB
=0D
FLASH: 16 MB
=0D
PCI: Bus Dev VenId DevId Class Int
=0D
00 1a 1057 5803 0680 00
=0D
In: serial
=0D
Out: serial
=0D
Err: serial
=0D
Net: FEC ETHERNET
=0D
IDE: Bus 0: OK
=0D
Device 0: Model: ST340015A Firm: 3.15 Ser#: 5LAMQLQ6
=0D
Type: Hard Disk
=0D
Capacity: 38166.6 MB =3D 37.2 GB (78165360 x 512)
=0D
Device 1: not available
=0D
=0D
=0D
Type "run flash_nfs" to mount root filesystem over NFS
=0D
=0D
=0D
Hit any key to stop autoboot: 0
=0D
## Booting image at fff00000 ...
=0D
Image Name: Linux PPC MPC5200 2.4
=0D
Image Type: PowerPC Linux Kernel Image (gzip compressed)
=0D
Data Size: 931083 Bytes =3D 909.3 kB
=0D
Load Address: 00000000
=0D
Entry Point: 00000000
=0D
Verifying Checksum ... OK
=0D
Uncompressing Kernel Image ... OK
=0D
Memory BAT mapping: BAT2=3D64Mb, BAT3=3D0Mb, residual: 0Mb
=0D
Linux version 2.4.25 (root@M4-110822) (gcc version 3.3.3 (DENX ELDK
3.1.1 3.3.3-10)) #1 Wed May 17 19:02:37 IST 2006
=0D
On node 0 totalpages: 16384
=0D
zone(0): 16384 pages.
=0D
zone(1): 0 pages.
=0D
zone(2): 0 pages.
=0D
Kernel command line: root=3D/dev/hda1 rw
ip=3D10.114.105.162:10.114.105.41:10.114.105.41:255.255.255.0:icecube:eth0
:off panic=3D1
=0D
Calibrating delay loop... 263.78 BogoMIPS
=0D
Memory: 62088k available (1564k kernel code, 524k data, 76k init, 0k
highmem)
=0D
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
=0D
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
=0D
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
=0D
Buffer cache hash table entries: 4096 (order: 2, 16384 bytes)
=0D
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
=0D
POSIX conformance testing by UNIFIX
=0D
PCI: Probing PCI hardware
=0D
PCI: Cannot allocate resource region 0 of device 00:1a.0
=0D
Linux NET4.0 for Linux 2.4
=0D
Based upon Swansea University Computer Society NET3.039
=0D
Initializing RT netlink socket
=0D
Starting kswapd
=0D
Journalled Block Device driver loaded
=0D
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
=0D
pty: 256 Unix98 ptys configured
=0D
ttyS0 on PSC1
=0D
ttyS1 on PSC2
=0D
ttyS2 on PSC3
=0D
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
=0D
loop: loaded (max 8 devices)
=0D
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
=0D
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=3Dxx
=0D
Port Config is: 0x11050004
=0D
ipb=3D66MHz, set clock period to 15
=0D
GPIO config: 11050004
=0D
ATA invalid: 00800000
=0D
ATA hostcnf: 03000000
=0D
ATA pio1 : 100a0a00
=0D
ATA pio2 : 02040600
=0D
XLB Arb cnf: 0000a366
=0D
mpc5xxx_ide: Setting up IDE interface ide0...
=0D
ATA DMA task: 5
=0D
Probing IDE interface ide0...
=0D
hda: ST340015A, ATA DISK drive
=0D
hda: Setting UDMA 2 timings
=0D
hda: Setting PIO 4 timings
=0D
ide0 at 0xf0003a60-0xf0003a67,0xf0003a5c on irq 45
=0D
hda: attached ide-disk driver.
=0D
hda: host protected area =3D> 1
=0D
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=3D77545/16/63,
UDMA(33)
=0D
Partition check:
=0D
hda:<7>Unhandled interrupt 1a, disabled
=0D
hda1 hda2
=0D
Icecube Bank 0: Found 1 x8 devices at 0x0 in 8-bit mode
=0D
Icecube Bank 0: Found 1 x8 devices at 0x800000 in 8-bit mode
=0D
Amd/Fujitsu Extended Query Table at 0x0040
=0D
Icecube Bank 0: CFI does not contain boot bank location. Assuming top.
=0D
number of CFI chips: 2
=0D
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
=0D
Icecube flash bank 0: Using static image partition definition
=0D
Creating 5 MTD partitions on "Icecube Bank 0":
=0D
0x00000000-0x00800000 : "Spare"
=0D
0x00800000-0x00900000 : "kernel"
=0D
0x00900000-0x00c00000 : "initrd"
=0D
0x00c00000-0x00f00000 : "jffs"
=0D
0x00f00000-0x01000000 : "Firmware"
=0D
usb.c: registered new driver usbdevfs
=0D
usb.c: registered new driver hub
=0D
host/usb-ohci.c: USB OHCI at membase 0xf0001000, IRQ 44
=0D
host/usb-ohci.c: usb-0, Built-In ohci
=0D
usb.c: new USB bus registered, assigned bus number 1
=0D
hub.c: USB hub found
=0D
hub.c: 2 ports detected
=0D
usb.c: registered new driver hiddev
=0D
usb.c: registered new driver hid
=0D
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
=0D
hid-core.c: USB HID support drivers
=0D
NET4: Linux TCP/IP 1.0 for NET4.0
=0D
eth0: Phy @ 0x0, type LXT971 (0x001378e2)
=0D
IP Protocols: ICMP, UDP, TCP, IGMP
=0D
IP: routing cache hash table of 512 buckets, 4Kbytes
=0D
TCP: Hash tables configured (established 4096 bind 8192)
=0D
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
=0D
IP-Config: Complete:
=0D
device=3Deth0, addr=3D10.114.105.162, mask=3D255.255.255.0,
gw=3D10.114.105.41,
=0D
host=3Dicecube, domain=3D, nis-domain=3D(none),
=0D
bootserver=3D10.114.105.41, rootserver=3D10.114.105.41, rootpath=3D
=0D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
=0D
hub.c: new USB device 0-1, assigned address 2
=0D
usb.c: USB device not accepting new address=3D2 (error=3D-110)
=0D
hub.c: new USB device 0-1, assigned address 3
=0D
usb.c: USB device not accepting new address=3D3 (error=3D-110)
=0D
kjournald starting. Commit interval 5 seconds
=0D
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
=0D
EXT3-fs: recovery complete.
=0D
EXT3-fs: mounted filesystem with ordered data mode.
=0D
VFS: Mounted root (ext3 filesystem).
=0D
Freeing unused kernel memory: 76k init
=0D
modprobe: Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
INIT: version 2.86 booting
=0D
eth0: status: link up, 100 Mbps Full Duplex, auto-negotiation complete.
=0D
Setting parameters of disc:hda: Setting UDMA 2 timings
=0D
hda: Setting PIO 4 timings
=0D
hda: DMA disabled
=0D
/dev/hda.
=0D
Activating swap.
=0D
Unable to find swap-space signature
=0D
Checking root file system...
=0D
fsck 1.38 (30-Jun-2005)
=0D
/dev/hda1: clean, 58172/2011296 files, 376931/4015864 blocks
=0D
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
=0D
RTC_RD_TIME: Invalid argument
=0D
ioctl() to /dev/rtc to read the time failed.
=0D
System time was Thu Jan 1 00:00:07 UTC 1970.
=0D
Setting the System Clock using the Hardware Clock as reference...
=0D
RTC_RD_TIME: Invalid argument
=0D
ioctl() to /dev/rtc to read the time failed.
=0D
System Clock set. System local time is now Thu Jan 1 00:00:07 UTC 1970.
=0D
Calculating module dependencies...done.
=0D
Loading modules:
=0D
Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
modprobe: Can't locate module *
=0D
Checking all file systems...
=0D
fsck 1.38 (30-Jun-2005)
=0D
Setting kernel variables ...
=0D
... done.
=0D
Mounting local filesystems...
=0D
Unable to find swap-space signature
=0D
Cleaning /tmpfind: warning: you have specified the -maxdepth option
after a non-option argument -perm, but options are not p.
=0D
find: warning: you have specified the -depth option after a non-option
argument !, but options are not positional (-depth af.
=0D
find: warning: you have specified the -depth option after a non-option
argument !, but options are not positional (-depth af.
=0D
/var/run /var/lock.
=0D
Running 0dns-down to make sure resolv.conf is ok...done.
=0D
Setting up networking...done.
=0D
Kernel hotplug support not enabled.
=0D
Setting up IP spoofing protection: rp_filter.
=0D
Configuring network interfaces...done.
=0D
Starting portmap daemon: portmap.
=0D
Loading the saved-state of the serial devices...
=0D
=0D
=0D
Setting the System Clock using the Hardware Clock as reference...
=0D
RTC_RD_TIME: Invalid argument
=0D
ioctl() to /dev/rtc to read the time failed.
=0D
System Clock set. Local time: Thu Jan 1 01:00:17 CET 1970
=0D
=0D
=0D
Running ntpdate to synchronize clockmodprobe: Note: /etc/modules.conf is
more recent than /lib/modules/2.4.25/modules.dep
=0D
modprobe: Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
.
=0D
Initializing random number generator...done.
=0D
Recovering nvi editor sessions... done.
=0D
Setting up X server socket directory /tmp/.X11-unix...done.
=0D
Setting up ICE socket directory /tmp/.ICE-unix...done.
=0D
INIT: Entering runlevel: 2
=0D
Starting system log daemon: syslogd.
=0D
Starting kernel log daemon: klogd.
=0D
Starting portmap daemon: portmap.
=0D
Starting automounter:.
=0D
Starting system message bus: dbus-1.
=0D
Starting internet superserver: inetd.
=0D
Starting printer spooler: lpd .
=0D
Starting PCMCIA services: Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
modprobe: Can't locate module pcmcia_core
=0D
Error: Failed to load pcmcia_core
=0D
Starting OpenBSD Secure Shell server: sshd.
=0D
Starting NFS common utilities: statd.
=0D
Starting NTP server: ntpd.
=0D
Starting bluez-utils: hcid sdpdBlueZ Core ver 2.3 Copyright (C)
2000,2001 Qualcomm Inc
=0D
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
=0D
Can't open RFCOMM control socket: No such file or directory
=0D
rfcomm.
=0D
Starting deferred execution scheduler: atd.
=0D
Starting periodic command scheduler: cron.
=0D
=0D
=0D
Debian GNU/Linux testing/unstable lite5200revA_no2 ttyS0
=0D
=0D
=0D
lite5200revA_no2 login: =0D
=0D
=0D
=0D
........................................................................
.....................
=0D
=0D
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and=
may contain proprietary, confidential or privileged information. If you=
are not the intended recipient, you should not disseminate, distribute or=
copy this e-mail. Please notify the sender immediately and destroy all=
copies of this message and any attachments.=0D
WARNING: Computer viruses can be transmitted via email. The recipient=
should check this email and any attachments for the presence of viruses.=
The company accepts no liability for any damage caused by any virus=
transmitted by this email.
=0D
www.wipro.com
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Olof Johansson @ 2006-05-19 16:18 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev list, paulus, cbe-oss-dev
In-Reply-To: <200605191211.18737.arnd@arndb.de>
On Fri, May 19, 2006 at 12:11:18PM +0200, Arnd Bergmann wrote:
> On Friday 19 May 2006 06:07, Benjamin Herrenschmidt wrote:
> > - Extended implementation of dcbt. (Another bit ? Or sould we just have
> > a "CELL" bit ? In which case should it cover the altivec additions too
> > or are those likely to exist in future non-Cell processors ?)
>
> Isn't that already covered by PPC_FEATURE_CELL? Git log shows
First, please don't use the cell bit for this since other processors
seem to implement the same things.
Second, the quoted information is 6 months old, and seemingly stale by
now. When Paulus pushed the POWER6 patch, he switched from the notion
of it signifying processor model to being base arch version. See:
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022525.html
(My patch to rename the existing POWER* bits to ARCH_2_* wasn't picked
up, I'll resend)
-Olof
^ permalink raw reply
* [RFC] snd-aoa and interrupts (headphone detection etc)
From: Johannes Berg @ 2006-05-19 16:15 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
Hey,
I thought about this a bit, but I'm not sure what the right way to
handle this is. First, I guess an introduction is on order about how the
fabrics and codecs currently work together.
As codecs can have arbitrary inputs and outputs, we have to keep this
generic enough. The tas for example has one analog output, and two
analog inputs (line-in and microphone). The analog output it has is
connected to the amps and then you can select where you want to hear
sound (possibly line-out, headphone, speakers) by controlling the amps
via the GPIOs.
On the other hand, the onyx for example has digital and analog output
along with two analog inputs. Instead of limiting myself to any fixed
items I decided to keep this generic. I probably should change this to
introduce fixed bits for various items though.
Anyway, the fabric has the hardcoded list of how things are hooked up,
and then creates a bitmap of which in/outputs of a codec are connected
and gives this bitmap to the codec driver which creates the appropriate
controls if applicable. This is currently only implemented properly for
the Onyx chip though.
Now, in- and output detection comes into play. The interrupt is always
generated via GPIOs.
Headphone detection is easy: We make the fabric register the interrupt
via the GPIO layer and when we get an interrupt we actually simply do
whatever the user wanted (this ought to be controllable).
The problematic part is things that the codec must control. Say we want
line-in detection to automatically switch to line-in if microphone is
selected (does anyone ever want this?). Then the problem is that the
interrupt arrives at the GPIO layer, and I can easily make it seen in
the fabric too. However, then propagating it to the codec is a bit
harder. Or we don't have it in the fabric but have the codec register
for that interrupt (through our GPIO layer). This is the first option.
The second option is changing the whole in-/output control code that we
have and moving it from the codec to the fabric layer. The fabric
already knows what in- and outputs a codec has (in order to know what is
connected), hence if we added a codec driver function to turn on/off any
in- or output we could have the fabric control this. But then we'd also
have to make known to the codec which of those are mutually exclusive,
and generally make it more complicated.
I currently favour the first option, the codec driver can know when it
makes sense to try registering the interrupt (if it isn't present it
fails anyway) and then do the appropriate stuff (possibly giving the
user a choice).
Comments?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Paul Collins @ 2006-05-19 15:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: debian-powerpc, Eddy Petrişor, linuxppc-dev list
In-Reply-To: <1148050189.6228.13.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Sat, 2006-05-20 at 00:40 +1000, Paul Collins wrote:
>
>> Here's the dmesg after "modprobe i2sbus":
>>
>> May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
>> May 20 00:35:51 briny kernel: i2sbus: control register contents:
>> May 20 00:35:51 briny kernel: i2sbus: fcr0 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus: cell_control = 0x0
>> May 20 00:35:51 briny kernel: i2sbus: fcr2 = 0x4ef1c25
>> May 20 00:35:51 briny kernel: i2sbus: fcr3 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus: clock_control = 0x0
>> May 20 00:35:51 briny kernel: layout id is 51
>
> Did you have the changed modules installed? Otherwise you'd also have to
> manually load snd_aoa_fabric_layout and possibly snd_aoa_codec_tas or
> so. If you had them installed the MODULE_ALIAS("sound-layout-51");
> should have made it load automatically.
Yep, I did make install after the build. And modinfo
/lib/modules/`uname -r`/kernel/sound/aoa/snd-aoa-fabric-layout.ko
shows ones of the aliases as "sound-layout-51".
I did a fresh boot with snd-powermac renamed out of the way, and now I
get even less action: nothing logged in dmesg, and when I unload all
five modules and probe snd-powermac (having renamed it back) I get
May 20 01:08:29 briny kernel: snd: can't request rsrc 0 (Sound Control: 0x80010000:80010fff)
Then when I removed snd-powermac and probed i2sbus I got the same
May 20 01:10:00 briny kernel: i2sbus: mapped i2s control registers
May 20 01:10:00 briny kernel: i2sbus: control register contents:
May 20 01:10:00 briny kernel: i2sbus: fcr0 = 0x0
May 20 01:10:00 briny kernel: i2sbus: cell_control = 0x0
May 20 01:10:00 briny kernel: i2sbus: fcr2 = 0xb7f53c
May 20 01:10:00 briny kernel: i2sbus: fcr3 = 0x0
May 20 01:10:00 briny kernel: i2sbus: clock_control = 0x0
May 20 01:10:00 briny kernel: layout id is 51
May 20 01:10:00 briny kernel: i2sbus control destroyed
Probing snd_aoa_fabric_layout and snd_aoa_codec_tas yielded no further
dmesg output and /proc/asounds/cards remains "no soundcards".
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 14:49 UTC (permalink / raw)
To: Paul Collins; +Cc: debian-powerpc, Eddy Petrişor, linuxppc-dev list
In-Reply-To: <87zmhef57o.fsf@briny.internal.ondioline.org>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
On Sat, 2006-05-20 at 00:40 +1000, Paul Collins wrote:
> Here's the dmesg after "modprobe i2sbus":
>
> May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
> May 20 00:35:51 briny kernel: i2sbus: control register contents:
> May 20 00:35:51 briny kernel: i2sbus: fcr0 = 0x0
> May 20 00:35:51 briny kernel: i2sbus: cell_control = 0x0
> May 20 00:35:51 briny kernel: i2sbus: fcr2 = 0x4ef1c25
> May 20 00:35:51 briny kernel: i2sbus: fcr3 = 0x0
> May 20 00:35:51 briny kernel: i2sbus: clock_control = 0x0
> May 20 00:35:51 briny kernel: layout id is 51
Did you have the changed modules installed? Otherwise you'd also have to
manually load snd_aoa_fabric_layout and possibly snd_aoa_codec_tas or
so. If you had them installed the MODULE_ALIAS("sound-layout-51");
should have made it load automatically.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Paul Collins @ 2006-05-19 14:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: debian-powerpc, Eddy Petrişor, linuxppc-dev list
In-Reply-To: <1148046418.3864.14.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2006-05-19 at 23:20 +1000, Paul Collins wrote:
>
>> I have a PowerBook5,4 here and I'd be happy to test support for it.
>> The hardware is identified by snd-powermac as "PowerMac Snapper" and
>> the layout ID appears to be "3".
>
> Try downloading snd-aoa and in snd-aoa-fabric-layout.c change the two
> occurrences of '70' to '3'. If it works, let me know and I'll add the
> proper entry for it.
When I probed i2sbus nothing much seemed to happen, so I added a
printk to see what layout ID was being returned, and I'm getting 51,
not 3 as found in the device tree. However, when I use 51 instead of
3 in those two places, I still don't get much happening.
Here's the dmesg after "modprobe i2sbus":
May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
May 20 00:35:51 briny kernel: i2sbus: control register contents:
May 20 00:35:51 briny kernel: i2sbus: fcr0 = 0x0
May 20 00:35:51 briny kernel: i2sbus: cell_control = 0x0
May 20 00:35:51 briny kernel: i2sbus: fcr2 = 0x4ef1c25
May 20 00:35:51 briny kernel: i2sbus: fcr3 = 0x0
May 20 00:35:51 briny kernel: i2sbus: clock_control = 0x0
May 20 00:35:51 briny kernel: layout id is 51
May 20 00:35:51 briny kernel: i2sbus control destroyed
And lsmod:
Module Size Used by
i2sbus 21632 0
soundbus 8132 1 i2sbus
radeon 129896 0
drm 82968 1 radeon
snd_usb_audio 90624 0
snd_usb_lib 19232 1 snd_usb_audio
snd_rawmidi 29280 1 snd_usb_lib
snd_hwdep 11012 1 snd_usb_audio
hci_usb 14164 3
snd_pcm_oss 50816 0
snd_pcm 103588 3 i2sbus,snd_usb_audio,snd_pcm_oss
snd_timer 27140 1 snd_pcm
snd_page_alloc 11432 1 snd_pcm
pcmcia 45776 0
ehci_hcd 37224 0
bcm43xx 448916 0
ieee80211softmac 32384 1 bcm43xx
uninorth_agp 11112 1
agpgart 38484 2 drm,uninorth_agp
ohci_hcd 24452 0
ieee80211 36776 2 bcm43xx,ieee80211softmac
ieee80211_crypt 6880 1 ieee80211
yenta_socket 30412 1
rsrc_nonstatic 13472 1 yenta_socket
pcmcia_core 49592 3 pcmcia,yenta_socket,rsrc_nonstatic
Here are the changes I made.
diff --git a/aoa/fabrics/snd-aoa-fabric-layout.c b/aoa/fabrics/snd-aoa-fabric-layout.c
index 65cda87..180dca4 100644
--- a/aoa/fabrics/snd-aoa-fabric-layout.c
+++ b/aoa/fabrics/snd-aoa-fabric-layout.c
@@ -84,7 +84,7 @@ MODULE_ALIAS("sound-layout-64");
MODULE_ALIAS("sound-layout-65");
MODULE_ALIAS("sound-layout-68");
MODULE_ALIAS("sound-layout-69");
-MODULE_ALIAS("sound-layout-70");
+MODULE_ALIAS("sound-layout-51");
MODULE_ALIAS("sound-layout-72");
MODULE_ALIAS("sound-layout-86");
MODULE_ALIAS("sound-layout-84");
@@ -214,7 +214,7 @@ static struct layout layouts[] = {
},
.busname = "digital in", .pcmid = 1 },
/* Early 2005 PowerBook */
- { .layout_id = 70,
+ { .layout_id = 51,
.codecs[0] = {
.name = "tas",
.connections = tas_connections_nolineout,
diff --git a/soundbus/i2sbus/i2sbus-core.c b/soundbus/i2sbus/i2sbus-core.c
index f6463cb..ff5b52e 100644
--- a/soundbus/i2sbus/i2sbus-core.c
+++ b/soundbus/i2sbus/i2sbus-core.c
@@ -130,7 +130,10 @@ static int i2sbus_add_dev(struct macio_d
u32 *layout_id;
layout_id = (u32*) get_property(sound, "layout-id", NULL);
if (layout_id) {
+ printk(KERN_INFO "layout id is %d\n", *layout_id);
snprintf(dev->sound.modalias, 32, "sound-layout-%d", *layout_id);
+ } else {
+ printk(KERN_INFO "no layout id!?\n");
}
}
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 14:40 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060519144028.GA2831@localhost>
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
On Fri, 2006-05-19 at 16:40 +0200, Wolfgang Pfeiffer wrote:
> ... because it's the job of alsaconf, too, to figure that
> out. IINM. And because I thought it might help to mention the issue,
> when I was already at it .. :)
:)
I never used alsaconf, and frankly, for PCI cards and anything else
that's sensible I don't see the point since the kernel along with
hotplugging can get it just to work. With ISA, well, yea, maybe. Or does
alsaconf have any other function than detecting the hardware and loading
the right modules?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Wolfgang Pfeiffer @ 2006-05-19 14:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148043018.3864.6.camel@johannes.berg>
On Fri, May 19, 2006 at 02:50:18PM +0200, Johannes Berg wrote:
> On Thu, 2006-05-18 at 20:17 +0200, Wolfgang Pfeiffer wrote:
>
> > BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> > PB5,8 ?
> > So far that's impossible, as it seems. But this could also be
> > related to mistakes I made in my modules files, or wherever.
>
> No idea, but I don't see why you'd want alsaconf to figure it out
... because it's the job of alsaconf, too, to figure that
out. IINM. And because I thought it might help to mention the issue,
when I was already at it .. :)
But yes, it does not bother me if the kernel itself knows what's going
on .. :)
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 14:37 UTC (permalink / raw)
To: Andreas Schwab; +Cc: list, debian-powerpc, Eddy Petrişor
In-Reply-To: <jemzdenkyg.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
On Fri, 2006-05-19 at 16:33 +0200, Andreas Schwab wrote:
> > [briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sound/layout-id
> > 0000000 \0 \0 \0 3
> > 0000004
>
> Apparently the layout-id on your system is 51 (decimal).
Eh, right, replace 70 by 51 of course. Thanks Andreas.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Andreas Schwab @ 2006-05-19 14:33 UTC (permalink / raw)
To: Paul Collins; +Cc: list, Johannes Berg, debian-powerpc, Eddy Petrişor
In-Reply-To: <87wtcirw0y.fsf@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
>> On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri=BAor wrote:
>>
>>> Any chance for 5,2 ? What is needed for it? Codec only?
>>
>> I don't know. If you try loading the modules, the kernel will tell you
>> something about an unhandled layout id. Alternatively, you can find the
>> layout-id file in your /proc/device-tree/ and tell me the number in it.
>> The rest I can figure out.
>
> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".
>
> [briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/s=
ound/layout-id
> 0000000 \0 \0 \0 3
> 0000004
Apparently the layout-id on your system is 51 (decimal).
Andreas.
--=20
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-19 14:32 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jer72qnl38.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
On Fri, 2006-05-19 at 16:30 +0200, Andreas Schwab wrote:
> Yes, sound is fully supported by snd-powermac on my system.
Alright, I'll look at it then.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Andreas Schwab @ 2006-05-19 14:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1148046512.3864.17.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2006-05-19 at 15:30 +0200, Andreas Schwab wrote:
>
>> >> Yes, that's while I had that loaded. Of course, I unloaded it before I
>> >> tried snd-aoa.
>> >
>> > Ok, but is that the correct stuff, i.e. does it work?
>>
>> Sorry, I can't quite figure out what "it" refers to in your question.
>
> Sorry. I was trying to ask if you get sound with snd-powermac, i.e. if
> the items
>
>>> 80008000-800083ff : 0.00010000:i2s
>>> 80008000-800083ff : Sound DMA
>>> 80010000-80010fff : 0.00010000:i2s
>>> 80010000-80010fff : Sound Control
>
> are correct.
Yes, sound is fully supported by snd-powermac on my system.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andy Whitcroft @ 2006-05-19 14:23 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, davej, tony.luck, linuxppc-dev, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <Pine.LNX.4.64.0605191447060.29077@skynet.skynet.ie>
Mel Gorman wrote:
> On Sun, 14 May 2006, Andrew Morton wrote:
>
>> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>>>
>>> Size zones and holes in an architecture independent manner for ia64.
>>>
>>
>> This one makes my ia64 die very early in boot. The trace is pretty
>> useless.
>>
>> config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
>>
>
> An indirect fix for this has been set out with a patchset with the
> subject "[PATCH 0/2] Fixes for node alignment and flatmem assumptions" .
> For arch-independent-zone-sizing, the issue was that FLATMEM assumes
> that NODE_DATA(0)->node_start_pfn == 0. This is not the case with
> arch-independent-zone-sizing and IA64. With
> arch-independent-zone-sizing, a nodes node_start_pfn will be at the
> first valid PFN.
>
>> <log snipped>
>>
>> Note the misaligned pfns.
>>
>
> You will still get the message about misaligned PFNs on IA64. This is
> because the lowest zone starts at the lowest available PFN which may not
> be 0 or any other aligned number. It shouldn't make a different - or at
> least I couldn't cause any problems.
With the updates I sent out to the zone alignment checks yesterday this
should now be ignored correctly without comment. The first zone is
allowed to be misaligned because we expect alignment of the mem_map.
With bob picco's patch from your set we ensure it is so.
-apw
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-19 14:03 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linuxppc-dev, ak, bob.picco, linux-kernel,
linux-mm
In-Reply-To: <20060514203158.216a966e.akpm@osdl.org>
On Sun, 14 May 2006, Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>> Size zones and holes in an architecture independent manner for ia64.
>>
>
> This one makes my ia64 die very early in boot. The trace is pretty useless.
>
> config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
>
An indirect fix for this has been set out with a patchset with the subject
"[PATCH 0/2] Fixes for node alignment and flatmem assumptions" . For
arch-independent-zone-sizing, the issue was that FLATMEM assumes that
NODE_DATA(0)->node_start_pfn == 0. This is not the case with
arch-independent-zone-sizing and IA64. With arch-independent-zone-sizing,
a nodes node_start_pfn will be at the first valid PFN.
> <log snipped>
>
> Note the misaligned pfns.
>
You will still get the message about misaligned PFNs on IA64. This is
because the lowest zone starts at the lowest available PFN which may not
be 0 or any other aligned number. It shouldn't make a different - or at
least I couldn't cause any problems.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* libspe update
From: D. Herrendoerfer @ 2006-05-19 13:56 UTC (permalink / raw)
To: linuxppc64-dev
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
***********************
Warning: Your file, libspe-1.1.0-20060519.tar.gz, contains more than 32 files after decompression and cannot be scanned.
***********************
This is the current version of libspe matching the current spufs
implementation
posted by Arnd Bergmann this week.
D. Herrendoerfer
[-- Attachment #2: libspe-1.1.0-20060519.tar.gz --]
[-- Type: application/x-gzip, Size: 53352 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-19 13:48 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jey7wynnux.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
On Fri, 2006-05-19 at 15:30 +0200, Andreas Schwab wrote:
> >> Yes, that's while I had that loaded. Of course, I unloaded it before I
> >> tried snd-aoa.
> >
> > Ok, but is that the correct stuff, i.e. does it work?
>
> Sorry, I can't quite figure out what "it" refers to in your question.
Sorry. I was trying to ask if you get sound with snd-powermac, i.e. if
the items
>> 80008000-800083ff : 0.00010000:i2s
>> 80008000-800083ff : Sound DMA
>> 80010000-80010fff : 0.00010000:i2s
>> 80010000-80010fff : Sound Control
are correct. I'll have to investigate a bit more what happens on your
machine.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 13:46 UTC (permalink / raw)
To: Paul Collins; +Cc: linuxppc-dev list, debian-powerpc, Eddy Petrişor
In-Reply-To: <87wtcirw0y.fsf@briny.internal.ondioline.org>
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
On Fri, 2006-05-19 at 23:20 +1000, Paul Collins wrote:
> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".
Try downloading snd-aoa and in snd-aoa-fabric-layout.c change the two
occurrences of '70' to '3'. If it works, let me know and I'll add the
proper entry for it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Andreas Schwab @ 2006-05-19 13:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1148042866.3864.3.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Thu, 2006-05-18 at 14:48 +0200, Andreas Schwab wrote:
>
>> Yes, that's while I had that loaded. Of course, I unloaded it before I
>> tried snd-aoa.
>
> Ok, but is that the correct stuff, i.e. does it work?
Sorry, I can't quite figure out what "it" refers to in your question.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Paul Collins @ 2006-05-19 13:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: list, Eddy Petrişor, debian-powerpc
In-Reply-To: <1147947784.15507.46.camel@johannes>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri=C5=9For wrote:
>
>> Any chance for 5,2 ? What is needed for it? Codec only?
>
> I don't know. If you try loading the modules, the kernel will tell you
> something about an unhandled layout id. Alternatively, you can find the
> layout-id file in your /proc/device-tree/ and tell me the number in it.
> The rest I can figure out.
I have a PowerBook5,4 here and I'd be happy to test support for it.
The hardware is identified by snd-powermac as "PowerMac Snapper" and
the layout ID appears to be "3".
[briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sou=
nd/layout-id
0000000 \0 \0 \0 3
0000004
--=20
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 12:50 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060518181748.GA2836@localhost>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On Thu, 2006-05-18 at 20:17 +0200, Wolfgang Pfeiffer wrote:
> BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> PB5,8 ?
> So far that's impossible, as it seems. But this could also be
> related to mistakes I made in my modules files, or wherever.
No idea, but I don't see why you'd want alsaconf to figure it out if the
kernel can by itself...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-19 12:47 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jek68jqz1l.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
On Thu, 2006-05-18 at 14:48 +0200, Andreas Schwab wrote:
> Yes, that's while I had that loaded. Of course, I unloaded it before I
> tried snd-aoa.
Ok, but is that the correct stuff, i.e. does it work?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 10:22 UTC (permalink / raw)
To: Tony Vroon; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <446B721D.8020203@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]
On Wed, 2006-05-17 at 19:57 +0100, Tony Vroon wrote:
> When writing documentation, you might want to add that the ALSA-plugin
> in XMMS & Audacious requires a period time of 100ms instead of the
> default of 50ms, as otherwise the sou*click*nd is n*click*ot ver*click*y
> good.
> (A look at the current code of that plugin, to see how the volume
> control code can be fixed would be highly appreciated)
How's that related to snd-aoa? You can currently buffer up to 131072
bytes which at 96KHz and 32 bits is ~171ms. At the regular 44100Hz/16bit
it is ~743ms. But you can easily increase that in i2sbus-pcm.c line
126ff:
/* these are somewhat arbitrary */
hw->buffer_bytes_max = 131072;
hw->period_bytes_min = 256;
hw->period_bytes_max = 16384;
The thing is just that this memory area is essentially mlock()ed so if I
did indeed allow 16k per period and 32 periods the stream would mlock
512K. What would others say is appropriate?
Ah then again I can see how this might be related to snd-aoa -- we only
update the pcm position on each period so maybe we should increase the
minimum number of periods. Can you try that? Go into i2sbus-pcm.c line
130 and change
hw->periods_min = 3;
to maybe 6. Or just try binary search for smallest value that makes it
work (if it ever does, but I think it should, if this is indeed the
issue). Indeed, at 50ms buffer you have just 8820 bytes which can even
be divided by 3 so that probably means that xmms used 3 periods. Maybe
that's a bit tight. Do you see the same issue with snd-powermac? (it
uses the same period setup)
> Not seen this, although I must say it does not resume from sleep as
> gracefully as I have seen you describe it.
What happens? I just fixed tas resume from sleep (by completely
re-initialising the codec) and something similar should be done for the
onyx probably (or do I do that already?) for suspend to disk, but other
than that... Oh I just realised that it'll lose some sound due to
restarting the dma command ring at the beginning. Hmm. I suppose I can
change that easily, will have to do some testing.
Benjamin (Berg), can we do that even with the lost interrupt issue?
Maybe both of these issues can be fixed by using the frame count
register instead to count how many samples were played? Below is a small
patch to print out a lot of frame count numbers, Benjamin, I'd
appreciate if you could look how this interacted with the lost
interrupts.
Note that for this to work we'd of course have to sample the frame count
register right before starting the DMA engine, it increases even while
we're not playing because we don't stop the clocks. We probably should
do that too for powersaving. Humm. Lots to do :) Oh and this probably
means that yes, it works fine even when we do lose interrupts.
Alternatively we could use the register just to detect if we lost
interrupts, i.e. calculate how many frames we have per period and then
see if the frame count increased approximately by that much (I've seen
+- a few frames probably due to timing, with higher samplerates we'll
probably see a bit more error) and if it increased by much more we could
estimate how many interrupts we lost. What do you think?
johannes
--- snd-aoa.orig/soundbus/i2sbus/i2sbus-pcm.c 2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus-pcm.c 2006-05-19 12:11:22.119474526 +0200
@@ -488,12 +488,17 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
{
struct pcm_info *pi;
+ u32 fc;
get_pcm_info(i2sdev, in, &pi, NULL);
if (!pi->substream) {
printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx");
return;
}
+ fc = in_le32(&i2sdev->intfregs->frame_count);
+ printk(KERN_DEBUG "i2sbus: frame count is %d\n", fc);
+ printk(KERN_DEBUG "i2sbus: delta fc = %d\n", fc - i2sdev->fc);
+ i2sdev->fc = fc;
pi->current_period = (pi->current_period+1) % (pi->periods);
snd_pcm_period_elapsed(pi->substream);
}
--- snd-aoa.orig/soundbus/i2sbus/i2sbus.h 2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus.h 2006-05-19 12:11:22.119474526 +0200
@@ -50,6 +50,7 @@ struct i2sbus_dev {
struct macio_dev *macio;
struct i2sbus_control *control;
volatile struct i2s_interface_regs __iomem *intfregs;
+ u32 fc;
int resource_allocated; /* bitmask of resources */
struct resource resources[3];
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* i2sbus transfer foo
From: Johannes Berg @ 2006-05-19 11:36 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]
Sorry for the vague subject :) I don't really know what to say...
Let me introduce some things first. First of all, the i2sbus controllers
Apple has in their mac-io chip are capable of doing (among others we
don't care about) 16-bit transfers in 32x and 64x i2s modes, and 24-bit
transfers in 64x i2s mode. For the latter, the chip requires that the
inputs are actually 32-bit aligned, which means that it's a bit weird
that it doesn't actually transfer all the 32 bits. But that's another
issue, maybe there's a way to make it transfer 32 bits that I don't
know. Or maybe it even does and we just don't have a codec capable of
using or creating data in those remaining 8 bits.
Anyway, let's dive right in, here's a sample capture where I was
capturing an 880Hz sine wave generated with gstreamer on another machine
via a direct cable:
00007910 f8 36 48 00 f7 a1 cc 00 f7 a1 cc 00 f7 2e ea 00 |.6H.............|
00007920 f7 2e ea 00 f6 df 58 00 f6 df 58 00 f6 b4 ee 00 |......X...X.....|
00007930 f6 b4 ee 00 f6 af 78 00 f6 af 78 00 f6 cf 59 00 |......x...x...Y.|
The hexdump above is directly from the DMA memory area, not gone through
alsa, I made a debugfs file that gives me access to the buffer area
straight away.
Let me start arecord again:
$ arecord -r 44100 -f S32_LE -c2 > /tmp/test.wav
Dumping the dma area again yields:
00008680 e4 00 ff bd e4 00 fe 93 22 00 fe 93 22 00 fd 6f |........"..."..o|
00008690 2b 00 fd 6f 2b 00 fc 55 62 00 fc 55 62 00 fb 49 |+..o+..Ub..Ub..I|
000086a0 76 00 fb 49 76 00 fa 52 49 00 fa 52 49 00 f9 71 |v..Iv..RI..RI..q|
000086b0 1f 00 f9 71 1f 00 f8 aa 2c 00 f8 aa 2c 00 f7 ff |...q....,...,...|
and a 3rd time:
0000ff60 00 07 3a 12 00 06 6f 77 00 06 6f 77 00 05 89 d9 |..:...ow..ow....|
0000ff70 00 05 89 d9 00 04 8e 73 00 04 8e 73 00 03 80 4a |.......s...s...J|
0000ff80 00 03 80 4a 00 02 64 b0 00 02 64 b0 00 01 3e c0 |...J..d...d...>.|
0000ff90 00 01 3e c0 00 00 16 65 00 00 16 65 00 fe ea b6 |..>....e...e....|
4th time it's like 3rd, 5th like first, but 6th time:
0000bc60 e8 39 00 00 13 60 00 00 13 60 00 01 3d 96 00 01 |.9...`...`..=...|
0000bc70 3d 96 00 02 63 55 00 02 63 55 00 03 7f f5 00 03 |=...cU..cU......|
0000bc80 7f f5 00 04 8b 73 00 04 8b 73 00 05 87 84 00 05 |.....s...s......|
0000bc90 87 84 00 06 6d cc 00 06 6d cc 00 07 37 ae 00 07 |....m...m...7...|
See the problem?
When I actually manage to have it aligned like in #3 above,
SNDRV_PCM_FORMAT_S24_BE would be correct. And in that case, I once even
got a nice wav file that audacity can downsample to 16 bit and play
properly. But in all other cases I get mangled sound for obvious
reasons.
The correct data layout seems to be the first though, because when I
transfer that *to* the chip for playback (by making i2sbus announce
32bit big-endian format to alsa) I get proper sound with the correct
volume, hence I just changed i2sbus to always announce 16 and 32-bit BE
formats which also no longer mangles sound with gstreamer (except for
clicking every once a while on some streams[1]).
Oh, and note that those 4 cases aren't all possible cases. If you think
about it you'll notice that there are 8 cases because we have two
channels. I think I even mixed them in the dumps above, not sure.
Some looking at snd-powermac code later I now changed the i2sbus code to
do a dbdma-programmed engine stop in hope that would synchronize (as a
comment in snd-powermac implies) but that doesn't seem to be correct
either. I now more often get the first case though not all the time.
I'm out of ideas. I don't have a clue how to get this thing synchronized
properly. If anyone has a solution let me know, otherwise I'll probably
just disable 24-bit recording for good, then at least the chances of
getting sound that makes sense (even if left and right might be
switched) are 1/2 as opposed to 1/4 assuming even distribution... Also,
the question is why this does not happen on playback, or at least so
much less frequently that I haven't seen it yet...
johannes
[1] only happens with gstreamer on some streams, and then only if I use
alsasink without giving it the latency-time option, even if I give it
the default it doesn't click. very strange.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox