* Re: [PATCH] powerpc:beyond ARRAY_SIZE of args.args
From: Paul Mackerras @ 2009-05-21 23:10 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton, paulmck
In-Reply-To: <4A15AF33.60100@gmail.com>
Roel Kluin writes:
> Do not go beyond ARRAY_SIZE of args.args
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> I'm quite sure the first is correct, but should maybe `args.nret'
> and `nargs + args.nret' also be `>= ARRAY_SIZE(args.args)'?
I don't think this change is needed, and it changes a user-visible
API, so I'm nacking it unless you can convince me there's really a
problem.
If nargs == ARRAY_SIZE(args.args), then args.nret must be zero, so
nothing will access *(args.rets).
Paul.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Ian Campbell @ 2009-05-21 22:08 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4A15B72E.2070202@goop.org>
On Thu, 2009-05-21 at 16:18 -0400, Jeremy Fitzhardinge wrote:
> I guess the test is checking for a bad implementation of map_single().
More importantly the io_tlb_overflow_buffer is basically a second chance
if you exhaust the swiotlb pool. The check seems to be there to ensure
that the second chance memory is suitable for the device (it's hard to
imagine, but possible I suppose, that it wouldn't be), a bad
implementation of map_single() is a secondary concern I suspect.
If all the callers of map_page did proper error handling this would all
be unnecessary. I guess someone was worried, at least at one point, that
they didn't. The failure case could possibly be scribbling into a random
memory location or more worryingly sprinkling random memory locations
onto your disk or whatever. That said I'd imagine that map_page
returning NULL would cause an oops long before anything tried to DMA
anything and the second chance probably doesn't buy us much in practice.
Ian.
^ permalink raw reply
* Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
From: Roderick Colenbrander @ 2009-05-21 20:31 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20090521165008.A020D710053@mail54-sin.bigfish.com>
Hi Stephen,
Grant forgot to attach the dts file (but a next patch will add it).
The dts file contains some lines for the pci bus mapping. The lines
are attached below. For pci support I'm using the reference bsb with
pci 'ML510 BSB1 Pcores Design' for PowerPC at:
http://www.xilinx.com/products/boards/ml510/ml510_10.1_3_1/bsb.htm.
The patch also contains a tutorial on how to add pci yourself.
As I mention in the comment of the plbv46_pci stuff C_IPIFBAR2PCIBAR_0
is not set correctly. Benjamin Herrenschmidt told me that inbound and
outbound pci transactions shouldn't overlap. With the value at ipif
plb 0xa0000000 maps to 0 on the pci side while the pci soft-core also
thinks that 0 maps to address 0 of the system memory. Setting
C_IPIFBAR2PCIBAR_0 to e.g. 0xa0000000 like I'm doing maps ipif plb
0xa0000000 to 0xa0000000 on the pci side and prevents this confusion.
The same is also wrong in the guides for the ml410.
Could you forward it to the right people so that this can get fixed?
No other changes are needed except for this one.
Roderick
+ plbv46_pci_0: plbv46-pci@85e00000 {
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "xlnx,plbv46-pci-1.03.a";
+ device_type = "pci";
+ reg = < 0x85e00000 0x10000 >;
+ /* The default ML510 BSB has
C_IPIFBAR2PCIBAR_0 set to 0 which means that a read/write to
+ * the memory mapped i/o region (which starts
at 0xa0000000) for pci bar 0 on the plb side
+ * translates to 0.
+ * It is important to this value to
0xa0000000, so that inbound and outbound pci transactions
+ * work properly including DMA.
+ */
+ ranges = <0x02000000 0x00000000 0xa0000000
0xa0000000 0x00000000 0x20000000
+ 0x01000000 0x00000000 0x00000000
0xf0000000 0x00000000 0x00010000>;
+
+ #interrupt-cells = <1>;
+ interrupt-parent = <&xps_intc_0>;
+ interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IRQ mapping for pci slots and ALI
M1533 periperhals. In total there are
+ * 5 interrupt lines connected to a
xps_intc controller. Four of them are PCI
+ * IRQ A, B, C, D and which correspond
to respectively xpx_intc 5, 4, 3 and 2.
+ * The fifth interrupt line is
connected to the south bridge and this one
+ * uses irq 1 and is active high
instead of active low.
+ *
+ * The M1533 contains various
peripherals including AC97 audio, a modem, USB,
+ * IDE and some power management
stuff. The modem isn't connected on the ML510
+ * and the power management core also
isn't used.
+ */
+
+ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
+ 0x3000 0 0 1 &xps_intc_0 3 2
+ 0x3000 0 0 2 &xps_intc_0 2 2
+ 0x3000 0 0 3 &xps_intc_0 5 2
+ 0x3000 0 0 4 &xps_intc_0 4 2
+
+ /* IDSEL 0x13 / dev=3, bus=1 / PCI slot 4 */
+ /*
+ 0x11800 0 0 1 &xps_intc_0 5 0 2
+ 0x11800 0 0 2 &xps_intc_0 4 0 2
+ 0x11800 0 0 3 &xps_intc_0 3 0 2
+ 0x11800 0 0 4 &xps_intc_0 2 0 2
+ */
+
+ /* According to the datasheet +
schematic ABCD [FPGA] of slot 5 is mapped to DABC.
+ * Testing showed that at least A maps
to B, the mapping of the other pins is a guess
+ * and for that reason the lines have
been commented.
+ */
+ /* IDSEL 0x15 / dev=5, bus=0 / PCI slot 5 */
+ 0x2800 0 0 1 &xps_intc_0 4 2
+ /*
+ 0x2800 0 0 2 &xps_intc_0 3 2
+ 0x2800 0 0 3 &xps_intc_0 2 2
+ 0x2800 0 0 4 &xps_intc_0 5 2
+ */
+
+ /* IDSEL 0x12 / dev=2, bus=1 / PCI slot 6 */
+ /*
+ 0x11000 0 0 1 &xps_intc_0 4 0 2
+ 0x11000 0 0 2 &xps_intc_0 3 0 2
+ 0x11000 0 0 3 &xps_intc_0 2 0 2
+ 0x11000 0 0 4 &xps_intc_0 5 0 2
+ */
+
+ /* IDSEL 0x11 / dev=1, bus=0 / AC97 audio */
+ 0x0800 0 0 1 &i8259 7 2
+
+ /* IDSEL 0x1b / dev=11, bus=0 / IDE */
+ 0x5800 0 0 1 &i8259 14 2
+
+ /* IDSEL 0x1f / dev 15, bus=0 / 2x USB 1.1 */
+ 0x7800 0 0 1 &i8259 7 2
+ >;
+ ali_m1533 {
+ #size-cells = <1>;
+ #address-cells = <2>;
+ i8259: interrupt-controller@20 {
+ reg = <1 0x20 2
+ 1 0xa0 2
+ 1 0x4d0 2>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ compatible = "chrp,iic";
+
+ /* The south bridge connection
is active high */
+ interrupts = <1 3>;
+ interrupt-parent = <&xps_intc_0>;
+ };
+ };
+ } ;
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Jeremy Fitzhardinge @ 2009-05-21 20:18 UTC (permalink / raw)
To: Becky Bruce; +Cc: FUJITA Tomonori, linuxppc-dev, linux-kernel, Ian Campbell
In-Reply-To: <E6DAA792-9923-4B76-9759-6955AABE3EAB@kernel.crashing.org>
Becky Bruce wrote:
> 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?
The Xen implementation would needs to do the phys to bus conversion page
by page anyway, so it wouldn't help much. But it also wouldn't hurt.
How expensive is the phys-to-bus conversion on power? Is it worth
making the interface more complex for? Would passing phys+bus mean that
we wouldn't also need to pass dev?
> 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?
It called them together a little earlier in the function, and the phys
address is still available.
I guess the test is checking for a bad implementation of map_single().
I found a single instance of someone reporting the message (in 2.6.11,
when swiotlb was ia64-specific: http://lkml.org/lkml/2008/3/3/249).
panic() is an odd way to handle an error (even an one which is an
implementation bug), but I guess it's better than scribbling on the
wrong memory.
J
^ permalink raw reply
* Re: ipr boot failure caused by MSI (2.6.30-rc1+)
From: James Bottomley @ 2009-05-21 19:51 UTC (permalink / raw)
To: Brian King; +Cc: ppc-dev, Wayne Boyer, linux-scsi
In-Reply-To: <4A15A1B2.8060609@linux.vnet.ibm.com>
On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote:
> 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
OK, so as an update, I booted to the initrd and inserted the network
modules, which are also MSI enabled and this is what I get:
(initramfs) cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 14 11 11 18 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
22: 1 0 1 0 MPIC-U3MSI Edge eth0
23: 0 2 1 0 MPIC-U3MSI Edge eth1
68: 193 166 113 177 MPIC Edge serial
251: 16 65 71 70 MPIC Edge ipi call function
252: 1574 1804 1346 1289 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: 1866
So clearly the MSI interrupts to the network cards are working and it
looks like just a local problem with the ipr rather than a platform
problem with MSI.
James
^ permalink raw reply
* Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
From: Grant Likely @ 2009-05-21 19:58 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090521165008.A020D710053@mail54-sin.bigfish.com>
On Thu, May 21, 2009 at 10:50 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>> 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
>> =A0# =A0 =A0 =A0This option enables support for the IBM PPC440GX evaluat=
ion
> board.
>>
>> =A0config XILINX_VIRTEX440_GENERIC_BOARD
>> - =A0 =A0 bool "Generic Xilinx Virtex 440 board"
>> + =A0 =A0 bool "Xilinx Virtex 5 support"
>
> 'Virtex 5' is a little ambiguous.. =A0I'd suggest keeping the old wording=
,
> or saying 'Virtex 5 FXT support'. =A0Even then it's somewhat ambiguous,
> since you could conceivably run linux on microblaze on V5FXT and use the
> powerpc for something else..
Considering that this option only appears when AMCC 44x is selected, I
think the ambiguity is minimal. :-)
I'll add the FXT though.
>> 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?
Oops; I started writing a comment and then never completed it.
Roderick; care to contribute some lines as to the purpose of this
block?
>> 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)
>> =A0 =A0 =A0 i8259_init(cascade_node, 0);
>> =A0 =A0 =A0 set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
>>
>> + =A0 =A0 /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive *=
/
>> + =A0 =A0 /* This looks like a dirty hack to me --gcl */
>> + =A0 =A0 outb(0xc0, 0x4d0);
>> + =A0 =A0 outb(0xc0, 0x4d1);
>> +
>
> Yeow... I agree about the dirty hack part... =A0shouldn't this be in the
> device tree somewhere, or in the ali driver?
Chatting with Roderick on IRC today, it may be that these two lines
aren't even necessary. They come from an old guide for porting Linux
to the ml410 in the pre-arch/powerpc days. Now that IRQ sense is
encoded into the device tree, this probably isn't needed.
> I'm curious if this works on ml410 as well.. =A0(Yes, I know, does this
> really matter much? =A0But there are still a bunch of them floating aroun=
d
> in universities.)
It should do (at least I hope it does). If I get my hands on an
ML410, then I'll try it out.
> =A0It may be nice to factor this out so ml410/ppc405 and
> microblaze can get it as well.
indeed.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] KVM: powerpc: beyond ARRAY_SIZE of vcpu->arch.guest_tlb
From: Roel Kluin @ 2009-05-21 19:53 UTC (permalink / raw)
To: avi, paulmck; +Cc: linuxppc-dev, Andrew Morton, kvm
Do not go beyond ARRAY_SIZE of vcpu->arch.guest_tlb
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 0fce4fb..c2cfd46 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -125,7 +125,7 @@ static int kvmppc_emul_tlbwe(struct kvm_vcpu *vcpu, u32 inst)
ws = get_ws(inst);
index = vcpu->arch.gpr[ra];
- if (index > PPC44x_TLB_SIZE) {
+ if (index >= PPC44x_TLB_SIZE) {
printk("%s: index %d\n", __func__, index);
kvmppc_dump_vcpu(vcpu);
return EMULATE_FAIL;
^ permalink raw reply related
* [PATCH] powerpc:beyond ARRAY_SIZE of args.args
From: Roel Kluin @ 2009-05-21 19:44 UTC (permalink / raw)
To: paulmck; +Cc: linuxppc-dev, Andrew Morton
Do not go beyond ARRAY_SIZE of args.args
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
I'm quite sure the first is correct, but should maybe `args.nret'
and `nargs + args.nret' also be `>= ARRAY_SIZE(args.args)'?
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 1f8505c..c94ab76 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -779,7 +779,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
return -EFAULT;
nargs = args.nargs;
- if (nargs > ARRAY_SIZE(args.args)
+ if (nargs >= ARRAY_SIZE(args.args)
|| args.nret > ARRAY_SIZE(args.args)
|| nargs + args.nret > ARRAY_SIZE(args.args))
return -EINVAL;
^ permalink raw reply related
* 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
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