Re: DTS file PCI / i8259 for Xilinx ML510
At some point in the file they create some (dummy?) pcie section in which they define a uli1575, an isa bus and attached to that isa bus a i8259. Is this the correct way of doing things? The i8259 driver seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined below but how are those mapped to the south bridge? I have seen some code in kernel/isa-bridge, is that code indeed responsible for setting up these ports? Yes, the pcie node is the PCI host bridge node and the uli1571 node acts as PCI2ISA bridge node. AFAIK their ranges properties are parsed by pci_process_bridge_OF_ranges(). IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only for now. The I/O addresses for the i8259 PIC are currently hardcoded and setup (request_resource()) in sysdev/i8259.c. I got the i8259 south bridge working now after adding an io_base_virt offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all the troubles to add ppc32 support to isa-bridge.c? The whole point of the code is basically to remap the io memory to low addresses for these 64-bit ppc systems (mainly freescale boards with a i8259 and pseries systems with a i8259). As far as I have seen it is only needed for i8259 interrupt controllers. Personally I think it would be better to pass a io base offset to i8259_setup or so. Or perhaps do some dts file parsing in i8259.c. I'm not sure what the proper layout would be for this in the dts file though. With those changes I mentioned to i8259.c I got some PCI devices of my ali m1553 south bridge working. The code is ugly and I need to do cleanups. When it is done I will submit some patches. Regards, Roderick Colenbrander -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS file PCI / i8259 for Xilinx ML510
Original-Nachricht Datum: Sun, 15 Mar 2009 09:38:26 +0100 Von: Roderick Colenbrander thunderbir...@gmx.net An: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@ozlabs.org Betreff: Re: DTS file PCI / i8259 for Xilinx ML510 At some point in the file they create some (dummy?) pcie section in which they define a uli1575, an isa bus and attached to that isa bus a i8259. Is this the correct way of doing things? The i8259 driver seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined below but how are those mapped to the south bridge? I have seen some code in kernel/isa-bridge, is that code indeed responsible for setting up these ports? Yes, the pcie node is the PCI host bridge node and the uli1571 node acts as PCI2ISA bridge node. AFAIK their ranges properties are parsed by pci_process_bridge_OF_ranges(). IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only for now. The I/O addresses for the i8259 PIC are currently hardcoded and setup (request_resource()) in sysdev/i8259.c. I got the i8259 south bridge working now after adding an io_base_virt offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all the troubles to add ppc32 support to isa-bridge.c? The whole point of the code is basically to remap the io memory to low addresses for these 64-bit ppc systems (mainly freescale boards with a i8259 and pseries systems with a i8259). pci_process_bridge_OF_ranges() should ioremap io_base_virt for you, if your board has only one PCI I/O space. It also sets isa_io_base to io_base_virt on PPC32, but expects that the ISA I/O space is mapped to PCI I/O address 0x0. Isn't that the case for your board? As far as I have seen it is only needed for i8259 interrupt controllers. Personally I think it would be better to pass a io base offset to i8259_setup or so. Or perhaps do some dts file parsing in i8259.c. I'm not sure what the proper layout would be for this in the dts file though. I think adding an io base offset parameter to i8259_setup isn't the right way to do it. I would expect other problems too, if ISA I/O space isn't mapped 1:1 to PCI I/O space on a PPC32 system. Maybe a more experienced kernel developer can comment on this? With those changes I mentioned to i8259.c I got some PCI devices of my ali m1553 south bridge working. The code is ugly and I need to do cleanups. When it is done I will submit some patches. IMHO that doesn't matter, as long as it helps people to understand your problem. :-) regards, Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS file PCI / i8259 for Xilinx ML510
I got the i8259 south bridge working now after adding an io_base_virt offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all the troubles to add ppc32 support to isa-bridge.c? The whole point of the code is basically to remap the io memory to low addresses for these 64-bit ppc systems (mainly freescale boards with a i8259 and pseries systems with a i8259). pci_process_bridge_OF_ranges() should ioremap io_base_virt for you, if your board has only one PCI I/O space. It also sets isa_io_base to io_base_virt on PPC32, but expects that the ISA I/O space is mapped to PCI I/O address 0x0. Isn't that the case for your board? Ah then perhaps that is my problem. I'm using my own pci implementation for Xilinx their plbv46 soft core. The soft core might be compatible with a generic ibm plb-pci bridge (sysdev/ppc44x_pci.c). Basically I'm doing something like which is done in powermac/pci.c e.g. creating the pci_controller and filling it with cfg_addr / cfg_data pointers, io ranges, resource ranges and so on. The data is obtained from the dts file but from some xilinx generated fields and doesn't have the generic ranges fields and some others. I guess it is time to fix this part of the DTS file. Some other issue I had which might be related to my DTS file bugs is some i/o port conflict. The M1553 south bridge is just a peripheral on the ML510 primary pci bus there are no PCI slots connected to it. There are four other pci slots of which two are directly connected to the fpga (they are on the same bus as the M1553) and two are connected using a pci-to-pci bridge because they use 5V instead of 3.3V. The bridge chip wanted 0x0-0xfff while some south bridge devices wanted low addresses (if I remember correctly the IDE controller wants 0x1f0-0x1f1 and some 0x3** ports). This generated some Cannot allocate resource region .. will remap messages from kernel/pci-common.c. This remapping didn't happen. Should a proper DTS file prevent this issue? If not where is the remapping done (I didn't see it). For that reason I'm ignoring the pci-to-pci bridge for now. Thanks, Roderick Colenbrander -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Remove extra semicolon in fsl_soc.c (2nd try)
TSEC/MDIO will not work with older device trees because of a semicolon at the end of a macro resulting in an empty for loop body. This fix only applies to 2.6.28; this code is gone in 2.6.29, according to Grant Likely! Signed-off-by: Johns Daniel johns.dan...@gmail.com mailto:johns.dan...@gmail.com == --- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig 2009-02-20 16:41:27.0 -0600 +++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c2009-03-14 09:01:38.994630400 -0500 @@ -257,7 +257,7 @@ static int __init gfar_mdio_of_init(void gfar_mdio_of_init_one(np); /* try the deprecated version */ - for_each_compatible_node(np, mdio, gianfar); + for_each_compatible_node(np, mdio, gianfar) gfar_mdio_of_init_one(np); return 0; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS file PCI / i8259 for Xilinx ML510
Original-Nachricht Datum: Sun, 15 Mar 2009 12:00:17 +0100 Von: Roderick Colenbrander thunderbir...@gmx.net An: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@ozlabs.org Betreff: Re: DTS file PCI / i8259 for Xilinx ML510 I got the i8259 south bridge working now after adding an io_base_virt offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all the troubles to add ppc32 support to isa-bridge.c? The whole point of the code is basically to remap the io memory to low addresses for these 64-bit ppc systems (mainly freescale boards with a i8259 and pseries systems with a i8259). pci_process_bridge_OF_ranges() should ioremap io_base_virt for you, if your board has only one PCI I/O space. It also sets isa_io_base to io_base_virt on PPC32, but expects that the ISA I/O space is mapped to PCI I/O address 0x0. Isn't that the case for your board? Ah then perhaps that is my problem. I'm using my own pci implementation for Xilinx their plbv46 soft core. The soft core might be compatible with a generic ibm plb-pci bridge (sysdev/ppc44x_pci.c). Basically I'm doing something like which is done in powermac/pci.c e.g. creating the pci_controller and filling it with cfg_addr / cfg_data pointers, io ranges, resource ranges and so on. The data is obtained from the dts file but from some xilinx generated fields and doesn't have the generic ranges fields and some others. I guess it is time to fix this part of the DTS file. I don't know much about this plb2pci bridge, but if you take a look at ppc4xx_probe_pci_bridge() in sysdev/ppc4xx_pci.c, you'll see that it calls pci_process_bridge_OF_ranges() too. Thus the ranges properties are required to setup PCI correctly. Some other issue I had which might be related to my DTS file bugs is some i/o port conflict. The M1553 south bridge is just a peripheral on the ML510 primary pci bus there are no PCI slots connected to it. There are four other pci slots of which two are directly connected to the fpga (they are on the same bus as the M1553) and two are connected using a pci-to-pci bridge because they use 5V instead of 3.3V. The bridge chip wanted 0x0-0xfff while some south bridge devices wanted low addresses (if I remember correctly the IDE controller wants 0x1f0-0x1f1 and some 0x3** ports). This generated some Cannot allocate resource region .. The I/O ports within 0x0-0xfff are somehow reserved for legacy ISA devices (in the M1553 southbridge), if I remember the PCI spec correctly. That will conflict with the PCI2PCI bridge anyway, if both claim PCI I/O transactions for this range. I guess you have to relocate the PCI I/O window of the PCI2PCI bridge. will remap messages from kernel/pci-common.c. This remapping didn't happen. Should a proper DTS file prevent this issue? If not where is the remapping done (I didn't see it). For that reason I'm ignoring the pci-to-pci bridge for now. AFAIK bridge windows are not relocated. The firmware should setup them correctly. Also, you don't have to add the PCI2PCI bridge to the DTS, if the bridge uses the standardized register set to define the I/O and memory windows. A general rule (for PCI) is to only define the information that cannot be probed by the kernel itself. regards, Gerhard -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: use generic pci_assign_unassign_resources
On Fri, 2009-03-13 at 16:42 -0600, Mark Takatz wrote: Ben, We're looking at the fixes you put in place for the various PCI errors and we think this is the solution we need for our system, a GE Fanuc CM6 PPC board (single 8641), but your patches appear to apply either to 2.6.24 or 2.6.25, and we have 2.6.23. Do you know of any similar work done on the 2.6.23 release? Thanks in advance for any help you can provide, No, you would have to backport major chunks of the PCI rework I did in between, along with fixes I did after that. At this stage I would recommend considering an update to 2.6.27 or 2.6.28. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
On Sat, 2009-03-14 at 09:58 -0500, Ryan Arnold wrote: We can do some VMX testing on existing POWER6 machines. The VSX instruction set hasn't been fully implemented in GCC yet so we'll need to wait a bit for that. Does anyone have an idea for a good VMX/Altivec benchmark? Note that there are two aspects to the problem: - Lazy save/restore on SMP. This would avoid both the save and restore phases, thus is where the most potential gain is to be made. At the expense of some tricky IPI work when processes migrate between CPUs. However, it will only be useful -if- a process using FP/VMX/VSX is interrupted by another process that isn't using them. For example, a kernel thread. So it's unclear whether that's worth it in practice, ie, does this happen that often ? - Always restoring the FP/VMX/VSX state on context switch in rather than taking a fault. This is reasonably simple, but at the potential expense of adding the save/restore overhead to applications that only seldomly use these facilities. (Some heuristics might help here). However, the question here what do this buy us ? IE, In the worst case scenario, which is HZ=1000, so every 1ms, the process would have the overhead of an interrupt to do the restore of the state. IE. The restore state itself doesn't count since it would be done either way (at context switch vs. in the unavailable interrupt), so all we win here is the overhead of the actual interrupt, which is implemented as a fast interrupt in assembly. So we have what here ? 1000 cycles to be pessimistic ? On a 1Ghz CPU, that is 1/1000 of the time slice, and both of these are rather pessimistic numbers. So that leaves us with the possible case of 2 tasks using the facility and running a fraction of the timeslice each, for example because they are ping-ponging with each other. Is that something that happens in practice to make it noticeable ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] cpumask: use mm_cpumask() wrapper: powerpc
Makes code futureproof against the impending change to mm-cpu_vm_mask.
It's also a chance to use the new cpumask_ ops which take a pointer
(the older ones are deprecated, but there's no hurry for arch code).
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
arch/powerpc/include/asm/mmu_context.h |2 +-
arch/powerpc/mm/hash_utils_64.c| 10 --
arch/powerpc/mm/mmu_context_nohash.c |2 +-
arch/powerpc/mm/pgtable.c |3 +--
arch/powerpc/mm/tlb_hash64.c |6 +++---
arch/powerpc/mm/tlb_nohash.c | 18 +-
arch/powerpc/platforms/cell/spu_base.c |2 +-
7 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -31,7 +31,7 @@ static inline void switch_mm(struct mm_s
struct task_struct *tsk)
{
/* Mark this context has been used on the new CPU */
- cpu_set(smp_processor_id(), next-cpu_vm_mask);
+ cpumask_set_cpu(smp_processor_id(), mm_cpumask(next));
/* 32-bit keeps track of the current PGDIR in the thread struct */
#ifdef CONFIG_PPC32
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -858,7 +858,7 @@ int hash_page(unsigned long ea, unsigned
unsigned long vsid;
struct mm_struct *mm;
pte_t *ptep;
- cpumask_t tmp;
+ const struct cpumask *tmp;
int rc, user_region = 0, local = 0;
int psize, ssize;
@@ -906,8 +906,8 @@ int hash_page(unsigned long ea, unsigned
return 1;
/* Check CPU locality */
- tmp = cpumask_of_cpu(smp_processor_id());
- if (user_region cpus_equal(mm-cpu_vm_mask, tmp))
+ tmp = cpumask_of(smp_processor_id());
+ if (user_region cpumask_equal(mm_cpumask(mm), tmp))
local = 1;
#ifdef CONFIG_HUGETLB_PAGE
@@ -1023,7 +1023,6 @@ void hash_preload(struct mm_struct *mm,
unsigned long vsid;
void *pgdir;
pte_t *ptep;
- cpumask_t mask;
unsigned long flags;
int local = 0;
int ssize;
@@ -1066,8 +1065,7 @@ void hash_preload(struct mm_struct *mm,
local_irq_save(flags);
/* Is that local to this CPU ? */
- mask = cpumask_of_cpu(smp_processor_id());
- if (cpus_equal(mm-cpu_vm_mask, mask))
+ if (cpumask_equal(mm_cpumask(mm), cpumask_of(smp_processor_id(
local = 1;
/* Hash it in */
diff --git a/arch/powerpc/mm/mmu_context_nohash.c
b/arch/powerpc/mm/mmu_context_nohash.c
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -97,7 +97,7 @@ static unsigned int steal_context_smp(un
mm-context.id = MMU_NO_CONTEXT;
/* Mark it stale on all CPUs that used this mm */
- for_each_cpu_mask_nr(cpu, mm-cpu_vm_mask)
+ for_each_cpu(cpu, mm_cpumask(mm))
__set_bit(id, stale_map[cpu]);
return id;
}
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -81,11 +81,10 @@ void pgtable_free_tlb(struct mmu_gather
void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
{
/* This is safe since tlb_gather_mmu has disabled preemption */
-cpumask_t local_cpumask = cpumask_of_cpu(smp_processor_id());
struct pte_freelist_batch **batchp = __get_cpu_var(pte_freelist_cur);
if (atomic_read(tlb-mm-mm_users) 2 ||
- cpus_equal(tlb-mm-cpu_vm_mask, local_cpumask)) {
+ cpumask_equal(mm_cpumask(tlb-mm), cpumask_of(smp_processor_id({
pgtable_free(pgf);
return;
}
diff --git a/arch/powerpc/mm/tlb_hash64.c b/arch/powerpc/mm/tlb_hash64.c
--- a/arch/powerpc/mm/tlb_hash64.c
+++ b/arch/powerpc/mm/tlb_hash64.c
@@ -139,12 +139,12 @@ void hpte_need_flush(struct mm_struct *m
*/
void __flush_tlb_pending(struct ppc64_tlb_batch *batch)
{
- cpumask_t tmp;
+ const struct cpumask *tmp;
int i, local = 0;
i = batch-index;
- tmp = cpumask_of_cpu(smp_processor_id());
- if (cpus_equal(batch-mm-cpu_vm_mask, tmp))
+ tmp = cpumask_of(smp_processor_id());
+ if (cpumask_equal(mm_cpumask(batch-mm), tmp))
local = 1;
if (i == 1)
flush_hash_page(batch-vaddr[0], batch-pte[0],
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -132,11 +132,11 @@ void flush_tlb_mm(struct mm_struct *mm)
pid = mm-context.id;
if (unlikely(pid == MMU_NO_CONTEXT))
goto no_context;
- cpu_mask
Re: DTS device tree node for dual port RAM
On Thu, Mar 12, 2009 at 9:19 AM, EXTERNAL Lange Matthias (AA-DGW/ENG1)
matthias.la...@beissbarth.com wrote:
What hardware irq# are you using? See this link for a description of
what the interrupts property should look like for external IRQs:
I am using hardware irq# 0 which is wired to the critical input line. That's
why I was defining the interrupts property to 0 0 0. So my device tree node
now looks like this
Okay, good. I just wanted to make sure.
dp...@4000 {
compatible = beissbarth,orion-dpram;
interrupts = 0 0 0;
interrupt-parent = mpc5200_pic;
};
This is unrelated to your question, but I'm wondering why you don't
have a reg property in your node.
If I am understanding it correctly I now need to implement a OF platform
driver in which I can use irq_of_parse_and_map() to get the virq for my
device.
That is the easiest way, yes. Actually, all you need to call
irq_of_parse_and_map() is a pointer to the device_node which can be
obtained by directly searching the tree. However, writing an
of_platform driver is a better way to get the device_node in this
case.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
Hi Mark, Could you please let me know how you booted the latest Linux kernel on MPC8313ERDB board ? ? ? As I tried but was not successful. It hangs or does nothing and waits at network configuration, mean to determine IP address (as I have used dhcp). Kindly please acknowledge ... thank you ... Kind Regards, Vijay Nikam On 3/11/09, Mark Bishop m...@bish.net wrote: Quoting Scott Wood scottw...@freescale.com: On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote: Yes I have actually. I have booted a 2.6.28.6. Same problem. I've booted many recent kernels on revA 8313ERDB; networking works fine. I'll try 2.6.28.6 specifically, though u-boot is acting up at the moment so I have to address that first. :-( Are you using the stock config and device tree from 2.6.28.6, or have you made any changes? Also, is it me but at some point from 2.6.23 to 2.6.28 did they started using hex numbers in the .dts file for interrupts = without the 0x preamble? Yes. dts version 0 had hex by default (with OF-like radix prefixes), and version 1 (indicated by /dts-v1/; at the top of the file) has decimal by default (with C-like radix prefixes). I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this board and .28 looked way different in the interrupt section for the eTSEC. Quoting Kumar Gala ga...@kernel.crashing.org: Please don't top-post. The boards we received didn't have SPI compiled into the kernel and when we went to go re-compile the kernel using the 20081222 and 20080711 BSPs. I realize that the interrupts were reversed for eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no longer hang when I ping, etc. But I still can't get the board on the network. I've verified it isn't the network settings. You're sure you're not trying to talk to the switch (which will claim link-up regardless of what's plugged into it)? The non-switch ethernet port is eTSEC2. What *does* it do when you ping, if neither hang nor work? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev After remapping the IRQs, it is working now. Any idea on what I need to do to get SPI working? I've compiled it into the kernel but don't see anything in /proc/bus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
