* Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
From: Benjamin Herrenschmidt @ 2009-09-15 0:42 UTC (permalink / raw)
To: Ludo Van Put; +Cc: linuxppc-dev
In-Reply-To: <5edaeed70909140608m3ddcda33y7f92b2dfd18ca92e@mail.gmail.com>
On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote:
> 2009/9/14 Josh Boyer <jwboyer@linux.vnet.ibm.com>:
> > On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote:
> >>Hi,
> >>
> >>we're working with a PPC440GX on a board that has a.o. a compact flash slot.
> >>We had the PCI subsystem of the ppc disabled in strapping for quite a while,
> >>until we wanted to start using it.
> >>However, when we enabled PCI in the strapping and in the (patched 2.6.10)
> >
> > 2.6.10? Really? If that is truly the case, you probably aren't going to get
> > a whole lot of help from the list, since that kernel is pretty ancient.
> >
> I can only acknowledge that, but we're stuck to that kernel for now...
>
> >>kernel configuration, we triggered an oops when probing for IDE devices (to
> >>read out the first 512 bytes of the CF). I can see that the ioremap64 call
> >>in the driver code for our CF returns a different address (compared to PCI
> >>disabled in strapping), but using this address later on for accessing the CF
> >>goes wrong.
> >
> > Posting the oops output would perhaps help. Or maybe not.
> >
> > josh
> >
>
> Here it goes, you never know:
>
> Oops: kernel access of bad area, sig: 11 [#1]
> PREEMPT
> NIP: C0148050 LR: C013BC64 SP: C07CFEA0 REGS: c07cfdf0 TRAP: 0300 Not tainted
> MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> DAR: E3093000, DSISR: 00000000
> TASK = c07cdb70[1] 'swapper' THREAD: c07ce000
> Last syscall: 120
> GPR00: 00000000 C07CFEA0 C07CDB70 E3093000 DFE829FE 00000100 C01184E8 C021B270
> GPR08: C0220000 C02D0F60 C07CDEF8 C07CDEF8 00000000 70000000 1FFF6400 00000001
> GPR16: 00000001 FFFFFFFF 1FFF06C0 00000000 00000001 C0220000 C0280000 00029000
> GPR24: 00000000 C02D0F60 C01F0000 C0148040 00000080 00000000 DFE82A00 C02D0FF0
> NIP [c0148050] ide_insw+0x10/0x24
> LR [c013bc64] ata_input_data+0x74/0x114
> Call backtrace:
> c013e6a4 try_to_identify+0x2ec/0x5ec
> c013eaa8 do_probe+0x104/0x304
> c013f0c4 probe_hwif+0x358/0x6c4
> c0140068 ideprobe_init+0xa8/0x1a0
> c02a4ef8 ide_generic_init+0x10/0x28
> c0001324 init+0xc4/0x244
> c0004254 kernel_thread+0x44/0x60
> Kernel panic - not syncing: Attempted to kill init!
> <0>Rebooting in 180 seconds..
>
>
> ide_insw is a asm routine to read in 16bit words and swap them. Copied
> from arch/ppc/kernel/misc.S. Works fine when PCI is disabled.
Probably because ide_insw uses isnw which offsets everything from
_IO_BASE which changes value when you have a PCI bus with an IO space...
If your IDE isn't PCI IO space based you shouldn't use ide_insw but the
MMIO variants instead.
Ben.
> KR, Ludo
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH 07/11] powerpc: Convert BUG() to use unreachable()
From: David Daney @ 2009-09-14 21:55 UTC (permalink / raw)
To: torvalds, akpm
Cc: linux-arch, linux-kernel, David Daney, linuxppc-dev,
Paul Mackerras
In-Reply-To: <4AAEBAC2.1050905@caviumnetworks.com>
Use the new unreachable() macro instead of for(;;);
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@ozlabs.org
---
arch/powerpc/include/asm/bug.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 64e1fdc..2c15212 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -68,7 +68,7 @@
_EMIT_BUG_ENTRY \
: : "i" (__FILE__), "i" (__LINE__), \
"i" (0), "i" (sizeof(struct bug_entry))); \
- for(;;) ; \
+ unreachable(); \
} while (0)
#define BUG_ON(x) do { \
--
1.6.2.5
^ permalink raw reply related
* [PATCH 00/11] Add support for GCC's __builtin_unreachable() and use it in BUG (v2).
From: David Daney @ 2009-09-14 21:50 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: linux-mips, Heiko Carstens, linuxppc-dev, Paul Mackerras,
H. Peter Anvin, linux-arch, linux-s390, linux-am33-list,
Helge Deller, x86, Ingo Molnar, Mike Frysinger, Ivan Kokshaysky,
uclinux-dist-devel, Thomas Gleixner, Roland McGrath,
Richard Henderson, Haavard Skinnemoen, linux-parisc,
Linux Kernel Mailing List, ralf, Kyle McMartin, linux-alpha,
Martin Schwidefsky, linux390, Koichi Yasutake
When I sent the first version, I had not realized that Roland McGrath
had only a day or two earlier submitted a very similar patch (although
one that only fixed up the x86 case).
I have been working on this quite a while now, starting with adding
the required support to GCC, so with an eye towards finishing it up I
have this new version.
From the announcement of the first version:
Starting with version 4.5, GCC has a new built-in function called
__builtin_unreachable(). The function tells the compiler that control
flow will never reach that point. Currently we trick the compiler by
putting in for(;;); but this has the disadvantage that extra code is
emitted for an endless loop. For an i386 kernel using
__builtin_unreachable() results in an defaultconfig that is nearly 4000
bytes smaller.
This patch set adds support to compiler.h creating a
new macro usable in the kernel called unreachable(). If the compiler
lacks __builtin_unreachable(), it just expands to for(;;).
The x86 and MIPS patches I actually tested with a GCC-4.5 snapshot.
Lacking the ability to test the rest of the architectures, I just did
what seemed right without even trying to compile the kernel.
For version 2:
I fixed a couple of checkpatch issues, and simplified the
unreachable() macro for the pre-GCC-4.5 case (as suggested by Richard
Henderson). Also several Acked-by: were added.
New in this version (as suggested by Ingo Molnar) I added 11/11 which
uses unreachable() in asm-generic/bug.h for !CONFIG_BUG case. This
one may be a little controversial as it will end up making code
slightly larger when !CONFIG_BUG and you are using a pre-GCC-4.5
compiler.
I will reply with the 11 patches.
David Daney (11):
Add support for GCC-4.5's __builtin_unreachable() to compiler.h (v2)
x86: Convert BUG() to use unreachable()
MIPS: Convert BUG() to use unreachable()
s390: Convert BUG() to use unreachable()
mn10300: Convert BUG() to use unreachable()
parisc: Convert BUG() to use unreachable()
powerpc: Convert BUG() to use unreachable()
alpha: Convert BUG() to use unreachable()
avr32: Convert BUG() to use unreachable()
blackfin: Convert BUG() to use unreachable()
Use unreachable() in asm-generic/bug.h for !CONFIG_BUG case.
arch/alpha/include/asm/bug.h | 3 ++-
arch/avr32/include/asm/bug.h | 2 +-
arch/blackfin/include/asm/bug.h | 2 +-
arch/mips/include/asm/bug.h | 4 +---
arch/mn10300/include/asm/bug.h | 3 ++-
arch/parisc/include/asm/bug.h | 4 ++--
arch/powerpc/include/asm/bug.h | 2 +-
arch/s390/include/asm/bug.h | 2 +-
arch/x86/include/asm/bug.h | 4 ++--
include/asm-generic/bug.h | 4 ++--
include/linux/compiler-gcc4.h | 14 ++++++++++++++
include/linux/compiler.h | 5 +++++
12 files changed, 34 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 2/5] powerpc/85xx/86xx: Add suspend/resume support
From: Anton Vorontsov @ 2009-09-14 21:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <4AAEAB56.1050609@freescale.com>
On Mon, Sep 14, 2009 at 03:45:10PM -0500, Scott Wood wrote:
[...]
> >You can't request the firmware in the qe driver's ->suspend()
> >routine necause the firmware may be on e.g. NFS filesystem or USB
> >stick (implies having QE Ethernet or QE USB fully functional).
>
> Is there any way for software to read out the current firmware from
> the device, or is it write-only?
Hm, I didn't look into iram stuff that much, but seemingly I can
read it back and save. In the end, it's just a ram that we access
in a weird way... Let me try it.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v3 2/5] powerpc/85xx/86xx: Add suspend/resume support
From: Scott Wood @ 2009-09-14 20:45 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20090914202017.GA14428@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> This patch adds suspend/resume support for MPC8540, MPC8569 and
> MPC8641D-compatible CPUs.
>
> MPC8540 and MPC8641D-compatible PMCs are trivial: we just write
> the SLP bit into the PM control and status register.
>
> MPC8569 is a bit trickier, QE turns off during suspend, thus on
> resume we must reload QE microcode and reset QE.
>
> So far we don't support Deep Sleep mode as found in newer MPC85xx
> CPUs (i.e. MPC8536). It can be relatively easy implemented though,
> and for it we reserve 'mem' suspend type.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com>
>> I'm not sure that we're guaranteed that the sleep has taken effect
>> immediately -- we may need to do a loop waiting for it to clear (on
>> 85xx), probably with some delays to give the bus a chance to become idle.
>
> Brilliant idea, thanks!
>
> But it works vice versa: upon write, the code flow stops immediately
> (on 85xx and 86xx),
That's what I've observed as well; the question is whether it's always
guaranteed to be immediate.
>> The 8610 manual says that that bit should only be set as part of a
>> sequence also involving the use of MSR[POW] (section 23.5.1.4).
>
> Well, 23.4.1.12 says:
>
> | Sleep status
> | 0 The device is not attempting to reach sleep mode.
> | 1 The device is attempting to enter sleep mode because
> | POWMGTCSR[SLP] is set, or HID0[SLEEP] and MSR[POW] in
> ^^
> | the e600 core are set. The core has halted fetching, snooping
> | to the L1 and L2 caches is disabled, ....
>
> The same in 85xx specs.
>
> I can confirm this on real hw, after setting the SLP bit, the 8610
> actually goes into sleep mode, no code flow happens until a wakeup
> event. So playing with MSR[POW] doesn't seem to be necessary. The
> same for 85xx.
OK, looks like section 23.5.1.4 is just bogus.
> This exact snippet could be moved to the "qe" device driver, yes.
> But I didn't bother because fsl_pmc have to request the QE firmware.
>
> You can't request the firmware in the qe driver's ->suspend()
> routine necause the firmware may be on e.g. NFS filesystem or USB
> stick (implies having QE Ethernet or QE USB fully functional).
Is there any way for software to read out the current firmware from the
device, or is it write-only?
> We can solve that by implementing ppc_md.suspend_prepare() (must
> be called from userspace context), there we could request the
> firmware. Then QE device driver would reload it in its resume()
> callback. Needless to say that it makes things a bit more
> complicated to follow.
>
> The current code vanishes without QE anyway. But if you insist,
> I can do the suspend_prepare() thing, although I'd prefer it as
> a cleanup patch for 2.6.33, since it would touch more code,
> specifically I'm concerned about ppc generic files.
I don't insist, it just struck me as odd.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: Fix bug where perf_counters breaks oprofile
From: Josh Boyer @ 2009-09-14 20:43 UTC (permalink / raw)
To: Maynard Johnson
Cc: Paul Mackerras, Benjamin Herrenschmidt, Maynard Johnson,
linuxppc-dev
In-Reply-To: <4AAEA40A.6040701@us.ibm.com>
On Mon, Sep 14, 2009 at 03:14:02PM -0500, Maynard Johnson wrote:
>Maynard Johnson wrote:
>> Paul Mackerras wrote:
>>> Currently there is a bug where if you use oprofile on a pSeries
>>> machine, then use perf_counters, then use oprofile again, oprofile
>>> will not work correctly; it will lose the PMU configuration the next
>>> time the hypervisor does a partition context switch, and thereafter
>>> won't count anything.
>Ben,
>Is there any way to get this bug fix into 2.6.31 or is the window closed? Once the problem occurs, you can't get oprofile to work again without a reboot. Really would be nice (for many reasons) to get this fixed in .31.
.31 is already released. Could probably get it into a -stable .31 kernel
though.
josh
^ permalink raw reply
* [PATCH v3 2/5] powerpc/85xx/86xx: Add suspend/resume support
From: Anton Vorontsov @ 2009-09-14 20:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20090914172811.GA9074@b07421-ec1.am.freescale.net>
This patch adds suspend/resume support for MPC8540, MPC8569 and
MPC8641D-compatible CPUs.
MPC8540 and MPC8641D-compatible PMCs are trivial: we just write
the SLP bit into the PM control and status register.
MPC8569 is a bit trickier, QE turns off during suspend, thus on
resume we must reload QE microcode and reset QE.
So far we don't support Deep Sleep mode as found in newer MPC85xx
CPUs (i.e. MPC8536). It can be relatively easy implemented though,
and for it we reserve 'mem' suspend type.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Mon, Sep 14, 2009 at 12:28:11PM -0500, Scott Wood wrote:
[...]
> > So far we don't support Deep Sleep mode as found in newer MPC85xx
> > CPUs (i.e. MPC8536). It can be relatively easy implemented though,
> > and for it we reserve 'mem' suspend type.
>
> We've got some code floating around here for that; it's just been falling
> through the cracks as far as getting a chance to clean up and push
> upstream. Hopefully it'll happen soon.
Nice.
[...]
> > +++ b/arch/powerpc/Kconfig
> > @@ -212,7 +212,8 @@ config ARCH_HIBERNATION_POSSIBLE
> >
> > config ARCH_SUSPEND_POSSIBLE
> > def_bool y
> > - depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
> > + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
> > + PPC_85xx || PPC_86xx
>
> This isn't directed at this patch, but why do we need this list? Can't
> each platform figure out for itself whether it can actually register that
> suspend_ops struct, just like any other driver?
Good question. Disabling PM also makes some drivers less
tested, since there are a lot of #ifdef CONFIG_PM in the
drivers.
Though in this patch I'm just following current practice, if
a cleanup patch for all platforms is desired, I can readily
implement it.
[...]
> > +config FSL_PMC
> > + bool
> > + default y
> > + depends on SUSPEND && (PPC_85xx || PPC_86xx)
> > + help
> > + Freescale MPC85xx/MPC86xx power management controller support
> > + (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
>
> I wish we had a better name for 85xx+86xx than "FSL". :-(
Ditto. It took me quite some time to pick the name, couldn't find
anything better.
> > +static int pmc_suspend_enter(suspend_state_t state)
> > +{
> > + setbits32(&pmc_regs->pmcsr, PMCSR_SLP);
> > + /* At this point, the CPU is asleep. */
>
> I'm not sure that we're guaranteed that the sleep has taken effect
> immediately -- we may need to do a loop waiting for it to clear (on
> 85xx), probably with some delays to give the bus a chance to become idle.
Brilliant idea, thanks!
But it works vice versa: upon write, the code flow stops immediately
(on 85xx and 86xx), so there wouldn't any point in trying to readback
the pmcsr. But upon resume, on 86xx (and most probably on 85xx,
though we don't see it), the SLP bit doesn't clear immediately, we
have to wait for it. This eliminates the need for clearing the bit
for 86xx (i.e. the clearing operation worked as a small delay).
> I'm not sure how much of that is necessary under certain conditions,
> versus just paranoia, though.
>
> Something like what you have here worked
> well enough for us in testing -- but having that clear immediately after
> makes me nervous. At least a read-back seems appropriate (which I
> suppose the clbits32 does, but I'd prefer something more explicit).
>
> > + /* For 86xx we need to clear the bit on resume, 85xx don't care. */
> > + clrbits32(&pmc_regs->pmcsr, PMCSR_SLP);
>
> Hmm, how does this work? Does it only enter sleep mode on the rising
> edge of that bit?
No, it appears it is the same as in 85xx, the bit clears by itself,
but we must wait for it. So your idea about looping and reading the
register actually eliminates the need for clrbits32(). Without the
clrbit32 (aka delay) or proper looping we would let device drivers
to resume too early, and things, obviously, didn't work.
> The 8610 manual says that that bit should only be set as part of a
> sequence also involving the use of MSR[POW] (section 23.5.1.4).
Well, 23.4.1.12 says:
| Sleep status
| 0 The device is not attempting to reach sleep mode.
| 1 The device is attempting to enter sleep mode because
| POWMGTCSR[SLP] is set, or HID0[SLEEP] and MSR[POW] in
^^
| the e600 core are set. The core has halted fetching, snooping
| to the L1 and L2 caches is disabled, ....
The same in 85xx specs.
I can confirm this on real hw, after setting the SLP bit, the 8610
actually goes into sleep mode, no code flow happens until a wakeup
event. So playing with MSR[POW] doesn't seem to be necessary. The
same for 85xx.
> > + if (pmc_qefw) {
> > + int ret;
> > +
> > + ret = qe_upload_firmware(pmc_qefw);
> > + if (ret)
> > + dev_err(pmc_dev, "could not upload firmware\n");
> > +
> > + qe_reset();
> > + }
>
> Does this really belong here, or should the QE subsystem have a device
> struct with suspend/resume ops?
This exact snippet could be moved to the "qe" device driver, yes.
But I didn't bother because fsl_pmc have to request the QE firmware.
You can't request the firmware in the qe driver's ->suspend()
routine necause the firmware may be on e.g. NFS filesystem or USB
stick (implies having QE Ethernet or QE USB fully functional).
We can solve that by implementing ppc_md.suspend_prepare() (must
be called from userspace context), there we could request the
firmware. Then QE device driver would reload it in its resume()
callback. Needless to say that it makes things a bit more
complicated to follow.
The current code vanishes without QE anyway. But if you insist,
I can do the suspend_prepare() thing, although I'd prefer it as
a cleanup patch for 2.6.33, since it would touch more code,
specifically I'm concerned about ppc generic files.
How about this patch?
Thanks!
arch/powerpc/Kconfig | 11 +++-
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_pmc.c | 131 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 142 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_pmc.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d00131c..a0743a7 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -212,7 +212,8 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
+ PPC_85xx || PPC_86xx
config PPC_DCR_NATIVE
bool
@@ -642,6 +643,14 @@ config FSL_PCI
select PPC_INDIRECT_PCI
select PCI_QUIRKS
+config FSL_PMC
+ bool
+ default y
+ depends on SUSPEND && (PPC_85xx || PPC_86xx)
+ help
+ Freescale MPC85xx/MPC86xx power management controller support
+ (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
+
config 4xx_SOC
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 9d4b174..5642924 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
+obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
diff --git a/arch/powerpc/sysdev/fsl_pmc.c b/arch/powerpc/sysdev/fsl_pmc.c
new file mode 100644
index 0000000..916a21a
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_pmc.c
@@ -0,0 +1,131 @@
+/*
+ * Suspend/resume support
+ *
+ * Copyright © 2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.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.
+ */
+
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/errno.h>
+#include <linux/suspend.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/of_platform.h>
+#include <linux/firmware.h>
+#include <asm/qe.h>
+
+struct pmc_regs {
+ __be32 devdisr;
+ __be32 devdisr2;
+ __be32 :32;
+ __be32 :32;
+ __be32 pmcsr;
+#define PMCSR_SLP (1 << 17)
+};
+
+struct pmc_data {
+ unsigned int flags;
+#define PMC_NEED_QE_RELOAD (1 << 0)
+
+ const char *fw_name;
+};
+
+static struct device *pmc_dev;
+static struct pmc_regs __iomem *pmc_regs;
+static const struct pmc_data *pmc_data;
+static struct qe_firmware *pmc_qefw;
+
+static int pmc_suspend_enter(suspend_state_t state)
+{
+ int ret;
+
+ setbits32(&pmc_regs->pmcsr, PMCSR_SLP);
+ /* At this point, the CPU is asleep. */
+
+ /* Upon resume, wait for SLP bit to be clear. */
+ ret = spin_event_timeout((in_be32(&pmc_regs->pmcsr) & PMCSR_SLP) == 0,
+ 10000, 10) ? 0 : -ETIMEDOUT;
+ if (ret)
+ dev_err(pmc_dev, "tired waiting for SLP bit to clear\n");
+
+ if (pmc_qefw) {
+ int ret;
+
+ ret = qe_upload_firmware(pmc_qefw);
+ if (ret)
+ dev_err(pmc_dev, "could not upload firmware\n");
+
+ qe_reset();
+ }
+ return ret;
+}
+
+static int pmc_suspend_valid(suspend_state_t state)
+{
+ if (state != PM_SUSPEND_STANDBY)
+ return 0;
+
+ if (pmc_data && pmc_data->flags & PMC_NEED_QE_RELOAD && !pmc_qefw) {
+ const struct firmware *fw;
+ int ret;
+
+ ret = request_firmware(&fw, pmc_data->fw_name, pmc_dev);
+ if (ret) {
+ dev_err(pmc_dev, "could not request firmware %s\n",
+ pmc_data->fw_name);
+ return 0;
+ }
+
+ pmc_qefw = (struct qe_firmware *)fw->data;
+ }
+
+ return 1;
+}
+
+static struct platform_suspend_ops pmc_suspend_ops = {
+ .valid = pmc_suspend_valid,
+ .enter = pmc_suspend_enter,
+};
+
+static int pmc_probe(struct of_device *ofdev, const struct of_device_id *id)
+{
+ pmc_regs = of_iomap(ofdev->node, 0);
+ if (!pmc_regs)
+ return -ENOMEM;
+
+ pmc_dev = &ofdev->dev;
+ pmc_data = id->data;
+ suspend_set_ops(&pmc_suspend_ops);
+ return 0;
+}
+
+static struct pmc_data mpc8569_pmc_data = {
+ .flags = PMC_NEED_QE_RELOAD,
+ .fw_name = "fsl_qe_ucode_8569.bin",
+};
+
+static const struct of_device_id pmc_ids[] = {
+ { .compatible = "fsl,mpc8569-pmc", .data = &mpc8569_pmc_data, },
+ { .compatible = "fsl,mpc8548-pmc", },
+ { .compatible = "fsl,mpc8641d-pmc", },
+ { },
+};
+
+static struct of_platform_driver pmc_driver = {
+ .driver.name = "fsl-pmc",
+ .match_table = pmc_ids,
+ .probe = pmc_probe,
+};
+
+static int __init pmc_init(void)
+{
+ return of_register_platform_driver(&pmc_driver);
+}
+device_initcall(pmc_init);
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix bug where perf_counters breaks oprofile
From: Maynard Johnson @ 2009-09-14 20:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Maynard Johnson, Paul Mackerras, linuxppc-dev
In-Reply-To: <4AA7AE3B.30809@us.ibm.com>
Maynard Johnson wrote:
> Paul Mackerras wrote:
>> Currently there is a bug where if you use oprofile on a pSeries
>> machine, then use perf_counters, then use oprofile again, oprofile
>> will not work correctly; it will lose the PMU configuration the next
>> time the hypervisor does a partition context switch, and thereafter
>> won't count anything.
Ben,
Is there any way to get this bug fix into 2.6.31 or is the window closed? Once the problem occurs, you can't get oprofile to work again without a reboot. Really would be nice (for many reasons) to get this fixed in .31.
Thanks.
-Maynard
>>
>> Maynard Johnson identified the sequence causing the problem:
>> - oprofile setup calls ppc_enable_pmcs(), which calls
>> pseries_lpar_enable_pmcs, which tells the hypervisor that we want
>> to use the PMU, and sets the "PMU in use" flag in the lppaca.
>> This flag tells the hypervisor whether it needs to save and restore
>> the PMU config.
>> - The perf_counter code sets and clears the "PMU in use" flag directly
>> as it context-switches the PMU between tasks, and leaves it clear
>> when it finishes.
>> - oprofile setup, called for a new oprofile run, calls ppc_enable_pmcs,
>> which does nothing because it has already been called. In particular
>> it doesn't set the "PMU in use" flag.
>>
>> This fixes the problem by arranging for ppc_enable_pmcs to always set
>> the "PMU in use" flag. It makes the perf_counter code call
>> ppc_enable_pmcs also rather than calling the lower-level function
>> directly, and removes the setting of the "PMU in use" flag from
>> pseries_lpar_enable_pmcs, since that is now done in its caller.
>>
>> This also removes the declaration of pasemi_enable_pmcs because it
>> isn't defined anywhere.
> Thanks, Paul. I tested the patch, and oprofile and perf now play nicely together.
>
> -Maynard
>> Reported-by: Maynard Johnson <mpjohn@us.ibm.com>
>> Signed-off-by: Paul Mackerras <paulus@samba.org>
>> ---
>> arch/powerpc/include/asm/pmc.h | 16 ++++++++++++++--
>> arch/powerpc/kernel/perf_counter.c | 13 +++----------
>> arch/powerpc/kernel/sysfs.c | 3 +++
>> arch/powerpc/platforms/pseries/setup.c | 4 ----
>> 4 files changed, 20 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/pmc.h b/arch/powerpc/include/asm/pmc.h
>> index d6a616a..ccc68b5 100644
>> --- a/arch/powerpc/include/asm/pmc.h
>> +++ b/arch/powerpc/include/asm/pmc.h
>> @@ -27,10 +27,22 @@ extern perf_irq_t perf_irq;
>>
>> int reserve_pmc_hardware(perf_irq_t new_perf_irq);
>> void release_pmc_hardware(void);
>> +void ppc_enable_pmcs(void);
>>
>> #ifdef CONFIG_PPC64
>> -void power4_enable_pmcs(void);
>> -void pasemi_enable_pmcs(void);
>> +#include <asm/lppaca.h>
>> +
>> +static inline void ppc_set_pmu_inuse(int inuse)
>> +{
>> + get_lppaca()->pmcregs_in_use = inuse;
>> +}
>> +
>> +extern void power4_enable_pmcs(void);
>> +
>> +#else /* CONFIG_PPC64 */
>> +
>> +static inline void ppc_set_pmu_inuse(int inuse) { }
>> +
>> #endif
>>
>> #endif /* __KERNEL__ */
>> diff --git a/arch/powerpc/kernel/perf_counter.c b/arch/powerpc/kernel/perf_counter.c
>> index 70e1f57..ccd6b21 100644
>> --- a/arch/powerpc/kernel/perf_counter.c
>> +++ b/arch/powerpc/kernel/perf_counter.c
>> @@ -62,7 +62,6 @@ static inline unsigned long perf_ip_adjust(struct pt_regs *regs)
>> {
>> return 0;
>> }
>> -static inline void perf_set_pmu_inuse(int inuse) { }
>> static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp) { }
>> static inline u32 perf_get_misc_flags(struct pt_regs *regs)
>> {
>> @@ -93,11 +92,6 @@ static inline unsigned long perf_ip_adjust(struct pt_regs *regs)
>> return 0;
>> }
>>
>> -static inline void perf_set_pmu_inuse(int inuse)
>> -{
>> - get_lppaca()->pmcregs_in_use = inuse;
>> -}
>> -
>> /*
>> * The user wants a data address recorded.
>> * If we're not doing instruction sampling, give them the SDAR
>> @@ -531,8 +525,7 @@ void hw_perf_disable(void)
>> * Check if we ever enabled the PMU on this cpu.
>> */
>> if (!cpuhw->pmcs_enabled) {
>> - if (ppc_md.enable_pmcs)
>> - ppc_md.enable_pmcs();
>> + ppc_enable_pmcs();
>> cpuhw->pmcs_enabled = 1;
>> }
>>
>> @@ -594,7 +587,7 @@ void hw_perf_enable(void)
>> mtspr(SPRN_MMCRA, cpuhw->mmcr[2] & ~MMCRA_SAMPLE_ENABLE);
>> mtspr(SPRN_MMCR1, cpuhw->mmcr[1]);
>> if (cpuhw->n_counters == 0)
>> - perf_set_pmu_inuse(0);
>> + ppc_set_pmu_inuse(0);
>> goto out_enable;
>> }
>>
>> @@ -627,7 +620,7 @@ void hw_perf_enable(void)
>> * bit set and set the hardware counters to their initial values.
>> * Then unfreeze the counters.
>> */
>> - perf_set_pmu_inuse(1);
>> + ppc_set_pmu_inuse(1);
>> mtspr(SPRN_MMCRA, cpuhw->mmcr[2] & ~MMCRA_SAMPLE_ENABLE);
>> mtspr(SPRN_MMCR1, cpuhw->mmcr[1]);
>> mtspr(SPRN_MMCR0, (cpuhw->mmcr[0] & ~(MMCR0_PMC1CE | MMCR0_PMCjCE))
>> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
>> index f41aec8..956ab33 100644
>> --- a/arch/powerpc/kernel/sysfs.c
>> +++ b/arch/powerpc/kernel/sysfs.c
>> @@ -17,6 +17,7 @@
>> #include <asm/prom.h>
>> #include <asm/machdep.h>
>> #include <asm/smp.h>
>> +#include <asm/pmc.h>
>>
>> #include "cacheinfo.h"
>>
>> @@ -123,6 +124,8 @@ static DEFINE_PER_CPU(char, pmcs_enabled);
>>
>> void ppc_enable_pmcs(void)
>> {
>> + ppc_set_pmu_inuse(1);
>> +
>> /* Only need to enable them once */
>> if (__get_cpu_var(pmcs_enabled))
>> return;
>> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
>> index 8d75ea2..ca5f2e1 100644
>> --- a/arch/powerpc/platforms/pseries/setup.c
>> +++ b/arch/powerpc/platforms/pseries/setup.c
>> @@ -223,10 +223,6 @@ static void pseries_lpar_enable_pmcs(void)
>> set = 1UL << 63;
>> reset = 0;
>> plpar_hcall_norets(H_PERFMON, set, reset);
>> -
>> - /* instruct hypervisor to maintain PMCs */
>> - if (firmware_has_feature(FW_FEATURE_SPLPAR))
>> - get_lppaca()->pmcregs_in_use = 1;
>> }
>>
>> static void __init pseries_discover_pic(void)
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] mpc5200: support for the MAN mpc5200 based board uc101
From: Wolfgang Grandegger @ 2009-09-14 19:16 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4AAE4F44.7080300@denx.de>
Hello Heiko,
Heiko Schocher wrote:
> Hello Grant,
>
> Grant Likely wrote:
>> Thanks for the patch. Comments below.
>>
>> g.
>>
>> On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher <hs@denx.de> wrote:
>>> - serial Console on PSC1
>>> - 64MB SDRAM
>>> - MTD CFI Flash
>>> - Ethernet FEC
>>> - I2C with PCF8563 and Temp. Sensor ADM9240
>>> - IDE support
>>>
>>> Signed-off-by: Heiko Schocher <hs@denx.de>
...snip....
>>> + i2c@3d40 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "fsl,mpc5200-i2c","fsl-i2c";
>>> + reg = <0x3d40 0x40>;
>>> + interrupts = <2 16 0>;
>>> + fsl5200-clocking;
>> I believe fsl5200-clocking is no longer required. There is a patch
>> pending which removes this property from the other .dts files.
Right, it obsolete.
> Ok, fix this.
Like it is, the I2C controller will use a fixed low speed fdt/dfsr
setting. You have two other options:
fsl,preserve-clocking;
clock-frequency = <400000>;
See also
http://lxr.linux.no/#linux+v2.6.31/Documentation/powerpc/dts-bindings/fsl/i2c.txt.
>>> +
>>> + hwmon@2c {
>>> + compatible = "ad,adm9240";
>>> + reg = <0x2c>;
>>> + };
>>> + rtc@51 {
>>> + compatible = "rtc,pcf8563";
rtc is not a proper vendor name. Should be nxp, IIRC.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Xilinx: SPI: Fix bits_per_word for transfers
From: Grant Likely @ 2009-09-14 18:37 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev, akonovalov, dbrownell
In-Reply-To: <20090914181617.ACF4B17B804F@mail59-sin.bigfish.com>
On Mon, Sep 14, 2009 at 12:17 PM, John Linn <john.linn@xilinx.com> wrote:
> The bits_per_word value can be set for each transfer, or can
> be set to zero in each transfer in which case it should default
> to the value in the driver.
>
> The driver was fixed to properly check the bits_per_word in
> the transfer that is passed in.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Looks good to me.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0drivers/spi/xilinx_spi.c | =A0 =A03 ++-
> =A01 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index 46b8c5c..5a143b9 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -148,7 +148,8 @@ static int xilinx_spi_setup_transfer(struct spi_devic=
e *spi,
> =A0{
> =A0 =A0 =A0 =A0u8 bits_per_word;
>
> - =A0 =A0 =A0 bits_per_word =3D (t) ? t->bits_per_word : spi->bits_per_wo=
rd;
> + =A0 =A0 =A0 bits_per_word =3D (t && t->bits_per_word)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0? t->bits_per_word : spi=
->bits_per_word;
> =A0 =A0 =A0 =A0if (bits_per_word !=3D 8) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_err(&spi->dev, "%s, unsupported bits_p=
er_word=3D%d\n",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, bits_per_word);
> --
> 1.6.2.1
>
>
>
> This email and any attachments are intended for the sole use of the named=
recipient(s) and contain(s) confidential information that may be proprieta=
ry, privileged or copyrighted under applicable law. If you are not the inte=
nded recipient, do not read, copy, or forward this email message or any att=
achments. Delete this email message and any attachments immediately.
>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/5] dynamic logical partitioning infrastructure
From: Brian King @ 2009-09-14 18:30 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AAABCE3.5090702@austin.ibm.com>
Nathan Fontenot wrote:
> +#include <linux/kernel.h>
> +#include <linux/kref.h>
> +#include <linux/notifier.h>
> +#include <linux/proc_fs.h>
> +#include <linux/spinlock.h>
> +
> +#include <asm/prom.h>
> +#include <asm/machdep.h>
> +#include <asm/uaccess.h>
> +#include <asm/rtas.h>
> +#include <asm/pSeries_reconfig.h>
> +
> +#define CFG_CONN_WORK_SIZE 4096
> +static char workarea[CFG_CONN_WORK_SIZE];
> +spinlock_t workarea_lock;
This can be:
static DEFINE_SPINLOCK(workarea_lock);
Then you can get rid of the runtime initializer.
> +
> +int release_drc(u32 drc_index)
> +{
> + int dr_status, rc;
> +
> + rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
> + DR_ENTITY_SENSE, drc_index);
> + if (rc || dr_status != DR_ENTITY_PRESENT)
> + return -1;
> +
> + rc = rtas_set_indicator(ISOLATION_STATE, drc_index, ISOLATE);
> + if (rc)
> + return -1;
> +
> + rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
> + if (rc) {
> + rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
> + return -1;
> + }
Is there a better return value here that might be more descriptive than -1?
> +
> + return 0;
> +}
> +
> +static int pseries_dlpar_init(void)
> +{
> + spin_lock_init(&workarea_lock);
> +
> + if (!machine_is(pseries))
> + return 0;
What's the point of this if check if you return 0 either way?
> +
> + return 0;
> +}
> +__initcall(pseries_dlpar_init);
> Index: powerpc/arch/powerpc/platforms/pseries/reconfig.c
> ===================================================================
> --- powerpc.orig/arch/powerpc/platforms/pseries/reconfig.c 2009-09-11
> 12:43:39.000000000 -0500
> +++ powerpc/arch/powerpc/platforms/pseries/reconfig.c 2009-09-11
> 12:51:52.000000000 -0500
> @@ -95,7 +95,7 @@
> return parent;
> }
>
> -static BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
> +struct blocking_notifier_head pSeries_reconfig_chain =
> BLOCKING_NOTIFIER_INIT(pSeries_reconfig_chain);
Can't this just be?
BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 0/5] kernel handling of dynamic logical partitioning
From: Daniel Walker @ 2009-09-14 18:24 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AAE89CE.2030804@austin.ibm.com>
On Mon, 2009-09-14 at 13:22 -0500, Nathan Fontenot wrote:
> Daniel Walker wrote:
> > On Fri, 2009-09-11 at 16:08 -0500, Nathan Fontenot wrote:
> >> am cc'ing lkml.
> >>
> >> Patches include in this set:
> >> 1/5 - DLPAR infrastructure for powerpc/pseries platform.
> >> 2/5 - Move the of_drconf_cell struct to prom.h
> >> 3/5 - Export the memory sysdev class
> >> 4/5 - Memory DLPAR handling
> >> 5/5 - CPU DLPAR handling
> >>
> >
> > It looks like a couple of your patches have some checkpatch issues..
> > Could you run these through scripts/checkpatch.pl and clean up any
> > problems it raises ? Specifically patches 1, 4, and 5 ..
> >
>
> thanks for checking this, I obviously forgot. I'll post updated patches
> (after running checkpatch on them) with fixes.
Ok, thanks..
Daniel
^ permalink raw reply
* Re: [PATCH 0/5] kernel handling of dynamic logical partitioning
From: Nathan Fontenot @ 2009-09-14 18:22 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1252704198.28368.31.camel@desktop>
Daniel Walker wrote:
> On Fri, 2009-09-11 at 16:08 -0500, Nathan Fontenot wrote:
>> am cc'ing lkml.
>>
>> Patches include in this set:
>> 1/5 - DLPAR infrastructure for powerpc/pseries platform.
>> 2/5 - Move the of_drconf_cell struct to prom.h
>> 3/5 - Export the memory sysdev class
>> 4/5 - Memory DLPAR handling
>> 5/5 - CPU DLPAR handling
>>
>
> It looks like a couple of your patches have some checkpatch issues..
> Could you run these through scripts/checkpatch.pl and clean up any
> problems it raises ? Specifically patches 1, 4, and 5 ..
>
thanks for checking this, I obviously forgot. I'll post updated patches
(after running checkpatch on them) with fixes.
-Nathan
^ permalink raw reply
* Re: [PATCH 5/5] kernel handling of CPU DLPAR
From: Nathan Fontenot @ 2009-09-14 18:20 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
In-Reply-To: <20090914064127.GC13139@centrinvest.ru>
Andrey Panin wrote:
> On 254, 09 11, 2009 at 04:15:33PM -0500, Nathan Fontenot wrote:
>> This adds the capability to DLPAR add and remove CPUs from the kernel. The
>> creates two new files /sys/devices/system/cpu/probe and
>> /sys/devices/system/cpu/release to handle the DLPAR addition and
>> removal of
>> CPUs respectively.
>>
>> CPU DLPAR add is accomplished by writing the drc-index of the CPU to the
>> probe file, and removal is done by writing the device-tree path of the cpu
>> to the release file.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
>> +static ssize_t cpu_probe_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + struct device_node *dn;
>> + u32 drc_index;
>> + char *cpu_name;
>> + int rc;
>> +
>> + drc_index = simple_strtoull(buf, NULL, 0);
>> + if (!drc_index)
>> + return -EINVAL;
>> +
>> + rc = acquire_drc(drc_index);
>> + if (rc)
>> + return rc;
>> +
>> + dn = configure_connector(drc_index);
>> + if (!dn) {
>> + release_drc(drc_index);
>> + return rc;
>> + }
>> +
>> + /* fixup dn name */
>> + cpu_name = kzalloc(strlen(dn->full_name) + strlen("/cpus/") + 1,
>> + GFP_KERNEL);
>
> Unchecked memory allocation with immediate crash in case of failure.
Yep, thats a bad thing. I'll fix this in an updated patch. thanks.
-Nathan
>
>> + sprintf(cpu_name, "/cpus/%s", dn->full_name);
>> + kfree(dn->full_name);
>> + dn->full_name = cpu_name;
>> +
>> + rc = add_device_tree_nodes(dn);
>> + if (rc)
>> + release_drc(drc_index);
>> +
>> + return rc ? rc : count;
>> +}
>> +
>> +static ssize_t cpu_release_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + struct device_node *dn;
>> + u32 *drc_index;
>> + int rc;
>> +
>> + dn = of_find_node_by_path(buf);
>> + if (!dn)
>> + return -EINVAL;
>> +
>> + drc_index = (u32 *)of_get_property(dn, "ibm,my-drc-index", NULL);
>> + if (!drc_index) {
>> + of_node_put(dn);
>> + return -EINVAL;
>> + }
>> +
>> + rc = release_drc(*drc_index);
>> + if (rc) {
>> + of_node_put(dn);
>> + return rc;
>> + }
>> +
>> + rc = remove_device_tree_nodes(dn);
>> + if (rc)
>> + acquire_drc(*drc_index);
>> +
>> + of_node_put(dn);
>> + return rc? rc : count;
>> +}
>> +
>> static struct class_attribute class_attr_mem_release =
>> __ATTR(release, S_IWUSR, NULL, memory_release_store);
>> +static struct class_attribute class_attr_cpu_probe =
>> + __ATTR(probe, S_IWUSR, NULL, cpu_probe_store);
>> +static struct class_attribute class_attr_cpu_release =
>> + __ATTR(release, S_IWUSR, NULL, cpu_release_store);
>>
>> static int pseries_dlpar_init(void)
>> {
>> @@ -576,6 +648,18 @@
>> printk(KERN_INFO "DLPAR: Could not create sysfs memory "
>> "release file\n");
>>
>> + rc = sysfs_create_file(&cpu_sysdev_class.kset.kobj,
>> + &class_attr_cpu_probe.attr);
>> + if (rc)
>> + printk(KERN_INFO "DLPAR: Could not create sysfs cpu "
>> + "probe file\n");
>> +
>> + rc = sysfs_create_file(&cpu_sysdev_class.kset.kobj,
>> + &class_attr_cpu_release.attr);
>> + if (rc)
>> + printk(KERN_INFO "DLPAR: Could not create sysfs cpu "
>> + "release file\n");
>> +
>> return 0;
>> }
>> __initcall(pseries_dlpar_init);
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
^ permalink raw reply
* Re: [PATCH 4/5] kernel handling of memory DLPAR
From: Nathan Fontenot @ 2009-09-14 18:18 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev, linux-kernel
In-Reply-To: <20090914063911.GB13139@centrinvest.ru>
Andrey Panin wrote:
> On 254, 09 11, 2009 at 04:14:35PM -0500, Nathan Fontenot wrote:
>> This adds the capability to DLPAR add and remove memory from the kernel. The
>> patch extends the powerpc handling of memory_add_physaddr_to_nid(), which is
>> called from the sysfs memory 'probe' file to first ensure that the memory
>> has been added to the system. This is done by creating a platform specific
>> callout from the routine. The pseries implementation of this handles the
>> DLPAR work to add the memory to the system and update the device tree.
>>
>> The patch also creates a pseries only 'release' sys file,
>> /sys/devices/system/memory/release. This file handles the DLPAR
>> release of
>> memory back to firmware and updating of the device-tree.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
>> +static struct property *clone_property(struct property *old_prop)
>> +{
>> + struct property *new_prop;
>> +
>> + new_prop = kzalloc((sizeof *new_prop), GFP_KERNEL);
>> + if (!new_prop)
>> + return NULL;
>> +
>> + new_prop->name = kzalloc(strlen(old_prop->name) + 1, GFP_KERNEL);
>> + new_prop->value = kzalloc(old_prop->length + 1, GFP_KERNEL);
>
> Memory leak here. What if one kzalloc() succeeded and another failed ?
>
This should be fine. The free_property routine will free the name or value
fields if they are allocated.
-Nathan
>> + if (!new_prop->name || !new_prop->value) {
>> + free_property(new_prop);
>> + return NULL;
>> + }
>> +
>> + strcpy(new_prop->name, old_prop->name);
>> + memcpy(new_prop->value, old_prop->value, old_prop->length);
>> + new_prop->length = old_prop->length;
>> +
>> + return new_prop;
>> +}
^ permalink raw reply
* [PATCH] Xilinx: SPI: Fix bits_per_word for transfers
From: John Linn @ 2009-09-14 18:17 UTC (permalink / raw)
To: dbrownell, linuxppc-dev, grant.likely, jwboyer, akonovalov; +Cc: John Linn
The bits_per_word value can be set for each transfer, or can
be set to zero in each transfer in which case it should default
to the value in the driver.
The driver was fixed to properly check the bits_per_word in
the transfer that is passed in.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/spi/xilinx_spi.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 46b8c5c..5a143b9 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -148,7 +148,8 @@ static int xilinx_spi_setup_transfer(struct spi_device *spi,
{
u8 bits_per_word;
- bits_per_word = (t) ? t->bits_per_word : spi->bits_per_word;
+ bits_per_word = (t && t->bits_per_word)
+ ? t->bits_per_word : spi->bits_per_word;
if (bits_per_word != 8) {
dev_err(&spi->dev, "%s, unsupported bits_per_word=%d\n",
__func__, bits_per_word);
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH v2 0/5] Suspend/resume support for some 83xx/85xx/86xx boards
From: Scott Wood @ 2009-09-14 17:33 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20090914153349.GA31420@oksana.dev.rtsoft.ru>
On Mon, Sep 14, 2009 at 07:33:49PM +0400, Anton Vorontsov wrote:
> On Sun, Aug 30, 2009 at 11:36:25PM +0400, Anton Vorontsov wrote:
> > On Fri, Aug 28, 2009 at 12:38:51AM -0500, Kumar Gala wrote:
> > > >This patch adds suspend/resume support for MPC8540-compatible and
> > > >MPC8569 CPUs.
> > [...]
> > > I'd also like to get Scott's Ack on this and the device tree patches
> > > before accepting them.
ACK the device tree stuff.
-Scott
^ permalink raw reply
* Re: [PATCH 2/5] powerpc/85xx/86xx: Add suspend/resume support
From: Scott Wood @ 2009-09-14 17:28 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20090830193718.GB17519@oksana.dev.rtsoft.ru>
On Sun, Aug 30, 2009 at 11:37:18PM +0400, Anton Vorontsov wrote:
> This patch adds suspend/resume support for MPC8540, MPC8569 and
> MPC8641D-compatible CPUs.
>
> MPC8540 and MPC8641D-compatible PMCs are trivial: we just write
> the SLP bit into the PM control and status register.
>
> MPC8569 is a bit trickier, QE turns off during suspend, thus on
> resume we must reload QE microcode and reset QE.
>
> So far we don't support Deep Sleep mode as found in newer MPC85xx
> CPUs (i.e. MPC8536). It can be relatively easy implemented though,
> and for it we reserve 'mem' suspend type.
We've got some code floating around here for that; it's just been falling
through the cracks as far as getting a chance to clean up and push
upstream. Hopefully it'll happen soon.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/Kconfig | 11 +++-
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/fsl_pmc.c | 124 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 135 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/sysdev/fsl_pmc.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index d00131c..a0743a7 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -212,7 +212,8 @@ config ARCH_HIBERNATION_POSSIBLE
>
> config ARCH_SUSPEND_POSSIBLE
> def_bool y
> - depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
> + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
> + PPC_85xx || PPC_86xx
This isn't directed at this patch, but why do we need this list? Can't
each platform figure out for itself whether it can actually register that
suspend_ops struct, just like any other driver?
> config PPC_DCR_NATIVE
> bool
> @@ -642,6 +643,14 @@ config FSL_PCI
> select PPC_INDIRECT_PCI
> select PCI_QUIRKS
>
> +config FSL_PMC
> + bool
> + default y
> + depends on SUSPEND && (PPC_85xx || PPC_86xx)
> + help
> + Freescale MPC85xx/MPC86xx power management controller support
> + (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
I wish we had a better name for 85xx+86xx than "FSL". :-(
> +static int pmc_suspend_enter(suspend_state_t state)
> +{
> + setbits32(&pmc_regs->pmcsr, PMCSR_SLP);
> + /* At this point, the CPU is asleep. */
I'm not sure that we're guaranteed that the sleep has taken effect
immediately -- we may need to do a loop waiting for it to clear (on
85xx), probably with some delays to give the bus a chance to become idle.
I'm not sure how much of that is necessary under certain conditions,
versus just paranoia, though. Something like what you have here worked
well enough for us in testing -- but having that clear immediately after
makes me nervous. At least a read-back seems appropriate (which I
suppose the clbits32 does, but I'd prefer something more explicit).
> + /* For 86xx we need to clear the bit on resume, 85xx don't care. */
> + clrbits32(&pmc_regs->pmcsr, PMCSR_SLP);
Hmm, how does this work? Does it only enter sleep mode on the rising
edge of that bit?
The 8610 manual says that that bit should only be set as part of a
sequence also involving the use of MSR[POW] (section 23.5.1.4).
> + if (pmc_qefw) {
> + int ret;
> +
> + ret = qe_upload_firmware(pmc_qefw);
> + if (ret)
> + dev_err(pmc_dev, "could not upload firmware\n");
> +
> + qe_reset();
> + }
Does this really belong here, or should the QE subsystem have a device
struct with suspend/resume ops?
-Scott
^ permalink raw reply
* Re: [PATCH 01/10] Add support for GCC-4.5's __builtin_unreachable() to compiler.h
From: David Daney @ 2009-09-14 15:40 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-mips, Heiko Carstens, linuxppc-dev, Paul Mackerras,
H. Peter Anvin, linux-s390, linux-am33-list, Helge Deller, x86,
Ingo Molnar, Mike Frysinger, Ivan Kokshaysky, linux390,
Thomas Gleixner, Richard Henderson, Haavard Skinnemoen,
linux-parisc, torvalds, linux-kernel, ralf, Kyle McMartin,
linux-alpha, Martin Schwidefsky, uclinux-dist-devel, akpm,
Koichi Yasutake, linuxppc-dev
In-Reply-To: <10f740e80909120022m72ad5ea7t692fba93cd3114e9@mail.gmail.com>
Geert Uytterhoeven wrote:
> On Fri, Sep 11, 2009 at 17:58, David Daney<ddaney@caviumnetworks.com> wrote:
>> Michael Buesch wrote:
>>> On Friday 11 September 2009 01:56:42 David Daney wrote:
>>>> +/* Unreachable code */
>>>> +#ifndef unreachable
>>>> +# define unreachable() do { for (;;) ; } while (0)
>>>> +#endif
>>> # define unreachable() do { } while (1)
>>>
>>> ? :)
>> Clearly I was not thinking clearly when I wrote that part. RTH noted the
>> same thing. I will fix it.
>
> However, people are so used to seeing the `do { } while (0)' idiom,
> that they might miss
> there's a `1' here, not a `0'.
>
> So perhaps it's better to use plain `for (;;)' for infinite loops?
>
I don't think so. The only valid token that can follow 'do { } while
(1)' is ';', any statement may follow 'for (;;)', so there is a greater
possibility to silently screw things up with the for(;;) form.
David Daney
^ permalink raw reply
* Re: [PATCH v2 0/5] Suspend/resume support for some 83xx/85xx/86xx boards
From: Anton Vorontsov @ 2009-09-14 15:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090830193625.GA14693@oksana.dev.rtsoft.ru>
On Sun, Aug 30, 2009 at 11:36:25PM +0400, Anton Vorontsov wrote:
> On Fri, Aug 28, 2009 at 12:38:51AM -0500, Kumar Gala wrote:
> > >This patch adds suspend/resume support for MPC8540-compatible and
> > >MPC8569 CPUs.
> [...]
> > I'd also like to get Scott's Ack on this and the device tree patches
> > before accepting them.
>
> Heh, I didn't notice that the PMC bindings for 85xx describe devdisr
> registers (and thus sleep = <> properties).
>
> So here are updated patches that should comply with the bindings.
> Plus,
>
> - It appears that 86xx PMCs registers-compatible with 85xx, so we
> can support both. Thus move 85xx/suspend.c to sysdev/fsl_pmc.c;
> - New patch that adds suspend/resume for MPC8610HPCD;
> - New patch that adds suspend/resume for 83xx QE boards;
> - Some fixes in "Make qe_reset() code path safe for repeated
> invocation" patch.
Kumar,
Is there any issues with the patches? Can you merge them for 2.6.32?
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
From: Grant Likely @ 2009-09-14 14:47 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4AAE5416.3040908@denx.de>
On Mon, Sep 14, 2009 at 8:32 AM, Heiko Schocher <hs@denx.de> wrote:
> Grant Likely wrote:
>> On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher <hs@denx.de> wrote:
>>> + =A0 =A0 =A0 soc5200@f0000000 {
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <1>;
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,mpc5200-immr";
>>
>> Does this board use the older and rarer non-'B' mpc5200 part? =A0If not,
>> then fsl,mpc5200b-immr also needs to be in this list.
>
> OK, I add this too
Okay, then before you resubmit, do a side-by-side comparison between
this file and one of the existing mpc5200b dts files. There are
numerous fsl,mpc5200b-* compatible values that need to be present.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
From: Grant Likely @ 2009-09-14 14:45 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Heiko Schocher
In-Reply-To: <20090914080322.GA3164@pengutronix.de>
On Mon, Sep 14, 2009 at 2:03 AM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> Hi,
>
>> + =A0 =A0 =A0 =A0 =A0 =A0 mpc5200_pic: interrupt-controller@500 {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // 5200 interrupts are encoded=
into two levels;
>
> Grant, maybe this comment could be dropped also for the in-kernel dts-fil=
es? I
> think it is sufficently described in mpc5200.txt. I could prepare a patch=
if
> you agree.
Meh. I don't mind it being there. Interrupt encoding is confusing
enough as is for people unfamiliar with the device tree, that any
additional hints are a plus. In fact, if you want to prepare a patch,
instead of removing this comment, replace it with one that tells
readers where to look for the encoding documentation.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
From: Heiko Schocher @ 2009-09-14 14:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40909140643j3183e181x49be002941ae5c36@mail.gmail.com>
Hello Grant,
Grant Likely wrote:
> Comments below.
>
> On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher <hs@denx.de> wrote:
>> - serial Console on PSC1
>> - 64MB SDRAM
>> - MTD CFI Flash
>> - Ethernet FEC
>> - I2C with PCF8563 and Temp. Sensor ADM9240
>> - IDE support
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>
>> arch/powerpc/boot/dts/mucmc52.dts | 231 ++++
>> arch/powerpc/configs/52xx/mucmc52_defconfig | 1476 ++++++++++++++++++++++++++
>
> Same comment as on your other patch. Drop the defconfig and add the
> needed bits to mpc5200_defconfig (in a separate patch, and add drivers
> as modules).
Yep, thanks. I look, how this works.
>> diff --git a/arch/powerpc/boot/dts/mucmc52.dts b/arch/powerpc/boot/dts/mucmc52.dts
>> new file mode 100644
>> index 0000000..a4a7a20
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/mucmc52.dts
>> @@ -0,0 +1,231 @@
>> +/*
>> + * mucmc52 board Device Tree Source
>> + *
>> + * Copyright (C) 2009 DENX Software Engineering GmbH
>> + * Heiko Schocher <hs@denx.de>
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/ {
>> + model = "man,mucmc52";
>> + compatible = "man,mucmc52";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + interrupt-parent = <&mpc5200_pic>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,5200@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + d-cache-line-size = <32>;
>> + i-cache-line-size = <32>;
>> + d-cache-size = <0x4000>; // L1, 16K
>> + i-cache-size = <0x4000>; // L1, 16K
>> + timebase-frequency = <0>; // from bootloader
>> + bus-frequency = <0>; // from bootloader
>> + clock-frequency = <0>; // from bootloader
>> + };
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x04000000>; // 64MB
>> + };
>> +
>> + soc5200@f0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc5200-immr";
>
> Does this board use the older and rarer non-'B' mpc5200 part? If not,
> then fsl,mpc5200b-immr also needs to be in this list.
OK, I add this too
Thanks
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: MPC8323 USB Host
From: Anton Vorontsov @ 2009-09-14 13:59 UTC (permalink / raw)
To: spa_kk; +Cc: linuxppc-dev
In-Reply-To: <25435195.post@talk.nabble.com>
Hello,
On Mon, Sep 14, 2009 at 05:49:01AM -0700, spa_kk wrote:
>
> Hello,
[...]
> The value in this variable are not getting changed even after connecting &
> disconnection the device.
Could be pins multiplexing or USB clocks misconfiguration.
> We have manual checked the USBRXP pin, this pin is
> HIGH => when device is connected
> LOW => when device is not connected.
>
> Kindly let us know how should we debug/proceed.
You might find this useful:
http://lkml.org/lkml/2009/4/1/481
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] mpc5200: support for the MAN mpc5200 based board uc101
From: Heiko Schocher @ 2009-09-14 14:12 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40909140638r422db79aj7568f492163c5d96@mail.gmail.com>
Hello Grant,
Grant Likely wrote:
> Thanks for the patch. Comments below.
>
> g.
>
> On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher <hs@denx.de> wrote:
>> - serial Console on PSC1
>> - 64MB SDRAM
>> - MTD CFI Flash
>> - Ethernet FEC
>> - I2C with PCF8563 and Temp. Sensor ADM9240
>> - IDE support
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> ---
>> - based on:
>> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
>>
>> - checked with:
>>
>> $ ./scripts/checkpatch.pl 0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch
>> total: 0 errors, 0 warnings, 1622 lines checked
>>
>> 0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch has no obvious style problems and is ready for submission.
>> $
>>
>> arch/powerpc/boot/dts/uc101.dts | 312 ++++++
>> arch/powerpc/configs/52xx/uc101_defconfig | 1303 ++++++++++++++++++++++++++
>
> I generally don't like board specific defconfigs unless there is a
> really compelling reason why it should be in the kernel tree. Please
> add the stuff you need (as modules!) to mpc5200_defconfig.
OK, thanks for spotting this. I take a look how this works.
> g.
>
>> diff --git a/arch/powerpc/boot/dts/uc101.dts b/arch/powerpc/boot/dts/uc101.dts
>> new file mode 100644
>> index 0000000..28e1c90
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/uc101.dts
>> @@ -0,0 +1,312 @@
>> +/*
>> + * uc101 board Device Tree Source
>> + *
>> + * Copyright (C) 2009 DENX Software Engineering GmbH
>> + * Heiko Schocher <hs@denx.de>
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/ {
>> + model = "man,uc101";
>> + compatible = "man,uc101";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + interrupt-parent = <&mpc5200_pic>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,5200@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + d-cache-line-size = <32>;
>> + i-cache-line-size = <32>;
>> + d-cache-size = <0x4000>; // L1, 16K
>> + i-cache-size = <0x4000>; // L1, 16K
>> + timebase-frequency = <0>; // from bootloader
>> + bus-frequency = <0>; // from bootloader
>> + clock-frequency = <0>; // from bootloader
>> + };
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x04000000>; // 64MB
>> + };
>> +
>> + soc5200@f0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc5200-immr";
>> + ranges = <0 0xf0000000 0x0000c000>;
>> + reg = <0xf0000000 0x00000100>;
>> + bus-frequency = <0>; // from bootloader
>> + system-frequency = <0>; // from bootloader
>> +
>> + cdm@200 {
>> + compatible = "fsl,mpc5200-cdm";
>> + reg = <0x200 0x38>;
>> + };
>> +
>> + mpc5200_pic: interrupt-controller@500 {
>> + // 5200 interrupts are encoded into two levels;
>> + interrupt-controller;
>> + #interrupt-cells = <3>;
>> + compatible = "fsl,mpc5200-pic";
>> + reg = <0x500 0x80>;
>> + interrupts = <0 0 3>;
>> + };
>> +
>> + gpt1: timer@610 { // General Purpose Timer 1 in GPIO mode
>> + compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
>> + reg = <0x610 0x10>;
>> + interrupts = <1 10 0>;
>> + gpio-controller;
>> + };
>> +
>> + gpt2: timer@620 { // General Purpose Timer 2 in GPIO mode
>> + compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
>> + reg = <0x620 0x10>;
>> + interrupts = <1 11 0>;
>> + gpio-controller;
>> + };
>> +
>> + gpt3: timer@630 { // General Purpose Timer 3 in GPIO mode
>> + compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
>> + reg = <0x630 0x10>;
>> + interrupts = <1 12 0>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + gpio_simple: gpio@b00 {
>> + compatible = "fsl,mpc5200-gpio";
>> + reg = <0xb00 0x40>;
>> + interrupts = <1 7 0>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + gpio_wkup: gpio@c00 {
>> + compatible = "fsl,mpc5200-gpio-wkup";
>> + reg = <0xc00 0x40>;
>> + interrupts = <1 8 0 0 3 0>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + dma-controller@1200 {
>> + device_type = "dma-controller";
>> + compatible = "fsl,mpc5200-bestcomm";
>> + reg = <0x1200 0x80>;
>> + interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
>> + 3 4 0 3 5 0 3 6 0 3 7 0
>> + 3 8 0 3 9 0 3 10 0 3 11 0
>> + 3 12 0 3 13 0 3 14 0 3 15 0>;
>> + };
>> +
>> + xlb@1f00 {
>> + compatible = "fsl,mpc5200-xlb";
>> + reg = <0x1f00 0x100>;
>> + };
>> +
>> + serial@2000 { // PSC1
>> + compatible = "fsl,mpc5200-psc-uart";
>> + reg = <0x2000 0x100>;
>> + interrupts = <2 1 0>;
>> + };
>> +
>> + serial@2200 { // PSC2
>> + compatible = "fsl,mpc5200-psc-uart";
>> + reg = <0x2200 0x100>;
>> + interrupts = <2 2 0>;
>> + };
>> +
>> + serial@2c00 { // PSC6
>> + compatible = "fsl,mpc5200-psc-uart";
>> + reg = <0x2c00 0x100>;
>> + interrupts = <2 6 0>;
>> + };
>> +
>> + ethernet@3000 {
>> + compatible = "fsl,mpc5200-fec";
>> + reg = <0x3000 0x400>;
>> + local-mac-address = [ 00 00 00 00 00 00 ];
>> + interrupts = <2 5 0>;
>> + phy-handle = <&phy0>;
>> + };
>> +
>> + mdio@3000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,mpc5200-mdio";
>> + reg = <0x3000 0x400>; // fec range, since we need to setup fec interrupts
>> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
>> +
>> + phy0: ethernet-phy@0 {
>> + reg = <0>;
>
> For completeness, you should have a compatible property for the PHY
> here in the form "<vendor>,<part number>"
Ok, fix this.
>> + };
>> + };
>> +
>> + ata@3a00 {
>> + compatible = "fsl,mpc5200-ata";
>> + reg = <0x3a00 0x100>;
>> + interrupts = <2 7 0>;
>> + };
>> +
>> + i2c@3d40 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,mpc5200-i2c","fsl-i2c";
>> + reg = <0x3d40 0x40>;
>> + interrupts = <2 16 0>;
>> + fsl5200-clocking;
>
> I believe fsl5200-clocking is no longer required. There is a patch
> pending which removes this property from the other .dts files.
Ok, fix this.
>> +
>> + hwmon@2c {
>> + compatible = "ad,adm9240";
>> + reg = <0x2c>;
>> + };
>> + rtc@51 {
>> + compatible = "rtc,pcf8563";
>> + reg = <0x51>;
>> + };
>> + };
>> +
>> + sram@8000 {
>> + compatible = "fsl,mpc5200-sram";
>> + reg = <0x8000 0x4000>;
>> + };
>> +
>> + };
>> +
>> + localbus {
>> + compatible = "fsl,mpc5200-lpb","simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + ranges = <0 0 0xff800000 0x00800000
>> + 1 0 0x80000000 0x00800000
>> + 3 0 0x80000000 0x00800000>;
>> +
>> + flash@0,0 {
>> + compatible = "cfi-flash";
>> + reg = <0 0 0x00800000>;
>> + bank-width = <2>;
>> + device-width = <2>;
>> + #size-cells = <1>;
>> + #address-cells = <1>;
>> + partition@0 {
>> + label = "DTS";
>> + reg = <0x0 0x00100000>;
>> + };
>> + partition@100000 {
>> + label = "Kernel";
>> + reg = <0x100000 0x00200000>;
>> + };
>> + partition@300000 {
>> + label = "RootFS";
>> + reg = <0x00300000 0x00200000>;
>> + };
>> +
>> + partition@500000 {
>> + label = "user";
>> + reg = <0x00500000 0x00200000>;
>> + };
>> + partition@700000 {
>> + label = "U-Boot";
>> + reg = <0x00700000 0x00040000>;
>> + };
>> + partition@740000 {
>> + label = "Env";
>> + reg = <0x00740000 0x00010000>;
>> + };
>> + partition@750000 {
>> + label = "red. Env";
>> + reg = <0x00750000 0x00010000>;
>> + };
>> + partition@760000 {
>> + label = "reserve";
>> + reg = <0x00760000 0x000a0000>;
>> + };
>> + };
>> +
>> + sram@1,0 {
>> + compatible = "sram";
>> + reg = <1 0x100000 0x100000>;
>> + };
>> +
>> + gpio-controller-100@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>
> Here I see "manroland", but the top level model and compatible
> properties use "man". Which should it be (I suspect "manroland" is a
> better choice).
You are right, I change this too "manroland".
>> + reg = <3 0x00600100 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-104@3,0 {
>
> These names should be:
> gpio-controller@3,600100
> gpio-controller@3,600104
> gpio-controller@3,600201
>
> etc.
OK, fix this.
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600104 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-200@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600200 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-201@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600201 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-202@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600202 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-203@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600203 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-204@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600204 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-206@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600206 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-207@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x00600207 0x1>;
>> + gpio-controller;
>> + };
>> + gpio-controller-20f@3,0 {
>> + #gpio-cells = <2>;
>> + compatible = "manroland,mucmc52-aux-gpio";
>> + reg = <3 0x0060020f 0x1>;
>> + gpio-controller;
>> + };
>> +
>> + display@3,0 {
>
> similarly, this should be display@3,600000
Ok.
>> + device_type = "pdsp-display";
>
> Drop device_type
Ok.
>> + compatible = "pdsp-display";
>
> No vendor prefix?
I take a look at this.
>> + reg = <3 0x00600000 0x1000>;
>> + };
>> + };
>> +
>> +};
Thanks for reviewing this patch
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ 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