Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
On Fri, 2009-10-09 at 07:14 +0200, Wolfram Sang wrote: > And while doing this and figuring the pro/cons of those methods, I > stumbled over this commit: > > gpio: pca953x: Get platform_data from OpenFirmware > (1965d30356c1c65660ba3330927671cfe81acdd5) Aside from any issues you have with the properties themselves, what's your take on this approach? Personally, I just got tired of waiting for someone else to solve the pdata/OF problem. So I submitted that commit as an attempt at something very simple and unobtrusive to the device driver itself. It seems pretty clean to me, but I'm curious to see if others have any better ideas. - Nate ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote:
> For your future reference, patches that look at the device tree should
> also cc: devicetree-disc...@lists.ozlabs.org so that new bindings can
> be reviewed and common mistakes can be avoided. It is expected that
> new device tree bindings are accompanied with documentation describing
> what the binding is for and how it should be used (see
> Documentation/powerpc/dts-bindings).
>
> I know this change is already in mainline, but can you please post the
> device tree fragment that you're using to describe this chip? I want
> to make sure we don't get stuck with things in the kernel that will be
> hard to maintain in the long term.
Hi Grant,
Sorry for neglecting to include devicetree-discuss on that one. I was
in fact aware of this list, and subscribe to it. I really just forgot
in this case.
I also have a documentation patch for it that went along with it, but it
wasn't ready in time and so it's been sitting in our local patch queue.
I can submit that soon, but it probably makes sense for Wolfram to
voice whatever his concerns were about "questionable" properties before
I document what's there.
Here's an example device tree node for this case:
gpio1: g...@18 {
compatible = "nxp,pca9557";
reg = <0x18>;
#gpio-cells = <2>;
gpio-controller;
polarity = <0x00>;
};
In this case, the linux,gpio-base property wasn't specified. But, the
use case is identical to the pdata->gpio_base field. "polarity" is used
for specifying polarity inversion for each line, and is in the same
format of the 'polarity inversion' register on the chip. My reasoning
in the property naming was as follows:
linux,gpio-base: Linux-specific as it relates to internal GPIO
numbering. So, it's prefixed with "linux,"
polarity: Dictated by how hardware is wired up, so it's needed
regardless of the OS.
- Nate
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -next 3/4] powerpc/85xx: Add defconfig for X-ES MPC85xx boards
Signed-off-by: Nate Case --- arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1821 +++ 1 files changed, 1821 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/85xx/xes_mpc85xx_defconfig diff --git a/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig b/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig new file mode 100644 index 000..2552cbe --- /dev/null +++ b/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig @@ -0,0 +1,1821 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.30-rc6 +# Thu Jun 11 11:25:17 2009 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +CONFIG_PPC_85xx=y +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_E500=y +# CONFIG_PPC_E500MC is not set +CONFIG_BOOKE=y +CONFIG_FSL_BOOKE=y +CONFIG_FSL_EMB_PERFMON=y +# CONFIG_PHYS_64BIT is not set +CONFIG_SPE=y +CONFIG_PPC_MMU_NOHASH=y +CONFIG_PPC_BOOK3E_MMU=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set +CONFIG_IRQ_PER_CPU=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +CONFIG_GENERIC_GPIO=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +CONFIG_GENERIC_TBSYNC=y +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +CONFIG_DTC=y +CONFIG_DEFAULT_UIMAGE=y +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +CONFIG_AUDIT=y +# CONFIG_AUDITSYSCALL is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_GROUP_SCHED is not set +# CONFIG_CGROUPS is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +CONFIG_KALLSYMS_EXTRA_PASS=y +# CONFIG_STRIP_ASM_SYMS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_PCI_QUIRKS=y +CONFIG_SLUB_DEBUG=y +CONFIG_COMPAT_BRK=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_IOREMAP_PROT=y +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_ARCH_TRACEHOOK=y +CONFIG_USE_GENERIC_SMP_HELPERS=y +# CONFIG_SLOW_WORK is not set +# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_STOP_MACHINE=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="cfq" +# CONFIG_FREEZER is not set +CONFIG_PPC_MSI_BITMAP=y + +# +# Platform support +# +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +CONFIG_MPC85xx=y +# CONFIG_MPC8540_AD
[PATCH -next 4/4] powerpc/bootwrapper: Custom build options for XPedite52xx targets
Some XPedite52xx boards have a legacy boot loader requiring some special care in the boot wrapper. The use of cuboot-85xx is needed to fix up embedded device trees, and a custom link address is specified to accommodate the boot loader and larger kernel image sizes used on X-ES MPC85xx platforms. Signed-off-by: Nate Case --- arch/powerpc/boot/wrapper |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index 3ac75ae..4db487d 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -225,6 +225,10 @@ asp834x-redboot) platformo="$object/fixed-head.o $object/redboot-83xx.o" binary=y ;; +xpedite52*) +link_address='0x140' +platformo=$object/cuboot-85xx.o +;; esac vmz="$tmpdir/`basename \"$kernel\"`.$ext" -- 1.6.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -next 1/4] powerpc/85xx: Add platform support for X-ES MPC85xx boards
Add support for X-ES single-board computers based on the Freescale
MPC85xx processors.
Signed-off-by: Nate Case
---
arch/powerpc/platforms/85xx/Kconfig | 10 +
arch/powerpc/platforms/85xx/Makefile |1 +
arch/powerpc/platforms/85xx/xes_mpc85xx.c | 282 +
3 files changed, 293 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/xes_mpc85xx.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index 43d385c..e0d39bf 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -64,6 +64,16 @@ config KSI8560
help
This option enables support for the Emerson KSI8560 board
+config XES_MPC85xx
+ bool "X-ES single-board computer"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the various single-board
+ computers from Extreme Engineering Solutions (X-ES) based on
+ Freescale MPC85xx processors.
+ Manufacturer: Extreme Engineering Solutions, Inc.
+ URL: <http://www.xes-inc.com/>
+
config STX_GP3
bool "Silicon Turnkey Express GP3"
help
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index a857b35..835733f 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_SBC8560) += sbc8560.o
obj-$(CONFIG_SBC8548) += sbc8548.o
obj-$(CONFIG_SOCRATES)+= socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560)+= ksi8560.o
+obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
\ No newline at end of file
diff --git a/arch/powerpc/platforms/85xx/xes_mpc85xx.c
b/arch/powerpc/platforms/85xx/xes_mpc85xx.c
new file mode 100644
index 000..ee01532
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/xes_mpc85xx.c
@@ -0,0 +1,282 @@
+/*
+ * Copyright (C) 2009 Extreme Engineering Solutions, Inc.
+ *
+ * X-ES board-specific functionality
+ *
+ * Based on mpc85xx_ds code from Freescale Semiconductor, Inc.
+ *
+ * Author: Nate Case
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* A few bit definitions needed for fixups on some boards */
+#define MPC85xx_L2CTL_L2E 0x8000 /* L2 enable */
+#define MPC85xx_L2CTL_L2I 0x4000 /* L2 flash invalidate */
+#define MPC85xx_L2CTL_L2SIZ_MASK 0x3000 /* L2 SRAM size (R/O) */
+
+void __init xes_mpc85xx_pic_init(void)
+{
+ struct mpic *mpic;
+ struct resource r;
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (np == NULL) {
+ printk(KERN_ERR "Could not find open-pic node\n");
+ return;
+ }
+
+ if (of_address_to_resource(np, 0, &r)) {
+ printk(KERN_ERR "Failed to map mpic register space\n");
+ of_node_put(np);
+ return;
+ }
+
+ mpic = mpic_alloc(np, r.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET |
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS,
+ 0, 256, " OpenPIC ");
+ BUG_ON(mpic == NULL);
+ of_node_put(np);
+
+ mpic_init(mpic);
+}
+
+static void xes_mpc85xx_configure_l2(void __iomem *l2_base)
+{
+ volatile uint32_t ctl, tmp;
+
+ asm volatile("msync; isync");
+ tmp = in_be32(l2_base);
+
+ /*
+* xMon may have enabled part of L2 as SRAM, so we need to set it
+* up for all cache mode just to be safe.
+*/
+ printk(KERN_INFO "xes_mpc85xx: Enabling L2 as cache\n");
+
+ ctl = MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2I;
+ if (machine_is_compatible("MPC8540") ||
+ machine_is_compatible("MPC8560"))
+ /*
+* Assume L2 SRAM is used fully for cache, so set
+* L2BLKSZ (bits 4:5) to match L2SIZ (bits 2:3).
+*/
+ ctl |= (tmp & MPC85xx_L2CTL_L2SIZ_MASK) >> 2;
+
+ asm volatile("msync; isync");
+ out_be32(l2_base, ctl);
+ asm volatile("msync; isync");
+}
+
+static void xes_mpc85xx_fixups(void)
+{
+ struct device_node *np;
+ int err;
+
+ /*
+* Legacy xMon firmware on some X-ES boards does not enable L2
+* as cache. We must ensure that they get enabled here.
+*/
+ for_each_node_by_name(np, "l2-cache-controller") {
+ struct resource r[2];
+
[PATCH v3 -next 0/0] powerpc/85xx: Support for X-ES MPC85xx boards
Hello, This is v3 of the "Add support for X-ES MPC85xx boards" patch submitted earlier. This time it's split up as Kumar requested: [1/4] powerpc/85xx: Add platform support for X-ES MPC85xx boards [2/4] powerpc/85xx: Add dts files for X-ES MPC85xx boards [3/4] powerpc/85xx: Add defconfig for X-ES MPC85xx boards [4/4] powerpc/bootwrapper: Custom build options for XPedite52xx targets This shouldn't be too invasive since the bulk of the changes are new files. This version should address the items brought up by Kumar and David Gibson. -- Nate Case ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: System clock systems to be twice as fast as RTC
On Thu, 2009-06-11 at 08:13 -0700, Subodh Nijsure wrote: > The system clock seems to be running twice as as fast as RTC, > > sh-2.05b# date ; sleep 60 ; date > Fri Sep 11 01:37:11 UTC 1970 > Fri Sep 11 01:37:41 UTC 1970 That's strange, but note that "date" reads the system clock and not the RTC. Use "hwclock" for the RTC. -- Nate Case ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
Hi David,
Thanks for the comments.
On Thu, 2009-06-11 at 11:32 +1000, David Gibson wrote:
> These last two aren't standard properties, so should probably be
> "xes,form-factor" and "xes,boot-bank".
I'll just delete them for now since they're not critical.
> > + pmcslots {
>
> What does this structure model? Without any reg properties it's kind
> of hard to see what you could do with it.
This would be a bit more obvious to those familiar with CompactPCI and
PMC modules. It aims to describe how many PMC slots are in the system,
and gives information on whether or not a module is installed and if
it's monarch of the bus or not. So it's really just a description of
the hardware. The properties themselves are useful because you may have
to read from GPIO lines to get this information (which may be accessible
only via I2C, which can't be done too early in the kernel). A reg
property could be used just for indexing the slots, but there are no
real memory-mapped resources involved for the slot itself (that
information would go in the PCI nodes).
It'd be nice if we could get a device tree standard for this type of
information in the future, but for now I can just delete it since we
don't yet rely on it in the kernel.
> > +
> > + tbi2: tbi-...@11 {
> > + reg = <0x11>;
> > + device_type = "tbi-phy";
>
> And this one, too. Although this node should probably have a
> compatible property instead.
I don't think I can drop that device_type yet. All the other device
trees for Freescale boards use it, and the Freescale MDIO driver appears
to rely on it. A future patch I suppose?
> Analagous comments for the other device trees.
Thanks again. I'll fix up the other things you and Kumar mentioned and
re-submit today.
--
Nate Case
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
On Wed, 2009-06-10 at 18:24 -0500, Kumar Gala wrote:
> > + form-factor = "6U cPCI";
> > + boot-bank = <0x0>; /* 0: Primary flash, 1: Secondary flash */
>
> I'm not a fan of taking device trees with properties that are
> specified anywhere.
I can just delete them for now. They're purely informational at this
point, but might be used in the future.
> > + soc8...@ef00 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
> > + compatible = "simple-bus";
>
> should have a compat like:
>
> compatible = "fsl,mpc8572-immr", "simple-bus";
Are you sure about this? I only see "simple-bus" in the mpc8572ds.dts
files in mainline and your next branch -- so I was just following your
lead here.
I'll split up the patch as well. It's not obvious where the 4-line boot
wrapper change should go, so I can make that one separate as well unless
you object.
--
Nate Case
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
On Thu, 2009-06-11 at 07:43 +1000, Benjamin Herrenschmidt wrote: > G. > > It's -WAY TOO LATE- > > I though I made it clear that patches should be ready in -next > -before- the merge window, in fact, by rc7 or rc8, we should have a > good idea of what's going in either via my 'next' branch or pending > stuff in patchwork. > > I'll go through your pile and may still merge it this time around, but > you should be more proactive at feeding me with that stuff before it's > merge time. Hmm, I guess this sorta answers my question to Kumar about my recent -next submissions being eligible for 2.6.31. Sorry for not paying closer attention -- I just assumed we weren't even close to the cutoff time. I didn't even see Kumar's "next" branch until April 30th (around -rc6..rc7 time I think). -- Nate Case ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -next] powerpc/85xx: Add support for X-ES MPC85xx boards
Hi Kumar,
Thanks for the feedback. Response below:
> > +
> > + root = of_find_node_by_path("/");
> > + if (root == NULL)
> > + return;
> > +
> > + model = of_get_property(root, "model", NULL);
> > + if (strncasecmp(model, "xes,", strlen("xes,")) != 0)
> > + return;
>
> What is this check for?
Historical accident. A while back we somehow ended up with a case of
probe() succeeding when it shouldn't have, and this was the workaround.
I'll remove it since it's useless now.
> > +
> > + printk(KERN_INFO "X-ES MPC85xx-based single-board computer: %s\n",
> > + model + strlen("xes,"));
>
> Why not print the name from machine_id.name
Because machine_id->name will give us "X-ES MPC8572" from the machine
description rather than the actual board name (e.g., xpedite5370).
In our situation, we have several boards that share largely the same
hardware design. I decided to just put 1 machine definition per
processor rather than having a machine definition for every board (which
would get pretty crazy for our case). For example, we have at least 6
MPC8572-based boards with more on the way, but all of their changes can
be described in the device tree (e.g., changes in number of ethernet
ports or PCI express controllers), so there's no need for a machine
definition for all of them.
> > +machine_device_initcall(xes_mpc8572, xes_mpc85xx_publish_devices);
> > +machine_device_initcall(xes_mpc8548, xes_mpc85xx_publish_devices);
>
> Do you not need this for xes_mpc8540?
Yes, thanks. I'll fix this and the other things you mentioned and
re-submit. Will this be able to make it into your next tree destined
for 2.6.31?
--
Nate Case
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -next] powerpc/fsl-booke: Enable L1 cache on e500v1/e500v2/e500mc CPUs
Some boot loaders may not enable L1 instruction/data cache. Check if data and instruction caches are enabled, and enable them if needed. Signed-off-by: Nate Case --- arch/powerpc/include/asm/reg_booke.h |2 + arch/powerpc/kernel/cpu_setup_fsl_booke.S | 49 +++-- 2 files changed, 48 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 601ddbc..6bcf364 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -389,12 +389,14 @@ #define ICCR_CACHE 1 /* Cacheable */ /* Bit definitions for L1CSR0. */ +#define L1CSR0_CPE 0x0001 /* Data Cache Parity Enable */ #define L1CSR0_CLFC0x0100 /* Cache Lock Bits Flash Clear */ #define L1CSR0_DCFI0x0002 /* Data Cache Flash Invalidate */ #define L1CSR0_CFI 0x0002 /* Cache Flash Invalidate */ #define L1CSR0_DCE 0x0001 /* Data Cache Enable */ /* Bit definitions for L1CSR1. */ +#define L1CSR1_CPE 0x0001 /* Instruction Cache Parity Enable */ #define L1CSR1_ICLFR 0x0100 /* Instr Cache Lock Bits Flash Reset */ #define L1CSR1_ICFI0x0002 /* Instr Cache Flash Invalidate */ #define L1CSR1_ICE 0x0001 /* Instr Cache Enable */ diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index eb4b9ad..0adb50a 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -17,6 +17,40 @@ #include #include +_GLOBAL(__e500_icache_setup) + mfspr r0, SPRN_L1CSR1 + andi. r3, r0, L1CSR1_ICE + bnelr /* Already enabled */ + orisr0, r0, l1csr1_...@h + ori r0, r0, (L1CSR1_ICFI | L1CSR1_ICLFR | L1CSR1_ICE) + mtspr SPRN_L1CSR1, r0 /* Enable I-Cache */ + isync + blr + +_GLOBAL(__e500_dcache_setup) + mfspr r0, SPRN_L1CSR0 + andi. r3, r0, L1CSR0_DCE + bnelr /* Already enabled */ + msync + isync + li r0, 0 + mtspr SPRN_L1CSR0, r0 /* Disable */ + msync + isync + li r0, (L1CSR0_DCFI | L1CSR0_CLFC) + mtspr SPRN_L1CSR0, r0 /* Invalidate */ + isync +1: mfspr r0, SPRN_L1CSR0 + andi. r3, r0, L1CSR0_CLFC + bne+1b /* Wait for lock bits reset */ + orisr0, r0, l1csr0_...@h + ori r0, r0, L1CSR0_DCE + msync + isync + mtspr SPRN_L1CSR0, r0 /* Enable */ + isync + blr + _GLOBAL(__setup_cpu_e200) /* enable dedicated debug exception handling resources (Debug APU) */ mfspr r3,SPRN_HID0 @@ -25,7 +59,16 @@ _GLOBAL(__setup_cpu_e200) b __setup_e200_ivors _GLOBAL(__setup_cpu_e500v1) _GLOBAL(__setup_cpu_e500v2) - b __setup_e500_ivors + mflrr4 + bl __e500_icache_setup + bl __e500_dcache_setup + bl __setup_e500_ivors + mtlrr4 + blr _GLOBAL(__setup_cpu_e500mc) - b __setup_e500mc_ivors - + mflrr4 + bl __e500_icache_setup + bl __e500_dcache_setup + bl __setup_e500mc_ivors + mtlrr4 + blr -- 1.6.0.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -next] powerpc/85xx: Add support for X-ES MPC85xx boards
On Mon, 2009-06-08 at 17:52 -0500, Kumar Gala wrote:
> > +static void xes_mpc85xx_configure_l1(void)
> > +{
[snip]
>
> I'd prefer we move this into __setup_cpu_e500v1/__setup_cpu_e500v2 so
> its done for all processors regardless of platform.
How does something like this look? Let me know and I can test and
submit it separately.
- Nate
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index eb4b9ad..546804f 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -17,6 +17,34 @@
#include
#include
+_GLOBAL(__e500_icache_enable)
+ mfspr r3, SPRN_L1CSR1
+ orisr3, r3, l1csr1_...@h
+ ori r3, r3, (L1CSR1_ICFI | L1CSR1_ICE)
+ mtspr SPRN_L1CSR1, r3 /* Enable I-Cache */
+ isync
+ blr
+
+_GLOBAL(__e500_dcache_enable)
+ msync
+ isync
+ li r3, 0
+ mtspr SPRN_L1CSR0, r3 /* Disable */
+ msync
+ isync
+ li r3, L1CSR0_DCFI
+ mtspr SPRN_L1CSR0, r3 /* Invalidate */
+ msync
+ isync
+ mfspr r3, SPRN_L1CSR0
+ orisr3, r3, l1csr0_...@h
+ ori r3, r3, (L1CSR0_DCFI | L1CSR0_DCE)
+ msync
+ isync
+ mtspr SPRN_L1CSR0, r3 /* Enable */
+ isync
+ blr
+
_GLOBAL(__setup_cpu_e200)
/* enable dedicated debug exception handling resources (Debug APU) */
mfspr r3,SPRN_HID0
@@ -25,7 +53,16 @@ _GLOBAL(__setup_cpu_e200)
b __setup_e200_ivors
_GLOBAL(__setup_cpu_e500v1)
_GLOBAL(__setup_cpu_e500v2)
- b __setup_e500_ivors
+ mflrr4
+ bl __e500_icache_enable
+ bl __e500_dcache_enable
+ bl __setup_e500_ivors
+ mtlrr4
+ blr
_GLOBAL(__setup_cpu_e500mc)
- b __setup_e500mc_ivors
-
+ mflrr4
+ bl __e500_icache_enable
+ bl __e500_dcache_enable
+ bl __setup_e500mc_ivors
+ mtlrr4
+ blr
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/boot: cuboot: Fix up ethernet3 MAC address on MPC85xx
MPC85xx platforms do support 4 ethernet ports, so make sure the boot
wrapper fixes up all of them in the fdt.
Signed-off-by: Nate Case
---
arch/powerpc/boot/cuboot-85xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/cuboot-85xx.c b/arch/powerpc/boot/cuboot-85xx.c
index 6776a1a..277ba4a 100644
--- a/arch/powerpc/boot/cuboot-85xx.c
+++ b/arch/powerpc/boot/cuboot-85xx.c
@@ -15,6 +15,7 @@
#include "cuboot.h"
#define TARGET_85xx
+#define TARGET_HAS_ETH3
#include "ppcboot.h"
static bd_t bd;
@@ -27,6 +28,7 @@ static void platform_fixups(void)
dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
dt_fixup_mac_address_by_alias("ethernet2", bd.bi_enet2addr);
+ dt_fixup_mac_address_by_alias("ethernet3", bd.bi_enet3addr);
dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 8, bd.bi_busfreq);
/* Unfortunately, the specific model number is encoded in the
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Building dtc etc. for packaging
On Tue, 2008-11-11 at 11:29 -0600, Matt Sealey wrote: > (the other tool we need is mkimage from U-Boot, I noticed Debian uses > this > same command name inside jigdo etc. too, sigh.. also you can't build > the > tools without the rest of U-Boot which is hard to envision doing just > to > get one command out of it - "make tools/mkimage" doesn't work and I > got > tired of reverse engineering the chickenscratch..) This is a bit off-topic, but here is my ugly hack to compile a statically linked 'mkimage' from the U-Boot tree: Place this file, 'Makefile.mkimage' in u-boot/tools/ ---[snip]--- CFLAGS = -O2 -static -I../include -DUSE_HOSTCC -I. ASMDIR = ../include/asm CFILES = ../lib_generic/crc32.c ../libfdt/fdt_strerror.c \ ../lib_generic/sha1.c ../lib_generic/md5.c ../common/image.c \ ../libfdt/fdt_wip.c ../libfdt/fdt.c ../libfdt/fdt_ro.c \ ../libfdt/fdt_rw.c mkimage: mkimage.c mv $(ASMDIR) $(ASMDIR).back ln -s $(ASMDIR)-i386 $(ASMDIR) gcc $(CFLAGS) $(CFILES) mkimage.c -o mkimage rm -f $(ASMDIR) mv $(ASMDIR).back $(ASMDIR) strip mkimage default: mkimage ---[snip]--- Then just run 'make -f Makefile.mkimage' from within tools/. Of course this uses some nasty tricks that will only work on i386 host. I don't think I'm the first person to have this need, so others here may have better solutions. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Passing I2C platform_data from device tree to i2c driver
Is there a plan for providing a way to set pdata for an I2C chip in a way that could be shared across all OF platforms? For example, the pca953x I2C GPIO driver requires that pdata != NULL so it can get the gpio_base field. It can also take in a default 'invert' value to initialize a chip register with. Currently, there's no obvious way to get this to work on PowerPC without hardcoding things in the arch/powerpc/platforms/*.c file. On ARM platforms, they currently handle this by declaring I2C_BOARD_INFO() in their board-specific files. For OF platforms, I think the obvious choice would be to specify platform data in the device tree. We already register I2C devices automatically as found in the device tree (see drivers/of/of_i2c.c), but this registration method does not provide any way to set platform_data. Of course, I could put some code in my board specific file to parse the device tree properties and set pdata accordingly, but this hardly seems ideal. After all, the device tree bindings -> pdata translation itself does not have to be board-specific. Basically, I think we need to have some common code somewhere that does the task of populating platform_data for a specific I2C chip based on a device tree node -- similarly to how we register the I2C devices already. Is anyone working on this? Did anyone have anything else in mind? -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Omit TBI auto-negotiation based on device tree
On Thu, 2008-10-30 at 18:07 -0700, Trent Piepho wrote:
> But more relevant to your serdes problem, I also have a patch that
> prevents
> restarting serdes auto-negotiation if the serdes link is already up.
> My SGMII
> PHY will auto-negotiate, but it takes about 3 seconds. Avoiding an
> unnecessary 3 second auto-negotiation when the gianfar device is
> opened lets
> me cut my power-on to DHCP completion time in half.
>
> I wonder if this would also fix your problem, without needing to add
> the extra
> workaround?
I just verified that your patch solves my problem without the need for
my workaround. So at this point, it looks like we can drop this patch
("Omit TBI auto-negotiation based on device tree").
I tested when booting the kernel in U-Boot both via both TFTP and flash
(I was worried that your patch may only fix things for the TFTP boot
case, but that wasn't the case fortunately).
Thanks for the patch!
--
Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [v5] powerpc: gpio driver for mpc8349/8572/8610 and compatible
On Thu, 2008-10-30 at 08:45 +0100, Peter Korsgaard wrote: > I would write a dedicated driver for something like that instead of > using gpiolib. > > Gpiolib has quite some overhead compared to the actual work for > changing a SoC gpio pin, but it also has some very nice > advantages. For most stuff people use GPIO pins for, the overhead is > not an issue (SPI chip selects, leds, keys, reset signals, ..). It's > very handy that we nowadays have generic drivers that work with any > GPIO (being SoC gpios or stuff on spi/i2c). For what it's worth, I think it could be useful to have an optimally fast gpiolib driver. This would let you have truly generic bit-bang drivers. Take a look at drivers/spi for example -- there's ~7 bit-bang drivers in there that use spi_bitbang.c for a library of functions. I am not familiar with these drivers, but at a glance it seems feasible that with fast gpiolib implementations you could reduce all of those to a single spi_bitbang.c driver. Trent, it looks like the big performance wins for you were obtained by deviating from the gpiolib interface? In that case a generic SPI/JTAG bit bang driver wouldn't benefit from the speed boosts in your MPC8572 GPIO driver (without explicitly calling mpc8572_gpio_lock and _mpc8572_gpio_set, etc). Is that correct? In any case, I appreciate what you did with your driver, so please don't give up on getting some of your bits merged in :) -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] gianfar: Omit TBI auto-negotiation based on device tree
Some SGMII PHYs don't auto-negotiate correctly with the TBI+SerDes
interface on the mpc85xx processors. Check for the "sgmii-aneg-disable"
device tree flag and skip enabling auto-negotiation on the TBI
side if present. Full duplex 1000 Mbit/s will be assumed for the
SGMII link to the PHY (note that this does not affect the link speed
on the external side of the external PHY).
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
I'm submitting this to linuxppc-dev and netdev, though I'm not sure
which tree it should go through. It touches network driver code
and some Freescale arch code, all of which is maintained by Kumar.
Documentation/powerpc/dts-bindings/fsl/tsec.txt |3 +++
arch/powerpc/sysdev/fsl_soc.c |4
drivers/net/gianfar.c | 21 +++--
drivers/net/gianfar.h |3 ++-
include/linux/fsl_devices.h |1 +
5 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt
b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
index cf55fa4..ad0633c 100644
--- a/Documentation/powerpc/dts-bindings/fsl/tsec.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
@@ -48,6 +48,9 @@ Properties:
hardware.
- fsl,magic-packet : If present, indicates that the hardware supports
waking up via magic packet.
+ - sgmii-aneg-disable : If present, indicates that the device's SGMII
+auto-negotiation should be disabled. This may be necessary on boards
+with PHYs that are unable to auto-negotiate with the MAC.
Example:
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 01b884b..5321aa4 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -355,6 +355,10 @@ static int __init gfar_of_init(void)
if (of_get_property(np, "fsl,magic-packet", NULL))
gfar_data.device_flags |=
FSL_GIANFAR_DEV_HAS_MAGIC_PACKET;
+ if (of_get_property(np, "sgmii-aneg-disable", NULL))
+ gfar_data.board_flags |=
+ FSL_GIANFAR_BRD_SGMII_ANEG_DIS;
+
ph = of_get_property(np, "phy-handle", NULL);
if (ph == NULL) {
u32 *fixed_link;
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 64b2011..0a1c22f 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -335,6 +335,15 @@ static int gfar_probe(struct platform_device *pdev)
if (dev->features & NETIF_F_IP_CSUM)
dev->hard_header_len += GMAC_FCB_LEN;
+ /*
+* Some SGMII PHYs don't auto-negotiate correctly with the
+* TBI+SerDes interface.
+*/
+ if (priv->einfo->board_flags & FSL_GIANFAR_BRD_SGMII_ANEG_DIS)
+ priv->tbi_aneg_enable = 0;
+ else
+ priv->tbi_aneg_enable = 1;
+
priv->rx_buffer_size = DEFAULT_RX_BUFFER_SIZE;
priv->tx_ring_size = DEFAULT_TX_RING_SIZE;
priv->rx_ring_size = DEFAULT_RX_RING_SIZE;
@@ -586,6 +595,7 @@ static void gfar_configure_serdes(struct net_device *dev)
struct gfar_mii __iomem *regs =
(void __iomem *)&priv->regs->gfar_mii_regs;
int tbipa = gfar_read(&priv->regs->tbipa);
+ u16 bmcr_val;
/* Single clk mode, mii mode off(for serdes communication) */
gfar_local_mdio_write(regs, tbipa, MII_TBICON, TBICON_CLK_SELECT);
@@ -594,8 +604,15 @@ static void gfar_configure_serdes(struct net_device *dev)
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
- gfar_local_mdio_write(regs, tbipa, MII_BMCR, BMCR_ANENABLE |
- BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
+ if (priv->tbi_aneg_enable)
+ /* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
+ bmcr_val = BMCR_ANENABLE | BMCR_ANRESTART | BMCR_FULLDPLX |
+ BMCR_SPEED1000;
+ else
+ /* ANEG disabled, full duplex, speed[1] set */
+ bmcr_val = BMCR_FULLDPLX | BMCR_SPEED1000;
+
+ gfar_local_mdio_write(regs, tbipa, MII_BMCR, bmcr_val);
}
static void init_registers(struct net_device *dev)
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index f46e9b6..aa485da 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -737,7 +737,8 @@ struct gfar_private {
rx_csum_enable:1,
extended_hash:1,
bd_stash_en:1,
- wol_en:1; /* Wake-on-LAN enabled */
+ wol_en:1, /* Wake-on-LAN enabled */
+ tbi_aneg_enable:1;
unsigned short padding;
unsigned int interruptT
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Fri, 2008-10-17 at 09:02 -0500, Nate Case wrote: > > With this patch it compiles and boots fine. > > The option -mabi=no-spe is not required. > > Please don't accept this patch yet. My past testing showed that > "-mabi=no-spe" was required for my toolchain. I'll go back and double > check though. OK, I went back and re-tested. Kernel: 2.6.27 CPU: MPC8572 Toolchain: Cross-compiler built using crosstool-ng gcc 4.3.1, default target CFLAGS include '-mabi=spe -mspe' binutils 2.18.90 snapshot (built with --enable-spe=yes) Kbuild flagsResult -- -mno-spe (*)FAILED -mno-spe -mabi=no-spe FAILED -mno-spe -mspe=no OK -mspe=noOK (*) 2.6.27 default In the failure case, the kernel would repeatedly dump out "SPE used in kernel (task=, pc=)". I think I was fooled before because I added _both_ "-mspe=no" and "-mabi=no-spe" to my KBUILD_CFLAGS and saw the problem go away. Since I trusted the documentation that -mspe=no and -mno-spe were the same, I assumed that -mabi=no-spe was the key. So, I've changed my mind. I now agree with Sebastian that "-mabi=no-spe" is not required. "-mno-spe -mspe=no" is probably the safe way to go. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Wed, 2008-10-15 at 16:43 +0200, Sebastian Andrzej Siewior wrote: > With this patch it compiles and boots fine. > The option -mabi=no-spe is not required. Please don't accept this patch yet. My past testing showed that "-mabi=no-spe" was required for my toolchain. I'll go back and double check though. - Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Tue, 2008-10-14 at 16:23 -0500, Kumar Gala wrote: > Why does -mno-spe work? > > From my gcc-4.3 info pages: > > `-mspe=YES/NO' > This option has been deprecated. Use `-mspe' and `-mno-spe' > instead. > > > +KBUILD_CFLAGS += $(call cc-option,-mabi=no-spe) > > is the -mabi=no-spe really needed? My guess is that the -mabi=no-spe was the real key of what made it work for him. I went through the same thing with my toolchain. You do need -mabi=no-spe if your toolchain defaults to -mabi=spe like mine does. I know that the more generic toolchains out there (CodeSourcery, ELDK) default to -mabi=no-spe, so in that case it would not be necessary. I don't know what generated instructions are actually to blame, but I do know that if you compile certain programs with "-mno-spe -mabi=spe" vs. "-mno-spe -mabi=no-spe", the results will differ. In the case of the kernel, you'll get a bunch of "SPE used in kernel" messages with the "-mno-spe -mabi=spe" combination. - Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Tue, 2008-10-14 at 14:25 -0500, Nate Case wrote: > > -mno-spe: Deprecated way to say "no SPE instructions" > -mspe=no: New way to do -mno-spe Sorry, I got this backwards (as Kumar pointed out in his other reply). -mspe=no is actually deprecated. - Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Mon, 2008-09-01 at 16:23 +0200, Sebastian Siewior wrote: > those two are requried on my fresh gcc 4.3.1 > > Signed-off-by: Thiemo Seufer <[EMAIL PROTECTED]> > Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]> > --- > Not sure if this is intendent or a gcc bug but with -mno-spe > the spe opcodes were not used floating point anymore but > for 64bit save/restore for instance. I wouldn't say this is due to a broken compiler. As I understand it, -mabi=no-spe and -mspe=no serve two different purposes. One is for disabling the SPE instructions and the other controls the ABI (which would make those 64-bit save/restores I'm guessing). I don't know why you'd ever want to use the SPE ABI without -mspe=yes, but gcc does provide that flexibility. -mno-spe: Deprecated way to say "no SPE instructions" -mspe=no: New way to do -mno-spe -mabi=no-spe: Disable SPE ABI Some compilers may enable "-mabi=spe" and/or "-mspe=yes" by default, so explicitly disabling both is necessary. I recently built a SPE toolchain which enabled both by default, so I ran into the "SPE used in kernel" problem when the kernel only passed "-mno-spe". - Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] edac: mpc85xx: Add support for MPC8572
From: Andrew Kilkenny <[EMAIL PROTECTED]>
This adds support for the dual-core MPC8572 processor. We have
to support making SPR changes on each core. Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.
Signed-off-by: Andrew Kilkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 28 +++-
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..63bdc47 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
/ MC SYSFS parts ***/
@@ -647,6 +648,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
.compatible = "fsl,8568-l2-cache-controller",
},
+ {
+.compatible = "fsl,mpc8572-l2-cache-controller",
+},
{},
};
@@ -912,7 +916,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device
*op,
/* register interrupts */
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_mc_isr, IRQF_DISABLED,
+ mpc85xx_mc_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] MC err", mci);
if (res < 0) {
printk(KERN_ERR "%s: Unable to request irq %d for "
@@ -980,6 +985,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
.compatible = "fsl,8568-memory-controller",
},
+ {
+.compatible = "fsl,mpc8572-memory-controller",
+},
{},
};
@@ -995,6 +1003,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+ orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x2));
+}
+
static int __init mpc85xx_mc_init(void)
{
int res = 0;
@@ -1031,8 +1045,7 @@ static int __init mpc85xx_mc_init(void)
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT) {
- orig_hid1 = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1 & ~0x2));
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
return 0;
@@ -1040,9 +1053,14 @@ static int __init mpc85xx_mc_init(void)
module_init(mpc85xx_mc_init);
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+ mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
static void __exit mpc85xx_mc_exit(void)
{
- mtspr(SPRN_HID1, orig_hid1);
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] edac: mpc85xx: Add support for MPC8572
On Fri, 2008-09-19 at 16:43 -0500, Kumar Gala wrote: > I don't have any issue with this, but why are you marking the PCI > error interrupt as shared? [snip] > this I'm a bit more skeptical about. The only one we really need to make shared is the memory controller interrupt. I'll drop it for the PCI and L2 interrupts in the next rev of the patch. > its fsl,mpc8572.. (we need to fix the others to match that convention > as its pretty standard for other device tree nodes) I actually started out with "fsl,mpc8572-*" but then somehow convinced myself I was wrong when I saw fsl,85xx in so many other places :) Thanks for the feedback. I'll correct these and re-submit. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] edac: mpc85xx: Add support for MPC8572
From: Andrew Kilkenny <[EMAIL PROTECTED]>
This adds support for the dual-core MPC8572 processor. We have
to support making SPR changes on each core. Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.
Signed-off-by: Andrew Kilkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 34 +++---
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..0668492 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
/ MC SYSFS parts ***/
@@ -272,7 +273,8 @@ static int __devinit mpc85xx_pci_err_probe(struct of_device
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_pci_isr, IRQF_DISABLED,
+ mpc85xx_pci_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] PCI err", pci);
if (res < 0) {
printk(KERN_ERR
@@ -576,7 +578,8 @@ static int __devinit mpc85xx_l2_err_probe(struct of_device
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_l2_isr, IRQF_DISABLED,
+ mpc85xx_l2_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] L2 err", edac_dev);
if (res < 0) {
printk(KERN_ERR
@@ -647,6 +650,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
.compatible = "fsl,8568-l2-cache-controller",
},
+ {
+.compatible = "fsl,8572-l2-cache-controller",
+},
{},
};
@@ -912,7 +918,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device
*op,
/* register interrupts */
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_mc_isr, IRQF_DISABLED,
+ mpc85xx_mc_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] MC err", mci);
if (res < 0) {
printk(KERN_ERR "%s: Unable to request irq %d for "
@@ -980,6 +987,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
.compatible = "fsl,8568-memory-controller",
},
+ {
+.compatible = "fsl,8572-memory-controller",
+},
{},
};
@@ -995,6 +1005,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+ orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x2));
+}
+
static int __init mpc85xx_mc_init(void)
{
int res = 0;
@@ -1031,8 +1047,7 @@ static int __init mpc85xx_mc_init(void)
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT) {
- orig_hid1 = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1 & ~0x2));
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
return 0;
@@ -1040,9 +1055,14 @@ static int __init mpc85xx_mc_init(void)
module_init(mpc85xx_mc_init);
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+ mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
static void __exit mpc85xx_mc_exit(void)
{
- mtspr(SPRN_HID1, orig_hid1);
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Git branch conventions
Hi Paul, Can you (or anyone really) describe what the usage conventions are for the master, powerpc-next, and merge branches in your tree? The 'master' and 'powerpc-next' branches appear to be identical right now. I can see that you usually submit pull requests to Linus via your 'merge' branch. I also notice that there are changes in 'merge' that aren't in 'master' or 'powerpc-next'. Likewise, I see changes in 'powerpc-next'/'master' that aren't in 'merge'. Is 'powerpc-next'/'master' purely 2.6.28 material currently while 'merge' is for whatever the next target release is (currently 2.6.27)? I couldn't find this explained officially anywhere, so I thought I'd ask. Maybe it'd shed some light for other people too. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH / RFC] net: don't grab a mutex within a timer context in gianfar
On Wed, 2008-07-23 at 22:03 +0200, Sebastian Siewior wrote: > I moved it into a workqueue, this is what tg3 does. > I would convert the other three drivers unless $dude suggests a better > method or somebody else takes care > > drivers/net/gianfar.c | 22 ++ > drivers/net/gianfar.h |2 ++ > 2 files changed, 20 insertions(+), 4 deletions(-) This looks good to me. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: bug: mutex_lock() in interrupt conntext via phy_stop() in gianfar
On Fri, 2008-07-18 at 14:10 +0200, Sebastian Siewior wrote: > Commit 35b5f6b1a aka [PHYLIB: Locking fixes for PHY I/O potentially sleeping] > changed the phydev->lock from spinlock into a mutex. Now, the following > code path got triggered while NFS was unavailable: > [snip] > |[ 194.864733] BUG: sleeping function called from invalid context at > /home/bigeasy/git/linux-2.6-powerpc/kernel/mutex.c:87 > |[ 194.875529] in_atomic():1, irqs_disabled():0 > |[ 194.879805] Call Trace: > |[ 194.882250] [c0383d90] [c0006dd8] show_stack+0x48/0x184 (unreliable) > |[ 194.888649] [c0383db0] [c001e938] __might_sleep+0xe0/0xf4 > |[ 194.894069] [c0383dc0] [c025a43c] mutex_lock+0x24/0x3c > |[ 194.899234] [c0383de0] [c019005c] phy_stop+0x20/0x70 > |[ 194.904234] [c0383df0] [c018d4ec] stop_gfar+0x28/0xf4 > |[ 194.909305] [c0383e10] [c018e8c4] gfar_timeout+0x30/0x60 > |[ 194.914638] [c0383e20] [c01fe7c0] dev_watchdog+0xa8/0x144 Hmm.. I'm not sure what the best solution is to this. Make the stop_gfar() call happen in a workqueue, and make a similar change to ucc_geth, fec_mpc52xx, and fs_enet? Modify phy_stop() to do the work in a workqueue conditionally if in interrupt context? Between these two I'd lean toward the latter. Does anyone have any better ideas? -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
On Tue, 2008-07-15 at 19:19 +0400, Anton Vorontsov wrote: > + led->cdev.name = of_get_property(np, "label", NULL); > + if (!led->cdev.name) > + led->cdev.name = dev_name(&ofdev->dev); How about also supporting a "trigger" property which would set cdev.default_trigger in the same manner? It would be useful for boards to be able to specify this in the device tree (e.g., if a certain LED is meant to be used as a "heartbeat"). -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gianfar in SGMII mode
On Wed, 2008-07-02 at 17:53 -0500, Nate Case wrote: > I'm looking at gfar_configure_serdes() and I'm at a loss as to why > this > is always called when the MAC is in SGMII mode. It looks like it > assumes the use of TBI for some reason. On my board it's just a > regular > SGMII interface to a bcm5482 PHY in SGMII mode, so there is no TBI > involved. > > I'm guessing this is a case of the driver making incorrect assumptions > based on the existing Freescale boards. Or am I missing something > here? Answering my own question: I see now that TBI is used internally on the chip for the SerDes interface which implements SGMII.. so maybe there's no problem with what the driver is doing after all. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
gianfar in SGMII mode
Hi Kumar, I'm looking at gfar_configure_serdes() and I'm at a loss as to why this is always called when the MAC is in SGMII mode. It looks like it assumes the use of TBI for some reason. On my board it's just a regular SGMII interface to a bcm5482 PHY in SGMII mode, so there is no TBI involved. I'm guessing this is a case of the driver making incorrect assumptions based on the existing Freescale boards. Or am I missing something here? -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] USB: isp1760: Support board-specific hardware configurations
This adds support for hardware configurations that don't match the
chip default register settings (e.g., 16-bit data bus, DACK and
DREQ pulled up instead of down, analog overcurrent mode).
These settings are passed in via the OF device tree. The PCI
interface still assumes the same default values.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
This version addresses feedback from Sebastian Siewior and
Olof Johansson. Specifically, a new flag was added for ISP1761 which
is set during probe time. This is used instead of checking the Chip
ID register (which doesn't allow you to distinguish between the ISP1760
and ISP1761). Also, device tree property checking is adjusted to
simply check for a property's presence when setting flags.
I tested this version on both a custom ppc64 board and Electra.
Olof also tried testing it on his Electra but without success (I'm
guessing, perhaps naively, that a difference between our setups was
the cause and the driver changes are still OK).
drivers/usb/host/isp1760-hcd.c | 67 +++
drivers/usb/host/isp1760-hcd.h | 20 +++-
drivers/usb/host/isp1760-if.c | 35 +++-
3 files changed, 104 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c
index 65aa5ec..d6c218c 100644
--- a/drivers/usb/host/isp1760-hcd.c
+++ b/drivers/usb/host/isp1760-hcd.c
@@ -38,6 +38,7 @@ struct isp1760_hcd {
unsignedi_thresh;
unsigned long reset_done;
unsigned long next_statechange;
+ unsigned intdevflags;
};
static inline struct isp1760_hcd *hcd_to_priv(struct usb_hcd *hcd)
@@ -378,9 +379,31 @@ static int isp1760_hc_setup(struct usb_hcd *hcd)
{
struct isp1760_hcd *priv = hcd_to_priv(hcd);
int result;
- u32 scratch;
+ u32 scratch, hwmode;
+
+ /* Setup HW Mode Control: This assumes a level active-low interrupt */
+ hwmode = HW_DATA_BUS_32BIT;
+
+ if (priv->devflags & ISP1760_FLAG_BUS_WIDTH_16)
+ hwmode &= ~HW_DATA_BUS_32BIT;
+ if (priv->devflags & ISP1760_FLAG_ANALOG_OC)
+ hwmode |= HW_ANA_DIGI_OC;
+ if (priv->devflags & ISP1760_FLAG_DACK_POL_HIGH)
+ hwmode |= HW_DACK_POL_HIGH;
+ if (priv->devflags & ISP1760_FLAG_DREQ_POL_HIGH)
+ hwmode |= HW_DREQ_POL_HIGH;
+
+ /*
+* We have to set this first in case we're in 16-bit mode.
+* Write it twice to ensure correct upper bits if switching
+* to 16-bit mode.
+*/
+ isp1760_writel(hwmode, hcd->regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode, hcd->regs + HC_HW_MODE_CTRL);
isp1760_writel(0xdeadbabe, hcd->regs + HC_SCRATCH_REG);
+ /* Change bus pattern */
+ scratch = isp1760_readl(hcd->regs + HC_CHIP_ID_REG);
scratch = isp1760_readl(hcd->regs + HC_SCRATCH_REG);
if (scratch != 0xdeadbabe) {
printk(KERN_ERR "ISP1760: Scratch test failed.\n");
@@ -403,17 +426,29 @@ static int isp1760_hc_setup(struct usb_hcd *hcd)
/* Step 11 passed */
- isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_REG);
- isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_ENABLE);
+ isp1760_info(priv, "bus width: %d, oc: %s\n",
+ (priv->devflags & ISP1760_FLAG_BUS_WIDTH_16) ?
+ 16 : 32, (priv->devflags & ISP1760_FLAG_ANALOG_OC) ?
+ "analog" : "digital");
/* ATL reset */
- scratch = isp1760_readl(hcd->regs + HC_HW_MODE_CTRL);
- isp1760_writel(scratch | ALL_ATX_RESET, hcd->regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode | ALL_ATX_RESET, hcd->regs + HC_HW_MODE_CTRL);
mdelay(10);
- isp1760_writel(scratch, hcd->regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode, hcd->regs + HC_HW_MODE_CTRL);
- isp1760_writel(PORT1_POWER | PORT1_INIT2, hcd->regs + HC_PORT1_CTRL);
- mdelay(10);
+ isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_REG);
+ isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_ENABLE);
+
+ /*
+* PORT 1 Control register of the ISP1760 is the OTG control
+* register on ISP1761.
+*/
+ if (!(priv->devflags & ISP1760_FLAG_ISP1761) &&
+ !(priv->devflags & ISP1760_FLAG_PORT1_DIS)) {
+ isp1760_writel(PORT1_POWER | PORT1_INIT2,
+ hcd->regs + HC_PORT1_CTRL);
+ mdelay(10);
+ }
priv->hcs_params = isp1760_readl(hcd->regs + HC_HCSPARAMS);
@@ -453,8 +488,7 @@ static int isp1760_run(struct usb_hcd *hcd)
hcd->state = HC_STATE_R
[PATCH 2/2] USB: isp1760: Support board-specific hardware configurations
This adds support for hardware configurations that don't match the
chip default register settings (e.g., 16-bit data bus, DACK and
DREQ pulled down instead of up, analog overcurrent mode).
These settings are passed in via the OF device tree. The PCI
interface still assumes the same default values.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/usb/host/isp1760-hcd.c | 68 +++
drivers/usb/host/isp1760-hcd.h | 19 ++-
drivers/usb/host/isp1760-if.c | 34 +++-
3 files changed, 103 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c
index 65aa5ec..679b8df 100644
--- a/drivers/usb/host/isp1760-hcd.c
+++ b/drivers/usb/host/isp1760-hcd.c
@@ -38,6 +38,7 @@ struct isp1760_hcd {
unsignedi_thresh;
unsigned long reset_done;
unsigned long next_statechange;
+ unsigned intdevflags;
};
static inline struct isp1760_hcd *hcd_to_priv(struct usb_hcd *hcd)
@@ -378,9 +379,31 @@ static int isp1760_hc_setup(struct usb_hcd *hcd)
{
struct isp1760_hcd *priv = hcd_to_priv(hcd);
int result;
- u32 scratch;
+ u32 scratch, hwmode;
+
+ /* Setup HW Mode Control: This assumes a level active-low interrupt */
+ hwmode = HW_DATA_BUS_32BIT;
+
+ if (priv->devflags & ISP1760_FLAG_BUS_WIDTH_16)
+ hwmode &= ~HW_DATA_BUS_32BIT;
+ if (priv->devflags & ISP1760_FLAG_ANALOG_OC)
+ hwmode |= HW_ANA_DIGI_OC;
+ if (priv->devflags & ISP1760_FLAG_DACK_POL_HIGH)
+ hwmode |= HW_DACK_POL_HIGH;
+ if (priv->devflags & ISP1760_FLAG_DREQ_POL_HIGH)
+ hwmode |= HW_DREQ_POL_HIGH;
+
+ /*
+* We have to set this first in case we're in 16-bit mode.
+* Write it twice to ensure correct upper bits if switching
+* to 16-bit mode.
+*/
+ isp1760_writel(hwmode, hcd->regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode, hcd->regs + HC_HW_MODE_CTRL);
isp1760_writel(0xdeadbabe, hcd->regs + HC_SCRATCH_REG);
+ /* Change bus pattern */
+ scratch = isp1760_readl(hcd->regs + HC_CHIP_ID_REG);
scratch = isp1760_readl(hcd->regs + HC_SCRATCH_REG);
if (scratch != 0xdeadbabe) {
printk(KERN_ERR "ISP1760: Scratch test failed.\n");
@@ -403,17 +426,30 @@ static int isp1760_hc_setup(struct usb_hcd *hcd)
/* Step 11 passed */
- isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_REG);
- isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_ENABLE);
+ isp1760_info(priv, "bus width: %d, oc: %s\n",
+ (priv->devflags & ISP1760_FLAG_BUS_WIDTH_16) ?
+ 16 : 32, (priv->devflags & ISP1760_FLAG_ANALOG_OC) ?
+ "analog" : "digital");
/* ATL reset */
- scratch = isp1760_readl(hcd->regs + HC_HW_MODE_CTRL);
- isp1760_writel(scratch | ALL_ATX_RESET, hcd->regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode | ALL_ATX_RESET, hcd->regs + HC_HW_MODE_CTRL);
mdelay(10);
- isp1760_writel(scratch, hcd->regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode, hcd->regs + HC_HW_MODE_CTRL);
- isp1760_writel(PORT1_POWER | PORT1_INIT2, hcd->regs + HC_PORT1_CTRL);
- mdelay(10);
+ isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_REG);
+ isp1760_writel(INTERRUPT_ENABLE_MASK, hcd->regs + HC_INTERRUPT_ENABLE);
+
+ /*
+* PORT 1 Control register of the ISP1760 is the OTG control
+* register on ISP1761.
+*/
+ scratch = isp1760_readl(hcd->regs + HC_CHIP_ID_REG);
+ if (((scratch & 0x) == 0x1760) &&
+ !(priv->devflags & ISP1760_FLAG_PORT1_DIS)) {
+ isp1760_writel(PORT1_POWER | PORT1_INIT2,
+ hcd->regs + HC_PORT1_CTRL);
+ mdelay(10);
+ }
priv->hcs_params = isp1760_readl(hcd->regs + HC_HCSPARAMS);
@@ -453,8 +489,7 @@ static int isp1760_run(struct usb_hcd *hcd)
hcd->state = HC_STATE_RUNNING;
isp1760_enable_interrupts(hcd);
temp = isp1760_readl(hcd->regs + HC_HW_MODE_CTRL);
- temp |= FINAL_HW_CONFIG;
- isp1760_writel(temp, hcd->regs + HC_HW_MODE_CTRL);
+ isp1760_writel(temp | HW_GLOBAL_INTR_EN, hcd->regs + HC_HW_MODE_CTRL);
command = isp1760_readl(hcd->regs + HC_USBCMD);
command &= ~(CMD_LRESET|CMD_RESET);
@@ -2112,6 +2147,7 @@ static int isp1760_get_frame(struct usb_hcd *hcd)
static void isp1760_stop(struct usb_hcd *hcd)
{
struct isp1760_hcd *priv = hcd_to_priv(hcd);
+ u32 temp;
isp1760_hub_control(hcd, C
[PATCH 1/2] USB: isp1760: Assign resource fields before adding hcd
This fixes the bogus "io mem 0x" message printed during driver init due to hcd->rsrc_start being assigned after the call to usb_add_hcd(). Signed-off-by: Nate Case <[EMAIL PROTECTED]> --- drivers/usb/host/isp1760-hcd.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c index c9cec87..65aa5ec 100644 --- a/drivers/usb/host/isp1760-hcd.c +++ b/drivers/usb/host/isp1760-hcd.c @@ -2207,14 +2207,14 @@ struct usb_hcd *isp1760_register(u64 res_start, u64 res_len, int irq, goto err_put; } - ret = usb_add_hcd(hcd, irq, irqflags); - if (ret) - goto err_unmap; - hcd->irq = irq; hcd->rsrc_start = res_start; hcd->rsrc_len = res_len; + ret = usb_add_hcd(hcd, irq, irqflags); + if (ret) + goto err_unmap; + return hcd; err_unmap: -- 1.5.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] USB: isp1760: Fixes and support for more hardware configs
I spent a little time getting the new isp1760 driver to work on my ppc64 board with an ISP1761. There were two main problems I encountered: - Driver wrote to the PORT 1 control register which is actually the OTG control register on the ISP1761. This needs to be skipped on ISP1761 until we have proper OTG support. - Driver assumed 32-bit data bus mode. You have to jump through a couple small hoops to get 16-bit mode to work, including some changes to the scratch register test. I also had to re-order some of the steps to occur _after_ setting HW MODE control. The first patch is a minor fix. The second patch takes care of the above issues and also adds support for the other bits in HW MODE control that might vary from board to board. Sebastian: I tried to be careful to minimize functional changes for your case (isp1760, 32-bit mode), so things should work the same for you with these patches applied. However, I only have an ISP1761 to test with so I'd appreciate it if you could test with your board. I'm CCing linuxppc-dev in case there's any feedback on the OF device tree property usage in patch 2/2. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Fix uninitialized variable bug in copy_{to|from}_user
Calls to copy_to_user() or copy_from_user() can fail
when copying N bytes, where N is a constant less than 8,
but not 1, 2, 4, or 8.
Signed-off-by: Dave Scidmore <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
include/asm-powerpc/uaccess.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 8e798e3..1a0736f 100644
--- a/include/asm-powerpc/uaccess.h
+++ b/include/asm-powerpc/uaccess.h
@@ -380,7 +380,7 @@ static inline unsigned long __copy_from_user_inatomic(void
*to,
const void __user *from, unsigned long n)
{
if (__builtin_constant_p(n) && (n <= 8)) {
- unsigned long ret;
+ unsigned long ret = 1;
switch (n) {
case 1:
@@ -406,7 +406,7 @@ static inline unsigned long __copy_to_user_inatomic(void
__user *to,
const void *from, unsigned long n)
{
if (__builtin_constant_p(n) && (n <= 8)) {
- unsigned long ret;
+ unsigned long ret = 1;
switch (n) {
case 1:
--
1.5.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: Support ISA legacy addresses in of_address_to_resource()
On Fri, 2008-05-09 at 14:31 +1000, Benjamin Herrenschmidt wrote:
> I don't understand that fix. Can you tell us more about the exact
> failure mode ? Especially, show us the device-tree bits and the
> addresses returned.
>
> I suspect the bug is in your device-tree that is forwarding IO
> addresses
> all the way without converting them to memory or something like that.
Your suspicion is correct in a way -- this allows IO port addresses to
make their way to 'struct resource' so that drivers can use inb(),
outb(), etc. After some thought, I'm not sure if a device tree using
I/O port addresses for a legacy node is considered a bug or not.
Here is the failure case my patch fixes:
[EMAIL PROTECTED],e00f {
linux,phandle = <0x3ff93688>;
ranges = <0x1 0x0 0x0 0x0 0x1000>;
reg = <0x0 0xe00f 0x0 0x1>;
class-code = <0x601ff>;
device-id = <0xa008>;
vendor-id = <0x1959>;
#address-cells = <0x2>;
#size-cells = <0x1>;
device_type = "isa";
[EMAIL PROTECTED] {
linux,phandle = <0x3ff93a00>;
reg = <0x1 0xca2 0x100>;
reg-spacing = <0x1>;
reg-size = <0x1>;
compatible = "ipmi-kcs";
device_type = "ipmi";
};
};
The address returned for ipmi@ for this case is 0x10ca2 instead of
0xca2.
The legacy "isa" bus node and the device nodes give the raw port
addresses (0xca2 in this case). In order for this to work, it has to be
assumed that ISA_IO_BASE is mapped properly on the platform so that the
port I/O functions will work with the raw port addresses.
The problem I encountered was that it would call pci_address_to_pio() on
the reg address of the ipmi node just because it had the IORESOURCE_IO
flag. This would result in the 'struct resource' getting the bogus
address of 0x10ca2 rather than 0xca2.
In my case, my real fix I have settled on is using the following instead
of using the I/O method:
[EMAIL PROTECTED],e00f {
linux,phandle = <0x3ff93688>;
ranges = <0x0 0x0 0x0 0xfc80 0x1000>;
reg = <0x0 0xe00f 0x0 0x1>;
class-code = <0x601ff>;
device-id = <0xa008>;
vendor-id = <0x1959>;
#address-cells = <0x2>;
#size-cells = <0x1>;
device_type = "isa";
[EMAIL PROTECTED] {
linux,phandle = <0x3ff93a00>;
reg = <0x0 0xca2 0x100>;
reg-spacing = <0x1>;
reg-size = <0x1>;
compatible = "ipmi-kcs";
device_type = "ipmi";
};
};
That is, the typical MMIO case so that 'struct resource' ends up with
0xfc800ca2. This works fine without the patch of course. If legacy I/O
port addresses are not permitted in device trees this way and we don't
want to support it, then you can ignore my patch. However, it does seem
a little strange to me that __of_address_to_resource() assumes anything
with IORESOURCE_IO is a PCI device.
- Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Get rid of leftover printk in isa-bridge.c
This printk() appears twice in the same function. Only the latter one in the inval_range: section appears to be legitimate. Signed-off-by: Nate Case <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c index ee172aa..e35092e 100644 --- a/arch/powerpc/kernel/isa-bridge.c +++ b/arch/powerpc/kernel/isa-bridge.c @@ -108,9 +108,6 @@ static void __devinit pci_process_ISA_OF_ranges(struct device_node *isa_node, if (size > 0x1) size = 0x1; - printk(KERN_ERR "no ISA IO ranges or unexpected isa range, " - "mapping 64k\n"); - __ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE, size, _PAGE_NO_CACHE|_PAGE_GUARDED); return; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Support ISA legacy addresses in of_address_to_resource()
When mapping an open firmware device tree node to a resource,
check if the device is on the "isa" legacy bus. In this case,
pci_address_to_pio() should not be used since that function is only
for addresses above the 64KB reserved region.
This was necessary to get IPMI working on a board that accesses
the IPMI controller via the legacy I/O region.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/prom_parse.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 90eb3a3..28d354d 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -622,7 +622,15 @@ static int __of_address_to_resource(struct device_node
*dev, const u32 *addrp,
memset(r, 0, sizeof(struct resource));
if (flags & IORESOURCE_IO) {
unsigned long port;
- port = pci_address_to_pio(taddr);
+ struct device_node *parent;
+
+ parent = of_get_parent(dev);
+ if (of_bus_isa_match(parent))
+ port = (unsigned long) taddr;
+ else
+ port = pci_address_to_pio(taddr);
+ of_node_put(parent);
+
if (port == (unsigned long)-1)
return -EINVAL;
r->start = port;
--
1.5.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
