* Re: Xilinx FX60
From: Grant Likely @ 2007-09-18 21:02 UTC (permalink / raw)
To: Robert Woodworth; +Cc: linuxppc-embedded
In-Reply-To: <1190149090.7268.29.camel@PisteOff>
On 9/18/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> I'm back trying to get the kernel on my Xilinx FX60 without success.
> Now I have more information:
>
> Using the Xilinx GDB, I'm getting either a "Bad Page fault exception" or
> a kernel "oops"
>
> The text in the _log_buf is as follows:
> (this happens before serial console init)
>
> Data machine check in kernel mode..
> Oops: machine check, sig: 7 [#1].
> <register dump>
>
>
>
> Any Ideas what would cause this? Memory problem?
> I've run several different embedded memory test programs on the PPC and
> they all pass fine.
You might still be having memory issues. Memory tests in general
don't hit memory as hard and fast as running code with caches enabled.
>
> I've synthesized my FX60 with the exact same memory map as my FX12 on
> the ML403 and used the same kernel config. ML403 works great.
>
> The only difference is that the FX60 board only has 32MB DDR, I have
> made sure that the correct memory size is in the kernel.
How are you booting your kernel? .ace? u-boot? load via debugger?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 03/28] Document local bus nodes in the device tree, and update cuboot-pq2.
From: Scott Wood @ 2007-09-18 21:01 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The /localbus node is used to describe devices that are connected via a chip
select or similar mechanism. The advantages over placing the devices under
the root node are that it can be probed without probing other random things
under the root, and that the description of which chip select a given device
uses can be used to set up mappings if the firmware failed to do so in a
useful manner.
cuboot-pq2 is updated to match the binding; previously, it called itself
chipselect rather than localbus, and used phandle linkage between the
actual bus node and the control node (the current agreement is to simply use
the fully-qualified address of the control registers, and ignore the overlap
with the IMMR node).
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Resent with a better commit message.
Documentation/powerpc/booting-without-of.txt | 38 ++++++++++++++++++++++++++
arch/powerpc/boot/cuboot-pq2.c | 29 +++++--------------
2 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index a599f1a..42cbfb0 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2017,6 +2017,44 @@ platforms are moved over to use the flattened-device-tree model.
fsl,cpm-command = <2e600000>;
};
+ m) Chipselect/Local Bus
+
+ Properties:
+ - name : Should be localbus
+ - #address-cells : Should be either two or three. The first cell is the
+ chipselect number, and the remaining cells are the
+ offset into the chipselect.
+ - #size-cells : Either one or two, depending on how large each chipselect
+ can be.
+ - ranges : Each range should correspond to a single chipselect, and cover
+ the entire access window as configured.
+
+ Example:
+ localbus@f0010100 {
+ compatible = "fsl,mpc8272ads-localbus",
+ "fsl,mpc8272-localbus",
+ "fsl,pq2-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <f0010100 40>;
+
+ ranges = <0 0 fe000000 02000000
+ 1 0 f4500000 00008000>;
+
+ flash@0,0 {
+ compatible = "jedec-flash";
+ reg = <0 0 2000000>;
+ bank-width = <4>;
+ device-width = <1>;
+ };
+
+ board-control@1,0 {
+ reg = <1 0 20>;
+ compatible = "fsl,mpc8272ads-bcsr";
+ };
+ };
+
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
diff --git a/arch/powerpc/boot/cuboot-pq2.c b/arch/powerpc/boot/cuboot-pq2.c
index b150bd4..e5d94ff 100644
--- a/arch/powerpc/boot/cuboot-pq2.c
+++ b/arch/powerpc/boot/cuboot-pq2.c
@@ -43,22 +43,21 @@ struct pci_range pci_ranges_buf[MAX_PROP_LEN / sizeof(struct pci_range)];
* some don't set up the PCI PIC at all, so we assume the device tree is
* sane and update the BRx registers appropriately.
*
- * For any node defined as compatible with fsl,pq2-chipselect,
- * #address/#size must be 2/1 for chipselect bus, 1/1 for parent bus,
- * and ranges must be for whole chip selects.
+ * For any node defined as compatible with fsl,pq2-localbus,
+ * #address/#size must be 2/1 for the localbus, and 1/1 for the parent bus.
+ * Ranges must be for whole chip selects.
*/
static void update_cs_ranges(void)
{
- u32 ctrl_ph;
- void *ctrl_node, *bus_node, *parent_node;
+ void *bus_node, *parent_node;
u32 *ctrl_addr;
unsigned long ctrl_size;
u32 naddr, nsize;
int len;
int i;
- bus_node = finddevice("/chipselect");
- if (!bus_node || !dt_is_compatible(bus_node, "fsl,pq2-chipselect"))
+ bus_node = finddevice("/localbus");
+ if (!bus_node || !dt_is_compatible(bus_node, "fsl,pq2-localbus"))
return;
dt_get_reg_format(bus_node, &naddr, &nsize);
@@ -73,19 +72,7 @@ static void update_cs_ranges(void)
if (naddr != 1 || nsize != 1)
goto err;
- len = getprop(bus_node, "fsl,ctrl", &ctrl_ph, 4);
- if (len != 4)
- goto err;
-
- ctrl_node = find_node_by_prop_value(NULL, "linux,phandle",
- (char *)&ctrl_ph, 4);
- if (!ctrl_node)
- goto err;
-
- if (!dt_is_compatible(ctrl_node, "fsl,pq2-chipselect-ctrl"))
- goto err;
-
- if (!dt_xlate_reg(ctrl_node, 0, (unsigned long *)&ctrl_addr,
+ if (!dt_xlate_reg(bus_node, 0, (unsigned long *)&ctrl_addr,
&ctrl_size))
goto err;
@@ -122,7 +109,7 @@ static void update_cs_ranges(void)
return;
err:
- printf("Bad /chipselect or fsl,pq2-chipselect-ctrl node\r\n");
+ printf("Bad /localbus node\r\n");
}
/* Older u-boots don't set PCI up properly. Update the hardware to match
--
1.5.3.1
^ permalink raw reply related
* Xilinx FX60
From: Robert Woodworth @ 2007-09-18 20:58 UTC (permalink / raw)
To: linuxppc-embedded
I'm back trying to get the kernel on my Xilinx FX60 without success.
Now I have more information:
Using the Xilinx GDB, I'm getting either a "Bad Page fault exception" or
a kernel "oops"
The text in the _log_buf is as follows:
(this happens before serial console init)
Data machine check in kernel mode..
Oops: machine check, sig: 7 [#1].
<register dump>
Any Ideas what would cause this? Memory problem?
I've run several different embedded memory test programs on the PPC and
they all pass fine.
I've synthesized my FX60 with the exact same memory map as my FX12 on
the ML403 and used the same kernel config. ML403 works great.
The only difference is that the FX60 board only has 32MB DDR, I have
made sure that the correct memory size is in the kernel.
??
RJW
^ permalink raw reply
* device tree question
From: Alan Bennett @ 2007-09-18 20:43 UTC (permalink / raw)
To: linuxppc-embedded
I want to make the mpc8272ads.dts tree work for my board.
I have an mpc8248
128MB Flash@ f800_0000 (Spansion S29GL512N)
128MB Flash@ D000_0000 (Spansion S29GL512N)
BCSR@e400_0000
2nd CSR@e410_0000
RAM@e420_0000
128MB SDRAM@[0x0..0800_0000]
Is it ok to have 0 in these:
cpus {
PowerPC,8272@0 {
. . .
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
. . .
How do I modify the following lines to match my hardware?
localbus@f0010100 {
. . .
ranges = <0 0 fe000000 02000000
1 0 f4500000 00008000
3 0 f8200000 00008000>;
flash@0,0 {
compatible = "jedec-flash";
reg = <0 0 2000000>;
bank-width = <4>;
device-width = <1>;
};
board-control@1,0 {
reg = <1 0 20>;
compatible = "fsl,mpc8272ads-bcsr";
};
. . .
====FULL MPC8278ads.dts
/*
* MPC8272 ADS Device Tree Source
*
* Copyright 2005 Freescale Semiconductor 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.
*/
/ {
model = "MPC8272ADS";
compatible = "fsl,mpc8272ads";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8272@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <d#32>;
i-cache-line-size = <d#32>;
d-cache-size = <d#16384>;
i-cache-size = <d#16384>;
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <0 0>;
};
localbus@f0010100 {
compatible = "fsl,mpc8272-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 40>;
ranges = <0 0 fe000000 02000000
1 0 f4500000 00008000
3 0 f8200000 00008000>;
flash@0,0 {
compatible = "jedec-flash";
reg = <0 0 2000000>;
bank-width = <4>;
device-width = <1>;
};
board-control@1,0 {
reg = <1 0 20>;
compatible = "fsl,mpc8272ads-bcsr";
};
PCI_PIC: interrupt-controller@3,0 {
compatible = "fsl,mpc8272ads-pci-pic",
"fsl,pq2ads-pci-pic";
#interrupt-cells = <1>;
interrupt-controller;
reg = <3 0 8>;
interrupt-parent = <&PIC>;
interrupts = <14 8>;
};
};
pci@f0010800 {
device_type = "pci";
reg = <f0010800 10c f00101ac 8 f00101c4 8>;
compatible = "fsl,mpc8272-pci", "fsl,pq2-pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
clock-frequency = <d#66666666>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x16 */
b000 0 0 1 &PCI_PIC 0
b000 0 0 2 &PCI_PIC 1
b000 0 0 3 &PCI_PIC 2
b000 0 0 4 &PCI_PIC 3
/* IDSEL 0x17 */
b800 0 0 1 &PCI_PIC 4
b800 0 0 2 &PCI_PIC 5
b800 0 0 3 &PCI_PIC 6
b800 0 0 4 &PCI_PIC 7
/* IDSEL 0x18 */
c000 0 0 1 &PCI_PIC 8
c000 0 0 2 &PCI_PIC 9
c000 0 0 3 &PCI_PIC a
c000 0 0 4 &PCI_PIC b>;
interrupt-parent = <&PIC>;
interrupts = <12 8>;
ranges = <42000000 0 80000000 80000000 0 20000000
02000000 0 a0000000 a0000000 0 20000000
01000000 0 00000000 f6000000 0 02000000>;
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
ranges = <00000000 f0000000 00053000>;
// Temporary -- will go away once kernel uses ranges for get_immrbase().
reg = <f0000000 00053000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <119c0 30 0 2000>;
ranges;
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};
serial@11a60 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a60 20 8300 100>;
interrupts = <2b 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0ce00000>;
};
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
PHY0: ethernet-phy@0 {
interrupt-parent = <&PIC>;
interrupts = <17 8>;
reg = <0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-phy@1 {
interrupt-parent = <&PIC>;
interrupts = <17 8>;
reg = <3>;
device_type = "ethernet-phy";
};
};
ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100 11390 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <21 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <16200300>;
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
};
/* May need to remove if on a part without crypto engine */
crypto@30000 {
device_type = "crypto";
model = "SEC2";
compatible = "fsl,mpc8272-talitos-sec2",
"fsl,talitos-sec2",
"fsl,talitos",
"talitos";
reg = <30000 10000>;
interrupts = <b 8>;
interrupt-parent = <&PIC>;
num-channels = <4>;
channel-fifo-len = <18>;
exec-units-mask = <0000007e>;
/* desc mask is for rev1.x, we need runtime fixup for >=2.x */
descriptor-types-mask = <01010ebf>;
};
};
chosen {
linux,stdout-path = "/soc/cpm/serial@11a00";
};
};
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Jon Smirl @ 2007-09-18 19:29 UTC (permalink / raw)
To: Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20070918151622.GD32628@nd47.coderock.org>
On 9/18/07, Domen Puncer <domen@coderock.org> wrote:
> More testing and getting it to work properly on Phytec pcm030 would
> be great.
Do we want to do anything about this?
[ 1.569657] net eth0: attached phy 0 to driver Generic PHY
[ 2.576013] Sending DHCP requests .<6>PHY: f0003000:00 - Link is Up
- 100/Full
[ 4.612000] ., OK
[ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my
address is 192.168.1.5
What is happening is the printk for "<6>PHY: f0003000:00 - Link is Up
- 100/Full" is done in an interrupt and it comes in the middle of the
kernel doing DHCP and printing ... without a CR.
Two possible solutions, get rid of the link-up message or wait in in
the initial driver load until the link is up. Or we could leave it the
way it is, but some people may report this as a bug.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Jon Smirl @ 2007-09-18 19:17 UTC (permalink / raw)
To: Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20070918151622.GD32628@nd47.coderock.org>
On 9/18/07, Domen Puncer <domen@coderock.org> wrote:
> More testing and getting it to work properly on Phytec pcm030 would
> be great.
I compiled it as a module:
CC [M] drivers/net/fec_mpc52xx/fec.o
drivers/net/fec_mpc52xx/fec.c:613: warning: 'mpc52xx_fec_mac_setup'
defined but not used
This code needs to be enclosed in "#ifndef MODULE". But why aren't you
using module_param() to make a string parameter and then copy it into
mpc52xx_fec_mac_addr[] if the parameter is not null?
If it is a module param you need to use
fec_mpc52xx_phy.mpc52xx-mac="xxxx" instead of just mpc52xx-mac. The
way it is not you can't use mpc52xx-mac when built as a module.
static int __init mpc52xx_fec_mac_setup(char *mac_address)
{
int i;
u64 val64;
val64 = simple_strtoull(mac_address, NULL, 16);
for (i = 0; i < 6; i++)
mpc52xx_fec_mac_addr[5-i] = val64 >> (i*8);
return 0;
}
__setup("mpc52xx-mac=", mpc52xx_fec_mac_setup);
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: 2.6.23-rc6-mm1
From: Greg KH @ 2007-09-18 19:16 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <46EFBF9E.6060208@linux.vnet.ibm.com>
On Tue, Sep 18, 2007 at 05:37:58PM +0530, Kamalesh Babulal wrote:
> Benjamin Herrenschmidt wrote:
>> On Tue, 2007-09-18 at 10:34 +0100, Andy Whitcroft wrote:
>>
>>> On Tue, Sep 18, 2007 at 02:43:48PM +0530, Kamalesh Babulal wrote:
>>>
>>>> Andrew Morton wrote:
>>>>
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
>>>>>
>>>>> 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
>>>>>
>>>>>
>>>> <snip>
>>>>
>>>> Hi Andrew,
>>>>
>>>> The 2.6.23-rc6-mm1build fails at
>>>>
>>>> CC drivers/pci/hotplug/rpadlpar_core.o
>>>> CC drivers/pci/hotplug/rpadlpar_sysfs.o
>>>> drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
>>>> specified in initializer
>>>> drivers/pci/hotplug/rpadlpar_sysfs.c: In function `dlpar_sysfs_init':
>>>> drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member
>>>> named `name'
>>>> make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
>>>> make[2]: *** [drivers/pci/hotplug] Error 2
>>>> make[1]: *** [drivers/pci] Error 2
>>>> make: *** [drivers] Error 2
>>>>
>>> This seems to be occuring across a number of the powerpc systems we test
>>> with. That driver is a power dynamic lpar IO partitioning driver.
>>>
>>> Relevant Cc: added.
>>>
>>
>> That's because somebody is breaking sysfs/kobject interfaces without
>> fixing all users :-) (Fair enough... it's just that we need to make sure
>> whoever takes care of that driver nowadays is aware of the breakage).
>>
>> Ben.
>>
> Hi Andrew,
>
> Using the kobject_set_name function to set the kobject k_name.
Close, you should also use the kobject_name() function when referencing
it.
I'll fix this up in the patch, thanks.
Oh, and sorry for breaking this, I could only test all of the modules
build on x86 due to traveling while creating this patch. I need to set
up some cross-compilers on my laptop to fix this issue :(
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Vitaly Bordug @ 2007-09-18 18:18 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070918160754.GA22698@ru.mvista.com>
Hello Valentine,
On Tue, 18 Sep 2007 20:07:54 +0400
Valentine Barshak wrote:
> Currently pci_32 doesn't support 64-bit physical addresses, while
> PowerPC440 platform has PCI space typically mapped above 4GB range.
> The patch adds 64-bit physical address support to 32-bit PCI code
> in order to bring-up PCI on 44x platform.
>
The approach looks interesting, and resource_size_t<>ulong apparently makes sense,
but I would strongly disagree we need to add more nuts and bolts into ranges parse func:
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
[...]
> void __init
> pci_process_bridge_OF_ranges(struct pci_controller *hose,
> struct device_node *dev, int primary)
> {
> static unsigned int static_lc_ranges[256] __initdata;
> const unsigned int *dt_ranges;
> - unsigned int *lc_ranges, *ranges, *prev, size;
> + unsigned int *lc_ranges, *ranges, *prev;
> int rlen = 0, orig_rlen;
> int memno = 0;
> struct resource *res;
> + u32 prev_pci_space, pci_space;
> + u64 prev_pci_addr, pci_addr;
> + u64 prev_size, size;
> + phys_addr_t cpu_phys_addr;
> +
> int np, na = of_n_addr_cells(dev);
> np = na + 5;
>
> @@ -879,11 +891,18 @@
> prev = NULL;
> while ((rlen -= np * sizeof(unsigned int)) >= 0) {
> if (prev) {
> - if (prev[0] == ranges[0] && prev[1] == ranges[1] &&
> - (prev[2] + prev[na+4]) == ranges[2] &&
> - (prev[na+2] + prev[na+4]) == ranges[na+2]) {
> - prev[na+4] += ranges[na+4];
> + prev_pci_space = prev[0];
> + prev_pci_addr = pci_get_range64(&prev[1]);
> + prev_size = pci_get_range64(&prev[na+3]);
> + pci_space = ranges[0];
> + pci_addr = pci_get_range64(&ranges[1]);
> + if ((prev_pci_space == pci_space) &&
> + ((prev_pci_addr + prev_size) == pci_addr)) {
> + size = pci_get_range64(&ranges[na+3]);
> + prev_size += size;
> ranges[0] = 0;
> + prev[na+3] = (u32)((prev_size >> 32) & 0xffffffff);
> + prev[na+4] = (u32)(prev_size & 0xffffffff);
> ranges += np;
> continue;
I do think that ranges hacking (even on a copy) to cope with contiguous ranges is not a good deed. And nobody would object the upper looks horrible from the maintenance POV.
> }
> @@ -904,21 +923,22 @@
> rlen = orig_rlen;
> while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
> res = NULL;
> - size = ranges[na+4];
> - switch ((ranges[0] >> 24) & 0x3) {
> + size = pci_get_range64(&ranges[na+3]);
This is not correct - it should depend on #ac of the parent node.
But I'll stop right here - there is no deep mutual difference between 32 & 64 bit so that to keep 2 similar implementations, none of which (esp 32bit) really comply the spec. It should work the same way, and, if there are differences, they should be handled
explicitly, and, of course, reconsidered if they make sense (like isa_io_base, absense of io_size in ppc32 and so on)
I am *not* telling here that my implementation is the only true way around. But we need to improve and make code cleaner rather then just extend existing error-prone approach.
--
Sincerely, Vitaly
^ permalink raw reply
* [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries.
From: Valentine Barshak @ 2007-09-18 17:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070918172510.GA30944@ru.mvista.com>
According to PowerPC 440EPx documentation,
MAL0 is comprised of four channels (two transmit and two receive).
Each channel is dedicated to one of two EMAC cores.
This patch fixes Sequoia DTS MAL0 entry and EMAC entries,
assigning correct channel numbers to EMACs.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/dts/sequoia.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-09-18 15:32:18.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-09-18 21:11:00.000000000 +0400
@@ -107,8 +107,8 @@
MAL0: mcmal {
compatible = "ibm,mcmal-440epx", "ibm,mcmal2";
dcr-reg = <180 62>;
- num-tx-chans = <4>;
- num-rx-chans = <4>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
interrupt-parent = <&MAL0>;
interrupts = <0 1 2 3 4>;
#interrupt-cells = <1>;
@@ -239,7 +239,7 @@
reg = <ef600e00 70>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
- mal-tx-channel = <0 1>;
+ mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <5dc>;
@@ -265,7 +265,7 @@
reg = <ef600f00 70>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
- mal-tx-channel = <2 3>;
+ mal-tx-channel = <1>;
mal-rx-channel = <1>;
cell-index = <1>;
max-frame-size = <5dc>;
^ permalink raw reply
* [PATCH 1/2] PowerPC: Fix Bamboo MAL0 dts entry.
From: Valentine Barshak @ 2007-09-18 17:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070918172510.GA30944@ru.mvista.com>
According to PowerPC 440EP documentation,
MAL0 consists of 6 channels (4 transmit channels and 2 receive channels)
This patch fixes Bamboo DTS MAL0 "num-rx-chans" entry.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/dts/bamboo.dts | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -ruN linux-2.6.orig/arch/powerpc/boot/dts/bamboo.dts linux-2.6/arch/powerpc/boot/dts/bamboo.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/bamboo.dts 2007-09-18 15:32:18.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts 2007-09-18 21:08:55.000000000 +0400
@@ -94,7 +94,7 @@
compatible = "ibm,mcmal-440ep", "ibm,mcmal-440gp", "ibm,mcmal";
dcr-reg = <180 62>;
num-tx-chans = <4>;
- num-rx-chans = <4>;
+ num-rx-chans = <2>;
interrupt-parent = <&MAL0>;
interrupts = <0 1 2 3 4>;
#interrupt-cells = <1>;
^ permalink raw reply
* [PATCH 0/2] PowerPC: Fix MAL0 DTS entries for Bamboo and Sequoia.
From: Valentine Barshak @ 2007-09-18 17:25 UTC (permalink / raw)
To: linuxppc-dev
A couple of minor fixes to correct MAL0 DTS entries for bamboo.dts and sequoia.dts.
Also correct MAL channel assignment for EMACs on Sequoia board.
^ permalink raw reply
* Re: 2.6.23-rc6-mm1
From: Andrew Morton @ 2007-09-18 16:53 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: Benjamin, linuxppc-dev, linux-kernel
In-Reply-To: <46EFBF9E.6060208@linux.vnet.ibm.com>
On Tue, 18 Sep 2007 17:37:58 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2007-09-18 at 10:34 +0100, Andy Whitcroft wrote:
> >
> >> On Tue, Sep 18, 2007 at 02:43:48PM +0530, Kamalesh Babulal wrote:
> >>
> >>> Andrew Morton wrote:
> >>>
> >>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >>>>
> >>>> 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
> >>>>
> >>>>
> >>>>
> >>> <snip>
> >>>
> >>> Hi Andrew,
> >>>
> >>> The 2.6.23-rc6-mm1build fails at
> >>>
> >>> CC drivers/pci/hotplug/rpadlpar_core.o
> >>> CC drivers/pci/hotplug/rpadlpar_sysfs.o
> >>> drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
> >>> specified in initializer
> >>> drivers/pci/hotplug/rpadlpar_sysfs.c: In function `dlpar_sysfs_init':
> >>> drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member
> >>> named `name'
> >>> make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> >>> make[2]: *** [drivers/pci/hotplug] Error 2
> >>> make[1]: *** [drivers/pci] Error 2
> >>> make: *** [drivers] Error 2
> >>>
> >> This seems to be occuring across a number of the powerpc systems we test
> >> with. That driver is a power dynamic lpar IO partitioning driver.
> >>
> >> Relevant Cc: added.
> >>
> >
> > That's because somebody is breaking sysfs/kobject interfaces without
> > fixing all users :-) (Fair enough... it's just that we need to make sure
> > whoever takes care of that driver nowadays is aware of the breakage).
> >
> > Ben.
> >
> Hi Andrew,
>
> Using the kobject_set_name function to set the kobject k_name.
>
> Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> ---
> --- linux-2.6.23-rc6/drivers/pci/hotplug/rpadlpar_sysfs.c
> 2007-09-18 14:56:05.000000000 +0530
> +++ linux-2.6.23-rc6/drivers/pci/hotplug/~rpadlpar_sysfs.c
> 2007-09-18 16:51:55.000000000 +0530
> @@ -129,17 +129,17 @@ struct kobj_type ktype_dlpar_io = {
> };
>
> struct kset dlpar_io_kset = {
> - .kobj = {.name = DLPAR_KOBJ_NAME,
> - .ktype = &ktype_dlpar_io,
> - .parent = &pci_hotplug_slots_subsys.kobj},
> + .kobj = {.ktype = &ktype_dlpar_io,
> + .parent = &pci_hotplug_slots_subsys.kobj},
> .ktype = &ktype_dlpar_io,
> };
>
> int dlpar_sysfs_init(void)
> {
> + kobject_set_name(&dlpar_io_kset.kobj, DLPAR_KOBJ_NAME);
> if (kset_register(&dlpar_io_kset)) {
> printk(KERN_ERR "rpadlpar_io: cannot register kset for
> %s\n",
> - dlpar_io_kset.kobj.name);
> + dlpar_io_kset.kobj.k_name);
> return -EINVAL;
> }
>
Thanks.
Your email client replaces tabs with spaces, and is performing wordwrapping.
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-09-18 16:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070918152302.GB788@ld0162-tx32.am.freescale.net>
On Sep 18, 2007, at 10:23 AM, Scott Wood wrote:
> On Tue, Sep 18, 2007 at 10:19:05AM -0500, Kumar Gala wrote:
>> Mainly that 8xx has been doing this for a vast number of years and I
>> see no reason to stop doing it at this point.
>>
>> While I can see that it might be misleading, clearly 8xx linux users
>> haven't had issues with it.
>
> Or they haven't said anything. :-P
:)
> How about a three-way choice of full emulation, minimal emulation,
> and no
> emulation?
I think I'd be ok with that.
- k
^ permalink raw reply
* [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Valentine Barshak @ 2007-09-18 16:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <DF9456FB-459D-4800-B994-D9B198096069@kernel.crashing.org>
Currently pci_32 doesn't support 64-bit physical addresses, while
PowerPC440 platform has PCI space typically mapped above 4GB range.
The patch adds 64-bit physical address support to 32-bit PCI code
in order to bring-up PCI on 44x platform.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/kernel/iomap.c | 4 +--
arch/powerpc/kernel/pci_32.c | 56 +++++++++++++++++++++++++++++--------------
2 files changed, 41 insertions(+), 19 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/iomap.c linux-2.6/arch/powerpc/kernel/iomap.c
--- linux-2.6.orig/arch/powerpc/kernel/iomap.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/iomap.c 2007-09-18 17:26:35.000000000 +0400
@@ -119,8 +119,8 @@
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
{
- unsigned long start = pci_resource_start(dev, bar);
- unsigned long len = pci_resource_len(dev, bar);
+ resource_size_t start = pci_resource_start(dev, bar);
+ resource_size_t len = pci_resource_len(dev, bar);
unsigned long flags = pci_resource_flags(dev, bar);
if (!len)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/pci_32.c linux-2.6/arch/powerpc/kernel/pci_32.c
--- linux-2.6.orig/arch/powerpc/kernel/pci_32.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/pci_32.c 2007-09-18 18:17:00.000000000 +0400
@@ -105,7 +105,7 @@
{
struct pci_controller* hose = (struct pci_controller *)dev->sysdata;
int i;
- unsigned long offset;
+ resource_size_t offset;
if (!hose) {
printk(KERN_ERR "No hose for PCI dev %s!\n", pci_name(dev));
@@ -115,7 +115,7 @@
struct resource *res = dev->resource + i;
if (!res->flags)
continue;
- if (res->end == 0xffffffff) {
+ if (res->end == (resource_size_t) -1) {
DBG("PCI:%s Resource %d [%016llx-%016llx] is unassigned\n",
pci_name(dev), i, (u64)res->start, (u64)res->end);
res->end -= res->start;
@@ -148,7 +148,7 @@
void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
struct resource *res)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -163,7 +163,7 @@
void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
struct pci_bus_region *region)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -439,7 +439,7 @@
u8 io_base_lo, io_limit_lo;
u16 mem_base, mem_limit;
u16 cmd;
- unsigned long start, end, off;
+ resource_size_t start, end, off;
struct pci_controller *hose = dev->sysdata;
if (!hose) {
@@ -843,16 +843,28 @@
}
EXPORT_SYMBOL(pci_device_from_OF_node);
+
+static inline u64 pci_get_range64(u32 *r)
+{
+ return (((u64)r[0] << 32) | r[1]);
+}
+
+
void __init
pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
static unsigned int static_lc_ranges[256] __initdata;
const unsigned int *dt_ranges;
- unsigned int *lc_ranges, *ranges, *prev, size;
+ unsigned int *lc_ranges, *ranges, *prev;
int rlen = 0, orig_rlen;
int memno = 0;
struct resource *res;
+ u32 prev_pci_space, pci_space;
+ u64 prev_pci_addr, pci_addr;
+ u64 prev_size, size;
+ phys_addr_t cpu_phys_addr;
+
int np, na = of_n_addr_cells(dev);
np = na + 5;
@@ -879,11 +891,18 @@
prev = NULL;
while ((rlen -= np * sizeof(unsigned int)) >= 0) {
if (prev) {
- if (prev[0] == ranges[0] && prev[1] == ranges[1] &&
- (prev[2] + prev[na+4]) == ranges[2] &&
- (prev[na+2] + prev[na+4]) == ranges[na+2]) {
- prev[na+4] += ranges[na+4];
+ prev_pci_space = prev[0];
+ prev_pci_addr = pci_get_range64(&prev[1]);
+ prev_size = pci_get_range64(&prev[na+3]);
+ pci_space = ranges[0];
+ pci_addr = pci_get_range64(&ranges[1]);
+ if ((prev_pci_space == pci_space) &&
+ ((prev_pci_addr + prev_size) == pci_addr)) {
+ size = pci_get_range64(&ranges[na+3]);
+ prev_size += size;
ranges[0] = 0;
+ prev[na+3] = (u32)((prev_size >> 32) & 0xffffffff);
+ prev[na+4] = (u32)(prev_size & 0xffffffff);
ranges += np;
continue;
}
@@ -904,21 +923,22 @@
rlen = orig_rlen;
while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
res = NULL;
- size = ranges[na+4];
- switch ((ranges[0] >> 24) & 0x3) {
+ size = pci_get_range64(&ranges[na+3]);
+ pci_space = ranges[0] >> 24;
+ switch (pci_space & 0x3) {
case 1: /* I/O space */
if (ranges[2] != 0)
break;
- hose->io_base_phys = ranges[na+2];
+ hose->io_base_phys = of_translate_address(dev, &ranges[3]);
/* limit I/O space to 16MB */
if (size > 0x01000000)
size = 0x01000000;
- hose->io_base_virt = ioremap(ranges[na+2], size);
+ hose->io_base_virt = ioremap(hose->io_base_phys, size);
if (primary)
isa_io_base = (unsigned long) hose->io_base_virt;
res = &hose->io_resource;
res->flags = IORESOURCE_IO;
- res->start = ranges[2];
+ res->start = pci_get_range64(&ranges[1]);
DBG("PCI: IO 0x%llx -> 0x%llx\n",
(u64)res->start, (u64)res->start + size - 1);
break;
@@ -933,14 +953,16 @@
}
while (memno < 3 && hose->mem_resources[memno].flags)
++memno;
+ pci_addr = pci_get_range64(&ranges[1]);
+ cpu_phys_addr = of_translate_address(dev, &ranges[3]);
if (memno == 0)
- hose->pci_mem_offset = ranges[na+2] - ranges[2];
+ hose->pci_mem_offset = (u64)cpu_phys_addr - pci_addr;
if (memno < 3) {
res = &hose->mem_resources[memno];
res->flags = IORESOURCE_MEM;
if(ranges[0] & 0x40000000)
res->flags |= IORESOURCE_PREFETCH;
- res->start = ranges[na+2];
+ res->start = cpu_phys_addr;
DBG("PCI: MEM[%d] 0x%llx -> 0x%llx\n", memno,
(u64)res->start, (u64)res->start + size - 1);
}
^ permalink raw reply
* [PATCH 2/2] [FS_ENET] Add polling support
From: Vitaly Bordug @ 2007-09-18 16:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20070918160527.13525.80935.stgit@localhost.localdomain>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/fs_enet/fs_enet-main.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 927cd9e..0e2d2b2 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -61,6 +61,9 @@ module_param(fs_enet_debug, int, 0);
MODULE_PARM_DESC(fs_enet_debug,
"Freescale bitmapped debugging message enable value");
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void fs_enet_netpoll(struct net_device *dev);
+#endif
static void fs_set_multicast_list(struct net_device *dev)
{
@@ -1049,6 +1052,10 @@ static struct net_device *fs_init_instance(struct device *dev,
ndev->stop = fs_enet_close;
ndev->get_stats = fs_enet_get_stats;
ndev->set_multicast_list = fs_set_multicast_list;
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev->poll_controller = fs_enet_netpoll;
+#endif
if (fpi->use_napi) {
ndev->poll = fs_enet_rx_napi;
ndev->weight = fpi->napi_weight;
@@ -1275,6 +1282,15 @@ static void __exit fs_cleanup(void)
cleanup_immap();
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void fs_enet_netpoll(struct net_device *dev)
+{
+ disable_irq(dev->irq);
+ fs_enet_interrupt(dev->irq, dev, NULL);
+ enable_irq(dev->irq);
+}
+#endif
+
/**************************************************************************************/
module_init(fs_init);
^ permalink raw reply related
* [PATCH 1/2] [FS_ENET] TX stuff should use fep->tx_lock, instead of fep->lock.
From: Vitaly Bordug @ 2007-09-18 16:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/fs_enet/fs_enet-main.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index a4a2a0e..927cd9e 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -348,7 +348,7 @@ static void fs_enet_tx(struct net_device *dev)
int dirtyidx, do_wake, do_restart;
u16 sc;
- spin_lock(&fep->lock);
+ spin_lock(&fep->tx_lock);
bdp = fep->dirty_tx;
do_wake = do_restart = 0;
@@ -428,7 +428,7 @@ static void fs_enet_tx(struct net_device *dev)
if (do_restart)
(*fep->ops->tx_restart)(dev);
- spin_unlock(&fep->lock);
+ spin_unlock(&fep->tx_lock);
if (do_wake)
netif_wake_queue(dev);
@@ -826,7 +826,9 @@ static int fs_enet_close(struct net_device *dev)
phy_stop(fep->phydev);
spin_lock_irqsave(&fep->lock, flags);
+ spin_lock(&fep->tx_lock);
(*fep->ops->stop)(dev);
+ spin_unlock(&fep->tx_lock);
spin_unlock_irqrestore(&fep->lock, flags);
/* release any irqs */
^ permalink raw reply related
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Scott Wood @ 2007-09-18 15:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <027F3363-3154-4A16-A251-C56D8DC339A1@kernel.crashing.org>
On Tue, Sep 18, 2007 at 10:19:05AM -0500, Kumar Gala wrote:
> Mainly that 8xx has been doing this for a vast number of years and I
> see no reason to stop doing it at this point.
>
> While I can see that it might be misleading, clearly 8xx linux users
> haven't had issues with it.
Or they haven't said anything. :-P
How about a three-way choice of full emulation, minimal emulation, and no
emulation?
-Scott
^ permalink raw reply
* Re: Problem booting linux with device tree table
From: Scott Wood @ 2007-09-18 15:17 UTC (permalink / raw)
To: Andrew Liu; +Cc: linuxppc-embedded
In-Reply-To: <46EF93D8.6050201@windriver.com>
On Tue, Sep 18, 2007 at 05:01:12PM +0800, Andrew Liu wrote:
> Latest U-boot need a chosen node in your DTS file,
It does not.
> So u need to add a chosen node in your DTS file.
>
> Take mpc8272ads for example: in its DTS, has the following:
>
> chosen {
> name = "chosen";
> linux,platform = <0>;
> interrupt-controller = <&Cpm_pic>;
> };
Please don't use that file as an example. :-)
-Scott
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Domen Puncer @ 2007-09-18 15:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709171508s76c842c8hca236249617cbb44@mail.gmail.com>
(I edited Cc: -jeff, +sven, hope you don't mind)
On 17/09/07 18:08 -0400, Jon Smirl wrote:
> On 9/17/07, Domen Puncer <domen@coderock.org> wrote:
> > Export phy_mii_ioctl, so network drivers can use it when built
> > as modules too.
>
> Domen, do you want to collect all of these changes for MPC5200 FEC in
> to a single patch series? The code is getting scattered around, I'll
> check it over to make sure it is all working. I have these patches
> applied individually and they all work.
>
> It builds on this series:
> [PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
>
> If you can put this together is a clean series, I should be able to
> layer support for the Phytec pcm030 on top of it.
>
> It would be these three combined...
>
> http://coderock.org/tmp/fec-v3rc1/
http://coderock.org/tmp/fec-v3rc2/
export_phy_mii_ioctl
fec_driver-bestcomm
fec_driver-dts
fec_driver-fec
fec_driver-phy
Built (on top of 7 bestcomm patches) and ran it built-in and as module
on Efika.
Order of applying only matters for phy part, which has to be after
the fec driver.
More testing and getting it to work properly on Phytec pcm030 would
be great.
Domen
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-09-18 15:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070918151147.GB736@ld0162-tx32.am.freescale.net>
On Sep 18, 2007, at 10:11 AM, Scott Wood wrote:
> On Tue, Sep 18, 2007 at 10:08:50AM -0500, Kumar Gala wrote:
>>
>> On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
>>
>>> On arch/ppc, Soft_emulate_8xx was used when full math emulation was
>>> turned off to emulate a minimal subset of floating point load/store
>>> instructions, to avoid needing a soft-float toolchain. This
>>> function
>>> is called, but not present, on arch/powerpc, causing a build error
>>> if floating point emulation is turned off.
>>>
>>> As:
>>> 1. soft-float toolchains are now common,
>>> 2. partial emulation could mislead someone into thinking they have
>>> a soft-float userspace because things usually work, only to have it
>>> fail when actual FP gets executed under unusual circumstances, and
>>> 3. full emulation is still available for those who need to run
>>> non-soft-float userspace,
>>>
>>> I'm deleting the call rather than moving Soft_emulate_8xx over to
>>> arch/powerpc.
>>>
>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>
>> I'm still not in favor of this and think we should move the
>> Soft_emulate_8xx code over.
>
> Any particular reasons that outweigh the reasons I gave, especially
> #2?
Mainly that 8xx has been doing this for a vast number of years and I
see no reason to stop doing it at this point.
While I can see that it might be misleading, clearly 8xx linux users
haven't had issues with it.
- k
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Scott Wood @ 2007-09-18 15:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <58472170-34D3-43F4-A816-87AF0020A086@kernel.crashing.org>
On Tue, Sep 18, 2007 at 10:08:50AM -0500, Kumar Gala wrote:
>
> On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
>
> >On arch/ppc, Soft_emulate_8xx was used when full math emulation was
> >turned off to emulate a minimal subset of floating point load/store
> >instructions, to avoid needing a soft-float toolchain. This function
> >is called, but not present, on arch/powerpc, causing a build error
> >if floating point emulation is turned off.
> >
> >As:
> >1. soft-float toolchains are now common,
> >2. partial emulation could mislead someone into thinking they have
> >a soft-float userspace because things usually work, only to have it
> >fail when actual FP gets executed under unusual circumstances, and
> >3. full emulation is still available for those who need to run
> >non-soft-float userspace,
> >
> >I'm deleting the call rather than moving Soft_emulate_8xx over to
> >arch/powerpc.
> >
> >Signed-off-by: Scott Wood <scottwood@freescale.com>
>
> I'm still not in favor of this and think we should move the
> Soft_emulate_8xx code over.
Any particular reasons that outweigh the reasons I gave, especially #2?
-Scott
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Kumar Gala @ 2007-09-18 15:13 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46EFE849.7080508@ru.mvista.com>
On Sep 18, 2007, at 10:01 AM, Valentine Barshak wrote:
> Kumar Gala wrote:
>> On Sep 18, 2007, at 9:44 AM, Valentine Barshak wrote:
>>> Add 64-bit physical address support to PCI.
>> Can you expand on your commit message. for example why do this?
>> is it address a bug fix, etc..
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
>>> arch/powerpc/kernel/iomap.c | 4 +--
>>> arch/powerpc/kernel/pci_32.c | 56 ++++++++++++++++++++++++++++
>>> +--------------
>>> 2 files changed, 41 insertions(+), 19 deletions(-)
>> - k
>
> Currently 32-bit pci code doesn't support 64-bit physical addresses.
> We have to add 64-bit addr support in order to bring-up pci on
> PowerPC 440. Actually, this refers to the conversation started here:
I can guess as to why, but its useful for the commit messages to be
more descriptive so when some goes back a year from now they know why
someone added this patch.
- k
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-09-18 15:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070917165746.GP6563@loki.buserror.net>
On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
> On arch/ppc, Soft_emulate_8xx was used when full math emulation was
> turned off to emulate a minimal subset of floating point load/store
> instructions, to avoid needing a soft-float toolchain. This function
> is called, but not present, on arch/powerpc, causing a build error
> if floating point emulation is turned off.
>
> As:
> 1. soft-float toolchains are now common,
> 2. partial emulation could mislead someone into thinking they have
> a soft-float userspace because things usually work, only to have it
> fail when actual FP gets executed under unusual circumstances, and
> 3. full emulation is still available for those who need to run
> non-soft-float userspace,
>
> I'm deleting the call rather than moving Soft_emulate_8xx over to
> arch/powerpc.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
I'm still not in favor of this and think we should move the
Soft_emulate_8xx code over.
- k
^ permalink raw reply
* Re: dtc: Whitespace cleanup
From: Jon Loeliger @ 2007-09-18 15:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070918014404.GB30766@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This large patch removes all trailing whitespace from dtc (including
> libfdt, the testsuite and documentation). It also removes a handful
> of redundant blank lines (at the end of functions, or when there are
> two blank lines together for no particular reason).
>
> As well as anything else, this means that quilt won't whinge when I go
> to convert the whole of libfdt into a patch to apply to the kernel.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Add basic testcases for dtc
From: Jon Loeliger @ 2007-09-18 15:02 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070918003340.GA30766@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds a handful of simple testcases for dtc. It adds a dts
> file which should generate the same sample tree as is used for the
> libfdt testcases, and tests invoking dtc on this dts, plus the
> standard batch of libfdt cases on the resulting dtb, which effectively
> checks that the dtb is correct.
>
> Because the test framework assumes each testcase is an executable with
> the right output conventions, we use a little shell script, dtc.sh, as
> a wrapper around dtc itself. It simply invokes dtc and returns a PASS
> or FAIL depending on whether dtc returned an error.
>
> It's not much, but it's a start.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
> NB: Jon, you won't be able to simply git-applymbox this and have it
> work. You'll need to manually add execute permission to tests/dtc.sh
> before git commiting it, since I can't encode the permissions in a
> patch. Sorry for the inconvenience, but it didn't really seem worth
> setting up my own git to pull from just for that.
No problem. Too bad you can't just use git, though... :-)
jdl
^ 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