* Fw: Regarding Device tree PCI binding on Linux-2.6.30 kernels
From: Thirumalai @ 2009-08-12 11:45 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
> Hi,
> Is there any changes on PCI Device tree binding has happened? Because i
> am trying to port linux 2.6.30 to my MPC7448 based custom board. The
> target is getting hanged at ethernet initialization. Also i have seen on
> the debug message of kernel that the PCI MEM/IO resources are not getting
> assigned. So when searched the reason for not assigning the PCI MEM/IO
> spaces. I have seen the implemetation of
> /linux/arch/powerpc/kernel/pci-common.c/ pci_process_bridge_OF_ranges() is
> some what different from the old kernels. The CPU address is taken using
> of_translate_address() function which is in prom_parse.c. This step is not
> included on the previous implementations. This particular implementation
> causing me problem of not finding PCI MEM/IO spaces. I have taken the dts
> file of arch/powerpc/boot/dts/MPC7448hpc2.dts as my base dts file and
> started to port for my hardware.
> Kindly let me know any changes that i need to know.
> My dts file,
>
> / {
> model = "dpvme0447";
> compatible = "mpc74xx";
> #address-cells = <1>;
> #size-cells = <1>;
>
> aliases {
> ethernet0 = &enet0;
> ethernet1 = &enet1;
>
> serial0 = &serial0;
> serial1 = &serial1;
>
> };
>
> cpus {
> #address-cells = <1>;
> #size-cells =<0>;
>
> PowerPC,7448@0 {
> device_type = "cpu";
> reg = <0>;
> d-cache-line-size = <0x20>; // 32 bytes
> i-cache-line-size = <0x20>; // 32 bytes
> d-cache-size = <0x8000>; // L1, 32K
> bytes
> i-cache-size = <0x8000>; // L1, 32K
> bytes
> timebase-frequency = <0>; // 33 MHz, from
> uboot
> clock-frequency = <0>; // From U-Boot
> bus-frequency = <0>; // From U-Boot
> 32-bit;
> };
> };
>
> memory {
> device_type = "memory";
> reg = <0x00000000 0x20000000 // DDR2 512M at 0
> >;
> };
>
> tsi108@50000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> device_type = "tsi-bridge";
> ranges = <0x00000000 0x50000000 0x00010000>;
> reg = <0x50000000 0x00010000>;
> assigned-addresses = <0>;
> bus-frequency = <0>;
>
> i2c@7000 {
> interrupt-parent = <&mpic>;
> interrupts = <0xE 0>;
> reg = <0x7000 0x400>;
> device_type = "i2c";
> compatible = "tsi108-i2c";
> };
>
> MDIO: mdio@6000 {
> device_type = "mdio";
> compatible = "tsi108-mdio";
> reg = <0x6000 0x50>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> phy8: ethernet-phy@6000 {
> interrupt-parent = <&mpic>;
> interrupts = <2 1>;
> reg = <8>;
> device_type = "ethernet-phy";
> };
>
> phy9: ethernet-phy@6400 {
> interrupt-parent = <&mpic>;
> interrupts = <2 1>;
> reg = <9>;
> device_type = "ethernet-phy"; enet0:
> ethernet@6200 {
> linux,network-index = <0>;
> #size-cells = <0>;
> device_type = "network";
> compatible = "tsi108-ethernet";
> reg = <0x6000 0x200>;
> address = [ 00 06 D2 00 00 01 ];
> interrupts = <0x10 2>;
> interrupt-parent = <&mpic>;
> mdio-handle = <&MDIO>;
> phy-handle = <&phy8>;
> };
>
> enet1: ethernet@6600 {
> linux,network-index = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> compatible = "tsi108-ethernet";
> reg = <0x6400 0x200>;
> address = [ 00 06 D2 00 00 02 ];
> interrupts = <0x11 2>;
> interrupt-parent = <&mpic>;
> mdio-handle = <&MDIO>;
> phy-handle = <&phy9>;
> };
>
> serial0: serial@7808 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x7808 0x200>;
> clock-frequency = <0x3f6b5a00>;
> interrupts = <0xc 0>;
> interrupt-parent = <&mpic>;
> };
>
> serial1: serial@7c08 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x7c08 0x200>;
> clock-frequency = <0x3f6b5a00>;
> interrupts = <0xd 0>;
> interrupt-parent = <&mpic>;
> };
> mpic: pic@7400 {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <0x7400 0x400>;
> built-in;
> compatible = "chrp,open-pic";
> device_type = "open-pic";
> big-endian;
> };
> pci@1000 {
> device_type = "pci";
> compatible = "tsi108-pci";
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <0x1000 0x1000>;
> big-endian;
> bus-range = <0x0 0xff>;
> /* RANGE_TYPE UNKNOWN PCI_ADD PROC_ADDR UNKNOWN
> SIZE
> 02000000 - PCIMEM
> 42000000 - PCI-MEM-PREFETCH
> 01000000 - PCIIO
> */
> ranges = <0x02000000 0x0 0xe0000000 0xe0000000 0x0
> 0x10000000
> 0x42000000 0x0 0x80000000 0x80000000 0x0
> 0x40000000
> 0x01000000 0x0 0x00000000 0xf0000000 0x0
> 0x00010000>;
> clock-frequency = <0x7f28154>;
> interrupt-parent = <&mpic>;
> interrupts = <0x17 2>;
> interrupt-map-mask = <0xf800 0 0 7>;
> interrupt-map = <
>
> /* IDSEL 0x11 */
> 0x0800 0x0 0x0 0x1 &RT0 0x24 0x0
> 0x0800 0x0 0x0 0x2 &RT0 0x25 0x0
> 0x0800 0x0 0x0 0x3 &RT0 0x26 0x0
> 0x0800 0x0 0x0 0x4 &RT0 0x27 0x0
>
> /* IDSEL 0x12 */
> 0x1000 0x0 0x0 0x1 &RT0 0x25 0x0
> 0x1000 0x0 0x0 0x2 &RT0 0x26 0x0
> 0x1000 0x0 0x0 0x3 &RT0 0x27 0x0
> 0x1000 0x0 0x0 0x4 &RT0 0x24 0x0
>
> /* IDSEL 0x13 */
> 0x1800 0x0 0x0 0x1 &RT0 0x26 0x0
> 0x1800 0x0 0x0 0x2 &RT0 0x27 0x0
> 0x1800 0x0 0x0 0x3 &RT0 0x26 0x0
> 0x1800 0x0 0x0 0x4 &RT0 0x26 0x0
>
> /* IDSEL 0x14 */
> 0x2000 0x0 0x0 0x1 &RT0 0x27 0x0
> 0x2000 0x0 0x0 0x2 &RT0 0x24 0x0
> 0x2000 0x0 0x0 0x3 &RT0 0x25 0x0
> 0x2000 0x0 0x0 0x4 &RT0 0x26 0x0
> >;
>
> RT0: router@1180 {
> clock-frequency = <0>;
> interrupt-controller;
> device_type = "pic-router";
> #address-cells = <0>;
> #interrupt-cells = <2>;
> built-in;
> big-endian;
> interrupts = <0x17 2>;
> interrupt-parent = <&mpic>;
> };
> };
> };
> };
>
> Regards,
> T.
> };
>
> };
>
Panic Message that i got
------------[ cut here ]------------
Kernel BUG at c0190764 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
DPVME0447
NIP: c0190764 LR: c0190764 CTR: c014ea54
REGS: df82bd80 TRAP: 0700 Not tainted (2.6.30)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24000022 XER: 20000000
TASK = df82c000[1] 'swapper' THREAD: df82a000
GPR00: c0190764 df82be30 df82c000 0000001a 00001509 ffffffff c014e9a4
00000034
GPR08: c02f4af0 c02e9bb8 00001509 c02cf8f4 24000022 00000000 00000002
00000000
GPR16: c02c0000 00000000 00000000 00000000 00000000 0ffaa41c c0300000
00000004
GPR24: 00000000 00000000 c02f0000 c02f0000 df821030 00000000 df821000
df821300
NIP [c0190764] tsi108_open+0x68/0x9c
LR [c0190764] tsi108_open+0x68/0x9c
Call Trace:
[df82be30] [c0190764] tsi108_open+0x68/0x9c (unreliable)
[df82be50] [c01b157c] dev_open+0xac/0x11c
[df82be70] [c01b147c] dev_change_flags+0x160/0x1b4
[df82be90] [c02bd8f4] ip_auto_config+0x18c/0xe5c
[df82bf50] [c0003c8c] do_one_initcall+0x34/0x1a8
[df82bfd0] [c02a2848] kernel_init+0x9c/0x100
[df82bff0] [c0012024] kernel_thread+0x4c/0x68
Instruction dump:
7c7d1b79 40820034 80bf003c 3c60c029 7fc6f378 38632ad8 90be0028 809f0040
4be90669 3c60c029 38632b08 4be9065d <0fe00000> 48000000 80bf003c 3c60c029
---[ end trace a900fd7f842065b9 ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Regards,
T.
**************** CAUTION - Disclaimer *****************This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
*********** End of Disclaimer ***********DataPatterns ITS Group**********
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Josh Boyer @ 2009-08-12 11:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: John Jacques, linuxppc-dev list, devicetree-discuss, Torez Smith,
Russell King
In-Reply-To: <1250063825.15143.43.camel@pasglop>
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
>Hi folks !
>
>(Russell, let us know if you want to dropped from the CC list, but I
>felt you may have some useful input to provide here).
>
>So I think it would be valuable to provide the ARM clock API exposed by
>include/linux/clk.h on various PowerPC embedded hardware.
I'm probably being particularly dense, and I haven't had my coffee yet this
morning, but you never actually said _why_ you think this is valuable?
I'm a bit confused as to what problem you are trying to solve with the API.
josh
^ permalink raw reply
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: Benjamin Herrenschmidt @ 2009-08-12 9:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, B.J. Buchalter
In-Reply-To: <705D9914-7AC7-42AB-A7F9-AD2447B9DDD8@kernel.crashing.org>
On Wed, 2009-08-12 at 00:20 -0500, Kumar Gala wrote:
> It is suppose to. I would recommend updating u-boot to something
> newer and see what you get on that side.
>
> Also I'll try see if we have a PCIe board w/a p2p bridge on it. I'm
> guessing no one has tried PCIe on 83xx w/a p2p bridge on it.
A few off-the-shelves FW + USB2 PCIe cards have that bridge and have
shown weird issues, might be worth shopping at your local Fry's :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: Benjamin Herrenschmidt @ 2009-08-12 9:56 UTC (permalink / raw)
To: B.J. Buchalter; +Cc: linuxppc-dev
In-Reply-To: <2D2EDFA8-E51F-4A2D-BEB7-8F9258518DA1@mhlabs.com>
On Tue, 2009-08-11 at 23:25 -0400, B.J. Buchalter wrote:
> I don't know the model of the board off the top of my head.
>
> I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI
> Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind the
> bridge.
>
> The same board definitely works as expected in a Mac Pro.
I've had problems on embedded 4xx with some of those guys. I think
there's a problem with the TI bridge, either it needs more time to
settle after reset or it doesn't cope with a second reset by the kernel
after the FW reset ,I don't remember... but there's definitely something
fishy with that bridge or something a bit too "tight" on spec we do on
both FSL and 44x that doesn't please that bridge.
Cheers,
Ben.
> In doing some Google searches about this, I have seen the TI part
> listed in the PCI configuration of folks running linux (though
> probably on Intel) and apparently having no problems with the busses
> behind the bridge being enumerated.
>
> I am guessing that the problem is related the the PCIe root complex on
> the 8377, but I am just guessing.
>
> Is PCIe known to work on the MPC837x?
>
> Thanks!
>
> B.J. Buchalter
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-12 8:29 UTC (permalink / raw)
To: devicetree-discuss
Cc: John Jacques, linuxppc-dev list, Torez Smith, Russell King
In-Reply-To: <1250063825.15143.43.camel@pasglop>
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
> - Device-tree: The idea on top of my mind would be to define a
> clock-map property that has the following format:
>
> A list of:
> - zero terminated string clock ID, padded with zeros
> to a cell boundary
> - a phandle to the clock provider
> - a numerical (string ?) ID for that clock within that provider
>
> The core would thus be able to do a search in that list based on the
> clock-id passed in, or if clk_get(dev, NULL), then, use the first one.
Thinking a bit more about that one, mixing strings and numbers in a
property sucks. What about instead:
clock-map is a list of phandle, id
clock-names is an optional list of 0 terminated strings
If there's only one clock, and the ID can be ommited, then the
clock-names property can be ommited completely too. Else, the
entries in clock-names match the entries in clock-map.
It's a bit strange to separate the list into two properties but
I think it will generally suck less than having them mixed, especially
with ASCII representations such as lsprop output.
Cheers,
Ben
^ permalink raw reply
* ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-12 7:57 UTC (permalink / raw)
To: devicetree-discuss
Cc: John Jacques, linuxppc-dev list, Torez Smith, Russell King
Hi folks !
(Russell, let us know if you want to dropped from the CC list, but I
felt you may have some useful input to provide here).
So I think it would be valuable to provide the ARM clock API exposed by
include/linux/clk.h on various PowerPC embedded hardware.
However, that brings various issues that I would like to discuss here,
as while the API exposed to driver is quite sane and something we might
want to keep mostly intact, I'm not too happy with what appears to be
the common practice on ARM which is to re-implement the whole API on
each machine type :-) I understand why they do that but that won't work
very well for us.
That leads to two major "items" to deal with basically:
- What provides the implementation of clk_get & friends
- How do we want (do we want at all ?) to use the device-tree to
some extent to represent the clocks
Now, here are some ideas, mostly in random orders, that I'm throwing
to the list for discussion, and from there we might see a plan emerge
(or not).
- Similar to what I did for interrupts, the core clk API implementation
(if there is such a thing) should not -require- some device-tree
representation or another, ie, we could and probably should provide
helpers, for example by allowing clk_get to use the device-tree to
lookup clocks (see discussions below) etc... but the base infrastructure
should work without and it should be possible (even if discouraged) for
a platform to provide the necessary stuff entirely from C code, like we
can create virq mappings without device-tree.
- We aren't be able to cater for all possible clock net layouts with a
single "core". Thus I think we should provide a "think" layer. The clk
object should probably have methods and clk_get_rate etc.. end up
calling these. Thus the "core" basically boils down to finding a clock
object for a given device. IE, Implementing clk_get(), which thus could
become a ppc_md. callback. We can provide a default one that uses the
device-tree to some extent, do be discussed.
- I looked at ARMs' mach-ns9xxx, which pretty much does the above
(without the ppc_md. bit) and I tend to think that maybe this would do a
nice base for a "core". I do wonder whether we should have the "ops" in
a separate struct so that it's easier for multiple instances of a clk to
share ops (when multiple clocks come from the same clock chip).
- From the above, question: Do we want to keep that parent pointer ?
Does it make sense ? Will we have objects that are clock providers and
themselves source from multiple parent ? Or we don't care and it becomes
entirely the responsibility of a given struct clk instance to deal with
its own parenthood ? Parenthood in the core has the advantage of making
it potentially easier to represent clock nets in the device-tree.
- Device-tree: The idea on top of my mind would be to define a
clock-map property that has the following format:
A list of:
- zero terminated string clock ID, padded with zeros
to a cell boundary
- a phandle to the clock provider
- a numerical (string ?) ID for that clock within that provider
The core would thus be able to do a search in that list based on the
clock-id passed in, or if clk_get(dev, NULL), then, use the first one.
A bit like irq_hosts, we provide a way to register clock providers
associated with a device-node. They provide a matching clk_get()
routine, thus when clk_get is called, the above lookup is done in the
clock-map, the clock provider is found, and it's own clk_get() method is
called with the original ID, the numerical ID, the target device, all it
might need to sort things out.
That's a reasonably simple way. I was thinking about something more
fancy like interrupts, with a #clock-cells, clocks, clock-parent
proprerties etc... but that has several drawbacks and isn't that useful.
One drawback is that like interrupts, it's hard to use such a scheme
with more than one parent for a device, and that's a lot more common
with clocks. Also, the existing API uses string clock IDs while the
above would have worked well only with numerical IDs.
Anyways, you guys give it a good thought and we see how it goes, it
shouldn't be a big deal, what do you think ?
Note that clock providers can be any node, so they can themselves be
of_devices that are naturally probed as such. We of course end up with
the usual problem of who gets registered first, since obviously clock
providers need to come in before they are looked up, and so I might
suggest that we stick in there a clock-provider property with no value,
and we have a way to return a specific error code to the driver if there
seem to be a DT clock provider but nothing registered for it yet, but
that adds some complication.
Maybe threaded probe can get us out of it by having one guy wait and the
probe continue until the clock provider is there :-) Or in the meantime
we just manually register them from arch code... whatever.
Also, it would be nice to have a way to have "generic" clock provider
drivers. For example, have a driver for the FooBar Clock chip, which is
known to provide 4 fully programmable clocks. So there could be a
generic driver for that, attached to the clock provider by the probe
code or via the device-tree, the devices clock-map's just provide the
clock ID within the chip (which output of the chip they are connected
to), and so the remaining questions is what to program in each clocks.
That's where we may want to define a clock-rates property that the clock
provider uses. HOWEVER, I'm keen at first to make that device-specific
rather than try to go to far at generalizing. Clock ships are fancy
little things with all sort of weird issues and constraints, so while it
would be nice to have all the necessary infos to program it in the DT,
I'm tempted to make the 'format' of those specific to a given clock chip
device/driver combination. To be discussed.
Anyway, thoughts ?
Cheers,
Ben.
^ permalink raw reply
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: B.J. Buchalter @ 2009-08-12 6:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <705D9914-7AC7-42AB-A7F9-AD2447B9DDD8@kernel.crashing.org>
On Aug 12, 2009, at 1:20 AM, Kumar Gala wrote:
>
> On Aug 11, 2009, at 10:25 PM, B.J. Buchalter wrote:
>
>> I don't know the model of the board off the top of my head.
>>
>> I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI
>> Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind
>> the bridge.
>>
>> The same board definitely works as expected in a Mac Pro.
>>
>> In doing some Google searches about this, I have seen the TI part
>> listed in the PCI configuration of folks running linux (though
>> probably on Intel) and apparently having no problems with the
>> busses behind the bridge being enumerated.
>>
>> I am guessing that the problem is related the the PCIe root complex
>> on the 8377, but I am just guessing.
>>
>> Is PCIe known to work on the MPC837x?
>
> It is suppose to. I would recommend updating u-boot to something
> newer and see what you get on that side.
Ok -- I can try that; I have been using the u-boot that shipped with
the board to avoid having to worry about wiping out the boot-load
accidently.
> Also I'll try see if we have a PCIe board w/a p2p bridge on it. I'm
> guessing no one has tried PCIe on 83xx w/a p2p bridge on it.
I see. A lot of the FireWire parts are based upon p2p bridges...
Thanks!
B.J. Buchalter
^ permalink raw reply
* [PATCH] powerpc/85xx: Workaround MPC8572/MPC8536 GPIO 1 errata.
From: Felix Radensky @ 2009-08-12 5:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Felix Radensky
On MPC8572 and MPC8536 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Felix Radensky <felix@embedded-sol.com>
---
arch/powerpc/sysdev/mpc8xxx_gpio.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 103eace..ee1c0e1 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -54,6 +54,22 @@ static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip *mm)
mpc8xxx_gc->data = in_be32(mm->regs + GPIO_DAT);
}
+/* Workaround GPIO 1 errata on MPC8572/MPC8536. The status of GPIOs
+ * defined as output cannot be determined by reading GPDAT register,
+ * so we use shadow data register instead. The status of input pins
+ * is determined by reading GPDAT register.
+ */
+static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ u32 val;
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
+
+ return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
+}
+
static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
@@ -136,7 +152,10 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
gc->ngpio = MPC8XXX_GPIO_PINS;
gc->direction_input = mpc8xxx_gpio_dir_in;
gc->direction_output = mpc8xxx_gpio_dir_out;
- gc->get = mpc8xxx_gpio_get;
+ if (of_device_is_compatible(np, "fsl,mpc8572-gpio"))
+ gc->get = mpc8572_gpio_get;
+ else
+ gc->get = mpc8xxx_gpio_get;
gc->set = mpc8xxx_gpio_set;
ret = of_mm_gpiochip_add(np, mm_gc);
--
1.5.4.3
^ permalink raw reply related
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: Kumar Gala @ 2009-08-12 5:20 UTC (permalink / raw)
To: B.J. Buchalter; +Cc: linuxppc-dev
In-Reply-To: <2D2EDFA8-E51F-4A2D-BEB7-8F9258518DA1@mhlabs.com>
On Aug 11, 2009, at 10:25 PM, B.J. Buchalter wrote:
> I don't know the model of the board off the top of my head.
>
> I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI
> Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind
> the bridge.
>
> The same board definitely works as expected in a Mac Pro.
>
> In doing some Google searches about this, I have seen the TI part
> listed in the PCI configuration of folks running linux (though
> probably on Intel) and apparently having no problems with the busses
> behind the bridge being enumerated.
>
> I am guessing that the problem is related the the PCIe root complex
> on the 8377, but I am just guessing.
>
> Is PCIe known to work on the MPC837x?
It is suppose to. I would recommend updating u-boot to something
newer and see what you get on that side.
Also I'll try see if we have a PCIe board w/a p2p bridge on it. I'm
guessing no one has tried PCIe on 83xx w/a p2p bridge on it.
- k
^ permalink raw reply
* Re: [PATCH 4/7] spi: Prefix modalias with "spi:"
From: Mike Frysinger @ 2009-08-12 4:12 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, linux-kernel, lm-sensors, linuxppc-dev, linux-mtd,
Jean Delvare, Andrew Morton, David Woodhouse
In-Reply-To: <20090729170510.GD4803@oksana.dev.rtsoft.ru>
On Wed, Jul 29, 2009 at 13:05, Anton Vorontsov wrote:
> This makes it consistent with other buses (platform, i2c, vio, ...).
> I'm not sure why we use the prefixes, but there must be a reason.
>
> This was easy enough to do it, and I did it.
acked-by-me for misc blackfin/adi drivers, thanks
-mike
^ permalink raw reply
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: B.J. Buchalter @ 2009-08-12 3:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <9E566D12-1A26-41BC-BB71-27D4CCE54E20@kernel.crashing.org>
On Aug 11, 2009, at 9:43 PM, Kumar Gala wrote:
>
> On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
>
>>
>> I have been trying to use a PCIe FireWire card on a MPC8377E-RDB
>> board.
>
> is this an off the shelf PCIe FireWire card?
Yes.
> If so which one?
I don't know the model of the board off the top of my head.
I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI
Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind the
bridge.
The same board definitely works as expected in a Mac Pro.
In doing some Google searches about this, I have seen the TI part
listed in the PCI configuration of folks running linux (though
probably on Intel) and apparently having no problems with the busses
behind the bridge being enumerated.
I am guessing that the problem is related the the PCIe root complex on
the 8377, but I am just guessing.
Is PCIe known to work on the MPC837x?
Thanks!
B.J. Buchalter
^ permalink raw reply
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: B.J. Buchalter @ 2009-08-12 3:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <835B2CCF-7189-499F-B0F5-527F2A788A77@kernel.crashing.org>
On Aug 11, 2009, at 9:43 PM, Kumar Gala wrote:
>
> On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
>
>>
>> So it seems like the XIO2000(A) is being misconfigured or
>> misidentified, and rather than finding the configured bus behind
>> the bridge, it is doing "something else", and as a result, not
>> finding the PCI OHCI FireWire controller on the PCI side of the
>> bridge.
>>
>> Unfortunately I have no real idea where to start looking at this...
>>
>> Any ideas? Or is there a better place to be posting about this?
>
> This is a reasonable place to post this. Can you see what u-boot
> reports for its PCI/e bus scan?
Thanks,
This is what u-boot says:
U-Boot 1.3.3 (Jun 19 2008 - 10:47:48) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal
Hard
CPU: e300c4, MPC8377E, Rev: 1.0 at 666.666 MHz, CSB: 333.333 MHz
Board: Freescale MPC837xERDB
I2C: ready
DRAM: 256 MB
PCIE0: Link
PCIE1: No link
FLASH: 8 MB
NAND: 32 MiB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1
eSDHC: No SD/MMC card found
SATA: SATA0 (No RDY)
SATA1 (No RDY)
Hit any key to stop autoboot: 0
=> set serverip 10.0.1.40
=> run tftpnfsboot
If there is additional information to be found, I'd be happy to
collect it.
Best regards,
B.J. Buchalter
^ permalink raw reply
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: Kumar Gala @ 2009-08-12 1:43 UTC (permalink / raw)
To: B.J. Buchalter; +Cc: linuxppc-dev
In-Reply-To: <4D3BDC67-986A-482D-BB3F-497F64C68531@mhlabs.com>
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
>
> I have been trying to use a PCIe FireWire card on a MPC8377E-RDB
> board.
is this an off the shelf PCIe FireWire card? If so which one?
- k
^ permalink raw reply
* Re: Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: Kumar Gala @ 2009-08-12 1:43 UTC (permalink / raw)
To: B.J. Buchalter; +Cc: linuxppc-dev
In-Reply-To: <4D3BDC67-986A-482D-BB3F-497F64C68531@mhlabs.com>
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
>
> So it seems like the XIO2000(A) is being misconfigured or
> misidentified, and rather than finding the configured bus behind the
> bridge, it is doing "something else", and as a result, not finding
> the PCI OHCI FireWire controller on the PCI side of the bridge.
>
> Unfortunately I have no real idea where to start looking at this...
>
> Any ideas? Or is there a better place to be posting about this?
This is a reasonable place to post this. Can you see what u-boot
reports for its PCI/e bus scan?
- k
^ permalink raw reply
* Problem with PCIe -> PCI bridge on MPC8377E-RDB
From: B.J. Buchalter @ 2009-08-11 22:27 UTC (permalink / raw)
To: linuxppc-dev
Hey Folks,
I have been trying to use a PCIe FireWire card on a MPC8377E-RDB board.
I have tried this with both the LTIB/BSP (2.6.25) and the head of the
kernel.org tree (at least from a couple of days ago).
With 2.6.25, the PCIe buss(es) don't show up at all during boot.
With 2.6.31-rc? the PCIe busses do show up, and the PCIe -> PCI bridge
is recognized, but no devices behind the bridge are probed or
identified.
Here is the boot log:
[ 0.000000] Linux version 2.6.31-rc5-00381-g7b2aa03-dirty (adminuser@debian.virtualboximages
) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-74) ) #32 Tue Aug 11
17:32:27 EDT 2009
[ 0.000000] console [udbg0] enabled
setup_arch: bootmem
mpc837x_rdb_setup_arch()
[ 0.000000] Found FSL PCI host bridge at 0x00000000e0008500.
Firmware bus number: 0->0
[ 0.000000] PCI host bridge /pci@e0008500 (primary) ranges:
[ 0.000000] MEM 0x0000000090000000..0x000000009fffffff ->
0x0000000090000000
[ 0.000000] MEM 0x0000000080000000..0x000000008fffffff ->
0x0000000080000000 Prefetch
[ 0.000000] IO 0x00000000e0300000..0x00000000e03fffff ->
0x0000000000000000
[ 0.000000] No pci config register base in dev tree, using default
[ 0.000000] Found FSL PCI host bridge at 0x00000000e0009000.
Firmware bus number: 0->255
[ 0.000000] PCI host bridge /pcie@e0009000 ranges:
[ 0.000000] MEM 0x00000000a8000000..0x00000000b7ffffff ->
0x00000000a8000000
[ 0.000000] IO 0x00000000b8000000..0x00000000b87fffff ->
0x0000000000000000
[ 0.000000] No pci config register base in dev tree, using default
[ 0.000000] Found FSL PCI host bridge at 0x00000000e000a000.
Firmware bus number: 0->255
[ 0.000000] PCI host bridge /pcie@e000a000 ranges:
[ 0.000000] MEM 0x00000000c8000000..0x00000000d7ffffff ->
0x00000000c8000000
[ 0.000000] IO 0x00000000d8000000..0x00000000d87fffff ->
0x0000000000000000
[...]
[ 0.129452] PCI: Probing PCI hardware
[ 0.133549] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
[ 0.139448] pci 0000:00:00.0: PME# disabled
[ 0.143727] pci 0000:00:0f.0: PME# supported from D0 D1 D2 D3hot
[ 0.149624] pci 0000:00:0f.0: PME# disabled
[ 0.154791] pci 0001:01:00.0: ignoring class b20 (doesn't match
header type 01)
[ 0.162100] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot
[ 0.168057] pci 0001:01:00.0: PME# disabled
[ 0.202566] pci 0001:03:00.0: PCI bridge, secondary bus 0001:04
[ 0.208477] pci 0001:03:00.0: IO window: disabled
[ 0.213311] pci 0001:03:00.0: MEM window: disabled
[ 0.218170] pci 0001:03:00.0: PREFETCH window: disabled
[ 0.223528] pci 0001:03:01.0: PCI bridge, secondary bus 0001:05
[ 0.229399] pci 0001:03:01.0: IO window: disabled
[ 0.234239] pci 0001:03:01.0: MEM window: disabled
[ 0.239163] pci 0001:03:01.0: PREFETCH window: disabled
[ 0.244522] pci 0001:03:02.0: PCI bridge, secondary bus 0001:06
[ 0.250394] pci 0001:03:02.0: IO window: disabled
[ 0.255234] pci 0001:03:02.0: MEM window: disabled
[ 0.260158] pci 0001:03:02.0: PREFETCH window: disabled
[ 0.265517] pci 0001:03:03.0: PCI bridge, secondary bus 0001:07
[ 0.271389] pci 0001:03:03.0: IO window: disabled
[ 0.276229] pci 0001:03:03.0: MEM window: disabled
[ 0.281153] pci 0001:03:03.0: PREFETCH window: disabled
[ 0.286513] pci 0001:03:04.0: PCI bridge, secondary bus 0001:08
[ 0.292384] pci 0001:03:04.0: IO window: disabled
[ 0.297224] pci 0001:03:04.0: MEM window: disabled
[ 0.302149] pci 0001:03:04.0: PREFETCH window: disabled
[ 0.307508] pci 0001:03:05.0: PCI bridge, secondary bus 0001:09
[ 0.313380] pci 0001:03:05.0: IO window: disabled
[ 0.318220] pci 0001:03:05.0: MEM window: disabled
[ 0.323144] pci 0001:03:05.0: PREFETCH window: disabled
[ 0.328503] pci 0001:03:06.0: PCI bridge, secondary bus 0001:0a
[ 0.334375] pci 0001:03:06.0: IO window: disabled
[ 0.339215] pci 0001:03:06.0: MEM window: disabled
[ 0.344139] pci 0001:03:06.0: PREFETCH window: disabled
[ 0.349498] pci 0001:03:07.0: PCI bridge, secondary bus 0001:0b
[ 0.355370] pci 0001:03:07.0: IO window: disabled
[ 0.360210] pci 0001:03:07.0: MEM window: disabled
[ 0.365134] pci 0001:03:07.0: PREFETCH window: disabled
[ 0.370493] pci 0001:03:08.0: PCI bridge, secondary bus 0001:0c
[ 0.376365] pci 0001:03:08.0: IO window: disabled
[ 0.381205] pci 0001:03:08.0: MEM window: disabled
[ 0.386129] pci 0001:03:08.0: PREFETCH window: disabled
[ 0.391489] pci 0001:03:09.0: PCI bridge, secondary bus 0001:0d
[ 0.397360] pci 0001:03:09.0: IO window: disabled
[ 0.402200] pci 0001:03:09.0: MEM window: disabled
[ 0.407125] pci 0001:03:09.0: PREFETCH window: disabled
[ 0.412484] pci 0001:03:0a.0: PCI bridge, secondary bus 0001:0e
[ 0.418356] pci 0001:03:0a.0: IO window: disabled
[ 0.423196] pci 0001:03:0a.0: MEM window: disabled
[ 0.428120] pci 0001:03:0a.0: PREFETCH window: disabled
[ 0.433479] pci 0001:03:0b.0: PCI bridge, secondary bus 0001:0f
[ 0.439351] pci 0001:03:0b.0: IO window: disabled
[ 0.444191] pci 0001:03:0b.0: MEM window: disabled
[ 0.449115] pci 0001:03:0b.0: PREFETCH window: disabled
[ 0.454474] pci 0001:03:0c.0: PCI bridge, secondary bus 0001:10
[ 0.460346] pci 0001:03:0c.0: IO window: disabled
[ 0.465186] pci 0001:03:0c.0: MEM window: disabled
[ 0.470110] pci 0001:03:0c.0: PREFETCH window: disabled
[ 0.475469] pci 0001:03:0d.0: PCI bridge, secondary bus 0001:11
[ 0.481341] pci 0001:03:0d.0: IO window: disabled
[ 0.486181] pci 0001:03:0d.0: MEM window: disabled
[ 0.491105] pci 0001:03:0d.0: PREFETCH window: disabled
[ 0.496465] pci 0001:03:0e.0: PCI bridge, secondary bus 0001:12
[ 0.502336] pci 0001:03:0e.0: IO window: disabled
[ 0.507176] pci 0001:03:0e.0: MEM window: disabled
[ 0.512101] pci 0001:03:0e.0: PREFETCH window: disabled
[ 0.517460] pci 0001:03:0f.0: PCI bridge, secondary bus 0001:13
[ 0.523331] pci 0001:03:0f.0: IO window: disabled
[ 0.528172] pci 0001:03:0f.0: MEM window: disabled
[ 0.533096] pci 0001:03:0f.0: PREFETCH window: disabled
[ 0.538455] pci 0001:03:10.0: PCI bridge, secondary bus 0001:14
[ 0.544327] pci 0001:03:10.0: IO window: disabled
[ 0.549167] pci 0001:03:10.0: MEM window: disabled
[ 0.554091] pci 0001:03:10.0: PREFETCH window: disabled
[ 0.559450] pci 0001:03:11.0: PCI bridge, secondary bus 0001:15
[ 0.565322] pci 0001:03:11.0: IO window: disabled
[ 0.570162] pci 0001:03:11.0: MEM window: disabled
[ 0.575086] pci 0001:03:11.0: PREFETCH window: disabled
[ 0.580445] pci 0001:03:12.0: PCI bridge, secondary bus 0001:16
[ 0.586317] pci 0001:03:12.0: IO window: disabled
[ 0.591157] pci 0001:03:12.0: MEM window: disabled
[ 0.596081] pci 0001:03:12.0: PREFETCH window: disabled
[ 0.601441] pci 0001:03:13.0: PCI bridge, secondary bus 0001:17
[ 0.607312] pci 0001:03:13.0: IO window: disabled
[ 0.612151] pci 0001:03:13.0: MEM window: disabled
[ 0.617076] pci 0001:03:13.0: PREFETCH window: disabled
[ 0.622436] pci 0001:03:14.0: PCI bridge, secondary bus 0001:18
[ 0.628308] pci 0001:03:14.0: IO window: disabled
[ 0.633148] pci 0001:03:14.0: MEM window: disabled
[ 0.638072] pci 0001:03:14.0: PREFETCH window: disabled
[ 0.643431] pci 0001:03:15.0: PCI bridge, secondary bus 0001:19
[ 0.649303] pci 0001:03:15.0: IO window: disabled
[ 0.654143] pci 0001:03:15.0: MEM window: disabled
[ 0.659067] pci 0001:03:15.0: PREFETCH window: disabled
[ 0.664426] pci 0001:03:16.0: PCI bridge, secondary bus 0001:1a
[ 0.670298] pci 0001:03:16.0: IO window: disabled
[ 0.675138] pci 0001:03:16.0: MEM window: disabled
[ 0.680062] pci 0001:03:16.0: PREFETCH window: disabled
[ 0.685421] pci 0001:03:17.0: PCI bridge, secondary bus 0001:1b
[ 0.691293] pci 0001:03:17.0: IO window: disabled
[ 0.696133] pci 0001:03:17.0: MEM window: disabled
[ 0.701057] pci 0001:03:17.0: PREFETCH window: disabled
[ 0.706417] pci 0001:03:18.0: PCI bridge, secondary bus 0001:1c
[ 0.712288] pci 0001:03:18.0: IO window: disabled
[ 0.717127] pci 0001:03:18.0: MEM window: disabled
[ 0.722053] pci 0001:03:18.0: PREFETCH window: disabled
[ 0.727412] pci 0001:03:19.0: PCI bridge, secondary bus 0001:1d
[ 0.733284] pci 0001:03:19.0: IO window: disabled
[ 0.738123] pci 0001:03:19.0: MEM window: disabled
[ 0.743048] pci 0001:03:19.0: PREFETCH window: disabled
[ 0.748407] pci 0001:03:1a.0: PCI bridge, secondary bus 0001:1e
[ 0.754279] pci 0001:03:1a.0: IO window: disabled
[ 0.759119] pci 0001:03:1a.0: MEM window: disabled
[ 0.764043] pci 0001:03:1a.0: PREFETCH window: disabled
[ 0.769402] pci 0001:03:1b.0: PCI bridge, secondary bus 0001:1f
[ 0.775274] pci 0001:03:1b.0: IO window: disabled
[ 0.780113] pci 0001:03:1b.0: MEM window: disabled
[ 0.785038] pci 0001:03:1b.0: PREFETCH window: disabled
[ 0.790397] pci 0001:03:1c.0: PCI bridge, secondary bus 0001:20
[ 0.796269] pci 0001:03:1c.0: IO window: disabled
[ 0.801109] pci 0001:03:1c.0: MEM window: disabled
[ 0.806033] pci 0001:03:1c.0: PREFETCH window: disabled
[ 0.811392] pci 0001:03:1d.0: PCI bridge, secondary bus 0001:21
[ 0.817264] pci 0001:03:1d.0: IO window: disabled
[ 0.822104] pci 0001:03:1d.0: MEM window: disabled
[ 0.827029] pci 0001:03:1d.0: PREFETCH window: disabled
[ 0.832388] pci 0001:03:1e.0: PCI bridge, secondary bus 0001:22
[ 0.838260] pci 0001:03:1e.0: IO window: disabled
[ 0.843100] pci 0001:03:1e.0: MEM window: disabled
[ 0.848024] pci 0001:03:1e.0: PREFETCH window: disabled
[ 0.853383] pci 0001:03:1f.0: PCI bridge, secondary bus 0001:23
[ 0.859255] pci 0001:03:1f.0: IO window: disabled
[ 0.864095] pci 0001:03:1f.0: MEM window: disabled
[ 0.869019] pci 0001:03:1f.0: PREFETCH window: disabled
[ 0.874378] pci 0001:02:00.0: PCI bridge, secondary bus 0001:03
[ 0.880250] pci 0001:02:00.0: IO window: disabled
[ 0.885090] pci 0001:02:00.0: MEM window: disabled
[ 0.890014] pci 0001:02:00.0: PREFETCH window: disabled
[ 0.895373] pci 0001:01:00.0: PCI bridge, secondary bus 0001:02
[ 0.901245] pci 0001:01:00.0: IO window: disabled
[ 0.906084] pci 0001:01:00.0: MEM window: disabled
[ 0.911009] pci 0001:01:00.0: PREFETCH window: disabled
and after boot:
$ lspci
0000:00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6
(rev 10)
0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device
00c6 (rev 10)
0001:02:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:01.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:02.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:03.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:04.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:05.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:06.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:07.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:08.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:09.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:0a.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:0b.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:0c.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:0d.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:0e.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:0f.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:10.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:11.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:12.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:13.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:14.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:15.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:16.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:17.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:18.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:19.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:1a.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:1b.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:1c.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:1d.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:1e.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
0001:03:1f.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200 PCI
Express-to-PCI Bridge (rev 03)
$ ls /sys/devices/pci0002:24
pci_bus:0002:24 power uevent
$ ls -l /sys/devices/pci0002:24/pci_bus:0002:24/
-r--r--r-- 1 root root 4096 Jan 20 20:52 cpuaffinity
lrwxrwxrwx 1 root root 0 Jan 20 20:52 device -
> ../../../devices/pci0002:24
-rw------- 1 root root 65535 Jan 20 20:52 legacy_io
-rw------- 1 root root 1048576 Jan 20 20:52 legacy_mem
drwxr-xr-x 2 root root 0 Jan 20 20:52 power
lrwxrwxrwx 1 root root 0 Jan 20 20:52 subsystem -
> ../../pci_bus
-rw-r--r-- 1 root root 4096 Jan 20 20:52 uevent
So it seems like the XIO2000(A) is being misconfigured or
misidentified, and rather than finding the configured bus behind the
bridge, it is doing "something else", and as a result, not finding the
PCI OHCI FireWire controller on the PCI side of the bridge.
Unfortunately I have no real idea where to start looking at this...
Any ideas? Or is there a better place to be posting about this?
TIA,
B.J. Buchalter
^ permalink raw reply
* Re: cross compiling wind river linux for ppc architecture
From: Josh Boyer @ 2009-08-11 23:00 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Linuxppc-dev, Sridhar Mahadevan
In-Reply-To: <7d1d9c250908111442kec430c1me20cc02d3e4fd60c@mail.gmail.com>
On Tue, Aug 11, 2009 at 05:42:26PM -0400, Paul Gortmaker wrote:
>On Tue, Aug 11, 2009 at 10:09 AM, Sridhar Mahadevan<msridhar87@gmail.com> wrote:
>> Hi,
>> Am trying to compile my WRL 2.6.21 kernel for PPC architecture.
>> The processor am using is AMCC powerpc 440EP .
>
>This isn't really the best choice of forum for trying to get help like this.
>Most of the people here are focused on working with the latest development
>kernels, and won't have the time to go back and look at year-old kernels
>based on the now removed PPC architecture.
>
>Plus they won't necessarily have any knowledge of what the WRL specific
>changes may or may not contain. If you have the opportunity to do so,
>the best choice for you would be to go through the normal WR support
>channels with full details of your problem.
>
>At a glance, it looks like you are trying to build with ARCH=powerpc, and
>yet I don't think (from memory) that the 4xx boards had migrated from
>ARCH=ppc until sometime around the 2.6.24-ish timeframe.
Basic support was in 2.6.22. 440EP was in 2.6.24.
josh
^ permalink raw reply
* Re: cross compiling wind river linux for ppc architecture
From: Paul Gortmaker @ 2009-08-11 21:42 UTC (permalink / raw)
To: Sridhar Mahadevan; +Cc: Linuxppc-dev
In-Reply-To: <70ca52c20908110709m41b1535ep4c8ed900163f3b18@mail.gmail.com>
On Tue, Aug 11, 2009 at 10:09 AM, Sridhar Mahadevan<msridhar87@gmail.com> wrote:
> Hi,
> Am trying to compile my WRL 2.6.21 kernel for PPC architecture.
> The processor am using is AMCC powerpc 440EP .
This isn't really the best choice of forum for trying to get help like this.
Most of the people here are focused on working with the latest development
kernels, and won't have the time to go back and look at year-old kernels
based on the now removed PPC architecture.
Plus they won't necessarily have any knowledge of what the WRL specific
changes may or may not contain. If you have the opportunity to do so,
the best choice for you would be to go through the normal WR support
channels with full details of your problem.
At a glance, it looks like you are trying to build with ARCH=powerpc, and
yet I don't think (from memory) that the 4xx boards had migrated from
ARCH=ppc until sometime around the 2.6.24-ish timeframe.
Paul.
> I just built the file system by running the configure command with
> --enable-rootfs=glibc-small and --enable-cpu-ppc-440 and i got a cross
> compiler.
> I took the linux kernel image and updated the PATH variable to the path of
> my cross compiler.I did a make with ARCH=powerpc and CROSS_COMPILER=/my
> cross compiler,except gcc/.
>
> When I try to do this I get the following error.
> arch/powerpc/mm/44x_mmu.c: In function 'mmu_mapin_ram':
> arch/powerpc/mm/44x_mmu.c:106: error: 'PPC_PIN_SIZE' undeclared (first use
> in this function)
> arch/powerpc/mm/44x_mmu.c:106: error: (Each undeclared identifier is
> reported only once
> arch/powerpc/mm/44x_mmu.c:106: error: for each function it appears in.)
> arch/powerpc/mm/44x_mmu.c:106: error: 'PPC44x_PIN_SHIFT' undeclared (first
> use in this function)
> arch/powerpc/mm/44x_mmu.c:109: error: 'PPC44x_LOW_SLOT' undeclared (first
> use in this function)
> make[1]: *** [arch/powerpc/mm/44x_mmu.o] Error 1
> make: *** [arch/powerpc/mm] Error 2
> It ll be very helpful for me if I could get a solution for this.
>
> Regards
> Sridhar M
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Dipankar Sarma @ 2009-08-11 17:53 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Pavel Machek,
Li, Shaohua, Ingo Molnar, linuxppc-dev@lists.ozlabs.org,
Darrick J. Wong
In-Reply-To: <1249950137.11545.38184.camel@localhost.localdomain>
On Mon, Aug 10, 2009 at 05:22:17PM -0700, Pallipadi, Venkatesh wrote:
> Also, I don't think using just the ACPI/BIOS supplied states in _CST is
> right thing to do for offline. _CST is meant for C-state and BIOS may
> not include some C-state in _CST if the system manufacturer thinks that
> the latency is too high for the state to be used as a C-state. That
> limitation applies for C-state as the cpu is expected to come out of
> C-state often and execute code handle interrupts etc. But, that
> restriction does not apply for offline online which is not as frequent
> as C-state entry and it already has big latency with startup IPI, and a
> whole baggage of CPU setup code. So, using BIOS CST info for CPU offline
> state doesn't seem right.
>
> May be having (to pick a number) 3 possible offline states for all
> platforms with one for halt equivalent and one for deepest possible that
> CPU can handle and one for deepest possible that platform likes for
> C-states may make sense. Will keeps things simpler in terms of usage
> expectations and possibly reduce the misuse oppurtubity?
Yes, I think we should let specific archs advertise a small set
of possible offline states and let the cpu state be set to one of
those only keeping the platform implementation robust.
Here is variant of the original proposal from Gautham -
/sys/devices/system/cpu/cpu<number>/available_states
For example, available state for an Intel platform could be exported as
"online dealloc C1 C6"
online = fully up
dealloc = offline and de-allocated (as in virtualized environment)
C1 = C1 or C1E halt
C6 = C6 sleep
/sys/devices/system/cpu/cpu<number>/state
Writing any of the available states to this file triggers transition to that
state barring some transitions that are disallowed to keep things simple
(e.g. dealloc cpus support only transition to online).
/sys/devices/system/cpu/cpu<number>/online
Backward compatibility - online = 0 changes state to C6 or dealloc depending
on the platform. online = 1 changes state to online.
Would this make sense ?
Thanks
Dipankar
^ permalink raw reply
* Re: need help getting SPI controller working on 405EX
From: Stefan Roese @ 2009-08-11 16:11 UTC (permalink / raw)
To: Nathan French
Cc: linuxppc-dev@ozlabs.org, linuxppc-dev@lists.ozlabs.org,
Lorenz Kolb
In-Reply-To: <1250006366.3747.8595.camel@localhost.localdomain>
On Tuesday 11 August 2009 17:59:26 Nathan French wrote:
> This is good news. Can you point me towards the patch for that?
Sure. Latest version is: "[PATCH v8] spi: Add PPC4xx SPI driver":
http://article.gmane.org/gmane.linux.ports.ppc64.devel/57940
Best regards,
Stefan
^ permalink raw reply
* Re: need help getting SPI controller working on 405EX
From: Nathan French @ 2009-08-11 15:59 UTC (permalink / raw)
To: Stefan Roese
Cc: linuxppc-dev@ozlabs.org, linuxppc-dev@lists.ozlabs.org,
Lorenz Kolb
In-Reply-To: <200908110744.52394.sr@denx.de>
This is good news. Can you point me towards the patch for that?
Nathan
On Tue, 2009-08-11 at 01:44 -0400, Stefan Roese wrote:
> On Monday 10 August 2009 18:07:15 Nathan French wrote:
> > > At least something similar worked for me some months ago (before we
> > > switched to a "real" driver for some custom peripheral).
> >
> > Did this work on a 4xx PowerPC platform? Or something else? I've been
> > told that there is no SPI driver for 4xx. If you have done this on 4xx
> > then I'm very interested.
>
> The 4xx SPI driver is (finally) queued for 2.6.32. So you either need to
> manually apply it now or wait a while.
>
> Best regards,
> Stefan
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Workaround MPC8536 GPIO 1 errata.
From: Anton Vorontsov @ 2009-08-11 15:24 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <4A818A4C.8060502@embedded-sol.com>
On Tue, Aug 11, 2009 at 06:12:12PM +0300, Felix Radensky wrote:
[...]
> >Plus, this are two reads instead of just one. I think it'll be better
> >to implement mpc8536_gpio_get(), and then do
> >
> >if (of_device_is_compatible(np, ... 8536-gpio-bank ...))
> > gc->get = mpc8536_gpio_get;
> >else
> > gc->get = mpc8xxx_gpio_get;
>
> The reads are from 2 different registers, how do you propose to replace
> them by a single read ?
I didn't propose that, I proposed to not do 2 reads for CPUs that
don't have the errata. ;-)
> I'll implement mpc8572_gpio_get(), suitable for both 8572 and 8536.
Great, thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Workaround MPC8536 GPIO 1 errata.
From: Felix Radensky @ 2009-08-11 15:12 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090811134450.GA9820@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Tue, Aug 11, 2009 at 12:04:18PM +0300, Felix Radensky wrote:
>> On MPC8536 Rev 1.0 the status of GPIO pins configured
>> as output cannot be determined by reading GPDAT register.
>> Workaround by reading the status of input pins from GPDAT
>> and the status of output pins from a shadow register.
>>
>> Signed-off-by: Felix Radensky <felix@embedded-sol.com>
>> ---
>> arch/powerpc/sysdev/mpc8xxx_gpio.c | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
>> index 103eace..0b996f3 100644
>> --- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
>> +++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
>> @@ -56,9 +56,13 @@ static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip *mm)
>>
>> static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
>> {
>> + u32 val;
>> struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
>> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
>> +
>> + val = in_be32(mm->regs + GPIO_DAT) && ~in_be32(mm->regs + GPIO_DIR);
>
> Are you sure about &&?
No, that's obviously a typo. Bitwise & intended.
>
> Plus, this are two reads instead of just one. I think it'll be better
> to implement mpc8536_gpio_get(), and then do
>
> if (of_device_is_compatible(np, ... 8536-gpio-bank ...))
> gc->get = mpc8536_gpio_get;
> else
> gc->get = mpc8xxx_gpio_get;
The reads are from 2 different registers, how do you propose to replace
them by a single read ?
I'll implement mpc8572_gpio_get(), suitable for both 8572 and 8536.
>
>> - return in_be32(mm->regs + GPIO_DAT) & mpc8xxx_gpio2mask(gpio);
>> + return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
>> }
>>
>> static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
>
> Thanks,
>
^ permalink raw reply
* cross compiling wind river linux for ppc architecture
From: Sridhar Mahadevan @ 2009-08-11 14:09 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
Hi,
Am trying to compile my WRL 2.6.21 kernel for PPC architecture.
The processor am using is AMCC powerpc 440EP .
I just built the file system by running the configure command with
--enable-rootfs=glibc-small and --enable-cpu-ppc-440 and i got a cross
compiler.
I took the linux kernel image and updated the PATH variable to the path of
my cross compiler.I did a make with ARCH=powerpc and CROSS_COMPILER=/my
cross compiler,except gcc/.
When I try to do this I get the following error.
arch/powerpc/mm/44x_mmu.c: In function 'mmu_mapin_ram':
arch/powerpc/mm/44x_mmu.c:106: error: 'PPC_PIN_SIZE' undeclared (first use
in this function)
arch/powerpc/mm/44x_mmu.c:106: error: (Each undeclared identifier is
reported only once
arch/powerpc/mm/44x_mmu.c:106: error: for each function it appears in.)
arch/powerpc/mm/44x_mmu.c:106: error: 'PPC44x_PIN_SHIFT' undeclared (first
use in this function)
arch/powerpc/mm/44x_mmu.c:109: error: 'PPC44x_LOW_SLOT' undeclared (first
use in this function)
make[1]: *** [arch/powerpc/mm/44x_mmu.o] Error 1
make: *** [arch/powerpc/mm] Error 2
It ll be very helpful for me if I could get a solution for this.
Regards
Sridhar M
[-- Attachment #2: Type: text/html, Size: 1754 bytes --]
^ permalink raw reply
* RE: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
From: Aggrwal Poonam-B10812 @ 2009-08-11 14:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <BAFDE07A-DC01-46A5-A36E-7F8FB508CBFD@kernel.crashing.org>
=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Tuesday, August 11, 2009 7:11 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
>=20
>=20
> On Aug 7, 2009, at 10:35 AM, Poonam Aggrwal wrote:
>=20
> >
> > + enet2: ethernet@26000 {
> > + #address-cells =3D <1>;
> > + #size-cells =3D <1>;
> > + cell-index =3D <2>;
> > + device_type =3D "network";
> > + model =3D "eTSEC";
> > + compatible =3D "gianfar";
> > + reg =3D <0x26000 0x1000>;
> > + ranges =3D <0x0 0x26000 0x1000>;
> > + local-mac-address =3D [ 00 00 00 00 00 00 ];
> > + interrupts =3D <31 2 32 2 33 2>;
> > + interrupt-parent =3D <&mpic>;
> > + phy-handle =3D <&phy1>;
> > + phy-connection-type =3D "rgmii-id";
> > + };
>=20
> was there an answer to why we don't have an mdio node for enet2?
>=20
Yes I already replied to it, actually the enet2 (eTSEC3) on RDB is only
exposed as RGMII, and the mdio lines it will use is those of enet0. In
case it also could be configured in SGMII(as in P2020DS), then we would
have needed the mdio node for enet2 to configure the TBI PHY.=20
> - k
>=20
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Workaround MPC8536 GPIO 1 errata.
From: Kumar Gala @ 2009-08-11 13:57 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Felix Radensky
In-Reply-To: <20090811134450.GA9820@oksana.dev.rtsoft.ru>
On Aug 11, 2009, at 8:44 AM, Anton Vorontsov wrote:
> On Tue, Aug 11, 2009 at 12:04:18PM +0300, Felix Radensky wrote:
>> On MPC8536 Rev 1.0 the status of GPIO pins configured
>> as output cannot be determined by reading GPDAT register.
>> Workaround by reading the status of input pins from GPDAT
>> and the status of output pins from a shadow register.
>>
>> Signed-off-by: Felix Radensky <felix@embedded-sol.com>
>> ---
>> arch/powerpc/sysdev/mpc8xxx_gpio.c | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/
>> sysdev/mpc8xxx_gpio.c
>> index 103eace..0b996f3 100644
>> --- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
>> +++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
>> @@ -56,9 +56,13 @@ static void mpc8xxx_gpio_save_regs(struct
>> of_mm_gpio_chip *mm)
>>
>> static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
>> {
>> + u32 val;
>> struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
>> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
>> +
>> + val = in_be32(mm->regs + GPIO_DAT) && ~in_be32(mm->regs +
>> GPIO_DIR);
>
> Are you sure about &&?
>
> Plus, this are two reads instead of just one. I think it'll be better
> to implement mpc8536_gpio_get(), and then do
>
> if (of_device_is_compatible(np, ... 8536-gpio-bank ...))
> gc->get = mpc8536_gpio_get;
> else
> gc->get = mpc8xxx_gpio_get;
I think 8572 has the same errata.
>
>> - return in_be32(mm->regs + GPIO_DAT) & mpc8xxx_gpio2mask(gpio);
>> + return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
>> }
>>
>> static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int
>> gpio, int val)
>
> Thanks,
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox