* Re: [PATCH] Remove ft_ordered from flatdevtree.c
From: David Gibson @ 2007-05-14 0:18 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <11789057794165-git-send-email-becky.bruce@freescale.com>
On Fri, May 11, 2007 at 12:49:39PM -0500, Becky Bruce wrote:
> AFAICT, nobody is using this function, and it causes a build warning
> to be generated. This patch cleans that up by removing the function
> and the commented-out code that calls it.
>
> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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: [PATCH 3/9] powerpc/ppc32: Update mpc52xx_psc structure with B revision changes
From: Matt Sealey @ 2007-05-13 23:46 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Linux PPC dev ML
In-Reply-To: <11790019223925-git-send-email-tnt@246tNt.com>
Would a note next to these new fields be worth it? "5200B only" or
"reserved on 5200" or even create a new PSC structure for the old
processor and recast it in drivers that really want to support both
revisions of the CPU?
Real nitpick:
Setting the CCR on the MPC5200 (not B) now means you need to left
shift your required CCR values by 16 bits before applying them into
the field for the desired effect.
If you were being lazy and just wanted to set some low-order bits
in the CCR on the 5200, with the old structure that's fine. With
the new structure, it will be writing into previously reserved
space on the 5200. The 5200B might work fine, unless it's a driver
someone missed, and is programming a value that should be in the
upper 16 bits of the new CCR, in which case now you have to left
shift by 16 bits.. :)
I don't suppose it matters a great deal (who uses an original MPC5200?),
but it would be an intrusive change if any drivers did actually use the
CCR already.. it's nice to mention somewhere though, I guess.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Sylvain Munaut wrote:
> On the mpc5200b the ccr register is 32 bits wide while on the
> mpc5200 it's only 16 bits. It's up to the driver to use the
> correct format depending on the chip it's running on.
>
> The 5200b also offers some more registers & status in AC97
> mode. Again, if not running on a 5200b the driver should not
> use those.
>
> Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
> ---
> include/asm-ppc/mpc52xx_psc.h | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-ppc/mpc52xx_psc.h b/include/asm-ppc/mpc52xx_psc.h
> index 9d850b2..c82b8d4 100644
> --- a/include/asm-ppc/mpc52xx_psc.h
> +++ b/include/asm-ppc/mpc52xx_psc.h
> @@ -28,6 +28,10 @@
> #define MPC52xx_PSC_MAXNUM 6
>
> /* Programmable Serial Controller (PSC) status register bits */
> +#define MPC52xx_PSC_SR_UNEX_RX 0x0001
> +#define MPC52xx_PSC_SR_DATA_VAL 0x0002
> +#define MPC52xx_PSC_SR_DATA_OVR 0x0004
> +#define MPC52xx_PSC_SR_CMDSEND 0x0008
> #define MPC52xx_PSC_SR_CDE 0x0080
> #define MPC52xx_PSC_SR_RXRDY 0x0100
> #define MPC52xx_PSC_SR_RXFULL 0x0200
> @@ -132,8 +136,10 @@ struct mpc52xx_psc {
> u8 reserved5[3];
> u8 ctlr; /* PSC + 0x1c */
> u8 reserved6[3];
> - u16 ccr; /* PSC + 0x20 */
> - u8 reserved7[14];
> + u32 ccr; /* PSC + 0x20 */
> + u32 ac97_slots; /* PSC + 0x24 */
> + u32 ac97_cmd; /* PSC + 0x28 */
> + u32 ac97_data; /* PSC + 0x2c */
> u8 ivr; /* PSC + 0x30 */
> u8 reserved8[3];
> u8 ip; /* PSC + 0x34 */
^ permalink raw reply
* Re: [PATCH 4/9] powerpc: BestComm core support for Freescale MPC5200
From: Matt Sealey @ 2007-05-13 23:29 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <4646BB76.1080602@246tNt.com>
Sylvain Munaut wrote:
>>> However, you could totally implement a "DMA devices" that would just
>>> use a simple "copy from there to there" task using this BestComm driver.
>>> So other part of the kernel (like network) could use that interface to
>>> use the dma engine ...
>>>
>> Can it also do the advanced operations like XOR on DMA that the
>> Intel ioat has? That would be even more interesting, I guess.
>>
> Actually yes it can.
> It just need someone motivated enough to write it ;)
Isn't there an XOR-while-copying-DMA example somewhere?
I'm sure I've seen reference to it, or it being used somewhere.. to
be honest the worst part of using BestComm is it's only well documented
on how to use tasks and how to set up the engine, actually writing them
is some kind of black art which Freescale hold close to their chest.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Fixed PHY and MPC832x based boards don't work
From: Joakim Tjernlund @ 2007-05-13 22:25 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070514003633.6710879e@localhost.localdomain>
On Mon, 2007-05-14 at 00:36 +0400, Vitaly Bordug wrote:
> On Sun, 13 May 2007 16:39:30 +0200
> Joakim Tjernlund wrote:
>
> > Trying to make the Fixed PHY work under my 832x based board on current
> > linus tree without success. Earlier kernels with custom PHY code for
> > ucc_geth work without any special tricks.
> >
> > If I enable the FIXED_MII_100_FDX option I get:
> > ls bus/mdio_bus/devices/
> > fixed@100:1@
> >
> > but ucc_geth wants its PHYs under
> > ls -l bus/of_platform/devices/*phy*
> > lrwxrwxrwx 1 root root 0 May 12 17:32
> > bus/of_platform/devices/ethernet-p hy.1
> > -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.1/
> > lrwxrwxrwx 1 root root 0 May 12 17:32
> > bus/of_platform/devices/ethernet-p hy.3
> > -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.3/
> > lrwxrwxrwx 1 root root 0 May 12 17:32
> > bus/of_platform/devices/fixed-phy. 2
> > -> ../../../devices/e0100000.qe/e0102320.mdio/fixed-phy.2/ These are
> > 3 PHYs I just added in the DTS tree:
> >
> > mdio@2320 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <2320 18>;
> > device_type = "mdio";
> > compatible = "ucc_geth_phy";
> >
> > phy1: ethernet-phy@18 {
> > linux,phandle = <212000>;
> > reg = <18>; // 24
> > device_type = "ethernet-phy";
> > interface = <3>; //ENET_100_MII
> > };
> > phy2: fixed-phy@64 {
> > linux,phandle = <212001>;
> > reg = <d#100>;
> > device_type = "ethernet-phy";
> > };
> > phy3: ethernet-phy@19 {
> > linux,phandle = <212002>;
> > interrupt-parent = <700>;
> > interrupts = <12 2>;
> > reg = <19>; // 25
> > device_type = "ethernet-phy";
> > interface = <3>; //ENET_100_MII
> > };
> > };
> >
> > How do I add a fixed PHY so that ucc_geth finds it?
> >
> well I guess ucc stuff follows gianfar trend in mdio bus specification for the phy.
> So, it would look like %d:%d or something like that.
>
> Can you please dump the whole dts here?
Sure, it look pretty much like the 832x_mds
phy2 is my experiment to get hold of the fixed phy, but the others should also be converted into a fixed phy. Here goes my DTS:
/ {
model = "TMCUTU";
compatible = "MPC83xx";
#address-cells = <1>;
#size-cells = <1>;
linux,phandle = <100>;
board {
bd_version = <1>;
slot_pos = <0>;
board_type = <0>;
sys_type = <0>;
sys_mode = <0>;
sys_rev = <0>;
subrack_id = <0>;
power_on_start = <0>;
target = <0>;
bi_r_version = "1234X1234X1234X1234X1234X1234X1234X";
enable_usb = <0>;
};
flash@f8000000 {
device_type = "rom";
compatible = "direct-mapped";
probe-type = "CFI";
reg = <f8000000 08000000>;
bank-width = <2>;
partitions = <00000000 00010000 /* HRCW */
00010000 00008000 /* env0 */
00018000 00008000 /* env1 */
00020000 00040000 /* u-boot0 */
00060000 00040000 /* u-boot1 */
000a0000 001e0000 /* kernel */
00280000 07d60000 /* JFFS2 */
>;
partition-names = "HRCW\0env0\0env1\0u-boot0\0u-boot1\0kernel\0JFFS2";
};
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
linux,phandle = <200>;
PowerPC,8321@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // Estimated by linux
bus-frequency = <0>;
clock-frequency = <0>;
32-bit;
linux,phandle = <201>;
// linux,boot-cpu;
};
};
memory {
device_type = "memory";
linux,phandle = <300>;
reg = <00000000 10000000>; //256 MB
//reg = <00000000 8000000>; //128 MB
};
soc8321@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
bus-frequency = <0>; //Set by boot
/*
wdt@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
reg = <200 100>;
};
*/
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = <700>;
dfsrr;
};
/*
i2c@3100 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3100 100>;
interrupts = <f 8>;
interrupt-parent = <700>;
dfsrr;
};
*/
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
clock-frequency = <0>; //Set by boot
interrupts = <9 8>;
interrupt-parent = <700>;
};
/*
serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>;
clock-frequency = <FBC5200>;
interrupts = <a 8>;
interrupt-parent = <700>;
};
*/
/*
crypto@30000 {
device_type = "crypto";
model = "SEC2";
compatible = "talitos";
reg = <30000 10000>;
interrupts = <b 8>;
interrupt-parent = <700>;
num-channels = <4>;
channel-fifo-len = <18>;
exec-units-mask = <0000007e>;
//desc mask is for rev1.x, we need runtime fixup for >=2.x
descriptor-types-mask = <01010ebf>;
};
*/
/*
pci@8500 {
linux,phandle = <8500>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
// IDSEL 0x11 AD17
8800 0 0 1 700 14 8
8800 0 0 2 700 15 8
8800 0 0 3 700 16 8
8800 0 0 4 700 17 8
// IDSEL 0x12 AD18
9000 0 0 1 700 16 8
9000 0 0 2 700 17 8
9000 0 0 3 700 14 8
9000 0 0 4 700 15 8
// IDSEL 0x13 AD19
9800 0 0 1 700 17 8
9800 0 0 2 700 14 8
9800 0 0 3 700 15 8
9800 0 0 4 700 16 8
// IDSEL 0x15 AD21
a800 0 0 1 700 14 8
a800 0 0 2 700 15 8
a800 0 0 3 700 16 8
a800 0 0 4 700 17 8
// IDSEL 0x16 AD22
b000 0 0 1 700 17 8
b000 0 0 2 700 14 8
b000 0 0 3 700 15 8
b000 0 0 4 700 16 8
// IDSEL 0x17 AD23
b800 0 0 1 700 16 8
b800 0 0 2 700 17 8
b800 0 0 3 700 14 8
b800 0 0 4 700 15 8
// IDSEL 0x18 AD24
c000 0 0 1 700 15 8
c000 0 0 2 700 16 8
c000 0 0 3 700 17 8
c000 0 0 4 700 14 8>;
interrupt-parent = <700>;
interrupts = <42 8>;
bus-range = <0 0>;
ranges = <02000000 0 a0000000 90000000 0 10000000
42000000 0 80000000 80000000 0 10000000
01000000 0 00000000 d0000000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
compatible = "83xx";
device_type = "pci";
};
*/
// IPIC
pic@700 {
linux,phandle = <700>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
built-in;
device_type = "ipic";
};
par_io@1400 {
reg = <1400 100>;
device_type = "par_io";
num-ports = <4>;
ucc_pin@02 {
linux,phandle = <140001>;
pio-map = <
// port pin dir open_drain assignment has_irq
3 4 3 0 2 0 // MDIO
3 5 1 0 2 0 // MDC
0 12 1 0 1 0 // TxD0, 18
0 13 1 0 1 0 // TxD1, 19
0 14 1 0 1 0 // TxD2, 20
0 15 1 0 1 0 // TxD3, 21
0 1b 1 0 1 0 // TxER, 27
0 1e 1 0 1 0 // TxEN, 30
3 16 2 0 1 0 // TxCLK->CLK4, 22
0 16 2 0 1 0 // RxD0, 22
0 17 2 0 1 0 // RxD1, 23
0 18 2 0 1 0 // RxD2, 24
0 19 2 0 1 0 // RxD3, 25
0 1a 2 0 1 0 // RxER, 26
0 1c 2 0 1 0 // RxDV, 28
3 17 2 0 1 0 // RxCLK->CLK3, 23
0 1d 2 0 1 0 // COL, 29
0 1f 2 0 1 0 // CRS, 31
>;
};
ucc_pin@03 {
linux,phandle = <140002>;
pio-map = <
1 0 1 0 1 0 // TxD0, 0
1 1 1 0 1 0 // TxD1, 1
1 2 1 0 1 0 // TxD2, 2
1 3 1 0 1 0 // TxD3, 3
1 9 1 0 1 0 // TxER, 9
1 c 1 0 1 0 // TxEN, 12
3 18 2 0 1 0 // TxCLK->CLK10, 24
1 4 2 0 1 0 // RxD0, 4
1 5 2 0 1 0 // RxD1, 5
1 6 2 0 1 0 // RxD2, 6
1 7 2 0 1 0 // RxD3, 7
1 8 2 0 1 0 // RxER, 8
1 a 2 0 1 0 // RxDV, 10
0 d 2 0 1 0 // RxCLK->CLK9, 13
1 b 2 0 1 0 // COL, 11
1 d 2 0 1 0 // CRS, 13
>; // MDC
};
ucc_pin@04 {
linux,phandle = <140003>;
pio-map = <
1 12 1 0 1 0 // TxD0, 18
1 13 1 0 1 0 // TxD1, 19
1 14 1 0 1 0 // TxD2, 20
1 15 1 0 1 0 // TxD3, 21
1 1b 1 0 1 0 // TxER, 27
1 1e 1 0 1 0 // TxEN, 30
3 6 2 0 1 0 // TxCLK->CLK8, 6
1 16 2 0 1 0 // RxD0, 22
1 17 2 0 1 0 // RxD1, 23
1 18 2 0 1 0 // RxD2, 24
1 19 2 0 1 0 // RxD3, 25
1 1a 2 0 1 0 // RxER, 26
1 1c 2 0 1 0 // RxDV, 28
3 1f 2 0 1 0 // RxCLK->CLK7, 31
1 1d 2 0 1 0 // COL, 29
1 1f 2 0 1 0 // CRS, 31
>; // MDC
};
};
};
// QE
qe@e0100000 {
#address-cells = <1>;
#size-cells = <1>;
//#interrupt-cells = <2>;
device_type = "qe";
model = "QE";
ranges = <0 e0100000 00100000>;
reg = <e0100000 480>;
brg-frequency = <0>; // set by boot
bus-frequency = <0>; // set by boot
muram@10000 {
device_type = "muram";
ranges = <0 00010000 00004000>;
data-only@0{
reg = <0 4000>;
};
};
spi@4c0 {
device_type = "spi";
compatible = "fsl_spi";
reg = <4c0 40>;
interrupts = <2>;
interrupt-parent = <80>;
mode = "cpu";
};
/*
spi@500 {
device_type = "spi";
compatible = "fsl_spi";
reg = <500 40>;
//interrupts = <81 0>;
interrupts = <1>;
interrupt-parent = <80>;
mode = "cpu";
};
*/
brg@640 {
device_type = "brg";
reg = <668 4>;
};
usb@6c0 {
device_type = "usb";
compatible = "qe_udc";
reg = <6c0 40 8B00 100>;
//reg_pram = <8B00 100>;
interrupts = <b>;
interrupt-parent = <80>;
mode = "slave";
};
ucc@3000 { //UCC2
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <2>;
reg = <3000 200>;
interrupts = <21>;
interrupt-parent = <80>;
mac-address = [ 00 04 9f 00 23 23 ];
rx-clock = <13>; //CLK3 19
tx-clock = <14>; //CLK4 20
phy-handle = <&phy1>;
phy-connection-type = "mii";
max-speed = <64>; // 100
pio-handle = <140001>;
};
ucc@2200 { //UCC3
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <3>;
reg = <2200 200>;
interrupts = <22>;
interrupt-parent = <80>;
mac-address = [ 00 11 22 33 44 55 ];
rx-clock = <19>; //CLK9, 25
tx-clock = <1a>; //CLK10, 26
phy-handle = <&phy2>;
phy-connection-type = "mii";
max-speed = <64>; // d#100
pio-handle = <140002>;
};
ucc@3200 { //UCC4
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <4>;
reg = <3200 200>;
interrupts = <23>;
interrupt-parent = <80>;
mac-address = [ 00 11 22 33 44 99 ];
rx-clock = <17>; //CLK7, 23
tx-clock = <18>; //CLK8, 24
phy-handle = <212002>;
phy-connection-type = "mii";
max-speed = <d#100>; //d#100
pio-handle = <140003>;
};
mdio@2320 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2320 18>;
device_type = "mdio";
compatible = "ucc_geth_phy";
phy1: ethernet-phy@18 {
linux,phandle = <212000>;
reg = <18>; // 24
device_type = "ethernet-phy";
interface = <3>; //ENET_100_MII
};
phy2: fixed-phy@64 {
linux,phandle = <212001>;
reg = <d#100>;
device_type = "ethernet-phy";
};
phy3: ethernet-phy@19 {
linux,phandle = <212002>;
interrupt-parent = <700>;
interrupts = <12 2>;
reg = <19>; // 25
device_type = "ethernet-phy";
interface = <3>; //ENET_100_MII
};
};
qeic@80 {
linux,phandle = <80>;
interrupt-controller;
device_type = "qeic";
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <80 80>;
built-in;
big-endian;
interrupts = <20 8 21 8>; //high:32 low:33
interrupt-parent = <700>;
};
};
};
^ permalink raw reply
* Re: [Cbe-oss-dev] [RFC] cell: saving spus information for kexec crash
From: Benjamin Herrenschmidt @ 2007-05-13 22:14 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Andre Detsch, cbe-oss-dev, linuxppc-dev
In-Reply-To: <20070511172233.GA14587@kryten>
On Fri, 2007-05-11 at 12:22 -0500, Anton Blanchard wrote:
> Hi,
>
> > This patch adds support for investigating spus information after a
> > kernel crash event, through kdump vmcore file.
> > Implementation is based on xmon code, but the new functionality was
> > kept independent.
>
> This brings up a point: it looks like kdump doesnt capture the FP and
> altivec regs. Could be important for some bugs.
>
> This brings up yet another point, it looks like our userspace core dumps
> dont capture altivec or SPU state.
That's interesting: We do have a dump_task_altivec() but it looks like
its never called ... ouch. Maybe we can use the XFPREGS stuff or should
we add our own hook in binfmt_elf.c for that ?
As for SPU state, there's code to dump the SPEs in a separate section,
though I don't know if it's been merged yet (no up to date git tree
at hand right now). It uses different macros off binfmt_elf.
Ben.
^ permalink raw reply
* Re: [PATCH] pcmcia: ppc64 needs 64-bit ioaddr_t
From: Christoph Hellwig @ 2007-05-13 21:46 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, linux-pcmcia, paulus, linux-kernel
In-Reply-To: <20070512143105.GA12890@lixom.net>
On Sat, May 12, 2007 at 09:31:05AM -0500, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 64-bit, since I/O addresses really
> are MMIO addresses, and remapped to a high range.
>
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.
In fact the only use of the type should be in the obsolete ioctl-based user
interface. So instead of changing the size of the type you should
a) make sure you're not using cardmgr
b) fix up those places that still use ioaddr_t where they shouldn't
and switch the to kio_addr_t (why not just unsigned long like all
other busses?)
^ permalink raw reply
* Re: [PATCH] pcmcia: ppc64 needs 64-bit ioaddr_t
From: Olof Johansson @ 2007-05-13 21:22 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <20070512143105.GA12890@lixom.net>
On Sat, May 12, 2007 at 09:31:05AM -0500, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 64-bit, since I/O addresses really
> are MMIO addresses, and remapped to a high range.
>
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.
Hold off on this one, with the current discussions going on it seems likely
that we'll be fine with 32 bits, just like arm/mips.
I'll repost within a day or two if needed.
-Olof
^ permalink raw reply
* Re: [PATCH] pasemi: electra IDE/pata_platform glue
From: Olof Johansson @ 2007-05-13 21:18 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, Alan Cox, linux-ide
In-Reply-To: <200705130248.22844.arnd@arndb.de>
Hi,
On Sun, May 13, 2007 at 02:48:22AM +0200, Arnd Bergmann wrote:
> Olof, have you looked at which of the two ->set_mode functions is more
> appropriate for electra? I would guess that you actually want to use
> the ata_generic one.
Actually, the pata_platform driver is _exactly_ what I want at this time,
since we can't do bus master dma and it assumes that. It's a perfect fit,
I see no reason to retool it.
Another reason for why I'm not that excited about doing a generic
of_platform driver is that it's likely that I'll do a new driver that
uses one of the simple dma engines on our SoC to get the data over PIO
(i.e still not bus master dma, but at least offloaded). That'd make the
resulting number of users of a pata_of driver 0 until the next one comes
around, with whatever that means with respect to bit-rot, etc.
That driver will, on the other hand, likely be an of_platform one. But
until then there's not much use in doing one.
-Olof
^ permalink raw reply
* Re: Fixed PHY and MPC832x based boards don't work
From: Vitaly Bordug @ 2007-05-13 20:36 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1179067171.20638.48.camel@gentoo-jocke.transmode.se>
On Sun, 13 May 2007 16:39:30 +0200
Joakim Tjernlund wrote:
> Trying to make the Fixed PHY work under my 832x based board on current
> linus tree without success. Earlier kernels with custom PHY code for
> ucc_geth work without any special tricks.
>
> If I enable the FIXED_MII_100_FDX option I get:
> ls bus/mdio_bus/devices/
> fixed@100:1@
>
> but ucc_geth wants its PHYs under
> ls -l bus/of_platform/devices/*phy*
> lrwxrwxrwx 1 root root 0 May 12 17:32
> bus/of_platform/devices/ethernet-p hy.1
> -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.1/
> lrwxrwxrwx 1 root root 0 May 12 17:32
> bus/of_platform/devices/ethernet-p hy.3
> -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.3/
> lrwxrwxrwx 1 root root 0 May 12 17:32
> bus/of_platform/devices/fixed-phy. 2
> -> ../../../devices/e0100000.qe/e0102320.mdio/fixed-phy.2/ These are
> 3 PHYs I just added in the DTS tree:
>
> mdio@2320 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <2320 18>;
> device_type = "mdio";
> compatible = "ucc_geth_phy";
>
> phy1: ethernet-phy@18 {
> linux,phandle = <212000>;
> reg = <18>; // 24
> device_type = "ethernet-phy";
> interface = <3>; //ENET_100_MII
> };
> phy2: fixed-phy@64 {
> linux,phandle = <212001>;
> reg = <d#100>;
> device_type = "ethernet-phy";
> };
> phy3: ethernet-phy@19 {
> linux,phandle = <212002>;
> interrupt-parent = <700>;
> interrupts = <12 2>;
> reg = <19>; // 25
> device_type = "ethernet-phy";
> interface = <3>; //ENET_100_MII
> };
> };
>
> How do I add a fixed PHY so that ucc_geth finds it?
>
well I guess ucc stuff follows gianfar trend in mdio bus specification for the phy.
So, it would look like %d:%d or something like that.
Can you please dump the whole dts here?
> Jocke
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* [PATCH] viopath: use completion
From: Christoph Hellwig @ 2007-05-13 15:50 UTC (permalink / raw)
To: boutcher, linuxppc-dev
Use a completion instead of abusing a semaphore for hypervisor event
completion in viopath.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/arch/powerpc/platforms/iseries/viopath.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/iseries/viopath.c 2007-05-10 10:53:13.000000000 +0200
+++ linux-2.6/arch/powerpc/platforms/iseries/viopath.c 2007-05-13 16:37:04.000000000 +0200
@@ -37,6 +37,7 @@
#include <linux/wait.h>
#include <linux/seq_file.h>
#include <linux/interrupt.h>
+#include <linux/completion.h>
#include <asm/system.h>
#include <asm/uaccess.h>
@@ -115,7 +116,7 @@ static int proc_viopath_show(struct seq_
u16 vlanMap;
dma_addr_t handle;
HvLpEvent_Rc hvrc;
- DECLARE_MUTEX_LOCKED(Semaphore);
+ DECLARE_COMPLETION(done);
struct device_node *node;
const char *sysid;
@@ -132,13 +133,13 @@ static int proc_viopath_show(struct seq_
HvLpEvent_AckInd_DoAck, HvLpEvent_AckType_ImmediateAck,
viopath_sourceinst(viopath_hostLp),
viopath_targetinst(viopath_hostLp),
- (u64)(unsigned long)&Semaphore, VIOVERSION << 16,
+ (u64)(unsigned long)&done, VIOVERSION << 16,
((u64)handle) << 32, HW_PAGE_SIZE, 0, 0);
if (hvrc != HvLpEvent_Rc_Good)
printk(VIOPATH_KERN_WARN "hv error on op %d\n", (int)hvrc);
- down(&Semaphore);
+ wait_for_completion(&done);
vlanMap = HvLpConfig_getVirtualLanIndexMap();
@@ -353,7 +354,7 @@ static void handleConfig(struct HvLpEven
return;
}
- up((struct semaphore *)event->xCorrelationToken);
+ complete((struct completion *)event->xCorrelationToken);
}
/*
^ permalink raw reply
* [Fwd: [alsa-devel] embedded sound architecture question]
From: Joachim Förster @ 2007-05-13 15:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I posted the following question/mail to the ALSA development mailing
list and somebody suggested posting it to the LKML, but I thought,
perhaps it is better to ask you, the Linux PPC embedded experts first,
since it is right about that topic.
It would be nice if somebody can say, if the described architecture
makes sense and will work or if it is a complete no-go.
-------- Forwarded Message --------
From: Joachim Förster <mls.JOFT@gmx.de>
To: alsa-devel@alsa-project.org
Subject: [alsa-devel] embedded sound architecture question
Date: Wed, 09 May 2007 22:47:34 +0200
Hi ALSA devs,
I'm going to write an ALSA driver for a not yet existing AC97
controller, which is going to be "written" (VHDL), too (at the same
time). Platform/Board is a Xilinx ML403 with Virtex-4 FPGA, PowerPC 405
architecture, OPB/OCP bus, AC97 Codec LM4550.
Before presenting my question, I have to say, that I'm a beginner with
ALSA/Linux driver development.
My question is: Does the architecture described below make sense/is
reasonable with ALSA and Linux?
The problem is, that there is no DMA controller and implementing an OPB
master device which would be able to do DMA itself is not an option at
this time.
So our thoughts were: Integrate the "DMA ring buffer" (which is usually
somewhere in main memory/RAM) into the AC97 controller. Make ALSA access
this HW buffer as if it was in main memory. This way, the device (AC97
controller) has "direct access" to its buffer "memory" - this could be
called "fake DMA".
The AC97 controller would have tell us where it is while playing and
firing interrupts after one period, so that we don't write to values
which are in the current period, instead update the area where of the
past played periods etc. ... The buffer should be a "ring buffer",
right?
Mapping this "IO memory" into kernel space should be possible with
io_remap_page_range(), right?
I would have to implement the mmap() callback in my driver, to setup the
given VMA (with the above function), right?
So, ALSA library/applications will be able to use MMAP mode, which is
what we want to achieve?
[We don't want copy()/silence(). An intermediate buffer with
ack()/tasklet/workqueue + FIFO in HW would be an alternative.]
[snip]
Thanks for reading & your time,
Joachim
^ permalink raw reply
* Re: [PATCH 11/13] powerpc: Add DTS file for the Motorola PrPMC2800 platform
From: Segher Boessenkool @ 2007-05-13 14:45 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4647098D.9050901@gmail.com>
>> Not bad at all -- it is trivial to decode _if_ you know
>> how it is encoded. You cannot tell by looking at the
>> property data only. What is [44 54 53 00] -- just some
>> bytes, or the integer 0x44545300, or the string "DTS"?
>> You cannot tell.
>
> OK. I was coming from the u-boot "fdt print" command. We do a pretty
> good job of guessing the print format (byte/word/long/string/strings),
> but this would fail the detection circuitry and be printed as a byte
> array [00, 00, 00, 05, 44, 54, ...] (the default format) because it
> takes a-priori knowledge to print it in the original input format.
> Not quite as pretty, but NBD.
Yes, every possible way of displaying property contents
is based on heuristics, some better than others -- taking
the property name (and perhaps some other context) into
account helps a lot. Also, hardly any property is not
an array of 32-bit ints or an array of strings.
Segher
^ permalink raw reply
* Fixed PHY and MPC832x based boards don't work
From: Joakim Tjernlund @ 2007-05-13 14:39 UTC (permalink / raw)
To: Kim Phillips, linuxppc-dev, Vitaly Wool
Trying to make the Fixed PHY work under my 832x based board on current
linus tree without success. Earlier kernels with custom PHY code for
ucc_geth work without any special tricks.
If I enable the FIXED_MII_100_FDX option I get:
ls bus/mdio_bus/devices/
fixed@100:1@
but ucc_geth wants its PHYs under
ls -l bus/of_platform/devices/*phy*
lrwxrwxrwx 1 root root 0 May 12 17:32 bus/of_platform/devices/ethernet-p
hy.1 -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.1/
lrwxrwxrwx 1 root root 0 May 12 17:32 bus/of_platform/devices/ethernet-p
hy.3 -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.3/
lrwxrwxrwx 1 root root 0 May 12 17:32 bus/of_platform/devices/fixed-phy.
2 -> ../../../devices/e0100000.qe/e0102320.mdio/fixed-phy.2/
These are 3 PHYs I just added in the DTS tree:
mdio@2320 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2320 18>;
device_type = "mdio";
compatible = "ucc_geth_phy";
phy1: ethernet-phy@18 {
linux,phandle = <212000>;
reg = <18>; // 24
device_type = "ethernet-phy";
interface = <3>; //ENET_100_MII
};
phy2: fixed-phy@64 {
linux,phandle = <212001>;
reg = <d#100>;
device_type = "ethernet-phy";
};
phy3: ethernet-phy@19 {
linux,phandle = <212002>;
interrupt-parent = <700>;
interrupts = <12 2>;
reg = <19>; // 25
device_type = "ethernet-phy";
interface = <3>; //ENET_100_MII
};
};
How do I add a fixed PHY so that ucc_geth finds it?
Jocke
^ permalink raw reply
* Re: [PATCH] pasemi: electra IDE/pata_platform glue
From: Alan Cox @ 2007-05-13 13:39 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, linuxppc-dev, paulus, linux-ide
In-Reply-To: <200705130248.22844.arnd@arndb.de>
> > Easier to use pata_platform I would think ? Just create the OF device and
> > bind it to pata_platform.
>
> Not sure I understand what you mean. pata_platform expects a platform_device,
> which cannot be cast from an of_device.
Other than the binding and wanting to use the standard ->set_mode they
appear to be identical so a copy of pata_platform ought to turn into a
pata_of very nicely.
> Olof, have you looked at which of the two ->set_mode functions is more
> appropriate for electra? I would guess that you actually want to use
> the ata_generic one.
You almost certainly simply don't want to provide one. I'm not sure the
pata_platform default one is right at all as it will assume the firmware
tuned everything. ata_generic does this purely because it is a "last
resort" driver for chips we can't tune/program at all.
Alan
^ permalink raw reply
* Re: [PATCH 11/13] powerpc: Add DTS file for the Motorola PrPMC2800 platform
From: Jerry Van Baren @ 2007-05-13 12:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <70c9e7f82599a85ba1ae974e11db1d8f@kernel.crashing.org>
Segher Boessenkool wrote:
>>>>> + partition-names = "FW Image A\0FW Config Data\0Kernel
>>>>> Image\0Filesystem\0FW Image B";
>>>> dtc now supports the syntax:
>>>> partition-names = "FW Image A", "FW Config Data", ...
>>>> for multi-string properties to make this sort of thing less ugly.
>>> Nice! Can you also concatenate different property
>>> encodings that way? Like,
>>> slot-names = <5>, "Slot A", "Slot C";
>>> or something like that?
>>> Segher
>>
>> Hi Segher,
>>
>> That doesn't make sense to me. It would be a bugger to understand the
>> value of "slot-names" since <5> is a number and the rest are strings.
>> How do you know it is a number? How do you know how big it is?
>
> You know that since it is how that particular property is
> defined: it is one integer (i.e., 32-bit big-endian),
> followed by a string (zero-terminated) for each set bit
> in the integer.
[snip]
> Not bad at all -- it is trivial to decode _if_ you know
> how it is encoded. You cannot tell by looking at the
> property data only. What is [44 54 53 00] -- just some
> bytes, or the integer 0x44545300, or the string "DTS"?
> You cannot tell.
OK. I was coming from the u-boot "fdt print" command. We do a pretty
good job of guessing the print format (byte/word/long/string/strings),
but this would fail the detection circuitry and be printed as a byte
array [00, 00, 00, 05, 44, 54, ...] (the default format) because it
takes a-priori knowledge to print it in the original input format. Not
quite as pretty, but NBD.
>> It seems to me that it would be much better as
>> slot-names = "5", "Slot A", "Slot C";
>> and do an atoi() conversion if you detect it is or expect it to be
>> numeric.
>
> Hey, I know! We could redefine OF to use XML instead!
> ;-)
Oooo Oooo Oooo. No wait, we're embedded, we march to the beat of a
different drummer. Nevermind. :-D
> Segher
Thanks,
gvb
^ permalink raw reply
* Re: [PATCH] pasemi: electra IDE/pata_platform glue
From: Segher Boessenkool @ 2007-05-13 11:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: Arnd Bergmann, linuxppc-dev, linux-ide, paulus, Alan Cox
In-Reply-To: <20070513061954.GA16623@lixom.net>
> Also, in this particular case, the bindings are not standardized, and
> there's a good chance that whatever new platform uses a similar device
> will need to do something slightly different.
Yeah, everyone else will do the sane thing, and describe
the two register ranges the IDE uses, not a much bigger
range full of register shadows like you have. It is one
thing for the hardware to do partial address decoding;
the device tree shouldn't normally expose this though.
But that's what you've got now, so you have your own
special OF device matching code, which is exactly as it
should be. No need to have "generic" ide OF matching
code until device trees containing such devices show
up :-)
Segher
^ permalink raw reply
* Re: [PATCH] pasemi: electra IDE/pata_platform glue
From: Benjamin Herrenschmidt @ 2007-05-13 8:01 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, Alan Cox, Arnd Bergmann, linux-ide
In-Reply-To: <20070513061954.GA16623@lixom.net>
> Great. That should fit perfectly with the glue I have now, it'll turn
> into the constructor instead.
>
> I honestly don't see what the benefit is of this recent obsession
> with creating of_platform devices for every new device that's not
> PCI, especially when there's an already well-fitting driver in the
> traditional platform model. It's not like the code to link the two is
> large and complex.
I agree.
> Also, in this particular case, the bindings are not standardized, and
> there's a good chance that whatever new platform uses a similar device
> will need to do something slightly different.
Yup.
Ben.
^ permalink raw reply
* Re: [PATCH 4/9] powerpc: BestComm core support for Freescale MPC5200
From: Sylvain Munaut @ 2007-05-13 7:17 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200705130224.46114.arnd@arndb.de>
>> However, you could totally implement a "DMA devices" that would just
>> use a simple "copy from there to there" task using this BestComm driver.
>> So other part of the kernel (like network) could use that interface to
>> use the dma engine ...
>>
>
> Can it also do the advanced operations like XOR on DMA that the
> Intel ioat has? That would be even more interesting, I guess.
>
Actually yes it can.
It just need someone motivated enough to write it ;)
>>>> +static int __init
>>>> +mpc52xx_bcom_init(void)
>>>> +{
>>>> + struct device_node *ofn_bcom, *ofn_sram;
>>>> + struct resource res_bcom;
>>>> +
>>>> + int rv;
>>>> +
>>>> + /* Find the bestcomm node. If none, fails 'silently' since
>>>> + * we may just be on another platform */
>>>> + ofn_bcom = of_find_compatible_node(
>>>> + NULL, "dma-controller", "mpc5200-bestcomm");
>>>> + if (!ofn_bcom)
>>>> + return -ENODEV;
>>>>
>>> I know, my usual rant is getting old, but why is this one not an
>>> of_platform_driver? It's not shared with arch/ppc or with arch/mips,
>>> and it's not needed before module_init() time.
>>>
>> It needs to be initialized before _any_ other driver that uses bestcomm.
>> When compiled as module that could be an of_platform_driver but when
>> built-in there is apparently no way to ensure it's going to be probed
>> first. (At least no clean way ... )
>>
>
> Initialization order is always a little tricky, but if you use a
> subsys_initcall, it should at least come before any regular driver
> like network or disk, and arch/ drivers come before any code in drivers/,
> so I don't see much of a problem here.
>
Mmm ... Silly of me but I didn't think of that.
I'll give it a shot.
(Actually before the transition to arch/powerpc, this was a
platform_driver ...
but there I could control the probe order with ppc_sys ).
>>> Why don't you use EXPORT_SYMBOL_GPL?
>>>
>> Why would I ? Is it mandatory now ?
>> I don't really have an objection to non-gpl modules to use the exported
>> functions ...
>>
>
> It's your choice, but there is a strong recommendation to use _GPL for
> all new interfaces nowadays. If you don't, people might suspect that
> you have a hidden agenda and actually plan to do non-gpl modules
> yourself.
>
Well if it's recommended ... And since Dale is in favor of it, so be it,
I don't have any hidden agenda ;)
Sylvain
^ permalink raw reply
* Re: [PATCH] pasemi: electra IDE/pata_platform glue
From: Olof Johansson @ 2007-05-13 6:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, paulus, Alan Cox, Arnd Bergmann, linux-ide
In-Reply-To: <1179022810.32247.54.camel@localhost.localdomain>
On Sun, May 13, 2007 at 12:20:10PM +1000, Benjamin Herrenschmidt wrote:
>
> Then, the plans I have in mind for the future of that stuff are around
> the idea of registering "constructors" based on bus matches and device
> matches respectively.
>
> The kernel will then walk the whole OF device-tree at boot, and will
> instanciate devices using those constructors, passing them the struct
> device of whatever was the parent.
>
> Thus we could easily have platforms registers constructors for specific
> devices that build a platform device off an OF node.
Great. That should fit perfectly with the glue I have now, it'll turn
into the constructor instead.
I honestly don't see what the benefit is of this recent obsession
with creating of_platform devices for every new device that's not
PCI, especially when there's an already well-fitting driver in the
traditional platform model. It's not like the code to link the two is
large and complex.
Also, in this particular case, the bindings are not standardized, and
there's a good chance that whatever new platform uses a similar device
will need to do something slightly different.
-Olof
^ permalink raw reply
* Re: Fix Kconfig undefined symbol 'IBM_NEW_EMAC_ZMII'
From: Tony Breeds @ 2007-05-13 3:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1178870202.32247.15.camel@localhost.localdomain>
On Fri, May 11, 2007 at 05:56:42PM +1000, Benjamin Herrenschmidt wrote:
> Can you comment it out instead ?
Sure.
Fix Kconfig undefined symbol 'IBM_NEW_EMAC_ZMII'
An allmodconfig on the current powerpc tree yields:
arch/powerpc/platforms/44x/Kconfig:41:warning: 'select' used by config symbol '440GP' refers to undefined symbol 'IBM_NEW_EMAC_ZMII'
Hide the select until the driver exists.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
CC: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/platforms/44x/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: working/arch/powerpc/platforms/44x/Kconfig
===================================================================
--- working.orig/arch/powerpc/platforms/44x/Kconfig
+++ working/arch/powerpc/platforms/44x/Kconfig
@@ -38,7 +38,8 @@ config 440EP
config 440GP
bool
- select IBM_NEW_EMAC_ZMII
+# Disabled until the new EMAC Driver is merged.
+# select IBM_NEW_EMAC_ZMII
config 440GX
bool
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH 4/9] powerpc: BestComm core support for Freescale MPC5200
From: Dale Farnsworth @ 2007-05-13 3:36 UTC (permalink / raw)
To: tnt; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <46465295.90309@246tNt.com>
Sylvain Munaut wrote:
> Arnd Bergmann wrote:
> > Why don't you use EXPORT_SYMBOL_GPL?
> Why would I ? Is it mandatory now ?
> I don't really have an objection to non-gpl modules to use the exported
> functions ...
> If Dale or Andrey have, they're free to post a patch to change to _GPL.
Hi Sylvain,
The general recommendation is to use EXPORT_SYMBOL_GPL unless there
is some overriding reason not to. I agree with that recommendation.
That's my preference for this code, but I'll defer to you Sylvain.
BTW, it's great to see this code being submitted.
-Dale Farnsworth
^ permalink raw reply
* Re: [PATCH] pasemi: electra IDE/pata_platform glue
From: Benjamin Herrenschmidt @ 2007-05-13 2:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, linuxppc-dev, paulus, Alan Cox, linux-ide
In-Reply-To: <200705130248.22844.arnd@arndb.de>
On Sun, 2007-05-13 at 02:48 +0200, Arnd Bergmann wrote:
> On Sunday 13 May 2007, Alan Cox wrote:
> > > Why not provide a proper pata_of.c driver based on ata_generic? That
> > > will help the next person that has a builtin ata controller and wants
> > > to get it running as an of_device.
> >
> > Easier to use pata_platform I would think ? Just create the OF device and
> > bind it to pata_platform.
>
> Not sure I understand what you mean. pata_platform expects a platform_device,
> which cannot be cast from an of_device.
Note that in the long run, we might have less problem with that sort of
thing.
First, every device now has an OF node optionally attached to it (since
I introduced dev_sysdata). This of_device doesn't really bring much more
than OF type/name/compatible properties based probing.
Then, the plans I have in mind for the future of that stuff are around
the idea of registering "constructors" based on bus matches and device
matches respectively.
The kernel will then walk the whole OF device-tree at boot, and will
instanciate devices using those constructors, passing them the struct
device of whatever was the parent.
Thus we could easily have platforms registers constructors for specific
devices that build a platform device off an OF node. We can have a
generic constructor that builds the PCI devices, etc... and we can have
bus constructors to generate of_device's for things where they are
useful, like plb4/5 on 4xx etc...
On top of that, I want to add some resource management to of_device and
maybe kill things like ebus, vio, etc... device if possible (that is if
the only difference to the base OF device can be resolved at
construction time).
Anyway, still only thoughts but that gives you an idea to where I'm
heading.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: make ioport_map() handle already mapped ranges
From: Benjamin Herrenschmidt @ 2007-05-13 1:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <200705130155.42414.arnd@arndb.de>
> There is a global io space range for all buses, which is maintained
> by the reserve_phb_iospace() call. You should get your I/O ports in there
> if you want them to just work. Note that while the reserve_phb_iospace()
> logic works in practice, it does have a few shortcomings that should
> eventually be resolved:
The solution is to use proper allocators for these.
As you pointed out on irc, it seems like the current __get_vm_area()
could match our needs. It might allow us to also get rid of imalloc.
I'll give that a go tomorrow.
Ben.
^ permalink raw reply
* Re: [PATCH 11/13] powerpc: Add DTS file for the Motorola PrPMC2800 platform
From: David Gibson @ 2007-05-13 1:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <c3bcf08004bf1d35292b8a5661e6a6e6@kernel.crashing.org>
On Sat, May 12, 2007 at 01:59:09PM +0200, Segher Boessenkool wrote:
> >> + partition-names = "FW Image A\0FW Config Data\0Kernel
> >> Image\0Filesystem\0FW Image B";
> >
> > dtc now supports the syntax:
> > partition-names = "FW Image A", "FW Config Data", ...
> > for multi-string properties to make this sort of thing less ugly.
>
> Nice! Can you also concatenate different property
> encodings that way? Like,
>
> slot-names = <5>, "Slot A", "Slot C";
>
> or something like that?
Yes, you can.
--
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: [PATCH] pasemi: electra IDE/pata_platform glue
From: Arnd Bergmann @ 2007-05-13 0:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, linux-ide, paulus, Alan Cox
In-Reply-To: <20070513005830.38ba8e3b@the-village.bc.nu>
On Sunday 13 May 2007, Alan Cox wrote:
> > Why not provide a proper pata_of.c driver based on ata_generic? That
> > will help the next person that has a builtin ata controller and wants
> > to get it running as an of_device.
>
> Easier to use pata_platform I would think ? Just create the OF device and
> bind it to pata_platform.
Not sure I understand what you mean. pata_platform expects a platform_device,
which cannot be cast from an of_device.
Actually, it might be possible to merge the common parts of pata_platform,
ata_generic and ata_of into one module, and have one driver for each
of the three bus_types on top of it. Currently, the only difference between
ata_generic and pata_platform is the ->set_mode function, which can
probably be made generic (controlled by a flag in the ata_port).
Olof, have you looked at which of the two ->set_mode functions is more
appropriate for electra? I would guess that you actually want to use
the ata_generic one.
Arnd <><
^ 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