* Re: ppc Floating Point support status
From: Kumar Gala @ 2007-09-05 14:11 UTC (permalink / raw)
To: Ben Buchli; +Cc: linuxppc-dev
In-Reply-To: <200709040940.04801.bbuchli@xes-inc.com>
On Sep 4, 2007, at 9:40 AM, Ben Buchli wrote:
> On Wednesday 22 August 2007 15:52:09 Kumar Gala wrote:
>> On Aug 22, 2007, at 1:37 PM, Ben Buchli wrote:
>>> Hello everybody,
>>> I was wondering what the status was on supporting floating-point
>>> instructions
>>> for the mpc8548. I found the suggested patch:
>>> http://patchwork.ozlabs.org/linuxppc/patch?
>>> order=patch&filter=none&id=9455,
>>> but I'm not sure for what kernel version this is and when it will be
>>> officially supported.
>>>
>>> Thanks a lot for your help!
>>>
>>> Please CC to me (bbuchli at xes-inc.com) as I haven't subscribed to
>>> this list.
>>
>> I thing these are still up in the air based on having some sense of
>> testing related to them.
>>
>> - k
>
> Kumar,
> thanks for getting back with me.
> We're doing some early performance testing on one of our boards
> with an
> mpc8548e. I was wondering if there's a snapshot available that we
> could use
> and maybe do some working/testing on.
> Thanks a lot.
I'm confused as to what you are looking for. Is 2.6.23-rc5 not
sufficient?
- k
^ permalink raw reply
* Re: Breakpoint is not hitting for Kernel Debugging
From: Detlev Zundel @ 2007-09-05 13:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7c1681440709032107u3feb0684x34dcf44b5e43616@mail.gmail.com>
Hi,
> Try adding this line to your BDI config to clear/invalidate the page
> table base address so that the MMU translation works before the MMU
> has been initialised.
>
> ;; Following is to clear the page table base address
> WM32 0x000000f0 0x00000000
Did you really need this under any circumstance? To only hit a
breakpoint?
I am asking because recent experiences with BDI debugging showed that
there are some pitfalls that one can fall into (and these are only the
ones that I got aware of):
a) - PTBASE is 0x00 (!) for head_fsl_booke, head_44x,
- PTBASE is 0xf0 for head_4xx
Don't ask me if this makes any sense, but that's how it is right
now.
So for the original poster I would say a PTBASE 0x0 would be in
order.
b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
start_kernel just fine by only subtracting 0xc0000000 (using a
"default" translation) - it was only later (debugging dynamic
modules) that the wrong PTBASE hit me hard.
What proved very useful for me is the bdi command "phys <addr>" to
check the translation the BDI uses [you can use the command (as all
BDI commands) through gdb with "mon phys <addr>" btw.] - a wrong
PTBASE led to subsequent "JTAG instruction overruns" so I was pretty
sure that this was my real problem.
Best wishes
Detlev
--
The limits of my language stand for the limits of my world.
-- Ludwig Wittgenstein
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Scott Wood @ 2007-09-05 13:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070905114023.GA4072@localhost.localdomain>
On Wed, Sep 05, 2007 at 03:40:23PM +0400, Anton Vorontsov wrote:
> On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> > The kernel is of course welcome to do so -- and this may be a valid
> > reason to attach pin information to specific device nodes, if it actually
> > saves a non-negligible amount of power -- but it's not a reason to force
> > the kernel to have to care by not setting things up in the firmware.
>
> Well, I might agree here. But to me it seems unnatural that I have to
> upgrade bootloader to use SPI -- I can already boot the kernel.
Sure -- the firmware should have been done right the first time.
Unfortunately, it very often doesn't, and thus fixups in the kernel's
platform code are warranted, but the firmware is still the preferred
place to do it.
> Bootloader's duties are finished when kernel booted.
And this line of thinking is what causes boards to be shipped with
half-assed firmware. :-)
-Scott
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: Josh Boyer @ 2007-09-05 5:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905054645.GA26788@localhost.localdomain>
On Wed, 2007-09-05 at 15:46 +1000, David Gibson wrote:
> > > > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> > > >
> > > > Probably. I just need to find out where they are stored.
> > >
> > > It's not buried somewhere in the arch/ppc/boot code?
> >
> > It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
> > I'd rather avoid. But I did find where it's stored in flash, so I can
> > read it from there. I just need to do a little more work to get it in a
> > manner that can be used.
>
> Hrm.. is that address actually guaranteed to be stable across PIBS
> versions? If arch/ppc uses __res, I think we should do that too. It
> shouldn't be any worse than what we already do fot cuboot.
The address should be stable for all versions of PIBS that come on the
Bamboo boards, yes. And after looking at it a bit more, the wrapper in
arch/ppc for PIBS essentially mocks up __res by reading the values out
of flash. So the way I'm doing it is the way it was already done.
josh
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Gerhard Pircher @ 2007-09-05 11:54 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905024805.GE17189@localhost.localdomain>
-------- Original-Nachricht --------
> Datum: Wed, 5 Sep 2007 12:48:05 +1000
> Von: David Gibson <david@gibson.dropbear.id.au>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Segher Boessenkool <segher@kernel.crashing.org>, linuxppc-dev@ozlabs.org
> Betreff: Re: [RFC] AmigaOne device tree source v2
> That looks totally bogus. Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy ISA IO space is an example). But this doesn't look like
> such a case - it just looks like whoever did the device tree
> misunderstood the distinction between reg and ranges.
AmigaOne's PCI bridge implements PCI config with indirect addressing, but
not within the ISA I/O space. I just wanted to clear up the meaning of
this reg entry, because it looks like everyone interprets the OF spec a
little bit differently.
> > > PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> > > PowerPC system bus. So, it can not be mentioned in the "ranges"
> > > property, but the PHB registers used to access it should be shown
> > > in the "reg" property. It could be a simple linear window (it
> > > sounds like it is here?), but it could for example also be
> > > implemented via an address/data register pair.
>
> Err... huh? The legacy IO space is assigned a block of addresses in
> 3-word "OF-PCI-space by the PCI binding. When that is translated into
> an MMIO range by the bridge, there's no reason that can't be encoded
> into the ranges property.
I defined the legacy I/O space together with the PCI I/O space in the
ranges property of the PCI node:
ranges = <01000000 0 00000000 fe000000 0 00c00000
The first 64k of this address space are mapped to ISA I/O in the PCI2ISA
bridge node.
> The whole damn point of the device tree is to avoid using this kind of
> non-local information "I know what the board type is over there, so it
> must be this PCI bridge over here". The node should have a compatible
> property which is sufficient to select the right bridge driver.
Yeah, I defined a compatible = "mai,articias"; property in the pci node.
Are there any naming conventions (maybe lower case only)?
> I think this is typically badly done at the moment, simply because PCI
> has historically been set up by the platform code, rather than by a
> "host bridge driver" in the mould of other drivers. I don't see that
> changing real soon, but that doesn't mean we shouldn't at least put
> enough information in the device tree to make it possible.
I agree (even if it means more work for me :-)
I'll post a revised version of the device tree.
Thanks!
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: Segher Boessenkool @ 2007-09-05 11:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1188952766.3223.3.camel@localhost.localdomain>
>> Hrm.. I'm still slightly uneasy though. In my Ebony device tree, the
>> POB's ranges exists to embed the 32-bit OPB space into the 64-bit PLB
>> space by tacking on a 0x1 in bits 32:35. In your 405gp ranges, you're
>> describing just the address range used by OPB peripherals
>> (0xef600000-0xf0000000) as residing at address 0 in OPB-space.
>>
>> Since the ranges will still generate the right physical addresses, I
>> guess it doesn't matter. But I'm not sure it meets the principle of
>> least surprise - since I think the documentation generally talks as
>> though addresses on the 405 OPB bus are identical to addreses on the
>> PLB.
>
> I don't care either way. If I remember correctly, this way of doing it
> came out of a discussion with Segher.
I don't think I ever said that this is a better way of doing things --
then again, I change my mind now and then.
Someone needs to write down a proposed device binding for these busses,
and then we can really discuss things ;-)
Segher
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Anton Vorontsov @ 2007-09-05 11:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904182028.GC18280@ld0162-tx32.am.freescale.net>
On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> On Tue, Sep 04, 2007 at 02:47:50PM +0400, Anton Vorontsov wrote:
> > > _and system GPIOs_ :-)
> >
> > Yup, firmware should set up gpios, to make initial kernel boot.
>
> No, it should set all pins and similar setup-once type initialization
> that is board-specific rather than device-specific -- there's no reason
> for the kernel to need to care about that sort of thing.
>
> > After that, kernel can and should manage GPIOs. Few examples.
> >
> > Say units (like USB or SPI) can work in very different modes. And
> > it's okay if user want to change device mode in the runtime.
>
> This is a special case that warrants kernel involvement. It should not
> be used as justification for the bootloader leaving pins unconfigured in
> the majority of cases where it does not make sense to change them at
> runtime.
>
> > Another example, power management - if some unit temporarily unused,
> > to save power GPIOs should be set up differently. Say if SPI unit
> > turned off (unused just now), it's wise to bring their dedicated
> > GPIOs to "power saving" state (be it output0/1 or input, it
> > depends).
>
> The kernel is of course welcome to do so -- and this may be a valid
> reason to attach pin information to specific device nodes, if it actually
> saves a non-negligible amount of power -- but it's not a reason to force
> the kernel to have to care by not setting things up in the firmware.
Well, I might agree here. But to me it seems unnatural that I have to
upgrade bootloader to use SPI -- I can already boot the kernel.
Bootloader's duties are finished when kernel booted. And if already
running kernel is unable to do something, it's not bootloader's fault
anymore, but kernel's itself. At least I like to think so. Maybe I'm
wrong, yet not sure. ;-)
And from the practical point of view, upgrading bootloader is much
more error-prone and risky for the users without proper rescue tools
and knowledge. Kernel is easier to deploy after bug-fixing (and
wrongly set up GPIO pin is a bug). That's why I tend to like "dumb
and simple" bootloaders and do not hang up too much duties on it.
Anyhow, all above is just my own preference, I'm not arguing at
all, because personally I'm fine with any option, be it dts, board
file, device driver's file, the bootloader, or all at once. ;-)
> -Scott
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Problems enabling NTP on ELDK
From: Johan Borkhuis @ 2007-09-05 11:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I tried enabling NTP on my embedded machine (using ELDK 4.1, ppc_85xx,
kernel version 2.6.14 with Xenomai 2.3.2). After I did that I noticed
that ksoftirqd/0 suddenly took almost all processor time (> 95%). What
is causing this? Is there a way around this, or is this something that
does not cause any problems?
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-05 8:18 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070904213339.D3DB7788046@mail56-fra.bigfish.com>
Wolfgang Reissnegger wrote:
> Hi Thomas,
>
> Xilinx is building the tools in the EDK to work with VxWorks and for Standalone systems. In order to compile a Linux kernel you need to get a toolchain from one of the Third Party vendors, such as MontaVista. They have the correct linker scripts for building a kernel.
>
> Cheers,
> Wolfgang
>
> Thomas Gerlach wrote:
>
>> hi folks,
>>
>>
>> my name is thomas trying to make embedded linux run on a powerpc, but
>> we've got special boards here, although we use a xilinx virtex4
>> fpga...
>>
>> as you said in the nabble-thread (see subject), i set up edk9.1
>> software platform settings und ran libgen to get the xparameters*
>> files. i copied those bsp files into the kernel tree (i use your
>> kernel linux-2.6-virtex from git.secretlabs.ca/git). after
>> configuring the kernel settigs, i try
>>
>> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
>>
>> what i get is the following output:
>>
>>
>>> CHK include/linux/version.h
>>> CHK include/linux/utsrelease.h
>>> CALL scripts/checksyscalls.sh
>>> CHK include/linux/compile.h
>>> LD init/mounts.o
>>> powerpc-eabi-ld: cannot find boot.o
>>> make[1]: *** [init/mounts.o] Error 1
>>> make: *** [init] Error 2
>>>
>> so, i searched for boot.o (it exists) and even copied it into several
>> dirs of the linux kernel tree (where i thought i would make sense),
>> but the problem still remains.
>>
>> googling results in
>>
>> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
>>
>>
>> and this, too, doesn't take me further in solving the problem.
>>
>> i hope you can help me.
>>
>> many thanks in advance,
>>
>> kind regards
>> thomas gerlach
>>
hi,
thank you much for this hint, i'll try it. this was the last thing i
thought of... ;)
kepp on cross-compiling, :)
regards
thomas
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-05 8:17 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40709040747j503a2054x27ba2b8146a93ff8@mail.gmail.com>
Grant Likely wrote:
> On 9/4/07, Thomas Gerlach <gerlach@kip.uni-heidelberg.de> wrote:
>
>> hi folks,
>>
>>
>> my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
>>
>> as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
>>
>> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
>>
>
> You should be using a Linux cross compiler, not powerpc-eabi-. The
> Xilinx cross compiler will not work to compile Linux kernels.
>
> You can build yourself a cross compiler using 'crosstool':
> http://www.kegel.org/crosstool.
>
> Alternately, you can download ELDK:
> http://www.denx.de/wiki/view/DULG/ELDKAvailability
>
> Cheers,
> g.
>
>
hi,
thank you much for this hint. this was the last thing i thought of... ;)
so long, keep on cross-compiling! :)
regards,
thomas
^ permalink raw reply
* Re: [PATCH 3/9] 8xx: Add pin and clock setting functions.
From: Vitaly Bordug @ 2007-09-05 7:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070831204418.GA3461@ld0162-tx32.am.freescale.net>
On Fri, 31 Aug 2007 15:44:18 -0500
Scott Wood wrote:
> > > + u32 mask = 7;
> > > +
> > gotta at least briefly explain the clue here, too.
>
> I'm not sure what you mean... what exactly are you asking me to
> explain?
>
> Note that this code is mostly duplicated from the existing CPM2
> version.
>
Then it would be good to mention that in short comment block before function.
> > We're adding helper functions and should be ready that something
> > somewhere won't work as expected.
>
> Could you elaborate on what you expect to possibly not work, or what
> we should do to "be ready"?
Some new PQ-like board being added to powerpc. I mean, each newly-added non-static function should have some sort of
description unless it(function) is completely self-explanatory.
Just a few words either here as a comment or in patch description, what the function supposed to do
and which way, so that someone not familiar with cpm/cpm2, would quickly understand
what's happening in there.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: David Gibson @ 2007-09-05 5:46 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1188952819.3223.5.camel@localhost.localdomain>
On Tue, Sep 04, 2007 at 07:40:19PM -0500, Josh Boyer wrote:
> On Wed, 2007-09-05 at 11:10 +1000, David Gibson wrote:
> > On Mon, Sep 03, 2007 at 08:42:11AM -0500, Josh Boyer wrote:
> > > On Mon, 2007-09-03 at 11:01 +1000, David Gibson wrote:
> > > > On Fri, Aug 31, 2007 at 03:04:51PM -0500, Josh Boyer wrote:
> > > > > Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> > > > > linker declarations that have been moved into ops.h
> > > > >
> > > > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > > >
> > > > [snip]
> > > > > --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> > > > > +++ linux-2.6/arch/powerpc/boot/bamboo.c
> > > > > @@ -24,8 +24,7 @@
> > > > > #include "4xx.h"
> > > > > #include "44x.h"
> > > > >
> > > > > -extern char _dtb_start[];
> > > > > -extern char _dtb_end[];
> > > > > +static u8 *bamboo_mac0, *bamboo_mac1;
> > > > >
> > > > > static void bamboo_fixups(void)
> > > > > {
> > > > > @@ -34,12 +33,16 @@ static void bamboo_fixups(void)
> > > > > ibm440ep_fixup_clocks(sysclk, 11059200);
> > > > > ibm4xx_fixup_memsize();
> > > > > ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> > > > > + if (bamboo_mac0 && bamboo_mac1)
> > > > > + dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> > > >
> > > > Bit ugly that you only set the MAC address for any ethernet if they're
> > > > supplied for every ethernet.
> > >
> > > Good point. Will fix.
> > >
> > > > > simple_alloc_init(_end, avail_ram, 32, 64);
> > > > > - bamboo_init();
> > > > > + bamboo_init(NULL, NULL);
> > > >
> > > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> > >
> > > Probably. I just need to find out where they are stored.
> >
> > It's not buried somewhere in the arch/ppc/boot code?
>
> It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
> I'd rather avoid. But I did find where it's stored in flash, so I can
> read it from there. I just need to do a little more work to get it in a
> manner that can be used.
Hrm.. is that address actually guaranteed to be stable across PIBS
versions? If arch/ppc uses __res, I think we should do that too. It
shouldn't be any worse than what we already do fot cuboot.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] powerpc: Add workaround for MPICs with broken register reads
From: Olof Johansson @ 2007-09-05 2:44 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Some versions of PWRficient 1682M have an interrupt controller in which
the first register in each pair for interrupt sources doesn't always
read with the right polarity/sense values.
To work around this, keep a software copy of the register instead. Since
it's not modified from the mpic itself, it's a feasible solution. Still,
keep it under a config option to avoid wasting memory on other platforms.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 041df77..b9f1efa 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -137,6 +137,10 @@ config MPIC_U3_HT_IRQS
depends on PPC_MAPLE
default y
+config MPIC_BROKEN_REGREAD
+ bool
+ depends on PPC_PASEMI
+
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index 95cd90f..117d90a 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -5,6 +5,7 @@ config PPC_PASEMI
select MPIC
select PPC_UDBG_16550
select PPC_NATIVE
+ select MPIC_BROKEN_REGREAD
help
This option enables support for PA Semi's PWRficient line
of SoC processors, including PA6T-1682M
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 74c64c0..c0fe063 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -228,8 +228,13 @@ static inline u32 _mpic_irq_read(struct mpic *mpic, unsigned int src_no, unsigne
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
- return _mpic_read(mpic->reg_type, &mpic->isus[isu],
- reg + (idx * MPIC_INFO(IRQ_STRIDE)));
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ return mpic->isu_reg0_shadow[idx];
+ else
+#endif
+ return _mpic_read(mpic->reg_type, &mpic->isus[isu],
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -240,6 +245,11 @@ static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
_mpic_write(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
+
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ mpic->isu_reg0_shadow[idx] = value;
+#endif
}
#define mpic_read(b,r) _mpic_read(mpic->reg_type,&(b),(r))
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 262db6b..c877fa7 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -309,6 +309,10 @@ struct mpic
unsigned long *hwirq_bitmap;
#endif
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ u32 isu_reg0_shadow[MPIC_MAX_IRQ_SOURCES];
+#endif
+
/* link */
struct mpic *next;
^ permalink raw reply related
* [PATCH] powerpc: Remove warning in arch/powerpc/kernel/sysfs.c
From: Olof Johansson @ 2007-09-05 2:43 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
arch/powerpc/kernel/sysfs.c: In function 'cpu_add_sysdev_attr_group':
arch/powerpc/kernel/sysfs.c:388: warning: ignoring return value of
'sysfs_create_group', declared with attribute warn_unused_result
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 55d29ed..63c0302 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -380,12 +380,14 @@ int cpu_add_sysdev_attr_group(struct attribute_group *attrs)
{
int cpu;
struct sys_device *sysdev;
+ int ret;
mutex_lock(&cpu_mutex);
for_each_possible_cpu(cpu) {
sysdev = get_cpu_sysdev(cpu);
- sysfs_create_group(&sysdev->kobj, attrs);
+ ret = sysfs_create_group(&sysdev->kobj, attrs);
+ WARN_ON(ret != 0);
}
mutex_unlock(&cpu_mutex);
^ permalink raw reply related
* [PATCH] powerpc: Move lowlevel runlatch calls under cpu feature control
From: Olof Johansson @ 2007-09-05 2:42 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
There's no need to call the runlatch on functions on processors that
don't implement them (CPU_FTR_CTRL).
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 33c4e8c..cec5908 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -656,7 +656,9 @@ hardware_interrupt_common:
FINISH_NAP
hardware_interrupt_entry:
DISABLE_INTS
+BEGIN_FTR_SECTION
bl .ppc64_runlatch_on
+END_FTR_SECTION_IFSET(CPU_FTR_CTRL)
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_IRQ
b .ret_from_except_lite
diff --git a/include/asm-powerpc/exception.h b/include/asm-powerpc/exception.h
index d850c8e..39abdb0 100644
--- a/include/asm-powerpc/exception.h
+++ b/include/asm-powerpc/exception.h
@@ -282,7 +282,9 @@ label##_common: \
EXCEPTION_PROLOG_COMMON(trap, PACA_EXGEN); \
FINISH_NAP; \
DISABLE_INTS; \
+BEGIN_FTR_SECTION \
bl .ppc64_runlatch_on; \
+END_FTR_SECTION_IFSET(CPU_FTR_CTRL) \
addi r3,r1,STACK_FRAME_OVERHEAD; \
bl hdlr; \
b .ret_from_except_lite
^ permalink raw reply related
* [PATCH] powerpc: Don't use generic machine check parsing everywhere
From: Olof Johansson @ 2007-09-05 2:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
If a platform provide it's own machine check handler, assume that code
will handle the reason parsing and reporting the error. The current
default fall-though only makes sense on a few 32-bit platforms that
lack individual handlers.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index ccfc99d..ce1aafc 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -440,34 +440,36 @@ void machine_check_exception(struct pt_regs *regs)
if (reason & MCSR_BUS_WRERR)
printk("Bus - Write Bus Error on buffered store or cache line push\n");
#else /* !CONFIG_4xx && !CONFIG_E500 && !CONFIG_E200 */
- printk("Machine check in kernel mode.\n");
- printk("Caused by (from SRR1=%lx): ", reason);
- switch (reason & 0x601F0000) {
- case 0x80000:
- printk("Machine check signal\n");
- break;
- case 0: /* for 601 */
- case 0x40000:
- case 0x140000: /* 7450 MSS error and TEA */
- printk("Transfer error ack signal\n");
- break;
- case 0x20000:
- printk("Data parity error signal\n");
- break;
- case 0x10000:
- printk("Address parity error signal\n");
- break;
- case 0x20000000:
- printk("L1 Data Cache error\n");
- break;
- case 0x40000000:
- printk("L1 Instruction Cache error\n");
- break;
- case 0x00100000:
- printk("L2 data cache parity error\n");
- break;
- default:
- printk("Unknown values in msr\n");
+ if (!ppc_md.machine_check_exception) {
+ printk("Machine check in kernel mode.\n");
+ printk("Caused by (from SRR1=%lx): ", reason);
+ switch (reason & 0x601F0000) {
+ case 0x80000:
+ printk("Machine check signal\n");
+ break;
+ case 0: /* for 601 */
+ case 0x40000:
+ case 0x140000: /* 7450 MSS error and TEA */
+ printk("Transfer error ack signal\n");
+ break;
+ case 0x20000:
+ printk("Data parity error signal\n");
+ break;
+ case 0x10000:
+ printk("Address parity error signal\n");
+ break;
+ case 0x20000000:
+ printk("L1 Data Cache error\n");
+ break;
+ case 0x40000000:
+ printk("L1 Instruction Cache error\n");
+ break;
+ case 0x00100000:
+ printk("L2 data cache parity error\n");
+ break;
+ default:
+ printk("Unknown values in msr\n");
+ }
}
#endif /* CONFIG_4xx */
^ permalink raw reply related
* [PATCH] powerpc: Remove unused platform_machine_check()
From: Olof Johansson @ 2007-09-05 2:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Remove leftover cruft from ARCH=ppc.
There are no users of platform_machine_check() in ARCH=powerpc, and none
should be added (they should use ppc_md.machine_check_handler instead).
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index d8502e3..ccfc99d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -324,15 +324,6 @@ static inline int check_io_access(struct pt_regs *regs)
#define clear_single_step(regs) ((regs)->msr &= ~MSR_SE)
#endif
-/*
- * This is "fall-back" implementation for configurations
- * which don't provide platform-specific machine check info
- */
-void __attribute__ ((weak))
-platform_machine_check(struct pt_regs *regs)
-{
-}
-
void machine_check_exception(struct pt_regs *regs)
{
int recover = 0;
@@ -480,12 +471,6 @@ void machine_check_exception(struct pt_regs *regs)
}
#endif /* CONFIG_4xx */
- /*
- * Optional platform-provided routine to print out
- * additional info, e.g. bus error registers.
- */
- platform_machine_check(regs);
-
if (debugger_fault_handler(regs))
return;
die("Machine check", regs, SIGBUS);
^ permalink raw reply related
* Re: [patch 2/6] cuimage for Bamboo board
From: Josh Boyer @ 2007-09-05 0:40 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905011045.GC17189@localhost.localdomain>
On Wed, 2007-09-05 at 11:10 +1000, David Gibson wrote:
> On Mon, Sep 03, 2007 at 08:42:11AM -0500, Josh Boyer wrote:
> > On Mon, 2007-09-03 at 11:01 +1000, David Gibson wrote:
> > > On Fri, Aug 31, 2007 at 03:04:51PM -0500, Josh Boyer wrote:
> > > > Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> > > > linker declarations that have been moved into ops.h
> > > >
> > > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > >
> > > [snip]
> > > > --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> > > > +++ linux-2.6/arch/powerpc/boot/bamboo.c
> > > > @@ -24,8 +24,7 @@
> > > > #include "4xx.h"
> > > > #include "44x.h"
> > > >
> > > > -extern char _dtb_start[];
> > > > -extern char _dtb_end[];
> > > > +static u8 *bamboo_mac0, *bamboo_mac1;
> > > >
> > > > static void bamboo_fixups(void)
> > > > {
> > > > @@ -34,12 +33,16 @@ static void bamboo_fixups(void)
> > > > ibm440ep_fixup_clocks(sysclk, 11059200);
> > > > ibm4xx_fixup_memsize();
> > > > ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> > > > + if (bamboo_mac0 && bamboo_mac1)
> > > > + dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> > >
> > > Bit ugly that you only set the MAC address for any ethernet if they're
> > > supplied for every ethernet.
> >
> > Good point. Will fix.
> >
> > > > simple_alloc_init(_end, avail_ram, 32, 64);
> > > > - bamboo_init();
> > > > + bamboo_init(NULL, NULL);
> > >
> > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> >
> > Probably. I just need to find out where they are stored.
>
> It's not buried somewhere in the arch/ppc/boot code?
It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
I'd rather avoid. But I did find where it's stored in flash, so I can
read it from there. I just need to do a little more work to get it in a
manner that can be used.
josh
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: Josh Boyer @ 2007-09-05 0:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905023612.GD17189@localhost.localdomain>
On Wed, 2007-09-05 at 12:36 +1000, David Gibson wrote:
> On Tue, Sep 04, 2007 at 07:42:03AM -0500, Josh Boyer wrote:
> > On Sun, 02 Sep 2007 08:59:44 -0500
> > Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> [snip]
> > > > > + POB0: opb {
> > > > > + compatible = "ibm,opb";
> > > >
> > > > Need an opb-405gp here, too.
> > >
> > > Yep.
> >
> > Fixed.
> >
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + ranges = <0 ef600000 a00000>;
> > > >
> > > > Hrm... something we ought to clarify is the interpretation of the
> > > > POB0_BEAR register with respect to the bridge's ranges property. For
> > > > 440 I think the BEAR will need to be interpreted as an OPB address,
> > > > rather than a PLB address, but I'm not sure if that will work here
> > > > with the limited ranges property you have.
> > >
> > > Ok, I'll look at this.
> >
> > The BEAR will still be interpreted as a PLB address here as far as I
> > can see. The ranges spans the entire OPB space. Am I missing
> > something?
>
> Ah, sorry, my mistake. I thought the BEAR register would encode an
> OPB address rather than a PLB address (and thus, be only 32-bits wide
> on 440). In fact it appears it does encode a PLB address (and is
> split into BEARH and BEARL registers on 440).
Right.
> Hrm.. I'm still slightly uneasy though. In my Ebony device tree, the
> POB's ranges exists to embed the 32-bit OPB space into the 64-bit PLB
> space by tacking on a 0x1 in bits 32:35. In your 405gp ranges, you're
> describing just the address range used by OPB peripherals
> (0xef600000-0xf0000000) as residing at address 0 in OPB-space.
>
> Since the ranges will still generate the right physical addresses, I
> guess it doesn't matter. But I'm not sure it meets the principle of
> least surprise - since I think the documentation generally talks as
> though addresses on the 405 OPB bus are identical to addreses on the
> PLB.
I don't care either way. If I remember correctly, this way of doing it
came out of a discussion with Segher.
josh
^ permalink raw reply
* [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
From: Olof Johansson @ 2007-09-05 2:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit 6a30bd1e2160e921a8fb051b472dfaf068f4f386
Author: Olof Johansson <olof@lixom.net>
Date: Tue Sep 4 21:53:30 2007 -0500
[POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
Move pasemi_idle_init() to be a late_initcall instead of being called from
setup_arch(). This way the cpufreq driver has a chance to initialize and
save away the boot time astate before we go to idle for the first time.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 3c962d5..d8e1fcc 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -72,8 +72,11 @@ static int pasemi_system_reset_exception(struct pt_regs *regs)
return 1;
}
-void __init pasemi_idle_init(void)
+static int __init pasemi_idle_init(void)
{
+ if (!machine_is(pasemi))
+ return -ENODEV;
+
#ifndef CONFIG_PPC_PASEMI_CPUFREQ
printk(KERN_WARNING "No cpufreq driver, powersavings modes disabled\n");
current_mode = 0;
@@ -82,7 +85,10 @@ void __init pasemi_idle_init(void)
ppc_md.system_reset_exception = pasemi_system_reset_exception;
ppc_md.power_save = modes[current_mode].entry;
printk(KERN_INFO "Using PA6T idle loop (%s)\n", modes[current_mode].name);
+
+ return 0;
}
+late_initcall(pasemi_idle_init);
static int __init idle_param(char *p)
{
diff --git a/arch/powerpc/platforms/pasemi/pasemi.h b/arch/powerpc/platforms/pasemi/pasemi.h
index 6fd2fe7..516acab 100644
--- a/arch/powerpc/platforms/pasemi/pasemi.h
+++ b/arch/powerpc/platforms/pasemi/pasemi.h
@@ -10,8 +10,6 @@ extern void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset);
extern void __init alloc_iobmap_l2(void);
-extern void __init pasemi_idle_init(void);
-
/* Power savings modes, implemented in asm */
extern void idle_spin(void);
extern void idle_doze(void);
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index fe9a5d6..5ddf40a 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -115,8 +115,6 @@ void __init pas_setup_arch(void)
/* Remap SDC register for doing reset */
/* XXXOJN This should maybe come out of the device tree */
reset_reg = ioremap(0xfc101100, 4);
-
- pasemi_idle_init();
}
static int __init pas_setup_mce_regs(void)
^ permalink raw reply related
* [POWERPC] pasemi: Print more information at machine check
From: Olof Johansson @ 2007-09-05 2:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit c456a6cdfe86cb0e2e2187f5e76768f9215e0693
Author: Olof Johansson <olof@lixom.net>
Date: Tue Sep 4 21:49:51 2007 -0500
[POWERPC] pasemi: Print more information at machine check
Add printout of some SoC error status registers, and dump the SLB contents
for those machine check events where it makes sense.
Since we can't go about and ioremap registers at machine check time,
and we generally want to do as little as possible to print out the
information, pre-build a table of the registers to dump and their address
in the common PCI config space range.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 05def62..fe9a5d6 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -39,8 +39,21 @@
#include "pasemi.h"
+/* SDC reset register, must be pre-mapped at reset time */
static void __iomem *reset_reg;
+/* Various error status registers, must be pre-mapped at MCE time */
+
+#define MAX_MCE_REGS 32
+struct mce_regs {
+ char *name;
+ void __iomem *addr;
+};
+
+static struct mce_regs mce_regs[MAX_MCE_REGS];
+static int num_mce_regs;
+
+
static void pas_restart(char *cmd)
{
printk("Restarting...\n");
@@ -106,6 +119,59 @@ void __init pas_setup_arch(void)
pasemi_idle_init();
}
+static int __init pas_setup_mce_regs(void)
+{
+ struct pci_dev *dev;
+ int reg;
+
+ if (!machine_is(pasemi))
+ return -ENODEV;
+
+ /* Remap various SoC status registers for use by the MCE handler */
+
+ reg = 0;
+
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa00a, NULL);
+ while (dev && reg < MAX_MCE_REGS) {
+ mce_regs[reg].name = kasprintf(GFP_KERNEL,
+ "mc%d_mcdebug_errsta", reg);
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x730);
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa00a, dev);
+ reg++;
+ }
+
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
+ if (dev && reg+4 < MAX_MCE_REGS) {
+ mce_regs[reg].name = "iobdbg_IntStatus1";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x438);
+ reg++;
+ mce_regs[reg].name = "iobdbg_IOCTbusIntDbgReg";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x454);
+ reg++;
+ mce_regs[reg].name = "iobiom_IntStatus";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0xc10);
+ reg++;
+ mce_regs[reg].name = "iobiom_IntDbgReg";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0xc1c);
+ reg++;
+ }
+
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa009, NULL);
+ if (dev && reg+2 < MAX_MCE_REGS) {
+ mce_regs[reg].name = "l2csts_IntStatus";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x200);
+ reg++;
+ mce_regs[reg].name = "l2csts_Cnt";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x214);
+ reg++;
+ }
+
+ num_mce_regs = reg;
+
+ return 0;
+}
+device_initcall(pas_setup_mce_regs);
+
static __init void pas_init_IRQ(void)
{
struct device_node *np;
@@ -166,25 +232,34 @@ static int pas_machine_check_handler(struct pt_regs *regs)
{
int cpu = smp_processor_id();
unsigned long srr0, srr1, dsisr;
+ int dump_slb = 0;
+ int i;
srr0 = regs->nip;
srr1 = regs->msr;
dsisr = mfspr(SPRN_DSISR);
printk(KERN_ERR "Machine Check on CPU %d\n", cpu);
- printk(KERN_ERR "SRR0 0x%016lx SRR1 0x%016lx\n", srr0, srr1);
- printk(KERN_ERR "DSISR 0x%016lx DAR 0x%016lx\n", dsisr, regs->dar);
+ printk(KERN_ERR "SRR0 0x%016lx SRR1 0x%016lx\n", srr0, srr1);
+ printk(KERN_ERR "DSISR 0x%016lx DAR 0x%016lx\n", dsisr, regs->dar);
+ printk(KERN_ERR "BER 0x%016lx MER 0x%016lx\n", mfspr(SPRN_PA6T_BER),
+ mfspr(SPRN_PA6T_MER));
+ printk(KERN_ERR "IER 0x%016lx DER 0x%016lx\n", mfspr(SPRN_PA6T_IER),
+ mfspr(SPRN_PA6T_DER));
printk(KERN_ERR "Cause:\n");
if (srr1 & 0x200000)
printk(KERN_ERR "Signalled by SDC\n");
+
if (srr1 & 0x100000) {
printk(KERN_ERR "Load/Store detected error:\n");
if (dsisr & 0x8000)
printk(KERN_ERR "D-cache ECC double-bit error or bus error\n");
if (dsisr & 0x4000)
printk(KERN_ERR "LSU snoop response error\n");
- if (dsisr & 0x2000)
+ if (dsisr & 0x2000) {
printk(KERN_ERR "MMU SLB multi-hit or invalid B field\n");
+ dump_slb = 1;
+ }
if (dsisr & 0x1000)
printk(KERN_ERR "Recoverable Duptags\n");
if (dsisr & 0x800)
@@ -192,13 +267,40 @@ static int pas_machine_check_handler(struct pt_regs *regs)
if (dsisr & 0x400)
printk(KERN_ERR "TLB parity error count overflow\n");
}
+
if (srr1 & 0x80000)
printk(KERN_ERR "Bus Error\n");
- if (srr1 & 0x40000)
+
+ if (srr1 & 0x40000) {
printk(KERN_ERR "I-side SLB multiple hit\n");
+ dump_slb = 1;
+ }
+
if (srr1 & 0x20000)
printk(KERN_ERR "I-cache parity error hit\n");
+ if (num_mce_regs == 0)
+ printk(KERN_ERR "No MCE registers mapped yet, can't dump\n");
+ else
+ printk(KERN_ERR "SoC debug registers:\n");
+
+ for (i = 0; i < num_mce_regs; i++)
+ printk(KERN_ERR "%s: 0x%08x\n", mce_regs[i].name,
+ in_le32(mce_regs[i].addr));
+
+ if (dump_slb) {
+ unsigned long e, v;
+ int i;
+
+ printk(KERN_ERR "slb contents:\n");
+ for (i = 0; i < SLB_NUM_ENTRIES; i++) {
+ asm volatile("slbmfee %0,%1" : "=r" (e) : "r" (i));
+ asm volatile("slbmfev %0,%1" : "=r" (v) : "r" (i));
+ printk(KERN_ERR "%02d %016lx %016lx\n", i, e, v);
+ }
+ }
+
+
/* SRR1[62] is from MSR[62] if recoverable, so pass that back */
return !!(srr1 & 0x2);
}
^ permalink raw reply related
* [POWERPC] pasemi: Export more SPRs to sysfs when CONFIG_DEBUG_KERNEL=y
From: Olof Johansson @ 2007-09-05 2:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit e34d30c44975ed7db1542f6548f2716185c87baf
Author: Olof Johansson <olof@lixom.net>
Date: Sat Sep 1 14:45:07 2007 -0500
[POWERPC] pasemi: Export more SPRs to sysfs when CONFIG_DEBUG_KERNEL=y
Export some of the implementation-specific registers via sysfs. Useful
when debugging, etc.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 55d29ed..d7835ba 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -197,6 +197,36 @@ SYSFS_PMCSETUP(pa6t_pmc3, SPRN_PA6T_PMC3);
SYSFS_PMCSETUP(pa6t_pmc4, SPRN_PA6T_PMC4);
SYSFS_PMCSETUP(pa6t_pmc5, SPRN_PA6T_PMC5);
+#ifdef CONFIG_DEBUG_KERNEL
+SYSFS_PMCSETUP(hid0, SPRN_HID0);
+SYSFS_PMCSETUP(hid1, SPRN_HID1);
+SYSFS_PMCSETUP(hid4, SPRN_HID4);
+SYSFS_PMCSETUP(hid5, SPRN_HID5);
+SYSFS_PMCSETUP(ima0, SPRN_PA6T_IMA0);
+SYSFS_PMCSETUP(ima1, SPRN_PA6T_IMA1);
+SYSFS_PMCSETUP(ima2, SPRN_PA6T_IMA2);
+SYSFS_PMCSETUP(ima3, SPRN_PA6T_IMA3);
+SYSFS_PMCSETUP(ima4, SPRN_PA6T_IMA4);
+SYSFS_PMCSETUP(ima5, SPRN_PA6T_IMA5);
+SYSFS_PMCSETUP(ima6, SPRN_PA6T_IMA6);
+SYSFS_PMCSETUP(ima7, SPRN_PA6T_IMA7);
+SYSFS_PMCSETUP(ima8, SPRN_PA6T_IMA8);
+SYSFS_PMCSETUP(ima9, SPRN_PA6T_IMA9);
+SYSFS_PMCSETUP(imaat, SPRN_PA6T_IMAAT);
+SYSFS_PMCSETUP(btcr, SPRN_PA6T_BTCR);
+SYSFS_PMCSETUP(pccr, SPRN_PA6T_PCCR);
+SYSFS_PMCSETUP(rpccr, SPRN_PA6T_RPCCR);
+SYSFS_PMCSETUP(der, SPRN_PA6T_DER);
+SYSFS_PMCSETUP(mer, SPRN_PA6T_MER);
+SYSFS_PMCSETUP(ber, SPRN_PA6T_BER);
+SYSFS_PMCSETUP(ier, SPRN_PA6T_IER);
+SYSFS_PMCSETUP(sier, SPRN_PA6T_SIER);
+SYSFS_PMCSETUP(siar, SPRN_PA6T_SIAR);
+SYSFS_PMCSETUP(tsr0, SPRN_PA6T_TSR0);
+SYSFS_PMCSETUP(tsr1, SPRN_PA6T_TSR1);
+SYSFS_PMCSETUP(tsr2, SPRN_PA6T_TSR2);
+SYSFS_PMCSETUP(tsr3, SPRN_PA6T_TSR3);
+#endif /* CONFIG_DEBUG_KERNEL */
static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
@@ -228,6 +258,36 @@ static struct sysdev_attribute pa6t_attrs[] = {
_SYSDEV_ATTR(pmc3, 0600, show_pa6t_pmc3, store_pa6t_pmc3),
_SYSDEV_ATTR(pmc4, 0600, show_pa6t_pmc4, store_pa6t_pmc4),
_SYSDEV_ATTR(pmc5, 0600, show_pa6t_pmc5, store_pa6t_pmc5),
+#ifdef CONFIG_DEBUG_KERNEL
+ _SYSDEV_ATTR(hid0, 0600, show_hid0, store_hid0),
+ _SYSDEV_ATTR(hid1, 0600, show_hid1, store_hid1),
+ _SYSDEV_ATTR(hid4, 0600, show_hid4, store_hid4),
+ _SYSDEV_ATTR(hid5, 0600, show_hid5, store_hid5),
+ _SYSDEV_ATTR(ima0, 0600, show_ima0, store_ima0),
+ _SYSDEV_ATTR(ima1, 0600, show_ima1, store_ima1),
+ _SYSDEV_ATTR(ima2, 0600, show_ima2, store_ima2),
+ _SYSDEV_ATTR(ima3, 0600, show_ima3, store_ima3),
+ _SYSDEV_ATTR(ima4, 0600, show_ima4, store_ima4),
+ _SYSDEV_ATTR(ima5, 0600, show_ima5, store_ima5),
+ _SYSDEV_ATTR(ima6, 0600, show_ima6, store_ima6),
+ _SYSDEV_ATTR(ima7, 0600, show_ima7, store_ima7),
+ _SYSDEV_ATTR(ima8, 0600, show_ima8, store_ima8),
+ _SYSDEV_ATTR(ima9, 0600, show_ima9, store_ima9),
+ _SYSDEV_ATTR(imaat, 0600, show_imaat, store_imaat),
+ _SYSDEV_ATTR(btcr, 0600, show_btcr, store_btcr),
+ _SYSDEV_ATTR(pccr, 0600, show_pccr, store_pccr),
+ _SYSDEV_ATTR(rpccr, 0600, show_rpccr, store_rpccr),
+ _SYSDEV_ATTR(der, 0600, show_der, store_der),
+ _SYSDEV_ATTR(mer, 0600, show_mer, store_mer),
+ _SYSDEV_ATTR(ber, 0600, show_ber, store_ber),
+ _SYSDEV_ATTR(ier, 0600, show_ier, store_ier),
+ _SYSDEV_ATTR(sier, 0600, show_sier, store_sier),
+ _SYSDEV_ATTR(siar, 0600, show_siar, store_siar),
+ _SYSDEV_ATTR(tsr0, 0600, show_tsr0, store_tsr0),
+ _SYSDEV_ATTR(tsr1, 0600, show_tsr1, store_tsr1),
+ _SYSDEV_ATTR(tsr2, 0600, show_tsr2, store_tsr2),
+ _SYSDEV_ATTR(tsr3, 0600, show_tsr3, store_tsr3),
+#endif /* CONFIG_DEBUG_KERNEL */
};
diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
index 281011e..347de53 100644
--- a/include/asm-powerpc/reg.h
+++ b/include/asm-powerpc/reg.h
@@ -518,21 +518,47 @@
#define PA6T_MMCR1_ES4 0x0000000000ff0000UL
#define PA6T_MMCR1_ES5 0x00000000ff000000UL
-#define SPRN_PA6T_SIAR 780
-#define SPRN_PA6T_UPMC0 771
-#define SPRN_PA6T_UPMC1 772
+#define SPRN_PA6T_UPMC0 771 /* User PerfMon Counter 0 */
+#define SPRN_PA6T_UPMC1 772 /* ... */
#define SPRN_PA6T_UPMC2 773
#define SPRN_PA6T_UPMC3 774
#define SPRN_PA6T_UPMC4 775
#define SPRN_PA6T_UPMC5 776
-#define SPRN_PA6T_UMMCR0 779
-#define SPRN_PA6T_UMMCR1 782
-#define SPRN_PA6T_PMC0 787
-#define SPRN_PA6T_PMC1 788
-#define SPRN_PA6T_PMC2 789
-#define SPRN_PA6T_PMC3 790
-#define SPRN_PA6T_PMC4 791
-#define SPRN_PA6T_PMC5 792
+#define SPRN_PA6T_UMMCR0 779 /* User Monitor Mode Control Register 0 */
+#define SPRN_PA6T_SIAR 780 /* Sampled Instruction Address */
+#define SPRN_PA6T_UMMCR1 782 /* User Monitor Mode Control Register 1 */
+#define SPRN_PA6T_SIER 785 /* Sampled Instruction Event Register */
+#define SPRN_PA6T_PMC0 787
+#define SPRN_PA6T_PMC1 788
+#define SPRN_PA6T_PMC2 789
+#define SPRN_PA6T_PMC3 790
+#define SPRN_PA6T_PMC4 791
+#define SPRN_PA6T_PMC5 792
+#define SPRN_PA6T_TSR0 793 /* Timestamp Register 0 */
+#define SPRN_PA6T_TSR1 794 /* Timestamp Register 1 */
+#define SPRN_PA6T_TSR2 799 /* Timestamp Register 2 */
+#define SPRN_PA6T_TSR3 784 /* Timestamp Register 3 */
+
+#define SPRN_PA6T_IER 981 /* Icache Error Register */
+#define SPRN_PA6T_DER 982 /* Dcache Error Register */
+#define SPRN_PA6T_BER 862 /* BIU Error Address Register */
+#define SPRN_PA6T_MER 849 /* MMU Error Register */
+
+#define SPRN_PA6T_IMA0 880 /* Instruction Match Array 0 */
+#define SPRN_PA6T_IMA1 881 /* ... */
+#define SPRN_PA6T_IMA2 882
+#define SPRN_PA6T_IMA3 883
+#define SPRN_PA6T_IMA4 884
+#define SPRN_PA6T_IMA5 885
+#define SPRN_PA6T_IMA6 886
+#define SPRN_PA6T_IMA7 887
+#define SPRN_PA6T_IMA8 888
+#define SPRN_PA6T_IMA9 889
+#define SPRN_PA6T_BTCR 978 /* Breakpoint and Tagging Control Register */
+#define SPRN_PA6T_IMAAT 979 /* Instruction Match Array Action Table */
+#define SPRN_PA6T_PCCR 1019 /* Power Counter Control Register */
+#define SPRN_PA6T_RPCCR 1021 /* Retire PC Trace Control Register */
+
#else /* 32-bit */
#define SPRN_MMCR0 952 /* Monitor Mode Control Register 0 */
^ permalink raw reply related
* [POWERPC] pasemi: Add workaround for erratum 5945
From: Olof Johansson @ 2007-09-05 2:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit 3f7a4e905341e46e7b442a9326c3b31229e25209
Author: Olof Johansson <olof@lixom.net>
Date: Mon Sep 3 00:11:49 2007 -0500
[POWERPC] pasemi: Add workaround for erratum 5945
Erratum 5945 causes some of the registers on the PCIe root ports to
not read correctly. Do a small dance to avoid this: Write an unused
register, read the value and write it back. Thankfully this is not in
a hot code path.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index fcfb3df..b6a0ec4 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -51,6 +51,61 @@ static void volatile __iomem *pa_pxp_cfg_addr(struct pci_controller *hose,
return hose->cfg_data + PA_PXP_CFA(bus, devfn, offset);
}
+static inline int is_root_port(int busno, int devfn)
+{
+ return ((busno == 0) && (PCI_FUNC(devfn) < 4) &&
+ ((PCI_SLOT(devfn) == 16) || (PCI_SLOT(devfn) == 17)));
+}
+
+static inline int is_5945_reg(int reg)
+{
+ return (((reg >= 0x18) && (reg < 0x34)) ||
+ ((reg >= 0x158) && (reg < 0x178)));
+}
+
+static int workaround_5945(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 *val)
+{
+ struct pci_controller *hose;
+ void volatile __iomem *addr, *dummy;
+ int byte;
+ u32 tmp;
+
+ if (!is_root_port(bus->number, devfn) || !is_5945_reg(offset))
+ return 0;
+
+ hose = pci_bus_to_host(bus);
+
+ addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset & ~0x3);
+ byte = offset & 0x3;
+
+ /* Workaround bug 5945: write 0 to a dummy register before reading,
+ * and write back what we read. We must read/write the full 32-bit
+ * contents so we need to shift and mask by hand.
+ */
+ dummy = pa_pxp_cfg_addr(hose, bus->number, devfn, 0x10);
+ out_le32(dummy, 0);
+ tmp = in_le32(addr);
+ out_le32(addr, tmp);
+
+ switch (len) {
+ case 1:
+ *val = (tmp >> (8*byte)) & 0xff;
+ break;
+ case 2:
+ if (byte == 0)
+ *val = tmp & 0xffff;
+ else
+ *val = (tmp >> 16) & 0xffff;
+ break;
+ default:
+ *val = tmp;
+ break;
+ }
+
+ return 1;
+}
+
static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 *val)
{
@@ -64,6 +119,9 @@ static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
if (!pa_pxp_offset_valid(bus->number, devfn, offset))
return PCIBIOS_BAD_REGISTER_NUMBER;
+ if (workaround_5945(bus, devfn, offset, len, val))
+ return PCIBIOS_SUCCESSFUL;
+
addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset);
/*
@@ -180,7 +238,7 @@ void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset)
{
struct pci_controller *hose;
- hose = pci_bus_to_host(bus);
+ hose = pci_bus_to_host(dev->bus);
- return pa_pxp_cfg_addr(hose, hose->number, dev->devfn, int offset)
+ return (void __iomem *)pa_pxp_cfg_addr(hose, dev->bus->number, dev->devfn, offset);
}
^ permalink raw reply related
* [POWERPC] pasemi: add pasemi_pci_getcfgaddr()
From: Olof Johansson @ 2007-09-05 2:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit aa37284d64c33d4755072d4bb4b5b1304d415d97
Author: Olof Johansson <olof@lixom.net>
Date: Sat Sep 1 15:43:52 2007 -0500
[POWERPC] pasemi: add pasemi_pci_getcfgaddr()
Add pasemi_pci_getcfgaddr(), to get the remapped address of a specific
config register for a PCI device.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/pasemi.h b/arch/powerpc/platforms/pasemi/pasemi.h
index be84954..6fd2fe7 100644
--- a/arch/powerpc/platforms/pasemi/pasemi.h
+++ b/arch/powerpc/platforms/pasemi/pasemi.h
@@ -6,6 +6,8 @@ extern void pas_pci_init(void);
extern void __devinit pas_pci_irq_fixup(struct pci_dev *dev);
extern void __devinit pas_pci_dma_dev_setup(struct pci_dev *dev);
+extern void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset);
+
extern void __init alloc_iobmap_l2(void);
extern void __init pasemi_idle_init(void);
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index 03d1d07..fcfb3df 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -175,3 +175,12 @@ void __init pas_pci_init(void)
/* Use the common resource allocation mechanism */
pci_probe_only = 1;
}
+
+void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset)
+{
+ struct pci_controller *hose;
+
+ hose = pci_bus_to_host(bus);
+
+ return pa_pxp_cfg_addr(hose, hose->number, dev->devfn, int offset)
+}
^ permalink raw reply related
* Re: [patch 5/6] Walnut board support
From: David Gibson @ 2007-09-05 3:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070831200643.514442000@linux.vnet.ibm.com>
On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> Board support for the PPC405 Walnut evaluation board
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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