[PATCH] powerpc: Set paca-data_offset = 0 for boot cpu
In commit 407821a we assigned a poison value to the paca-data_offset. Unfortunately with CONFIG_LOCK_STAT=y lockdep will read write to percpu data very early in boot, prior to us initialising the percpu areas, leading to a crash. We have been getting away with this because the data_offset was previously set to zero. This causes lockdep to read write to the initial copy of the percpu variables, which are discarded later in boot. Although that is fishy, it does work, and for lock statistics it is no big deal to discard the counts from early boot. So set the paca-data_offset = 0 for the boot cpu paca only. Reported-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- arch/powerpc/kernel/setup_64.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index 389bd4f..efb6a41 100644 --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -208,6 +208,8 @@ void __init early_setup(unsigned long dt_ptr) /* Fix up paca fields required for the boot cpu */ get_paca()-cpu_start = 1; + /* Allow percpu accesses to work until we setup percpu data */ + get_paca()-data_offset = 0; /* Probe the machine type */ probe_machine(); -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Remove tlb batching hack for nighthawk
In hpte_init_native() we call tlb_batching_enabled() to decide if we
should setup ppc_md.flush_hash_range.
tlb_batching_enabled() checks the _unflattened_ device tree, to see
if we are running on a nighthawk.
Since commit a223535 (dont allow pSeries_probe to succeed without
initialising MMU, Dec 2006), hpte_init_native() has been called from
pSeries_probe() - at which point we have not yet unflattened the
device tree.
This means tlb_batching_enabled() will always return true, so the hack
has effectively been disabled since Dec 2006. Ergo, I think we can
drop it.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/mm/hash_native_64.c | 26 +-
1 file changed, 1 insertion(+), 25 deletions(-)
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index f21e8ce..60c21a8 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -539,29 +539,6 @@ static void native_flush_hash_range(unsigned long number,
int local)
local_irq_restore(flags);
}
-#ifdef CONFIG_PPC_PSERIES
-/* Disable TLB batching on nighthawk */
-static inline int tlb_batching_enabled(void)
-{
- struct device_node *root = of_find_node_by_path(/);
- int enabled = 1;
-
- if (root) {
- const char *model = of_get_property(root, model, NULL);
- if (model !strcmp(model, IBM,9076-N81))
- enabled = 0;
- of_node_put(root);
- }
-
- return enabled;
-}
-#else
-static inline int tlb_batching_enabled(void)
-{
- return 1;
-}
-#endif
-
void __init hpte_init_native(void)
{
ppc_md.hpte_invalidate = native_hpte_invalidate;
@@ -570,6 +547,5 @@ void __init hpte_init_native(void)
ppc_md.hpte_insert = native_hpte_insert;
ppc_md.hpte_remove = native_hpte_remove;
ppc_md.hpte_clear_all = native_hpte_clear;
- if (tlb_batching_enabled())
- ppc_md.flush_hash_range = native_flush_hash_range;
+ ppc_md.flush_hash_range = native_flush_hash_range;
}
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Set paca-data_offset = 0 for boot cpu
Michael Ellerman mich...@ellerman.id.au writes: In commit 407821a we assigned a poison value to the paca-data_offset. Unfortunately with CONFIG_LOCK_STAT=y lockdep will read write to percpu data very early in boot, prior to us initialising the percpu areas, leading to a crash. We have been getting away with this because the data_offset was previously set to zero. This causes lockdep to read write to the initial copy of the percpu variables, which are discarded later in boot. Although that is fishy, it does work, and for lock statistics it is no big deal to discard the counts from early boot. So set the paca-data_offset = 0 for the boot cpu paca only. Reported-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Signed-off-by: Michael Ellerman mich...@ellerman.id.au Tested-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- arch/powerpc/kernel/setup_64.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index 389bd4f..efb6a41 100644 --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -208,6 +208,8 @@ void __init early_setup(unsigned long dt_ptr) /* Fix up paca fields required for the boot cpu */ get_paca()-cpu_start = 1; + /* Allow percpu accesses to work until we setup percpu data */ + get_paca()-data_offset = 0; /* Probe the machine type */ probe_machine(); -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
On 08/10/2012 09:27 AM, Arnd Bergmann wrote:
On Friday 10 August 2012, Chunhe Lan wrote:
+static inline void mmc_delay(unsigned int ms)
+{
+ if (ms 1000 / HZ) {
+ cond_resched();
+ mdelay(ms);
+ } else {
+ msleep(ms);
+ }
+}
I would actually question the point in this function to start with: The
decision whether to call mdelay() or msleep() should only be based on
whether you are allowed to sleep in the caller context. The idea of
cond_resched();
mdelay(ms);
sets off alarm bells, and I would always replace that with msleep().
I think that it does not replace with msleep().
When the time of sleep is very short, program should not been scheduled
in the context. Because it expends the more time.
Thanks,
Chunhe
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] arch/powerpc: Don't release eeh_mutex in eeh_phb_pe_get
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
=
[ BUG: bad unlock balance detected! ]
3.6.0-rc5-00338-gcaa1d63-dirty #6 Not tainted
-
swapper/0/1 is trying to release lock (eeh_mutex) at:
[c0058218] .eeh_add_to_parent_pe+0x318/0x410
but there are no more locks to release!
other info that might help us debug this:
no locks held by swapper/0/1.
stack backtrace:
Call Trace:
[c0003e483870] [c0013310] .show_stack+0x70/0x1c0 (unreliable)
[c0003e483920] [c00d8310] .print_unlock_inbalance_bug+0x110/0x120
[c0003e4839b0] [c00d9a50] .lock_release+0x1d0/0x240
[c0003e483a60] [c0778064] .__mutex_unlock_slowpath+0xb4/0x250
[c0003e483b10] [c0058218] .eeh_add_to_parent_pe+0x318/0x410
[c0003e483bc0] [c005a118] .pseries_eeh_of_probe+0x258/0x2f0
[c0003e483cc0] [c0032528] .traverse_pci_devices+0xa8/0x150
[c0003e483d70] [c0aa7288] .eeh_init+0xd4/0x140
[c0003e483e00] [c000abc4] .do_one_initcall+0x64/0x1e0
[c0003e483ec0] [c0a90418] .kernel_init+0x1e8/0x2bc
[c0003e483f90] [c002048c] .kernel_thread+0x54/0x70
EEH: PCI Enhanced I/O Error Handling Enabled
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/eeh_pe.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c
b/arch/powerpc/platforms/pseries/eeh_pe.c
index 9d35543..797cd18 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -105,11 +105,8 @@ static struct eeh_pe *eeh_phb_pe_get(struct pci_controller
*phb)
* the PE for PHB has been determined when that
* was created.
*/
- if ((pe-type EEH_PE_PHB)
- pe-phb == phb) {
- eeh_unlock();
+ if ((pe-type EEH_PE_PHB) pe-phb == phb)
return pe;
- }
}
return NULL;
--
1.7.10
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc: Don't release eeh_mutex in eeh_phb_pe_get
On Fri, Sep 21, 2012 at 02:59:46PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
=
[ BUG: bad unlock balance detected! ]
3.6.0-rc5-00338-gcaa1d63-dirty #6 Not tainted
-
swapper/0/1 is trying to release lock (eeh_mutex) at:
[c0058218] .eeh_add_to_parent_pe+0x318/0x410
but there are no more locks to release!
other info that might help us debug this:
no locks held by swapper/0/1.
stack backtrace:
Call Trace:
[c0003e483870] [c0013310] .show_stack+0x70/0x1c0 (unreliable)
[c0003e483920] [c00d8310] .print_unlock_inbalance_bug+0x110/0x120
[c0003e4839b0] [c00d9a50] .lock_release+0x1d0/0x240
[c0003e483a60] [c0778064] .__mutex_unlock_slowpath+0xb4/0x250
[c0003e483b10] [c0058218] .eeh_add_to_parent_pe+0x318/0x410
[c0003e483bc0] [c005a118] .pseries_eeh_of_probe+0x258/0x2f0
[c0003e483cc0] [c0032528] .traverse_pci_devices+0xa8/0x150
[c0003e483d70] [c0aa7288] .eeh_init+0xd4/0x140
[c0003e483e00] [c000abc4] .do_one_initcall+0x64/0x1e0
[c0003e483ec0] [c0a90418] .kernel_init+0x1e8/0x2bc
[c0003e483f90] [c002048c] .kernel_thread+0x54/0x70
EEH: PCI Enhanced I/O Error Handling Enabled
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Acked-by: Gavin Shan sha...@linux.vnet.ibm.com
Thanks,
Gavin
---
arch/powerpc/platforms/pseries/eeh_pe.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c
b/arch/powerpc/platforms/pseries/eeh_pe.c
index 9d35543..797cd18 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -105,11 +105,8 @@ static struct eeh_pe *eeh_phb_pe_get(struct
pci_controller *phb)
* the PE for PHB has been determined when that
* was created.
*/
- if ((pe-type EEH_PE_PHB)
- pe-phb == phb) {
- eeh_unlock();
+ if ((pe-type EEH_PE_PHB) pe-phb == phb)
return pe;
- }
}
return NULL;
--
1.7.10
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PCI device not working
Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Thanx in advance for your help, regards Davide ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
On Friday 21 September 2012, Chunhe Lan wrote: On 08/10/2012 09:27 AM, Arnd Bergmann wrote: On Friday 10 August 2012, Chunhe Lan wrote: cond_resched(); mdelay(ms); sets off alarm bells, and I would always replace that with msleep(). I think that it does not replace with msleep(). When the time of sleep is very short, program should not been scheduled in the context. Because it expends the more time. A time measured in miliseconds is never very short for the scheduler, a lot of things can happen during that time span. The code I quoted also does not care too much about accuracy, otherwise it would adapt the time in the mdelay based on whether the cond_resched() actually schedules to another thread. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-pci: use 'Header Type' to identify PCIE mode
On Sep 20, 2012, at 10:37 PM, Lian Minghaun-b31939 wrote:
Hi Kumar,
please see my comments inline.
On 09/19/2012 10:22 PM, Kumar Gala wrote:
On Sep 19, 2012, at 2:23 AM, Minghuan Lian wrote:
The original code uses 'Programming Interface' field to judge if PCIE is
EP or RC mode, however, some latest silicons do not support this
functionality.
According to PCIE specification, 'Header Type' offset 0x0e is used to
indicate header type, so change code to use 'Header Type' field to
judge PCIE mode. Because FSL PCI controller does not support 'Header Type',
patch still uses 'Programming Interface' to identify PCI mode.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
arch/powerpc/sysdev/fsl_pci.c | 38 +++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index c37f461..43d30df 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -38,15 +38,15 @@ static int fsl_pcie_bus_fixup, is_mpc83xx_pci;
static void __devinit quirk_fsl_pcie_header(struct pci_dev *dev)
{
- u8 progif;
+ u8 hdr_type;
/* if we aren't a PCIe don't bother */
if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
return;
/* if we aren't in host mode don't bother */
- pci_read_config_byte(dev, PCI_CLASS_PROG, progif);
- if (progif 0x1)
+ pci_read_config_byte(dev, PCI_HEADER_TYPE, hdr_type);
+ if ((hdr_type 0x7f) != PCI_HEADER_TYPE_BRIDGE)
return;
dev-class = PCI_CLASS_BRIDGE_PCI 8;
@@ -425,7 +425,7 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
- u8 progif;
+ u8 hdr_type, progif;
if (!of_device_is_available(dev)) {
pr_warning(%s: disabled\n, dev-full_name);
@@ -457,25 +457,24 @@ int __init fsl_add_bridge(struct device_node *dev,
int is_primary)
setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
PPC_INDIRECT_TYPE_BIG_ENDIAN);
- early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, progif);
- if ((progif 1) == 1) {
- /* unmap cfg_data cfg_addr separately if not on same page */
- if (((unsigned long)hose-cfg_data PAGE_MASK) !=
- ((unsigned long)hose-cfg_addr PAGE_MASK))
- iounmap(hose-cfg_data);
- iounmap(hose-cfg_addr);
- pcibios_free_controller(hose);
- return -ENODEV;
- }
-
setup_pci_cmd(hose);
I think we should be doing the check before we call setup_pci_cmd(). The
old code didn't touch the controller registers if we where and end-point.
We should maintain that.
[Minghuan] Thanks for you pointing this.
I want to move setup_pci_cmd like this:
pr_debug( -Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n,
hose, hose-cfg_addr, hose-cfg_data);
+setup_pci_cmd(hose);
/* Interpret the ranges property */
/* This also maps the I/O region and sets isa_io/mem_base */
pci_process_bridge_OF_ranges(hose, dev, is_primary);
This movement will cause fsl_pcie_check_link() calling before setup_pci_cmd().
Is this ok?
I think so, as its how the code is today:
setup_pci_cmd()
..
if (pcie)
fsl_pcie_check_link()
If not, I will call setup_pci_cmd() for PCI and PCIE respectively.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote: Power supply for PCI inbound/outbound window registers is off when system go to deep-sleep state. We save the values of registers before suspend and restore to registers after resume. Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- Changes for V4: We just rebase the patch upon following patch: powerpc/fsl-pci: Unify pci/pcie initialization code arch/powerpc/include/asm/pci-bridge.h |2 +- arch/powerpc/sysdev/fsl_pci.c | 121 + 2 files changed, 122 insertions(+), 1 deletions(-) Did you ever compare this to just re-parsing device tree method? - k I tested the re-parsing way by using setup_pci_atmu() when resume. And I found out that re-parsing will *change* outbound IO translation address regitster. It seems that in the first bootup, after setup_atmu() pcibios_setup_phb_resources() may update hose-io_resource, but atmu is not updated according to the new hose-io_resource value. In resume from sleep setup_atmu() will reset atmu according to the new hose-io_resource value. So the setup_atmu() will cause different result on outbound IO register between first bootup and resume from sleep. So... There's a possibility that in the first bootup atmu is not setup properly. [Are you seeing this happen in your testing? If so its a bug we need to look at fixing.] Yes, I see this in my testing. Also PCIe ethernet card works well after resuming from sleep in both save/restore and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO resource) So, I guess the result of re-parsing (actually it's re-setup) is right and ATMU is not setup properly at the first bootup. Are you seeing the following message - PCI: I/O resource not set for host bridge ? No. Trying to understand why you'd hit the reassignment of io_resource. - k I did some investigations and the conclusion is: io_resource.flags IORESOURCE_IO are both positive but io_resource.start is 0 before pcibios_setup_phb_io_space() is done. The sequence of related process listed below: fsl_add_bridge() - setup_pci_atmu() pcibios_init() - pcibios_scan_phb() - pcibios_setup_phb_io_space() Because fsl_add_bridge() must be finished before pcibios_init() so ATMU is set when io_resource.start is 0. That means outbound IO regs are not set. If system re-setup ATMU the io_resource.start has already updated so outbound IO regs are set. My question is: Is there any problem if outbound IO regs are not set in first bootup? Yes, it means that IO transactions would not work. Please also provide the IO resource address range before and after the pci scan. Then we can evaluate if the range is needed to be mapped via ATMU. Leo Since potar is set by out_be32(pci-pow[j].potar, (hose-io_resource.start 12); I provide the result of hose-io_resource.start 12 as follows: pcie@ffe09000: before pci scan: io_resource.start 12: 0 after pci scan : io_resource.start 12: ff7ed pcie@ffe0a000: before pci scan: io_resource.start 12: 0 after pci scan : io_resource.start 12: ff7db pcie@ffe0b000: before pci scan: io_resource.start 12: 0 after pci scan : io_resource.start 12: ff7c9 Note that I tested on P1022DS. - Hongtao. 1. What's the device tree nodes for PCIe look like? 2. Can you get the pr_debug() in setup_pci_atmu() to print and report results (as well as full boot log) However, I think the change of the io_resource.start is normal and correct behavior. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. What do you mean by first instance of the device ? Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Probably a dts issue. What does lspci in linux say? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI device not working
I mean there are two controllers and both of them have a device subtended (both 0x1b65:0xabba). u-boot can see both devices, linux detects only the device attached to the first controller. Here's the output of lspci and /proc/iomem : root@(none):/# lspci -v :00:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: a000-afff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting :01:00.0 Class 0280: Device 1b65:abba (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at a000 (32-bit, non-prefetchable) [size=1K] Memory at a001 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel ? Capabilities: [800] Advanced Error Reporting 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11) Flags: bus master, fast devsel, latency 0 Memory at ignored (32-bit, non-prefetchable) Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: b000-bfff Capabilities: [44] Power Management version 2 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting root@(none):/# cat /proc/iomem a000-afff : /pcie@ffe09000 a000-afff : PCI Bus :01 a000-a3ff : :01:00.0 a001-a001 : :01:00.0 b000-bfff : /pcie@ffe0a000 b000-bfff : PCI Bus 0001:03 ef00-efff : ef00.nor ffe04500-ffe04507 : serial ffe04600-ffe04607 : serial thanx for your help, Davide I mean that the kernel detects the first controller and the device attached to it, plus the second controller: the device on the second controller is not detected (same device as the one detected on the first controller) 2012/9/21 Kumar Gala ga...@kernel.crashing.org On Sep 21, 2012, at 6:33 AM, Davide Viti wrote: Hi, I'm working on a custom board based on P1020 with two (identical) PCI devices attached; The work is derived from another board with a single instance of that device. The system is based on u-boot-2009.11 and Linux 2.6.34.6 The pci command on u-boot, shows me both the PCI controllers and the attached devices: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b65 0xabba Network controller 0x80 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x1957 0x0100 Processor 0x20 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x1b65 0xabba Network controller 0x80 The kernel detects only the first instance of the device. What do you mean by first instance of the device ? Didn't get very far while looking at dts file and kernel logs, so I'm asking for some help on narrowing down the problem. I'm wondering if I can assume that the problem is restricted to kernel/dts and avoid concentrating on uboot. I can provide any log (didn't want to post tons of details on the first message) Probably a dts issue. What does lspci in linux say? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc/usb: fix bug of CPU hang when missing USB PHY clock
On Tue, Sep 18, 2012 at 04:52:39PM +0800, Shengzhou Liu wrote: when missing USB PHY clock, kernel booting up will hang during USB initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid CPU hanging in this case. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v3 change: no check for UTMI PHY. v2 change: use spin_event_timeout() instead. drivers/usb/host/ehci-fsl.c | 57 +- drivers/usb/host/ehci-fsl.h |1 + include/linux/fsl_devices.h |1 + 3 files changed, 41 insertions(+), 18 deletions(-) This is already applied, right? greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Probing for native availability of isel from userspace
Hello, Is it possible to determine if _native_ isel is available from userspace somehow? So far my searches on the web and within kernel (headers)/glibc were fruitless (aux vectors, cpu_user_features), few people people (Hollis Blanchard, Richard Henderson) suggested PPC_FEATURE_ARCH_2_06, but PowerISA_V2.06B_V2_PUBLIC.pdf says - 3.3.11 Fixed-Point Select [Category: Phased-In (sV2.06)] about isel, the sV2.06 (s part) means something i suppose, furthermore Hollis mentioned that some pre 2.06 cores came with isel. Thanks. -- mailto:av1...@comtv.ru ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
On Thu, 2012-09-20 at 18:53 -0400, David Miller wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Fri, 21 Sep 2012 08:22:44 +1000 Hrm, that's ancient gunk, I'll have to dig. We potentially can support ISA devices DMA'ing from an ISA bridge... but via the iommu, which means isa_virt_to_bus is a non-starter. But then, do we really care ? IE. Is there single device that actually requires ISA_DMA_API and that is expected to work on any currently supported powerpc hw ? :-) We don't even support PReP anymore, so that leaves us with what ? ISA_DMA_API implies a fixed window of addresses which are = 32-bits on the bus, which is a hardware requirement of these devices. isa_virt_to_bus() goes to that physical address, and the expection is that you use GFP_DMA and thus the physical addresses fit inside of an unsigned int. Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all of memory is ZONE_DMA). It's always been like that afaik. We could support ISA device limited addressability using the iommu but that would involve a map/unmap type API (which I remember we did support in the old days by passing NULL to pci_map_*, but we dropped that along the way). isa_virt_to_bus() basically amounts to a virt--phys plus a cast. Anybody has an objection to turning ISA_DMA_API off ? Then you can remove all of the DMA api stuff in powerpc's asm/dma.h but some of it looks like it might be in use. I will dig a bit. I think there might be some users of the ISA DMA engine for legacy floppies and parport on some early pSeries and CHRP machines (including Pegasos). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
