* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Ian Campbell @ 2009-05-21 19:01 UTC (permalink / raw)
To: Becky Bruce
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org, Jeremy Fitzhardinge,
linux-kernel@vger.kernel.org
In-Reply-To: <E6DAA792-9923-4B76-9759-6955AABE3EAB@kernel.crashing.org>
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
> We have both in every case but one,
> which is in swiotlb_map_page where we call address_needs_mapping()
> without calling range_needs_mapping.
The reason it calls address_needs_mapping without range_needs_mapping is
that in the swiotlb_force=1 case it would trigger every time. If
address_needs_mapping and range_needs_mapping are merged as proposed and
they do not subsume the swiotlb_force check (and I don't think they
would) then I think this will work fine.
> It's not actually clear to me that we need that check, though. Can
> someone explain what case that was designed to catch?
If map_single fails and returns NULL then we try to use
io_tlb_overflow_buffer, if that is somehow not DMA-able (for the
particular device) then the check will trigger. I would have thought we
could arrange that the overflow buffer is always OK and really if
map_page is failing we must be close the edge already.
Ian.
^ permalink raw reply
* Audio and mpc5200 bestcomm tasks
From: Jon Smirl @ 2009-05-21 18:52 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev
ALSA really wants to dynamically know the address of the current DMA
location while transfers are active. This is an important piece of
implementing pause/resume. Pause doesn't work too well if there is 2s
of music already queued. The work around is to know the sample rate
and use the jiffy count to estimate how far into the buffer DMA has
progressed. But that's not as accurate as just asking the DMA
hardware.
I poked around in the SRAM data and couldn't find the address. Is it
there or can the Bestcomm tasks be modified to leave it somewhere
visible?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: ipr boot failure caused by MSI (2.6.30-rc1+)
From: Brian King @ 2009-05-21 18:47 UTC (permalink / raw)
To: James Bottomley; +Cc: Brian King, ppc-dev, Wayne Boyer, linux-scsi
In-Reply-To: <1242926159.3007.5.camel@localhost.localdomain>
cc'ing linuxppc-dev...
-Brian
James Bottomley wrote:
> Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr
> just times out and refuses to probe devices. If I let it drop into the
> initramfs system, this is what the interrupts shows:
>
> (initramfs) cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 16: 20 10 13 11 MPIC Level pata_amd
> 20: 0 0 0 0 MPIC Level ohci_hcd:usb1, ohci_hcd:usb2
> 21: 0 0 0 0 MPIC-U3MSI Edge ipr
> 68: 37 37 48 37 MPIC Edge serial
> 251: 10 71 69 72 MPIC Edge ipi call function
> 252: 1555 1779 1372 1155 MPIC Edge ipi reschedule
> 253: 0 0 0 0 MPIC Edge ipi call function single
> 254: 0 0 0 0 MPIC Edge ipi debugger
> BAD: 416
>
> So you see the IPR is the only device not receiving them.
>
> I can fix the boot hang by reverting
>
> commit 5a9ef25b14d39b8413364df12cb8d9bb7a673a32
> Author: Wayne Boyer <wayneb@linux.vnet.ibm.com>
> Date: Fri Jan 23 09:17:35 2009 -0800
>
> [SCSI] ipr: add MSI support
>
> The system in question is:
>
> SYSTEM INFORMATION
> Processor = PowerPC,970MP @ 2500 MHz
> I/O Bridge = U4 (4.4)
> SMP Size = 4 (#0 #1 #2 #3)
> Boot-Date = 2009-04-21 17:13:36
> Memory = 2 GB of RAM @ 666 MHz
> Board Type = Bimini (7047191/0000000/1)
> MFG Date = 1608
> Part No. = 10N8748
> FRU No. = 10N7182
> FRU Serial = YL30W8106038
> UUID = 00000000000000000000000000000000
> Flashside = 1 (temporary)
> Version = HEAD
> Build Date = 12-04-2008 16:13
>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Becky Bruce @ 2009-05-21 18:27 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: FUJITA Tomonori, linuxppc-dev, linux-kernel, Ian Campbell
In-Reply-To: <4A1592CF.8000208@goop.org>
On May 21, 2009, at 12:43 PM, Jeremy Fitzhardinge wrote:
> Becky Bruce wrote:
>>>
>>>
>>> If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
>>>
>>> static inline int is_buffer_dma_capable(struct device *dev,
>>> dma_addr_t addr, size_t size)
>>>
>>> then we don't need two checking functions, address_needs_mapping and
>>> range_needs_mapping.
>>
>> It's never been clear to me *why* we had both in the first place -
>> if you can explain this, I'd be grateful :)
>
> I was about to ask the same thing. It seems that
> range_needs_mapping should be able to do both jobs.
>
> I think range_needs_mapping came from the Xen swiotlb changes, and
> address_needs_mapping came from your powerpc changes. Many of the
> changes were exact overlaps; I think this was one of the few
> instances where there was a difference.
I think address_needs_mapping was already there and I added the
ability for an arch to provide its own version. Ian added
range_needs_mapping in commit b81ea27b2329bf44b. At the time, it
took a virtual address as its argument, so we couldn't use it for
highmem. That's since been changed to phys_addr_t, so I think we
should be able to merge the two.
>
> We need a range check in Xen (rather than iterating over individual
> pages) because we want to check that the underlying pages are
> machine contiguous, but I think that's also sufficient to do
> whatever checks you need to do.
Yes.
>
> The other difference is that is_buffer_dma_capable operates on a
> dma_addr_t, which presumes that you can generate a dma address and
> then test for its validity. For Xen, it doesn't make much sense to
> talk about the dma_addr_t for memory which isn't actually dma-
> capable; we need the test to be in terms of phys_addr_t. Given that
> the two functions are always called from the same place, that
> doesn't seem to pose a problem.
>
> So I think the unified function would be something like:
>
> int range_needs_mapping(struct device *hwdev, phys_addr_t addr,
> size_t size);
>
> which would be defined somewhere under asm/*.h. Would that work for
> powerpc?
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've already done and
that I need in the calling code as well. Can we pass in both the
phys_addr_t and the dma_addr_t? We have both in every case but one,
which is in swiotlb_map_page where we call address_needs_mapping()
without calling range_needs_mapping. It's not actually clear to me
that we need that check, though. Can someone explain what case that
was designed to catch?
Cheers,
Becky
^ permalink raw reply
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Grant Likely @ 2009-05-21 17:58 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <38563D01-3F19-480A-AC65-743A0A2318BE@kernel.crashing.org>
On Thu, May 21, 2009 at 11:43 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>> However, on the other point, Jon is correct. =A0The first value in the
>> list should be "atmel,24c32", not "at24,24c32".
>
> Yeah. =A0So perhaps "atmel,24c32","24c32" ? =A0I'm not terribly happy
> with that last name, but these devices are _very_ common.
I don't think the last name is necessary at all. I'd leave it at
"atmel,24c32". non-atmel parts can claim compatibility with the atmel
version if really necessary. I don't like the 'generic' version
either.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
From: Roderick Colenbrander @ 2009-05-21 17:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090521165008.A020D710053@mail54-sin.bigfish.com>
> Yeow... I agree about the dirty hack part... shouldn't this be in the
> device tree somewhere, or in the ali driver?
>
> I'm curious if this works on ml410 as well.. (Yes, I know, does this
> really matter much? But there are still a bunch of them floating around
> in universities.) It may be nice to factor this out so ml410/ppc405 and
> microblaze can get it as well.
>
> Steve
Yes the code can work one the ML410 as well. The thing is that you
would need a recent reference design from Xilinx. Before Xilinx used a
OPB pci bridge and these days they use a PLB (v46) pci bridge. The old
reference designs use the OPB core. I saw someone using a ML410
reference design which used the PBL pci soft-core and the same memory
addresses were even used as in the ml510 reference design I'm using.
I'm not sure where the guy got the design since the xilinx site only
shows old opb_pci stuff. (though the core is nearly the same) Further
most devices are also at the same locations on the pci bus.
Further the ml410 also offers good old lpt1 and some other things
which aren't on the ml510 but yes the pci code and big parts of the
dts file I wrote can be reused.
Roderick
^ permalink raw reply
* Re: [PATCH v4 0/3] Add support for ML510 board
From: Roderick Colenbrander @ 2009-05-21 17:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20090521162202.10880.34056.stgit@localhost.localdomain>
On Thu, May 21, 2009 at 6:24 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> Heck, I don't know if this stuff even works, but I've refactored
> Roderick's patches into something closer to the structure that I'd like
> to see. =A0There are still a few things that bother me, but I think it
> is mostly there.
>
> It at least boots on an ML507 board.
>
> Roderick, can you please take a look?
>
> Thanks,
> g.
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
>
>From a quick glance it looks good. I will test it on monday.
Roderick
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Jeremy Fitzhardinge @ 2009-05-21 17:43 UTC (permalink / raw)
To: Becky Bruce; +Cc: FUJITA Tomonori, linuxppc-dev, linux-kernel, Ian Campbell
In-Reply-To: <19E48A70-3332-423C-ACAD-390F940EE81C@kernel.crashing.org>
Becky Bruce wrote:
>>
>>
>> If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
>>
>> static inline int is_buffer_dma_capable(struct device *dev,
>> dma_addr_t addr, size_t size)
>>
>> then we don't need two checking functions, address_needs_mapping and
>> range_needs_mapping.
>
> It's never been clear to me *why* we had both in the first place - if
> you can explain this, I'd be grateful :)
I was about to ask the same thing. It seems that range_needs_mapping
should be able to do both jobs.
I think range_needs_mapping came from the Xen swiotlb changes, and
address_needs_mapping came from your powerpc changes. Many of the
changes were exact overlaps; I think this was one of the few instances
where there was a difference.
We need a range check in Xen (rather than iterating over individual
pages) because we want to check that the underlying pages are machine
contiguous, but I think that's also sufficient to do whatever checks you
need to do.
The other difference is that is_buffer_dma_capable operates on a
dma_addr_t, which presumes that you can generate a dma address and then
test for its validity. For Xen, it doesn't make much sense to talk
about the dma_addr_t for memory which isn't actually dma-capable; we
need the test to be in terms of phys_addr_t. Given that the two
functions are always called from the same place, that doesn't seem to
pose a problem.
So I think the unified function would be something like:
int range_needs_mapping(struct device *hwdev, phys_addr_t addr,
size_t size);
which would be defined somewhere under asm/*.h. Would that work for
powerpc?
J
^ permalink raw reply
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Segher Boessenkool @ 2009-05-21 17:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40905200936o63f47937rda28126ce0f46aad@mail.gmail.com>
> As the other thread states, "eeprom" is far too vague, and it is
> certainly not documented, and does not say anything meaningful about
> the protocol used to talk to the eeprom. Sure, most i2c eeproms use
> the same protocol,
Not at all! Pretty much every size of 24c has its own protocol;
and some manufacturers have special extensions for locking parts
of the array, etc. A driver can ignore that last part, but not
the first. So the SEEPROM size should be part of its "compatible"
name; simplest way for that is to use the model number.
> but an assumption cannot be made that that will
> always be the case. Plus, the namespace will collide with non-i2c
> eeproms. "i2c-eeprom" is better, but not great. Before a value like
> "i2c-eeprom" can be acceptable, it must be documented and reviewed as
> to exactly what it means, and even then I'm uncomfortable with it.
>
> However, on the other point, Jon is correct. The first value in the
> list should be "atmel,24c32", not "at24,24c32".
Yeah. So perhaps "atmel,24c32","24c32" ? I'm not terribly happy
with that last name, but these devices are _very_ common.
Segher
^ permalink raw reply
* RE: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
From: Stephen Neuendorffer @ 2009-05-21 16:50 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090521162434.10880.62883.stgit@localhost.localdomain>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of Grant
Likely
> Sent: Thursday, May 21, 2009 9:25 AM
> To: linuxppc-dev@ozlabs.org; Roderick Colenbrander
> Subject: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference
designsupport
> =
> From: Roderick Colenbrander <thunderbird2k@gmail.com>
> =
> Signed-off-by: Roderick Colenbrander <thunderbird2k@gmail.com>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =
> arch/powerpc/platforms/44x/Kconfig | 10 +++++++++-
> arch/powerpc/platforms/44x/Makefile | 1 +
> arch/powerpc/platforms/44x/virtex_ml510.c | 29
+++++++++++++++++++++++++++++
> arch/powerpc/sysdev/xilinx_intc.c | 5 +++++
> 4 files changed, 44 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
> =
> =
> diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
> index 0d83a6a..af1c51d 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -156,7 +156,7 @@ config YOSEMITE
> # This option enables support for the IBM PPC440GX evaluation
board.
> =
> config XILINX_VIRTEX440_GENERIC_BOARD
> - bool "Generic Xilinx Virtex 440 board"
> + bool "Xilinx Virtex 5 support"
'Virtex 5' is a little ambiguous.. I'd suggest keeping the old wording,
or saying 'Virtex 5 FXT support'. Even then it's somewhat ambiguous,
since you could conceivably run linux on microblaze on V5FXT and use the
powerpc for something else..
> depends on 44x
> default n
> select XILINX_VIRTEX_5_FXT
> @@ -171,6 +171,14 @@ config XILINX_VIRTEX440_GENERIC_BOARD
> Most Virtex 5 designs should use this unless it needs to do
some
> special configuration at board probe time.
> =
> +config XILINX_ML510
> + bool "Xilinx ML510 board support"
> + depends on XILINX_VIRTEX440_GENERIC_BOARD
> + select PPC_PCI_CHOICE
> + select XILINX_PCI if PCI
> + select PPC_INDIRECT_PCI if PCI
> + select PPC_I8259 if PCI
> +
> config PPC44x_SIMPLE
> bool "Simple PowerPC 44x board support"
> depends on 44x
> diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
> index 01f51da..ee6185a 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_EBONY) +=3D ebony.o
> obj-$(CONFIG_SAM440EP) +=3D sam440ep.o
> obj-$(CONFIG_WARP) +=3D warp.o
> obj-$(CONFIG_XILINX_VIRTEX_5_FXT) +=3D virtex.o
> +obj-$(CONFIG_XILINX_ML510) +=3D virtex_ml510.o
> diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c
b/arch/powerpc/platforms/44x/virtex_ml510.c
> new file mode 100644
> index 0000000..ba4a6e3
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/virtex_ml510.c
> @@ -0,0 +1,29 @@
> +#include <asm/i8259.h>
> +#include <linux/pci.h>
> +#include "44x.h"
> +
> +/**
> + * ml510_ail_quirk
Tpyo, but is the comment even necessary if it doesn't say anything
useful?
> + */
> +static void __devinit ml510_ali_quirk(struct pci_dev *dev)
> +{
> + /* Enable the IDE controller */
> + pci_write_config_byte(dev, 0x58, 0x4c);
> + /* Assign irq 14 to the primary ide channel */
> + pci_write_config_byte(dev, 0x44, 0x0d);
> + /* Assign irq 15 to the secondary ide channel */
> + pci_write_config_byte(dev, 0x75, 0x0f);
> + /* Set the ide controller in native mode */
> + pci_write_config_byte(dev, 0x09, 0xff);
> +
> + /* INTB =3D disabled, INTA =3D disabled */
> + pci_write_config_byte(dev, 0x48, 0x00);
> + /* INTD =3D disabled, INTC =3D disabled */
> + pci_write_config_byte(dev, 0x4a, 0x00);
> + /* Audio =3D INT7, Modem =3D disabled. */
> + pci_write_config_byte(dev, 0x4b, 0x60);
> + /* USB =3D INT7 */
> + pci_write_config_byte(dev, 0x74, 0x06);
> +}
> +DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ml510_ali_quirk);
> +
> diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
> index 90b5772..3ee1fd3 100644
> --- a/arch/powerpc/sysdev/xilinx_intc.c
> +++ b/arch/powerpc/sysdev/xilinx_intc.c
> @@ -257,6 +257,11 @@ static void __init
xilinx_i8259_setup_cascade(void)
> i8259_init(cascade_node, 0);
> set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
> =
> + /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
> + /* This looks like a dirty hack to me --gcl */
> + outb(0xc0, 0x4d0);
> + outb(0xc0, 0x4d1);
> +
Yeow... I agree about the dirty hack part... shouldn't this be in the
device tree somewhere, or in the ali driver?
I'm curious if this works on ml410 as well.. (Yes, I know, does this
really matter much? But there are still a bunch of them floating around
in universities.) It may be nice to factor this out so ml410/ppc405 and
microblaze can get it as well.
Steve
> out:
> of_node_put(cascade_node);
> }
> =
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Albert Herranz @ 2009-05-21 16:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ilya Yanok
Hello list,=0A=0ACommit 33f00dcedb0e22cdb156a23632814fc580fcfcf8 seems to h=
ave broken DMA coherent allocations for CONFIG_NOT_COHERENT_CACHE platforms=
.=0A=0AThe problems seem to be that the new __dma_alloc_coherent() and __dm=
a_free_coherent() implementations:=0A=0A- don't respect anymore the passed =
gfp flags (__dma_alloc_coherent() unconditionally uses GFP_KERNEL within th=
e function irrespective of the caller flags)=0A- can't be used in interrupt=
context as they use get_vm_area_caller()/vfree() which end up triggering B=
UG_ON(in_interrupt())=0A=0AOne victim happens to be the USB core subsystem =
which sometimes frees dma coherent memory in interrupt context for drivers =
flagged HCD_LOCAL_MEM.=0A=0AThis has been experienced while writing a new E=
HCI driver for the Nintendo Wii platform.=0A=0Ausb 1-1: new high speed USB =
device using ehci-mipc and address 2=0A------------[ cut here ]------------=
=0Akernel BUG at mm/vmalloc.c:1328!=0AOops: Exception in kernel mode, sig: =
5 [#1]=0APREEMPT wii=0AModules linked in:=0ANIP: c008ea20 LR: c0015890 CTR:=
c00111d4=0AREGS: d2c65b10 TRAP: 0700 Not tainted (2.6.30-rc2-isobel-wii=
-00092-gcba94db-dirty)=0AMSR: 00021032 <ME,CE,IR,DR> CR: 42482028 XER: 00=
000000=0ATASK =3D d2c600f0[28] 'kmmcd' THREAD: d2c64000=0AGPR00: 00010000 d=
2c65bc0 d2c600f0 d4030000 d4030000 d4030000 12da1000 00000001 =0AGPR08: 000=
00000 d2c64000 00000020 00000000 22482022 94fdfb98 6e1979bc c6bbdbdd =0AGPR=
16: 00000020 00200200 00100100 d4020060 00000001 d401c0ec 00000001 d401c0ec=
=0AGPR24: d2d9a6c0 00000000 00000000 d2f69de0 d2d9a600 d2f69e30 d2f69e2c d=
2da08e0 =0ANIP [c008ea20] vfree+0xc/0x18=0ALR [c0015890] __dma_free_coheren=
t+0x14/0x24=0ACall Trace:=0A[d2c65bc0] [c0017af8] __mipc_recv_req+0x160/0x1=
78 (unreliable)=0A[d2c65bd0] [c00111ec] dma_direct_free_coherent+0x18/0x28=
=0A[d2c65be0] [c01cfca4] hcd_free_coherent+0x7c/0x12c=0A[d2c65c10] [c01d00b=
8] unmap_urb_for_dma+0x150/0x1cc=0A[d2c65c20] [c01d0174] usb_hcd_giveback_u=
rb+0x40/0xe4=0A[d2c65c30] [c01df474] ehci_urb_done+0xf0/0x114=0A[d2c65c50] =
[c01e3870] qh_completions+0x41c/0x4dc=0A[d2c65ca0] [c01e44e0] scan_async+0x=
9c/0x1a0=0A[d2c65cc0] [c01e49ec] ehci_work+0x58/0xc4=0A[d2c65cd0] [c01e5424=
] ehci_irq+0x22c/0x230=0A[d2c65d00] [c01cfa88] usb_hcd_irq+0x50/0xa8=0A[d2c=
65d20] [c00597d8] handle_IRQ_event+0xdc/0x250=0A[d2c65d60] [c005ba20] handl=
e_level_irq+0x9c/0x138=0A[d2c65d80] [c001cbc8] hollywood_pic_irq_cascade+0x=
7c/0xf8=0A[d2c65da0] [c00064b4] do_IRQ+0x9c/0xc4=0A[d2c65dc0] [c0011fb8] re=
t_from_except+0x0/0x14=0A=0AAny comments on how to address this issue (othe=
r than reverting the above mentioned commit, which fixes it) are welcome.=
=0A=0AThanks,=0AAlbert=0A=0A=0A=0A
^ permalink raw reply
* [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference design support
From: Grant Likely @ 2009-05-21 16:24 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090521162202.10880.34056.stgit@localhost.localdomain>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/44x/Kconfig | 10 +++++++++-
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 +++++++++++++++++++++++++++++
arch/powerpc/sysdev/xilinx_intc.c | 5 +++++
4 files changed, 44 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0d83a6a..af1c51d 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -156,7 +156,7 @@ config YOSEMITE
# This option enables support for the IBM PPC440GX evaluation board.
config XILINX_VIRTEX440_GENERIC_BOARD
- bool "Generic Xilinx Virtex 440 board"
+ bool "Xilinx Virtex 5 support"
depends on 44x
default n
select XILINX_VIRTEX_5_FXT
@@ -171,6 +171,14 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config XILINX_ML510
+ bool "Xilinx ML510 board support"
+ depends on XILINX_VIRTEX440_GENERIC_BOARD
+ select PPC_PCI_CHOICE
+ select XILINX_PCI if PCI
+ select PPC_INDIRECT_PCI if PCI
+ select PPC_I8259 if PCI
+
config PPC44x_SIMPLE
bool "Simple PowerPC 44x board support"
depends on 44x
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 01f51da..ee6185a 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c b/arch/powerpc/platforms/44x/virtex_ml510.c
new file mode 100644
index 0000000..ba4a6e3
--- /dev/null
+++ b/arch/powerpc/platforms/44x/virtex_ml510.c
@@ -0,0 +1,29 @@
+#include <asm/i8259.h>
+#include <linux/pci.h>
+#include "44x.h"
+
+/**
+ * ml510_ail_quirk
+ */
+static void __devinit ml510_ali_quirk(struct pci_dev *dev)
+{
+ /* Enable the IDE controller */
+ pci_write_config_byte(dev, 0x58, 0x4c);
+ /* Assign irq 14 to the primary ide channel */
+ pci_write_config_byte(dev, 0x44, 0x0d);
+ /* Assign irq 15 to the secondary ide channel */
+ pci_write_config_byte(dev, 0x75, 0x0f);
+ /* Set the ide controller in native mode */
+ pci_write_config_byte(dev, 0x09, 0xff);
+
+ /* INTB = disabled, INTA = disabled */
+ pci_write_config_byte(dev, 0x48, 0x00);
+ /* INTD = disabled, INTC = disabled */
+ pci_write_config_byte(dev, 0x4a, 0x00);
+ /* Audio = INT7, Modem = disabled. */
+ pci_write_config_byte(dev, 0x4b, 0x60);
+ /* USB = INT7 */
+ pci_write_config_byte(dev, 0x74, 0x06);
+}
+DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ml510_ali_quirk);
+
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index 90b5772..3ee1fd3 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -257,6 +257,11 @@ static void __init xilinx_i8259_setup_cascade(void)
i8259_init(cascade_node, 0);
set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+ /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
+ /* This looks like a dirty hack to me --gcl */
+ outb(0xc0, 0x4d0);
+ outb(0xc0, 0x4d1);
+
out:
of_node_put(cascade_node);
}
^ permalink raw reply related
* [PATCH v4 2/3] powerpc/virtex: refactor intc driver and add support for i8259 cascading
From: Grant Likely @ 2009-05-21 16:24 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090521162202.10880.34056.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
This patch refactors some of the xilinx_intc interrupt controller driver
and adds support for cascading an i8259 off one of the irq lines.
This patch was based on the ML510 support work done by Roderick
Colenbrander.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/sysdev/xilinx_intc.c | 76 ++++++++++++++++++++++++++++---------
1 files changed, 58 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index c658b41..90b5772 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -25,6 +25,7 @@
#include <linux/of.h>
#include <asm/io.h>
#include <asm/processor.h>
+#include <asm/i8259.h>
#include <asm/irq.h>
/*
@@ -191,20 +192,14 @@ struct irq_host * __init
xilinx_intc_init(struct device_node *np)
{
struct irq_host * irq;
- struct resource res;
void * regs;
- int rc;
/* Find and map the intc registers */
- rc = of_address_to_resource(np, 0, &res);
- if (rc) {
- printk(KERN_ERR __FILE__ ": of_address_to_resource() failed\n");
+ regs = of_iomap(np, 0);
+ if (!regs) {
+ pr_err("xilinx_intc: could not map registers\n");
return NULL;
}
- regs = ioremap(res.start, 32);
-
- printk(KERN_INFO "Xilinx intc at 0x%08llx mapped to 0x%p\n",
- (unsigned long long) res.start, regs);
/* Setup interrupt controller */
out_be32(regs + XINTC_IER, 0); /* disable all irqs */
@@ -217,6 +212,7 @@ xilinx_intc_init(struct device_node *np)
if (!irq)
panic(__FILE__ ": Cannot allocate IRQ host\n");
irq->host_data = regs;
+
return irq;
}
@@ -227,23 +223,65 @@ int xilinx_intc_get_irq(void)
return irq_linear_revmap(master_irqhost, in_be32(regs + XINTC_IVR));
}
+#if defined(CONFIG_PPC_I8259)
+/*
+ * Support code for cascading to 8259 interrupt controllers
+ */
+static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+ if (cascade_irq)
+ generic_handle_irq(cascade_irq);
+
+ /* Let xilinx_intc end the interrupt */
+ desc->chip->ack(irq);
+ desc->chip->unmask(irq);
+}
+
+static void __init xilinx_i8259_setup_cascade(void)
+{
+ struct device_node *cascade_node;
+ int cascade_irq;
+
+ /* Initialize i8259 controller */
+ cascade_node = of_find_compatible_node(NULL, NULL, "chrp,iic");
+ if (!cascade_node)
+ return;
+
+ cascade_irq = irq_of_parse_and_map(cascade_node, 0);
+ if (!cascade_irq) {
+ pr_err("virtex_ml510: Failed to map cascade interrupt\n");
+ goto out;
+ }
+
+ i8259_init(cascade_node, 0);
+ set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+
+ out:
+ of_node_put(cascade_node);
+}
+#else
+static inline void xilinx_i8259_setup_cascade(void) { return; }
+#endif /* defined(CONFIG_PPC_I8259) */
+
+static struct of_device_id xilinx_intc_match[] __initconst = {
+ { .compatible = "xlnx,opb-intc-1.00.c", },
+ { .compatible = "xlnx,xps-intc-1.00.a", },
+ {}
+};
+
+/*
+ * Initialize master Xilinx interrupt controller
+ */
void __init xilinx_intc_init_tree(void)
{
struct device_node *np;
/* find top level interrupt controller */
- for_each_compatible_node(np, NULL, "xlnx,opb-intc-1.00.c") {
+ for_each_matching_node(np, xilinx_intc_match) {
if (!of_get_property(np, "interrupts", NULL))
break;
}
- if (!np) {
- for_each_compatible_node(np, NULL, "xlnx,xps-intc-1.00.a") {
- if (!of_get_property(np, "interrupts", NULL))
- break;
- }
- }
-
- /* xilinx interrupt controller needs to be top level */
BUG_ON(!np);
master_irqhost = xilinx_intc_init(np);
@@ -251,4 +289,6 @@ void __init xilinx_intc_init_tree(void)
irq_set_default_host(master_irqhost);
of_node_put(np);
+
+ xilinx_i8259_setup_cascade();
}
^ permalink raw reply related
* [PATCH v4 1/3] powerpc/virtex: Add support for Xilinx PCI host bridge
From: Grant Likely @ 2009-05-21 16:24 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090521162202.10880.34056.stgit@localhost.localdomain>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
This patch adds support for the Xilinx plbv46-pci-1.03.a PCI host
bridge IPcore.
Signed-off-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/xilinx_pci.h | 21 +++++
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/44x/virtex.c | 2 +
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/xilinx_pci.c | 132 +++++++++++++++++++++++++++++++++
6 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
diff --git a/arch/powerpc/include/asm/xilinx_pci.h b/arch/powerpc/include/asm/xilinx_pci.h
new file mode 100644
index 0000000..7a8275c
--- /dev/null
+++ b/arch/powerpc/include/asm/xilinx_pci.h
@@ -0,0 +1,21 @@
+/*
+ * Xilinx pci external definitions
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef INCLUDE_XILINX_PCI
+#define INCLUDE_XILINX_PCI
+
+#ifdef CONFIG_XILINX_PCI
+extern void __init xilinx_pci_init(void);
+#else
+static inline void __init xilinx_pci_init(void) { return; }
+#endif
+
+#endif /* INCLUDE_XILINX_PCI */
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
index fc7fb00..d0fc686 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -14,6 +14,7 @@
#include <asm/prom.h>
#include <asm/time.h>
#include <asm/xilinx_intc.h>
+#include <asm/xilinx_pci.h>
#include <asm/ppc4xx.h>
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
@@ -47,6 +48,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = "Xilinx Virtex",
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq = xilinx_intc_get_irq,
.restart = ppc4xx_reset_system,
diff --git a/arch/powerpc/platforms/44x/virtex.c b/arch/powerpc/platforms/44x/virtex.c
index 68637fa..cf96cca 100644
--- a/arch/powerpc/platforms/44x/virtex.c
+++ b/arch/powerpc/platforms/44x/virtex.c
@@ -16,6 +16,7 @@
#include <asm/prom.h>
#include <asm/time.h>
#include <asm/xilinx_intc.h>
+#include <asm/xilinx_pci.h>
#include <asm/reg.h>
#include <asm/ppc4xx.h>
#include "44x.h"
@@ -53,6 +54,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = "Xilinx Virtex440",
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq = xilinx_intc_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index e3e8707..04a8061 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -329,4 +329,8 @@ config MCU_MPC8349EMITX
also register MCU GPIOs with the generic GPIO API, so you'll able
to use MCU pins as GPIOs.
+config XILINX_PCI
+ bool "Xilinx PCI host bridge support"
+ depends on PCI && XILINX_VIRTEX
+
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..2d1c87d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IPIC) += ipic.o
obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX) += xilinx_intc.o
+obj-$(CONFIG_XILINX_PCI) += xilinx_pci.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
diff --git a/arch/powerpc/sysdev/xilinx_pci.c b/arch/powerpc/sysdev/xilinx_pci.c
new file mode 100644
index 0000000..1453b0e
--- /dev/null
+++ b/arch/powerpc/sysdev/xilinx_pci.c
@@ -0,0 +1,132 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
+ * Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was written
+ * by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt <benh@kernel.crashing.org>, IBM Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/ioport.h>
+#include <linux/of.h>
+#include <linux/pci.h>
+#include <mm/mmu_decl.h>
+#include <asm/io.h>
+#include <asm/xilinx_pci.h>
+
+#define XPLB_PCI_ADDR 0x10c
+#define XPLB_PCI_DATA 0x110
+#define XPLB_PCI_BUS 0x114
+
+#define PCI_HOST_ENABLE_CMD PCI_COMMAND_SERR | PCI_COMMAND_PARITY | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY
+
+static struct of_device_id xilinx_pci_match[] = {
+ { .compatible = "xlnx,plbv46-pci-1.03.a", },
+ {}
+};
+
+/**
+ * xilinx_pci_fixup_bridge - Block Xilinx PHB configuration.
+ */
+static void xilinx_pci_fixup_bridge(struct pci_dev *dev)
+{
+ struct pci_controller *hose;
+ int i;
+
+ if (dev->devfn || dev->bus->self)
+ return;
+
+ hose = pci_bus_to_host(dev->bus);
+ if (!hose)
+ return;
+
+ if (!of_match_node(xilinx_pci_match, hose->dn))
+ return;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ dev->resource[i].start = 0;
+ dev->resource[i].end = 0;
+ dev->resource[i].flags = 0;
+ }
+
+ dev_info(&dev->dev, "Hiding Xilinx plb-pci host bridge resources %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, xilinx_pci_fixup_bridge);
+
+/**
+ * xilinx_pci_exclude_device - Don't do config access for non-root bus
+ *
+ * This is a hack. Config access to any bus other than bus 0 does not
+ * currently work on the ML510 so we prevent it here.
+ */
+static int
+xilinx_pci_exclude_device(struct pci_controller *hose, u_char bus, u8 devfn)
+{
+ return (bus != 0);
+}
+
+/**
+ * xilinx_pci_init - Find and register a Xilinx PCI host bridge
+ */
+void __init xilinx_pci_init(void)
+{
+ struct pci_controller *hose;
+ struct resource r;
+ void __iomem *pci_reg;
+ struct device_node *pci_node;
+
+ pci_node = of_find_matching_node(NULL, xilinx_pci_match);
+ if(!pci_node)
+ return;
+
+ if (of_address_to_resource(pci_node, 0, &r)) {
+ pr_err("xilinx-pci: cannot resolve base address\n");
+ return;
+ }
+
+ hose = pcibios_alloc_controller(pci_node);
+ if (!hose) {
+ pr_err("xilinx-pci: pcibios_alloc_controller() failed\n");
+ return;
+ }
+
+ /* Setup config space */
+ setup_indirect_pci(hose, r.start + XPLB_PCI_ADDR,
+ r.start + XPLB_PCI_DATA,
+ PPC_INDIRECT_TYPE_SET_CFG_TYPE);
+
+ /* According to the xilinx plbv46_pci documentation the soft-core starts
+ * a self-init when the bus master enable bit is set. Without this bit
+ * set the pci bus can't be scanned.
+ */
+ early_write_config_word(hose, 0, 0, PCI_COMMAND, PCI_HOST_ENABLE_CMD);
+
+ /* Set the max latency timer to 255 */
+ early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0xff);
+
+ /* Set the max bus number to 255 */
+ pci_reg = of_iomap(pci_node, 0);
+ out_8(pci_reg + XPLB_PCI_BUS, 0xff);
+ iounmap(pci_reg);
+
+ /* Nothing past the root bridge is working right now. By default
+ * exclude config access to anything except bus 0 */
+ if (!ppc_md.pci_exclude_device)
+ ppc_md.pci_exclude_device = xilinx_pci_exclude_device;
+
+ /* Register the host bridge with the linux kernel! */
+ pci_process_bridge_OF_ranges(hose, pci_node, 1);
+
+ pr_info("xilinx-pci: Registered PCI host bridge\n");
+}
^ permalink raw reply related
* [PATCH v4 0/3] Add support for ML510 board
From: Grant Likely @ 2009-05-21 16:24 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
Heck, I don't know if this stuff even works, but I've refactored
Roderick's patches into something closer to the structure that I'd like
to see. There are still a few things that bother me, but I think it
is mostly there.
It at least boots on an ML507 board.
Roderick, can you please take a look?
Thanks,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Grant Likely @ 2009-05-21 15:36 UTC (permalink / raw)
To: Piotr Zięcik
Cc: Becky Bruce, Wolfgang Denk, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood
In-Reply-To: <200905211034.39762.kosmo@semihalf.com>
2009/5/21 Piotr Zi=EAcik <kosmo@semihalf.com>:
> Thursday 14 May 2009 16:00:33 Grant Likely wrote:
>> > MPC5121 support was added to drivers/net/fs_enet. MPC52xx uses
>> > drivers/net/fec_mpc52xx.c. Do you think that creating one universal
>> > driver from these two is now possible? You said that it should be easy=
,
>> > however you also said that cache coherency issues makes this imposible=
.
>>
>> Not impossible. =A0Hard.
>
> I thought a bit more about merging FEC drivers and I see one problem more=
.
> Driver fs_enet works with FEC's with own DMA engine and fec_mpc52xx.c use=
s
> BestComm. Integration of these two drivers will need a DMA abstraction la=
yer
> to keep everything clean. Unfortuanetly BestComm driver does not provide =
any
> abstraction - it only exports set of functions to deal with specific
> hardware: FEC and PATA.
>
> More #ifdef's will be needed to remove linking with BestComm driver if ke=
rnel
> will be compiled without 52xx support and resulting code will not be much
> better than existing one. Especially that new DMA abstraction layer proba=
bly
> will be quite complex.
If it looks too ugly, then just fork the driver.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-21 15:23 UTC (permalink / raw)
To: Morrison, Tom, Kumar Gala
Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <27AB6AE2-F8BA-4F05-9597-BCE0F98C1126@kernel.crashing.org>
Just had a little conference with several co-workers...to go over
results
We think that LT0 (the one that maps the kernel) has been corrupted:
Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
---------------------------------------------------------------
LT0 C0000000 00000000 00 0FF 04 9 0 0
PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
---------------------------------------------------------------
0 0 P P E E D E E D D V
Is absolutely wrong - this is TLB for the kernel - and as you can see=20
...it does NOT have execution privileges (and in fact the user space=20
HAS executive privileges for this area (complete opposite of what it=20
should be)...
This is why it is stuck AT that instruction (can't even single step
from that location)..
(one of) The first problem(s) is how can/when did this TLB get
corrupted!
Tom
^ permalink raw reply
* RE: How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-21 14:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <27AB6AE2-F8BA-4F05-9597-BCE0F98C1126@kernel.crashing.org>
What do you mean by 'odd' mappings (the EPN or RPNor ??)
Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
---------------------------------------------------------------
LT8 E5BF1000 995EA900 96 000 0C D 8 0
<continued>
PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
0 1 U S D E E E E D D V
We are using a 36bit address (mainly to remap our I/O and local bus
devices
to outside the 32bit addressing space)...
t
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Thursday, May 21, 2009 10:45 AM
>> To: Morrison, Tom
>> Cc: linuxppc-dev@ozlabs.org; Young, Andrew; Brown, Jeff; Geary Sean-
>> R60898
>> Subject: Re: How to debug a hung multi-core system....
>>=20
>> > [Morrison, Tom]
>> > >BKM>tat
>> >
>> > Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
>> > PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
>> >
>>=20
>> > LT0 C0000000 00000000 00 0FF 04 9 0 0
>> > 0 0 P P E E D E E D D V
>> > LT1 D0000000 01000000 00 0FF 04 9 0 0
>> > 0 0 P P E E D E E D D V
>> > LT2 E0000000 02000000 00 0FF 04 9 0 0
>> > 0 0 P P E E D E E D D V
>>=20
>> > LT4 F924E000 7C054500 BA 000 0B E 0 3
>> > 0 0 P S E E D E E D D V
>>=20
>> > LT6 80000000 1F000000 F2 0FF 1D 9 B 3
>> > 0 0 U S D E D E E E D V
>> > LT7 64000000 1F000000 B3 07F 02 8 B 0
>> > 0 1 U S D E D D E E D V
>> > LT8 E5BF1000 995EA900 96 000 0C D 8 0
>> > 0 1 U S D E E E E D D V
>>=20
>> > LT11 6B000000 F5700000 BC 03F 04 7 D 0
>> > 0 1 P S E E E E E E D V
>> > LT12 712DB000 F1B59100 2A 000 19 C F 1
>> > 0 1 P S E E E E D E D V
>> > LT13 00000000 F0000000 7F 0FF 07 B 0 0
>> > 0 1 P S D D E E E E D V
>> > LT14 A3000000 FDD00000 C5 03F 16 7 E 3
>> > 0 1 P S E E E D D E D V
>> > LT15 F7F00000 B0B80000 82 00F 1F 5 F 0
>> > 0 1 P P E E D D D D D V
>>=20
>> Do you know what the Entry field means? Are you guys putting your
own
>> mappings into the TLB? LT4..LT15 (with VAL =3D V) seem very odd to =
me.
>>=20
>> - k
^ permalink raw reply
* Re: How to debug a hung multi-core system....
From: Kumar Gala @ 2009-05-21 14:45 UTC (permalink / raw)
To: Morrison, Tom; +Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110F53A79@EMPBEDEX.empirix.com>
> [Morrison, Tom]
> >BKM>tat
>
> Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
> PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
>
> LT0 C0000000 00000000 00 0FF 04 9 0 0
> 0 0 P P E E D E E D D V
> LT1 D0000000 01000000 00 0FF 04 9 0 0
> 0 0 P P E E D E E D D V
> LT2 E0000000 02000000 00 0FF 04 9 0 0
> 0 0 P P E E D E E D D V
> LT4 F924E000 7C054500 BA 000 0B E 0 3
> 0 0 P S E E D E E D D V
> LT6 80000000 1F000000 F2 0FF 1D 9 B 3
> 0 0 U S D E D E E E D V
> LT7 64000000 1F000000 B3 07F 02 8 B 0
> 0 1 U S D E D D E E D V
> LT8 E5BF1000 995EA900 96 000 0C D 8 0
> 0 1 U S D E E E E D D V
> LT11 6B000000 F5700000 BC 03F 04 7 D 0
> 0 1 P S E E E E E E D V
> LT12 712DB000 F1B59100 2A 000 19 C F 1
> 0 1 P S E E E E D E D V
> LT13 00000000 F0000000 7F 0FF 07 B 0 0
> 0 1 P S D D E E E E D V
> LT14 A3000000 FDD00000 C5 03F 16 7 E 3
> 0 1 P S E E E D D E D V
> LT15 F7F00000 B0B80000 82 00F 1F 5 F 0
> 0 1 P P E E D D D D D V
Do you know what the Entry field means? Are you guys putting your own
mappings into the TLB? LT4..LT15 (with VAL = V) seem very odd to me.
- k
^ permalink raw reply
* RE: How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-21 13:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <C966FFF1-23FD-4581-A001-79F6961F8E49@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 5573 bytes --]
<see middle post>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Thursday, May 21, 2009 9:13 AM
>> To: Morrison, Tom
>> Cc: linuxppc-dev@ozlabs.org; Young, Andrew; Brown, Jeff
>> Subject: Re: How to debug a hung multi-core system....
>>
>>
>> On May 20, 2009, at 6:17 PM, Morrison, Tom wrote:
[Morrison, Tom]
<snip some verbose explanations>
>> >
>> > Core 1 seems to be Idle loop - happily doing nothing
>> > (and not servicing TCP and/or the console)...
>> >
>> > Core 0 seems to be 'stuck' at the "InstructionStorage"
>> > Exception. And it seems to be going 'nowhere' fast
>> >
>> > SRR0 seems to point to this same spot (0xc00006C0)
>> > SRR1 value is 0x00021200
>> >
>> > I am at a loss to see how the kernel (and/or our kernel BSP)
>> > cause this exception, and I am even more of a loss on figuring
>> > out an application could cause this exception...
>>
>> This is a bit odd as we shouldn't see an ISI from 0xc00006C0.
>>
>> Are you able to single step Core0? Can you dump the contents of the
>> TLBs on Core0
[Morrison, Tom]
[Morrison, Tom]
<snip some of verbose explanation>
Yes, very odd...
And I am able to get TLB entries from the core that is in
Instruction Storage Exception, I made
[Morrison, Tom]
>BKM>tat
Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1 PID TS
PROT SHEN UR UW UX SR SW SX TIDZ VAL
IT0 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
IT1 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
IT2 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
IT3 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
DT0 0011C000 00000000 00 000 06 0 0 0 0
0 U P D D D D D D D I
DT1 D435C000 20000000 00 000 1E 0 0 0 0
0 U P D D D D D D D I
DT2 0011C000 00000000 00 000 06 0 0 0 0
0 U P D D D D D D D I
DT3 D435C000 20000000 00 000 1E 0 0 0 0
0 U P D D D D D D D I
LT0 C0000000 00000000 00 0FF 04 9 0 0 0
0 P P E E D E E D D V
LT1 D0000000 01000000 00 0FF 04 9 0 0 0
0 P P E E D E E D D V
LT2 E0000000 02000000 00 0FF 04 9 0 0 0
0 P P E E D E E D D V
LT3 39A40000 027FF700 0D 000 06 E A 3 0
1 U S D D D E E D D I
LT4 F924E000 7C054500 BA 000 0B E 0 3 0
0 P S E E D E E D D V
LT5 82A9F000 46664C00 FB 000 1A F 4 2 0
0 U S E E D D E D D I
LT6 80000000 1F000000 F2 0FF 1D 9 B 3 0
0 U S D E D E E E D V
LT7 64000000 1F000000 B3 07F 02 8 B 0 0
1 U S D E D D E E D V
LT8 E5BF1000 995EA900 96 000 0C D 8 0 0
1 U S D E E E E D D V
LT9 7F3BF000 C6DF7300 DF 000 15 1 2 3 0
1 U S E D D E E E D I
LT10 917C7000 EEA67F00 7F 000 17 C 5 3 0
1 P S E E E E E E D I
LT11 6B000000 F5700000 BC 03F 04 7 D 0 0
1 P S E E E E E E D V
LT12 712DB000 F1B59100 2A 000 19 C F 1 0
1 P S E E E E D E D V
LT13 00000000 F0000000 7F 0FF 07 B 0 0 0
1 P S D D E E E E D V
LT14 A3000000 FDD00000 C5 03F 16 7 E 3 0
1 P S E E E D D E D V
LT15 F7F00000 B0B80000 82 00F 1F 5 F 0 0
1 P P E E D D D D D V
To answer your 2nd question - we have about 10 processes, and
about 60-70 threads total (30+ for the main processing process)...
>> > Anybody have any ideas - and/or ways to re-configure our
>> > setup to obtain more data? Or does this sound familiar to
>> > a bug somebody has already found in the kernel?
>> >
>> > We are even having trouble defining a test program that can
>> > cause (on purpose) the 'InstructionStorage' Exception (does
>> > anybody have an simple 'c' (or ppc assembly) program that
>> > causes this exception (so we can run in user application land
>> > and see if the symptoms are similar))?
>> >
>> > Thank you in advance for any / all help you can provide....
>> > because I am completely stumped on even how to proceed!
>>
>>
>> Is your application generating a lot of processes or have a lot of
>> concurrent processes on the 8572?
>>
>> - k
[-- Attachment #2: Type: text/html, Size: 28598 bytes --]
^ permalink raw reply
* Re: How to debug a hung multi-core system....
From: Kumar Gala @ 2009-05-21 13:12 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110EFACB2@EMPBEDEX.empirix.com>
On May 20, 2009, at 6:17 PM, Morrison, Tom wrote:
> All,
>
> First off, we turned SPE off completely in our build - so we
> could debug a much deeper problem that seems to be occurring
> in our application (before we try to find a potential test
> case for corruption of GPR registers).
>
> We have had this problem for 3 weeks, and just recently have
> come down to a single test case that makes it fail (although
> extremely complicated test case)...
>
> Setup:
> Master Blade (8548E) with Linux 2.6.23 (and custom BSP)
> Slave Blade (8572E) with Linux 2.6.23 (and similar custom BSP).
>
> The Master Blade works flawlessly (and also works in a slave
> capacity too flawlessly). The single 'slave' 8572E blades
> communicates with the 'master' blade over TCP/IP & PCI Express
> (and is running a similar application)...
>
> Running Single Core on slave 8572E (nosmp option on command line)
> the application works in all conditions (from modestly loaded to
> well oversubscribed/pegged CPU).
>
> In Multi-core option, the application also works flawlessly. The
> problem comes when we oversubscribe our application and push
> this 'slave' blade to the extreme edge of processing (falling
> behind in our processing...etc).
>
> Eventually, sometime between 5-15 minutes, this board becomes
> hung (where the console becomes completely unresponsive and
> you cannot 'ping' the box).
>
> I have a JTAG WindRiver ICE and connect to this blade after it
> is hung, and it appears that both cores are running to some
> extent:
>
> Core 1 seems to be Idle loop - happily doing nothing
> (and not servicing TCP and/or the console)...
>
> Core 0 seems to be 'stuck' at the "InstructionStorage"
> Exception. And it seems to be going 'nowhere' fast
>
> SRR0 seems to point to this same spot (0xc00006C0)
> SRR1 value is 0x00021200
>
> I am at a loss to see how the kernel (and/or our kernel BSP)
> cause this exception, and I am even more of a loss on figuring
> out an application could cause this exception...
This is a bit odd as we shouldn't see an ISI from 0xc00006C0.
Are you able to single step Core0? Can you dump the contents of the
TLBs on Core0
> Anybody have any ideas - and/or ways to re-configure our
> setup to obtain more data? Or does this sound familiar to
> a bug somebody has already found in the kernel?
>
> We are even having trouble defining a test program that can
> cause (on purpose) the 'InstructionStorage' Exception (does
> anybody have an simple 'c' (or ppc assembly) program that
> causes this exception (so we can run in user application land
> and see if the symptoms are similar))?
>
> Thank you in advance for any / all help you can provide....
> because I am completely stumped on even how to proceed!
Is your application generating a lot of processes or have a lot of
concurrent processes on the 8572?
- k
^ permalink raw reply
* Re: [PATCH 3/6] powerpc: add memory map support to Freescale RapidIO block
From: Li Yang @ 2009-05-21 10:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: zw, netdev, linux-kernel, linuxppc-dev, davem
In-Reply-To: <20090512150552.a98dca64.akpm@linux-foundation.org>
On Wed, May 13, 2009 at 6:05 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 12 May 2009 16:36:00 +0800
> Li Yang <leoli@freescale.com> wrote:
>
>> + =C2=A0 =C2=A0 align =3D (size < 0x1000) ? 0x1000 : 1 << (__ilog2(size =
- 1) + 1);
>> +
>> + =C2=A0 =C2=A0 /* Align the size */
>> + =C2=A0 =C2=A0 if ((lstart + size) > (_ALIGN_DOWN(lstart, align) + alig=
n)) {
>
> __ilog2() and _ALIGN_DOWN() are powerpc-specific functions. =C2=A0It woul=
d
> be preferable to use more general helpers if possible. =C2=A0ALIGN() and =
ilog2()
> might suit here.
Will change to use ilog2().
_ALIGN_DOWN() gets a lower aligned address while ALIGN() gets a higher
address. It seems that we don't have a general helper to do the same.
- Leo
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Piotr Zięcik @ 2009-05-21 8:34 UTC (permalink / raw)
To: Grant Likely
Cc: Becky Bruce, Wolfgang Denk, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood
In-Reply-To: <fa686aa40905140700k3ca28ac0m74c9c161ad538abc@mail.gmail.com>
Thursday 14 May 2009 16:00:33 Grant Likely wrote:
> > MPC5121 support was added to drivers/net/fs_enet. MPC52xx uses
> > drivers/net/fec_mpc52xx.c. Do you think that creating one universal
> > driver from these two is now possible? You said that it should be easy,
> > however you also said that cache coherency issues makes this imposible.
>
> Not impossible. Hard.
I thought a bit more about merging FEC drivers and I see one problem more.
Driver fs_enet works with FEC's with own DMA engine and fec_mpc52xx.c uses
BestComm. Integration of these two drivers will need a DMA abstraction layer
to keep everything clean. Unfortuanetly BestComm driver does not provide any
abstraction - it only exports set of functions to deal with specific
hardware: FEC and PATA.
More #ifdef's will be needed to remove linking with BestComm driver if kernel
will be compiled without 52xx support and resulting code will not be much
better than existing one. Especially that new DMA abstraction layer probably
will be quite complex.
--
Best Regards.
Piotr Ziecik
^ permalink raw reply
* Re: next branch update
From: Stephen Rothwell @ 2009-05-21 8:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1242890760.5109.1.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Hi Ben,
On Thu, 21 May 2009 17:26:00 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> I updated my "next" branch with the following patches. If something
> older than a week old is missing (and not already delegated to a
> maintainer on patchwork) please let me know.
Not older than a week, but trivial and has nowhere else to go:
http://patchwork.ozlabs.org/patch/27437/
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* next branch update
From: Benjamin Herrenschmidt @ 2009-05-21 7:26 UTC (permalink / raw)
To: linuxppc-dev list
I updated my "next" branch with the following patches. If something
older than a week old is missing (and not already delegated to a
maintainer on patchwork) please let me know.
Anton Blanchard (1):
powerpc: Improve decrementer accuracy
Anton Vorontsov (6):
powerpc/85xx: Add PCI IDs for MPC8569 family processors
powerpc/85xx: Fix mpc8569emds crypto node to include SNOW unit
powerpc/85xx: Fix reg & interrupts for mpc8569emds localbus added NAND
powerpc/85xx: Add eSDHC support for MPC8569E-MDS boards
powerpc/85xx: Enable Serial RapidIO for MPC85xx MDS boards
powerpc/85xx: Add STMicro M25P40 serial flash support for MPC8569E-MDS
Becky Bruce (3):
powerpc/86xx: Add 36-bit device tree for mpc8641hpcn
powerpc: make dma_window_* in pci_controller struct avail on 32b
powerpc: Use sg->dma_length in sg_dma_len() macro on 32-bit
Geert Uytterhoeven (1):
powerpc: Keep track of emulated instructions
Geoff Levand (1):
powerpc/ps3: Use smp_request_message_ipi
Haiying Wang (7):
powerpc/85xx: clean up for mpc8568_mds name
powerpc/qe: update risc allocation for QE
net/ucc_geth: update riscTx and riscRx in ucc_geth
powerpc/qe: update QE Serial Number
net/ucc_geth: Assign six threads to Rx for UEC
powerpc/85xx: Add MPC8569MDS board support
powerpc/qe: add new qe properties for QE based chips
Jan Blunck (1):
powerpc/spufs: Remove double check for non-negative dentry
Kumar Gala (32):
powerpc/fsl: Remove cell-index from PCI nodes
powerpc: Refactor board check for PCI quirks on FSL boards with uli1575
powerpc/fsl: use of_iomap() for rstcr mapping
powerpc/85xx: Add binding for LAWs and ECM
powerpc/85xx: Add new LAW & ECM device tree nodes for all 85xx systems
powerpc/86xx: Add binding for LAWs and MCM
powerpc/86xx: Add new LAW & MCM device tree nodes for all 86xx systems
powerpc/cpm: Remove some cruft code and defines
powerpc/86xx: clean up smp init code
powerpc/fsl: Removed reg property from 85xx/86xx soc node
fsldma: Fix compile warnings
powerpc/85xx: Add MSI nodes for MPC8568/9 MDS systems
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs
powerpc/fsl_rio: Fix compile warnings
powerpc/fsl: Update FSL esdhc binding
powerpc/85xx: Add P2020DS board support
powerpc/fsl: Setup PCI inbound window based on actual amount of memory
powerpc: Fix up elf_read_implies_exec() usage
powerpc/pci: Clean up direct access to sysdata by indirect ops
powerpc/pci: Clean up direct access to sysdata by FSL platforms
powerpc/pci: Clean up direct access to sysdata by 52xx platforms
powerpc/pci: Clean up direct access to sysdata by 4xx platforms
powerpc/pci: Clean up direct access to sysdata by CHRP platforms
powerpc/pci: Clean up direct access to sysdata on tsi108 platforms
powerpc/pci: Clean up direct access to sysdata by powermac platforms
powerpc/pci: Clean up direct access to sysdata by RTAS
powerpc/pci: Clean up direct access to sysdata by celleb platforms
powerpc/pci: Move pseries code into pseries platform specific area
powerpc/pci: Cleanup some minor cruft
powerpc/pci: Remove redundant pcnet32 fixup
powerpc/pci: clean up direct access to sysdata by iseries platform
Li Yang (2):
powerpc/fsl_rio: use LAW address from device tree
rapidio: fix section mismatch warnings
Michael Ellerman (7):
powerpc/oprofile: Remove unused dump_pmcs() in FSL oprofile
powerpc/irq: Move #ifdef'ed body of do_IRQ() into a separate function
powerpc/irq: Move stack overflow check into a separate function
powerpc/irq: Move get_irq() comment into header
powerpc/irq: Remove fallback to __do_IRQ()
powerpc/powermac: Use generic_handle_irq() in gatwick_action()
powerpc/irq: We don't need __do_IRQ() anymore
Michael Neuling (2):
powerpc: Cleanup macros in ppc-opcode.h
powerpc: Move VSX load/stores into ppc-opcode.h
Milton Miller (2):
powerpc: Enable MMU feature sections for inline asm
powerpc: Add 2.06 tlbie mnemonics
Robert Jennings (1):
powerpc/pseries: CMO unused page hinting
Sean MacLennan (1):
powerpc: Update Warp to use leds-gpio driver
Tony Breeds (1):
powerpc/mpic: Cleanup mpic_find() implementation
Vinay Sridhar (1):
powerpc/xmon: Add dl command to dump contents of __log_buf
^ 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;
as well as URLs for NNTP newsgroup(s).