* 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
* [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: 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
* 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: 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
* 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: MPC8xx: resolution of gettimeofday() ?
From: Eugene Surovegin @ 2006-05-19 17:55 UTC (permalink / raw)
To: Steven Scholz; +Cc: linuxppc-embedded
In-Reply-To: <446D7CFA.5060505@imc-berlin.de>
On Fri, May 19, 2006 at 10:08:26AM +0200, Steven Scholz wrote:
> Eugene,
>
> >> what is the resolution of gettimeofday() for an MPC8xx?
> >>
> >> IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
> >>
> >> This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
> >> resolution of 16/80MHz = 200ns and overflows every 50000 ticks.
> >>
> >> But is this decrementer used to update xtime?
> >> Will gettimeofday() have a resolution of 200ns?
> >>
> >> How about linux 2.4 where xtime is a "struct timeval" rather then "struct
> >> timespec"?
> >>
> >
> > Usually on PPC we use timebase to interpolate time between Decrementer
> > interrupts. In this case gettimeofday resolution is determined by
> > timebase resolution which is quite high (megahertz range).
>
> Sorry. I don't understand. What do you mean with "timebase"? Is there a
> second timer/counter?
PowerPC has a facility called timebase. This is 64-bit counter which
can be accessed using special instructions (mftb, mftbu on 32-bit PPC).
Counter resolution depends on particular chip implementation, some
use core clock, other use bus clock...
It's similar to the time-stamp counter in Intel CPUs (accessed
with rdtsc instruction).
Please, refer to PPC arch manuals for more information. Also, if you
really interested in how gettimeofday() is implemented, why don't you
look at the source code yourself?
--
Eugene
^ permalink raw reply
* Re: To connect USB Bluetooth Dongle with embedded linux platform MPC 5200 Lite
From: Wolfgang Denk @ 2006-05-19 19:15 UTC (permalink / raw)
To: jabir.kannath; +Cc: linuxppc-embedded
In-Reply-To: <41CB8F9678E6F0498DA096429793FA850D2379@blr-m3-msg.wipro.com>
In message <41CB8F9678E6F0498DA096429793FA850D2379@blr-m3-msg.wipro.com> you wrote:
>
> We are in need of re-building Linux kernel 2.4.25 to support USB
> Bluetooth Dongle for the embedded platform MPC 5200 Lite.
Have you checked that your BT dongle is really working in Linux? See
http://www.qbik.ch/usb/devices/search_res.php?pattern=bluetooth
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
An armed society is a polite society.
^ permalink raw reply
* Re: [PATCH] remove powerpc bitops infavor of existing generic bitops
From: Jon Mason @ 2006-05-19 20:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17517.20729.170817.242398@cargo.ozlabs.ibm.com>
On Fri, May 19, 2006 at 03:00:41PM +1000, Paul Mackerras wrote:
> Jon Mason writes:
>
> > There already exists a big endian safe bitops implementation in
> > lib/find_next_bit.c. The code in it is 90%+ common with the powerpc
> > specific version, so the powerpc version is redundant. This patch
> > makes the necessary changes to use the generic bitops in powerpc, and
> > removes the powerpc specific version.
>
> This patch breaks ARCH=ppc builds. Please resubmit with the necessary
> changes to arch/ppc/Kconfig as well.
>
> Paul.
Sorry. Here is the patch with the necessary correction.
Thanks,
Jon
Signed-off-by: Jon Mason <jdmason@us.ibm.com>
diff -r a89fd2f124df arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig Fri May 19 16:17:18 2006 +0700
+++ b/arch/powerpc/Kconfig Fri May 19 15:34:39 2006 -0500
@@ -42,6 +42,10 @@ config GENERIC_HWEIGHT
default y
config GENERIC_CALIBRATE_DELAY
+ bool
+ default y
+
+config GENERIC_FIND_NEXT_BIT
bool
default y
diff -r a89fd2f124df arch/powerpc/lib/Makefile
--- a/arch/powerpc/lib/Makefile Fri May 19 16:17:18 2006 +0700
+++ b/arch/powerpc/lib/Makefile Fri May 19 15:34:39 2006 -0500
@@ -7,7 +7,6 @@ obj-$(CONFIG_PPC32) += div64.o copy_32.o
obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
endif
-obj-y += bitops.o
obj-$(CONFIG_PPC64) += checksum_64.o copypage_64.o copyuser_64.o \
memcpy_64.o usercopy_64.o mem_64.o string.o \
strcase.o
diff -r a89fd2f124df arch/ppc/Kconfig
--- a/arch/ppc/Kconfig Fri May 19 16:17:18 2006 +0700
+++ b/arch/ppc/Kconfig Fri May 19 15:34:39 2006 -0500
@@ -37,6 +37,10 @@ config PPC32
# All PPCs use generic nvram driver through ppc_md
config GENERIC_NVRAM
+ bool
+ default y
+
+config GENERIC_FIND_NEXT_BIT
bool
default y
diff -r a89fd2f124df include/asm-powerpc/bitops.h
--- a/include/asm-powerpc/bitops.h Fri May 19 16:17:18 2006 +0700
+++ b/include/asm-powerpc/bitops.h Fri May 19 15:34:39 2006 -0500
@@ -288,8 +288,8 @@ static __inline__ int test_le_bit(unsign
#define __test_and_clear_le_bit(nr, addr) \
__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define find_first_zero_le_bit(addr, size) find_next_zero_le_bit((addr), (size), 0)
-unsigned long find_next_zero_le_bit(const unsigned long *addr,
+#define find_first_zero_le_bit(addr, size) generic_find_next_zero_le_bit((addr), (size), 0)
+unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
/* Bitmap functions for the ext2 filesystem */
@@ -309,7 +309,7 @@ unsigned long find_next_zero_le_bit(cons
#define ext2_find_first_zero_bit(addr, size) \
find_first_zero_le_bit((unsigned long*)addr, size)
#define ext2_find_next_zero_bit(addr, size, off) \
- find_next_zero_le_bit((unsigned long*)addr, size, off)
+ generic_find_next_zero_le_bit((unsigned long*)addr, size, off)
/* Bitmap functions for the minix filesystem. */
diff -r a89fd2f124df arch/powerpc/lib/bitops.c
--- a/arch/powerpc/lib/bitops.c Fri May 19 16:17:18 2006 +0700
+++ /dev/null Thu Jan 1 00:00:00 1970 +0000
@@ -1,150 +0,0 @@
-#include <linux/types.h>
-#include <linux/module.h>
-#include <asm/byteorder.h>
-#include <asm/bitops.h>
-
-/**
- * find_next_bit - find the next set bit in a memory region
- * @addr: The address to base the search on
- * @offset: The bitnumber to start searching at
- * @size: The maximum size to search
- */
-unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
- unsigned long offset)
-{
- const unsigned long *p = addr + BITOP_WORD(offset);
- unsigned long result = offset & ~(BITS_PER_LONG-1);
- unsigned long tmp;
-
- if (offset >= size)
- return size;
- size -= result;
- offset %= BITS_PER_LONG;
- if (offset) {
- tmp = *(p++);
- tmp &= (~0UL << offset);
- if (size < BITS_PER_LONG)
- goto found_first;
- if (tmp)
- goto found_middle;
- size -= BITS_PER_LONG;
- result += BITS_PER_LONG;
- }
- while (size & ~(BITS_PER_LONG-1)) {
- if ((tmp = *(p++)))
- goto found_middle;
- result += BITS_PER_LONG;
- size -= BITS_PER_LONG;
- }
- if (!size)
- return result;
- tmp = *p;
-
-found_first:
- tmp &= (~0UL >> (BITS_PER_LONG - size));
- if (tmp == 0UL) /* Are any bits set? */
- return result + size; /* Nope. */
-found_middle:
- return result + __ffs(tmp);
-}
-EXPORT_SYMBOL(find_next_bit);
-
-/*
- * This implementation of find_{first,next}_zero_bit was stolen from
- * Linus' asm-alpha/bitops.h.
- */
-unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
- unsigned long offset)
-{
- const unsigned long *p = addr + BITOP_WORD(offset);
- unsigned long result = offset & ~(BITS_PER_LONG-1);
- unsigned long tmp;
-
- if (offset >= size)
- return size;
- size -= result;
- offset %= BITS_PER_LONG;
- if (offset) {
- tmp = *(p++);
- tmp |= ~0UL >> (BITS_PER_LONG - offset);
- if (size < BITS_PER_LONG)
- goto found_first;
- if (~tmp)
- goto found_middle;
- size -= BITS_PER_LONG;
- result += BITS_PER_LONG;
- }
- while (size & ~(BITS_PER_LONG-1)) {
- if (~(tmp = *(p++)))
- goto found_middle;
- result += BITS_PER_LONG;
- size -= BITS_PER_LONG;
- }
- if (!size)
- return result;
- tmp = *p;
-
-found_first:
- tmp |= ~0UL << size;
- if (tmp == ~0UL) /* Are any bits zero? */
- return result + size; /* Nope. */
-found_middle:
- return result + ffz(tmp);
-}
-EXPORT_SYMBOL(find_next_zero_bit);
-
-static inline unsigned int ext2_ilog2(unsigned int x)
-{
- int lz;
-
- asm("cntlzw %0,%1": "=r"(lz):"r"(x));
- return 31 - lz;
-}
-
-static inline unsigned int ext2_ffz(unsigned int x)
-{
- u32 rc;
- if ((x = ~x) == 0)
- return 32;
- rc = ext2_ilog2(x & -x);
- return rc;
-}
-
-unsigned long find_next_zero_le_bit(const unsigned long *addr,
- unsigned long size, unsigned long offset)
-{
- const unsigned int *p = ((const unsigned int *)addr) + (offset >> 5);
- unsigned int result = offset & ~31;
- unsigned int tmp;
-
- if (offset >= size)
- return size;
- size -= result;
- offset &= 31;
- if (offset) {
- tmp = cpu_to_le32p(p++);
- tmp |= ~0U >> (32 - offset); /* bug or feature ? */
- if (size < 32)
- goto found_first;
- if (tmp != ~0)
- goto found_middle;
- size -= 32;
- result += 32;
- }
- while (size >= 32) {
- if ((tmp = cpu_to_le32p(p++)) != ~0)
- goto found_middle;
- result += 32;
- size -= 32;
- }
- if (!size)
- return result;
- tmp = cpu_to_le32p(p);
-found_first:
- tmp |= ~0 << size;
- if (tmp == ~0) /* Are any bits zero? */
- return result + size; /* Nope. */
-found_middle:
- return result + ext2_ffz(tmp);
-}
-EXPORT_SYMBOL(find_next_zero_le_bit);
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Srinivas Murthy @ 2006-05-19 21:28 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20060519162310.GI12135@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]
Thanks for the reply.
I have a couple of concerns here. I would appreciate if you could provide
your thoughts.
On a PPC (44x) platform, following an error such as parity error detected by
the PCI root complex, should we cause a bus error (causing a machine-check
exception) or complete the bus transaction normally but trigger a critical
interrupt? Note that these are two diff types of interrupts as seen by the
CPU with the machine check having the highest NMI priority.
If the parity error detection was a result of say a memory read operation by
the core to a PCI device, there might be a several cycle diff between the
read and the cpu being interrupted (with the critical interrupt handler).
This may result in data corruption, etc. Is this a valid concern to have?
What is the normal approach to deal with this issue in an "enterprise" or
high-end environment?
On 5/19/06, Linas Vepstas <linas@austin.ibm.com> wrote:
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 3062 bytes --]
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Paul Mackerras @ 2006-05-19 22:33 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <20060519161822.GL8220@pb15.lixom.net>
Olof Johansson writes:
> (My patch to rename the existing POWER* bits to ARCH_2_* wasn't picked
> up, I'll resend)
The problem is that those names are now part of the API. I'll need an
ack from the glibc developers before I apply your patch to change them.
Paul.
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Linas Vepstas @ 2006-05-19 23:00 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605191428n57c18a60h5b86863d729cd9b9@mail.gmail.com>
On Fri, May 19, 2006 at 02:28:29PM -0700, Srinivas Murthy wrote:
>
> On a PPC (44x) platform, following an error such as parity error detected by
> the PCI root complex, should we cause a bus error (causing a machine-check
> exception) or complete the bus transaction normally but trigger a critical
> interrupt? Note that these are two diff types of interrupts as seen by the
> CPU with the machine check having the highest NMI priority.
I can't answer that question; I'd say that's a platform implementation
question that each platform has to decide on thier own. If you have a
recoverable machine check, and can take it and recover from it, then
I suppose that's a reasonable choice. But I've never dealt with that.
> If the parity error detection was a result of say a memory read operation by
> the core to a PCI device, there might be a several cycle diff between the
> read and the cpu being interrupted (with the critical interrupt handler).
> This may result in data corruption, etc. Is this a valid concern to have?
Yes. Sort of. Maybe. In the early days of getting pci error handling
to work, it became clear that there were lots of pci devices with weak
firmware or buggy hardware that were dma'ing to all sorts of wild adresses,
and/or doing other bad things (mangled PCI split transactions, etc).
We became painfully aware of this, because our pci bridges flagged any DMA
to any page that hadn't been expressly mapped (as well as a bunch of
other PCI errors). Seems that these devices had been busy corrupting
memory and whatever else for years, and no one noticed before, because
no one had a stringent, error checking PCI bridge. Is data corruption
important? Yes. Have you been living with it for years, and not noticing
it? Yes.
(Most of those I dealt with have been fixed, either in the Linux device
driver, the device firmware, or in one case, a hardware change, (I assume
some gate array fixup)).
> What is the normal approach to deal with this issue in an "enterprise" or
> high-end environment?
On IBM pSeries, the PCI-Host bridge stops the transaction; I don't know
the details at the hardware level; I presume its some abort or termination.
In principle, the corrupted data never makes it to system memory or CPU.
If the CPU is reading, 0xffffffff is returned, as are all future reads.
All writes are dropped on the floor. DMA's are also cut off.
On pSeries, there's no interrupt generated on error. Rather, if the
device gets an unexpected 0xffffff on read, it can query the firmware
for the PCI bridge state, and proceed from there. Typical scenario
is that an error occurred during DMA, long ago; the device driver gets
a dma-complete interrupt from pci device, and discovers upon reading
that the device interrupt status register is all 0xffff... During
recovery, that hunk of incomplete dma data is discarded.
The point here is that its potentially OK to allow corrupted data into
systm memory, as long as its at the right address, and as long as the
device driver can nuke it before it has gotten to other consumers.
If you ar getting parity erorrs on DMA addresses, then ... :-)
PCI Express does something else, and I don't quite understand what.
Part of thier mechanism involves an interrupt, although its somehow
wired that on MMIO read, the interrupt gets to the CPU before the
MMIO read completes. Some chunk of it seems x86/itanium-centric.
The Intel guys have been trying to figure out how to implement this,
but haven't done so yet.
--linas
^ permalink raw reply
* RE: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
From: Meswani, Mitesh @ 2006-05-20 0:25 UTC (permalink / raw)
To: Segher Boessenkool, will_schmidt; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <18583972-9E29-4B52-BF2E-53102F1794EB@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]
Hello Segher and Will
I tried using these macros on some applications and they dont seem to have any effect. I am running everything as root, and have been using bind processor commands to ensure that a task is assigned to a logical cpu. Since I am running SPEC CPU benchmarks I was exepecting to see a difference in run times, CPI when running two seperate SPEC apps on SMT threads.
Is there some thing else I need to do to make sure that the processor takes the hint to "lower the HMT priority " , I am executing them from a regular shell which I assume has user level priority.
Thanks
Mitesh
Mitesh R. Meswani
Ph.D. Candidate
Research Associate, PLS2 Group
Room 106 F, Department of Computer Science
The University of Texas at El Paso,
El Paso, Texas 79968
Tel: 915 747 8012 (O)
Email: mmeswani@utep.edu
________________________________
From: Segher Boessenkool [mailto:segher@kernel.crashing.org]
Sent: Mon 5/8/2006 5:04 PM
To: will_schmidt@vnet.ibm.com
Cc: Meswani, Mitesh; linuxppc-dev@ozlabs.org; Arnd Bergmann; linux-kernel@vger.kernel.org; cbe-oss-dev@ozlabs.org
Subject: Re: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
> the HMT_* macros are telling firmware that "this processor thread
> should
> run at this priority". Typically used when we're waiting on a
> spinlock.
> I.e. When we are waiting on a spinlock, we hit the HMT_low macro to
> drop
> our threads priority, allowing the other thread to use those extra
> cycles finish it's stuff quicker, and maybe even release the lock
> we're
> waiting for. HMT_* is all within the kernel though, no
> exposure
> to userspace apps.
Actually, those macros translate straight into a single machine insn.
No firmware is involved. See include/asm-powerpc/processor.h. For
example:
#define HMT_very_low() asm volatile("or 31,31,31 # very low
priority")
You can use those same macros from user space, although it is CPU
implementation dependent which priorities you can actually set (you
probably can do low and medium priority).
Segher
[-- Attachment #2: Type: text/html, Size: 3507 bytes --]
^ permalink raw reply
* input/powermac: Cleanup of mac_hid and support for ctrl+click and command+click
From: Michael Hanselmann @ 2006-05-20 14:12 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-input, linuxppc-dev
This patch cleans up mac_hid and adds support for Ctrl+Click (right
click) and Command+Click (middle click) emulation. The latter is similar
to Mac OS X.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
---
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/char/keyboard.c linux-2.6.17-rc4/drivers/char/keyboard.c
--- linux-2.6.17-rc4.orig/drivers/char/keyboard.c 2006-05-13 12:33:45.000000000 +0200
+++ linux-2.6.17-rc4/drivers/char/keyboard.c 2006-05-19 23:33:17.000000000 +0200
@@ -40,6 +40,10 @@
#include <linux/sysrq.h>
#include <linux/input.h>
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+#include <asm/mac_hid.h>
+#endif
+
static void kbd_disconnect(struct input_handle *handle);
extern void ctrl_alt_del(void);
@@ -1052,10 +1056,6 @@ static unsigned short x86_keycodes[256]
308,310,313,314,315,317,318,319,320,357,322,323,324,325,276,330,
332,340,365,342,343,344,345,346,356,270,341,368,369,370,371,372 };
-#ifdef CONFIG_MAC_EMUMOUSEBTN
-extern int mac_hid_mouse_emulate_buttons(int, int, int);
-#endif /* CONFIG_MAC_EMUMOUSEBTN */
-
#ifdef CONFIG_SPARC
static int sparc_l1_a_state = 0;
extern void sun_do_break(void);
@@ -1151,7 +1151,7 @@ static void kbd_keycode(unsigned int key
rep = (down == 2);
#ifdef CONFIG_MAC_EMUMOUSEBTN
- if (mac_hid_mouse_emulate_buttons(1, keycode, down))
+ if (mac_hid_mouse_emulate_buttons(keycode, down))
return;
#endif /* CONFIG_MAC_EMUMOUSEBTN */
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/input/input.c linux-2.6.17-rc4/drivers/input/input.c
--- linux-2.6.17-rc4.orig/drivers/input/input.c 2006-05-13 12:33:45.000000000 +0200
+++ linux-2.6.17-rc4/drivers/input/input.c 2006-05-20 13:43:41.000000000 +0200
@@ -24,6 +24,10 @@
#include <linux/device.h>
#include <linux/mutex.h>
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+#include <asm/mac_hid.h>
+#endif
+
MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>");
MODULE_DESCRIPTION("Input core");
MODULE_LICENSE("GPL");
@@ -194,8 +198,16 @@ static void input_repeat_key(unsigned lo
if (!test_bit(dev->repeat_key, dev->key))
return;
- input_event(dev, EV_KEY, dev->repeat_key, 2);
- input_sync(dev);
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ if (!mac_hid_repeat_key(dev->repeat_key)) {
+#endif
+
+ input_event(dev, EV_KEY, dev->repeat_key, 2);
+ input_sync(dev);
+
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ }
+#endif
if (dev->rep[REP_PERIOD])
mod_timer(&dev->timer, jiffies + msecs_to_jiffies(dev->rep[REP_PERIOD]));
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/input/mousedev.c linux-2.6.17-rc4/drivers/input/mousedev.c
--- linux-2.6.17-rc4.orig/drivers/input/mousedev.c 2006-05-13 12:33:46.000000000 +0200
+++ linux-2.6.17-rc4/drivers/input/mousedev.c 2006-05-20 00:48:58.000000000 +0200
@@ -27,6 +27,9 @@
#ifdef CONFIG_INPUT_MOUSEDEV_PSAUX
#include <linux/miscdevice.h>
#endif
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+#include <asm/mac_hid.h>
+#endif
MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
MODULE_DESCRIPTION("Mouse (ExplorerPS/2) device interfaces");
@@ -316,8 +319,12 @@ static void mousedev_event(struct input_
if (value != 2) {
if (code == BTN_TOUCH && test_bit(BTN_TOOL_FINGER, handle->dev->keybit))
mousedev_touchpad_touch(mousedev, value);
- else
+ else {
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ code = mac_hid_mouse_click(code, value);
+#endif
mousedev_key_event(mousedev, code, value);
+ }
}
break;
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/macintosh/Kconfig linux-2.6.17-rc4/drivers/macintosh/Kconfig
--- linux-2.6.17-rc4.orig/drivers/macintosh/Kconfig 2006-05-13 12:33:46.000000000 +0200
+++ linux-2.6.17-rc4/drivers/macintosh/Kconfig 2006-05-20 13:29:07.000000000 +0200
@@ -144,6 +144,10 @@ config MAC_EMUMOUSEBTN
/proc/sys/dev/mac_hid/mouse_button_emulation
/proc/sys/dev/mac_hid/mouse_button2_keycode
/proc/sys/dev/mac_hid/mouse_button3_keycode
+ /proc/sys/dev/mac_hid/key_click
+
+ When key_click is enabled by writing a value other than 0 into it,
+ Ctrl+Click is for right click and Command+Click for middle click.
If you have an Apple machine with a 1-button mouse, say Y here.
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/macintosh/mac_hid.c linux-2.6.17-rc4/drivers/macintosh/mac_hid.c
--- linux-2.6.17-rc4.orig/drivers/macintosh/mac_hid.c 2006-05-13 12:33:46.000000000 +0200
+++ linux-2.6.17-rc4/drivers/macintosh/mac_hid.c 2006-05-20 14:03:20.000000000 +0200
@@ -4,8 +4,7 @@
* HID support stuff for Macintosh computers.
*
* Copyright (C) 2000 Franz Sirl.
- *
- * This file will soon be removed in favor of an uinput userspace tool.
+ * Copyright (C) 2006 Michael Hanselmann <linux-kernel@hansmi.ch>
*/
#include <linux/config.h>
@@ -14,16 +13,19 @@
#include <linux/sysctl.h>
#include <linux/input.h>
#include <linux/module.h>
-
+#include <asm/mac_hid.h>
static struct input_dev *emumousebtn;
-static int emumousebtn_input_register(void);
-static int mouse_emulate_buttons = 0;
+static int mouse_emulate_buttons;
static int mouse_button2_keycode = KEY_RIGHTCTRL; /* right control key */
static int mouse_button3_keycode = KEY_RIGHTALT; /* right option key */
-static int mouse_last_keycode = 0;
+static int key_click;
+static int key_click_active;
+static int key_click_button;
+static int key_pressed;
+static int inside_mouse_click;
-#if defined(CONFIG_SYSCTL)
+#ifdef CONFIG_SYSCTL
/* file(s) in /proc/sys/dev/mac_hid */
ctl_table mac_hid_files[] = {
{
@@ -50,6 +52,14 @@ ctl_table mac_hid_files[] = {
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = DEV_MAC_HID_KEY_CLICK,
+ .procname = "key_click",
+ .data = &key_click,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
@@ -79,33 +89,91 @@ ctl_table mac_hid_root_dir[] = {
static struct ctl_table_header *mac_hid_sysctl_header;
-#endif /* endif CONFIG_SYSCTL */
+#endif /* CONFIG_SYSCTL */
-int mac_hid_mouse_emulate_buttons(int caller, unsigned int keycode, int down)
+/* Emulate mouse buttons with keys */
+int mac_hid_mouse_emulate_buttons(unsigned int keycode, int down)
{
- switch (caller) {
- case 1:
- /* Called from keyboard.c */
- if (mouse_emulate_buttons
- && (keycode == mouse_button2_keycode
- || keycode == mouse_button3_keycode)) {
- if (mouse_emulate_buttons == 1) {
- input_report_key(emumousebtn,
- keycode == mouse_button2_keycode ? BTN_MIDDLE : BTN_RIGHT,
- down);
+ if (inside_mouse_click)
+ return 0;
+
+ if (key_click &&
+ (keycode == KEY_LEFTCTRL || keycode == KEY_RIGHTCTRL ||
+ keycode == KEY_LEFTMETA || keycode == KEY_RIGHTMETA)) {
+ if (down && !key_pressed && !key_click_active)
+ key_pressed = keycode;
+ else if (!down && keycode == key_pressed) {
+ key_pressed = 0;
+
+ if (key_click_active > 0) {
+ input_report_key(emumousebtn, key_click_active, 0);
input_sync(emumousebtn);
- return 1;
+
+ key_click_active = -1;
}
- mouse_last_keycode = down ? keycode : 0;
}
- break;
}
+
+ if (mouse_emulate_buttons) {
+ if (keycode == mouse_button2_keycode)
+ input_report_key(emumousebtn, BTN_RIGHT, down);
+ else if (keycode == mouse_button3_keycode)
+ input_report_key(emumousebtn, BTN_MIDDLE, down);
+
+ input_sync(emumousebtn);
+
+ return 1;
+ }
+
return 0;
}
-EXPORT_SYMBOL(mac_hid_mouse_emulate_buttons);
+/* Modify mouse button value if the Control key is pressed */
+int mac_hid_mouse_click(unsigned int code, int value)
+{
+ if (!key_click || code != BTN_LEFT || inside_mouse_click)
+ return code;
+
+ inside_mouse_click = 1;
+
+ if (value && key_pressed && !key_click_active) {
+ key_click_active = key_pressed;
+
+ input_report_key(emumousebtn, key_click_active, 0);
+ input_sync(emumousebtn);
+
+ if (key_click_active == KEY_LEFTMETA ||
+ key_click_active == KEY_RIGHTMETA)
+ code = BTN_MIDDLE;
+ else
+ code = BTN_RIGHT;
+
+ key_click_button = code;
+ } else if (!value && key_click_active) {
+ if (key_click_active > 0) {
+ input_report_key(emumousebtn, key_click_active, 1);
+ input_sync(emumousebtn);
+ }
-static int emumousebtn_input_register(void)
+ key_click_active = 0;
+
+ code = key_click_button;
+ }
+
+ inside_mouse_click = 0;
+
+ return code;
+}
+
+/* This function returns true if the given keycode should not
+ * be repeated.
+ */
+int mac_hid_repeat_key(unsigned int keycode)
+{
+ return (key_click && key_click_active == keycode);
+}
+
+int __init mac_hid_init(void)
{
emumousebtn = input_allocate_device();
if (!emumousebtn)
@@ -121,24 +189,22 @@ static int emumousebtn_input_register(vo
emumousebtn->keybit[LONG(BTN_MOUSE)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) | BIT(BTN_RIGHT);
emumousebtn->relbit[0] = BIT(REL_X) | BIT(REL_Y);
- input_register_device(emumousebtn);
-
- return 0;
-}
+ set_bit(KEY_LEFTCTRL, emumousebtn->keybit);
+ set_bit(KEY_RIGHTCTRL, emumousebtn->keybit);
+ set_bit(KEY_LEFTMETA, emumousebtn->keybit);
+ set_bit(KEY_RIGHTMETA, emumousebtn->keybit);
-int __init mac_hid_init(void)
-{
- int err;
-
- err = emumousebtn_input_register();
- if (err)
- return err;
+ input_register_device(emumousebtn);
-#if defined(CONFIG_SYSCTL)
+#ifdef CONFIG_SYSCTL
mac_hid_sysctl_header = register_sysctl_table(mac_hid_root_dir, 1);
-#endif /* CONFIG_SYSCTL */
+#endif
return 0;
}
device_initcall(mac_hid_init);
+
+EXPORT_SYMBOL(mac_hid_mouse_emulate_buttons);
+EXPORT_SYMBOL_GPL(mac_hid_mouse_click);
+EXPORT_SYMBOL_GPL(mac_hid_repeat_key);
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/include/asm-powerpc/mac_hid.h linux-2.6.17-rc4/include/asm-powerpc/mac_hid.h
--- linux-2.6.17-rc4.orig/include/asm-powerpc/mac_hid.h 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.17-rc4/include/asm-powerpc/mac_hid.h 2006-05-20 00:49:22.000000000 +0200
@@ -0,0 +1,13 @@
+/*
+ * HID support stuff for Macintosh computers.
+ */
+#ifndef __ASM_POWERPC_MAC_HID_H
+#define __ASM_POWERPC_MAC_HID_H
+#ifdef __KERNEL__
+
+extern int mac_hid_mouse_emulate_buttons(unsigned int keycode, int down);
+extern int mac_hid_mouse_click(unsigned int code, int value);
+extern int mac_hid_repeat_key(unsigned int keycode);
+
+#endif
+#endif
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/include/linux/sysctl.h linux-2.6.17-rc4/include/linux/sysctl.h
--- linux-2.6.17-rc4.orig/include/linux/sysctl.h 2006-05-13 12:34:00.000000000 +0200
+++ linux-2.6.17-rc4/include/linux/sysctl.h 2006-05-20 12:31:23.000000000 +0200
@@ -870,7 +870,8 @@ enum {
DEV_MAC_HID_MOUSE_BUTTON_EMULATION=3,
DEV_MAC_HID_MOUSE_BUTTON2_KEYCODE=4,
DEV_MAC_HID_MOUSE_BUTTON3_KEYCODE=5,
- DEV_MAC_HID_ADB_MOUSE_SENDS_KEYCODES=6
+ DEV_MAC_HID_ADB_MOUSE_SENDS_KEYCODES=6,
+ DEV_MAC_HID_KEY_CLICK=7,
};
/* /proc/sys/dev/scsi */
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Berg @ 2006-05-20 14:57 UTC (permalink / raw)
To: charles-debian-nospam; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060518004141.GC1552@kunpuu.plessy.org>
On Thu, 2006-18-05 at 09:41 +0900, Charles Plessy wrote:=20
> Hi all,
>=20
> just a "me too" mail:
>=20
> Le Thu, May 18, 2006 at 12:02:01AM +0200, B=C3=B8rge Holen a =C3=A9crit :
> > I can also remember half way throught a ogg/mp3 playlist when it also=20
> > scrambled the output, this has only happened ONCE.
>=20
> I experience the same on my 8,1 powermac, but more systematically. It
> takes usually more than one hour of continuous listening before it
> happens, and then it happens sort of stochastically. I am not using
> anything else than xmms, so I did not figure out if it is a xmms or a
> driver problem. Stop/Starting the listening stops the scrambling.
This is exactly the problem that I have experienced since a while now.
The problem is that some interrupts get lost. This results in a broken
address calculation and the new data is written to the wrong place.
The attached patch fixes this by checking the 'frame_count'.
What I don't really understand is, that the first time the interrupt
gets executed, the frame_count is 8 _less_ of what I would have expected
My guess is that the dma controller reads the last 32 bytes, and then
the interrupt gets fired.
diff --git a/soundbus/i2sbus/i2sbus-pcm.c b/soundbus/i2sbus/i2sbus-pcm.c
index 9eadf83..8511234 100644
--- a/soundbus/i2sbus/i2sbus-pcm.c
+++ b/soundbus/i2sbus/i2sbus-pcm.c
@@ -440,6 +440,11 @@ static int i2sbus_pcm_trigger(struct i2s
return -ENXIO;
}
=20
+ /* get the current frame_count - 32 bytes. This is just guessed,
+ but it seems that the interrupt triggers as soon as the last 32 bytes
+ are cached or something. */
+ pi->frame_count =3D in_le32(&i2sdev->intfregs->frame_count) - 0x20 / (pi=
->substream->runtime->sample_bits / 8);
+
/* wake up the chip with the next descriptor */
out_le32(&pi->dbdma->control, (RUN|WAKE) | ((RUN|WAKE)<<16));
/* off you go! */
@@ -488,13 +493,29 @@ 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;
+ u32 delta;
=20
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;
}
- pi->current_period =3D (pi->current_period+1) % (pi->periods);
+=09
+ fc =3D in_le32(&i2sdev->intfregs->frame_count);
+ /* a counter overflow does not change the calculation. */
+ delta =3D fc - pi->frame_count;
+=09
+ if (delta <=3D pi->substream->runtime->period_size) {
+ pi->current_period =3D pi->current_period + 1;
+ delta =3D 0;
+ } else while (delta >=3D pi->substream->runtime->period_size) {
+ pi->current_period =3D pi->current_period + 1;
+ delta =3D delta - pi->substream->runtime->period_size;
+ }
+=09
+ pi->frame_count =3D fc - delta;
+ pi->current_period =3D pi->current_period % pi->periods;
snd_pcm_period_elapsed(pi->substream);
}
=20
diff --git a/soundbus/i2sbus/i2sbus.h b/soundbus/i2sbus/i2sbus.h
index b054e02..f5d16aa 100644
--- a/soundbus/i2sbus/i2sbus.h
+++ b/soundbus/i2sbus/i2sbus.h
@@ -41,6 +41,7 @@ struct pcm_info {
struct snd_pcm_substream *substream;
int current_period;
int periods;
+ u32 frame_count;
struct dbdma_command_mem dbdma_ring;
volatile struct dbdma_regs __iomem *dbdma;
};
^ permalink raw reply related
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-20 20:59 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, mel, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060508141151.26912.15976.sendpatchset@skynet>
Mel Gorman <mel@csn.ul.ie> wrote:
>
>
> Size zones and holes in an architecture independent manner for x86_64.
>
>
I found a .config which triggers the cant-map-acpitables problem.
With that .config, and without this patch:
Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.6
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
DMI 2.4 present.
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
With that .config, and with this patch:
Bootdata ok (command line is ro root=LABEL=/ earlyprintk=serial,ttyS0,9600,keep netconsole=4444@192.168.2.4/eth0,5147@192.168.2.33/00:0D:56:C6:C6:CC)
Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #33 SMP Sat May 20 12:08:03 PDT 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
Too many memory regions, truncating
Too many memory regions, truncating
Too many memory regions, truncating
DMI 2.4 present.
ACPI: Unable to map RSDT header
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: Product ID: APIC at: 0xFEE00000
ACPI disables itself.
Good .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-good
Bad .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-bad
The handling of MAX_ACTIVE_REGIONS is unpleasing, sorry. In my setup it is
5. But we _really_ only support 4 regions. So for a start it is misnamed.
The maximum number of regions we support is actually MAX_ACTIVE_REGIONS-1.
And this is a config option too! So the user must specify
CONFIG_MAX_ACTIVE_REGIONS as the number of active regions plus one, for the
terminating region which has end_pfn=0. It's weird.
I would not consider this code to be adequately commented. Please raise a
patch which comments the major functions - what they do, why they do it,
any caveats or implementations details. A few lines each - don't overdo
it. Details such as whether the various end_pfn's are inclusive or
exclusive are important, as is a description of the return value.
Anyway, I just don't get how this code can work. We have an e820 map with
up to 128 entries (this machine has ten) and we're trying to scrunch that
all into the four-entry early_node_map[].
With config-good we're set up for NUMA, CONFIG_NODES_SHIFT=6. So
MAX_ACTIVE_REGIONS is enormous. But it's quite wrong that we're using
number-of-zones*number-of-nodes to size a data structure which has to
accommodate all the entries in the e820 map. These things aren't related.
On my little x86 PC:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
255MB LOWMEM available.
found SMP MP-table at 000ff780
Range (nid 0) 0 -> 65472, max 4
On node 0 totalpages: 65472
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 61376 pages, LIFO batch:15
So here, the architecture code only called add_active_range() the once, for
the entire memory map. But on the x86_64 add_active_range() was called
once per e820 entry. I'm dimly starting to realise that this is perhaps
the problem - the weird-looking definition of MAX_ACTIVE_REGIONS _expects_
the architecture to call add_active_range() with a start_pfn/end_pfn which
describes the entire range of pfns for each zone in each node. Even if
that span includes not-present pfns. Would that be correct? I didn't see
a comment in there describing this design (I do go on).
If so, perhaps the bug is that the x86_64 code isn't doing that. And that
x86 isn't doing it for some people either.
Anyway. From the implementation I can see what the code is doing. But I
see no description of what it is _supposed_ to be doing. (The process of
finding differences between these two things is known as "debugging"). I
could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
I look forward to the next version ;)
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andi Kleen @ 2006-05-20 21:27 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, Mel Gorman, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <20060520135922.129a481d.akpm@osdl.org>
> Anyway. From the implementation I can see what the code is doing. But I
> see no description of what it is _supposed_ to be doing. (The process of
> finding differences between these two things is known as "debugging"). I
> could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
> I look forward to the next version ;)
Or we could just keep the working old code.
Can somebody remind me what this patch kit was supposed to fix or improve again?
-Andi
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-20 21:40 UTC (permalink / raw)
To: Andi Kleen
Cc: davej, tony.luck, linux-mm, mel, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <200605202327.19606.ak@suse.de>
Andi Kleen <ak@suse.de> wrote:
>
>
> > Anyway. From the implementation I can see what the code is doing. But I
> > see no description of what it is _supposed_ to be doing. (The process of
> > finding differences between these two things is known as "debugging"). I
> > could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
> > I look forward to the next version ;)
>
> Or we could just keep the working old code.
>
> Can somebody remind me what this patch kit was supposed to fix or improve again?
>
Well, it creates arch-neutral common code, teaches various architectures
use it. It's the sort of thing we do all the time.
These things are opportunities to eliminate crufty arch code which few
people understand and replace them with new, clean common code which lots
of people understand. That's not a bad thing to be doing.
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andi Kleen @ 2006-05-20 22:17 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, mel, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <20060520144043.22f993b1.akpm@osdl.org>
> Well, it creates arch-neutral common code, teaches various architectures
> use it. It's the sort of thing we do all the time.
>
> These things are opportunities to eliminate crufty arch code which few
> people understand and replace them with new, clean common code which lots
> of people understand. That's not a bad thing to be doing.
I'm not fundamentally against that, but so far it seems to just generate lots of
new bugs? I'm not sure it's really worth the pain.
-Andi
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-20 22:54 UTC (permalink / raw)
To: Andi Kleen
Cc: davej, tony.luck, linux-mm, mel, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <200605210017.59984.ak@suse.de>
Andi Kleen <ak@suse.de> wrote:
>
>
> > Well, it creates arch-neutral common code, teaches various architectures
> > use it. It's the sort of thing we do all the time.
> >
> > These things are opportunities to eliminate crufty arch code which few
> > people understand and replace them with new, clean common code which lots
> > of people understand. That's not a bad thing to be doing.
>
> I'm not fundamentally against that, but so far it seems to just generate lots of
> new bugs? I'm not sure it's really worth the pain.
>
It is a bit disproportionate. But in some ways that's a commentary on the
current code. All this numa/sparse/flat/discontig/holes-in-zones/
virt-memmap/ stuff is pretty hairy, especially in its initalisation.
I'm willing to go through the pain if it ends up with something cleaner
which more people understand a little bit.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-20 23:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148034127.15507.178.camel@johannes>
> 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?
What do you mean by lost interrupts ?
DBDMA sends edge interrupts. Thus, if it emits interrupts A, then B and
C, and for any reason, your kenrel is not able to service interrupts (is
doing something with IRQs disabled) from before B happens to after C
happens, you'll indeed get called only twice (A and C) and "B" will be
sort-of lost.
First thing about that is: what the heck is causing us to have such a
latency !!! that would be useful to figure out. A way to do that would
be maybe to "detect" when C happens that we missed B (see below how to
do that) and print something along with the regs->nip & lr (or even a
backtrace). That might give us an idea of there interrupts are
re-enabled after the long latency which could perhaps lead us to the
cause of the latency.
Now for detecting lost interrupts (and for being immune to them), the
technique is not to just assume IRQ -> 1 period completed, but instead,
when an irq happens, to go read the DBDMA descriptors in memory to see
which ones have actually been completed. Their status field should be
updated as their get comleted. Thus, you keep track of the "previous"
last completed descriptor and you walk from that to recycle them.
Since we can only update the framecounter on a per-period basis, the
driver would benefit from having lots of very small periods. I don't
know if we can provide "hints" to userland about that though. Using the
i2s frame counter means we need some kind of calibration... it might
still be counting if for the reason the DBDMA "misses" something or gets
stopped....
Ben.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-20 23:59 UTC (permalink / raw)
To: Benjamin Berg; +Cc: linuxppc-dev, debian-powerpc, charles-debian-nospam
In-Reply-To: <1148137032.3407.12.camel@localhost>
On Sat, 2006-05-20 at 16:57 +0200, Benjamin Berg wrote:
> On Thu, 2006-18-05 at 09:41 +0900, Charles Plessy wrote:
> > Hi all,
> >
> > just a "me too" mail:
> >
> > Le Thu, May 18, 2006 at 12:02:01AM +0200, Børge Holen a écrit :
> > > I can also remember half way throught a ogg/mp3 playlist when it also
> > > scrambled the output, this has only happened ONCE.
> >
> > I experience the same on my 8,1 powermac, but more systematically. It
> > takes usually more than one hour of continuous listening before it
> > happens, and then it happens sort of stochastically. I am not using
> > anything else than xmms, so I did not figure out if it is a xmms or a
> > driver problem. Stop/Starting the listening stops the scrambling.
>
> This is exactly the problem that I have experienced since a while now.
> The problem is that some interrupts get lost. This results in a broken
> address calculation and the new data is written to the wrong place.
See my other mail about that. Worth tracking down. As far as the DBDMA
handling is concerned, I think walking the descriptors and harvesting
status bits is a better approach as it also allows you to get error
status if you ever get any. Now, if you can have some reliable frame
counter, that's definitely something to look into passing userland too.
> The attached patch fixes this by checking the 'frame_count'.
> What I don't really understand is, that the first time the interrupt
> gets executed, the frame_count is 8 _less_ of what I would have expected
> My guess is that the dma controller reads the last 32 bytes, and then
> the interrupt gets fired.
The DBDMA definitely has a fifo. By the time you get the IRQ, it may
have started pumping the "next" packet. 32 bytes sounds about right for
the DBDMA fifo... old DBDMAs had 16 bits iirc but I could imagine Apple
improving that.
> diff --git a/soundbus/i2sbus/i2sbus-pcm.c b/soundbus/i2sbus/i2sbus-pcm.c
> index 9eadf83..8511234 100644
> --- a/soundbus/i2sbus/i2sbus-pcm.c
> +++ b/soundbus/i2sbus/i2sbus-pcm.c
> @@ -440,6 +440,11 @@ static int i2sbus_pcm_trigger(struct i2s
> return -ENXIO;
> }
>
> + /* get the current frame_count - 32 bytes. This is just guessed,
> + but it seems that the interrupt triggers as soon as the last 32 bytes
> + are cached or something. */
> + pi->frame_count = in_le32(&i2sdev->intfregs->frame_count) - 0x20 / (pi->substream->runtime->sample_bits / 8);
> +
> /* wake up the chip with the next descriptor */
> out_le32(&pi->dbdma->control, (RUN|WAKE) | ((RUN|WAKE)<<16));
> /* off you go! */
> @@ -488,13 +493,29 @@ 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;
> + u32 delta;
>
> 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;
> }
> - pi->current_period = (pi->current_period+1) % (pi->periods);
> +
> + fc = in_le32(&i2sdev->intfregs->frame_count);
> + /* a counter overflow does not change the calculation. */
> + delta = fc - pi->frame_count;
> +
> + if (delta <= pi->substream->runtime->period_size) {
> + pi->current_period = pi->current_period + 1;
> + delta = 0;
> + } else while (delta >= pi->substream->runtime->period_size) {
> + pi->current_period = pi->current_period + 1;
> + delta = delta - pi->substream->runtime->period_size;
> + }
> +
> + pi->frame_count = fc - delta;
> + pi->current_period = pi->current_period % pi->periods;
> snd_pcm_period_elapsed(pi->substream);
> }
>
> diff --git a/soundbus/i2sbus/i2sbus.h b/soundbus/i2sbus/i2sbus.h
> index b054e02..f5d16aa 100644
> --- a/soundbus/i2sbus/i2sbus.h
> +++ b/soundbus/i2sbus/i2sbus.h
> @@ -41,6 +41,7 @@ struct pcm_info {
> struct snd_pcm_substream *substream;
> int current_period;
> int periods;
> + u32 frame_count;
> struct dbdma_command_mem dbdma_ring;
> volatile struct dbdma_regs __iomem *dbdma;
> };
>
>
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-21 15:50 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060520135922.129a481d.akpm@osdl.org>
On Sat, 20 May 2006, Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>>
>> Size zones and holes in an architecture independent manner for x86_64.
>>
>>
>
> I found a .config which triggers the cant-map-acpitables problem.
>
>
> With that .config, and without this patch:
>
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.6
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> DMI 2.4 present.
> ACPI: PM-Timer IO Port: 0x408
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Processor #0 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> Processor #1 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
> ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>
>
> With that .config, and with this patch:
>
> Bootdata ok (command line is ro root=LABEL=/ earlyprintk=serial,ttyS0,9600,keep netconsole=4444@192.168.2.4/eth0,5147@192.168.2.33/00:0D:56:C6:C6:CC)
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #33 SMP Sat May 20 12:08:03 PDT 2006
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> Too many memory regions, truncating
> Too many memory regions, truncating
> Too many memory regions, truncating
> DMI 2.4 present.
> ACPI: Unable to map RSDT header
> Intel MultiProcessor Specification v1.4
> Virtual Wire compatibility mode.
> OEM ID: Product ID: APIC at: 0xFEE00000
>
> ACPI disables itself.
>
ok, not good but at least it's certain. I had been lulled into a false
sense of security when Christian's machine was still not able to boot with
the patch backed out. I still have not reproduced the problem locally, but
I don't have an x86_64 with so many holes either.
> Good .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-good
> Bad .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-bad
>
>
> The handling of MAX_ACTIVE_REGIONS is unpleasing, sorry. In my setup it is
> 5. But we _really_ only support 4 regions. So for a start it is misnamed.
> The maximum number of regions we support is actually MAX_ACTIVE_REGIONS-1.
> And this is a config option too! So the user must specify
> CONFIG_MAX_ACTIVE_REGIONS as the number of active regions plus one, for the
> terminating region which has end_pfn=0. It's weird.
>
That's a fair comment. I'll put more thought into the definition of
MAX_ACTIVE_REGIONS and how it is used.
> I would not consider this code to be adequately commented. Please raise a
> patch which comments the major functions - what they do, why they do it,
> any caveats or implementations details. A few lines each - don't overdo
> it. Details such as whether the various end_pfn's are inclusive or
> exclusive are important, as is a description of the return value.
>
Understood. Right now, the closest thing to an explanation is a comment in
include/linux/mm.h but it is not very detailed.
> Anyway, I just don't get how this code can work. We have an e820 map with
> up to 128 entries (this machine has ten) and we're trying to scrunch that
> all into the four-entry early_node_map[].
>
Missing E820MAX was a mistake. On x86_64, CONFIG_MAX_ACTIVE_REGIONS should
have been used. I didn't expect x86_64 to have so many memory holes.
> With config-good we're set up for NUMA, CONFIG_NODES_SHIFT=6. So
> MAX_ACTIVE_REGIONS is enormous. But it's quite wrong that we're using
> number-of-zones*number-of-nodes to size a data structure which has to
> accommodate all the entries in the e820 map. These things aren't related.
>
Very true.
>
> On my little x86 PC:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
> BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
> BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
> BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> 0MB HIGHMEM available.
> 255MB LOWMEM available.
> found SMP MP-table at 000ff780
> Range (nid 0) 0 -> 65472, max 4
> On node 0 totalpages: 65472
> DMA zone: 4096 pages, LIFO batch:0
> Normal zone: 61376 pages, LIFO batch:15
>
> So here, the architecture code only called add_active_range() the once, for
> the entire memory map.
Because in this case, the architecture reported that there was just one
range of available pages with no holes.
> But on the x86_64 add_active_range() was called once per e820 entry.
> I'm dimly starting to realise that this is perhaps the problem - the
> weird-looking definition of MAX_ACTIVE_REGIONS _expects_ the
> architecture to call add_active_range() with a start_pfn/end_pfn which
> describes the entire range of pfns for each zone in each node. Even if
> that span includes not-present pfns. Would that be correct?
Not quite and the confusion is because of how I defined
MAX_ACTIVE_REGIONS. The calculation for it is similar to how i386 using
SRAT calculates MAX_CHUNKS;
#define MAX_CHUNKS_PER_NODE 4
#define MAXCHUNKS (MAX_CHUNKS_PER_NODE * MAX_NUMNODES)
which has little bearing on any other arch.
What is meant to happen is that add_active_range() is called for every
range of physical page frames where real memory is, regardless of what
zone they are in. On x86_64, the ranges are discovered by walking the e820
map in e820_register_active_ranges(). Once it is known where physical
memory is, the holes can be figured out. If I have;
Range (nid 0) 0 -> 100
Range (nid 0) 200 -> 400
I know there is a memory hole of 100 pages. The end PFN of each zone is
passed to free_area_init_nodes(). By walking the early_node_map[], it can
be discovered what the size of the zone and the holes are.
> I didn't see
> a comment in there describing this design (I do go on).
>
I'll address that issue.
> If so, perhaps the bug is that the x86_64 code isn't doing that. And that
> x86 isn't doing it for some people either.
>
I'm hoping in this case that having MAX_ACTIVE_REGIONS match E820MAX will
fix the issue on your machine. I'm still confused why Christian's failed
to boot with the patch backed out though.
> Anyway. From the implementation I can see what the code is doing. But I
> see no description of what it is _supposed_ to be doing. (The process of
> finding differences between these two things is known as "debugging"). I
> could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
> I look forward to the next version ;)
>
I'll start working on it. Thanks a lot.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-21 16:20 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Morton, davej, tony.luck, linux-mm, linux-kernel,
bob.picco, linuxppc-dev
In-Reply-To: <200605202327.19606.ak@suse.de>
On Sat, 20 May 2006, Andi Kleen wrote:
>
>> Anyway. From the implementation I can see what the code is doing. But I
>> see no description of what it is _supposed_ to be doing. (The process of
>> finding differences between these two things is known as "debugging"). I
>> could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
>> I look forward to the next version ;)
>
> Or we could just keep the working old code.
>
> Can somebody remind me what this patch kit was supposed to fix or
> improve again?
>
The current code for discovering the zone sizes and holes is sometimes
very hairy despite there being some similaries in each arch. This patch
kit will eliminiate some of the uglier code and have one place where zones
and holes can be sized. To me, that is a good idea once the bugs are
rattled out.
On a related note, parts of the current zone-based anti-fragmentation
implementation are an architecture-specific mess because changing how
zones are sized is tricky with the current code. With this patch kit,
sizing zones for easily reclaimable pages is relatively straight-forward.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* HDLC ENET over SCC3
From: Antonio Di Bacco @ 2006-05-21 16:57 UTC (permalink / raw)
To: linuxppc-embedded
I'm using Denk kernel 2.4.25 and eldk 3.1.1
Is is supporting HDLC over SCC3?
Bye,
Antonio.
^ 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