* Re: [PATCH] remove geometry support from ps3 storage driver
From: Geert Uytterhoeven @ 2007-05-21 14:36 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070521125311.GA27626@aepfle.de>
Hi Olaf,
On Mon, 21 May 2007, Olaf Hering wrote:
> The old ps3_storage driver did not support DOS geometry, so there is no
> point to start adding code for it.
Thanks! I didn't know the .getgeo() routine is optional. I thought it was used
by disk partitioning software.
cfdisk seems to be happy after this change.
sfdisk complains it cannot get the geometry, but it continuous, assuming H=64
and S=32.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* [PATCH] set module owner in ps3 modules
From: Olaf Hering @ 2007-05-21 12:54 UTC (permalink / raw)
To: Geoff Levand, linuxppc-dev
In-Reply-To: <20070521125311.GA27626@aepfle.de>
setting ->owner will help with refcounting (?) and it provides proper
symlinks in sysfs.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Index: linux-2.6.22-rc2/drivers/block/ps3disk.c
===================================================================
--- linux-2.6.22-rc2.orig/drivers/block/ps3disk.c
+++ linux-2.6.22-rc2/drivers/block/ps3disk.c
@@ -425,6 +411,7 @@ static int ps3disk_remove(struct ps3_sys
static struct ps3_system_bus_driver ps3disk = {
.match_id = PS3_MATCH_ID_STOR_DISK,
.core.name = DEVICE_NAME,
+ .core.owner = THIS_MODULE,
.probe = ps3disk_probe,
.remove = ps3disk_remove,
.shutdown = ps3disk_remove,
Index: linux-2.6.22-rc2/drivers/char/ps3flash.c
===================================================================
--- linux-2.6.22-rc2.orig/drivers/char/ps3flash.c
+++ linux-2.6.22-rc2/drivers/char/ps3flash.c
@@ -467,6 +467,7 @@ static int ps3flash_remove(struct ps3_sy
static struct ps3_system_bus_driver ps3flash = {
.match_id = PS3_MATCH_ID_STOR_FLASH,
.core.name = DEVICE_NAME,
+ .core.owner = THIS_MODULE,
.probe = ps3flash_probe,
.remove = ps3flash_remove,
.shutdown = ps3flash_remove,
Index: linux-2.6.22-rc2/drivers/net/gelic_net.c
===================================================================
--- linux-2.6.22-rc2.orig/drivers/net/gelic_net.c
+++ linux-2.6.22-rc2/drivers/net/gelic_net.c
@@ -1576,6 +1576,7 @@ static struct ps3_system_bus_driver ps3_
.shutdown = ps3_gelic_driver_remove,
.core = {
.name = "ps3_gelic_driver",
+ .owner = THIS_MODULE,
},
};
Index: linux-2.6.22-rc2/drivers/scsi/ps3rom.c
===================================================================
--- linux-2.6.22-rc2.orig/drivers/scsi/ps3rom.c
+++ linux-2.6.22-rc2/drivers/scsi/ps3rom.c
@@ -907,6 +907,7 @@ static int ps3rom_remove(struct ps3_syst
static struct ps3_system_bus_driver ps3rom = {
.match_id = PS3_MATCH_ID_STOR_ROM,
.core.name = DEVICE_NAME,
+ .core.owner = THIS_MODULE,
.probe = ps3rom_probe,
.remove = ps3rom_remove
};
Index: linux-2.6.22-rc2/drivers/usb/host/ehci-ps3.c
===================================================================
--- linux-2.6.22-rc2.orig/drivers/usb/host/ehci-ps3.c
+++ linux-2.6.22-rc2/drivers/usb/host/ehci-ps3.c
@@ -229,6 +229,7 @@ static struct ps3_system_bus_driver ps3_
.match_id = PS3_MATCH_ID_EHCI,
.core = {
.name = "ps3-ehci-driver",
+ .owner = THIS_MODULE,
},
.probe = ps3_ehci_probe,
.remove = ps3_ehci_remove,
Index: linux-2.6.22-rc2/drivers/usb/host/ohci-ps3.c
===================================================================
--- linux-2.6.22-rc2.orig/drivers/usb/host/ohci-ps3.c
+++ linux-2.6.22-rc2/drivers/usb/host/ohci-ps3.c
@@ -233,6 +233,7 @@ static struct ps3_system_bus_driver ps3_
.match_id = PS3_MATCH_ID_OHCI,
.core = {
.name = "ps3-ohci-driver",
+ .owner = THIS_MODULE,
},
.probe = ps3_ohci_probe,
.remove = ps3_ohci_remove,
Index: linux-2.6.22-rc2/sound/ppc/snd_ps3.c
===================================================================
--- linux-2.6.22-rc2.orig/sound/ppc/snd_ps3.c
+++ linux-2.6.22-rc2/sound/ppc/snd_ps3.c
@@ -1020,6 +1020,7 @@ static struct ps3_system_bus_driver snd_
.shutdown = snd_ps3_driver_remove,
.core = {
.name = SND_PS3_DRIVER_NAME,
+ .owner = THIS_MODULE,
},
};
^ permalink raw reply
* [PATCH] remove geometry support from ps3 storage driver
From: Olaf Hering @ 2007-05-21 12:53 UTC (permalink / raw)
To: Geoff Levand, linuxppc-dev
The old ps3_storage driver did not support DOS geometry, so there is no
point to start adding code for it.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Index: linux-2.6.22-rc2/drivers/block/ps3disk.c
===================================================================
--- linux-2.6.22-rc2.orig/drivers/block/ps3disk.c
+++ linux-2.6.22-rc2/drivers/block/ps3disk.c
@@ -43,10 +43,6 @@
#define KERNEL_SECTOR_SIZE 512
-// FIXME SCSI uses H=64, S=32. Can we still repartition disks partitioned using
-// the old driver?
-#define PS3DISK_HEADS 255
-#define PS3DISK_SECTORS 63
#define PS3DISK_NAME "ps3d%c"
@@ -70,21 +66,11 @@ static int ps3disk_open(struct inode *in
return 0;
}
-static int ps3disk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
-{
- geo->heads = PS3DISK_HEADS;
- geo->sectors = PS3DISK_SECTORS;
- geo->cylinders = min(65535UL,
- get_capacity(bdev->bd_disk) /
- (PS3DISK_HEADS * PS3DISK_SECTORS));
- return 0;
-}
static struct block_device_operations ps3disk_fops = {
.owner = THIS_MODULE,
.open = ps3disk_open,
- .getgeo = ps3disk_getgeo,
};
static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
^ permalink raw reply
* RE: Fixed PHY problems
From: Hammond Christian-r55079 @ 2007-05-21 12:46 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1179656221.2714.19.camel@gentoo-jocke.transmode.se>
Thanks,
Regarding the PHY set-up in the dts once the patch has been applied, how
should it be implemented?
I had edited from...
phy1: ethernet-phy@01 {
reg =3D <0>;
device_type =3D "ethernet-phy";
interface =3D <6>;
};=20
To...
phy1: fixed-phy@64 {
reg =3D <d#100>;
device_type =3D "ethernet-phy";
interface =3D <6>;
};
When bringing up the fixed phy in ifconfig I get the following recurring
dump and prompt access is lost. Should this implementation not just
ignore the phy set-up?
~ # ifconfig eth1 10.137.32.175 netmask 255.255.255.0 up
read wrong value : mii_id 100,mii_reg 2, base d100c120
read wrong value : mii_id 100,mii_reg 3, base d100c120
eth1: PHY is Generic MII (ffffffff)
~ # read wrong value : mii_id 100,mii_reg 4, base d100c120
read wrong value : mii_id 100,mii_reg 0, base d100c120
read wrong value : mii_id 100,mii_reg 1, base d100c120
read wrong value : mii_id 100,mii_reg 1, base d100c120
read wrong value : mii_id 100,mii_reg 5, base d100c120
eth1: Full Duplex
eth1: Speed 100BT
eth1: Link is up
read wrong value : mii_id 100,mii_reg 1, base d100c120
read wrong value : mii_id 100,mii_reg 1, base d100c120
read wrong value : mii_id 100,mii_reg 5, base d100c120
=20
-----Original Message-----
From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20
Sent: 20 May 2007 11:17
To: Hammond Christian-r55079
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Fixed PHY problems
On Sat, 2007-05-19 at 15:42 +0100, Hammond Christian-r55079 wrote:
> Hi Vitaly,
> =20
> I was pointed in the direction of message chain "Fixed PHY problems"
> for interfacing a fixed PHY to a 83xx UEC. Could you please forward on
> the patch you mentioned in the trail?
Vitaly sent me the patch, had to do some minor tweaking to make it
compile. Attaching the patch.
> =20
> Any ideas if the implementation succeeded in the end?
No, the fixed PHY is on another bus than what ucc_geth expects.
See msg from me titled "Fixed PHY and MPC832x based boards don't work"
from about a week ago.
Jocke
> =20
> Christian Hammond
> =20
> NCSG Applications Engineer
> =20
> Tel: +44 1355 355962
> Fax: +44 1355 261790
> =20
> Freescale Semiconductor
> Kelvin Industrial Estate
> East Kilbride
> Glasgow G75 0TG
> United Kingdom
^ permalink raw reply
* lite5200b, trouble with dtb
From: Pradyumna Sampath @ 2007-05-21 11:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
Hi everyone,
Last time around (
http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg02602.html
) , I was trying to boot my lite5200 eval board with v2.6.20-rt3 and
was advised to boot with the dtb files.
This time around Im trying to boot my custom lite5200B board with the
dtb file thats comes with the vanilla kernel and it hangs at the same
point ( "Transferring control to linux (at address 00000000 ..." ).
I edited my dts file to be the most basic to boot linux (attached).
I booted my eval board with "DEBUG" and I got this.
## Transferring control to Linux (at address 00000000) ...
[ 0.000000] -> early_init_devtree()
[ 0.000000] search "chosen", depth: 0, uname:
[ 0.000000] search "chosen", depth: 1, uname: cpus
[ 0.000000] search "chosen", depth: 2, uname: PowerPC,5200@0
[ 0.000000] search "chosen", depth: 1, uname: memory
However, even with DEBUG enabled I dont get a single charecter out
from the custom board.
What am I doing wrong ?
thanks in advance.
regards
prady
[-- Attachment #2: lite5200b_2_6_21.dts --]
[-- Type: application/octet-stream, Size: 8874 bytes --]
/*
* Lite5200B board Device Tree Source
*
* Copyright 2006-2007 Secret Lab Technologies Ltd.
* Grant Likely <grant.likely@secretlab.ca>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/*
* WARNING: Do not depend on this tree layout remaining static just yet.
* The MPC5200 device tree conventions are still in flux
* Keep an eye on the linuxppc-dev mailing list for more details
*/
/ {
model = "fsl,lite5200b";
// revision = "1.0";
compatible = "fsl,lite5200b\0generic-mpc5200";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,5200@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>;
i-cache-line-size = <20>;
d-cache-size = <4000>; // L1, 16K
i-cache-size = <4000>; // L1, 16K
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
32-bit;
};
};
memory {
device_type = "memory";
// reg = <00000000 10000000>; // 256MB
reg = <00000000 04000000>; // 64MB
};
soc5200@f0000000 {
model = "fsl,mpc5200b";
revision = ""; // from bootloader
#interrupt-cells = <3>;
device_type = "soc";
ranges = <0 f0000000 f0010000>;
reg = <f0000000 00010000>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
cdm@200 {
compatible = "mpc5200b-cdm\0mpc5200-cdm";
reg = <200 38>;
};
pic@500 {
// 5200 interrupts are encoded into two levels;
linux,phandle = <500>;
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
compatible = "mpc5200b-pic\0mpc5200-pic";
reg = <500 80>;
built-in;
};
// gpt@600 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <0>;
// reg = <600 10>;
// interrupts = <1 9 0>;
// interrupt-parent = <500>;
// has-wdt;
// };
// gpt@610 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <1>;
// reg = <610 10>;
// interrupts = <1 a 0>;
// interrupt-parent = <500>;
// };
// gpt@620 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <2>;
// reg = <620 10>;
// interrupts = <1 b 0>;
// interrupt-parent = <500>;
// };
// gpt@630 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <3>;
// reg = <630 10>;
// interrupts = <1 c 0>;
// interrupt-parent = <500>;
// };
// gpt@640 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <4>;
// reg = <640 10>;
// interrupts = <1 d 0>;
// interrupt-parent = <500>;
// };
// gpt@650 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <5>;
// reg = <650 10>;
// interrupts = <1 e 0>;
// interrupt-parent = <500>;
// };
// gpt@660 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <6>;
// reg = <660 10>;
// interrupts = <1 f 0>;
// interrupt-parent = <500>;
// };
// gpt@670 { // General Purpose Timer
// compatible = "mpc5200b-gpt\0mpc5200-gpt";
// device_type = "gpt";
// cell-index = <7>;
// reg = <670 10>;
// interrupts = <1 10 0>;
// interrupt-parent = <500>;
// };
// rtc@800 { // Real time clock
// compatible = "mpc5200b-rtc\0mpc5200-rtc";
// device_type = "rtc";
// reg = <800 100>;
// interrupts = <1 5 0 1 6 0>;
// interrupt-parent = <500>;
// };
// mscan@900 {
// device_type = "mscan";
// compatible = "mpc5200b-mscan\0mpc5200-mscan";
// cell-index = <0>;
// interrupts = <2 11 0>;
// interrupt-parent = <500>;
// reg = <900 80>;
// };
// mscan@980 {
// device_type = "mscan";
// compatible = "mpc5200b-mscan\0mpc5200-mscan";
// cell-index = <1>;
// interrupts = <1 12 0>;
// interrupt-parent = <500>;
// reg = <980 80>;
// };
// gpio@b00 {
// compatible = "mpc5200b-gpio\0mpc5200-gpio";
// reg = <b00 40>;
// interrupts = <1 7 0>;
// interrupt-parent = <500>;
// };
// gpio-wkup@b00 {
// compatible = "mpc5200b-gpio-wkup\0mpc5200-gpio-wkup";
// reg = <c00 40>;
// interrupts = <1 8 0 0 3 0>;
// interrupt-parent = <500>;
// };
// pci@0d00 {
// #interrupt-cells = <1>;
// #size-cells = <2>;
// #address-cells = <3>;
// device_type = "pci";
// compatible = "mpc5200b-pci\0mpc5200-pci";
// reg = <d00 100>;
// interrupt-map-mask = <f800 0 0 7>;
// interrupt-map = <c000 0 0 1 500 0 0 3 // 1st slot
// c000 0 0 2 500 1 1 3
// c000 0 0 3 500 1 2 3
// c000 0 0 4 500 1 3 3
//
// c800 0 0 1 500 1 1 3 // 2nd slot
// c800 0 0 2 500 1 2 3
// c800 0 0 3 500 1 3 3
// c800 0 0 4 500 0 0 3>;
// clock-frequency = <0>; // From boot loader
// interrupts = <2 8 0 2 9 0 2 a 0>;
// interrupt-parent = <500>;
// bus-range = <0 0>;
// ranges = <42000000 0 80000000 80000000 0 20000000
// 02000000 0 a0000000 a0000000 0 10000000
// 01000000 0 00000000 b0000000 0 01000000>;
// };
// spi@f00 {
// device_type = "spi";
// compatible = "mpc5200b-spi\0mpc5200-spi";
// reg = <f00 20>;
// interrupts = <2 d 0 2 e 0>;
// interrupt-parent = <500>;
// };
// usb@1000 {
// device_type = "usb-ohci-be";
// compatible = "mpc5200b-ohci\0mpc5200-ohci\0ohci-be";
// reg = <1000 ff>;
// interrupts = <2 6 0>;
// interrupt-parent = <500>;
// };
// bestcomm@1200 {
// device_type = "dma-controller";
// compatible = "mpc5200b-bestcomm\0mpc5200-bestcomm";
// reg = <1200 80>;
// interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
// 3 4 0 3 5 0 3 6 0 3 7 0
// 3 8 0 3 9 0 3 a 0 3 b 0
// 3 c 0 3 d 0 3 e 0 3 f 0>;
// interrupt-parent = <500>;
// };
// xlb@1f00 {
// compatible = "mpc5200b-xlb\0mpc5200-xlb";
// reg = <1f00 100>;
// };
serial@2000 { // PSC1
device_type = "serial";
compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
port-number = <0>; // Logical port assignment
cell-index = <0>;
reg = <2000 100>;
interrupts = <2 1 0>;
interrupt-parent = <500>;
};
// PSC2 in ac97 mode example
//ac97@2200 { // PSC2
// device_type = "sound";
// compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
// cell-index = <1>;
// reg = <2200 100>;
// interrupts = <2 2 0>;
// interrupt-parent = <500>;
//};
// PSC3 in CODEC mode example
//i2s@2400 { // PSC3
// device_type = "sound";
// compatible = "mpc5200b-psc-i2s"; //not 5200 compatible
// cell-index = <2>;
// reg = <2400 100>;
// interrupts = <2 3 0>;
// interrupt-parent = <500>;
//};
// PSC4 in uart mode example
//serial@2600 { // PSC4
// device_type = "serial";
// compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
// cell-index = <3>;
// reg = <2600 100>;
// interrupts = <2 b 0>;
// interrupt-parent = <500>;
//};
// PSC5 in uart mode example
//serial@2800 { // PSC5
// device_type = "serial";
// compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
// cell-index = <4>;
// reg = <2800 100>;
// interrupts = <2 c 0>;
// interrupt-parent = <500>;
//};
// PSC6 in spi mode example
//spi@2c00 { // PSC6
// device_type = "spi";
// compatible = "mpc5200b-psc-spi\0mpc5200-psc-spi";
// cell-index = <5>;
// reg = <2c00 100>;
// interrupts = <2 4 0>;
// interrupt-parent = <500>;
//};
// ethernet@3000 {
// device_type = "network";
// compatible = "mpc5200b-fec\0mpc5200-fec";
// reg = <3000 800>;
// mac-address = [ 02 03 04 05 06 07 ]; // Bad!
// interrupts = <2 5 0>;
// interrupt-parent = <500>;
// };
// ata@3a00 {
// device_type = "ata";
// compatible = "mpc5200b-ata\0mpc5200-ata";
// reg = <3a00 100>;
// interrupts = <2 7 0>;
// interrupt-parent = <500>;
// };
// i2c@3d00 {
// device_type = "i2c";
// compatible = "mpc5200b-i2c\0mpc5200-i2c";
// cell-index = <0>;
// reg = <3d00 40>;
// interrupts = <2 f 0>;
// interrupt-parent = <500>;
// };
//
// i2c@3d40 {
// device_type = "i2c";
// compatible = "mpc5200b-i2c\0mpc5200-i2c";
// cell-index = <1>;
// reg = <3d40 40>;
// interrupts = <2 10 0>;
// interrupt-parent = <500>;
// };
// sram@8000 {
// device_type = "sram";
// compatible = "mpc5200b-sram\0mpc5200-sram\0sram";
// reg = <8000 4000>;
// };
};
};
^ permalink raw reply
* Re: fsl booke MM vs. SMP questions
From: Dave Liu @ 2007-05-21 11:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev, Paul Mackerras, Kumar Gala
In-Reply-To: <1179742083.32247.689.camel@localhost.localdomain>
On Mon, 2007-05-21 at 20:08 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-05-21 at 17:57 +0800, Dave Liu wrote:
>
> > > If not, you might have to use a _PAGE_BUSY bit similar to what 64 bits
> > > uses as a per-PTE lock, or use mmu_hash_lock... Unless you come up with
> > > a great idea or some HW black magic that makes the problem go away...
> >
> > I would like the _PAGE_BUSY bit for a per-PTE lock, it will have better
> > performance benifit than global lock. The BookE architecutre doesn't use
> > the hardware hash table, so can not use the mmu_hash_lock, which is
> > global lock for hashtable.
>
> (BTW. Did you remove the list CC on purpose ? If not, then please add it
> back on your reply and make sure my reply is fully visible :-)
Sorry for that, It is wrong to click the mouse.
> Still.. having to use a lwarx/stwcx. loop in the TLB refill handler is a
> sad story don't you think ? I don't know for you guys but on the cpus I
> know, those take hundres of cycles....
It is true, I know that.
> I've come up with an idea (thanks wli for tipping me off) that's
> inspired from RCU instead:
>
> We have a per-cpu flag called tlbbusy
>
> The tlb miss handler does:
>
> - tlbbusy = 1
> - barrier (make sure the following read is in order vs. the previous
> store to tlbbusy)
> - read linux PTE value
> - write it to the HW TLB
and write the linux PTE with referenced bit?
> - appropriate sync
> - tlbbusy = 0
>
> Now, the tlb invalidation code (which can use a batch to be even more
> efficient, see how 64 bits or x86 use batching for TLB invalidations)
> can then use the fact that the mm carries a cpu bitmask of all CPUs that
> ever touched that mm and thus can do, after a PTE has changed and before
> broadcasting an invalidation:
How to interlock this PTE change with the PTE change of tlb miss?
> - make a local copy "mask" of the mm->cpu_vm_mask
> - clear bit for the current cpu from the mask
> - while there is still a bit in the mask
> - for each bit in the mask, check if tlbbusy for that cpu is 0
> -> if 0, clear the bit in the mask
> - loop until there's nop more bit in the mask
> - perform the tlbivax
It looks like good idea, but what is the bad things with the batch
invalidation?
> In addition, if you have a "local" version of tlbivax (no broadcast),
> you can do a nice optimisation if after step 2 (clear bit for the
> current cpu) the mask is already 0 (that means the mm only ever existed
> on the local cpu), in which case you can do a local tlbivax and return.
The BookE has the "local" version of tlbivax with the tlbwe inst. Yes,
It actually can reduce the bus traffic.
^ permalink raw reply
* Re: Using kprobes [was Re: [PATCH] Performance Stats: Kernel patch
From: Maxim Uvarov @ 2007-05-21 15:28 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Andrew Morton, pavel, wli, dada1
In-Reply-To: <20070511172304.GI4452@austin.ibm.com>
Linas Vepstas wrote:
>On Thu, May 10, 2007 at 11:12:42AM -0700, Andrew Morton wrote:
>
>
>>I don't think the syscall-counting feature has a future, sorry. Perhaps
>>you could do something like hooking it up on-demand by insertion of a kprobe,
>>dunno.
>>
>>
>
>This is an interesting point. I've started fiddling with (a wrapper
>around) kprobes that allows me to pick any subroutine symbol in System.map,
>and then get an event whenever that subroutine gets called. Its pretty
>slick, and allows me to gather data on certain unusual events in the
>kernel. (I'm not using this for performance monitoring, I'm trying to
>do RAS).
>
>It makes a lot of sense to me to have a generic kprobe extension, where
>you could give it a list of subroutine names, and it'll collect stats
>on the number of times that the routine was called. Some user-space thingy
>could poll for those stats, or you could put them in /sys or wherever.
>
>Its more complicted than just instriumenting syscalls, but a lot more
>useful, I would think ...
>
>--linas
>
>
>
Thanks Linas, but do you think that kprobes is safe for syscall counting?
I think that the overhead will be much bigger in that case. In my case it is
1 line asm instruction and it is defended with #ifdefs.
Kprobes is very good thing. But is not clear for me how to count
per-thread statistics.
In my case I increased struct thread_info. In case with kprobes it is
easy to count all
do_fork execution, for example, but not for each thread. And in any
case, place for keeping this
counters is needed.
Maxim.
^ permalink raw reply
* Re: [PATCH] unbreak lite5200 dts (_pic vs. -pic)
From: Sylvain Munaut @ 2007-05-21 7:45 UTC (permalink / raw)
To: Domen Puncer; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20070521065600.GD20713@moe.telargo.com>
Acked-by: Sylvain Munaut <tnt@246tNt.com>
Paul, can you pick this up for you next send ? Here's the patchwork link
in case
you don't follow -embedded.
http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11248
Sylvain
Domen Puncer wrote:
> Unbreak lite5200 dts, which were broken by
> 5c1992f83304cf2d56934dd6c06709b96e1b0c81
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
>
> ---
> arch/powerpc/boot/dts/lite5200.dts | 2 +-
> arch/powerpc/boot/dts/lite5200b.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200.dts
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200.dts
> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200.dts
> @@ -67,7 +67,7 @@
> interrupt-controller;
> #interrupt-cells = <3>;
> device_type = "interrupt-controller";
> - compatible = "mpc5200_pic";
> + compatible = "mpc5200-pic";
> reg = <500 80>;
> built-in;
> };
> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> @@ -67,7 +67,7 @@
> interrupt-controller;
> #interrupt-cells = <3>;
> device_type = "interrupt-controller";
> - compatible = "mpc5200b-pic\0mpc5200_pic";
> + compatible = "mpc5200b-pic\0mpc5200-pic";
> reg = <500 80>;
> built-in;
> };
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: MPC5200 ethernet communication stops unexpected
From: Eberhard Stoll @ 2007-05-21 7:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5b525e390705150803l516a5d9x9c214e2b4b00ea0e@mail.gmail.com>
Hi,
> xlb = (struct mpc52xx_xlb *)MPC5xxx_XLB;
> out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_BSDIS);
>
this modification seems to solve my problem, too (ethernet communication
stops unexpected / best comm tx task deadlock(?))!
As i described before ping -f triggered the problem in between 20
minutes everytime. With this patch my configuration to trigger the fault
run from Friday to Monday (> 60h) without any error!
So it seems for me this solved my problem, too!
Best regards,
Eberhard
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
^ permalink raw reply
* Re: [PATCH] [POWERPC] Comment out a currently unused function
From: Stephen Rothwell @ 2007-05-21 7:36 UTC (permalink / raw)
To: michael; +Cc: ppc-dev, paulus
In-Reply-To: <1179731970.5579.0.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Mon, 21 May 2007 17:19:30 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> Why not remove it? You can always get it back with git.
Because I am hopeful that the comment on the module_exit() line is
implying that the maintainer (or someone else who knows what is going on)
is intending to fis it up soon. :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] mpc52xx_psc_spi: fix it for CONFIG_PPC_MERGE
From: Dragos Carp @ 2007-05-21 7:31 UTC (permalink / raw)
To: Domen Puncer; +Cc: spi-devel-general, David Brownell, linuxppc-embedded
In-Reply-To: <20070516073707.GD9667@nd47.coderock.org>
Acked-by: Dragos Carp <dragos.carp@toptica.com>
Domen Puncer wrote:
> Fix mpc5200 PSC SPI driver to actually work for CONFIG_PPC_MERGE
> - s/mpc52xx/mpc5200/, as this was changed in device tree some time ago
> - fix spi id detection
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
>
> ---
> drivers/spi/mpc52xx_psc_spi.c | 25 +++++++++++--------------
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> Index: work-powerpc.git/drivers/spi/mpc52xx_psc_spi.c
> ===================================================================
> --- work-powerpc.git.orig/drivers/spi/mpc52xx_psc_spi.c
> +++ work-powerpc.git/drivers/spi/mpc52xx_psc_spi.c
> @@ -329,8 +329,8 @@ static int mpc52xx_psc_spi_port_config(i
> int ret = 0;
>
> #if defined(CONFIG_PPC_MERGE)
> - cdm = mpc52xx_find_and_map("mpc52xx-cdm");
> - gpio = mpc52xx_find_and_map("mpc52xx-gpio");
> + cdm = mpc52xx_find_and_map("mpc5200-cdm");
> + gpio = mpc52xx_find_and_map("mpc5200-gpio");
> #else
> cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
> gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
> @@ -445,9 +445,6 @@ static int __init mpc52xx_psc_spi_do_pro
> struct spi_master *master;
> int ret;
>
> - if (pdata == NULL)
> - return -ENODEV;
> -
> master = spi_alloc_master(dev, sizeof *mps);
> if (master == NULL)
> return -ENOMEM;
> @@ -594,17 +591,17 @@ static int __init mpc52xx_psc_spi_of_pro
> }
> regaddr64 = of_translate_address(op->node, regaddr_p);
>
> + /* get PSC id (1..6, used by port_config) */
> if (op->dev.platform_data == NULL) {
> - struct device_node *np;
> - int i = 0;
> + const u32 *psc_nump;
>
> - for_each_node_by_type(np, "spi") {
> - if (of_find_device_by_node(np) == op) {
> - id = i;
> - break;
> - }
> - i++;
> + psc_nump = of_get_property(op->node, "cell-index", NULL);
> + if (!psc_nump || *psc_nump > 5) {
> + printk(KERN_ERR "mpc52xx_psc_spi: Device node %s has invalid "
> + "cell-index property\n", op->node->full_name);
> + return -EINVAL;
> }
> + id = *psc_nump + 1;
> }
>
> return mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64,
> @@ -617,7 +614,7 @@ static int __exit mpc52xx_psc_spi_of_rem
> }
>
> static struct of_device_id mpc52xx_psc_spi_of_match[] = {
> - { .type = "spi", .compatible = "mpc52xx-psc-spi", },
> + { .type = "spi", .compatible = "mpc5200-psc-spi", },
> {},
> };
>
>
>
>
--
Dragos Carp
Research & Development
Phone: +49 89 85837-159, Fax: +49 89 85837-200
Address: TOPTICA Photonics AG, Lochhamer Schlag 19, D-82166 Graefelfing, Germany
TOPTICA – A Passion for Precision
TOPTICA Photonics AG, Registered Office: 82166 Graefelfing, Germany
Companies' Register: Amtsgericht München, HRB 137368
Executive Directors: Dr. Wilhelm Kaenders, Dr. Thomas Weber
Chairman of the Supervisory Board: Dr. Kristian Hohla
www.toptica.com
^ permalink raw reply
* Re: [PATCH] fix celleb link failure
From: Ishizaki Kou @ 2007-05-21 7:28 UTC (permalink / raw)
To: hch; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070516103752.GA22383@lst.de>
> Index: linux-2.6.20/arch/powerpc/platforms/celleb/Makefile
> ===================================================================
> ---
linux-2.6.20.orig/arch/powerpc/platforms/celleb/Makefile 2007-05-
16 11:36:28.000000000 +0200
> +++
linux-2.6.20/arch/powerpc/platforms/celleb/Makefile 2007-05-16
11:36:41.000000000 +0200
> @@ -4,5 +4,5 @@ obj-y += interrupt.o iommu.o
setup.o
>
> obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_PPC_UDBG_BEAT) += udbg_beat.o
> -obj-$(CONFIG_HAS_TXX9_SERIAL) += scc_sio.o
> +obj-$(CONFIG_SERIAL_TXX9) += scc_sio.o
> obj-$(CONFIG_SPU_BASE) += spu_priv1.o
Acked-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Thanks.
Best regards,
Kou Ishizaki
^ permalink raw reply
* RE: BDI2000 configuration file for MPC8313E-RDB
From: Frank Prepelica @ 2007-05-21 7:25 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
> > Leonid asked:
> > And here most important question comes: for our actual HW we are
going=20
> > to use ST-Micro NAND flash, one of NAND512-B, NAND01G-B, NAND02G-B,=20
> > NAND04G-B and NAND08G-B. Is BDI2000 capable of programming these=20
> > flashes? What changes in .cfg file are required?
> Sorry, but the BDI does not support programming any NAND flash.
> You can write your own driver. Then load the data and the driver into=20
> SDRAM via the BDI and execute it.
Well, I think I have to try this, if there's really no other way.=20
I'm not quite sure, maybe you know the PowerTAB Pro JTAG Debugger,
(it's recommended in the manuals) could this one get directly access
to NAND memory?
> I'm afraid I didn't understand you. Are you saying that you actually
> were able to program NAND using BDI2000? I would like to know how you
> achieved that. I suspect that was some kind of "indirect" procedure,
> Ruedi wrote about, but please provide details.
Uhm, it's possible that achieved that in an "indirect" way that I was
not aware of. But as I said, the complete flash and ram was empty, just
loaded=20
the corresponding BDI config file to BDI2000 JTAG and I got access to
flash memory where I placed the bootloader image. Hmm, anyway ;)
The BDI config: http://www.ultsol.com/config/Emb%20Planet/83xx.cfg
Best regards
Frank
^ permalink raw reply
* Re: [PATCH] [POWERPC] Comment out a currently unused function
From: Michael Ellerman @ 2007-05-21 7:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070521154026.640320cd.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
On Mon, 2007-05-21 at 15:40 +1000, Stephen Rothwell wrote:
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/macintosh/windfarm_smu_sat.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --git a/drivers/macintosh/windfarm_smu_sat.c b/drivers/macintosh/windfarm_smu_sat.c
> index 1043b39..42b767a 100644
> --- a/drivers/macintosh/windfarm_smu_sat.c
> +++ b/drivers/macintosh/windfarm_smu_sat.c
> @@ -400,10 +400,12 @@ static int __init sat_sensors_init(void)
> return i2c_add_driver(&wf_sat_driver);
> }
>
> +#if 0 /* uncomment when module_exit() below is uncommented */
> static void __exit sat_sensors_exit(void)
> {
> i2c_del_driver(&wf_sat_driver);
> }
> +#endif
Why not remove it? You can always get it back with git.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* fsl booke MM vs. SMP questions
From: Benjamin Herrenschmidt @ 2007-05-21 7:06 UTC (permalink / raw)
To: ppc-dev; +Cc: Kumar Gala, Paul Mackerras
Hi Folks !
I see that the fsl booke code has some #ifdef CONFIG_SMP bits here or
there, thus I suppose there are some SMP implementations of these
right ?
I'm having some serious issues trying to figure out how the TLB
management is made SMP safe however.
There are at least two main issues I've spotted at this point (there's
at least one more if there are HW threading, that is the TLB is shared
between logical processors, but I'll ignore that for now since I don't
think there is such a thing ... yet).
- How do you guys shield PTE flushing vs. TLB misses on another CPU ?
That is, how do you prevent (if you do) the following scenario:
cpu 0 cpu 1
tlb miss pte_clear (or similar)
load PTE value
write 0 to PTE (or replace)
tlbviax (tlbie)
tlbwe
That scenario, as you can see, will leave you with stale entries in the
TLB which will ultimately lead to all sort of unpleasant/random
behaviours.
If the answer is "oops ... we don't", then let's try to find out ways
out of that since I may have a similar issue in a not too distant
future :-) And I'm trying to find out a -fast- way to deal with that
without bloating the fast path. My main problem is that I want to avoid
taking a spin lock or equivalent atomic operation in the fast TLB reload
path (which would solve the problem) since lwarx/stwcx. are generally
real slow (hundreds of cycles on some processors).
- I see that your TLB miss handle is using a non-atomic store to write
the _PAGE_ACCESSED bit back to the PTE. Don't you have a similar race
where something would do:
cpu 0 cpu 1
tlb miss pte_clear (or similar)
load PTE value
write 0 to PTE (or replace)
write back PTE with _PAGE_ACCESSED
tlbwe
This is an extension of the previous race but it's a different problem
so I listed it separately. In that case, the problem is worse, since not
only you have a stale TLB entry, but you -also- have corrupted the linux
PTE by writing back the old value in it.
At this point, I'm afraid you may have no choice but going atomic, which
means paying the cost of lwarx/stwcx. on TLB misses, though if you have
a solution for the first problem, then you can avoid the atomic
operation in the second problem if _PAGE_ACCESSED is already set.
If not, you might have to use a _PAGE_BUSY bit similar to what 64 bits
uses as a per-PTE lock, or use mmu_hash_lock... Unless you come up with
a great idea or some HW black magic that makes the problem go away...
In any case, I'm curious about how you have or intend to solve that
since as I said above, I might be in a similar situation soon and am
trying to keep the TLB miss handler as fast as humanly possible.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] unbreak lite5200 dts (_pic vs. -pic)
From: Domen Puncer @ 2007-05-21 6:56 UTC (permalink / raw)
To: linuxppc-embedded
Unbreak lite5200 dts, which were broken by
5c1992f83304cf2d56934dd6c06709b96e1b0c81
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
arch/powerpc/boot/dts/lite5200.dts | 2 +-
arch/powerpc/boot/dts/lite5200b.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200.dts
===================================================================
--- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200.dts
+++ work-powerpc.git/arch/powerpc/boot/dts/lite5200.dts
@@ -67,7 +67,7 @@
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
- compatible = "mpc5200_pic";
+ compatible = "mpc5200-pic";
reg = <500 80>;
built-in;
};
Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
===================================================================
--- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
+++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
@@ -67,7 +67,7 @@
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
- compatible = "mpc5200b-pic\0mpc5200_pic";
+ compatible = "mpc5200b-pic\0mpc5200-pic";
reg = <500 80>;
built-in;
};
^ permalink raw reply
* linux support for am29lv641ml
From: Nethra @ 2007-05-21 5:26 UTC (permalink / raw)
To: linuxppc-dev
hi,
I have tested jffs2 booting on board MPC8272ADS and PQ2FADS-ZU board.
linux is 2.6.10 and boot loarder is u-boot-1.1.2.
Now we r using custom board simillar to MPC8272ADS board...
but flash we r using here is AM29LV641ML.But jffs2 booting is not working.
does kernel has support for this flash..?, if not how to add the support for
this flash?
with regards,
Nethra.
--
View this message in context: http://www.nabble.com/linux-support-for-am29lv641ml-tf3788347.html#a10713345
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] [POWERPC] Comment out a currently unused function
From: Stephen Rothwell @ 2007-05-21 5:40 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/macintosh/windfarm_smu_sat.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/drivers/macintosh/windfarm_smu_sat.c b/drivers/macintosh/windfarm_smu_sat.c
index 1043b39..42b767a 100644
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -400,10 +400,12 @@ static int __init sat_sensors_init(void)
return i2c_add_driver(&wf_sat_driver);
}
+#if 0 /* uncomment when module_exit() below is uncommented */
static void __exit sat_sensors_exit(void)
{
i2c_del_driver(&wf_sat_driver);
}
+#endif
module_init(sat_sensors_init);
/*module_exit(sat_sensors_exit); Uncomment when cleanup is implemented */
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH] ibm_emac: Correctly detect old link speed
From: David Gibson @ 2007-05-21 5:13 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200705162044.47776.sr@denx.de>
On Wed, May 16, 2007 at 08:44:47PM +0200, Stefan Roese wrote:
> On Wednesday 16 May 2007, Eugene Surovegin wrote:
> > On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote:
> > > This patch fixes a bug where the link speed change was not
> > > detected correctly. This occured on a 440SPe (EMAC4) system
> > > where the old link speed was 100Mbps and the new link speed
> > > is 1000Mbps.
> >
> > Good catch, Stefan. Unfortunately, I have to NACK your patch - you
> > broke non EMAC4 builds.
>
> Yes, you're right of course.
>
> > Correct fix is just to remove EMAC_MR1_MF_1000GPCS from the first
> > if condition.
>
> Yep.
>
> > I'll send correct fix shortly along with other queued patches.
>
> Thanks.
I've merged essentially the same fix into the device tree aware
"new_emac" driver.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: New version of the device tree aware EMAC driver
From: David Gibson @ 2007-05-21 5:06 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <464B475A.4090808@ru.mvista.com>
On Wed, May 16, 2007 at 10:03:06PM +0400, Valentine Barshak wrote:
> Valentine Barshak wrote:
> > David Gibson wrote:
> >
> >> I've made a few more tiny tweaks to BenH's rewritten device-tree based
> >> 4xx EMAC driver. The main change is that it now no longer requires
> >> 'device_type', just 'compatible' to be set in the ZMII and MAL device
> >> nodes when probing. This works better with current thinking on
> >> flattened device trees which discourages creating new device_type
> >> values unless there is a clear use for a new device class binding.
> >>
> >> The patch can be obtained from:
> >>
> >> http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070516.patch
> >>
> >>
> >>
> > In __emac_mdio_read and __emac_mdio_write functions:
> >
> > + if (!emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
> > + r |= EMAC_STACR_OC;
> >
> > should be
> >
> > + if (emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
> > + r |= EMAC_STACR_OC;
> >
> > Thanks.
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> With the above 2 fixes (and Marvell 88E1111 Ethernet PHY support added)
> seems to work fine on Sequoia PPC440EPx,
> thanks.
Ok, I've merged those fixes. New version of the driver coming soon.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] [POWERPC] Some extra via-pmu exports
From: Stephen Rothwell @ 2007-05-21 5:05 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
pmu_battery_count, pmu_batteries, pmu_power_flags were only exported
for 32 bit builds but are now needed for 64 bit as well.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/macintosh/via-pmu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 157080b..07c189c 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2841,10 +2841,10 @@ EXPORT_SYMBOL(pmu_wait_complete);
EXPORT_SYMBOL(pmu_suspend);
EXPORT_SYMBOL(pmu_resume);
EXPORT_SYMBOL(pmu_unlock);
-#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
-EXPORT_SYMBOL(pmu_enable_irled);
EXPORT_SYMBOL(pmu_battery_count);
EXPORT_SYMBOL(pmu_batteries);
EXPORT_SYMBOL(pmu_power_flags);
+#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
+EXPORT_SYMBOL(pmu_enable_irled);
#endif /* CONFIG_PM && CONFIG_PPC32 */
--
1.5.1.4
^ permalink raw reply related
* Re: powerpc 750cl availability
From: Rogelio Serrano @ 2007-05-21 2:54 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <4650CFEE.8020007@genesi-usa.com>
On 5/21/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Here's a long shot - have you tried IBM and Tundra? :D
>
> Both should be highly available right now. You could try one of the
> larger electronic suppliers (Arrow, AVnet, EDV) on the phone, sometimes
> they just don't put it on the website as they're more special orders,
> but they can all get anything you like.
>
i found them in avnet. i found out that you actually have to try
different combinations of letters and punctuation. the 750cl is
actually less then 60 usd for one piece.
the tsi-110 is nowhere to be found though. i think i have to call
tundra in hong kong. otherwise i will settle for the tsi-109.
i will be publishing the schematic and pcb layout. i dont have enough
resources to actually test it. i guess i just have to take the risk of
simulating the entire board, send the pcb to the fab, populate, reflow
and cross my fingers and then flip the switch...
if magic smoke escapes, order another set...
i think i will not be going on a vacation for the next five years ;-)
^ permalink raw reply
* Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?
From: Benjamin Herrenschmidt @ 2007-05-21 1:56 UTC (permalink / raw)
To: Christian Böhme; +Cc: linuxppc-dev
In-Reply-To: <4650E27B.3020401@gmx.de>
> Has anyone any idea what causes the audio output to die prematurely ?
Nope... it can't be a routing problem since interrupt -is- routed (you
are getting it !) unless I missed some subtle breakage in the
device-tree.
Which exact tipb model is this ? (cat /proc/device-tree/model)
Cheers,
Ben.
^ permalink raw reply
* Interrupt routing broken on TiBook IV with 2.6.21.x ?
From: Christian Böhme @ 2007-05-21 0:06 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
With the availability of the stable 2.6.21.x kernels I recently started to
move over from OSS to ALSA for audio I/O. Along with that move came the
surprise that not the simplest audio output works anymore (actually, this
was the case with the stable 2.6.20.x kernels and OSS already which I
therefore opted to avoid).
The problem I ran into is that no matter which application (speaker-test,
aplay, xmms, gxine) using either the native ALSA API or via the OSS
compatibility layer, none of these is able to sustain audio output for
more than 7 seconds. In fact, most attempts max out at statistically one
second (with many even shorter than that). After the signal at the output
jack died, the application appears to be blocking forever (it does not spin)
with no signs of ending its output.
I initially presented this problem on alsa-user@lists.sourceforge.net where
someone suggested that it might actually be caused by (broken) interrupt
routing for the built-in audio device. This assumption may be supported
by the observation that once the sound previously produced by the application
(speaker-test in the simplest case) stopped being sent through the output
jack, no increase in the interrupt counter occurs.
An example output of /proc/interrupts on my machine looks like this (why
eth0 does not show up in this listing is beyond me):
CPU0
19: 39005 MPIC 1 Level ide0
20: 34 MPIC 1 Level ide1
25: 151785 MPIC 1 Level VIA-PMU
26: 131 MPIC 1 Level keywest i2c
27: 1 MPIC 1 Level ohci_hcd:usb1
28: 1 MPIC 1 Level ohci_hcd:usb2
30: 197 MPIC 1 Edge PMac Output
31: 1 MPIC 1 Edge PMac Input
40: 2 MPIC 1 Level ohci1394
42: 0 MPIC 1 Level keywest i2c
47: 7682 MPIC 1 Level GPIO1 ADB
48: 39571 MPIC 1 Level radeon@pci:0000:00:10.0
57: 0 MPIC 1 Level eth1
58: 1 MPIC 1 Level yenta
61: 1 MPIC 1 Edge Sound Headphone Detection
BAD: 0
Has anyone any idea what causes the audio output to die prematurely ?
Cheers,
Christian
^ permalink raw reply
* Re: powerpc 750cl availability
From: Matt Sealey @ 2007-05-20 22:47 UTC (permalink / raw)
To: Rogelio Serrano; +Cc: linuxppc-dev
In-Reply-To: <a9951d2a0705201044v38a4c41cy8e83c72481d0113e@mail.gmail.com>
Here's a long shot - have you tried IBM and Tundra? :D
Both should be highly available right now. You could try one of the
larger electronic suppliers (Arrow, AVnet, EDV) on the phone, sometimes
they just don't put it on the website as they're more special orders,
but they can all get anything you like.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Rogelio Serrano wrote:
> does anybody know any suppliers for the powerpc 750cl and the tsi110?
> i cant seem to find it on the web anywhere.
>
> is there an end user board available anywhere?
>
> i have loaded the schematics in gschem and i am planning to start pcb
> layouting but im not sure if the parts are available.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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