* Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug, bisected to 6dda9d55)
From: pacman @ 2010-10-27 8:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1287608215.2198.23.camel@pasglop>
Benjamin Herrenschmidt writes:
>
> Ok so you'll have to make up a "workaround" in prom_init that looks for
> OHCI's in the device-tree and disable them.
>
> Check if the OHCI node has some existing f-code words you can use for
> that with "dev /path-to-ohci words" in OF for example. If not, you may
> need to use the low level register accessors. Use OF client interface
> "interpret" to run forth code from C.
I responded with a long list of reasons that I'm not qualified to do that
work myself:
|Here are the major problems:
|
|1. How do I locate all usb nodes in the device tree?
|
|2. How do I know if a particular usb node is OHCI?
|
|3. Knowing that a node is OHCI, how do I know where its control registers
|are? I'm sure this is calculated from the "reg" property but I don't see how.
|
|4. Knowing where the control registers are, how do I access them? Do I need
|to request a virt-to-phys mapping or can I assume that it's already mapped,
|or that the "rl!" command will do the right thing with a physical address?
|
|5. Which control register should I use to tell the OHCI to be quiet? Just do
|a general reset, or is there something that specifically turns off the
|counter that's been causing the trouble?
Since then, the silence has been deafening.
My assumption now is that this is not ever getting fixed. I'm certainly not
able to fix it. I'm not a even kernel programmer! I got far enough to
diagnose the cause just with the "add more printk's and boot it again"
technique. Hundreds of reboots trying to figure it out. I was a conscientious
bug-reporter, I thought.
I could pull the PCI card and be done with it. I never used those USB ports
anyway. But after all the suffering I went through to find this bug... the
crashing e2fsck's and consequent filesystem corruption... I hate the idea of
surrendering to it. There are possibly other affected users who I'd be
abandoning to suffer similarly in the future.
For the last week I've studied OpenFirmware as hard as I can. I read the spec
cover to cover. And the USB annex, and the PCI annex. But I'm still lost in
all the different address formats.
I took my best guess on how to handle this problem, and ran with it, ending
up with a 97-line Forth script, and that was just to get a virtual address,
not to actually do anything with it, and it used a hardcoded device path. But
it didn't work, all I got was an "invalid pointer" error. I made another
guess at something that wasn't documented anywhere (the fact that this stuff
is insufficiently documented is the one thing I can state with complete
confidence!) and out came a successful translation to a virtual address: 0.
If I'm the only one fighting this bug, the bug wins.
--
Alan Curry
^ permalink raw reply
* Re: Freescale P2020/ 85xx PCIe: DMA low throughtput
From: Natalie Shapira @ 2010-10-27 9:25 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-dev, zw
In-Reply-To: <929D3CED81F34E43887A393170D66FB90355C3CA@GBRSUN01MS002.eu.xerox.net>
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]
Jenkins, Clive wrote:
>> Hi,
>>
>> I'm working on bring up for a new board based on Freescales p2020.
>> I have a programmable FPGA as a PCIe device with a buffer I can
>> write to and from.
>> I want to test performence for the PCIe bus.
>> I encountered a problem while doing a DMA between the FPGA & DDR.
>> The whole buffer moves to and from the device with out
>> mismatches but with low throughtput.
>> The thing is that the buffer divided to many transactions of byte
>> size instead of transferring it in a burst.
>> I must mention that even a buffer of word size, divided in to byte
>> transactions by the DMA (the core can read a word so it seems like
>> the DMA fault.
>> I tried to change the latency timer, max latency, min latency and
>> cache line in the configuration space of both sides of the pcie
>> bus. It didn't help.
>> Do you have an idea what can it be?
>>
>> Thanks,
>> Natalie.
>>
>
> Assuming the P2020 has the usual 85xx-style DMA engine, you may have
> the Band Width Control cleared to 0. This 4-bit field (BWC) restricts
> the transfer size to 2^BWC bytes, for BWC=0,1,..0xa. 0xb-0xe are
> reserved. 0xf disables bandwidth sharing to allow uninterrupted
> transfers from each channel, so if you are using several channels
> one channel can completely lock out other channels. BWC=0x8 at reset
> (2^8 = 256 bytes). See the P2020 manual for more details.
>
> BWC is the field with mask 0x0f000000 in the MR (Master Reset)
> register for the channel (0, 1, 2, 3), at offset 0x100, 0x180, 0x200,
> 0x280 relative to the base of the DMA controller.
>
> Clive
>
>
>
Hi, Thanks.
I changed the BWC but the transactions are still in a byte size instead
of burst.
Do you have another idea?
Natalie.
[-- Attachment #2: Type: text/html, Size: 2126 bytes --]
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug, bisected to 6dda9d55)
From: Olaf Hering @ 2010-10-27 10:13 UTC (permalink / raw)
To: pacman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101027085738.1837.qmail@kosh.dhis.org>
On Wed, Oct 27, pacman@kosh.dhis.org wrote:
> |1. How do I locate all usb nodes in the device tree?
> |
> |2. How do I know if a particular usb node is OHCI?
In the installed system, run 'lspci | grep -i usb', this gives the pci
bus numbers. Then run 'find /sys -name devspec', and look or the bus
numbers from the lspci output. Each devspec file contains the firmware
path. The ohci node may have subdirectories. Run 'words' in each of
them at the firmware prompt. Perhaps there is one to shutdown the
controller?
I just noticed older firmware did not have a node for ohci, newer ones
my have a /pci@80000000/usb@5 node.
Good luck.
Olaf
^ permalink raw reply
* RE: Freescale P2020/ 85xx PCIe: DMA low throughtput
From: Jenkins, Clive @ 2010-10-27 11:28 UTC (permalink / raw)
To: Natalie Shapira; +Cc: linuxppc-dev, zw
In-Reply-To: <4CC7EFFC.10405@extricom.com>
> Hi,=20
> =09
> I'm working on bring up for a new board based on
Freescales p2020.
> I have a programmable FPGA as a PCIe device with a
buffer I can
> write to and from.
> I want to test performence for the PCIe bus.=20
> I encountered a problem while doing a DMA between the
FPGA & DDR.=20
> The whole buffer moves to and from the device with
out
> mismatches but with low throughtput.=20
> The thing is that the buffer divided to many
transactions of byte
> size instead of transferring it in a burst.=20
> I must mention that even a buffer of word size, divided
in to byte
> transactions by the DMA (the core can read a word so it
seems like
> the DMA fault.
> I tried to change the latency timer, max latency, min
latency and
> cache line in the configuration space of both sides of
the pcie
> bus. It didn't help.
> Do you have an idea what can it be?=20
> =09
> Thanks,
> Natalie.=20
> =20
>
>=09
> Assuming the P2020 has the usual 85xx-style DMA engine, you may
have
> the Band Width Control cleared to 0. This 4-bit field (BWC)
restricts
> the transfer size to 2^BWC bytes, for BWC=3D0,1,..0xa. 0xb-0xe are
> reserved. 0xf disables bandwidth sharing to allow uninterrupted
> transfers from each channel, so if you are using several
channels
> one channel can completely lock out other channels. BWC=3D0x8 at
reset
> (2^8 =3D 256 bytes). See the P2020 manual for more details.
>=09
> BWC is the field with mask 0x0f000000 in the MR (Master Reset)
> register for the channel (0, 1, 2, 3), at offset 0x100, 0x180,
0x200,
> 0x280 relative to the base of the DMA controller.
>=09
> Clive
>=09
>=09
> =20
>
> Hi, Thanks.
> I changed the BWC but the transactions are still in a byte size
instead
> of burst. Do you have another idea?
>
> Natalie.
Sorry, no.
Are you sure you have modified the FSL-DMA driver in the kernel so it
does not
write zero to BWC?
Clive
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug, bisected to 6dda9d55)
From: Benjamin Herrenschmidt @ 2010-10-27 13:27 UTC (permalink / raw)
To: pacman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101027085738.1837.qmail@kosh.dhis.org>
> Since then, the silence has been deafening.
>
> My assumption now is that this is not ever getting fixed. I'm certainly not
> able to fix it. I'm not a even kernel programmer! I got far enough to
> diagnose the cause just with the "add more printk's and boot it again"
> technique. Hundreds of reboots trying to figure it out. I was a conscientious
> bug-reporter, I thought.
I'm happy to help you fix it but I'm travelling at the moment and won't
have much time for a couple of weeks.
Cheers,
Ben.
> I could pull the PCI card and be done with it. I never used those USB ports
> anyway. But after all the suffering I went through to find this bug... the
> crashing e2fsck's and consequent filesystem corruption... I hate the idea of
> surrendering to it. There are possibly other affected users who I'd be
> abandoning to suffer similarly in the future.
>
> For the last week I've studied OpenFirmware as hard as I can. I read the spec
> cover to cover. And the USB annex, and the PCI annex. But I'm still lost in
> all the different address formats.
>
> I took my best guess on how to handle this problem, and ran with it, ending
> up with a 97-line Forth script, and that was just to get a virtual address,
> not to actually do anything with it, and it used a hardcoded device path. But
> it didn't work, all I got was an "invalid pointer" error. I made another
> guess at something that wasn't documented anywhere (the fact that this stuff
> is insufficiently documented is the one thing I can state with complete
> confidence!) and out came a successful translation to a virtual address: 0.
>
> If I'm the only one fighting this bug, the bug wins.
>
^ permalink raw reply
* Re: [PATCH] powerpc/5121: pdm360ng: fix touch irq if 8xxx gpio driver is enabled
From: Grant Likely @ 2010-10-27 13:40 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20100925222244.2fad5ff6@wker>
On Sat, Sep 25, 2010 at 10:22:44PM +0200, Anatolij Gustschin wrote:
> On Wed, 15 Sep 2010 20:38:23 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
> > On Wed, Sep 15, 2010 at 10:12:57PM +0200, Anatolij Gustschin wrote:
> > > Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension
> > > breaks touch screen support on this board since the GPIO
> > > interrupt will be mapped to 8xxx GPIO irq host resulting in
> > > a not requestable interrupt in the touch screen driver. Fix
> > > it by mapping the touch interrupt on 8xxx GPIO irq host.
> >
> > This looks wrong to me. The touchscreen code should not go mucking
> > about in the GPIO controller registers; that is the job of the gpio
> > driver.
>
> But if there is no GPIO driver (as it was the case before adding
> mpc512x support in the 8xxx gpio driver) or if the driver is not
> enabled in the kernel configuration? Then the platform specific
> callback (called from touchscreen driver) returns the pin state
> and acknowlegdes the interrupt.
So, basically the touchscreen device node has an interrupts property
which does not use the gpio controller as the interrupt controller,
but instead points directly and the interrupt controller that the gpio
controller is cascaded from.
Really it sounds like the device tree data is broken. The preferred
solution is be to fix the device tree to declare the gpio node as
an interrupt controller.
>
> > What is the reason that the touch interrupt isn't
> > requestable?
>
> The 8xxx gpio driver sets up gpio irq host and installs
> the chained irq handler for GPIO interrupt 78 using
> set_irq_chained_handler() which sets the status field of
> the irq_desc structure to IRQ_NOREQUEST | IRQ_NOPROBE.
> Other drivers can't request this GPIO interrupt any more,
> request_threaded_irq() checks the IRQ_NOREQUEST status
> flag and returns -EINVAL if it is set. The gpio interrupts
> for each gpio pin are now handled by the
> mpc8xxx_gpio_irq_cascade() handler as they should.
>
> > It looks like the 8xxx gpio driver is designed to hand
> > out a separate virq number for each gpio pin (I've not had time to dig
> > into details, so you'll need to educate me on the problem details)
>
> Yes, exactly. This patch adds code to request the
> board's pen_down gpio pin and to use it's virq number in
> the touchscreen driver. The touchscreen driver can
> request this virq interrupt and it is now properly handled
> by the chained handler in the gpio driver.
...but it does so by hard coding the irq number (via the GPIO number)
into the board code; a situation which I've tried very hard to avoid.
This is what I'm not okay with.
Another solution is to modify the 8xxx gpio driver to cascade off the
normal request_irq() path instead of via set_irq_chained_handler(),
but that *might* have unacceptable performance impact for other users.
Unfortunately, I've been slow on this patch, so I cannot get anything
into 2.6.37 (sorry). However, I've not asked Linus to pull the 8xxx
gpio driver changes either so nothing in mainline will get broken.
g.
^ permalink raw reply
* [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
From: Chris Metcalf @ 2010-10-27 16:54 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
The tile architecture uses this framework for our serial console,
and our users complain that the delay of up to two seconds feels like
the machine has gone non-responsive and is disturbing. By contrast,
a delay of up to half a second feels like just the normal sort of
delay caused by swapping, network lag, etc. and is not noticeable.
The overhead is obviously not much greater.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
---
I'm happy to push this via the tile tree if the linuxppc-dev folks
want to give me an acked-by, or you can take it into your tree. Thanks!
drivers/char/hvc_console.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 3afd62e..1df5431 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -565,11 +565,11 @@ static int hvc_chars_in_buffer(struct tty_struct *tty)
* and during console activity we will use a default MIN_TIMEOUT of 10. When
* the console is idle, we increase the timeout value on each pass through
* msleep until we reach the max. This may be noticeable as a brief (average
- * one second) delay on the console before the console responds to input when
+ * 0.25 second) delay on the console before the console responds to input when
* there has been no input for some time.
*/
#define MIN_TIMEOUT (10)
-#define MAX_TIMEOUT (2000)
+#define MAX_TIMEOUT (500)
static u32 timeout = MIN_TIMEOUT;
#define HVC_POLL_READ 0x00000001
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
From: Alan Cox @ 2010-10-27 19:21 UTC (permalink / raw)
To: Chris Metcalf; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <201010271659.o9RGxrMc009847@farm-0002.internal.tilera.com>
On Wed, 27 Oct 2010 12:54:27 -0400
Chris Metcalf <cmetcalf@tilera.com> wrote:
> The tile architecture uses this framework for our serial console,
That may be a mistake unless your console is genuinely only capable of
polled input.
Alan
^ permalink raw reply
* Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
From: Chris Metcalf @ 2010-10-27 19:46 UTC (permalink / raw)
To: Alan Cox; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101027202101.226085c1@lxorguk.ukuu.org.uk>
On 10/27/2010 3:21 PM, Alan Cox wrote:
> On Wed, 27 Oct 2010 12:54:27 -0400 Chris Metcalf <cmetcalf@tilera.com> wrote:
>> The tile architecture uses this framework for our serial console,
> That may be a mistake unless your console is genuinely only capable of
> polled input.
The console is in fact interrupt-driven within the hypervisor, and data is
buffered there. However, the current hypervisor console API is only
"write" and "read". We have a bugzilla to add console interrupts to the
hypervisor API and use them from Linux, but we haven't done it yet.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: pacman @ 2010-10-27 21:04 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101027101351.GA28218@aepfle.de>
Olaf Hering writes:
>
> On Wed, Oct 27, pacman@kosh.dhis.org wrote:
>
> > |1. How do I locate all usb nodes in the device tree?
> > |
> > |2. How do I know if a particular usb node is OHCI?
>
> In the installed system, run 'lspci | grep -i usb', this gives the pci
> bus numbers. Then run 'find /sys -name devspec', and look or the bus
Once the system is running, I have no problem figuring it out. What I meant
was how do I write some code to identify OHCI devices correctly, from within
the limited environment of the Forth interpreter, which will work in the
general case.
I already know that /pci@80000000/usb@5 and /pci@80000000/usb@5,1 are the
problem nodes on my machine. And I've learned enough about OF to do a full
recursive device tree search to find the USB nodes, so the first question is
answered.
But the UHCI and OHCI nodes look very much alike in the OF properties. "name"
is just "usb" and there's no "compatible".
The big question that I'm still stumbling over is how to access the device
registers. The "reg" property looks like this:
phys size
-------------------------- -----------------
00002800 00000000 00000000 00000000 00000000
02002810 00000000 00000000 00000000 00001000
so I take the second group of 5 words, which should be the device registers,
and try to map it to a virtual address. The members are unpacked on the stack
like this:
00000000 00000000 02002810 00000000 00001000
which looks like this stack diagram from OF spec:
map-in ( phys.lo ... phys.hi size -- virt )
and the method call goes like this:
" map-in" $call-parent
The result: "invalid pointer". But I notice it only popped 4 items. I think
maybe the "size" for map-in is not the same as the "size" found in the reg
property. Maybe #size-cells applies in one place but not the other. Thanks
for not documenting that! Try again:
00000000 00000000 02002810 00001000 " map-in" $call-parent
This one doesn't complain, but leaves me a 0 on the stack as its answer. The
OHCI registers have been mapped to virtual address 0? Doesn't seem likely.
--
Alan Curry
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: Segher Boessenkool @ 2010-10-27 22:05 UTC (permalink / raw)
To: pacman; +Cc: Olaf Hering, linuxppc-dev, linux-kernel
In-Reply-To: <20101027210457.23673.qmail@kosh.dhis.org>
>> > |1. How do I locate all usb nodes in the device tree?
>> > |
>> > |2. How do I know if a particular usb node is OHCI?
You look for compatible "usb-ohci".
But this doesn't help you. You do not know yet if the
problem happens for all usb-ohci; for example, it could be
that you have the console output device on usb; or as another
example, it could be that this firmware leaves all pci devices
in some active state.
So as I see it you have only two options:
1) Figure out what exactly is going on;
or 2) make the kernel shut down all pci devices early (either
in actual kernel code, or in an OF boot script).
> The big question that I'm still stumbling over is how to access the device
> registers. The "reg" property looks like this:
You should look at "assigned-addresses", not "reg". Well,
you first need to look at "reg" to figure out what entry
in "assigned-addresses" to use.
Segher
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: pacman @ 2010-10-27 22:58 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olaf Hering, linuxppc-dev, linux-kernel
In-Reply-To: <50654.84.105.60.153.1288217125.squirrel@gate.crashing.org>
Segher Boessenkool writes:
>
> >> > |1. How do I locate all usb nodes in the device tree?
> >> > |
> >> > |2. How do I know if a particular usb node is OHCI?
>
> You look for compatible "usb-ohci".
There is no "compatible" there. I can probably use class-code since the
parent is a PCI bus.
>
> But this doesn't help you. You do not know yet if the
> problem happens for all usb-ohci; for example, it could be
> that you have the console output device on usb; or as another
> example, it could be that this firmware leaves all pci devices
> in some active state.
>
> So as I see it you have only two options:
>
> 1) Figure out what exactly is going on;
I thought we were past that. The startup sequence leaves the device in a bad
state (writing 1000 times per second to memory that the kernel believes is
not in use), so it needs to be given a reset command before the kernel tries
to use that memory.
> > The big question that I'm still stumbling over is how to access the device
> > registers. The "reg" property looks like this:
>
> You should look at "assigned-addresses", not "reg". Well,
> you first need to look at "reg" to figure out what entry
> in "assigned-addresses" to use.
The properties look like this:
/pci@80000000/usb@5/assigned-addresses
02002810 00000000 80000000 00000000 00001000
/pci@80000000/usb@5/reg
00002800 00000000 00000000 00000000 00000000
02002810 00000000 00000000 00000000 00001000
I'm not sure how I'm supposed to know which entry from "reg" is the right
one. I've been guessing that it's the second one, since that one matches the
only entry in "assigned-addresses". It's supposed to go the other direction?
--
Alan Curry
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: Segher Boessenkool @ 2010-10-27 23:33 UTC (permalink / raw)
To: pacman; +Cc: Olaf Hering, linuxppc-dev, linux-kernel
In-Reply-To: <20101027225855.25345.qmail@kosh.dhis.org>
>> 1) Figure out what exactly is going on;
>
> I thought we were past that.
We are not.
> The startup sequence leaves the device in a
> bad
> state (writing 1000 times per second to memory that the kernel believes is
> not in use), so it needs to be given a reset command before the kernel
> tries
> to use that memory.
The question now is what causes the firmware to do that, and then
what is the best way to stop it from doing that.
>> > The big question that I'm still stumbling over is how to access the
>> device
>> > registers. The "reg" property looks like this:
>>
>> You should look at "assigned-addresses", not "reg". Well,
>> you first need to look at "reg" to figure out what entry
>> in "assigned-addresses" to use.
Ignore this part, I was confused.
> The properties look like this:
>
> /pci@80000000/usb@5/assigned-addresses
> 02002810 00000000 80000000 00000000 00001000
Lovely, incorrect data (it should start with 82002810, i.e.,
not relocatable -- it is already an assigned address!).
This means: 32-bit MMIO address space for bus 0 dev 5 fn 0,
first BAR; assigned to address 80000000; size is 1000.
You could try a boot script like this:
dev /pci
0 ffff04 DO 0 i config-w! -100 +LOOP
device-end
which should disable all PCI devices on all busses, on that
PCI host bus (it disables every device behind pci-pci bridges
separately, as long as every such bridge has a higher secondary
bus number than primary bus number; if you only want to disable
everything on the root bus (which should be sufficient), use
ff04 instead of ffff04).
Segher
^ permalink raw reply
* Re: [REPOST] [PATCH 0/6] fixes and MPC8308 support for the mpc512x_dma driver
From: Ilya Yanok @ 2010-10-28 0:44 UTC (permalink / raw)
To: Piotr Zięcik; +Cc: vlad, linuxppc-dev, wd, dzu
In-Reply-To: <201010270924.28854.kosmo@semihalf.com>
Hi Piotr,
On 27.10.2010 11:24, Piotr Zięcik wrote:
> Currently I am not able to deal with this as I am much involved in
> other development.
I see. Excuse me for disturbing you then.
Guys, anybody can review/test/pull these patches?
Regards, Ilya.
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: pacman @ 2010-10-28 1:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <50748.84.105.60.153.1288222432.squirrel@gate.crashing.org>
Segher Boessenkool writes:
>
> >> 1) Figure out what exactly is going on;
> >
> > I thought we were past that.
>
> We are not.
>
> > The startup sequence leaves the device in a
> > bad
> > state (writing 1000 times per second to memory that the kernel believes is
> > not in use), so it needs to be given a reset command before the kernel
> > tries
> > to use that memory.
>
> The question now is what causes the firmware to do that, and then
> what is the best way to stop it from doing that.
As far as I can tell, it turns on the host controller during the global
probe, which is not wrong because USB devices could theoretically be used for
booting, or for console display. Then it never turns off the host controller
because someone forgot to put in the code to turn it off.
It's not easy to figure out exactly where that should have been done. Turning
off the host controller too soon would rule out booting from USB, but leaving
it running while the OS is starting up has caused a major problem.
So is it wrong to leave the host controller enabled when the OS is booted? If
not, then the error must be in the communication of which memory addresses
are in use by OF. I've got a node /memory@0 whose "available" property looks
like this:
00000000 00400000
00584000 0007c000
0092a1d8 00004e28
00a2f000 005d1000
01800000 0e3fd000
0fbffab4 0000054c
>From that list, it looks to me like OF is telling the kernel that it should
not attempt to use any address above 0xfbffab4+0x54c == 0xfc00000. The
addresses being written to by the OHCI controller are 0xfc5c080 and
0xfc61080. If the kernel is staying within the "available" list, there won't
be a problem.
Later, when the kernel decides it's done using OF, what's supposed to happen?
It closes stdin, but that doesn't help here since the offending device is a
bus node, not an input node. It looks to me like the kernel makes the
assumption that all devices other than stdin and stdout will have been
deactivated already when the kernel starts, and that this assumption has
been violated. Who is wrong, from the perspective of the OF standard, the
assumer or the violator?
Then there's the "quiesce" call, which I don't understand at all since it's
not mentioned in any of the specification documents I've been able to find.
It's been mentioned as an Apple-only thing. Seems like it would be a good
name for a "make all the devices stop puking on the RAM" function. Since the
OF spec doesn't include this function, they must not have thought it was
necessary.
> > /pci@80000000/usb@5/assigned-addresses
> > 02002810 00000000 80000000 00000000 00001000
>
> Lovely, incorrect data (it should start with 82002810, i.e.,
> not relocatable -- it is already an assigned address!).
Now you see how I have trouble relating the docs to the reality...
>
> This means: 32-bit MMIO address space for bus 0 dev 5 fn 0,
> first BAR; assigned to address 80000000; size is 1000.
But "address 80000000" is a physical address (I think), so do I need to do a
map-in on it before using it?
>
> You could try a boot script like this:
>
>
> dev /pci
> 0 ffff04 DO 0 i config-w! -100 +LOOP
> device-end
>
>
> which should disable all PCI devices on all busses, on that
Almost all of my devices are under that PCI node. What will I prove by
disabling them?
--
Alan Curry
^ permalink raw reply
* RapidIO: MC Exception when enumerating peer to peer connection
From: Thomas Taranowski @ 2010-10-28 1:24 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm trying to bring up a RapidIO on my p2020 on v2.6.36-rc7. I'm
running into an issue when the host tries to enumerate the agent
devices, and fails miserably. The rio driver does a
fsl_rio_config_read with a destid of 255, after which it hangs, until
I get a timeout exception (Handled now, thanks!). The port connection
get's trained, and everything looks good, but I get no response. Any
ideas on what to look at to debug this?
Also, after the timeout, the driver seems to hang after that,
presumably because the port is in an error-stop state, because when I
use my trusty jtag to issue a Port Link Maintenance Request and
request status, I get back unrecoverable ackID error for port 1, and
error-stopped port_status for port 2.
0_ffec0140 : 00000004 80000050 02000202 00000000 .......P........
0_ffec0150 : 00000000 00000000 00120002 42600001 ............B`..
0_ffec0160 : 00000004 00000005 00000000 00000000 ................
Reference information below:
U-Boot LAW configuration:
========================
Local Access Window Configuration
LAWBAR1 : 0x000a0000, LAWAR1 : 0x80c00017 /* SRIO Port 1 */
LAWBAR2 : 0x000a1000, LAWAR2 : 0x80d00017 /8 SRIO Port 2 */
Excerpt from linux boot:
====================
Setting up RapidIO peer-to-peer network /rapidio@ffec0000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~ fsl_rio_setup ~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
of:fsl-of-rio ffec0000.rapidio: Of-device full name /rapidio@ffec0000
of:fsl-of-rio ffec0000.rapidio: Regs: [mem 0xffec0000-0xffedffff]
of:fsl-of-rio ffec0000.rapidio: LAW start 0x00000000a0000000,
size 0x0000000001000000.
of:fsl-of-rio ffec0000.rapidio: pwirq: 48, bellirq: 50, txirq: 53, rxirq 54
of:fsl-of-rio ffec0000.rapidio: Overriding RIO_PORT setting to single lane 0
of:fsl-of-rio ffec0000.rapidio: RapidIO PHY type: serial
of:fsl-of-rio ffec0000.rapidio: Hardware port width: 4
of:fsl-of-rio ffec0000.rapidio: Training connection status: Single-lane 0
of:fsl-of-rio ffec0000.rapidio: RapidIO Common Transport System size: 256
EIPWQBAR: 0x00000000 IPWQBAR: 0x1f107000
IPWMR: 0x00100120 IPWSR: 0x00000000
RIO: enumerate master port 0, RIO0 mport
rio_enum_host: port `RIO0 mport`
fsl_local_config_write: index 0 offset 00000068 data 00000000
fsl_local_config_read: index 0 offset 00000068
fsl_local_config_write: index 0 offset 00000060 data 00000000
master port device id set to 0 (next=0)
fsl_local_config_read: index 0 offset 0000000c
fsl_local_config_read: index 0 offset 00000100
fsl_local_config_read: index 0 offset 00000158
RIO: Rio network device created
rio_enable_rx_tx_port(local = 1, destid = 0, hopcount = 0, port_num = 0)
fsl_local_config_read: index 0 offset 0000000c
fsl_local_config_read: index 0 offset 00000100
fsl_local_config_read: index 0 offset 0000015c
fsl_local_config_write: index 0 offset 0000015c data 42600001
Enumerating rionet.
RIO: acquiring device lock...
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4
RIO: fsl_rio_mcheck_exception - MC Exception handled. reason=0x80000000
RIO: cfg_read error -14 for ff:0:68
RIO_LTLEDCSR = 0x0
Thanks!
^ permalink raw reply
* [PATCH] Add Freescale CodeWarrior debug support for kernel
From: Roy Zang @ 2010-10-28 8:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: adrian.bogdan
CodeWarrior is popular embedded tools to support debugging Powerpc.
This patch adds Freescale CodeWarrior debug support for Linux kernel on
85xx/QorIQ platform.
Signed-off-by: Bogdan Adrin <drian.bogdan@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/Kconfig.debug | 8 ++++++++
arch/powerpc/Makefile | 5 +++++
arch/powerpc/include/asm/reg_booke.h | 4 ++++
arch/powerpc/kernel/fsl_booke_entry_mapping.S | 3 +++
arch/powerpc/kernel/head_fsl_booke.S | 11 +++++++++--
arch/powerpc/kernel/idle.c | 5 ++++-
6 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2d38a50..eedd2ac 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -153,6 +153,14 @@ config BDI_SWITCH
Unless you are intending to debug the kernel with one of these
machines, say N here.
+config DEBUG_CODEWARRIOR
+ bool "Include CodeWarrior kernel debugging"
+ depends on DEBUG_KERNEL && PPC32
+ help
+ Say Y here to include CodeWarrior kernel debugging option
+ Unless you are intending to debug the kernel with one of these
+ machines, say N here.
+
config BOOTX_TEXT
bool "Support for early boot text console (BootX or OpenFirmware only)"
depends on PPC_OF && PPC_BOOK3S
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b7212b6..d3050e6 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -121,6 +121,11 @@ KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
# often slow when they are implemented at all
KBUILD_CFLAGS += -mno-string
+ifeq ($(CONFIG_DEBUG_CODEWARRIOR),y)
+CFLAGS += -g2 -gdwarf-2
+AFLAGS_KERNEL += -Wa,-gdwarf2
+endif
+
ifeq ($(CONFIG_6xx),y)
KBUILD_CFLAGS += -mcpu=powerpc
endif
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 667a498..ac65fcd 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -35,7 +35,11 @@
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE)
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
#else
+#if defined(CONFIG_DEBUG_CODEWARRIOR)
+#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)
+#else
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE)
+#endif
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
#endif
diff --git a/arch/powerpc/kernel/fsl_booke_entry_mapping.S b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
index a92c79b..9102aa7 100644
--- a/arch/powerpc/kernel/fsl_booke_entry_mapping.S
+++ b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
@@ -116,6 +116,9 @@ skpinv: addi r6,r6,1 /* Increment */
xori r6,r4,1
slwi r6,r6,5 /* setup new context with other address space */
+#if defined(CONFIG_DEBUG_CODEWARRIOR)
+ ori r6, r6, 0x200 /* enable DE bit for MSR */
+#endif
bl 1f /* Find our address */
1: mflr r9
rlwimi r7,r9,0,20,31
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 529b817..9962d09 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -21,7 +21,7 @@
* debbie_chu@mvista.com
* Copyright 2002-2004 MontaVista Software, Inc.
* PowerPC 44x support, Matt Porter <mporter@kernel.crashing.org>
- * Copyright 2004 Freescale Semiconductor, Inc
+ * Copyright 2004,2010 Freescale Semiconductor, Inc
* PowerPC e500 modifications, Kumar Gala <galak@kernel.crashing.org>
*
* This program is free software; you can redistribute it and/or modify it
@@ -135,7 +135,7 @@ _ENTRY(__early_start)
mtspr SPRN_HID0, r2
#endif
-#if !defined(CONFIG_BDI_SWITCH)
+#if !defined(CONFIG_BDI_SWITCH) && !defined(CONFIG_DEBUG_CODEWARRIOR)
/*
* The Abatron BDI JTAG debugger does not tolerate others
* mucking with the debug registers.
@@ -197,6 +197,13 @@ _ENTRY(__early_start)
/*
* Decide what sort of machine this is and initialize the MMU.
*/
+#if defined(CONFIG_DEBUG_CODEWARRIOR)
+ lis r10, 0x1008 /* clear the V bit from the L2MMU_CAM8 register */
+ mtspr SPRN_MAS0, r10
+ lis r10, 0x0
+ mtspr SPRN_MAS1, r10
+ tlbwe
+#endif
mr r3,r31
mr r4,r30
mr r5,r29
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 39a2baa..83fb019 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -73,8 +73,11 @@ void cpu_idle(void)
stop_critical_timings();
/* check again after disabling irqs */
- if (!need_resched() && !cpu_should_die())
+ if (!need_resched() && !cpu_should_die()) {
+#if !defined(CONFIG_DEBUG_CODEWARRIOR)
ppc_md.power_save();
+#endif
+ }
start_critical_timings();
--
1.5.6.5
^ permalink raw reply related
* mpc52xx_gpt breaks on linux-2.6.26
From: nello martuscielli @ 2010-10-28 15:18 UTC (permalink / raw)
To: linuxppc-dev
If i try to enable watchdog it breaks linux kernel build when enabled.
I'm using an Efika MPC5200B with CRUX PPC 2.6 32bit.
CONFIG_WATCHDOG=y
CONFIG_MPC5200_WDT=y
That's compiling linux-2.6.36:
[..]
LD arch/powerpc/lib/built-in.o
CC arch/powerpc/sysdev/simple_gpio.o
CC arch/powerpc/sysdev/bestcomm/ata.o
CC arch/powerpc/sysdev/bestcomm/bcom_ata_task.o
CC arch/powerpc/sysdev/bestcomm/bestcomm.o
CC arch/powerpc/sysdev/bestcomm/sram.o
LD arch/powerpc/sysdev/bestcomm/bestcomm-core.o
LD arch/powerpc/sysdev/bestcomm/bestcomm-ata.o
LD arch/powerpc/sysdev/bestcomm/built-in.o
CC [M] arch/powerpc/sysdev/bestcomm/fec.o
CC [M] arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.o
CC [M] arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.o
CC [M] arch/powerpc/sysdev/bestcomm/gen_bd.o
CC [M] arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.o
CC [M] arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.o
LD [M] arch/powerpc/sysdev/bestcomm/bestcomm-fec.o
LD [M] arch/powerpc/sysdev/bestcomm/bestcomm-gen-bd.o
CC arch/powerpc/sysdev/mpc5xxx_clocks.o
AS arch/powerpc/sysdev/6xx-suspend.o
LD arch/powerpc/sysdev/built-in.o
CC arch/powerpc/platforms/52xx/mpc52xx_pic.o
CC arch/powerpc/platforms/52xx/mpc52xx_common.o
CC arch/powerpc/platforms/52xx/mpc52xx_gpt.o
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_write':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_ioctl':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:562: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_open':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:635: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit
declaration of function 'nonseekable_open'
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_release':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:643: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: At top level:
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable
'mpc52xx_wdt_fops' has initializer but incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field
'owner' specified in initializer
cc1: warnings being treated as errors
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: unknown field
'llseek' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: 'no_llseek'
undeclared here (not in a function)
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:660: error: unknown field
'write' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:660: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:660: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:661: error: unknown field
'unlocked_ioctl' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:661: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:661: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:662: error: unknown field
'open' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:662: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:662: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:663: error: unknown field
'release' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:663: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:663: error: (near
initialization for 'mpc52xx_wdt_fops')
make[2]: *** [arch/powerpc/platforms/52xx/mpc52xx_gpt.o] Error 1
make[1]: *** [arch/powerpc/platforms/52xx] Error 2
make: *** [arch/powerpc/platforms] Error 2
thanks for any advice.
Nello Martuscielli
^ permalink raw reply
* mpc52xx_gpt breaks on linux-2.6.26
From: nello martuscielli @ 2010-10-28 16:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTikf=ztL+wL7WvaUW4-4uvfeJUUaqMJWqdjwSzQK@mail.gmail.com>
If i try to enable watchdog =A0it breaks linux kernel build when enabled.
I'm using an Efika MPC5200B with CRUX PPC 2.6 32bit.
CONFIG_WATCHDOG=3Dy
CONFIG_MPC5200_WDT=3Dy
That's compiling linux-2.6.36:
[..]
=A0LD =A0 =A0 =A0arch/powerpc/lib/built-in.o
=A0CC =A0 =A0 =A0arch/powerpc/sysdev/simple_gpio.o
=A0CC =A0 =A0 =A0arch/powerpc/sysdev/bestcomm/ata.o
=A0CC =A0 =A0 =A0arch/powerpc/sysdev/bestcomm/bcom_ata_task.o
=A0CC =A0 =A0 =A0arch/powerpc/sysdev/bestcomm/bestcomm.o
=A0CC =A0 =A0 =A0arch/powerpc/sysdev/bestcomm/sram.o
=A0LD =A0 =A0 =A0arch/powerpc/sysdev/bestcomm/bestcomm-core.o
=A0LD =A0 =A0 =A0arch/powerpc/sysdev/bestcomm/bestcomm-ata.o
=A0LD =A0 =A0 =A0arch/powerpc/sysdev/bestcomm/built-in.o
=A0CC [M] =A0arch/powerpc/sysdev/bestcomm/fec.o
=A0CC [M] =A0arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.o
=A0CC [M] =A0arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.o
=A0CC [M] =A0arch/powerpc/sysdev/bestcomm/gen_bd.o
=A0CC [M] =A0arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.o
=A0CC [M] =A0arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.o
=A0LD [M] =A0arch/powerpc/sysdev/bestcomm/bestcomm-fec.o
=A0LD [M] =A0arch/powerpc/sysdev/bestcomm/bestcomm-gen-bd.o
=A0CC =A0 =A0 =A0arch/powerpc/sysdev/mpc5xxx_clocks.o
=A0AS =A0 =A0 =A0arch/powerpc/sysdev/6xx-suspend.o
=A0LD =A0 =A0 =A0arch/powerpc/sysdev/built-in.o
=A0CC =A0 =A0 =A0arch/powerpc/platforms/52xx/mpc52xx_pic.o
=A0CC =A0 =A0 =A0arch/powerpc/platforms/52xx/mpc52xx_common.o
=A0CC =A0 =A0 =A0arch/powerpc/platforms/52xx/mpc52xx_gpt.o
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_write':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_ioctl':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:562: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_open':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:635: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit
declaration of function 'nonseekable_open'
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_wdt_release=
':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:643: error: dereferencing
pointer to incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: At top level:
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable
'mpc52xx_wdt_fops' has initializer but incomplete type
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field
'owner' specified in initializer
cc1: warnings being treated as errors
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: unknown field
'llseek' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: 'no_llseek'
undeclared here (not in a function)
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:659: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:660: error: unknown field
'write' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:660: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:660: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:661: error: unknown field
'unlocked_ioctl' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:661: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:661: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:662: error: unknown field
'open' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:662: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:662: error: (near
initialization for 'mpc52xx_wdt_fops')
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:663: error: unknown field
'release' specified in initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:663: error: excess elements
in struct initializer
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:663: error: (near
initialization for 'mpc52xx_wdt_fops')
make[2]: *** [arch/powerpc/platforms/52xx/mpc52xx_gpt.o] Error 1
make[1]: *** [arch/powerpc/platforms/52xx] Error 2
make: *** [arch/powerpc/platforms] Error 2
thanks for any advice.
Nello Martuscielli
^ permalink raw reply
* Re: PowerMac G5 config
From: kevin diggs @ 2010-10-28 19:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTinaYPUwX+YOJh1pCKmSWS_JmG8+eHQ3QvJgG3KA@mail.gmail.com>
Hi,
Apparently, for some reason, you can't use -depth in your find
command when rebuilding your initrd???
Machine is now running 2.6.36. Glad to be rid of that awful cpufreq driver ...
kevin
On Mon, Oct 25, 2010 at 1:45 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> I have a G5 (dual 970FX, june 2004?) running YDL 6.0. After fighting
> to get a compiler that will build 2.6.29+ (4.2.1 -> 4.2.2) I can't get
> it to boot. It spits out a bunch of message about devices (I think the
> last ones are USB related) and then says:
>
> Restarting System
>
> and then reboots. I've attached a diff of the 2.6.28 config that will boot.
>
> Any suggestions would be greatly appreciated. Thanks!
>
> kevin
>
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: Segher Boessenkool @ 2010-10-28 19:50 UTC (permalink / raw)
To: pacman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101028011147.26254.qmail@kosh.dhis.org>
> So is it wrong to leave the host controller enabled when the OS is booted?
Yes. Or, rather, there should be some way for the client to turn off
all dma and interrupt activity; if the client closes the ihandles in
"/chosen", and perhaps calls "quiesce", that should be enough.
> If
> not, then the error must be in the communication of which memory addresses
> are in use by OF. I've got a node /memory@0 whose "available" property
> looks
> like this:
> 00000000 00400000
> 00584000 0007c000
> 0092a1d8 00004e28
> 00a2f000 005d1000
> 01800000 0e3fd000
> 0fbffab4 0000054c
>>From that list, it looks to me like OF is telling the kernel that it
>> should
> not attempt to use any address above 0xfbffab4+0x54c == 0xfc00000.
The client is allowed to "take over" all memory, if it doesn't call OF
after doing so. This won't work if some device scribbles on it, as
you have seen.
> Later, when the kernel decides it's done using OF, what's supposed to
> happen?
> It closes stdin, but that doesn't help here since the offending device is
> a
> bus node, not an input node. It looks to me like the kernel makes the
> assumption that all devices other than stdin and stdout will have been
> deactivated already when the kernel starts, and that this assumption has
> been violated. Who is wrong, from the perspective of the OF standard, the
> assumer or the violator?
The violator.
>> Lovely, incorrect data (it should start with 82002810, i.e.,
>> not relocatable -- it is already an assigned address!).
>
> Now you see how I have trouble relating the docs to the reality...
Yeah :-(
>> This means: 32-bit MMIO address space for bus 0 dev 5 fn 0,
>> first BAR; assigned to address 80000000; size is 1000.
>
> But "address 80000000" is a physical address (I think), so do I need to do
> a
> map-in on it before using it?
Yes.
>> You could try a boot script like this:
>>
>>
>> dev /pci
>> 0 ffff04 DO 0 i config-w! -100 +LOOP
>> device-end
>>
>>
>> which should disable all PCI devices on all busses, on that
>
> Almost all of my devices are under that PCI node. What will I prove by
> disabling them?
You should put it after "load", and before "go".
It should give you a working system; it's a sledgehammer workaround.
Segher
^ permalink raw reply
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: pacman @ 2010-10-28 21:07 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <52441.84.105.60.153.1288295412.squirrel@gate.crashing.org>
Segher Boessenkool writes:
>
> > So is it wrong to leave the host controller enabled when the OS is booted?
>
> Yes. Or, rather, there should be some way for the client to turn off
> all dma and interrupt activity; if the client closes the ihandles in
> "/chosen", and perhaps calls "quiesce", that should be enough.
Sounds good to me, I only wish someone had written down what "quiesce" means.
> >
> > Almost all of my devices are under that PCI node. What will I prove by
> > disabling them?
>
> You should put it after "load", and before "go".
>
> It should give you a working system; it's a sledgehammer workaround.
I can do it a little more gracefully than that. This works to deactivate the
problem devices manually:
1 lbflip 80000000 8 + rl!
1 lbflip 80001000 8 + rl!
where 80000000 and 80001000 have been obtained from
/pci@80000000/usb@5/assigned-addresses and
/pci@80000000/usb@5,1/assigned-addresses; 8 is the offset of the
HcCommandStatus register; and the 1 bit is HostControllerReset (HCR).
Now I'm just trying to find the more correct way of doing it, without
hardcoded addresses. That'll be something like this:
search the device tree for OHCI nodes
for each OHCI node
get assigned-addresses
map-in
set HCR
wait for acknowledgement
map-out
which can be done any time before the quiesce call, since that marks the
point where the kernel assumes that there are no devices writing to memory.
Sound good?
--
Alan Curry
^ permalink raw reply
* [PATHC v1] PPC4xx: Adding PCI(E) MSI support
From: tmarri @ 2010-10-28 22:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmarri
From: Tirumala Marri <tmarri@apm.com>
This patch adds MSI support for 440SPe, 460Ex, 460Sx and 405Ex.
Signed-off-by: Tirumala R Marri <tmarri@apm.com>
---
v1:
* Get rid of bitmap functions.
* Remove irq mapping as each MSI is tied to UIC.
* Cleaning up of prints.
---
arch/powerpc/boot/dts/canyonlands.dts | 18 +++
arch/powerpc/boot/dts/katmai.dts | 18 +++
arch/powerpc/boot/dts/kilauea.dts | 28 ++++
arch/powerpc/boot/dts/redwood.dts | 20 +++
arch/powerpc/platforms/40x/Kconfig | 2 +
arch/powerpc/platforms/44x/Kconfig | 6 +
arch/powerpc/sysdev/Kconfig | 6 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_msi.c | 251 +++++++++++++++++++++++++++++++++
9 files changed, 350 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..5a8e04e 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -519,5 +519,23 @@
0x0 0x0 0x0 0x3 &UIC3 0x12 0x4 /* swizzled int C */
0x0 0x0 0x0 0x4 &UIC3 0x13 0x4 /* swizzled int D */>;
};
+
+ MSI: ppc4xx-msi@C10000000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0xC 0x10000000 0x100>;
+ sdr-base = <0x36C>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <3>;
+ interrupts = <0 1 2 3>;
+ interrupt-parent = <&UIC3>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC3 0x18 1
+ 1 &UIC3 0x19 1
+ 2 &UIC3 0x1A 1
+ 3 &UIC3 0x1B 1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 7c3be5e..f913dbe 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -442,6 +442,24 @@
0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /* swizzled int D */>;
};
+ MSI: ppc4xx-msi@400300000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x4 0x00300000 0x100>;
+ sdr-base = <0x3B0>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <3>;
+ interrupts =<0 1 2 3>;
+ interrupt-parent = <&UIC0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC0 0xC 1
+ 1 &UIC0 0x0D 1
+ 2 &UIC0 0x0E 1
+ 3 &UIC0 0x0F 1>;
+ };
+
I2O: i2o@400100000 {
compatible = "ibm,i2o-440spe";
reg = <0x00000004 0x00100000 0x100>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 083e68e..21e88f5 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -394,5 +394,33 @@
0x0 0x0 0x0 0x3 &UIC2 0xd 0x4 /* swizzled int C */
0x0 0x0 0x0 0x4 &UIC2 0xe 0x4 /* swizzled int D */>;
};
+
+ MSI: ppc4xx-msi@C10000000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x0 0xEF620000 0x100>;
+ sdr-base = <0x4B0>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <12>;
+ interrupts = <0 1 2 3 4 5 6 7 8 9 0xA 0xB 0xC 0xD>;
+ interrupt-parent = <&UIC2>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC2 0x10 1
+ 1 &UIC2 0x11 1
+ 2 &UIC2 0x12 1
+ 2 &UIC2 0x13 1
+ 2 &UIC2 0x14 1
+ 2 &UIC2 0x15 1
+ 2 &UIC2 0x16 1
+ 2 &UIC2 0x17 1
+ 2 &UIC2 0x18 1
+ 2 &UIC2 0x19 1
+ 2 &UIC2 0x1A 1
+ 2 &UIC2 0x1B 1
+ 2 &UIC2 0x1C 1
+ 3 &UIC2 0x1D 1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/redwood.dts b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..d86a3a4 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -358,8 +358,28 @@
0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /* swizzled int D */>;
};
+ MSI: ppc4xx-msi@400300000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x4 0x00300000 0x100
+ 0x4 0x00300000 0x100>;
+ sdr-base = <0x3B0>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <3>;
+ interrupts =<0 1 2 3>;
+ interrupt-parent = <&UIC0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC0 0xC 1
+ 1 &UIC0 0x0D 1
+ 2 &UIC0 0x0E 1
+ 3 &UIC0 0x0F 1>;
+ };
+
};
+
chosen {
linux,stdout-path = "/plb/opb/serial@ef600200";
};
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index b721764..92aeee6 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -57,6 +57,8 @@ config KILAUEA
select 405EX
select PPC40x_SIMPLE
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
help
This option enables support for the AMCC PPC405EX evaluation board.
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0f979c5..3836353 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -74,6 +74,8 @@ config KATMAI
select 440SPe
select PCI
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
help
This option enables support for the AMCC PPC440SPe evaluation board.
@@ -119,6 +121,8 @@ config CANYONLANDS
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII
help
@@ -145,6 +149,8 @@ config REDWOOD
select 460SX
select PCI
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
help
This option enables support for the AMCC PPC460SX Redwood board.
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..ec86000 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,6 +7,12 @@ config PPC4xx_PCI_EXPRESS
depends on PCI && 4xx
default n
+config 4xx_MSI
+ bool
+ depends on PCI_MSI
+ depends on PCI && 4xx
+ default n
+
config PPC_MSI_BITMAP
bool
depends on PCI_MSI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 0bef9da..30f4da4 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_XILINX_PCI) += xilinx_pci.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
+obj-$(CONFIG_4xx_MSI) += ppc4xx_msi.o
endif
obj-$(CONFIG_PPC4xx_GPIO) += ppc4xx_gpio.o
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
new file mode 100644
index 0000000..9d5e0c9
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -0,0 +1,251 @@
+/*
+ * Adding PCI-E MSI support for PPC4XX SoCs.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Authors: Tirumala R Marri <tmarri@apm.com>
+ * Feng Kan <fkan@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <linux/irq.h>
+#include <linux/bootmem.h>
+#include <linux/pci.h>
+#include <linux/msi.h>
+#include <linux/of_platform.h>
+#include <linux/interrupt.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include <boot/dcr.h>
+#include <asm/dcr-regs.h>
+#include <asm/msi_bitmap.h>
+
+#define PEIH_TERMADH 0x00
+#define PEIH_TERMADL 0x08
+#define PEIH_MSIED 0x10
+#define PEIH_MSIMK 0x18
+#define PEIH_MSIASS 0x20
+#define PEIH_FLUSH0 0x30
+#define PEIH_FLUSH1 0x38
+#define PEIH_CNTRST 0x48
+
+#define UPPER_4BITS_OF36BIT 32
+#define LOWER_32BITS_OF36BIT 0xFFFFFFFF
+
+struct ppc4xx_msi {
+ u32 msi_addr_lo;
+ u32 msi_addr_hi;
+ void __iomem *msi_regs;
+ u32 feature;
+};
+
+static struct ppc4xx_msi *ppc4xx_msi;
+struct ppc4xx_msi_feature {
+ u32 ppc4xx_pic_ip;
+ u32 msiir_offset;
+};
+
+static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ struct msi_desc *entry;
+ unsigned int virq = 0;
+ struct msi_msg msg;
+ struct ppc4xx_msi *msi_data = ppc4xx_msi;
+ static int int_no = 0; /* To remember last used interrupt */
+ struct device_node *msi_dev = NULL;
+ const u32 *count;
+
+ msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
+ if (msi_dev)
+ return -ENODEV;
+
+ count = of_get_property(msi_dev, "interrupt-count", NULL);
+ if (!count) {
+ dev_err(&dev->dev, "no interrupts property found \n");
+ return -ENODEV;
+ }
+
+ if (int_no > *count)
+ return -EINVAL;
+
+ list_for_each_entry(entry, &dev->msi_list, list) {
+ virq = irq_of_parse_and_map(msi_dev, int_no);
+ printk("virq = 0x%x\n", virq);
+ if (virq == NO_IRQ) {
+ dev_err(&dev->dev, "%s: fail mapping irq\n", __func__);
+ return -EINVAL;
+ } else
+ set_irq_data(virq, (void *)int_no);
+
+ dev_dbg(&dev->dev, "%s: virq = %d \n", __func__, virq);
+
+ /* Setup msi address space */
+ msg.address_hi = msi_data->msi_addr_hi;
+ msg.address_lo = msi_data->msi_addr_lo;
+
+ set_irq_msi(virq, entry);
+ msg.data = int_no;
+ int_no++;
+ write_msi_msg(virq, &msg);
+ }
+
+ return 0;
+}
+
+void ppc4xx_teardown_msi_irqs(struct pci_dev *dev)
+{
+ struct msi_desc *entry;
+
+ dev_dbg(&dev->dev, "PCIE-MSI: tearing down msi irqs\n");
+
+ list_for_each_entry(entry, &dev->msi_list, list) {
+ if (entry->irq == NO_IRQ)
+ continue;
+ set_irq_msi(entry->irq, NULL);
+ irq_dispose_mapping(entry->irq);
+ }
+
+ return;
+}
+
+static int ppc4xx_msi_check_device(struct pci_dev *pdev, int nvec, int type)
+{
+ dev_dbg(&pdev->dev, "PCIE-MSI:%s called. vec %x type %d\n",
+ __func__, nvec, type);
+ return 0;
+}
+
+static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
+ struct resource res, struct ppc4xx_msi *msi)
+{
+ const u32 *msi_data;
+ const u32 *msi_mask;
+ const u32 *sdr_addr;
+ int rc = 0;
+ dma_addr_t msi_phys;
+ void *msi_virt;
+
+ sdr_addr = of_get_property(dev->dev.of_node, "sdr-base", NULL);
+ if (!sdr_addr)
+ return -1;
+
+ SDR0_WRITE(sdr_addr, (u64)res.start >> UPPER_4BITS_OF36BIT); /*HIGH addr */
+ SDR0_WRITE(sdr_addr + 1, res.start & LOWER_32BITS_OF36BIT); /* Low addr */
+
+ msi->msi_regs = ioremap((u64) res.start, res.end - res.start + 1);
+ if (!msi->msi_regs) {
+ dev_err(&dev->dev, "ioremap problem failed\n");
+ return ENOMEM;
+ }
+ dev_dbg(&dev->dev, "PCIE-MSI: msi register mapped 0x%x 0x%x\n",
+ (u32) (msi->msi_regs + PEIH_TERMADH), (u32) (msi->msi_regs));
+
+ msi_virt = dma_alloc_coherent(&dev->dev, 64, &msi_phys, GFP_KERNEL);
+ msi->msi_addr_hi = 0x0;
+ msi->msi_addr_lo = (u32) msi_phys;
+ dev_dbg(&dev->dev, "PCIE-MSI: msi address 0x%x \n", msi->msi_addr_lo);
+
+ /* Progam the Interrupt handler Termination addr registers */
+ out_be32(msi->msi_regs + PEIH_TERMADH, msi->msi_addr_hi);
+ out_be32(msi->msi_regs + PEIH_TERMADL, msi->msi_addr_lo);
+
+ msi_data = of_get_property(dev->dev.of_node, "msi-data", NULL);
+ if (!msi_data) {
+ rc = -1;
+ goto error_out;
+ }
+
+ msi_mask = of_get_property(dev->dev.of_node, "msi-mask", NULL);
+ if (!msi_mask) {
+ rc = -1;
+ goto error_out;
+ }
+
+ /* Program MSI Expected data and Mask bits */
+ out_be32(msi->msi_regs + PEIH_MSIED, 0);
+ out_be32(msi->msi_regs + PEIH_MSIMK, *msi_mask);
+
+ return 0;
+ error_out:
+ iounmap(msi->msi_regs);
+ return rc;
+}
+static int __devinit ppc4xx_msi_probe(struct platform_device *dev,
+ const struct of_device_id *match)
+{
+ struct ppc4xx_msi *msi;
+ struct resource res;
+ int err = 0;
+
+ dev_dbg(&dev->dev, "PCIE-MSI: Setting up MSI support...\n");
+
+ msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
+ if (!msi) {
+ dev_err(&dev->dev, "No memory for MSI structure\n");
+ err = -ENOMEM;
+ goto error_out;
+ }
+ /* Get MSI ranges */
+ err = of_address_to_resource(dev->dev.of_node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "%s resource error!\n",
+ dev->dev.of_node->full_name);
+ goto error_out;
+ }
+
+ if (ppc4xx_setup_pcieh_hw(dev, res, msi))
+ goto error_out;
+
+ ppc4xx_msi = msi;
+
+ WARN_ON(ppc_md.setup_msi_irqs);
+ ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
+ ppc_md.msi_check_device = ppc4xx_msi_check_device;
+ return 0;
+
+ error_out:
+ kfree(msi);
+ return err;
+}
+static const struct ppc4xx_msi_feature ppc4xx_msi_feature = {
+ .ppc4xx_pic_ip = 0,
+ .msiir_offset = 0x140,
+};
+
+static const struct of_device_id ppc4xx_msi_ids[] = {
+ {
+ .compatible = "amcc,ppc4xx-msi",
+ .data = (void *)&ppc4xx_msi_feature,
+ },
+ {}
+};
+
+static struct of_platform_driver ppc4xx_msi_driver = {
+ .driver = {
+ .name = "ppc4xx-msi",
+ .owner = THIS_MODULE,
+ .of_match_table = ppc4xx_msi_ids,
+ },
+ .probe = ppc4xx_msi_probe,
+};
+
+static __init int ppc4xx_msi_init(void)
+{
+ return of_register_platform_driver(&ppc4xx_msi_driver);
+}
+
+subsys_initcall(ppc4xx_msi_init);
--
1.6.1.rc3
^ permalink raw reply related
* Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
From: Segher Boessenkool @ 2010-10-29 0:16 UTC (permalink / raw)
To: pacman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101028210753.22240.qmail@kosh.dhis.org>
>> > Almost all of my devices are under that PCI node. What will I prove by
>> > disabling them?
>>
>> You should put it after "load", and before "go".
>>
>> It should give you a working system; it's a sledgehammer workaround.
>
> I can do it a little more gracefully than that. This works to deactivate
> the
> problem devices manually:
>
> 1 lbflip 80000000 8 + rl!
> 1 lbflip 80001000 8 + rl!
>
> where 80000000 and 80001000 have been obtained from
> /pci@80000000/usb@5/assigned-addresses and
> /pci@80000000/usb@5,1/assigned-addresses; 8 is the offset of the
> HcCommandStatus register; and the 1 bit is HostControllerReset (HCR).
>
> Now I'm just trying to find the more correct way of doing it, without
> hardcoded addresses. That'll be something like this:
>
> search the device tree for OHCI nodes
> for each OHCI node
> get assigned-addresses
> map-in
> set HCR
> wait for acknowledgement
> map-out
As you noted, your firmware does not show which usb host controllers
are OHCI and which are not. It has a lot of other problems as well.
Also, it's a lot of code to do things this way. Which is why I suggested
the "heavy handed" workaround: it is simple and should work on even the
most broken OF implementations.
To figure out which host controllers are OHCI, you'll need to look
at the PCI class code (0c0310 for OHCI), since your OF doesn't want
to tell you.
> Sound good?
Sounds like it should work, yes.
Segher
^ permalink raw reply
* [PATCH 0/3][RFC][REPOST] Add Support for Virtual Processor Home Node (VPHN)
From: Jesse Larrew @ 2010-10-29 0:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: markn, pmac, tbreeds, lkessler, Jesse Larrew, mjwolf
From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
The SPLPAR option allows the platform to dispatch virtual processors on
physical processors that, due to the variable nature of work loads, are
temporarily free, thus improving the utilization of computing resources.
However, SPLPAR implies inconsistent mapping of virtual to physical
processors, thus defeating resource allocation software that attempts to
optimize performance on platforms that implement the NUMA option.
To bridge the gap between these two options, the VPHN option maintains a
substantially consistent mapping of a given virtual processor to a physical
processor or set of processors within a given associativity domain. When
allocating computing resources, the kernel can take advantage of this
statistically consistent mapping to improve processing performance.
VPHN mappings are substantially consistent but not static. For any given
dispatch cycle, a best effort is made by the hypervisor to dispatch the
virtual processor on a physical processor within a targeted associativity
domain (the virtual processor's home node). However, if processing capacity
within the home node is not available, some other physical processor is
assigned to meet the processing capacity entitlement. From time to time,
to optimize the total platform performance, it may be necessary for the
platform to change the home node of a given virtual processor.
The Virtual Processor Home Node feature addresses this by adding the
H_HOME_NODE_ASSOCIATIVITY hcall to retrieve the current associativity
domain information directly from the hypervisor for a given virtual
processor's home node. It also exposes a set of associativity change
counters in the Virtual Processor Area (VPA) of each processor to indicate
when associativity changes occur.
This patch set sets a timer during boot that will periodically poll the
associativity change counters. When a change in associativity is detected,
it retrieves the new associativity domain information via the
H_HOME_NODE_ASSOCIATIVITY hcall and updates the NUMA node maps and sysfs
entries accordingly. The polling mechanism is also tied into the
ibm,suspend-me rtas call to stop/restart polling before/after a suspend,
hibernate, migrate, or checkpoint restart operation.
This patch set applies to v2.6.36 and includes the following:
[PATCH 1/3] powerpc: Add VPHN firmware feature
[PATCH 2/3] powerpc: Poll VPA for topology changes and update NUMA maps
[PATCH 3/3] powerpc: Disable VPHN polling during a suspend operation
Signed-off-by: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/firmware.h | 3 +-
arch/powerpc/include/asm/hvcall.h | 3 +-
arch/powerpc/include/asm/lppaca.h | 5 +-
arch/powerpc/include/asm/topology.h | 6 +-
arch/powerpc/kernel/rtas.c | 15 ++
arch/powerpc/mm/numa.c | 274 +++++++++++++++++++++++++++-
arch/powerpc/platforms/pseries/firmware.c | 1 +
7 files changed, 293 insertions(+), 14 deletions(-)
^ 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