* Re: The question about the UART on UCC5,UCC6,UCC7,UCC8 for MPC8360?
From: Timur Tabi @ 2007-11-26 15:33 UTC (permalink / raw)
To: ??; +Cc: linuxppc-embedded
In-Reply-To: <396048835.09329@tsinghua.org.cn>
?? wrote:
> after compiled, I download the linux to MPC8360 board, but I cannot find the
> serial device for UCC5,UCC6,UCC7,UCC8. I just find the ttyS0,ttyS1 is OK.
> Could you tell me that what's the name for the serial device of UCC5,6,7,8?
> Whether or not I can use those UART just like the ttyS0,ttyS1?
I don't know why the BSP offers a UART driver for the 8360, because the driver
isn't available yet. I'm working on that, though. I'll post the driver in a
week or so, and it will be included in 2.6.25. You'll have to ask the BSP
support line if they plan on updating the BSP to include the new driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Sequoia EMAC only works if u-boot initializes it?
From: Steven A. Falco @ 2007-11-26 15:59 UTC (permalink / raw)
To: linuxppc-dev
I have noticed odd behavior on a Sequoia board. Kernel is built from
DENX git, ARCH=powerpc, 2.6.23.1.
Sequence that works:
1) In u-boot, do "dhcp" (this initializes the PHY)
2) Boot linux from flash
3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
Ethernet is now functional, and I can ping the Sequoia (and it can ping
my host)
Sequence that does not work:
1) Boot linux from flash without letting u-boot touch eth0
2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
Ethernet appears to come up, but it is not functional. I.e. I get
"eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
and the board cannot ping my host.
So, the kernel appears to be missing some initialization that u-boot
provides.
However, eth1 is more strange. U-boot can use it (via "setenv ethact
ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not
u-boot first initializes it.
If anyone has suggestions on where to look, I'd appreciate it. I'm
going to look at the PHY register settings and see if there are any
clues there...
Steve
^ permalink raw reply
* Re: [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 15:52 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <474886C2.7030609@scram.de>
Jochen Friedrich wrote:
> diff --git a/arch/powerpc/sysdev/commproc.c
> b/arch/powerpc/sysdev/commproc.c
> index f6a6378..2426bcb 100644
> --- a/arch/powerpc/sysdev/commproc.c
> +++ b/arch/powerpc/sysdev/commproc.c
> @@ -240,6 +240,34 @@ void __init cpm_reset(void)
> #endif
> }
>
> +static DEFINE_SPINLOCK(cmd_lock);
> +
> +#define MAX_CR_CMD_LOOPS 10000
> +
> +int cpm_command(u32 command, u8 opcode)
> +{
> + int i, ret;
> + unsigned long flags;
> +
> + if (command & 0xffffff0f)
> + return -EINVAL;
> +
> + spin_lock_irqsave(&cmd_lock, flags);
I'm a little uneasy about this -- what's the longest it can take for the
CPM command to complete (or timeout)? I'd rather use a mutex, if we can
make sure that it's never called from atomic context.
> +
> + ret = 0;
> + out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
> + for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> + if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
> + goto out;
> +
> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> __FUNCTION__);
> + ret = -EIO;
> +out:
> + spin_unlock_irqrestore(&cmd_lock, flags);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpm_command);
Can we please not play the GPL DRM game here?
Besides, Documentation/DocBook/kernel-hacking.tmpl explicitly says that
"It implies that the function is considered an internal implementation
issue, and not really an interface."
I don't think this is the case here.
-Scott
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-26 15:51 UTC (permalink / raw)
To: Grant Likely, Jon Smirl, PowerPC dev list, Timur Tabi
In-Reply-To: <20071120005941.GC3126@localhost.localdomain>
David Gibson wrote:
> 1) We have a "universal" device-tree-based fabric driver which
> parses all the above-described interconnection information in the
> device tree and handles any situation. Cool, but probably a lot of
> work and fiddly to get right.
Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC
v2 audio drivers in the kernel before we even consider this. And it may not
even be possible. I can easily imagine situations where we need board-specific
code that belongs in a machine-specific fabric driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2007-11-26 15:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4744D2AE.60902@freescale.com>
Timur Tabi wrote:
> David Gibson wrote:
>
>> Indeed, indexing or writing into shared registers is exactly what
>> cell-index is for.
>
> I don't care whether it's cell-index or device-id, but I need to know
> which DMA controller is #0 and which one is #1, and I need to know which
> channel is #0, which one is #1, etc.
OK, cell-index makes sense there too, then.
-Scott
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Luke Browning @ 2007-11-26 15:41 UTC (permalink / raw)
To: michael
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, Thomas Klein, linux-ppc, Christoph Raisch,
Paul Mackerras, Marcus Eder, Stefan Roscher
In-Reply-To: <1196064988.19855.15.camel@concordia>
On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote:
>
> Hi Thomas,
>
> I'm sorry, but this patch is all wrong IMHO.
>
> For kdump we have to assume that the kernel is fundamentally broken,
> we've panicked, so something bad has happened - every line of kernel
> code that is run decreases the chance that we'll successfully make it
> into the kdump kernel.
I agree with Michael.
> Solutions that might be better:
>
> a) if there are a finite number of handles and we can predict their
> values, just delete them all in the kdump kernel before the driver
> loads.
This is a good solution if handles are predefined.
> b) if there are a small & finite number of handles, save their values
> in a device tree property and have the kdump kernel read them and
> delete them before the driver loads.
Also good but is more complicated.
> c) if neither of those work, provide a minimal routine that _only_
> deletes the handles in the crashed kernel.
> d) <something else>
Can the driver or configuration method for the driver query PHYP to
determine if there are any pre-existing mappings...
Regards, Luke
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Kumar Gala @ 2007-11-26 15:41 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200711252322.09370.arnd@arndb.de>
On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote:
> On Wednesday 21 November 2007, Kumar Gala wrote:
>> + * Freescale 8xxx/3.0 Gb/s SATA nodes
>> +
>> + SATA nodes are defined to describe on-chip Serial ATA
>> controllers.
>> + Each SATA port should have its own node.
>> +
>> + Required properties:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,sata-CHIP", where CHIP is the processor
>> + (mpc8315, mpc8379, etc.) and the second is
>> + "fsl,sata-pq2pro"
>> + - interrupts : <interrupt mapping for SATA IRQ>
>> + - interrupt-parent : optional, if needed for interrupt mapping
>> + - reg : <registers mapping>
>> +
>
> Should this maybe also mandate a compatible property that is defined
> in a way to match the generic (p)ata_of_platform driver?
Is there something about the (p)ata_of_platform driver you think we
can use. The SATA controller here is a unique piece of HW and
requires a unique driver so I'm not sure what we get from
(p)ata_of_platform.
- k
^ permalink raw reply
* Re: Debugging with gdbserver slow
From: khollan @ 2007-11-26 15:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13865715.post@talk.nabble.com>
khollan wrote:
>
> Hi everyone,
>
> Im using gdbserver to debug Linux apps on my embedded board, but it takes
> like 3-6 sec to step one line of code. Its about the same to go from
> breakpoint to breakpont. Im using TCP to connect the host to the target.
> Is this typical or is there some setting wrong or was it built wrong. Its
> a PPC405 in a Xilinx FPGA.
>
> Thanks
>
> khollan
>
How long does it take everyone else to step through code serial or TCP?
--
View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13951808
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* initramfs and busybox kernel oops
From: fabien @ 2007-11-26 15:16 UTC (permalink / raw)
To: linuxppc-embedded
hi all,
I'm trying to get busybox working on my custom board mpc855t and linux
kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i
link directly in kernel. To verify whether the kernel is able to lauch
the init process i've compiled a small hello world program. But no
when i try with busybox 1.8.1 staticaly linked i got an Oops error
kernel access to bad area. I don't know why the former work fine but
no the latter.
If someone have some ideas for where to look for ?
In my initramfs there is :
in /dev :
crw-r--r-- 1 root root 5, 1 nov 22 13:32 console
crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null
crw------- 1 root root 4, 1 nov 26 10:11 tty1
in /bin :
lrwxrwxrwx 1 root root 7 nov 26 10:17 ash -> busybox*
-rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox*
lrwxrwxrwx 1 root root 7 nov 26 10:17 cat -> busybox*
(and others links)
My init script file (/init) :
#!/bin/sh
/bin/ash
...
Serial: CPM driver $Revision: 0.02 $
cpm_uart: WARNING: no UART devices found on platform bus!
cpm_uart: the driver will guess configuration, but this mode is no
longer supported.
ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
TCP cubic registered
Freeing unused kernel memory: 512k init
execute init process
Hello world test bonjour salut
...
...
ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
TCP cubic registered
Freeing unused kernel memory: 504k init
execute init process
Oops
...
(log_buf) when i try with busybox. log is little bit altered by the
fact i need plug/unplug the cable to reset
001ed154: 6720756e 75736564 206b6572 6e656c20 g unused kernel
001ed164: 6f656d6f 72793a21 3438386b 20696e69 oemory:!488k ini
001ed174: 740a3d37 3e43506f 20756172 745b305d t.=7>CPo uart[0]
001ed184: 3a737461 72747570 0a3c373e 4358cd20 :startup.<7>CX.
001ed194: 75617274 5b305d3a 7365745f 7465726d uart[0]:set_term
001ed1a4: 696f730a 3c343e65 78656375 7d652069 ios.<4>execu}e i
001ed1b4: 6e697420 70f26f63 6573730a 3c343e4f nit p.ocess.<4>O
001ed1c4: 7f70733a 206f6572 6e656c20 61636365 .ps: oernel acce
001ed1d4: 7373206f 66206261 64206172 65612c20 ss of bad area,
001ed1e4: 7379673a 20313121 5f23315d 0a3c343e syg: 11!_#1].<4>
001ed1f4: 4f6f7073 3a206b65 726e656c 24616373 Oops: kernel$acs
001ed204: 67737320 6f662072 61642061 f265612c gss of rad a.ea,
001ed214: 20736967 3a203131 205b2332 5d0a3c34 sig: 11 [#2].<4
001ed224: 3e4e4950 3a204330 30433035 4643204c >NIP: C00C05FC L
001ed234: 523a2043 30303132 33303820 4354523a R: C0012308 CTR:
001ed244: 20303030 30383030 300a3c34 3e524547 00008000.<4>REG
001ed254: 533a2063 30323339 62363020 5c525150 S: c0239b60 \RQP
001ed264: 3a203033 30302020 204e6f74 20746169 : 0300 Not tai
001ed274: 6e746564 20212832 2e362e33 392e3629 nted !(2.6.19.6)
001ed284: 0b3c343e 4d53523a 20f13030 303130b3 .<4>MSR: .00010.
001ed294: 32203c4d 452e4952 2c44523e 60204352 2 <ME.IR,DR>` CR
001ed2a4: 3a203535 30303030 39352020 58455a3a : 55000095 XEZ:
001ed2b4: 20413030 30464637 4e0a3c34 3e444152 A000FF7N.<4>DAR
001ed2c4: 3a213346 30303030 30302c22 44534953 :!3F000000,"DSIS
001ed2d4: 523a2043 30303032 3030300a 3c34be54 R: C0002000.<4.T
001ed2e4: 4153cb20 3d206330 32333762 37305b31 AS. = c0237b70[1
001ed2f4: 5d202769 6e697427 205448d2 4549443a ] 'init' TH.EID:
001ed304: a063b032 33383830 b00a3c36 3e475052 .c.23880..<6>GPR
001ed314: b0303a20 30303030 30343733 20433032 .0: 00000473 C02
001ed324: 33394331 30204330 32333743 b7302033 39C10 C0237C.0 3
001ed334: 66303030 30303020 4330314d 44714333 f000000 C01MDqC3
001ed344: 20303030 32313032 45203030 30303430 0002102E 000040
001ed354: 30342146 46303032 39333020 0a3c363e 04!FF002930 .<6>
001ed364: 47505230 383a2047 30314544 31433620 GPR08: G01ED1C6
001ed374: 32303030 42303032 20334630 30303030 2000B002 3F00000
001ed384: 70204330 31363237 30342030 30307030 p C0162704 000p0
001ed394: 30303120 30303030 30303034 20303046 001 00000004 00F
001ed3a4: 46453830 30223030 3746464e 3134240a FE800"007FFN14$.
001ed3b4: 3c363e47 50d231b6 3a203030 30303030 <6>GP.1.: 000000
001ed3c4: 30302030 30b13030 30303120 30303f46 00 00.00001 00?F
001ed3d4: 46463030 204b3031 36303030 30205330 FF00 K0160000 S0
...
thank a lot for help
fab
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Joakim Tjernlund @ 2007-11-26 15:04 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <20071126142915.19642.5842.stgit@localhost.localdomain>
On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> not connected to the real MDIO bus.
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> ---
>
> Documentation/powerpc/booting-without-of.txt | 3 +
> arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> 2 files changed, 42 insertions(+), 17 deletions(-)
>
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..cf25070 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> services interrupts for this device.
> - phy-handle : The phandle for the PHY connected to this ethernet
> controller.
> + - fixed-link : <a b c> where a is emulated phy id - choose any,
> + but unique to the all specified fixed-links, b is duplex - 0 half,
> + 1 full, c is link speed - d#10/d#100/d#1000.
Good work!
May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
flow control or not just popped up here today so I got a use for it.
Jocke
^ permalink raw reply
* [PATCH 3/3] [POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
From: Vitaly Bordug @ 2007-11-26 14:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20071126142906.19642.45540.stgit@localhost.localdomain>
...thus use fixed-link to register proper "Fixed PHY"
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5072f6d..e2d00f1 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -115,14 +115,6 @@
reg = <1c>;
device_type = "ethernet-phy";
};
-
- /* Vitesse 7385 */
- phy1f: ethernet-phy@1f {
- interrupt-parent = < &ipic >;
- interrupts = <12 8>;
- reg = <1f>;
- device_type = "ethernet-phy";
- };
};
ethernet@24000 {
@@ -159,7 +151,8 @@
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <23 8 24 8 25 8>;
interrupt-parent = < &ipic >;
- phy-handle = < &phy1f >;
+ /* Vitesse 7385 isn't on the MDIO bus */
+ fixed-link = <1 1 d#1000>;
linux,network-index = <1>;
};
^ permalink raw reply related
* [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Vitaly Bordug @ 2007-11-26 14:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20071126142906.19642.45540.stgit@localhost.localdomain>
fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
not connected to the real MDIO bus.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 3 +
arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
2 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..cf25070 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
services interrupts for this device.
- phy-handle : The phandle for the PHY connected to this ethernet
controller.
+ - fixed-link : <a b c> where a is emulated phy id - choose any,
+ but unique to the all specified fixed-links, b is duplex - 0 half,
+ 1 full, c is link speed - d#10/d#100/d#1000.
Recommended properties:
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..e06a5c9 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -24,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/of_platform.h>
#include <linux/phy.h>
+#include <linux/phy_fixed.h>
#include <linux/spi/spi.h>
#include <linux/fsl_devices.h>
#include <linux/fs_enet_pd.h>
@@ -193,7 +194,6 @@ static const char *gfar_tx_intr = "tx";
static const char *gfar_rx_intr = "rx";
static const char *gfar_err_intr = "error";
-
static int __init gfar_of_init(void)
{
struct device_node *np;
@@ -277,29 +277,51 @@ static int __init gfar_of_init(void)
gfar_data.interface = PHY_INTERFACE_MODE_MII;
ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
+ if (ph == NULL) {
+ struct fixed_phy_status status = {};
+ u32 *fixed_link;
- if (phy == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
+ fixed_link = (u32*)of_get_property(np, "fixed-link",NULL);
+ if (!fixed_link) {
+ ret = -ENODEV;
+ goto unreg;
+ }
- mdio = of_get_parent(phy);
+ status.link = 1;
+ status.duplex = fixed_link[1];
+ status.speed = fixed_link[2];
+
+ ret = fixed_phy_add(PHY_POLL, fixed_link[0], &status);
+ if (ret)
+ goto unreg;
+
+ gfar_data.bus_id = 0;
+ gfar_data.phy_id = fixed_link[0];
+ } else {
+ phy = of_find_node_by_phandle(*ph);
+
+ if (phy == NULL) {
+ ret = -ENODEV;
+ goto unreg;
+ }
+
+ mdio = of_get_parent(phy);
+
+ id = of_get_property(phy, "reg", NULL);
+ ret = of_address_to_resource(mdio, 0, &res);
+ if (ret) {
+ of_node_put(phy);
+ of_node_put(mdio);
+ goto unreg;
+ }
+
+ gfar_data.phy_id = *id;
+ gfar_data.bus_id = res.start;
- id = of_get_property(phy, "reg", NULL);
- ret = of_address_to_resource(mdio, 0, &res);
- if (ret) {
of_node_put(phy);
of_node_put(mdio);
- goto unreg;
}
- gfar_data.phy_id = *id;
- gfar_data.bus_id = res.start;
-
- of_node_put(phy);
- of_node_put(mdio);
-
ret =
platform_device_add_data(gfar_dev, &gfar_data,
sizeof(struct
^ permalink raw reply related
* [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
From: Vitaly Bordug @ 2007-11-26 14:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
With that patch fixed.c now fully emulates MDIO bus, thus no need
to duplicate PHY layer functionality. That, in turn, drastically
simplifies the code, and drops down line count.
As an additional bonus, now there is no need to register MDIO bus
for each PHY, all emulated PHYs placed on the platform fixed MDIO bus.
There is also no more need to pre-allocate PHYs via .config option,
this is all now handled dynamically.
p.s. Don't even try to understand patch content! Better: apply patch
and look into resulting drivers/net/phy/fixed.c.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/phy/Kconfig | 32 +--
drivers/net/phy/fixed.c | 427 ++++++++++++++++-----------------------------
include/linux/phy_fixed.h | 49 ++---
3 files changed, 176 insertions(+), 332 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 54b2ba9..a05c614 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -61,34 +61,12 @@ config ICPLUS_PHY
Currently supports the IP175C PHY.
config FIXED_PHY
- tristate "Drivers for PHY emulation on fixed speed/link"
+ tristate "Drivers for MDIO Bus/PHY emulation on fixed speed/link"
---help---
- Adds the driver to PHY layer to cover the boards that do not have any PHY bound,
- but with the ability to manipulate the speed/link in software. The relevant MII
- speed/duplex parameters could be effectively handled in a user-specified function.
- Currently tested with mpc866ads.
-
-config FIXED_MII_10_FDX
- bool "Emulation for 10M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_100_FDX
- bool "Emulation for 100M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_1000_FDX
- bool "Emulation for 1000M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_AMNT
- int "Number of emulated PHYs to allocate "
- depends on FIXED_PHY
- default "1"
- ---help---
- Sometimes it is required to have several independent emulated
- PHYs on the bus (in case of multi-eth but phy-less HW for instance).
- This control will have specified number allocated for each fixed
- PHY type enabled.
+ Adds the platform "fixed" MDIO Bus to cover the boards that use
+ PHYs that are not connected to the real MDIO bus.
+
+ Currently tested with mpc866ads and mpc8349e-mitx.
config MDIO_BITBANG
tristate "Support for bitbanged MDIO buses"
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 5619182..31719b3 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -1,362 +1,237 @@
/*
- * drivers/net/phy/fixed.c
+ * Fixed MDIO bus (MDIO bus emulation with fixed PHYs)
*
- * Driver for fixed PHYs, when transceiver is able to operate in one fixed mode.
+ * Author: Vitaly Bordug <vbordug@ru.mvista.com>
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
*
- * Author: Vitaly Bordug
- *
- * Copyright (c) 2006 MontaVista Software, Inc.
+ * Copyright (c) 2006-2007 MontaVista Software, Inc.
*
* 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.
- *
*/
+
#include <linux/kernel.h>
-#include <linux/string.h>
-#include <linux/errno.h>
-#include <linux/unistd.h>
-#include <linux/slab.h>
-#include <linux/interrupt.h>
-#include <linux/init.h>
-#include <linux/delay.h>
-#include <linux/netdevice.h>
-#include <linux/etherdevice.h>
-#include <linux/skbuff.h>
-#include <linux/spinlock.h>
-#include <linux/mm.h>
#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/list.h>
#include <linux/mii.h>
-#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
-#include <asm/io.h>
-#include <asm/irq.h>
-#include <asm/uaccess.h>
-
-/* we need to track the allocated pointers in order to free them on exit */
-static struct fixed_info *fixed_phy_ptrs[CONFIG_FIXED_MII_AMNT*MAX_PHY_AMNT];
-
-/*-----------------------------------------------------------------------------
- * If something weird is required to be done with link/speed,
- * network driver is able to assign a function to implement this.
- * May be useful for PHY's that need to be software-driven.
- *-----------------------------------------------------------------------------*/
-int fixed_mdio_set_link_update(struct phy_device *phydev,
- int (*link_update) (struct net_device *,
- struct fixed_phy_status *))
-{
- struct fixed_info *fixed;
-
- if (link_update == NULL)
- return -EINVAL;
-
- if (phydev) {
- if (phydev->bus) {
- fixed = phydev->bus->priv;
- fixed->link_update = link_update;
- return 0;
- }
- }
- return -EINVAL;
-}
+#define MII_REGS_NUM 29
-EXPORT_SYMBOL(fixed_mdio_set_link_update);
+struct fixed_mdio_bus {
+ int irqs[PHY_MAX_ADDR];
+ struct mii_bus mii_bus;
+ struct list_head phys;
+};
-struct fixed_info *fixed_mdio_get_phydev (int phydev_ind)
-{
- if (phydev_ind >= MAX_PHY_AMNT)
- return NULL;
- return fixed_phy_ptrs[phydev_ind];
-}
+struct fixed_phy {
+ int id;
+ u16 regs[MII_REGS_NUM];
+ struct phy_device *phydev;
+ struct fixed_phy_status status;
+ int (*link_update)(struct net_device *, struct fixed_phy_status *);
+ struct list_head node;
+};
-EXPORT_SYMBOL(fixed_mdio_get_phydev);
+static struct platform_device *pdev;
+static struct fixed_mdio_bus platform_fmb = {
+ .phys = LIST_HEAD_INIT(platform_fmb.phys),
+};
-/*-----------------------------------------------------------------------------
- * This is used for updating internal mii regs from the status
- *-----------------------------------------------------------------------------*/
-#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX) || defined(CONFIG_FIXED_MII_1000_FDX)
-static int fixed_mdio_update_regs(struct fixed_info *fixed)
+static int fixed_phy_update_regs(struct fixed_phy *fp)
{
- u16 *regs = fixed->regs;
u16 bmsr = 0;
u16 bmcr = 0;
- if (!regs) {
- printk(KERN_ERR "%s: regs not set up", __FUNCTION__);
- return -EINVAL;
- }
-
- if (fixed->phy_status.link)
- bmsr |= BMSR_LSTATUS;
-
- if (fixed->phy_status.duplex) {
+ if (fp->status.duplex) {
bmcr |= BMCR_FULLDPLX;
- switch (fixed->phy_status.speed) {
+ switch (fp->status.speed) {
+ case 1000:
+ bmsr |= BMSR_ESTATEN;
+ bmcr |= BMCR_SPEED1000;
+ break;
case 100:
bmsr |= BMSR_100FULL;
bmcr |= BMCR_SPEED100;
break;
-
case 10:
bmsr |= BMSR_10FULL;
break;
+ default:
+ printk(KERN_WARNING "fixed phy: unknown speed\n");
+ return -EINVAL;
}
} else {
- switch (fixed->phy_status.speed) {
+ switch (fp->status.speed) {
+ case 1000:
+ bmsr |= BMSR_ESTATEN;
+ bmcr |= BMCR_SPEED1000;
+ break;
case 100:
bmsr |= BMSR_100HALF;
bmcr |= BMCR_SPEED100;
break;
-
case 10:
- bmsr |= BMSR_100HALF;
+ bmsr |= BMSR_10HALF;
break;
+ default:
+ printk(KERN_WARNING "fixed phy: unknown speed\n");
+ return -EINVAL;
}
}
- regs[MII_BMCR] = bmcr;
- regs[MII_BMSR] = bmsr | 0x800; /*we are always capable of 10 hdx */
+ if (fp->status.link)
+ bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
+
+ fp->regs[MII_PHYSID1] = fp->id >> 16;
+ fp->regs[MII_PHYSID2] = fp->id;
+
+ fp->regs[MII_BMSR] = bmsr;
+ fp->regs[MII_BMCR] = bmcr;
return 0;
}
-static int fixed_mii_read(struct mii_bus *bus, int phy_id, int location)
+static int fixed_mdio_read(struct mii_bus *bus, int phy_id, int reg_num)
{
- struct fixed_info *fixed = bus->priv;
-
- /* if user has registered link update callback, use it */
- if (fixed->phydev)
- if (fixed->phydev->attached_dev) {
- if (fixed->link_update) {
- fixed->link_update(fixed->phydev->attached_dev,
- &fixed->phy_status);
- fixed_mdio_update_regs(fixed);
+ struct fixed_mdio_bus *fmb = container_of(bus, struct fixed_mdio_bus,
+ mii_bus);
+ struct fixed_phy *fp;
+
+ if (reg_num >= MII_REGS_NUM)
+ return -1;
+
+ list_for_each_entry(fp, &fmb->phys, node) {
+ if (fp->id == phy_id) {
+ /* Issue callback if user registered it. */
+ if (fp->link_update) {
+ fp->link_update(fp->phydev->attached_dev,
+ &fp->status);
+ fixed_phy_update_regs(fp);
}
+ return fp->regs[reg_num];
}
+ }
- if ((unsigned int)location >= fixed->regs_num)
- return -1;
- return fixed->regs[location];
+ return 0xFFFF;
}
-static int fixed_mii_write(struct mii_bus *bus, int phy_id, int location,
- u16 val)
+static int fixed_mdio_write(struct mii_bus *bus, int phy_id, int reg_num,
+ u16 val)
{
- /* do nothing for now */
return 0;
}
-static int fixed_mii_reset(struct mii_bus *bus)
+/*
+ * If something weird is required to be done with link/speed,
+ * network driver is able to assign a function to implement this.
+ * May be useful for PHY's that need to be software-driven.
+ */
+int fixed_phy_set_link_update(struct phy_device *phydev,
+ int (*link_update)(struct net_device *,
+ struct fixed_phy_status *))
{
- /*nothing here - no way/need to reset it */
- return 0;
-}
-#endif
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct fixed_phy *fp;
-static int fixed_config_aneg(struct phy_device *phydev)
-{
- /* :TODO:03/13/2006 09:45:37 PM::
- The full autoneg funcionality can be emulated,
- but no need to have anything here for now
- */
- return 0;
-}
+ if (!link_update || !phydev || !phydev->bus)
+ return -EINVAL;
-/*-----------------------------------------------------------------------------
- * the manual bind will do the magic - with phy_id_mask == 0
- * match will never return true...
- *-----------------------------------------------------------------------------*/
-static struct phy_driver fixed_mdio_driver = {
- .name = "Fixed PHY",
-#ifdef CONFIG_FIXED_MII_1000_FDX
- .features = PHY_GBIT_FEATURES,
-#else
- .features = PHY_BASIC_FEATURES,
-#endif
- .config_aneg = fixed_config_aneg,
- .read_status = genphy_read_status,
- .driver = { .owner = THIS_MODULE, },
-};
+ list_for_each_entry(fp, &fmb->phys, node) {
+ if (fp->id == phydev->phy_id) {
+ fp->link_update = link_update;
+ fp->phydev = phydev;
+ return 0;
+ }
+ }
-static void fixed_mdio_release(struct device *dev)
-{
- struct phy_device *phydev = container_of(dev, struct phy_device, dev);
- struct mii_bus *bus = phydev->bus;
- struct fixed_info *fixed = bus->priv;
-
- kfree(phydev);
- kfree(bus->dev);
- kfree(bus);
- kfree(fixed->regs);
- kfree(fixed);
+ return -ENOENT;
}
+EXPORT_SYMBOL_GPL(fixed_phy_set_link_update);
-/*-----------------------------------------------------------------------------
- * This func is used to create all the necessary stuff, bind
- * the fixed phy driver and register all it on the mdio_bus_type.
- * speed is either 10 or 100 or 1000, duplex is boolean.
- * number is used to create multiple fixed PHYs, so that several devices can
- * utilize them simultaneously.
- *
- * The device on mdio bus will look like [bus_id]:[phy_id],
- * bus_id = number
- * phy_id = speed+duplex.
- *-----------------------------------------------------------------------------*/
-#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX) || defined(CONFIG_FIXED_MII_1000_FDX)
-struct fixed_info *fixed_mdio_register_device(
- int bus_id, int speed, int duplex, u8 phy_id)
+int fixed_phy_add(unsigned int irq, int phy_id,
+ struct fixed_phy_status *status)
{
- struct mii_bus *new_bus;
- struct fixed_info *fixed;
- struct phy_device *phydev;
- int err;
+ int ret;
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct fixed_phy *fp;
- struct device *dev = kzalloc(sizeof(struct device), GFP_KERNEL);
+ fp = kzalloc(sizeof(*fp), GFP_KERNEL);
+ if (!fp)
+ return -ENOMEM;
- if (dev == NULL)
- goto err_dev_alloc;
+ memset(fp->regs, 0xFF, sizeof(fp->regs[0]) * MII_REGS_NUM);
- new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
+ fmb->irqs[phy_id] = irq;
- if (new_bus == NULL)
- goto err_bus_alloc;
+ fp->id = phy_id;
+ fp->status = *status;
- fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
+ ret = fixed_phy_update_regs(fp);
+ if (ret)
+ goto err_regs;
- if (fixed == NULL)
- goto err_fixed_alloc;
+ list_add_tail(&fp->node, &fmb->phys);
- fixed->regs = kzalloc(MII_REGS_NUM * sizeof(int), GFP_KERNEL);
- if (NULL == fixed->regs)
- goto err_fixed_regs_alloc;
+ return 0;
- fixed->regs_num = MII_REGS_NUM;
- fixed->phy_status.speed = speed;
- fixed->phy_status.duplex = duplex;
- fixed->phy_status.link = 1;
+err_regs:
+ kfree(fp);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(fixed_phy_add);
- new_bus->name = "Fixed MII Bus";
- new_bus->read = &fixed_mii_read;
- new_bus->write = &fixed_mii_write;
- new_bus->reset = &fixed_mii_reset;
- /*set up workspace */
- fixed_mdio_update_regs(fixed);
- new_bus->priv = fixed;
+static int __init fixed_mdio_bus_init(void)
+{
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ int ret;
- new_bus->dev = dev;
- dev_set_drvdata(dev, new_bus);
+ pdev = platform_device_register_simple("Fixed MDIO bus", 0, NULL, 0);
+ if (!pdev) {
+ ret = -ENOMEM;
+ goto err_pdev;
+ }
- /* create phy_device and register it on the mdio bus */
- phydev = phy_device_create(new_bus, 0, 0);
- if (phydev == NULL)
- goto err_phy_dev_create;
+ fmb->mii_bus.id = 0;
+ fmb->mii_bus.name = "Fixed MDIO Bus";
+ fmb->mii_bus.dev = &pdev->dev;
+ fmb->mii_bus.read = &fixed_mdio_read;
+ fmb->mii_bus.write = &fixed_mdio_write;
+ fmb->mii_bus.irq = fmb->irqs;
- /*
- * Put the phydev pointer into the fixed pack so that bus read/write
- * code could be able to access for instance attached netdev. Well it
- * doesn't have to do so, only in case of utilizing user-specified
- * link-update...
- */
+ ret = mdiobus_register(&fmb->mii_bus);
+ if (ret)
+ goto err_mdiobus_reg;
- fixed->phydev = phydev;
- phydev->speed = speed;
- phydev->duplex = duplex;
+ return 0;
- phydev->irq = PHY_IGNORE_INTERRUPT;
- phydev->dev.bus = &mdio_bus_type;
+err_mdiobus_reg:
+ platform_device_unregister(pdev);
+err_pdev:
+ return ret;
+}
+module_init(fixed_mdio_bus_init);
- snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
- PHY_ID_FMT, bus_id, phy_id);
+static void __exit fixed_mdio_bus_exit(void)
+{
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct fixed_phy *fp;
- phydev->bus = new_bus;
+ mdiobus_unregister(&fmb->mii_bus);
+ platform_device_unregister(pdev);
- phydev->dev.driver = &fixed_mdio_driver.driver;
- phydev->dev.release = fixed_mdio_release;
- err = phydev->dev.driver->probe(&phydev->dev);
- if (err < 0) {
- printk(KERN_ERR "Phy %s: problems with fixed driver\n",
- phydev->dev.bus_id);
- goto err_out;
- }
- err = device_register(&phydev->dev);
- if (err) {
- printk(KERN_ERR "Phy %s failed to register\n",
- phydev->dev.bus_id);
- goto err_out;
+ list_for_each_entry(fp, &fmb->phys, node) {
+ list_del(&fp->node);
+ kfree(fp);
}
- //phydev->state = PHY_RUNNING; /* make phy go up quick, but in 10Mbit/HDX
- return fixed;
-
-err_out:
- kfree(phydev);
-err_phy_dev_create:
- kfree(fixed->regs);
-err_fixed_regs_alloc:
- kfree(fixed);
-err_fixed_alloc:
- kfree(new_bus);
-err_bus_alloc:
- kfree(dev);
-err_dev_alloc:
-
- return NULL;
-
}
-#endif
+module_exit(fixed_mdio_bus_exit);
-MODULE_DESCRIPTION("Fixed PHY device & driver for PAL");
+MODULE_DESCRIPTION("Fixed MDIO bus (MDIO bus emulation with fixed PHYs)");
MODULE_AUTHOR("Vitaly Bordug");
MODULE_LICENSE("GPL");
-
-static int __init fixed_init(void)
-{
- int cnt = 0;
- int i;
-/* register on the bus... Not expected to be matched
- * with anything there...
- *
- */
- phy_driver_register(&fixed_mdio_driver);
-
-/* We will create several mdio devices here, and will bound the upper
- * driver to them.
- *
- * Then the external software can lookup the phy bus by searching
- * for 0:101, to be connected to the virtual 100M Fdx phy.
- *
- * In case several virtual PHYs required, the bus_id will be in form
- * [num]:[duplex]+[speed], which make it able even to define
- * driver-specific link control callback, if for instance PHY is
- * completely SW-driven.
- */
- for (i=1; i <= CONFIG_FIXED_MII_AMNT; i++) {
-#ifdef CONFIG_FIXED_MII_1000_FDX
- fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(0, 1000, 1, i);
-#endif
-#ifdef CONFIG_FIXED_MII_100_FDX
- fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(1, 100, 1, i);
-#endif
-#ifdef CONFIG_FIXED_MII_10_FDX
- fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(2, 10, 1, i);
-#endif
- }
-
- return 0;
-}
-
-static void __exit fixed_exit(void)
-{
- int i;
-
- phy_driver_unregister(&fixed_mdio_driver);
- for (i=0; i < MAX_PHY_AMNT; i++)
- if ( fixed_phy_ptrs[i] )
- device_unregister(&fixed_phy_ptrs[i]->phydev->dev);
-}
-
-module_init(fixed_init);
-module_exit(fixed_exit);
diff --git a/include/linux/phy_fixed.h b/include/linux/phy_fixed.h
index 04ba70d..01669d1 100644
--- a/include/linux/phy_fixed.h
+++ b/include/linux/phy_fixed.h
@@ -1,38 +1,29 @@
#ifndef __PHY_FIXED_H
#define __PHY_FIXED_H
-#define MII_REGS_NUM 29
-
-/* max number of virtual phy stuff */
-#define MAX_PHY_AMNT 10
-/*
- The idea is to emulate normal phy behavior by responding with
- pre-defined values to mii BMCR read, so that read_status hook could
- take all the needed info.
-*/
-
struct fixed_phy_status {
- u8 link;
- u16 speed;
- u8 duplex;
+ int link;
+ int speed;
+ int duplex;
};
-/*-----------------------------------------------------------------------------
- * Private information hoder for mii_bus
- *-----------------------------------------------------------------------------*/
-struct fixed_info {
- u16 *regs;
- u8 regs_num;
- struct fixed_phy_status phy_status;
- struct phy_device *phydev; /* pointer to the container */
- /* link & speed cb */
- int (*link_update) (struct net_device *, struct fixed_phy_status *);
+#ifdef CONFIG_FIXED_PHY
+extern int fixed_phy_add(unsigned int irq, int phy_id,
+ struct fixed_phy_status *status);
+#else
+static inline int fixed_phy_add(unsigned int irq, int phy_id,
+ struct fixed_phy_status *status)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_FIXED_PHY */
-};
-
-
-int fixed_mdio_set_link_update(struct phy_device *,
- int (*link_update) (struct net_device *, struct fixed_phy_status *));
-struct fixed_info *fixed_mdio_get_phydev (int phydev_ind);
+/*
+ * This function issued only by fixed_phy-aware drivers, no need
+ * protect it with #ifdef
+ */
+extern int fixed_phy_set_link_update(struct phy_device *phydev,
+ int (*link_update)(struct net_device *,
+ struct fixed_phy_status *));
#endif /* __PHY_FIXED_H */
^ permalink raw reply related
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Jochen Friedrich @ 2007-11-26 11:15 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071125191833.1e76f335@kernel.crashing.org>
Hi Vitaly,
>> Maybe this is a stupid question, but why did you choose
>> EXPORT_SYMBOL_GPL and not EXPORT_SYMBOL?
>>
> To prevent using those pointers from within non-GPL modules. kind of policy now...
In particular in this case, as these pointers are currently not exported, at all. They
are currently used by a few drivers and will disappear again once these drivers have
been converted to use the propper accessors, which will also prevent access conflicts
to the CPM registers.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Christoph Raisch @ 2007-11-26 10:45 UTC (permalink / raw)
To: michael
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Paul Mackerras, Marcus Eder, tklein,
Stefan Roscher
In-Reply-To: <1196064988.19855.15.camel@concordia>
Michael Ellerman wrote on 26.11.2007 09:16:28:
> Solutions that might be better:
>
> a) if there are a finite number of handles and we can predict their
> values, just delete them all in the kdump kernel before the driver
> loads.
Guessing the values does not work, because of the handle structure
defined by the hypervisor.
> b) if there are a small & finite number of handles, save their values
> in a device tree property and have the kdump kernel read them and
> delete them before the driver loads.
5*16*nr_ports+1+1= >82. a ML16 has 4 adapters with up to 16 ports, so the
number
is not small anymore....
The device tree functions are currently not exported.
If you crashdump to a new kernel, will it get the device tree
representation
of the crashed kernel or of the initial one of open firmware?
> c) if neither of those work, provide a minimal routine that _only_
> deletes the handles in the crashed kernel.
I would hope this has the highest chance to actually work.
For this we would have to add a proper notifier chain.
Do you agree?
> d) <something else>
Firmware change? But that's not something you will get very soon.
Christoph R.
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Vitaly Bordug @ 2007-11-26 10:28 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <19DACFA1-05DB-4331-BE71-282590B9DFE5@embeddedalley.com>
On Sun, 25 Nov 2007 13:02:03 -0800
Dan Malek wrote:
>
> On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote:
>
> > To prevent using those pointers from within non-GPL modules. kind
> > of policy now...
>
> As the original copyright holder of nearly all of this of
> this code, I do not wish this be done.
In this particular case this is not going to happen anyway, but I will take your opinion into
account for the similar cases.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-26 10:24 UTC (permalink / raw)
To: Michel D?nzer, linuxppc-dev
In-Reply-To: <1196068814.22865.108.camel@thor.sulgenrain.local>
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
On Mon, Nov 26, 2007 at 10:20:14AM +0100, Michel D?nzer wrote:
> > Regarding the sub-thread on x86 emulation, that is totally out of scope
> > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
> > may have minor errors here, ask airlied if you need more
> > clarification):
> > a) Initialization code (I think arch-specific)
> > b) AtomBIOS script interpreter (I think arch-specific)
> > c) AtomBIOS scripts (card-specific, but not arch-specific)
> > d) Data tables (card-specific, but not arch-specific)
> >
> > The AtomBIOS parts of the various drivers need data from c+d primarily,
> > and provide their own script interpreter, or not using the scripts, just
> > the data tables.
> Are you sure the X1900 Mac Edition ROM contains any ATOM data structures
> though? I rather doubt it.
That's what I'm trying to ascertain actually, because it directly
impacts what work needs to be done in the drivers.
If it was me writing the ROMs in the first place (but it's not), from
what I understand of the ATOM, I'd have OpenFirmware versions of a+b,
and then could re-use c+d.
The fact that both Nvidia and ATI OF-powered cards fail when trying to
access their expansion ROMs, I'm inclined to think there is something in
accessing them that we are missing, and that the ROMs must exist (the
sata_mv one existed and was accessible).
On actually accessing the rest of the ATI X1900 card, the avivotool from
git://people.freedesktop.org/~airlied/radeontool.git (avivo branch) can
actually access the rest of the rest of the card registers.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* perfmon2 needs hard_irq_disable() for powerpc
From: Sonny Rao @ 2007-11-26 7:44 UTC (permalink / raw)
To: perfmon2-devel
Cc: mikey, miltonm, dwg, linuxppc-dev, paulus, anton, eranian,
cjashfor
Hi, I've been reading through the perfmon2 patch for 2.6.23 and it
dawned on me that in the powerpc architecture we have the notion of
lazy-disabling of interrupts where we don't actually disable
interrupts unless we see one come in and then turn them off. I believe
a notable exception is the performance monitor interrupt which we
allow to break into our critical sections. This is desirable because
we want to profile those sections and right now, no in-kernel user of
the performance monitor interrupt in powerpc does any synchronization
across cpus inside the interrupt handler (oprofile seems to use
per-cpu buffers/state for everything). We use hard_irq_disable() when
we _really_ have to disable interrupts because we're switching out the
kernel stack, etc.
Perfmon2 is more demanding in its synchronization requirements and it
uses spin_lock_irqsave() in the generic arch-neutral code in several
places, I think this will break on powerpc the way we're handling
things now.
I'm copying a few people to solicit opinions on how best to deal with
this. I think it's desirable to keep the property of letting us
profile critical sections in the kernel wherever possible. So we would
need to add hard_irq_disable/enable calls to the generic code, but want to
check with you guys first.
Sonny
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Michel Dänzer @ 2007-11-26 9:20 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20071126085928.GE14557@curie-int.orbis-terrarum.net>
On Mon, 2007-11-26 at 00:59 -0800, Robin H. Johnson wrote:
>
> Regarding the sub-thread on x86 emulation, that is totally out of scope
> for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
> may have minor errors here, ask airlied if you need more
> clarification):
> a) Initialization code (I think arch-specific)
> b) AtomBIOS script interpreter (I think arch-specific)
> c) AtomBIOS scripts (card-specific, but not arch-specific)
> d) Data tables (card-specific, but not arch-specific)
>
> The AtomBIOS parts of the various drivers need data from c+d primarily,
> and provide their own script interpreter, or not using the scripts, just
> the data tables.
Are you sure the X1900 Mac Edition ROM contains any ATOM data structures
though? I rather doubt it.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: perfmon2 needs hard_irq_disable() for powerpc
From: Stephane Eranian @ 2007-11-26 8:55 UTC (permalink / raw)
To: Sonny Rao
Cc: mikey, miltonm, dwg, linuxppc-dev, paulus, anton, cjashfor,
perfmon2-devel
In-Reply-To: <20071126074438.GA27499@kevlar.boston.burdell.org>
Hello Sonny,
On Mon, Nov 26, 2007 at 02:44:38AM -0500, Sonny Rao wrote:
> Hi, I've been reading through the perfmon2 patch for 2.6.23 and it
> dawned on me that in the powerpc architecture we have the notion of
> lazy-disabling of interrupts where we don't actually disable
> interrupts unless we see one come in and then turn them off. I believe
> a notable exception is the performance monitor interrupt which we
> allow to break into our critical sections. This is desirable because
> we want to profile those sections and right now, no in-kernel user of
> the performance monitor interrupt in powerpc does any synchronization
> across cpus inside the interrupt handler (oprofile seems to use
> per-cpu buffers/state for everything). We use hard_irq_disable() when
> we _really_ have to disable interrupts because we're switching out the
> kernel stack, etc.
>
> Perfmon2 is more demanding in its synchronization requirements and it
> uses spin_lock_irqsave() in the generic arch-neutral code in several
> places, I think this will break on powerpc the way we're handling
> things now.
>
We use spinlocks to serialize access to the perfmon context. The irq masking
is here to avoid a race between a user calling into perfmon and a counter
interrupt.
Allowing PMU interrupts in critical sections is useful, yet it gets
complicated very quickly because of locking issues, including within
the perfmon code. For instance, a consequence of a interrupt could be
that a SIGIO message is posted. If counter interrupts were allowed in the
signal code, then we could potentially get dedlock situations.
>From what you are saying it seems on powerpc, there may be a way to
differentiate interrupts and thus possibly allow a less restrictive
locking policy.
> I'm copying a few people to solicit opinions on how best to deal with
> this. I think it's desirable to keep the property of letting us
> profile critical sections in the kernel wherever possible. So we would
> need to add hard_irq_disable/enable calls to the generic code, but want to
> check with you guys first.
>
I am open to suggestions. If we can enable monitoring in critical sections
and still avoid races and dealocks, at least on powerpc, then I'll be happy
to allow this.
Thanks.
--
-Stephane
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-26 8:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071125194101.GD14557@curie-int.orbis-terrarum.net>
[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]
On Sun, Nov 25, 2007 at 11:41:01AM -0800, Robin H. Johnson wrote:
> I was looking around for a description of the ROM layout, and instead I
> found this: http://developer.apple.com/technotes/tn/tn2000.html
> It was relevant because it explicitly mentioned enabling the
> PCI_COMMAND_MEMORY bit in the PCI_COMMAND register, which is NOT present
> in any path of the sizing code.
...
> By doing:
> # dev="/sys/devices/pci0001:00/0001:00:03.0/0001:06:00.0/"
> # echo 1 >${dev}/enable
> # echo 1 >${dev}/rom
> # cat ${dev}/rom >rom
> The ROM is successfully returned for two of my 3 cards.
> Namely, both of the ones containing x86 BIOS (sata_sil24, ATI X700).
> The X1900 does still not return any ROM.
...
> I broke my testing kernel temporarily, so I need a bit more testing to
> see why the X1900 did not return a ROM. More on that in a couple of
> hours.
(Part of this is from an IRC discussion with benh, summarized with
results here).
Thanks to some friends, I added some more PCIe cards to the test set:
The complete list is now:
x86-BIOS:
- Silicon Image, Inc. SiI 3132 Serial ATA Raid II (sata_sil24)
- ATI X700
OpenFirmware (all get relevant nodes in the device-tree after boot):
- ATI X1900
- Nvidia 6600
- Marvell SATA 7042 (sata_mv) [Sonnet Tempo SATA E4P]
For testing, I explicitly enable the device, and then try to read the
ROM. Additionally, I have some debug printk statements scattered about
rom.c and pci-sysfs.c, to detect various parts of the branching.
Additionaly per Jon's suggestion, I also have a bit of code at the end
of the sizing routine:
if (image == rom) { printk(...); return size; }
On the G5, the results are as follows:
- sata_sil24, X700, sata_mv - ROMS readable and valid.
- Nvidia 6600 - Returns junk data, changes between boots.
pci_get_rom_size fails the size decode, the first two readb() both
return 0x33
- ATI X1900 - Returns nulls. pci_get_rom_size fails here, the readbs()
return 0x00.
On an x86_64 (Core2 Duo), the results are as follows:
- sata_sil24 , X700 - ROMS readable and valid.
- sata_mv - appears in lspci, and works, but lspci does NOT show an 'Expansion ROM' line.
- Nvidia 6600, ATI X1900 - do not show up the kernel at all, or in
lspci. The PCIe Root port [8086:29a1] is entirely missing from the
lspci output.
Regarding the sub-thread on x86 emulation, that is totally out of scope
for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
may have minor errors here, ask airlied if you need more
clarification):
a) Initialization code (I think arch-specific)
b) AtomBIOS script interpreter (I think arch-specific)
c) AtomBIOS scripts (card-specific, but not arch-specific)
d) Data tables (card-specific, but not arch-specific)
The AtomBIOS parts of the various drivers need data from c+d primarily,
and provide their own script interpreter, or not using the scripts, just
the data tables.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: [PATCH] Add for_each_child_of_node() helper for iterating over child nodes
From: Stephen Rothwell @ 2007-11-26 8:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, David S. Miller
In-Reply-To: <e68326d47ae49fee03c635514d5a86a566b13ff9.1196064155.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
On Mon, 26 Nov 2007 19:03:45 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
>
> Add for_each_child_of_node() to encapsulate the common idiom of
> iterating over the children of a device_node.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
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] ehea: Add kdump support
From: Michael Ellerman @ 2007-11-26 8:16 UTC (permalink / raw)
To: Thomas Klein
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Paul Mackerras,
Marcus Eder, Stefan Roscher
In-Reply-To: <200711091433.51259.osstklei@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]
On Fri, 2007-11-09 at 14:33 +0100, Thomas Klein wrote:
> To support ehea driver reloading in a kdump kernel the driver has to perform
> firmware handle deregistrations when the original kernel crashes. As there's
> currently no notifier chain for machine crashes this patch enables kdump support
> in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
> machine crash handler. The original machine_crash_shutdown() fn is called
> afterwards. This works fine as long as the ehea driver is the only one which
> does so. Problems may occur if other drivers do the same and unload regularly.
> This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
> low risk on base kernel. In 2.6.24 we know ehea is the only user of this
> mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
> The full solution might be that register_reboot_notifier() provides sth
> like a SYS_CRASH action. Please apply.
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 2 +-
> drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+), 1 deletions(-)
>
Hi Thomas,
I'm sorry, but this patch is all wrong IMHO.
For kdump we have to assume that the kernel is fundamentally broken,
we've panicked, so something bad has happened - every line of kernel
code that is run decreases the chance that we'll successfully make it
into the kdump kernel.
So just calling unregister_driver() is no good, that's going to call
lots of code, try to take lots of locks, rely on lots of data structures
being uncorrupted etc. etc.
And the hijacking of machine_crash_shutdown() is IMO not an acceptable
solution, as you say it only works if EHEA is the only driver to do it.
And as soon as EHEA does it other drivers will want to do it.
What we need is the _minimal_ set of actions that can happen to make
EHEA work in the kdump kernel.
Solutions that might be better:
a) if there are a finite number of handles and we can predict their
values, just delete them all in the kdump kernel before the driver
loads.
b) if there are a small & finite number of handles, save their values
in a device tree property and have the kdump kernel read them and
delete them before the driver loads.
c) if neither of those work, provide a minimal routine that _only_
deletes the handles in the crashed kernel.
d) <something else>
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
* [PATCH] Add for_each_child_of_node() helper for iterating over child nodes
From: Michael Ellerman @ 2007-11-26 8:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, David S. Miller
Add for_each_child_of_node() to encapsulate the common idiom of
iterating over the children of a device_node.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
After conducting a straw pole of powerpc hackers, this seems to be the
preferred name for such a beast.
include/linux/of.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 5c39b92..c65af7b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -46,6 +46,10 @@ extern struct device_node *of_find_node_by_phandle(phandle handle);
extern struct device_node *of_get_parent(const struct device_node *node);
extern struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev);
+#define for_each_child_of_node(parent, child) \
+ for (child = of_get_next_child(parent, NULL); child != NULL; \
+ child = of_get_next_child(parent, child))
+
extern struct property *of_find_property(const struct device_node *np,
const char *name,
int *lenp);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-26 7:46 UTC (permalink / raw)
To: PPCML; +Cc: Olof Johansson, Paul Mackerras, LKML
[-- Attachment #1: Type: text/plain, Size: 218 bytes --]
This patch adds checking for NULL value returned to prevent possible
NULL pointer dereference.
Also two unneeded 'return' are removed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
Any comments are welcome.
[-- Attachment #2: ppc-celleb-fix-null.diff --]
[-- Type: text/plain, Size: 2105 bytes --]
arch/powerpc/platforms/celleb/pci.c | 23 ++++++++++++++++++++---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..9b8bb01 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config, int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config, int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -348,9 +345,25 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
pr_debug("PCI: res assigned 0x%016lx\n", (unsigned long)*res);
wi0 = of_get_property(node, "device-id", NULL);
+ if (unlikely((!wi0))) {
+ printk(KERN_ERR "PCI: device-id not found.\n");
+ goto error;
+ }
wi1 = of_get_property(node, "vendor-id", NULL);
+ if (unlikely((!wi1))) {
+ printk(KERN_ERR "PCI: vendor-id not found.\n");
+ goto error;
+ }
wi2 = of_get_property(node, "class-code", NULL);
+ if (unlikely((!wi2))) {
+ printk(KERN_ERR "PCI: class-code not found.\n");
+ goto error;
+ }
wi3 = of_get_property(node, "revision-id", NULL);
+ if (unlikely((!wi3))) {
+ printk(KERN_ERR "PCI: revision-id not found.\n");
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] & 0xffff);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] & 0xffff);
@@ -372,6 +385,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, "interrupts", &rlen);
+ if (!li) {
+ printk(KERN_ERR "PCI: interrupts not found.\n");
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
^ permalink raw reply related
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