* Re: RFC: Mega rename of device tree routines from of_*() to dt_*()
From: Mitch Bradley @ 2010-11-26 7:36 UTC (permalink / raw)
To: michael
Cc: linux-arch, linux-mips, microblaze-uclinux, devicetree-discuss,
LKML, linuxppc-dev list, sparclinux, Andrew Morton, Andrea Scian,
Linus Torvalds
In-Reply-To: <1290750606.9453.394.camel@concordia>
>> One Laptop Per Child ships real Open Firmware on its x86 Linux systems,
>> of which approximately 2 million have been shipped or ordered. An ARM
>> version, also with OFW, is in the works.
>
> OK. I don't see any code under arch/x86 or arch/arm that uses of_()
> routines though? Or is it under drivers or something?
>
Andres Salomon has been working for some time to get some Open Firmware
support for x86 upstream. As you can probably imagine, it has been slow
going, but seems to be getting close.
The OLPC ARM work is just beginning, so nothing has been submitted yet.
The first hardware prototypes are still being debugged. Lennert
Buytenhek is the key OS person who will be involved.
^ permalink raw reply
* [PATCH] ucc_geth: fix ucc halt problem in half duplex mode
From: Li Yang @ 2010-11-26 9:29 UTC (permalink / raw)
To: linuxppc-dev, netdev, davem
Cc: Anton Vorontsov, Jean-Denis Boyer, Andreas Schmitz
In commit 58933c64(ucc_geth: Fix the wrong the Rx/Tx FIFO size),
the UCC_GETH_UTFTT_INIT is set to 512 based on the recommendation
of the QE Reference Manual. But that will sometimes cause tx halt
while working in half duplex mode.
According to errata draft QE_GENERAL-A003(High Tx Virtual FIFO
threshold size can cause UCC to halt), setting UTFTT less than
[(UTFS x (M - 8)/M) - 128] will prevent this from happening
(M is the minimum buffer size).
The patch changes UTFTT back to 256.
Signed-off-by: Li Yang <leoli@freescale.com>
Cc: Jean-Denis Boyer <jdboyer@media5corp.com>
Cc: Andreas Schmitz <Andreas.Schmitz@riedel.net>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 05a9558..a78b9c0 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -899,7 +899,8 @@ struct ucc_geth_hardware_statistics {
#define UCC_GETH_UTFS_INIT 512 /* Tx virtual FIFO size
*/
#define UCC_GETH_UTFET_INIT 256 /* 1/2 utfs */
-#define UCC_GETH_UTFTT_INIT 512
+#define UCC_GETH_UTFTT_INIT 256 /* 1/2 utfs
+ due to errata */
/* Gigabit Ethernet (1000 Mbps) */
#define UCC_GETH_URFS_GIGA_INIT 4096/*2048*/ /* Rx virtual
FIFO size */
--
1.6.6-rc1.GIT
^ permalink raw reply related
* [PATCH v3] ppc44x:PHY fixup for USB on canyonlands board
From: Rupjyoti Sarmah @ 2010-11-26 11:10 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: rsarmah
This fix is a reset for USB PHY that requires some amount of time for power to be stable on Canyonlands.
Signed-off-by: Rupjyoti Sarmah <rsarmah@apm.com>
---
changes from previous version:
- moved a Macro from header file to the source file
- corrected & updated comments
- replaced the out_be32 calls by setbits32 calls
- bootup delay reduced, udelay is replaced by msleep
arch/powerpc/boot/dts/canyonlands.dts | 13 +++
arch/powerpc/platforms/44x/44x.h | 4 +
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/canyonlands.c | 120 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 -
5 files changed, 138 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..a9f7538 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -224,6 +224,13 @@
};
};
+ cpld@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "apm,ppc460ex-bcsr";
+ reg = <2 0x0 0x9>;
+ };
+
ndfc@3,0 {
compatible = "ibm,ndfc";
reg = <0x00000003 0x00000000 0x00002000>;
@@ -320,6 +327,12 @@
interrupts = <0x3 0x4>;
};
+ GPIO0: gpio@ef600b00 {
+ compatible = "ibm,ppc4xx-gpio";
+ reg = <0xef600b00 0x00000048>;
+ gpio-controller;
+ };
+
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-460ex", "ibm,zmii";
reg = <0xef600d00 0x0000000c>;
diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
index dbc4d2b..63f703e 100644
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -4,4 +4,8 @@
extern u8 as1_readb(volatile u8 __iomem *addr);
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
+#define GPIO0_OSRH 0xC
+#define GPIO0_TSRH 0x14
+#define GPIO0_ISR1H 0x34
+
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 82ff326..6854e73 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
obj-$(CONFIG_ISS4xx) += iss4xx.o
+obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
new file mode 100644
index 0000000..61e80ce
--- /dev/null
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -0,0 +1,120 @@
+/*
+ * This contain platform specific code for Canyonlands board based on
+ * APM ppc44x series of processors.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Rupjyoti Sarmah <rsarmah@apm.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+#include <asm/udbg.h>
+#include <asm/uic.h>
+#include <linux/of_platform.h>
+#include <linux/delay.h>
+#include "44x.h"
+
+#define BCSR_USB_EN 0x11
+
+static __initdata struct of_device_id ppc44x_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init ppc44x_device_probe(void)
+{
+ of_platform_bus_probe(NULL, ppc44x_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(canyonlands, ppc44x_device_probe);
+
+/* Using this code only for the Canyonlands board. */
+
+static int __init ppc44x_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, "amcc,canyonlands")) {
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
+ return 1;
+ }
+ return 0;
+}
+
+/* USB PHY fixup code on Canyonlands kit. */
+
+static int __init ppc460ex_canyonlands_fixup(void)
+{
+ u8 __iomem *bcsr ;
+ void __iomem *vaddr;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "apm,ppc460ex-bcsr");
+ if (!np) {
+ printk(KERN_ERR "failed did not find apm, ppc460ex bcsr node\n");
+ return -ENODEV;
+ }
+
+ bcsr = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!bcsr) {
+ printk(KERN_CRIT "Could not remap bcsr\n");
+ return -ENODEV;
+ }
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,ppc4xx-gpio");
+ vaddr = of_iomap(np, 0);
+ if (!vaddr) {
+ printk(KERN_CRIT "Could not get gpio node address\n");
+ return -ENODEV;
+ }
+ /* Disable USB, through the BCSR7 bits */
+ setbits8(&bcsr[7], BCSR_USB_EN);
+
+ /* Wait for a while after reset */
+ msleep(100);
+
+ /* Enable USB here */
+ clrbits8(&bcsr[7], BCSR_USB_EN);
+
+ /*
+ * Configure multiplexed gpio16 and gpio19 as alternate1 output
+ * source after USB reset.This configuration is done through GPIO0_TSRH
+ * and GPIO0_OSRH bits 0:1 and 6:7.
+ */
+ setbits32((vaddr + GPIO0_OSRH), 0x42000000);
+ setbits32((vaddr + GPIO0_TSRH), 0x42000000);
+ of_node_put(np);
+ return 0;
+}
+machine_device_initcall(canyonlands, ppc460ex_canyonlands_fixup);
+define_machine(canyonlands) {
+ .name = "Canyonlands",
+ .probe = ppc44x_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 7ddcba3..c81c19c 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -53,7 +53,6 @@ static char *board[] __initdata = {
"amcc,arches",
"amcc,bamboo",
"amcc,bluestone",
- "amcc,canyonlands",
"amcc,glacier",
"ibm,ebony",
"amcc,eiger",
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH v3] ppc44x:PHY fixup for USB on canyonlands board
From: Wolfgang Denk @ 2010-11-26 14:23 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linuxppc-dev, rsarmah, linux-kernel
In-Reply-To: <201011261110.oAQBANZL012455@amcc.com>
Dear Rupjyoti Sarmah,
In message <201011261110.oAQBANZL012455@amcc.com> you wrote:
>
> + cpld@2,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "apm,ppc460ex-bcsr";
This results in a mix of "amcc," and "apm," strings.
Are there any plans to unify this?
> diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
> new file mode 100644
> index 0000000..61e80ce
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/canyonlands.c
> @@ -0,0 +1,120 @@
> +/*
> + * This contain platform specific code for Canyonlands board based on
> + * APM ppc44x series of processors.
Canyonlands is always PPC460EX, or does it ever come with other
processors as well?
> +static int __init ppc44x_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> + if (of_flat_dt_is_compatible(root, "amcc,canyonlands")) {
> + ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
> + return 1;
> + }
> + return 0;
> +}
Bad indentation.
> + /* Disable USB, through the BCSR7 bits */
> + setbits8(&bcsr[7], BCSR_USB_EN);
> +
> + /* Wait for a while after reset */
> + msleep(100);
> +
> + /* Enable USB here */
> + clrbits8(&bcsr[7], BCSR_USB_EN);
> +
> + /*
> + * Configure multiplexed gpio16 and gpio19 as alternate1 output
> + * source after USB reset.This configuration is done through GPIO0_TSRH
> + * and GPIO0_OSRH bits 0:1 and 6:7.
> + */
Earlier versions of the patch included a delay after the clrbits8()
call as well. Is it intentional that you dropped this now?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every program has at least one bug and can be shortened by at least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.
^ permalink raw reply
* RE: [PATCH v3] ppc44x:PHY fixup for USB on canyonlands board
From: Rupjyoti Sarmah @ 2010-11-26 15:32 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101126142342.E05A411D94F1@gemini.denx.de>
Hi Wolfgang,
>> This results in a mix of "amcc," and "apm," strings.
>> Are there any plans to unify this?
We can make all as apm, but right now I believe there is no plan to do so.
>>Earlier versions of the patch included a delay after the clrbits8()
>>call as well. Is it intentional that you dropped this now?
It is dropped intentionally.
Rest of your suggestions, I will modify and resubmit. Thanks.
Regards,
Rup
^ permalink raw reply
* RE: [PATCH v3] ppc44x:PHY fixup for USB on canyonlands board
From: Benjamin Herrenschmidt @ 2010-11-26 21:22 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linuxppc-dev, Wolfgang Denk, linux-kernel
In-Reply-To: <ade8814261339ab5028557ae3dc15c0b@mail.gmail.com>
On Fri, 2010-11-26 at 21:02 +0530, Rupjyoti Sarmah wrote:
> Hi Wolfgang,
>
> >> This results in a mix of "amcc," and "apm," strings.
> >> Are there any plans to unify this?
> We can make all as apm, but right now I believe there is no plan to do so.
>
> >>Earlier versions of the patch included a delay after the clrbits8()
> >>call as well. Is it intentional that you dropped this now?
> It is dropped intentionally.
>
> Rest of your suggestions, I will modify and resubmit. Thanks.
I think this should remain consistent within the platform and stick to
"amcc".
Cheers,
Ben.
^ permalink raw reply
* PHY/FEC Network adapter failed to initialize on MPC52xx Board
From: Peter @ 2010-11-27 13:31 UTC (permalink / raw)
To: linuxppc-dev
Hi all
I got completely stuck with a network adapter problem on my
ppc board (MPC52xx style). The ntwork adapter does not seem
to intialize correctly when booted without 'help from uboot'
The adapter works properly when I first use it with uboot. E.g.
using tftp to load the kernel or just issuing a dummy sntp
command. It does not get intialized if I boot linux without
using any network relevant command in ubboot
The difference manifests on the boot message: (working)
PHY working
...
mpc52xx MII bus: probed
TCP cubic registered
NET: Registered protocol family 17
IP-Config: Complete:
device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2,
host=192.168.1.245, domain=, nis-domain=(none),
bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.244
Looking up port of RPC 100005/1 on 192.168.1.244
VFS: Mounted root (nfs filesystem) on device 0:11.
Freeing unused kernel memory: 124k init
PHY: f0003000:00 - Link is Up - 100/Full
# ping 192.168.1.2 returns proper results.
PHY Not working:
...
mpc52xx MII bus: probed
TCP cubic registered
NET: Registered protocol family 17
IP-Config: Complete:
device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2,
host=192.168.1.245, domain=, nis-domain=(none),
bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath=
VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
Freeing unused kernel memory: 124k init
# ping 192.168.1.2 hangs
The second snipped does not have "Looking up.." messages because it
boots from flash. Main difference is "PHY: f0003000:00 - Link is Up - 100/Full"
which does not appear at the failing case.
Linux Version is 2.6.35.7 patched with xenomai 2.5
U-Boot 2010.06 (Aug 05 2010 - 19:54:45)
Linux configuration see below: ( i left most entries out that are not set)
I also experimented with different settings but finally only
CONFIG_FEC_MPC52xx=y and CONFIG_FEC_MPC52xx_MDIO=y
seem to be of any relevance. If both are set, the adapter works
when initialized by uboot.
Any help or tips will be very much appreciated,
Regards, Peter
Linux .config
...
#
# Platform support
#
# CONFIG_PPC_CHRP is not set
# CONFIG_MPC5121_ADS is not set
# CONFIG_MPC5121_GENERIC is not set
CONFIG_PPC_MPC52xx=y
CONFIG_PPC_MPC5200_SIMPLE=y
# CONFIG_PPC_EFIKA is not set
CONFIG_PPC_LITE5200=y
# CONFIG_PPC_MEDIA5200 is not set
CONFIG_PPC_MPC5200_BUGFIX=y
# CONFIG_PPC_MPC5200_GPIO is not set
CONFIG_PPC_MPC5200_LPBFIFO=y
CONFIG_PPC_BESTCOMM=y
CONFIG_PPC_BESTCOMM_FEC=y
CONFIG_PPC_BESTCOMM_GEN_BD=y
# CONFIG_SIMPLE_GPIO is not set
..
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PPC_PCI_CHOICE=y
...
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
#
# MII PHY device drivers
#
CONFIG_LXT_PHY=y ## Does not seem to have any influence
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_ETHOC=y ## Does not seem to have any influence
CONFIG_FEC_MPC52xx=y ## Must be Y in roder to get adapter working with uboot's init
CONFIG_FEC_MPC52xx_MDIO=y ## Must be Y in roder to get adapter working with uboot's init
^ permalink raw reply
* ppc_set_hwdebug vs ptrace_set_debugreg
From: Andreas Schwab @ 2010-11-27 19:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dave Kleikamp, K.Prasad
Why does ptrace_set_debugreg call register_user_hw_breakpoint, but
ppc_set_hwdebug doesn't? Shouldn't ppc_set_hwdebug set the
DABR_DATA_(READ|WRITE|TRANSLATION) bits in the dabr?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] powerpc: fix PPC_PTRACE_SETHWDEBUG on PPC_BOOK3S
From: Andreas Schwab @ 2010-11-28 0:24 UTC (permalink / raw)
To: linuxppc-dev
Properly set the DABR_TRANSLATION/DABR_DATA_READ/DABR_DATA_READ bits in
the dabr when setting the debug register via PPC_PTRACE_SETHWDEBUG. Also
don't reject trigger type of PPC_BREAKPOINT_TRIGGER_READ.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/kernel/ptrace.c | 22 ++++++++++++++++------
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index a9b3296..9065369 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1316,6 +1316,10 @@ static int set_dac_range(struct task_struct *child,
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifndef CONFIG_PPC_ADV_DEBUG_REGS
+ unsigned long dabr;
+#endif
+
if (bp_info->version != 1)
return -ENOTSUPP;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
@@ -1353,11 +1357,10 @@ static long ppc_set_hwdebug(struct task_struct *child,
/*
* We only support one data breakpoint
*/
- if (((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0) ||
- ((bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0) ||
- (bp_info->trigger_type != PPC_BREAKPOINT_TRIGGER_WRITE) ||
- (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) ||
- (bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE))
+ if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
+ (bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
+ bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
+ bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
return -EINVAL;
if (child->thread.dabr)
@@ -1366,7 +1369,14 @@ static long ppc_set_hwdebug(struct task_struct *child,
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
- child->thread.dabr = (unsigned long)bp_info->addr;
+ dabr = (unsigned long)bp_info->addr & ~7UL;
+ dabr |= DABR_TRANSLATION;
+ if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
+ dabr |= DABR_DATA_READ;
+ if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
+ dabr |= DABR_DATA_WRITE;
+
+ child->thread.dabr = dabr;
return 1;
#endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
--
1.7.3.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: PHY/FEC Network adapter failed to initialize on MPC52xx Board
From: Gary Thomas @ 2010-11-28 11:55 UTC (permalink / raw)
To: Peter; +Cc: linuxppc-dev
In-Reply-To: <4CF10819.4050007@crane-soft.de>
On 11/27/2010 06:31 AM, Peter wrote:
> Hi all
>
> I got completely stuck with a network adapter problem on my
> ppc board (MPC52xx style). The ntwork adapter does not seem
> to intialize correctly when booted without 'help from uboot'
>
> The adapter works properly when I first use it with uboot. E.g.
> using tftp to load the kernel or just issuing a dummy sntp
> command. It does not get intialized if I boot linux without
> using any network relevant command in ubboot
>
> The difference manifests on the boot message: (working)
> PHY working
> ...
> mpc52xx MII bus: probed
> TCP cubic registered
> NET: Registered protocol family 17
> IP-Config: Complete:
> device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2,
> host=192.168.1.245, domain=, nis-domain=(none),
> bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath=
> Looking up port of RPC 100003/2 on 192.168.1.244
> Looking up port of RPC 100005/1 on 192.168.1.244
> VFS: Mounted root (nfs filesystem) on device 0:11.
> Freeing unused kernel memory: 124k init
> PHY: f0003000:00 - Link is Up - 100/Full
>
> # ping 192.168.1.2 returns proper results.
>
> PHY Not working:
> ...
> mpc52xx MII bus: probed
> TCP cubic registered
> NET: Registered protocol family 17
> IP-Config: Complete:
> device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2,
> host=192.168.1.245, domain=, nis-domain=(none),
> bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath=
> VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
> Freeing unused kernel memory: 124k init
>
> # ping 192.168.1.2 hangs
>
>
> The second snipped does not have "Looking up.." messages because it
> boots from flash. Main difference is "PHY: f0003000:00 - Link is Up - 100/Full"
> which does not appear at the failing case.
>
> Linux Version is 2.6.35.7 patched with xenomai 2.5
> U-Boot 2010.06 (Aug 05 2010 - 19:54:45)
>
> Linux configuration see below: ( i left most entries out that are not set)
> I also experimented with different settings but finally only
> CONFIG_FEC_MPC52xx=y and CONFIG_FEC_MPC52xx_MDIO=y
> seem to be of any relevance. If both are set, the adapter works
> when initialized by uboot.
>
> Any help or tips will be very much appreciated,
There are a couple of possibilities:
* Many PHY devices will have an external RESET or enable pin which is
driven by GPIO. The board support package in U-Boot for your board
would then enable the PHY device as part of network initialization.
The Linux kernel typically does not fiddle with such things.
* The actual PHY device may need some setup (adjustment of internal
PHY registers) before it will come on-line, e.g. the device may not
be strapped to auto-negotiate on the wire to find a link. U-Boot
might be turning this on, or even forcing the link up (I've seen
such devices that needed this level of hand-holding). Again, the
Linux network driver typically will not be doing these sort of
operations.
To figure out what's going on and what else you might need, you should
look at both the U-Boot code for your board and the board documentation
(schematics, etc). Then you should be able to see what U-Boot does that
the Linux kernel is not. In the end, you may need to add some code in
your target platform support in Linux to add the additional stuff to make
the PHY work.
> Linux .config
>
> ...
> #
> # Platform support
> #
> # CONFIG_PPC_CHRP is not set
> # CONFIG_MPC5121_ADS is not set
> # CONFIG_MPC5121_GENERIC is not set
> CONFIG_PPC_MPC52xx=y
> CONFIG_PPC_MPC5200_SIMPLE=y
> # CONFIG_PPC_EFIKA is not set
> CONFIG_PPC_LITE5200=y
> # CONFIG_PPC_MEDIA5200 is not set
> CONFIG_PPC_MPC5200_BUGFIX=y
> # CONFIG_PPC_MPC5200_GPIO is not set
> CONFIG_PPC_MPC5200_LPBFIFO=y
>
> CONFIG_PPC_BESTCOMM=y
> CONFIG_PPC_BESTCOMM_FEC=y
> CONFIG_PPC_BESTCOMM_GEN_BD=y
> # CONFIG_SIMPLE_GPIO is not set
> ..
> # Bus options
> #
> CONFIG_ZONE_DMA=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_PPC_PCI_CHOICE=y
> ...
> #
> # Generic Driver Options
> #
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_MTD=y
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_CMDLINE_PARTS=y
>
> #
> # MII PHY device drivers
> #
> CONFIG_LXT_PHY=y ## Does not seem to have any influence
> CONFIG_NET_ETHERNET=y
> CONFIG_MII=y
> CONFIG_ETHOC=y ## Does not seem to have any influence
> CONFIG_FEC_MPC52xx=y ## Must be Y in roder to get adapter working with uboot's init
> CONFIG_FEC_MPC52xx_MDIO=y ## Must be Y in roder to get adapter working with uboot's init
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* [PATCH] powerpc: update compat_arch_ptrace
From: Andreas Schwab @ 2010-11-28 16:33 UTC (permalink / raw)
To: linuxppc-dev
Update compat_arch_ptrace to follow recent changes in
PTRACE_GET_DEBUGREG and the addition of
PPC_PTRACE_{GETHWDBGINFO|{SET|DEL}HWDEBUG}. The latter three can be
forwarded to arch_ptrace unchanged.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/kernel/ptrace32.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
index 8a6daf4..69c4be9 100644
--- a/arch/powerpc/kernel/ptrace32.c
+++ b/arch/powerpc/kernel/ptrace32.c
@@ -280,7 +280,11 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
/* We only support one DABR and no IABRS at the moment */
if (addr > 0)
break;
+#ifdef CONFIG_PPC_ADV_DEBUG_REGS
+ ret = put_user(child->thread.dac1, (u32 __user *)data);
+#else
ret = put_user(child->thread.dabr, (u32 __user *)data);
+#endif
break;
}
@@ -312,6 +316,9 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
case PTRACE_SET_DEBUGREG:
case PTRACE_SYSCALL:
case PTRACE_CONT:
+ case PPC_PTRACE_GETHWDBGINFO:
+ case PPC_PTRACE_SETHWDEBUG:
+ case PPC_PTRACE_DELHWDEBUG:
ret = arch_ptrace(child, request, addr, data);
break;
--
1.7.3.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH] ucc_geth: fix ucc halt problem in half duplex mode
From: David Miller @ 2010-11-29 2:37 UTC (permalink / raw)
To: leoli; +Cc: netdev, Andreas.Schmitz, avorontsov, linuxppc-dev, jdboyer
In-Reply-To: <1290763798-22844-1-git-send-email-leoli@freescale.com>
From: Li Yang <leoli@freescale.com>
Date: Fri, 26 Nov 2010 17:29:58 +0800
> In commit 58933c64(ucc_geth: Fix the wrong the Rx/Tx FIFO size),
> the UCC_GETH_UTFTT_INIT is set to 512 based on the recommendation
> of the QE Reference Manual. But that will sometimes cause tx halt
> while working in half duplex mode.
>
> According to errata draft QE_GENERAL-A003(High Tx Virtual FIFO
> threshold size can cause UCC to halt), setting UTFTT less than
> [(UTFS x (M - 8)/M) - 128] will prevent this from happening
> (M is the minimum buffer size).
>
> The patch changes UTFTT back to 256.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Cc: Jean-Denis Boyer <jdboyer@media5corp.com>
> Cc: Andreas Schmitz <Andreas.Schmitz@riedel.net>
> Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 3/5] fpga: add basic CARMA board support
From: Benjamin Herrenschmidt @ 2010-11-29 0:36 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1283964082-30133-4-git-send-email-iws@ovro.caltech.edu>
On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> This adds basic support for the system controller FPGA on the OVRO CARMA
> board. This patch only adds infrastructure that will be used by later
> drivers.
One comment I have is do you really need to create a class ? Do you
provide a specific API/interface that would make it useful ?
Cheers,
Ben.
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
> ---
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/fpga/Kconfig | 1 +
> drivers/fpga/Makefile | 1 +
> drivers/fpga/carma/Kconfig | 21 ++++++++++++
> drivers/fpga/carma/Makefile | 1 +
> drivers/fpga/carma/carma.c | 73 +++++++++++++++++++++++++++++++++++++++++++
> drivers/fpga/carma/carma.h | 22 +++++++++++++
> 8 files changed, 122 insertions(+), 0 deletions(-)
> create mode 100644 drivers/fpga/Kconfig
> create mode 100644 drivers/fpga/Makefile
> create mode 100644 drivers/fpga/carma/Kconfig
> create mode 100644 drivers/fpga/carma/Makefile
> create mode 100644 drivers/fpga/carma/carma.c
> create mode 100644 drivers/fpga/carma/carma.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index a2b902f..8945ae6 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -111,4 +111,6 @@ source "drivers/xen/Kconfig"
> source "drivers/staging/Kconfig"
>
> source "drivers/platform/Kconfig"
> +
> +source "drivers/fpga/Kconfig"
> endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index ae47344..c0b05de 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -115,3 +115,4 @@ obj-$(CONFIG_VLYNQ) += vlynq/
> obj-$(CONFIG_STAGING) += staging/
> obj-y += platform/
> obj-y += ieee802154/
> +obj-$(CONFIG_FPGA_DRIVERS) += fpga/
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> new file mode 100644
> index 0000000..c85c2cc
> --- /dev/null
> +++ b/drivers/fpga/Kconfig
> @@ -0,0 +1 @@
> +source "drivers/fpga/carma/Kconfig"
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> new file mode 100644
> index 0000000..409a5f9
> --- /dev/null
> +++ b/drivers/fpga/Makefile
> @@ -0,0 +1 @@
> +obj-y += carma/
> diff --git a/drivers/fpga/carma/Kconfig b/drivers/fpga/carma/Kconfig
> new file mode 100644
> index 0000000..448885e
> --- /dev/null
> +++ b/drivers/fpga/carma/Kconfig
> @@ -0,0 +1,21 @@
> +
> +menuconfig FPGA_DRIVERS
> + bool "FPGA Drivers"
> + default n
> + help
> + Say Y here to see options for devices used with custom FPGAs.
> + This option alone does not add any kernel code.
> +
> + If you say N, all options in this submenu will be skipped and disabled.
> +
> +if FPGA_DRIVERS
> +
> +config CARMA
> + tristate "CARMA System Controller FPGA support"
> + depends on FSL_SOC && PPC_83xx
> + default n
> + help
> + Say Y here to include basic support for the CARMA System Controller
> + FPGA. This option allows the other more advanced drivers to be built.
> +
> +endif # FPGA_DRIVERS
> diff --git a/drivers/fpga/carma/Makefile b/drivers/fpga/carma/Makefile
> new file mode 100644
> index 0000000..90d0594
> --- /dev/null
> +++ b/drivers/fpga/carma/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_CARMA) += carma.o
> diff --git a/drivers/fpga/carma/carma.c b/drivers/fpga/carma/carma.c
> new file mode 100644
> index 0000000..97549d2
> --- /dev/null
> +++ b/drivers/fpga/carma/carma.c
> @@ -0,0 +1,73 @@
> +/*
> + * CARMA Board Utility Driver
> + *
> + * Copyright (c) 2009-2010 Ira W. Snyder <iws@ovro.caltech.edu>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +
> +#include "carma.h"
> +
> +static struct class *carma_class;
> +static const char drv_name[] = "carma";
> +
> +/*
> + * CARMA Device Class Functions
> + */
> +
> +struct device *carma_device_create(struct device *parent, dev_t devno,
> + const char *fmt, ...)
> +{
> + struct device *dev;
> + va_list vargs;
> +
> + va_start(vargs, fmt);
> + dev = device_create_vargs(carma_class, parent, devno, NULL, fmt, vargs);
> + va_end(vargs);
> +
> + return dev;
> +}
> +EXPORT_SYMBOL_GPL(carma_device_create);
> +
> +void carma_device_destroy(dev_t devno)
> +{
> + device_destroy(carma_class, devno);
> +}
> +EXPORT_SYMBOL_GPL(carma_device_destroy);
> +
> +/*
> + * Module Init / Exit
> + */
> +
> +static int __init carma_init(void)
> +{
> + /* Register the CARMA device class */
> + carma_class = class_create(THIS_MODULE, "carma");
> + if (IS_ERR(carma_class)) {
> + pr_err("%s: unable to create CARMA class\n", drv_name);
> + return PTR_ERR(carma_class);
> + }
> +
> + return 0;
> +}
> +
> +static void __exit carma_exit(void)
> +{
> + class_destroy(carma_class);
> +}
> +
> +MODULE_AUTHOR("Ira W. Snyder <iws@ovro.caltech.edu>");
> +MODULE_DESCRIPTION("CARMA Device Class Driver");
> +MODULE_LICENSE("GPL");
> +
> +module_init(carma_init);
> +module_exit(carma_exit);
> diff --git a/drivers/fpga/carma/carma.h b/drivers/fpga/carma/carma.h
> new file mode 100644
> index 0000000..f556dc8
> --- /dev/null
> +++ b/drivers/fpga/carma/carma.h
> @@ -0,0 +1,22 @@
> +/*
> + * CARMA Board Utilities
> + *
> + * Copyright (c) 2009-2010 Ira W. Snyder <iws@ovro.caltech.edu>
> + *
> + * 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.
> + */
> +
> +#ifndef CARMA_DEVICE_H
> +#define CARMA_DEVICE_H
> +
> +#include <linux/device.h>
> +
> +struct device *carma_device_create(struct device *parent, dev_t devno,
> + const char *fmt, ...)
> + __attribute__((format(printf, 3, 4)));
> +void carma_device_destroy(dev_t devno);
> +
> +#endif /* CARMA_DEVICE_H */
^ permalink raw reply
* Re: [PATCH 3/5] fpga: add basic CARMA board support
From: Benjamin Herrenschmidt @ 2010-11-29 0:38 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1283964082-30133-4-git-send-email-iws@ovro.caltech.edu>
On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> This adds basic support for the system controller FPGA on the OVRO CARMA
> board. This patch only adds infrastructure that will be used by later
> drivers.
Oh and another comment ...
I'm not sure about drivers/fpga ... in the end, one would expect such a
directory to contain stuff to manipulate FPGAs in the sense of
downloading bitfiles, instanciating devices (device-tree manipulation ?)
etc...
>From what I see in your code, the fact that these are FPGAs is almost
irrelevant, you are providing support for "carma" devices, and such are
no different than some other platform device, they just happen to be
implemented as FPGAs. Or am I missing something ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 3/7 v2] ppc: do not search for dma-window property on dlpar remove
From: Benjamin Herrenschmidt @ 2010-11-29 1:38 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: sonnyrao, miltonm, Paul Mackerras, Anton Blanchard, linuxppc-dev
In-Reply-To: <1288150518-4026-4-git-send-email-nacc@us.ibm.com>
On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
> The iommu_table pointer in the pci auxiliary struct of device_node has
> not been used by the iommu ops since the dma refactor of
> 12d04eef927bf61328af2c7cbe756c96f98ac3bf, however this code still uses
> it to find tables for dlpar. By only setting the PCI_DN iommu_table
> pointer on nodes with dma window properties, we will be able to quickly
> find the node for later checks, and can remove the table without looking
> for the the dma window property on dlpar remove.
The answer might well be yes but are we sure this works with busses &
devices that don't have a dma,window ? ie. we always properly look for
parents when assigning pci devices arch_data iommu table ? Did you test
it ? :-) (Best way is to find a card with a P2P bridge on it).
Cheers,
Ben.
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> ---
> arch/powerpc/platforms/pseries/iommu.c | 6 +-----
> 1 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 9184db3..8ab32da 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -455,9 +455,6 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus *bus)
> ppci->iommu_table = iommu_init_table(tbl, ppci->phb->node);
> pr_debug(" created table: %p\n", ppci->iommu_table);
> }
> -
> - if (pdn != dn)
> - PCI_DN(dn)->iommu_table = ppci->iommu_table;
> }
>
> @@ -571,8 +568,7 @@ static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long acti
>
> switch (action) {
> case PSERIES_RECONFIG_REMOVE:
> - if (pci && pci->iommu_table &&
> - of_get_property(np, "ibm,dma-window", NULL))
> + if (pci && pci->iommu_table)
> iommu_free_table(pci->iommu_table, np->full_name);
> break;
> default:
^ permalink raw reply
* Re: PHY/FEC Network adapter failed to initialize on MPC52xx Board
From: tiejun.chen @ 2010-11-29 2:48 UTC (permalink / raw)
To: Peter; +Cc: linuxppc-dev
In-Reply-To: <4CF10819.4050007@crane-soft.de>
Peter wrote:
> Hi all
>
> I got completely stuck with a network adapter problem on my
> ppc board (MPC52xx style). The ntwork adapter does not seem
> to intialize correctly when booted without 'help from uboot'
>
Looks your problem is very similar to one I replied here not long ago :) That is
also issued from MPC5200. And I remember there was a wrong Port Multiplex
Configuration.
If possible maybe you can check the email subjected "Problem Ethernet
Initialization MPC5200 + LXT971A" on linuxppc-dev list.
Hope its useful.
Tiejun
> The adapter works properly when I first use it with uboot. E.g.
> using tftp to load the kernel or just issuing a dummy sntp
> command. It does not get intialized if I boot linux without
> using any network relevant command in ubboot
>
> The difference manifests on the boot message: (working)
> PHY working
> ...
> mpc52xx MII bus: probed
> TCP cubic registered
> NET: Registered protocol family 17
> IP-Config: Complete:
> device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2,
> host=192.168.1.245, domain=, nis-domain=(none),
> bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath=
> Looking up port of RPC 100003/2 on 192.168.1.244
> Looking up port of RPC 100005/1 on 192.168.1.244
> VFS: Mounted root (nfs filesystem) on device 0:11.
> Freeing unused kernel memory: 124k init
> PHY: f0003000:00 - Link is Up - 100/Full
>
> # ping 192.168.1.2 returns proper results.
>
> PHY Not working:
> ...
> mpc52xx MII bus: probed
> TCP cubic registered
> NET: Registered protocol family 17
> IP-Config: Complete:
> device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2,
> host=192.168.1.245, domain=, nis-domain=(none),
> bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath=
> VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
> Freeing unused kernel memory: 124k init
>
> # ping 192.168.1.2 hangs
>
>
> The second snipped does not have "Looking up.." messages because it
> boots from flash. Main difference is "PHY: f0003000:00 - Link is Up - 100/Full"
> which does not appear at the failing case.
>
> Linux Version is 2.6.35.7 patched with xenomai 2.5
> U-Boot 2010.06 (Aug 05 2010 - 19:54:45)
>
> Linux configuration see below: ( i left most entries out that are not set)
> I also experimented with different settings but finally only
> CONFIG_FEC_MPC52xx=y and CONFIG_FEC_MPC52xx_MDIO=y
> seem to be of any relevance. If both are set, the adapter works
> when initialized by uboot.
>
> Any help or tips will be very much appreciated,
>
> Regards, Peter
>
>
> Linux .config
>
> ...
> #
> # Platform support
> #
> # CONFIG_PPC_CHRP is not set
> # CONFIG_MPC5121_ADS is not set
> # CONFIG_MPC5121_GENERIC is not set
> CONFIG_PPC_MPC52xx=y
> CONFIG_PPC_MPC5200_SIMPLE=y
> # CONFIG_PPC_EFIKA is not set
> CONFIG_PPC_LITE5200=y
> # CONFIG_PPC_MEDIA5200 is not set
> CONFIG_PPC_MPC5200_BUGFIX=y
> # CONFIG_PPC_MPC5200_GPIO is not set
> CONFIG_PPC_MPC5200_LPBFIFO=y
>
> CONFIG_PPC_BESTCOMM=y
> CONFIG_PPC_BESTCOMM_FEC=y
> CONFIG_PPC_BESTCOMM_GEN_BD=y
> # CONFIG_SIMPLE_GPIO is not set
> ..
> # Bus options
> #
> CONFIG_ZONE_DMA=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_PPC_PCI_CHOICE=y
> ...
> #
> # Generic Driver Options
> #
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_MTD=y
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_CMDLINE_PARTS=y
>
> #
> # MII PHY device drivers
> #
> CONFIG_LXT_PHY=y ## Does not seem to have any influence
> CONFIG_NET_ETHERNET=y
> CONFIG_MII=y
> CONFIG_ETHOC=y ## Does not seem to have any influence
> CONFIG_FEC_MPC52xx=y ## Must be Y in roder to get adapter working with uboot's init
> CONFIG_FEC_MPC52xx_MDIO=y ## Must be Y in roder to get adapter working with uboot's init
^ permalink raw reply
* Re: [PATCH 14/15] ppc64 iommu: use coherent_dma_mask for alloc_coherent
From: Benjamin Herrenschmidt @ 2010-11-29 0:58 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <1284573958-8397-15-git-send-email-nacc@us.ibm.com>
On Wed, 2010-09-15 at 11:05 -0700, Nishanth Aravamudan wrote:
> The IOMMU code has been passing the dma-mask instead of the
> coherent_dma_mask to the iommu allocator. Coherent allocations should
> be made using the coherent_dma_mask.
Won't that break macio devices too ? afaik, they don't set
coherent_dma_mask. Have you tried booting on a G5 with iommu enabled ?
(It may not be broken, just asking...)
Cheers,
Ben.
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> ---
> We currently don't check the mask other than to warn when its being set,
> so I don't think this is stable material.
> ---
> arch/powerpc/kernel/dma-iommu.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index 6e54a0f..e755415 100644
> --- a/arch/powerpc/kernel/dma-iommu.c
> +++ b/arch/powerpc/kernel/dma-iommu.c
> @@ -19,7 +19,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
> - dma_handle, device_to_mask(dev), flag,
> + dma_handle, dev->coherent_dma_mask, flag,
> dev_to_node(dev));
> }
>
^ permalink raw reply
* Re: [PATCH 15/15] ppc/vio: ensure dma_coherent_mask is set
From: Benjamin Herrenschmidt @ 2010-11-29 1:02 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Brian King, Paul Mackerras, linuxppc-dev, Milton Miller
In-Reply-To: <1284573958-8397-16-git-send-email-nacc@us.ibm.com>
On Wed, 2010-09-15 at 11:05 -0700, Nishanth Aravamudan wrote:
> Without this change drivers, such as ibmvscsi, fail to load with the
> previous change.
> ---
So you broke bisection... fold the patch instead or invert them
Cheers,
Ben.
> arch/powerpc/kernel/vio.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index 3c3083f..e8d73de 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1259,6 +1259,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
> viodev->dev.parent = &vio_bus_device.dev;
> viodev->dev.bus = &vio_bus_type;
> viodev->dev.release = vio_dev_release;
> + /* needed to ensure proper operation of coherent allocations
> + * later, in case driver doesn't set it explicitly */
> + dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64));
>
> /* register with generic device framework */
> if (device_register(&viodev->dev)) {
^ permalink raw reply
* Re: [PATCH 3/5] fpga: add basic CARMA board support
From: Stephen Neuendorffer @ 2010-11-29 3:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel, Ira W. Snyder
In-Reply-To: <1290991094.32570.213.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
On Sun, Nov 28, 2010 at 4:38 PM, Benjamin Herrenschmidt <
benh@kernel.crashing.org> wrote:
> On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> > This adds basic support for the system controller FPGA on the OVRO CARMA
> > board. This patch only adds infrastructure that will be used by later
> > drivers.
>
> Oh and another comment ...
>
> I'm not sure about drivers/fpga ... in the end, one would expect such a
> directory to contain stuff to manipulate FPGAs in the sense of
> downloading bitfiles, instanciating devices (device-tree manipulation ?)
> etc...
>
> From what I see in your code, the fact that these are FPGAs is almost
> irrelevant, you are providing support for "carma" devices, and such are
> no different than some other platform device, they just happen to be
> implemented as FPGAs. Or am I missing something ?
>
> Cheers,
> Ben.
>
>
Generally, I agree with this: There doesn't seem to be anything generic
about
the FPGA support you are adding, it seems very specific to the CARMA
hardware.
I'm generally not opposed to drivers/fpga: I think that colocating drivers
for things
that are basically FPGA compute platforms isn't necessarily a bad idea, but
I think it would be better if those devices were colocated because they
shared
some FPGA-oriented infrastructure, which this doesn't seem to do.
Currently,
generic infrastructure has been going into drivers/char, and drivers
themselves have
been going wherever they seem best. Really what you have is 2 character
devices: one
for configuration, and one for access.
Steve
[-- Attachment #2: Type: text/html, Size: 2129 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Poll VPA for topology changes and update NUMA maps
From: Benjamin Herrenschmidt @ 2010-11-29 3:44 UTC (permalink / raw)
To: Jesse Larrew; +Cc: markn, pmac, tbreeds, lkessler, mjwolf, linuxppc-dev
In-Reply-To: <20101109232501.17098.55112.sendpatchset@manic8ball.ltc.austin.ibm.com>
On Tue, 2010-11-09 at 16:25 -0700, Jesse Larrew wrote:
> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>
> This patch sets a timer during boot that will periodically poll the
> associativity change counters in the VPA. When a change in
> associativity is detected, it retrieves the new associativity domain
> information via the H_HOME_NODE_ASSOCIATIVITY hcall and updates the
> NUMA node maps and sysfs entries accordingly. Note that since the
> ibm,associativity device tree property does not exist on configurations
> with both NUMA and SPLPAR enabled, no device tree updates are necessary.
>
> Signed-off-by: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
> ---
No fundamental objection, just quick nits before I merge:
> +
> +/* Vrtual Processor Home Node (VPHN) support */
> +#define VPHN_NR_CHANGE_CTRS (8)
> +static u8 vphn_cpu_change_counts[NR_CPUS][VPHN_NR_CHANGE_CTRS];
> +static cpumask_t cpu_associativity_changes_mask;
> +static void topology_work_fn(struct work_struct *work);
> +static DECLARE_WORK(topology_work, topology_work_fn);
Remove the prototype for topology_work_fn() and puts the DECLARE_WORK
right below the function itself.
> +static void topology_timer_fn(unsigned long ignored);
> +static struct timer_list topology_timer =
> + TIMER_INITIALIZER(topology_timer_fn, 0, 0);
Same deal.
> +static void set_topology_timer(void);
> +int stop_topology_update(void);
> +
> +/*
> + * Store the current values of the associativity change counters in the
> + * hypervisor.
> + */
> +static void setup_cpu_associativity_change_counters(void)
> +{
> + int cpu = 0;
> +
> + for_each_possible_cpu(cpu) {
> + int i = 0;
> + u8 *counts = vphn_cpu_change_counts[cpu];
> + volatile u8 *hypervisor_counts = lppaca[cpu].vphn_assoc_counts;
> +
> + for (i = 0; i < VPHN_NR_CHANGE_CTRS; i++) {
> + counts[i] = hypervisor_counts[i];
> + }
> + }
> +
> + return;
> +}
> +
> +/*
> + * The hypervisor maintains a set of 8 associativity change counters in
> + * the VPA of each cpu that correspond to the associativity levels in the
> + * ibm,associativity-reference-points property. When an associativity
> + * level changes, the corresponding counter is incremented.
> + *
> + * Set a bit in cpu_associativity_changes_mask for each cpu whose home
> + * node associativity levels have changed.
> + */
> +static void update_cpu_associativity_changes_mask(void)
> +{
> + int cpu = 0;
> + cpumask_t *changes = &cpu_associativity_changes_mask;
> +
> + cpumask_clear(changes);
> +
> + for_each_possible_cpu(cpu) {
> + int i;
> + u8 *counts = vphn_cpu_change_counts[cpu];
> + volatile u8 *hypervisor_counts = lppaca[cpu].vphn_assoc_counts;
> +
> + for (i = 0; i < VPHN_NR_CHANGE_CTRS; i++) {
> + if (hypervisor_counts[i] > counts[i]) {
> + counts[i] = hypervisor_counts[i];
> +
> + if (!(cpumask_test_cpu(cpu, changes)))
> + cpumask_set_cpu(cpu, changes);
> + }
> + }
This is a tad sub-optimal. I'd just set a local variable, and
after the inside loop set the cpumask bit when that variable is set.
Also, keep another variable that accumulate all bits set and return
its value so you don't have to re-check the mask in the caller.
cpumask operations can be expensive.
> + }
> +
> + return;
You don't need a return; at the end of a function.
> +}
> +
> +/* 6 64-bit registers unpacked into 12 32-bit associativity values */
> +#define VPHN_ASSOC_BUFSIZE (6*sizeof(u64)/sizeof(u32))
> +
> +/*
> + * Convert the associativity domain numbers returned from the hypervisor
> + * to the sequence they would appear in the ibm,associativity property.
> + */
> +static int vphn_unpack_associativity(const long *packed, unsigned int *unpacked)
> +{
> + int i = 0;
> + int nr_assoc_doms = 0;
> + const u16 *field = (const u16*) packed;
> +
> +#define VPHN_FIELD_UNUSED (0xffff)
> +#define VPHN_FIELD_MSB (0x8000)
> +#define VPHN_FIELD_MASK (~VPHN_FIELD_MSB)
> +
> + for (i = 0; i < VPHN_ASSOC_BUFSIZE; i++) {
> + if (*field == VPHN_FIELD_UNUSED) {
> + /* All significant fields processed, and remaining
> + * fields contain the reserved value of all 1's.
> + * Just store them.
> + */
> + unpacked[i] = *((u32*)field);
> + field += 2;
> + }
> + else if (*field & VPHN_FIELD_MSB) {
> + /* Data is in the lower 15 bits of this field */
> + unpacked[i] = *field & VPHN_FIELD_MASK;
> + field++;
> + nr_assoc_doms++;
> + }
> + else {
> + /* Data is in the lower 15 bits of this field
> + * concatenated with the next 16 bit field
> + */
> + unpacked[i] = *((u32*)field);
> + field += 2;
> + nr_assoc_doms++;
> + }
> + }
> +
> + return nr_assoc_doms;
> +}
> +
> +/*
> + * Retrieve the new associativity information for a virtual processor's
> + * home node.
> + */
> +static long hcall_vphn(unsigned long cpu, unsigned int *associativity)
> +{
> + long rc = 0;
> + long retbuf[PLPAR_HCALL9_BUFSIZE] = {0};
> + u64 flags = 1;
> + int hwcpu = get_hard_smp_processor_id(cpu);
> +
> + rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, retbuf, flags, hwcpu);
> + vphn_unpack_associativity(retbuf, associativity);
> +
> + return rc;
> +}
> +
> +static long
> +vphn_get_associativity(unsigned long cpu, unsigned int *associativity)
> +{
Nowadays, we prefer keeping the "static long" and the function name on
the same line. If you really want to avoid >80 col (I don't care myself
much as long as you stick below 100) then move the second argument down
one line.
> + long rc = 0;
> +
> + rc = hcall_vphn(cpu, associativity);
> +
> + switch (rc) {
> + case H_FUNCTION:
> + printk(KERN_INFO
> + "VPHN is not supported. Disabling polling...\n");
> + stop_topology_update();
> + break;
> + case H_HARDWARE:
> + printk(KERN_ERR
> + "hcall_vphn() experienced a hardware fault "
> + "preventing VPHN. Disabling polling...\n");
> + stop_topology_update();
> + }
> +
> + return rc;
> +}
> +
> +/*
> + * Update the node maps and sysfs entries for each cpu whose home node
> + * has changed.
> + */
> +int arch_update_cpu_topology(void)
> +{
> + int cpu = 0, nid = 0, old_nid = 0;
> + unsigned int associativity[VPHN_ASSOC_BUFSIZE] = {0};
> + struct sys_device *sysdev = NULL;
> +
> + for_each_cpu_mask(cpu, cpu_associativity_changes_mask) {
> + vphn_get_associativity(cpu, associativity);
> + nid = associativity_to_nid(associativity);
> +
> + if (nid < 0 || !node_online(nid))
> + nid = first_online_node;
> +
> + old_nid = numa_cpu_lookup_table[cpu];
> +
> + /* Disable hotplug while we update the cpu
> + * masks and sysfs.
> + */
> + get_online_cpus();
> + unregister_cpu_under_node(cpu, old_nid);
> + unmap_cpu_from_node(cpu);
> + map_cpu_to_node(cpu, nid);
> + register_cpu_under_node(cpu, nid);
> + put_online_cpus();
> +
> + sysdev = get_cpu_sysdev(cpu);
> + if (sysdev)
> + kobject_uevent(&sysdev->kobj, KOBJ_CHANGE);
> + }
> +
> + return 1;
> +}
That looks terribly expensive. Might be worth considering adding a way
to sysfs to "mv" an object around in the future.
> +static void topology_work_fn(struct work_struct *work)
> +{
> + rebuild_sched_domains();
> +}
> +
> +void topology_schedule_update(void)
> +{
> + schedule_work(&topology_work);
> +}
> +
> +static void topology_timer_fn(unsigned long ignored)
> +{
> + update_cpu_associativity_changes_mask();
> + if (!cpumask_empty(&cpu_associativity_changes_mask))
> + topology_schedule_update();
> + set_topology_timer();
> +}
I wonder if we really need that cpumask and timer overall. We might be
better off just having a per-cpu copy of the counters and check them in
the timer interrupt, it's low enough overhead don't you think ?
> +static void set_topology_timer(void)
> +{
> + topology_timer.data = 0;
> + topology_timer.expires = jiffies + 60 * HZ;
> + add_timer(&topology_timer);
> +}
> +
> +/*
> + * Start polling for VPHN associativity changes.
> + */
> +int start_topology_update(void)
> +{
> + int rc = 0;
> +
> + if (firmware_has_feature(FW_FEATURE_VPHN)) {
> + setup_cpu_associativity_change_counters();
> + init_timer_deferrable(&topology_timer);
> + set_topology_timer();
> + rc = 1;
> + }
> +
> + return rc;
> +}
> +__initcall(start_topology_update);
> +
> +/*
> + * Disable polling for VPHN associativity changes.
> + */
> +int stop_topology_update(void)
> +{
> + return del_timer(&topology_timer);
> +}
del_timer_sync() ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Record vma->phys_addr in ioremap()
From: Michael Ellerman @ 2010-11-29 4:26 UTC (permalink / raw)
To: linuxppc-dev
The vmalloc code can track the physical address of a vma, when the
vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
Because get_vm_area_caller() doesn't know it's being called for
ioremap() it's up to the arch code to set the phys_addr. A bunch
of other arch's do this, I'm not sure why powerpc doesn't?
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/mm/pgtable_32.c | 1 +
arch/powerpc/mm/pgtable_64.c | 2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index a87ead0..71932d0 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -230,6 +230,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (area == 0)
return NULL;
+ area->phys_addr = p;
v = (unsigned long) area->addr;
} else {
v = (ioremap_bot -= size);
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 21d6dfa..88927a0 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -223,6 +223,8 @@ void __iomem * __ioremap_caller(phys_addr_t addr, unsigned long size,
caller);
if (area == NULL)
return NULL;
+
+ area->phys_addr = paligned;
ret = __ioremap_at(paligned, area->addr, size, flags);
if (!ret)
vunmap(area->addr);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Record vma->phys_addr in ioremap()
From: Benjamin Herrenschmidt @ 2010-11-29 4:56 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <e4aea657faf920a0d207e582724ccd7ef08487f1.1291004790.git.michael@ellerman.id.au>
On Mon, 2010-11-29 at 15:26 +1100, Michael Ellerman wrote:
> The vmalloc code can track the physical address of a vma, when the
> vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
>
> Because get_vm_area_caller() doesn't know it's being called for
> ioremap() it's up to the arch code to set the phys_addr. A bunch
> of other arch's do this, I'm not sure why powerpc doesn't?
Because I never noticed ? :-)
Cheers,
Ben.
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/mm/pgtable_32.c | 1 +
> arch/powerpc/mm/pgtable_64.c | 2 ++
> 2 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index a87ead0..71932d0 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -230,6 +230,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
> area = get_vm_area_caller(size, VM_IOREMAP, caller);
> if (area == 0)
> return NULL;
> + area->phys_addr = p;
> v = (unsigned long) area->addr;
> } else {
> v = (ioremap_bot -= size);
> diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
> index 21d6dfa..88927a0 100644
> --- a/arch/powerpc/mm/pgtable_64.c
> +++ b/arch/powerpc/mm/pgtable_64.c
> @@ -223,6 +223,8 @@ void __iomem * __ioremap_caller(phys_addr_t addr, unsigned long size,
> caller);
> if (area == NULL)
> return NULL;
> +
> + area->phys_addr = paligned;
> ret = __ioremap_at(paligned, area->addr, size, flags);
> if (!ret)
> vunmap(area->addr);
^ permalink raw reply
* Re: [PATCH] powerpc: Record vma->phys_addr in ioremap()
From: Michael Ellerman @ 2010-11-29 5:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1291006613.32570.288.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Mon, 2010-11-29 at 15:56 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-11-29 at 15:26 +1100, Michael Ellerman wrote:
> > The vmalloc code can track the physical address of a vma, when the
> > vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
> >
> > Because get_vm_area_caller() doesn't know it's being called for
> > ioremap() it's up to the arch code to set the phys_addr. A bunch
> > of other arch's do this, I'm not sure why powerpc doesn't?
>
> Because I never noticed ? :-)
Yeah I figured. It seems to go back past 2.6.12 so who knows when it
went in, anyway it's useful.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: Benjamin Herrenschmidt @ 2010-11-29 5:44 UTC (permalink / raw)
To: pacman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101105064332.1678.qmail@kosh.dhis.org>
> I have a mostly-finished patch to do the above. I'll include it below, but
> first a few words about why it's only mostly finished.
>
> The other Pegasos workarounds are in fixup_device_tree_chrp, and I don't see
> anything like an "if(machine_is_pegasos)" around them. What keeps them from
> being erroneously run on other CHRP-type machines? I made this patch mainly
> by copying pieces of other functions from prom_init.c, but couldn't find the
> "test for Pegasos before running a Pegasos workaround" piece.
Probably bcs the condition they test for really only happens on
pegasos ? :-)
I agree it's a bit gross tho.
The "ranges" property fixup is pretty harmless in any case. The other
fixup might be worth moving to a separate pegasos-only function in which
you would test for a pegasos properly and add your own stuff.
> Another issue is, since the firmware doesn't give me a "compatible" property
> with the details of the controller, I just have to assume that it's
> little-endian. I'm not sure if that's clean, since the real ohci driver
> supports both endiannesses, with at least 3 different Kconfig options(!) to
> choose between them.
If it's PCI it's LE or somebody needs to be shot :-)
> Then there's the volatile which I guess is supposed to be replaced by
> something else, but I don't know what the something else is. I believe this
> usage is extremely close to what volatile was meant for.
Yeah, it's fine, just add something like that on the next line:
asm volatile("eieio" : : : "memory");
> Finally, when I updated to a more recent upstream kernel to test the patch, I
> found that an intervening commit (3df7169e73fc1d71a39cffeacc969f6840cdf52b,
> OHCI: work around for nVidia shutdown problem) has had a major effect,
> on the appearance of my bug.
>
> Before that change, the window in which the bug could strike was from the end
> of prom_init (when the kernel believes that devices are quiescent) to the
> initialization of the ohci-hcd driver (which actually quietens the device, or
> at least directs its scribbling to a properly allocated page). After the
> change, the window ends at some point early in the PCI bus setup. That's a
> window so small that with a new kernel, I can't provoke a symptom even if I
> try.
Right but it's very fishy, ie, it may still be DMA'ing and god knows
where ... you may or may not get lucky. I'd rather you do a proper
fixup :-)
Cheers,
Ben.
> Mostly-finished patch:
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 941ff4d..a14f21b 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2237,6 +2237,81 @@ static void __init fixup_device_tree_chrp(void)
> }
> }
> }
> +
> +/*
> + * Pegasos firmware doesn't quiesce OHCI controllers, so do it manually
> + */
> +static void __init pegasos_quiesce(void)
> +{
> + phandle node, parent_node;
> + ihandle parent_ih;
> + int rc;
> + char type[16], *path;
> + u32 prop[5], map_size;
> + prom_arg_t ohci_virt;
> +
> + for (node = 0; prom_next_node(&node); ) {
> + memset(type, 0, sizeof(type));
> + prom_getprop(node, "device_type", type, sizeof(type));
> + if (strcmp(type, RELOC("usb")) != 0)
> + continue;
> +
> + /* Parent should be a PCI bus (so class-code makes sense).
> + class-code should be 0x0C0310 */
> + parent_node = call_prom("parent", 1, 1, node);
> + if (!parent_node)
> + continue;
> + rc = prom_getprop(node, "class-code", prop, sizeof(u32));
> + if (rc != sizeof(u32) || prop[0] != 0x0c0310)
> + continue;
> +
> + rc = prom_getprop(node, "assigned-addresses",
> + prop, 5*sizeof(u32));
> + if (rc != 5*sizeof(u32))
> + continue;
> +
> + /* Open the parent and call map-in */
> +
> + /* It seems OF doesn't null-terminate the path :-( */
> + path = RELOC(prom_scratch);
> + memset(path, 0, PROM_SCRATCH_SIZE);
> +
> + if (call_prom("package-to-path", 3, 1, parent_node,
> + path, PROM_SCRATCH_SIZE-1) == PROM_ERROR)
> + continue;
> + parent_ih = call_prom("open", 1, 1, path);
> +
> + /* Get the OHCI node's pathname, for printing later */
> + memset(path, 0, PROM_SCRATCH_SIZE);
> + call_prom("package-to-path", 3, 1, node,
> + path, PROM_SCRATCH_SIZE-1);
> +
> + map_size = prop[4];
> + if (call_prom_ret("call-method", 6, 2, &ohci_virt,
> + ADDR("map-in"), parent_ih,
> + map_size, prop[0], prop[1], prop[2]) == 0) {
> + prom_printf("resetting OHCI device %s...", path);
> +
> + /* Set HostControllerReset (==1) in HcCommandStatus,
> + * located at offset 8 in the register area. The <<24
> + * is because the CPU is big-endian and the device is
> + * little-endian. */
> + *(volatile u32 *)(ohci_virt + 8) |= (1<<24);
> +
> + /* controller should acknowledge by zeroing the bit
> + * within 10us. waiting 1ms should be plenty. */
> + call_prom("interpret", 1, 1, "1 ms");
> + if (*(volatile u32 *)(ohci_virt + 8) & (1<<24))
> + prom_printf("failed\n");
> + else
> + prom_printf("done\n");
> +
> + call_prom("call-method", 4, 1, ADDR("map-out"),
> + parent_ih, map_size, ohci_virt);
> + }
> + call_prom("close", 1, 0, parent_ih);
> + }
> +}
> #else
> #define fixup_device_tree_chrp()
> #endif
> @@ -2642,6 +2717,7 @@ unsigned long __init prom_init(unsigned long r3, unsigned long r4,
> * devices etc...
> */
> prom_printf("Calling quiesce...\n");
> + pegasos_quiesce();
> call_prom("quiesce", 0, 0);
>
> /*
>
^ permalink raw reply
* Re: RFC: Mega rename of device tree routines from of_*() to dt_*()
From: David Gibson @ 2010-11-29 5:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, linux-mips, microblaze-uclinux, devicetree-discuss,
LKML, linuxppc-dev list, sparclinux
In-Reply-To: <1290692075.689.20.camel@concordia>
[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]
On Fri, Nov 26, 2010 at 12:34:35AM +1100, Michael Ellerman wrote:
> On Thu, 2010-11-25 at 01:03 +1100, Michael Ellerman wrote:
> > Hi all,
> >
> > There were some murmurings on IRC last week about renaming the of_*()
> > routines.
> ...
> > The thinking is that on many platforms that use the of_() routines
> > OpenFirmware is not involved at all, this is true even on many powerpc
> > platforms. Also for folks who don't know the OpenFirmware connection
> > it reads as "of", as in "a can of worms".
> ...
> > So I'm hoping people with either say "YES this is a great idea", or "NO
> > this is stupid".
>
> I'm still hoping, but so far it seems most people have got better things
> to do, and of those that do have an opinion the balance is slightly
> positive.
>
> So here's a first cut of a patch to add the new names. I've not touched
> of_platform because that is supposed to go away. That will lead to some
> odd looking code in the interim, but I think is the right approach.
>
> Most of these are straight renames, but some have changed more
> substantially. The routines for the flat tree have all become fdt_foo().
I'm a little uneasy about using the same prefix as libfdt (fdt_foo())
for routines that have a different implementation and different names
/ semantics to the libfdt routines.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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