* Re: [2/2] fsl/pci: The new pci suspend/resume implementation
From: Scott Wood @ 2014-03-19 21:00 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: roy.zang, galak, rjw, linux-pci, bhelgaas, linuxppc-dev
In-Reply-To: <1389081848-26506-2-git-send-email-dongsheng.wang@freescale.com>
On Tue, Jan 07, 2014 at 04:04:08PM +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> The new suspend/resume implementation, send pme turnoff message
> in suspend, and send pme exit message in resume.
>
> Add a PME handler, to response PME & message interrupt.
>
> Change platform_driver->suspend/resume to syscore->suspend/resume.
> pci-driver will call back EP device, to save EP state in
> pci_pm_suspend_noirq, so we need to keep the link, until
> pci_pm_suspend_noirq finish.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Is this patch OK to go in without patch 1/2? It's not clear whether that
was deemed incorrect (as in new patch coming) or unnecessary.
It would also be good if you submit with the explanation from
http://www.spinics.net/lists/linux-pci/msg27844.html in the commit
message.
> -static int fsl_pci_probe(struct platform_device *pdev)
> +#ifdef CONFIG_PM
> +static irqreturn_t fsl_pci_pme_handle(int irq, void *dev_id)
> {
> - int ret;
> - struct device_node *node;
> + struct pci_controller *hose = dev_id;
> + struct ccsr_pci __iomem *pci = hose->private_data;
> + u32 dr;
>
> - node = pdev->dev.of_node;
> - ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
> + dr = in_be32(&pci->pex_pme_mes_dr);
> + if (dr)
> + out_be32(&pci->pex_pme_mes_dr, dr);
> + else
> + return IRQ_NONE;
>
> - mpc85xx_pci_err_probe(pdev);
> + return IRQ_HANDLED;
> +}
Why do you put some of the HANDLED path in the if statement, and some
outside?
Just do:
if (!dr)
return IRQ_NONE;
out_be32(...);
return IRQ_HANDLED;
> +static int fsl_pci_pme_probe(struct pci_controller *hose)
> +{
> + struct ccsr_pci __iomem *pci;
> + struct pci_dev *dev = hose->bus->self;
> + u16 pms;
> + int pme_irq;
> + int res;
> +
> + /* PME Disable */
> + pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pms);
> + pms &= ~PCI_PM_CTRL_PME_ENABLE;
> + pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pms);
> +
> + pme_irq = irq_of_parse_and_map(hose->dn, 0);
> + if (!pme_irq) {
> + pr_warn("Failed to map PME interrupt.\n");
dev_err()
> +
> + return -ENXIO;
> + }
> +
> + res = devm_request_irq(hose->parent, pme_irq,
> + fsl_pci_pme_handle,
> + IRQF_DISABLED | IRQF_SHARED,
> + "[PCI] PME", hose);
IRQF_DISABLED is a deprecated no-op.
> + if (res < 0) {
> + pr_warn("Unable to requiest irq %d for PME\n", pme_irq);
dev_err() etc.
-Scott
^ permalink raw reply
* Re: [RFC, v3] powerpc: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
From: Scott Wood @ 2014-03-19 20:42 UTC (permalink / raw)
To: LEROY Christophe; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20131215150957.1F5C143E5B@localhost.localdomain>
On Sun, Dec 15, 2013 at 04:09:57PM +0100, LEROY Christophe wrote:
> Hereunder is a try to implement the sizing of the initial memory size based on
> initial-mapped-area size given by uboot in r7.
> As this has an impact on all powerpc platforms due to the need to provide the
> info up to function setup_initial_memory_limit(), I'm not completly sure of the
> proper implementation.
> Thanks to provide comments.
>
> Today on the 8xx, the only way to load kernels whose size is greater than
> 8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory initially
> mapped is limited to 8Mbytes. This patch uses the size of initial memory mapped
> by the bootloader and given to the kernel through register r7.
> This is done regardless of whether CONFIG_PIN_TLB is active or not. It allows to
> load "big" kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT) without
> having to activate CONFIG_PIN_TLB.
>
> Not-yet-signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> ---
> Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
> http://www.avast.com
>
> Index: linux/arch/powerpc/include/asm/mmu.h
> ===================================================================
> --- linux/arch/powerpc/include/asm/mmu.h (revision 5484)
> +++ linux/arch/powerpc/include/asm/mmu.h (copie de travail)
> @@ -138,7 +138,8 @@
> extern void early_init_mmu_secondary(void);
>
> extern void setup_initial_memory_limit(phys_addr_t first_memblock_base,
> - phys_addr_t first_memblock_size);
> + phys_addr_t first_memblock_size,
> + u64 init_mem_size);
What is the difference between first_memblock_size and init_mem_size, in
terms of what you expect setup_initial_memory_limit to do with them?
Can you just pass in min(first_memblock_size, init_mem_size), with the
non-ePAPR fallback handled in head_8xx.S (just load r30 with 8M instead
of zero)?
> #ifdef CONFIG_PPC64
> /* This is our real memory area size on ppc64 server, on embedded, we
> Index: linux/arch/powerpc/kernel/head_8xx.S
> ===================================================================
> --- linux/arch/powerpc/kernel/head_8xx.S (revision 5484)
> +++ linux/arch/powerpc/kernel/head_8xx.S (copie de travail)
> @@ -31,6 +31,8 @@
> #include <asm/asm-offsets.h>
> #include <asm/ptrace.h>
>
> +#define EPAPR_MAGIC 0x65504150
> +
> /* Macro to make the code more readable. */
> #ifdef CONFIG_8xx_CPU6
> #define DO_8xx_CPU6(val, reg) \
> @@ -77,10 +79,19 @@
> .globl __start
> __start:
> mr r31,r3 /* save device tree ptr */
> + li r30,0
>
> + lis r8,EPAPR_MAGIC@h
> + ori r8,r8, EPAPR_MAGIC@l
> + cmpw cr0,r8, r6
Whitespace
> + bne 1f
> +
> + mr r30,r7 /* save initial ram size */
> +
> /* We have to turn on the MMU right away so we get cache modes
> * set correctly.
> */
> +1:
> bl initial_mmu
>
> /* We now have the lower 8 Meg mapped into TLB entries, and the caches
> @@ -717,6 +728,8 @@
> */
> li r3,0
> mr r4,r31
> + li r5,0
> + mr r6,r30
> bl machine_init
> bl MMU_init
>
> @@ -841,11 +854,17 @@
> ori r8, r8, MI_BOOTINIT|0x2 /* Inhibit cache -- Cort */
> mtspr SPRN_MD_RPN, r8
>
> + /* Map two more 8M kernel data pages if needed
> + * We check how much memory is mapped by the bootloader
> + */
Whitespace
> Index: linux/arch/powerpc/kernel/prom.c
> ===================================================================
> --- linux/arch/powerpc/kernel/prom.c (revision 5484)
> +++ linux/arch/powerpc/kernel/prom.c (copie de travail)
> @@ -649,7 +649,7 @@
> }
> }
>
> -void __init early_init_devtree(void *params)
> +void __init early_init_devtree(void *params, u64 init_mem_size)
> {
> phys_addr_t limit;
>
> @@ -697,7 +697,7 @@
> /* make sure we've parsed cmdline for mem= before this */
> if (memory_limit)
> first_memblock_size = min_t(u64, first_memblock_size, memory_limit);
> - setup_initial_memory_limit(memstart_addr, first_memblock_size);
> + setup_initial_memory_limit(memstart_addr, first_memblock_size, init_mem_size);
Line length.
Yes, I know there's an existing violation on the previous line. :-)
> Index: linux/arch/powerpc/mm/init_32.c
> ===================================================================
> --- linux/arch/powerpc/mm/init_32.c (revision 5484)
> +++ linux/arch/powerpc/mm/init_32.c (copie de travail)
> @@ -206,19 +206,16 @@
>
> #ifdef CONFIG_8xx /* No 8xx specific .c file to put that in ... */
> void setup_initial_memory_limit(phys_addr_t first_memblock_base,
> - phys_addr_t first_memblock_size)
> + phys_addr_t first_memblock_size,
> + u64 init_mem_size)
> {
> /* We don't currently support the first MEMBLOCK not mapping 0
> * physical on those processors
> */
> BUG_ON(first_memblock_base != 0);
>
> -#ifdef CONFIG_PIN_TLB
> - /* 8xx can only access 24MB at the moment */
> - memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01800000));
> -#else
> - /* 8xx can only access 8MB at the moment */
> - memblock_set_current_limit(min_t(u64, first_memblock_size, 0x00800000));
> -#endif
> + if (!init_mem_size)
> + init_mem_size = 0x00800000;
> + memblock_set_current_limit(min_t(u64, first_memblock_size, init_mem_size));
Line length
> }
> #endif /* CONFIG_8xx */
> Index: linux/arch/powerpc/mm/ppc_mmu_32.c
> ===================================================================
> --- linux/arch/powerpc/mm/ppc_mmu_32.c (revision 5484)
> +++ linux/arch/powerpc/mm/ppc_mmu_32.c (copie de travail)
> @@ -273,7 +273,8 @@
> }
>
> void setup_initial_memory_limit(phys_addr_t first_memblock_base,
> - phys_addr_t first_memblock_size)
> + phys_addr_t first_memblock_size,
> + u64 init_mem_size)
> {
> /* We don't currently support the first MEMBLOCK not mapping 0
> * physical on those processors
> Index: linux/arch/powerpc/mm/tlb_nohash.c
> ===================================================================
> --- linux/arch/powerpc/mm/tlb_nohash.c (revision 5484)
> +++ linux/arch/powerpc/mm/tlb_nohash.c (copie de travail)
> @@ -654,7 +654,8 @@
> }
>
> void setup_initial_memory_limit(phys_addr_t first_memblock_base,
> - phys_addr_t first_memblock_size)
> + phys_addr_t first_memblock_size,
> + u64 init_mem_size)
> {
> /* On non-FSL Embedded 64-bit, we adjust the RMA size to match
> * the bolted TLB entry. We know for now that only 1G
It seems a bit odd for this function to take init_mem_size on these other
platforms, but not use it.
-Scott
^ permalink raw reply
* RE: EDAC PCIe errors when scannning the bus
From: Rajat Jain @ 2014-03-19 19:58 UTC (permalink / raw)
To: Valentin Longchamp, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org
Cc: Guenter Roeck
In-Reply-To: <532991AD.6020903@keymile.com>
SGVsbG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgtcGNp
LW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LXBjaS0NCj4gb3duZXJAdmdlci5r
ZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgVmFsZW50aW4gTG9uZ2NoYW1wDQo+IFNlbnQ6IFdlZG5l
c2RheSwgTWFyY2ggMTksIDIwMTQgNTo0NyBBTQ0KPiBUbzogbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmc7IGxpbnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogRURBQyBQQ0ll
IGVycm9ycyB3aGVuIHNjYW5ubmluZyB0aGUgYnVzDQo+IA0KPiBIZWxsbywNCj4gDQo+IFdlIGhh
dmUgYSBib2FyZCB0aGF0IGlzIGJhc2VkIG9uIEZyZWVzY2FsZSdzIFAyMDQxIFNvQy4gVGhlIGJv
YXJkcyBoYXMgMg0KPiBQQ0llIGJ1c2VzIHdpdGggdGhpcyB0b3BvbG9neToNCj4gDQo+IFBDSWUg
MCA8LS0tPiBQRVg4NTA1IHN3aXRjaCA8LS0tPiA0IG5ldHdvcmsgZGV2aWNlcyBQQ0lFIDIgPC0t
LT4gRlBHQQ0KPiANCj4gT24gMy4xMC4zMyArIGEgc3Vic2V0IG9mIHRoZSBGcmVlc2NhbGUgU0RL
IDEuNCBwYXRjaGVzLCBib3RoIFBDSWUgYnVzZXMNCj4gd29yayB3ZWxsIGFuZCB3ZSBhcmUgYWJs
ZSB0byB1c2UgdGhlIGRldmljZXMgb24gdGhlbS4NCj4gDQo+IEZvciBlYWNoIGJ1cywgSSBob3dl
dmVyIGtlZXAgZ2V0dGluZyBFREFDIFBDSWUgZXJyb3JzIGF0IHRoZSB2ZXJ5IGZpcnN0DQo+IHN0
YWdlIG9mIGJ1cyBlbnVtZXJhdGlvbiAocGxlYXNlIHNlZSB0aGUgYXR0YWNoZWQga2VybmVsIGxv
Zywgd2l0aCBzb21lDQo+IGRlYnVnIG91dHB1dCBmcm9tIGFyY2gvcG93ZXJwYy9rZXJuZWwvcGNp
LWNvbW1vbi5jIGFuZA0KPiBkcml2ZXJzL3BjaS9wcm9iZS5jKSBmb3IgYm90aCBidXNlcy4NCj4g
DQo+IE15IGN1cnJlbnQgInVuZGVyc3RhbmRpbmciIG9mIHRoZSBzaXR1YXRpb24gaXMgc3VjaDog
c2luY2UNCj4gUENJX1BST0JFX05PUk1BTCBpcyB1c2VkLCBwY2liaW9zX3NjYW5fcGhiKCkgY2Fs
bHMgcGNpX3NjYW5fY2hpbGRfYnVzKCkNCj4gdGhhdCBkb2VzIGEgcGNpX3NjYW5fc2xvdCgpIG9u
IHRoZSBidXMgZm9yIDMyIHNsb3RzLiBUaGUgZmlyc3QNCj4gcGNpX3NjYW5fc2xvdCgpIGlzIHN1
Y2Nlc3NmdWwgYW5kIGl0IGRpc2NvdmVycyB0aGUgUDIwNDEncyBQQ0llDQo+IENvbnRyb2xsZXIu
IEFsbCB0aGUgMzEgb3RoZXIgcGNpX3NjYW5fc2xvdCgpIGNhbGxzIGdlbmVyYXRlIGFuIEVEQUMg
UENJZQ0KPiBlcnJvciwgdGhhdCBpcyB0cmlnZ2VyZWQgYnkgdGhlIGNvbmZpZ3VyYXRpb24gcmVh
ZCB0cmFuc2FjdGlvbiB0byByZWFkDQo+IGFuIGh5cG90aGV0aWNhbCB2ZW5kb3IgSUQgb2YgYSBk
ZXZpY2Ugb24gdGhlIGJ1cy4gVGhpcyBpcyByZWxldmFudCB3aXRoDQo+IHRoYXQgaXMgcmVwb3J0
ZWQgYnkgdGhlIEVEQUMgZXJyb3IgaGFuZGxlciAoYWxsIHRoZSAzMSBhcmUgdGhlIHNhbWUpOg0K
PiANCj4gPiBQQ0lFIGVycm9yKHMpIGRldGVjdGVkDQo+ID4gUENJRSBFUlJfRFIgcmVnaXN0ZXI6
IDB4MDAwMjAwMDANCj4gDQo+IElDQ0EgYml0IGlzIHNldDogQWNjZXNzIHRvIGFuIGlsbGVnYWwg
Y29uZmlndXJhdGlvbiBzcGFjZSBmcm9tDQo+IFBFWF9DT05GSUdfQUREUi9QRVhfQ09ORklHX0RB
VEEgd2FzIGRldGVjdGVkLg0KPiANCj4gPiBQQ0lFIEVSUl9DQVBfU1RBVCByZWdpc3RlcjogMHg4
MDAwMDAwMQ0KPiANCj4gVG8gaXMgc2V0OiBUcmFuc2FjdGlvbiBvcmlnaW5hdGVkIGZyb20gUEVY
X0NPTkZJR19BRERSL1BFWF9DT05GSUdfREFUQS4NCj4gDQo+ID4gUENJRSBFUlJfQ0FQX1IwIHJl
Z2lzdGVyOiAweDAwMDAwODAwDQo+IA0KPiBGTVQ6IDBiMDAsIFRZUEU6IDBiMDAxMDAgKENvbmZp
ZyByZWFkIEkgZ3Vlc3MpDQo+IA0KPiA+IFBDSUUgRVJSX0NBUF9SMSByZWdpc3RlcjogMHgwMDAw
MDAwMA0KPiA+IFBDSUUgRVJSX0NBUF9SMiByZWdpc3RlcjogMHgwMDAwMDAwMA0KPiA+IFBDSUUg
RVJSX0NBUF9SMyByZWdpc3RlcjogMHgwMDAwMDAwMA0KPiANCj4gQWZ0ZXJ3YXJkcywgcGNpX3Nj
YW5fY2hpbGRfYnVzKCkgY2FsbHMgcGNpYmlvc19maXh1cF9idXMgKHRoYXQgbWF5YmUNCj4gaGVs
cHMgPykuDQo+IEZyb20gaGVyZSwgc2luY2UgdGhlIFAyMDQxJ3MgUENJZSBDb250cm9sbGVyIGlz
IGEgYnJpZGdlLA0KPiBwY2lfc2Nhbl9icmlkZ2UgaXMgY2FsbGVkIGZvciB0aGlzIGJ1cyBhbmQg
YWxsIHRoZSBkZXZpY2VzIGFyZSBkZXRlY3RlZA0KPiB3aXRob3V0IGhhdmluZyBhbnkgY29uZmln
dXJhdGlvbiB0cmFuc2FjdGlvbiBjYXVzaW5nIEVEQUMgZXJyb3JzLg0KPiANCj4gSGFzIHNvbWVv
bmUgYWxyZWFkeSBvYnNlcnZlZCBzdWNoIGEgYmVoYXZpb3IgPyBXaHkgZG8gdGhlc2UgaW5pdGlh
bA0KPiB0cmFuc2FjdGlvbiBnZW5lcmF0ZSBhbiBlcnJvciA/IFdoYXQgd291bGQgYmUgYSBwb3Nz
aWJsZSBmaXggdG8gYXZvaWQNCj4gdGhlc2UgdHJhbnNhY3Rpb24gZXJyb3JzIGZvciB0aGVzZSAz
MSAodW5uZWRlZCA/KSBwY2lfc2Nhbl9zbG90KCkgY2FsbHMNCj4gb24gdGhlIGluaXRpYWwgYnVz
ID8NCg0KSSBzZWUgdGhpcyB0b28gb24gbXkgUDUwMjAgYmFzZWQgcGxhdGZvcm0uIE5vIGZpeCB5
ZXQsIGZvciBub3cgZGlzYWJsaW5nIHRoZSBFREFDLg0KDQpUaGFua3MsDQoNClJhamF0DQoNCj4g
DQo+IEJlc3QgUmVnYXJkcywNCj4gDQo+IFZhbGVudGluDQo=
^ permalink raw reply
* Re: Tasks stuck in futex code (in 3.14-rc6)
From: Davidlohr Bueso @ 2014-03-19 18:06 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Srikar Dronamraju, torvalds, LKML, paulus, tglx, Paul E. McKenney,
linuxppc-dev, mingo
In-Reply-To: <20140319170829.GD8557@laptop.programming.kicks-ass.net>
On Wed, 2014-03-19 at 18:08 +0100, Peter Zijlstra wrote:
> On Wed, Mar 19, 2014 at 04:47:05PM +0100, Peter Zijlstra wrote:
> > > I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
> > > reverting the commit solved the problem.
> >
> > Joy,.. let me look at that with ppc in mind.
errr... just sat down to check email this morning. CC'ing Paul as for
any subtle barrier issues.
^ permalink raw reply
* Re: Tasks stuck in futex code (in 3.14-rc6)
From: Peter Zijlstra @ 2014-03-19 17:08 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linuxppc-dev, LKML, davidlohr, paulus, tglx, torvalds, mingo
In-Reply-To: <20140319154705.GB8557@laptop.programming.kicks-ass.net>
On Wed, Mar 19, 2014 at 04:47:05PM +0100, Peter Zijlstra wrote:
> > I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
> > reverting the commit solved the problem.
>
> Joy,.. let me look at that with ppc in mind.
OK; so while pretty much all the comments from that patch are utter
nonsense (what was I thinking), I cannot actually find a real bug.
But could you try the below which replaces a control dependency with a
full barrier. The control flow is plenty convoluted that I think the
control barrier isn't actually valid anymore and that might indeed
explain the fail.
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -119,42 +119,32 @@
* sys_futex(WAIT, futex, val);
* futex_wait(futex, val);
*
- * waiters++;
- * mb(); (A) <-- paired with -.
- * |
- * lock(hash_bucket(futex)); |
- * |
- * uval = *futex; |
- * | *futex = newval;
- * | sys_futex(WAKE, futex);
- * | futex_wake(futex);
- * |
- * `-------> mb(); (B)
- * if (uval == val)
+ *
+ * lock(hash_bucket(futex)); (A)
+ *
+ * uval = *futex;
+ * *futex = newval;
+ * sys_futex(WAKE, futex);
+ * futex_wake(futex);
+ *
+ * if (uval == val) (B) smp_mb(); (D)
* queue();
- * unlock(hash_bucket(futex));
- * schedule(); if (waiters)
+ * unlock(hash_bucket(futex)); (C)
+ * schedule(); if (spin_is_locked(&hb_lock) ||
+ * (smp_rmb(), !plist_empty))) (E)
* lock(hash_bucket(futex));
* wake_waiters(futex);
* unlock(hash_bucket(futex));
*
- * Where (A) orders the waiters increment and the futex value read -- this
- * is guaranteed by the head counter in the hb spinlock; and where (B)
- * orders the write to futex and the waiters read -- this is done by the
- * barriers in get_futex_key_refs(), through either ihold or atomic_inc,
- * depending on the futex type.
- *
- * This yields the following case (where X:=waiters, Y:=futex):
- *
- * X = Y = 0
- *
- * w[X]=1 w[Y]=1
- * MB MB
- * r[Y]=y r[X]=x
- *
- * Which guarantees that x==0 && y==0 is impossible; which translates back into
- * the guarantee that we cannot both miss the futex variable change and the
- * enqueue.
+ *
+ * Because of the acquire (A) and release (C) the futex value load and the
+ * plist_add are guaranteed to be inside the locked region. Furthermore, the
+ * control dependency (B) ensures the futex load happens before the plist_add().
+ *
+ * On the wakeup side, the full barrier (D) separates the futex value write
+ * from the hb_lock load, and matches with the control dependency. The rmb (E)
+ * separates the spin_is_locked() read and the plist_head_empty() read, such
+ * that ..., matches with the release barrier (C).
*/
#ifndef CONFIG_HAVE_FUTEX_CMPXCHG
@@ -250,7 +240,7 @@ static inline void futex_get_mm(union fu
/*
* Ensure futex_get_mm() implies a full barrier such that
* get_futex_key() implies a full barrier. This is relied upon
- * as full barrier (B), see the ordering comment above.
+ * as full barrier (D), see the ordering comment above.
*/
smp_mb__after_atomic();
}
@@ -308,10 +298,10 @@ static void get_futex_key_refs(union fut
switch (key->both.offset & (FUT_OFF_INODE|FUT_OFF_MMSHARED)) {
case FUT_OFF_INODE:
- ihold(key->shared.inode); /* implies MB (B) */
+ ihold(key->shared.inode); /* implies MB (D) */
break;
case FUT_OFF_MMSHARED:
- futex_get_mm(key); /* implies MB (B) */
+ futex_get_mm(key); /* implies MB (D) */
break;
}
}
@@ -385,7 +375,7 @@ get_futex_key(u32 __user *uaddr, int fsh
if (!fshared) {
key->private.mm = mm;
key->private.address = address;
- get_futex_key_refs(key); /* implies MB (B) */
+ get_futex_key_refs(key); /* implies MB (D) */
return 0;
}
@@ -492,7 +482,7 @@ get_futex_key(u32 __user *uaddr, int fsh
key->shared.pgoff = basepage_index(page);
}
- get_futex_key_refs(key); /* implies MB (B) */
+ get_futex_key_refs(key); /* implies MB (D) */
out:
unlock_page(page_head);
@@ -1604,7 +1594,7 @@ static inline struct futex_hash_bucket *
hb = hash_futex(&q->key);
q->lock_ptr = &hb->lock;
- spin_lock(&hb->lock); /* implies MB (A) */
+ spin_lock(&hb->lock);
return hb;
}
@@ -1995,6 +1985,8 @@ static int futex_wait_setup(u32 __user *
goto retry;
}
+ smp_mb();
+
if (uval != val) {
queue_unlock(*hb);
ret = -EWOULDBLOCK;
^ permalink raw reply
* Re: Tasks stuck in futex code (in 3.14-rc6)
From: Srikar Dronamraju @ 2014-03-19 16:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linuxppc-dev, LKML, davidlohr, paulus, tglx, torvalds, mingo
In-Reply-To: <20140319154705.GB8557@laptop.programming.kicks-ass.net>
> >
> > Infact I can reproduce this if the java_constraint is either node, socket, system.
> > However I am not able to reproduce if java_constraint is set to core.
>
> What's any of that mean?
>
Using the constraint, one can specify how many jvm instances should
participate in the specjbb run.
For example on a 4 node box, I can say 2 jvms per constraint with
constraint set to node and specjbb will run with 8 instances of java.
I was running with 1 jvm per constraint. But when I set the constraint
to node/System, I keep seeing this problem. However if I set the
constraint to core (which means running more instances of java), the
problem is not seen. I kind of guess, the lesser the number of java
instances the easier it is to reproduce.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: Tasks stuck in futex code (in 3.14-rc6)
From: Linus Torvalds @ 2014-03-19 16:04 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Peter Zijlstra, LKML, Davidlohr Bueso, Paul Mackerras,
Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <20140319152619.GB10406@linux.vnet.ibm.com>
On Wed, Mar 19, 2014 at 8:26 AM, Srikar Dronamraju
<srikar@linux.vnet.ibm.com> wrote:
>
> I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
> reverting the commit solved the problem.
Ok. I'll give Peter and Davidlohr a few days to perhaps find something
obvious, but I guess we'll need to revert it from 3.14 and try again
later unless some fix comes up quickly..
Oh well.
Linus
^ permalink raw reply
* [PATCH] powerpc/le: big endian arguments for ppc_rtas()
From: Greg Kurz @ 2014-03-19 16:02 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, anton, linux-kernel
The ppc_rtas() syscall allows userspace to interact directly with RTAS.
For the moment, it assumes every thing is big endian and returns either
EINVAL or EFAULT when called in a little endian environment.
As suggested by Benjamin, to avoid bugs when userspace wants to pass
a non 32 bit value to RTAS, it is far better to stick with a simple
rationale: ppc_rtas() should be called with a big endian rtas_args
structure.
With this patch, it is now up to userspace to forge big endian arguments,
as expected by RTAS.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
Ben,
The chunk with the -1 return code check may look a bit pedantic. Please feel
free to kill it. :)
Cheers.
--
Greg
arch/powerpc/kernel/rtas.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 4cf674d..f386296 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1013,12 +1013,13 @@ struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
return NULL;
}
+/* We assume to be passed big endian arguments */
asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
{
struct rtas_args args;
unsigned long flags;
char *buff_copy, *errbuf = NULL;
- int nargs;
+ int nargs, nret, token;
int rc;
if (!capable(CAP_SYS_ADMIN))
@@ -1027,10 +1028,13 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
return -EFAULT;
- nargs = args.nargs;
+ nargs = be32_to_cpu(args.nargs);
+ nret = be32_to_cpu(args.nret);
+ token = be32_to_cpu(args.token);
+
if (nargs > ARRAY_SIZE(args.args)
- || args.nret > ARRAY_SIZE(args.args)
- || nargs + args.nret > ARRAY_SIZE(args.args))
+ || nret > ARRAY_SIZE(args.args)
+ || nargs + nret > ARRAY_SIZE(args.args))
return -EINVAL;
/* Copy in args. */
@@ -1038,14 +1042,14 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
nargs * sizeof(rtas_arg_t)) != 0)
return -EFAULT;
- if (args.token == RTAS_UNKNOWN_SERVICE)
+ if (token == RTAS_UNKNOWN_SERVICE)
return -EINVAL;
args.rets = &args.args[nargs];
- memset(args.rets, 0, args.nret * sizeof(rtas_arg_t));
+ memset(args.rets, 0, nret * sizeof(rtas_arg_t));
/* Need to handle ibm,suspend_me call specially */
- if (args.token == ibm_suspend_me_token) {
+ if (token == ibm_suspend_me_token) {
rc = rtas_ibm_suspend_me(&args);
if (rc)
return rc;
@@ -1062,7 +1066,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
/* A -1 return code indicates that the last command couldn't
be completed due to a hardware error. */
- if (args.rets[0] == -1)
+ if (be32_to_cpu(args.rets[0]) == -1)
errbuf = __fetch_rtas_last_error(buff_copy);
unlock_rtas(flags);
@@ -1077,7 +1081,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
/* Copy out args. */
if (copy_to_user(uargs->args + nargs,
args.args + nargs,
- args.nret * sizeof(rtas_arg_t)) != 0)
+ nret * sizeof(rtas_arg_t)) != 0)
return -EFAULT;
return 0;
^ permalink raw reply related
* Re: EDAC PCIe errors when scannning the bus
From: Johannes Thumshirn @ 2014-03-19 15:54 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: linux-pci, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <532991AD.6020903@keymile.com>
On Wed, Mar 19, 2014 at 01:46:37PM +0100, Valentin Longchamp wrote:
> Hello,
>
> We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe
> buses with this topology:
>
> PCIe 0 <---> PEX8505 switch <---> 4 network devices
> PCIE 2 <---> FPGA
>
> On 3.10.33 + a subset of the Freescale SDK 1.4 patches, both PCIe buses work
> well and we are able to use the devices on them.
>
> For each bus, I however keep getting EDAC PCIe errors at the very first stage of
> bus enumeration (please see the attached kernel log, with some debug output from
> arch/powerpc/kernel/pci-common.c and drivers/pci/probe.c) for both buses.
>
> My current "understanding" of the situation is such: since PCI_PROBE_NORMAL is
> used, pcibios_scan_phb() calls pci_scan_child_bus() that does a pci_scan_slot()
> on the bus for 32 slots. The first pci_scan_slot() is successful and it
> discovers the P2041's PCIe Controller. All the 31 other pci_scan_slot() calls
> generate an EDAC PCIe error, that is triggered by the configuration read
> transaction to read an hypothetical vendor ID of a device on the bus. This is
> relevant with that is reported by the EDAC error handler (all the 31 are the same):
>
> > PCIE error(s) detected
> > PCIE ERR_DR register: 0x00020000
>
> ICCA bit is set: Access to an illegal configuration space from
> PEX_CONFIG_ADDR/PEX_CONFIG_DATA was detected.
>
> > PCIE ERR_CAP_STAT register: 0x80000001
>
> To is set: Transaction originated from PEX_CONFIG_ADDR/PEX_CONFIG_DATA.
>
> > PCIE ERR_CAP_R0 register: 0x00000800
>
> FMT: 0b00, TYPE: 0b00100 (Config read I guess)
>
> > PCIE ERR_CAP_R1 register: 0x00000000
> > PCIE ERR_CAP_R2 register: 0x00000000
> > PCIE ERR_CAP_R3 register: 0x00000000
>
> Afterwards, pci_scan_child_bus() calls pcibios_fixup_bus (that maybe helps ?).
> From here, since the P2041's PCIe Controller is a bridge, pci_scan_bridge is
> called for this bus and all the devices are detected without having any
> configuration transaction causing EDAC errors.
>
> Has someone already observed such a behavior ? Why do these initial transaction
> generate an error ? What would be a possible fix to avoid these transaction
> errors for these 31 (unneded ?) pci_scan_slot() calls on the initial bus ?
>
> Best Regards,
>
> Valentin
Hi Valentin,
I've encountered similar problems on a P4080 based design (mine has additional
machine checks that cause an oops). I haven't solved it yet, so I unfortunately
can't offer you a fix. But I was told there are some errata workarounds that
more or less could have an impact on PCIe behavior. Could you show me the output
of U-Boot's errata command?
Especially if the workarounds for A-004580 and A-004849 are in place.
Johannes
^ permalink raw reply
* Re: Tasks stuck in futex code (in 3.14-rc6)
From: Peter Zijlstra @ 2014-03-19 15:47 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linuxppc-dev, LKML, davidlohr, paulus, tglx, torvalds, mingo
In-Reply-To: <20140319152619.GB10406@linux.vnet.ibm.com>
On Wed, Mar 19, 2014 at 08:56:19PM +0530, Srikar Dronamraju wrote:
> There are 332 tasks all stuck in futex_wait_queue_me().
> I am able to reproduce this consistently.
>
> Infact I can reproduce this if the java_constraint is either node, socket, system.
> However I am not able to reproduce if java_constraint is set to core.
What's any of that mean?
> I ran git bisect between v3.12 and v3.14-rc6 and found that
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0c29f79ecea0b6fbcefc999e70f2843ae8306db
>
> commit b0c29f79ecea0b6fbcefc999e70f2843ae8306db
> Author: Davidlohr Bueso <davidlohr@hp.com>
> Date: Sun Jan 12 15:31:25 2014 -0800
>
> futexes: Avoid taking the hb->lock if there's nothing to wake up
>
> was the commit thats causing the threads to be stuck in futex.
>
> I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
> reverting the commit solved the problem.
Joy,.. let me look at that with ppc in mind.
^ permalink raw reply
* Re: [PATCH] fix dmaengine_unmap failure.
From: Dan Williams @ 2014-03-19 15:43 UTC (permalink / raw)
To: Xuelin Shi; +Cc: Vinod Koul, dmaengine@vger.kernel.org, linuxppc-dev
In-Reply-To: <30ef7093dcc247e490831a43355ec10f@BL2PR03MB147.namprd03.prod.outlook.com>
On Tue, Mar 18, 2014 at 11:39 PM, Xuelin Shi <xuelin.shi@freescale.com> wrote:
> Hi Dan,
>
> In async_mult(...) of async_raid6_recov.c, the count 3 is used to request an unmap.
> However the to_cnt and bidi_cnt are both set to 1 and from_cnt to 0.
> Then while trying to do unmap, we are getting the wrong "unmap" from a different mempool.
>
> In this patch, the mempool is associated with the unmap structure instead of computing it again.
> By this way, it is guaranteed that the unmap is the same when we get and put the unmap data.
>
> BTW: the mempool is just used to manage the struct unmap, not the pages.
>
I see, what about just storing the map_cnt at allocation time? It
could be another byte in struct dmaengine_unmap_data rather than an 8
byte pointer.
^ permalink raw reply
* Tasks stuck in futex code (in 3.14-rc6)
From: Srikar Dronamraju @ 2014-03-19 15:26 UTC (permalink / raw)
To: davidlohr; +Cc: peterz, torvalds, LKML, paulus, tglx, linuxppc-dev, mingo
Hi,
When running specjbb on a power7 numa box, I am seeing java threads
getting stuck in futex
# ps -Ao pid,tt,user,fname,tmout,f,wchan | grep futex
14808 pts/0 root java - 0 futex_wait_queue_me
14925 pts/0 root java - 0 futex_wait_queue_me
#
stack traces, I see
[ 1843.426591] Call Trace:
[ 1843.426595] [c0000017101d74d0] [0000000000000020] 0x20 (unreliable)
[ 1843.426601] [c0000017101d76a0] [c000000000014c50] .__switch_to+0x1e0/0x390
[ 1843.426607] [c0000017101d7750] [c0000000006ed314] .__schedule+0x364/0x8c0
[ 1843.426613] [c0000017101d79d0] [c000000000139c28] .futex_wait_queue_me+0xf8/0x1a0
[ 1843.426619] [c0000017101d7a60] [c00000000013afbc] .futex_wait+0x17c/0x2a0
[ 1843.426626] [c0000017101d7c10] [c00000000013cee4] .do_futex+0x254/0xd80
[ 1843.426631] [c0000017101d7d60] [c00000000013db2c] .SyS_futex+0x11c/0x1d0
[ 1843.426638] [c0000017101d7e30] [c000000000009efc] syscall_exit+0x0/0x7c
[ 1843.426643] java S 00003fffa08b16a0 0 14812 14203 0x00000080
[ 1843.426650] Call Trace:
[ 1843.426653] [c00000170c6034d0] [c000001710b09cf8] 0xc000001710b09cf8 (unreliable)
[ 1843.426660] [c00000170c6036a0] [c000000000014c50] .__switch_to+0x1e0/0x390
[ 1843.426666] [c00000170c603750] [c0000000006ed314] .__schedule+0x364/0x8c0
[ 1843.426672] [c00000170c6039d0] [c000000000139c28] .futex_wait_queue_me+0xf8/0x1a0
[ 1843.426679] [c00000170c603a60] [c00000000013afbc] .futex_wait+0x17c/0x2a0
[ 1843.453383] [c00000170c603c10] [c00000000013cee4] .do_futex+0x254/0xd80
[ 1843.453389] [c00000170c603d60] [c00000000013db2c] .SyS_futex+0x11c/0x1d0
[ 1843.453395] [c00000170c603e30] [c000000000009efc] syscall_exit+0x0/0x7c
[ 1843.453400] java S 00003fffa08b1a74 0 14813 14203 0x00000080
[ 1843.453407] Call Trace:
There are 332 tasks all stuck in futex_wait_queue_me().
I am able to reproduce this consistently.
Infact I can reproduce this if the java_constraint is either node, socket, system.
However I am not able to reproduce if java_constraint is set to core.
I ran git bisect between v3.12 and v3.14-rc6 and found that
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0c29f79ecea0b6fbcefc999e70f2843ae8306db
commit b0c29f79ecea0b6fbcefc999e70f2843ae8306db
Author: Davidlohr Bueso <davidlohr@hp.com>
Date: Sun Jan 12 15:31:25 2014 -0800
futexes: Avoid taking the hb->lock if there's nothing to wake up
was the commit thats causing the threads to be stuck in futex.
I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
reverting the commit solved the problem.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH RFC v9 2/6] dma: mpc512x: add support for peripheral transfers
From: Vinod Koul @ 2014-03-19 14:08 UTC (permalink / raw)
To: Alexander Popov
Cc: Lars-Peter Clausen, Arnd Bergmann, Gerhard Sittig,
Andy Shevchenko, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <CAF0T0X5egegHc3pheSbPRPuZaVaktMtdUiGPOLhcWZevH=pD=A@mail.gmail.com>
On Wed, Mar 19, 2014 at 05:26:47PM +0400, Alexander Popov wrote:
> Hello Andy
>
> 2014-03-14 13:47 GMT+04:00 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > On Wed, 2014-03-12 at 15:47 +0400, Alexander Popov wrote:
> >> + case DMA_SLAVE_CONFIG:
> >> + /* Constraints:
> >> + * - only transfers between a peripheral device and
> >> + * memory are supported;
> >> + * - minimal transfer chunk is 4 bytes and consequently
> >> + * source and destination addresses must be 4-byte aligned
> >> + * and transfer size must be aligned on (4 * maxburst)
> >> + * boundary;
> >> + * - during the transfer RAM address is being incremented by
> >> + * the size of minimal transfer chunk;
> >> + * - peripheral port's address is constant during the transfer.
> >> + */
> >> +
> >> + cfg = (void *)arg;
> >> +
> >> + if (!is_slave_direction(cfg->direction))
> >> + return -EINVAL;
> >
> > As far as I understand the intention you have not to use direction field
> > in the dma_slave_config. It will be removed once.
> >
> >> +
> >> + if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES &&
> >> + cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> >> + return -EINVAL;
> >> +
> >> + spin_lock_irqsave(&mchan->lock, flags);
> >> +
> >> + if (cfg->direction == DMA_DEV_TO_MEM) {
> >> + mchan->per_paddr = cfg->src_addr;
> >> + mchan->tcd_nunits = cfg->src_maxburst;
> >> + } else {
> >> + mchan->per_paddr = cfg->dst_addr;
> >> + mchan->tcd_nunits = cfg->dst_maxburst;
> >> + }
> >
> > Ditto.
>
> Excuse me, I don't understand this point.
> I have to use cfg->direction because in case of DMA_DEV_TO_MEM
> I use cfg->SRC_addr and cfg->SRC_maxburst and in case of
> DMA_MEM_TO_DEV I use cfg->DST_addr and cfg->DST_maxburst.
> Is it correct?
You store the complete config for both source and destination.
Then based on the descriptor direction you can retrive the values from channel
context and program
This way you _dont_ need to fix the direction and can use it both ways!
--
~Vinod
^ permalink raw reply
* Re: [PATCH RFC v9 2/6] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2014-03-19 13:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lars-Peter Clausen, Arnd Bergmann, Vinod Koul, Gerhard Sittig,
Alexander Popov, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <1394790471.28803.247.camel@smile.fi.intel.com>
Hello Andy
2014-03-14 13:47 GMT+04:00 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> On Wed, 2014-03-12 at 15:47 +0400, Alexander Popov wrote:
>> + case DMA_SLAVE_CONFIG:
>> + /* Constraints:
>> + * - only transfers between a peripheral device and
>> + * memory are supported;
>> + * - minimal transfer chunk is 4 bytes and consequently
>> + * source and destination addresses must be 4-byte aligned
>> + * and transfer size must be aligned on (4 * maxburst)
>> + * boundary;
>> + * - during the transfer RAM address is being incremented by
>> + * the size of minimal transfer chunk;
>> + * - peripheral port's address is constant during the transfer.
>> + */
>> +
>> + cfg = (void *)arg;
>> +
>> + if (!is_slave_direction(cfg->direction))
>> + return -EINVAL;
>
> As far as I understand the intention you have not to use direction field
> in the dma_slave_config. It will be removed once.
>
>> +
>> + if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES &&
>> + cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>> + return -EINVAL;
>> +
>> + spin_lock_irqsave(&mchan->lock, flags);
>> +
>> + if (cfg->direction == DMA_DEV_TO_MEM) {
>> + mchan->per_paddr = cfg->src_addr;
>> + mchan->tcd_nunits = cfg->src_maxburst;
>> + } else {
>> + mchan->per_paddr = cfg->dst_addr;
>> + mchan->tcd_nunits = cfg->dst_maxburst;
>> + }
>
> Ditto.
Excuse me, I don't understand this point.
I have to use cfg->direction because in case of DMA_DEV_TO_MEM
I use cfg->SRC_addr and cfg->SRC_maxburst and in case of
DMA_MEM_TO_DEV I use cfg->DST_addr and cfg->DST_maxburst.
Is it correct?
Best regards,
Alexander
^ permalink raw reply
* EDAC PCIe errors when scannning the bus
From: Valentin Longchamp @ 2014-03-19 12:46 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, linux-pci
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
Hello,
We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe
buses with this topology:
PCIe 0 <---> PEX8505 switch <---> 4 network devices
PCIE 2 <---> FPGA
On 3.10.33 + a subset of the Freescale SDK 1.4 patches, both PCIe buses work
well and we are able to use the devices on them.
For each bus, I however keep getting EDAC PCIe errors at the very first stage of
bus enumeration (please see the attached kernel log, with some debug output from
arch/powerpc/kernel/pci-common.c and drivers/pci/probe.c) for both buses.
My current "understanding" of the situation is such: since PCI_PROBE_NORMAL is
used, pcibios_scan_phb() calls pci_scan_child_bus() that does a pci_scan_slot()
on the bus for 32 slots. The first pci_scan_slot() is successful and it
discovers the P2041's PCIe Controller. All the 31 other pci_scan_slot() calls
generate an EDAC PCIe error, that is triggered by the configuration read
transaction to read an hypothetical vendor ID of a device on the bus. This is
relevant with that is reported by the EDAC error handler (all the 31 are the same):
> PCIE error(s) detected
> PCIE ERR_DR register: 0x00020000
ICCA bit is set: Access to an illegal configuration space from
PEX_CONFIG_ADDR/PEX_CONFIG_DATA was detected.
> PCIE ERR_CAP_STAT register: 0x80000001
To is set: Transaction originated from PEX_CONFIG_ADDR/PEX_CONFIG_DATA.
> PCIE ERR_CAP_R0 register: 0x00000800
FMT: 0b00, TYPE: 0b00100 (Config read I guess)
> PCIE ERR_CAP_R1 register: 0x00000000
> PCIE ERR_CAP_R2 register: 0x00000000
> PCIE ERR_CAP_R3 register: 0x00000000
Afterwards, pci_scan_child_bus() calls pcibios_fixup_bus (that maybe helps ?).
>From here, since the P2041's PCIe Controller is a bridge, pci_scan_bridge is
called for this bus and all the devices are detected without having any
configuration transaction causing EDAC errors.
Has someone already observed such a behavior ? Why do these initial transaction
generate an error ? What would be a possible fix to avoid these transaction
errors for these 31 (unneded ?) pci_scan_slot() calls on the initial bus ?
Best Regards,
Valentin
[-- Attachment #2: PCIe-boot-log.txt --]
[-- Type: text/plain, Size: 52105 bytes --]
U-Boot KM-v2013.10-7.0.5-00001-g29cfbaf (Mar 13 2014 - 11:40:15)
CPU0: P2041E, Version: 2.0, (0x82180120)
Core: e500mc, Version: 3.2, (0x80230032)
Clock Configuration:
CPU0:1333.333 MHz, CPU1:1333.333 MHz, CPU2:1333.333 MHz, CPU3:1333.333 MHz,
CCB:666.667 MHz,
DDR:533.333 MHz (1066.667 MT/s data rate) (Asynchronous), LBC:83.333 MHz
FMAN1: 533.333 MHz
QMAN: 333.333 MHz
PME: 333.333 MHz
L1: D-cache 32 KiB enabled
I-cache 32 KiB enabled
Reset Configuration Word (RCW):
00000000: 14600000 00000000 28200000 00000000
00000010: 148e70cf cfc02000 58000000 41000000
00000020: 00000000 00000000 00000000 f0428816
00000030: 00000000 00000000 00000000 00000000
Board: Keymile kmcoge4
I2C: ready
SPI: ready
DRAM: Initializing with SPD
Detected UDIMM
1 GiB (DDR3, 64-bit, CL=8, ECC off)
L2: 128 KiB enabled
Corenet Platform Cache: 1 MiB enabled
SERDES: bank 3 disabled
NAND: 256 MiB
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
PCIe FPGA config: done
PCIe1: Root Complex, x1, regs @ 0xfe200000
01:00.0 - 10b5:8505 - Bridge device
02:01.0 - 10b5:8505 - Bridge device
03:00.0 - 11ab:8000 - Network controller
02:02.0 - 10b5:8505 - Bridge device
04:00.0 - 11ab:8000 - Network controller
02:03.0 - 10b5:8505 - Bridge device
05:00.0 - 11ab:8000 - Network controller
02:04.0 - 10b5:8505 - Bridge device
06:00.0 - 11ab:8000 - Network controller
PCIe1: Bus 00 - 06
PCIe3: Root Complex, x1, regs @ 0xfe202000
08:00.0 - 10ee:000a - Memory controller
PCIe3: Bus 07 - 08
In: serial
Out: serial
Err: serial
Net: Initializing Fman
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
Fman1: Uploading microcode version 106.1.9
FM1@DTSEC5 [PRIME]
Warning: Bootlimit (3) exceeded. Using altbootcmd.
Hit any key to stop autoboot: 0
Using FM1@DTSEC5 device
TFTP from server 192.168.12.201; our IP address is 192.168.12.16
Filename 'kmcoge4/kmcoge4.dtb'.
Load address: 0x1f80000
Loading: ###
119.1 KiB/s
done
Bytes transferred = 30240 (7620 hex)
Using FM1@DTSEC5 device
TFTP from server 192.168.12.201; our IP address is 192.168.12.16
Filename 'kmcoge4/ecc_bch_uImage'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#############
4.4 MiB/s
done
Bytes transferred = 4002063 (3d110f hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.10.32-kmcoge4-v0.5-00003
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 4001999 Bytes = 3.8 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01f80000
Booting using the fdt blob at 0x1f80000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03fe5000, end 03fff61f ... OK
Using Keymile kmp204x machine description
Memory CAM mapping: 256/256 Mb, residual: 510Mb
Initializing cgroup subsys cpu
Linux version 3.10.32-kmcoge4-v0.5-00003-g6885786-dirty (chlongv1@chber1-10533x.keymile.net) (gcc version 4.7.2 (GCC) ) #6 SMP Wed Mar 19 08:27:30 CET 2014
No /soc@ffe000000/qman@318000 property 'fsl,qman-fqd', using memblock_alloc(0000000000400000)
No /soc@ffe000000/qman@318000 property 'fsl,qman-pfdr', using memblock_alloc(0000000002000000)
Qman ver:0a01,01,02
No /soc@ffe000000/bman@31a000 property 'fsl,bman-fbpr', using memblock_alloc(0000000001000000)
Bman ver:0a02,01,00
Found legacy serial port 0 for /soc@ffe000000/serial@11c500
mem=ffe11c500, taddr=ffe11c500, irq=0, clk=333333330, speed=0
Found legacy serial port 1 for /soc@ffe000000/serial@11c600
mem=ffe11c600, taddr=ffe11c600, irq=0, clk=333333330, speed=0
Found legacy serial port 2 for /soc@ffe000000/serial@11d500
mem=ffe11d500, taddr=ffe11d500, irq=0, clk=333333330, speed=0
Found legacy serial port 3 for /soc@ffe000000/serial@11d600
mem=ffe11d600, taddr=ffe11d600, irq=0, clk=333333330, speed=0
CPU maps initialized for 1 thread per core
(thread shift is 0)
bootconsole [udbg0] enabled
setup_arch: bootmem
Keymile kmp204x board from Freescale Semiconductor
arch: exit
Top of RAM: 0x3fe7f000, Total RAM: 0x3fe7f000
Memory hole size: 0MB
Zone ranges:
DMA [mem 0x00000000-0x1fffffff]
Normal empty
HighMem [mem 0x20000000-0x3fe7efff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x00000000-0x3fe7efff]
On node 0 totalpages: 261759
free_area_init_node: node 0, pgdat c07f1ec0, node_mem_map c08bf000
DMA zone: 1024 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 131072 pages, LIFO batch:31
HighMem zone: 1021 pages used for memmap
HighMem zone: 130687 pages, LIFO batch:31
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 11 pages/cpu @c10c5000 s22400 r8192 d14464 u45056
pcpu-alloc: s22400 r8192 d14464 u45056 alloc=11*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260735
Kernel command line: root=/dev/nfs rw nfsroot=192.168.12.201:/opt/eldk/ppc_82xx debug ip=192.168.12.16:192.168.12.201:::kmcoge4:eth0:off: console=ttyS0,115200 mem=0x3fe7f000 init=/sbin/init-overlay.sh eccmode=bch phram.phram=phvar,0x3feff000,0x100000 ubi.mtd=ubi0,2048
forcing BCH ECC algorithm to: bch!
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Sorting __ex_table...
High memory: 522744k
Memory: 909796k/1047036k available (7912k kernel code, 137240k reserved, 300k data, 732k bss, 324k init)
Kernel virtual memory layout:
* 0xfff5f000..0xfffff000 : fixmap
* 0xffc00000..0xffe00000 : highmem PTEs
* 0xffbfb000..0xffc00000 : early ioremap
* 0xe1000000..0xffbfb000 : vmalloc & ioremap
Hierarchical RCU implementation.
RCU debugfs-based tracing is enabled.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
NR_IRQS:512 nr_irqs:512 16
mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe040000, max 4 CPUs
mpic: ISU size: 512, shift: 9, mask: 1ff
mpic: Initializing for 512 sources
time_init: decrementer frequency = 20.833333 MHz
time_init: processor frequency = 1333.333320 MHz
clocksource: timebase mult[3000000d] shift[24] registered
clockevent: decrementer mult[5555554] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys net_cls
mpic: requesting IPIs...
e500 family performance monitor hardware support registered
Brought up 4 CPUs
devtmpfs: initialized
NET: Registered protocol family 16
Found FSL PCI host bridge at 0x0000000ffe200000. Firmware bus number: 0->6
PCI host bridge /pcie@ffe200000 (primary) ranges:
MEM 0x0000000c00000000..0x0000000c1fffffff -> 0x00000000e0000000
IO 0x0000000ff8000000..0x0000000ff800ffff -> 0x0000000000000000
/pcie@ffe200000: PCICSRBAR @ 0xdf000000
EDAC PCI0: Giving out device to module 'MPC85xx_edac' controller 'mpc85xx_pci_err': DEV 'ffe200000.pcie' (INTERRUPT)
MPC85xx_edac acquired irq 482 for PCI Err
MPC85xx_edac PCI err registered
Found FSL PCI host bridge at 0x0000000ffe202000. Firmware bus number: 0->1
PCI host bridge /pcie@ffe202000 ranges:
MEM 0x0000000c20000000..0x0000000c3fffffff -> 0x00000000e0000000
IO 0x0000000ff8010000..0x0000000ff801ffff -> 0x0000000000000000
/pcie@ffe202000: PCICSRBAR @ 0xdf000000
EDAC PCI1: Giving out device to module 'MPC85xx_edac' controller 'mpc85xx_pci_err': DEV 'ffe202000.pcie' (INTERRUPT)
MPC85xx_edac acquired irq 480 for PCI Err
MPC85xx_edac PCI err registered
PCI: Probing PCI hardware
PCI: Scanning PHB /pcie@ffe200000
PCI: PHB IO resource = 00000000-0000ffff [100] off 0x00000000
PCI: PHB MEM resource 0 = c00000000-c1fffffff [200] off 0xb20000000
fsl-pci ffe200000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0xc00000000-0xc1fffffff] (bus address [0xe0000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-ff]
probe mode: 0
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: [1957:0412] type 01 class 0x0b2000
pci 0000:00:00.0: reg 10: [mem 0xdf000000-0xdfffffff]
PCI:0000:00:00.0 Resource 0 00000000df000000-00000000dfffffff [40200]
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
pci_bus 0000:00: fixups for bus
PCI: Fixup bus devices 0 (PHB)
PCI: Try to map irq for 0000:00:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 482
pci 0000:00:00.0: scanning [bus 01-06] behind bridge, pass 0
pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: [10b5:8505] type 01 class 0x060400
pci 0000:01:00.0: reg 10: [mem 0xc00000000-0xc0001ffff]
PCI:0000:01:00.0 Resource 0 0000000c00000000-0000000c0001ffff [40200]
pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
pci_bus 0000:01: fixups for bus
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [mem 0xc00000000-0xc1fffffff]
PCI:0000:00:00.0 Bus rsrc 1 0000000c00000000-0000000c1fffffff [200]
PCI: Fixup bus devices 1 (0000:00:00.0)
PCI: Try to map irq for 0000:01:00.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
pci 0000:01:00.0: scanning [bus 02-06] behind bridge, pass 0
pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:02: scanning bus
pci 0000:02:01.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
pci 0000:02:02.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
pci 0000:02:03.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
pci 0000:02:04.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:04.0: PME# supported from D0 D3hot D3cold
pci_bus 0000:02: fixups for bus
pci 0000:01:00.0: PCI bridge to [bus 02-ff]
pci 0000:01:00.0: bridge window [mem 0xc00100000-0xc1fffffff]
PCI:0000:01:00.0 Bus rsrc 1 0000000c00100000-0000000c1fffffff [200]
PCI: Fixup bus devices 2 (0000:01:00.0)
PCI: Try to map irq for 0000:02:01.0...
Got one, spec 4 cells (0x00000001 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 20
PCI: Try to map irq for 0000:02:02.0...
Got one, spec 4 cells (0x00000002 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 21
PCI: Try to map irq for 0000:02:03.0...
Got one, spec 4 cells (0x00000003 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 22
PCI: Try to map irq for 0000:02:04.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
pci 0000:02:01.0: scanning [bus 03-03] behind bridge, pass 0
pci 0000:02:02.0: scanning [bus 04-04] behind bridge, pass 0
pci 0000:02:03.0: scanning [bus 05-05] behind bridge, pass 0
pci 0000:02:04.0: scanning [bus 06-06] behind bridge, pass 0
pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:03: scanning bus
pci 0000:03:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:03:00.0: reg 10: [mem 0xc00100000-0xc001fffff 64bit pref]
pci 0000:03:00.0: reg 18: [mem 0xc04000000-0xc07ffffff 64bit pref]
PCI:0000:03:00.0 Resource 0 0000000c00100000-0000000c001fffff [14220c]
PCI:0000:03:00.0 Resource 2 0000000c04000000-0000000c07ffffff [14220c]
pci 0000:03:00.0: supports D1 D2
pci_bus 0000:03: fixups for bus
pci 0000:02:01.0: PCI bridge to [bus 03-ff]
pci 0000:02:01.0: bridge window [mem 0xc00100000-0xc07ffffff]
PCI:0000:02:01.0 Bus rsrc 1 0000000c00100000-0000000c07ffffff [200]
PCI: Fixup bus devices 3 (0000:02:01.0)
PCI: Try to map irq for 0000:03:00.0...
Got one, spec 4 cells (0x00000001 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 20
pci_bus 0000:03: bus scan returning with max=03
pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
pci 0000:02:02.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:04: scanning bus
pci 0000:04:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:04:00.0: reg 10: [mem 0xc08000000-0xc080fffff 64bit pref]
pci 0000:04:00.0: reg 18: [mem 0xc0c000000-0xc0fffffff 64bit pref]
PCI:0000:04:00.0 Resource 0 0000000c08000000-0000000c080fffff [14220c]
PCI:0000:04:00.0 Resource 2 0000000c0c000000-0000000c0fffffff [14220c]
pci 0000:04:00.0: supports D1 D2
pci_bus 0000:04: fixups for bus
pci 0000:02:02.0: PCI bridge to [bus 04-ff]
pci 0000:02:02.0: bridge window [mem 0xc08000000-0xc0fffffff]
PCI:0000:02:02.0 Bus rsrc 1 0000000c08000000-0000000c0fffffff [200]
PCI: Fixup bus devices 4 (0000:02:02.0)
PCI: Try to map irq for 0000:04:00.0...
Got one, spec 4 cells (0x00000002 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 21
pci_bus 0000:04: bus scan returning with max=04
pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
pci 0000:02:03.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:05: scanning bus
pci 0000:05:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:05:00.0: reg 10: [mem 0xc10000000-0xc100fffff 64bit pref]
pci 0000:05:00.0: reg 18: [mem 0xc14000000-0xc17ffffff 64bit pref]
PCI:0000:05:00.0 Resource 0 0000000c10000000-0000000c100fffff [14220c]
PCI:0000:05:00.0 Resource 2 0000000c14000000-0000000c17ffffff [14220c]
pci 0000:05:00.0: supports D1 D2
pci_bus 0000:05: fixups for bus
pci 0000:02:03.0: PCI bridge to [bus 05-ff]
pci 0000:02:03.0: bridge window [mem 0xc10000000-0xc17ffffff]
PCI:0000:02:03.0 Bus rsrc 1 0000000c10000000-0000000c17ffffff [200]
PCI: Fixup bus devices 5 (0000:02:03.0)
PCI: Try to map irq for 0000:05:00.0...
Got one, spec 4 cells (0x00000003 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 22
pci_bus 0000:05: bus scan returning with max=05
pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:06: scanning bus
pci 0000:06:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:06:00.0: reg 10: [mem 0xc18000000-0xc180fffff 64bit pref]
pci 0000:06:00.0: reg 18: [mem 0xc1c000000-0xc1fffffff 64bit pref]
PCI:0000:06:00.0 Resource 0 0000000c18000000-0000000c180fffff [14220c]
PCI:0000:06:00.0 Resource 2 0000000c1c000000-0000000c1fffffff [14220c]
pci 0000:06:00.0: supports D1 D2
pci_bus 0000:06: fixups for bus
pci 0000:02:04.0: PCI bridge to [bus 06-ff]
pci 0000:02:04.0: bridge window [mem 0xc18000000-0xc1fffffff]
PCI:0000:02:04.0 Bus rsrc 1 0000000c18000000-0000000c1fffffff [200]
PCI: Fixup bus devices 6 (0000:02:04.0)
PCI: Try to map irq for 0000:06:00.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
pci_bus 0000:06: bus scan returning with max=06
pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
pci_bus 0000:02: bus scan returning with max=06
pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 06
pci_bus 0000:01: bus scan returning with max=06
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 06
pci_bus 0000:00: bus scan returning with max=06
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 06
PCI: Scanning PHB /pcie@ffe202000
PCI: PHB IO resource = 00020000-0002ffff [100] off 0x00020000
PCI: PHB MEM resource 0 = c20000000-c3fffffff [200] off 0xb40000000
fsl-pci ffe202000.pcie: PCI host bridge to bus 0001:07
pci_bus 0001:07: root bus resource [io 0x20000-0x2ffff] (bus address [0x0000-0xffff])
pci_bus 0001:07: root bus resource [mem 0xc20000000-0xc3fffffff] (bus address [0xe0000000-0xffffffff])
pci_bus 0001:07: root bus resource [bus 07-ff]
probe mode: 0
pci_bus 0001:07: busn_res: [bus 07-ff] end is updated to ff
pci_bus 0001:07: scanning bus
pci 0001:07:00.0: [1957:0412] type 01 class 0x0b2000
pci 0001:07:00.0: reg 10: [mem 0xdf000000-0xdfffffff]
PCI:0001:07:00.0 Resource 0 00000000df000000-00000000dfffffff [40200]
pci 0001:07:00.0: supports D1 D2
pci 0001:07:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
pci_bus 0001:07: fixups for bus
PCI: Fixup bus devices 7 (PHB)
PCI: Try to map irq for 0001:07:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 480
pci 0001:07:00.0: scanning [bus 01-01] behind bridge, pass 0
pci 0001:07:00.0: Primary bus is hard wired to 0
pci 0001:07:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
pci 0001:07:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0001:08: scanning bus
pci 0001:08:00.0: [10ee:000a] type 00 class 0x050000
pci 0001:08:00.0: reg 10: [mem 0xc20000000-0xc201fffff]
pci 0001:08:00.0: reg 14: [mem 0xc20200000-0xc203fffff]
PCI:0001:08:00.0 Resource 0 0000000c20000000-0000000c201fffff [40200]
PCI:0001:08:00.0 Resource 1 0000000c20200000-0000000c203fffff [40200]
pci 0001:08:00.0: supports D1 D2
pci 0001:08:00.0: PME# supported from D0 D1 D2 D3hot
pci_bus 0001:08: fixups for bus
pci 0001:07:00.0: PCI bridge to [bus 08-ff]
pci 0001:07:00.0: bridge window [mem 0xc20000000-0xc203fffff]
PCI:0001:07:00.0 Bus rsrc 1 0000000c20000000-0000000c203fffff [200]
PCI: Fixup bus devices 8 (0001:07:00.0)
PCI: Try to map irq for 0001:08:00.0...
Got one, spec 4 cells (0x0000002a 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 42
pci_bus 0001:08: bus scan returning with max=08
pci_bus 0001:08: busn_res: [bus 08-ff] end is updated to 08
pci_bus 0001:07: bus scan returning with max=08
pci_bus 0001:07: busn_res: [bus 07-ff] end is updated to 08
PCI: Allocating bus resources for 0000:00...
PCI: PHB (bus 0) bridge rsrc 4: 0000000000000000-000000000000ffff [0x100], parent c07bfa20 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 5: 0000000c00000000-0000000c1fffffff [0x200], parent c07bf9f8 (PCI mem)
PCI: Allocating bus resources for 0000:01...
PCI: 0000:00:00.0 (bus 1) bridge rsrc 0: 0000000000000000-000000000000ffff [0x100], parent db14ae88 (/pcie@ffe200000)
PCI: 0000:00:00.0 (bus 1) bridge rsrc 1: 0000000c00000000-0000000c1fffffff [0x200], parent db14aeb0 (/pcie@ffe200000)
PCI: Allocating bus resources for 0000:02...
PCI: 0000:01:00.0 (bus 2) bridge rsrc 1: 0000000c00100000-0000000c1fffffff [0x200], parent db0ea698 (PCI Bus 0000:01)
PCI: Allocating bus resources for 0000:03...
PCI: 0000:02:01.0 (bus 3) bridge rsrc 1: 0000000c00100000-0000000c07ffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0000:04...
PCI: 0000:02:02.0 (bus 4) bridge rsrc 1: 0000000c08000000-0000000c0fffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0000:05...
PCI: 0000:02:03.0 (bus 5) bridge rsrc 1: 0000000c10000000-0000000c17ffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0000:06...
PCI: 0000:02:04.0 (bus 6) bridge rsrc 1: 0000000c18000000-0000000c1fffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0001:07...
PCI: PHB (bus 7) bridge rsrc 4: 0000000000020000-000000000002ffff [0x100], parent c07bfa20 (PCI IO)
PCI: PHB (bus 7) bridge rsrc 5: 0000000c20000000-0000000c3fffffff [0x200], parent c07bf9f8 (PCI mem)
PCI: Allocating bus resources for 0001:08...
PCI: 0001:07:00.0 (bus 8) bridge rsrc 0: 0000000000020000-000000000002ffff [0x100], parent db14a888 (/pcie@ffe202000)
PCI: 0001:07:00.0 (bus 8) bridge rsrc 1: 0000000c20000000-0000000c3fffffff [0x200], parent db14a8b0 (/pcie@ffe202000)
PCI: Allocating 0000:00:00.0: Resource 0: 00000000df000000..00000000dfffffff [40200]
PCI: Cannot allocate resource region 0 of device 0000:00:00.0, will remap
PCI: Allocating 0000:01:00.0: Resource 0: 0000000c00000000..0000000c0001ffff [40200]
PCI: Allocating 0000:03:00.0: Resource 0: 0000000c00100000..0000000c001fffff [14220c]
PCI: Allocating 0000:03:00.0: Resource 2: 0000000c04000000..0000000c07ffffff [14220c]
PCI: Allocating 0000:04:00.0: Resource 0: 0000000c08000000..0000000c080fffff [14220c]
PCI: Allocating 0000:04:00.0: Resource 2: 0000000c0c000000..0000000c0fffffff [14220c]
PCI: Allocating 0000:05:00.0: Resource 0: 0000000c10000000..0000000c100fffff [14220c]
PCI: Allocating 0000:05:00.0: Resource 2: 0000000c14000000..0000000c17ffffff [14220c]
PCI: Allocating 0000:06:00.0: Resource 0: 0000000c18000000..0000000c180fffff [14220c]
PCI: Allocating 0000:06:00.0: Resource 2: 0000000c1c000000..0000000c1fffffff [14220c]
PCI: Allocating 0001:07:00.0: Resource 0: 00000000df000000..00000000dfffffff [40200]
PCI: Cannot allocate resource region 0 of device 0001:07:00.0, will remap
PCI: Allocating 0001:08:00.0: Resource 0: 0000000c20000000..0000000c201fffff [40200]
PCI: Allocating 0001:08:00.0: Resource 1: 0000000c20200000..0000000c203fffff [40200]
Reserving legacy ranges for domain 0000
Candidate legacy IO: [io 0x0000-0x0fff]
PCI 0000:00 Cannot reserve Legacy IO [io 0x0000-0x0fff]
hose mem res: [mem 0xc00000000-0xc1fffffff]
Reserving legacy ranges for domain 0001
Candidate legacy IO: [io 0x20000-0x20fff]
PCI 0001:07 Cannot reserve Legacy IO [io 0x20000-0x20fff]
hose mem res: [mem 0xc20000000-0xc3fffffff]
PCI: Assigning unassigned resources...
pci 0000:02:01.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000
pci 0000:02:01.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000
pci 0000:02:02.0: bridge window [io 0x1000-0x0fff] to [bus 04] add_size 1000
pci 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 04] add_size 200000
pci 0000:02:03.0: bridge window [io 0x1000-0x0fff] to [bus 05] add_size 1000
pci 0000:02:03.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 05] add_size 200000
pci 0000:02:01.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:02.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:03.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:01:00.0: bridge window [io 0x1000-0x0fff] to [bus 02-06] add_size 3000
pci 0000:02:01.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:02.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:03.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:01:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02-06] add_size 600000
pci 0000:01:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 600000
pci 0000:00:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01-06] add_size 600000
pci 0000:00:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 600000
pci 0000:00:00.0: BAR 0: can't assign mem (size 0x1000000)
pci 0000:00:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:00:00.0: BAR 0: can't assign mem (size 0x1000000)
pci 0000:00:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:01:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 600000
pci 0000:01:00.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 3000
pci 0000:01:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x3fff]
pci 0000:01:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:02:01.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:02.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:03.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:01.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:02.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:03.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:01.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:02.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:03.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:02:02.0: BAR 7: assigned [io 0x2000-0x2fff]
pci 0000:02:03.0: BAR 7: assigned [io 0x3000-0x3fff]
pci 0000:02:03.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:02.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:01.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:01.0: PCI bridge to [bus 03]
pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
pci 0000:02:01.0: bridge window [mem 0xc00100000-0xc07ffffff]
pci 0000:02:02.0: PCI bridge to [bus 04]
pci 0000:02:02.0: bridge window [io 0x2000-0x2fff]
pci 0000:02:02.0: bridge window [mem 0xc08000000-0xc0fffffff]
pci 0000:02:03.0: PCI bridge to [bus 05]
pci 0000:02:03.0: bridge window [io 0x3000-0x3fff]
pci 0000:02:03.0: bridge window [mem 0xc10000000-0xc17ffffff]
pci 0000:02:04.0: PCI bridge to [bus 06]
pci 0000:02:04.0: bridge window [mem 0xc18000000-0xc1fffffff]
pci 0000:01:00.0: PCI bridge to [bus 02-06]
pci 0000:01:00.0: bridge window [io 0x1000-0x3fff]
pci 0000:01:00.0: bridge window [mem 0xc00100000-0xc1fffffff]
pci 0000:00:00.0: PCI bridge to [bus 01-06]
pci 0000:00:00.0: bridge window [io 0x0000-0xffff]
pci 0000:00:00.0: bridge window [mem 0xc00000000-0xc1fffffff]
pci 0001:07:00.0: BAR 0: can't assign mem (size 0x1000000)
pci 0001:07:00.0: PCI bridge to [bus 08]
pci 0001:07:00.0: bridge window [io 0x20000-0x2ffff]
pci 0001:07:00.0: bridge window [mem 0xc20000000-0xc3fffffff]
Some PCI device resources are unassigned, try booting with pci=realloc
PCI: Try to map irq for 0000:00:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 482
PCI: Try to map irq for 0000:01:00.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
PCI: Try to map irq for 0000:02:01.0...
Got one, spec 4 cells (0x00000001 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 20
PCI: Try to map irq for 0000:02:02.0...
Got one, spec 4 cells (0x00000002 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 21
PCI: Try to map irq for 0000:02:03.0...
Got one, spec 4 cells (0x00000003 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 22
PCI: Try to map irq for 0000:02:04.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
PCI: Try to map irq for 0001:07:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 480
pci_bus 0000:00: resource 4 [io 0x0000-0xffff]
pci_bus 0000:00: resource 5 [mem 0xc00000000-0xc1fffffff]
pci_bus 0000:01: resource 0 [io 0x0000-0xffff]
pci_bus 0000:01: resource 1 [mem 0xc00000000-0xc1fffffff]
pci_bus 0000:02: resource 0 [io 0x1000-0x3fff]
pci_bus 0000:02: resource 1 [mem 0xc00100000-0xc1fffffff]
pci_bus 0000:03: resource 0 [io 0x1000-0x1fff]
pci_bus 0000:03: resource 1 [mem 0xc00100000-0xc07ffffff]
pci_bus 0000:04: resource 0 [io 0x2000-0x2fff]
pci_bus 0000:04: resource 1 [mem 0xc08000000-0xc0fffffff]
pci_bus 0000:05: resource 0 [io 0x3000-0x3fff]
pci_bus 0000:05: resource 1 [mem 0xc10000000-0xc17ffffff]
pci_bus 0000:06: resource 1 [mem 0xc18000000-0xc1fffffff]
pci_bus 0001:07: resource 4 [io 0x20000-0x2ffff]
pci_bus 0001:07: resource 5 [mem 0xc20000000-0xc3fffffff]
pci_bus 0001:08: resource 0 [io 0x20000-0x2ffff]
pci_bus 0001:08: resource 1 [mem 0xc20000000-0xc3fffffff]
Setting up Freescale MSI support
Setting up Freescale MSI support
Setting up Freescale MSI support
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
Bman err interrupt handler present
Bman portal initialised, cpu 0
Bman portal initialised, cpu 1
Bman portal initialised, cpu 2
Bman portal initialised, cpu 3
Bman portals initialised
Bman: BPID allocator includes range 32:32
Qman err interrupt handler present
Qman portal initialised, cpu 0
Qman portal initialised, cpu 1
Qman portal initialised, cpu 2
Qman portal initialised, cpu 3
Qman portals initialised
Qman: FQID allocator includes range 256:256
Qman: FQID allocator includes range 32768:32768
Qman: CGRID allocator includes range 0:256
Qman: pool channel allocator includes range 33:15
Switching to clocksource timebase
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 32 bytes, default 64
audit: initializing netlink socket (disabled)
type=2000 audit(2.215:1): initialized
bounce pool size: 64 pages
HugeTLB registered 4 MB page size, pre-allocated 0 pages
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 64 MB page size, pre-allocated 0 pages
HugeTLB registered 256 MB page size, pre-allocated 0 pages
HugeTLB registered 1 GB page size, pre-allocated 0 pages
squashfs: version 4.0 (2009/01/31) Phillip Lougher
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
NTFS driver 2.1.30 [Flags: R/O].
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
aufs 3.10
msgmni has been set to 884
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe11c500 (irq = 36) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe11c600 (irq = 36) is a 16550A
serial8250.0: ttyS2 at MMIO 0xffe11d500 (irq = 37) is a 16550A
serial8250.0: ttyS3 at MMIO 0xffe11d600 (irq = 37) is a 16550A
ePAPR hypervisor byte channel driver
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
st: Version 20101219, fixed bufsize 32768, s/g segs 256
phram_setup name=phvar, addr=3feff000, len=1024k
phram: phvar device: 0x100000 at 0x3feff000
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
forcing BCH ECC algorithm to 5!
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
1 ofpart partitions found on MTD device ffa00000.flash
Creating 1 MTD partitions on "ffa00000.flash":
0x000000000000-0x000010000000 : "ubi0"
eLBC NAND device at 0xfffa00000, bank 0
fsl_espi ffe110000.spi: master is unqueued, this is deprecated
m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
4 ofpart partitions found on MTD device spi32766.0
Creating 4 MTD partitions on "spi32766.0":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000110000 : "env"
0x000000110000-0x000000120000 : "envred"
0x000000120000-0x000000130000 : "fman-ucode"
m25p80 spi32766.2: m25p32 (4096 Kbytes)
1 ofpart partitions found on MTD device spi32766.2
Creating 1 MTD partitions on "spi32766.2":
0x000000000000-0x000000400000 : "fpga-config"
fsl_espi ffe110000.spi: at 0xe1106000 (irq = 53)
libphy: Fixed MDIO Bus: probed
fsl-pq_mdio ffe4e1120.mdio: deferring probe since network devices not present yet
platform ffe4e1120.mdio: Driver fsl-pq_mdio requests probe deferral
libphy: Freescale XGMAC MDIO Bus: probed
FMAN(0) Fifo size settings:
- Total buffers available(512 - 256B/buffer)
- Total throughput(3Gbps)
- Max frame size(1522B)
- 1G ports TX 3(12 bufs set (min: 12))
- 1G ports RX 3(142 bufs set (min: 14))
- OH-HC ports 4(8)
- Shared extra buffers(16)
FMAN(0) open dma settings:
- Total open dma available(32)
- 1G ports TX 3(4)
- 1G ports RX 3(4)
- OH-HC ports 4(1)
- Shared extra open dma(4)
FMAN(0) Tnums settings:
- Total Tnums available(128)
- 1G ports TX 3(19)
- 1G ports RX 3(20)
- OH-HC ports 4(2)
- Shared extra tnums(3)
Freescale FM module (Mar 18 2014:15:06:49), FMD API version 21.1.0
Freescale FM Ports module (Mar 18 2014:15:06:50)
dpaa_debugfs: FSL DPAA Ethernet debugfs entries ()
fsl_mac: mac.c:417:mac_load() fsl_mac: FSL FMan MAC API based driver ()
fsl_mac ffe4e0000.ethernet: FMan dTSEC version: 0x08240101
fsl_mac ffe4e0000.ethernet: FMan MAC address: 00:11:22:33:44:55
fsl_mac ffe4e2000.ethernet: FMan dTSEC version: 0x08240101
fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:11:22:33:44:55
fsl_mac ffe4e8000.ethernet: FMan dTSEC version: 0x08240101
fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:e0:df:a3:45:a1
fsl_dpa: dpaa_eth.c:4320:dpa_load() fsl_dpa: FSL DPAA Ethernet driver ()
fsl_dpa ethernet.16: Using private BM buffer pools
fsl_dpa: dpaa_eth.c:3715:dpa_rx_fq_init() Using dynamic RX QM frame queues
fsl_dpa: dpaa_eth.c:3739:dpa_tx_fq_init() Using dynamic TX QM frame queues
fsl_dpa ethernet.17: Using private BM buffer pools
fsl_dpa: dpaa_eth.c:3715:dpa_rx_fq_init() Using dynamic RX QM frame queues
fsl_dpa: dpaa_eth.c:3739:dpa_tx_fq_init() Using dynamic TX QM frame queues
fsl_dpa ethernet.18: Using private BM buffer pools
fsl_dpa: dpaa_eth.c:3715:dpa_rx_fq_init() Using dynamic RX QM frame queues
fsl_dpa: dpaa_eth.c:3739:dpa_tx_fq_init() Using dynamic TX QM frame queues
fsl_oh: offline_port.c:439:oh_port_load() fsl_oh: FSL FMan Offline Parsing port driver ()
i2c /dev entries driver
mpc-i2c ffe118000.i2c: timeout 1000000 us
mpc-i2c ffe118000.i2c: SCL GPIO pin not yet available, deferring probing
mpc-i2c ffe118000.i2c: failed to request GPIOs
platform ffe118000.i2c: Driver mpc-i2c requests probe deferral
Freescale(R) MPC85xx EDAC driver, (C) 2006 Montavista Software
mpc85xx_mc_err_probe: No ECC DIMMs discovered
caam ffe300000.crypto: device ID = 0x0a12010000000000 (Era 3)
caam ffe300000.crypto: job rings = 4, qi = 1
caam ffe300000.crypto: fsl,sec-v4.2 algorithms registered in /proc/crypto
platform ffe301000.jr: registering rng-caam
qriox ffb000000.bec: GPIO ctlr registered
qriox ffb000000.bec: GPIO export registered
qriox ffb000000.bec: IRQ ctlr registered
qriox ffb000000.bec: QRIO1 Rev. 0x13 registered @ 0xffb000000..0xffb00007f, BUF_ENA=ON
qriox ffb000000.bec: Populate qriox child nodes...
bc_get_addr: bc_get_addr no node, trying compatible node
created "/proc/driver/bootcount"
bootcount driver registered.
bfticu: attaching bftic4, private db461940
bfticu: physical resources [mem 0xfe0000000-0xfe00000ff]
bfticu fe0000000.bftic4: Chip id correct 0x65
bfticu fe0000000.bftic4: Set up succesfully 48 bfticu_irqs
bfticu:init
km_event_probe: probing events for qrio_events.12
km_event_handler: setup OK.
km_event_probe: probing events for fe0000000.bftic4_events
km_event_handler: setup OK.
u32 classifier
Performance counters on
ipip: IPv4 over IPv4 tunneling driver
TCP: cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
tipc: Activated (version 2.0.0)
NET: Registered protocol family 30
tipc: Started in single node mode
Key type dns_resolver registered
libphy: Freescale PowerQUICC MII Bus: probed
mpc-i2c ffe118000.i2c: timeout 1000000 us
mpc-i2c ffe118000.i2c: requested GPIO 180 for SCL
mpc-i2c ffe118000.i2c: requested GPIO 181 for SDA
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "ubi0", size 256 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 2044, bad PEBs: 4, corrupted PEBs: 0
UBI: user volume: 11, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 0
UBI: available PEBs: 1017, total reserved PEBs: 1027, PEBs reserved for bad PEB handling: 36
UBI: background thread "ubi_bgt0d" started, PID 110
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, hwaddr=00:e0:df:a3:45:a1, ipaddr=192.168.12.16, mask=255.255.255.0, gw=255.255.255.255
host=kmcoge4, domain=, nis-domain=(none)
bootserver=192.168.12.201, rootserver=192.168.12.201, rootpath=
VFS: Mounted root (nfs filesystem) on device 0:17.
devtmpfs: mounted
Freeing unused kernel memory: 324K (c0769000 - c07ba000)
6.677 INFO init-overlay done in 0.26
8.300 INFO sysinit done in 1.61
root@kmcoge4:~#
^ permalink raw reply
* Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
From: Gautham R Shenoy @ 2014-03-19 11:02 UTC (permalink / raw)
To: Srivatsa S. Bhat; +Cc: linuxppc-dev, Gautham R. Shenoy
In-Reply-To: <53293AA8.2040609@linux.vnet.ibm.com>
On Wed, Mar 19, 2014 at 12:05:20PM +0530, Srivatsa S. Bhat wrote:
> On 03/19/2014 05:07 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
> >> From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> >>
> >> Create a helper method that computes the cpumask corresponding to the
> >> thread-siblings of a cpu. Use this for initializing the policy->cpus
> >> mask for a given cpu.
> >>
> >> (Original code written by Srivatsa S. Bhat. Gautham moved this to a
> >> helper function!)
> >
> > How does that differ from the existing entry in the sibling map which
> > you can obtain with the helper cpu_sibling_mask() ? (You probably want
> > to *copy* the mask of course but I don't see the need of re-creating
> > one from scratch).
> >
>
> The intent here was to have a sibling mask that is invariant of CPU
> hotplug. cpu_sibling_mask is updated on every hotplug operation, and this
> would break cpufreq, since policy->cpus has to be hotplug invariant.
>
> This should have been noted in the changelog of patch 1 as well as this
> patch. (The earlier (internal) versions of this patchset had the
> description in the changelogs, but somehow it got dropped accidentally).
> I'll work with Gautham and ensure that we have this important info
> included in the changelog. Thanks for pointing it out!
I reused that part of the code because I was unaware of
cpu_sibling_mask()!
For implementing powernv_cpufreq_get(), cpu_sibling_mask() suffices
since we are using this mask as a parameter to
smp_call_function_any(), and hence are concerned only about the online
siblings.
I shall fix the changelog to reflect Srivatsa's reason for having a
mask that does not vary with cpu-hotplug.
>
> Regards,
> Srivatsa S. Bhat
>
>
> > Also, this should have been CCed to the cpufreq mailing list and maybe
> > the relevant maintainer too.
Ok. Will do it in the subsequent version.
Thanks for the review!
> >
> > Cheers,
> > Ben.
> >
> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> >> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> >> ---
> >> drivers/cpufreq/powernv-cpufreq.c | 24 ++++++++++++++++++------
> >> 1 file changed, 18 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> >> index ab1551f..4cad727 100644
> >> --- a/drivers/cpufreq/powernv-cpufreq.c
> >> +++ b/drivers/cpufreq/powernv-cpufreq.c
> >> @@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
> >>
> >> /* Helper routines */
> >>
> >> +/**
> >> + * Sets the bits corresponding to the thread-siblings of cpu in its core
> >> + * in 'cpus'.
> >> + */
> >> +static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
> >> +{
> >> + int base, i;
> >> +
> >> + base = cpu_first_thread_sibling(cpu);
> >> +
> >> + for (i = 0; i < threads_per_core; i++) {
> >> + cpumask_set_cpu(base + i, cpus);
> >> + }
> >> +
> >> + return;
> >> +}
> >> +
> >> /* Access helpers to power mgt SPR */
> >>
> >> static inline unsigned long get_pmspr(unsigned long sprn)
> >> @@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus, unsigned int new_index)
> >>
> >> static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
> >> {
> >> - int base, i;
> >> -
> >> #ifdef CONFIG_SMP
> >> - base = cpu_first_thread_sibling(policy->cpu);
> >> -
> >> - for (i = 0; i < threads_per_core; i++)
> >> - cpumask_set_cpu(base + i, policy->cpus);
> >> + powernv_cpu_to_core_mask(policy->cpu, policy->cpus);
> >> #endif
> >> policy->cpuinfo.transition_latency = 25000;
> >>
> >
> >
>
^ permalink raw reply
* [PATCH] fix wrong usage of dmaengine_unmap_put in async_xxx
From: xuelin.shi @ 2014-03-19 8:18 UTC (permalink / raw)
To: dan.j.williams, vinod.koul; +Cc: dmaengine, Xuelin Shi, linuxppc-dev
From: Xuelin Shi <xuelin.shi@freescale.com>
dmaengine_unmap_put does below two things:
a) unmap pages for srcs and dests
b) free unmap struct
The unmap struct data is generated but only initialized while
other some dma contions are met, like dma alignment etc.
If the unmap data is not initialized, call dmaengine_unmap_put
will unmap some random data in unmap->addr[...]
Also call dmaengine_get_unmap_data immediatally after generating tx
is not correct. Maybe the tx has not been finished by DMA hardware
yet but the srcs and dests are dma unmapped.
This patch fixed above two issues by:
a) only generates unmap struct data when other dma conditions are met.
b) eliminates dmaengine_unmap_put when tx is generated because tx knowes
the best time to unmap it (in interrupt processing).
Signed-off-by: Xuelin Shi <xuelin.shi@freescale.com>
---
crypto/async_tx/async_memcpy.c | 38 ++++----
crypto/async_tx/async_pq.c | 191 ++++++++++++++++++++++-------------------
crypto/async_tx/async_xor.c | 100 +++++++++++----------
3 files changed, 175 insertions(+), 154 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index f8c0b8d..578d1bd 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -52,10 +52,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
struct dma_async_tx_descriptor *tx = NULL;
struct dmaengine_unmap_data *unmap = NULL;
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
-
- if (unmap && is_dma_copy_aligned(device, src_offset, dest_offset, len)) {
+ if (device && is_dma_copy_aligned(device, src_offset, dest_offset, len)) {
unsigned long dma_prep_flags = 0;
if (submit->cb_fn)
@@ -63,17 +60,24 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
if (submit->flags & ASYNC_TX_FENCE)
dma_prep_flags |= DMA_PREP_FENCE;
- unmap->to_cnt = 1;
- unmap->addr[0] = dma_map_page(device->dev, src, src_offset, len,
- DMA_TO_DEVICE);
- unmap->from_cnt = 1;
- unmap->addr[1] = dma_map_page(device->dev, dest, dest_offset, len,
- DMA_FROM_DEVICE);
- unmap->len = len;
-
- tx = device->device_prep_dma_memcpy(chan, unmap->addr[1],
- unmap->addr[0], len,
- dma_prep_flags);
+ unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
+ if (unmap) {
+ unmap->to_cnt = 1;
+ unmap->addr[0] = dma_map_page(device->dev, src,
+ src_offset, len,
+ DMA_TO_DEVICE);
+ unmap->from_cnt = 1;
+ unmap->addr[1] = dma_map_page(device->dev, dest,
+ dest_offset, len,
+ DMA_FROM_DEVICE);
+ unmap->len = len;
+
+ tx = device->device_prep_dma_memcpy(chan,
+ unmap->addr[1],
+ unmap->addr[0],
+ len,
+ dma_prep_flags);
+ }
}
if (tx) {
@@ -85,6 +89,8 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
void *dest_buf, *src_buf;
pr_debug("%s: (sync) len: %zu\n", __func__, len);
+ dmaengine_unmap_put(unmap);
+
/* wait for any prerequisite operations */
async_tx_quiesce(&submit->depend_tx);
@@ -99,8 +105,6 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
async_tx_sync_epilog(submit);
}
- dmaengine_unmap_put(unmap);
-
return tx;
}
EXPORT_SYMBOL_GPL(async_memcpy);
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index d05327c..a25343c 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -175,10 +175,7 @@ async_gen_syndrome(struct page **blocks, unsigned int offset, int disks,
BUG_ON(disks > 255 || !(P(blocks, disks) || Q(blocks, disks)));
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
-
- if (unmap &&
+ if (device &&
(src_cnt <= dma_maxpq(device, 0) ||
dma_maxpq(device, DMA_PREP_CONTINUE) > 0) &&
is_dma_pq_aligned(device, offset, 0, len)) {
@@ -194,42 +191,52 @@ async_gen_syndrome(struct page **blocks, unsigned int offset, int disks,
/* convert source addresses being careful to collapse 'empty'
* sources and update the coefficients accordingly
*/
- unmap->len = len;
- for (i = 0, j = 0; i < src_cnt; i++) {
- if (blocks[i] == NULL)
- continue;
- unmap->addr[j] = dma_map_page(device->dev, blocks[i], offset,
- len, DMA_TO_DEVICE);
- coefs[j] = raid6_gfexp[i];
- unmap->to_cnt++;
- j++;
- }
+ unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
+ if (unmap) {
+ unmap->len = len;
+ for (i = 0, j = 0; i < src_cnt; i++) {
+ if (blocks[i] == NULL)
+ continue;
+ unmap->addr[j] = dma_map_page(device->dev,
+ blocks[i],
+ offset,
+ len,
+ DMA_TO_DEVICE);
+ coefs[j] = raid6_gfexp[i];
+ unmap->to_cnt++;
+ j++;
+ }
- /*
- * DMAs use destinations as sources,
- * so use BIDIRECTIONAL mapping
- */
- unmap->bidi_cnt++;
- if (P(blocks, disks))
- unmap->addr[j++] = dma_map_page(device->dev, P(blocks, disks),
- offset, len, DMA_BIDIRECTIONAL);
- else {
- unmap->addr[j++] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_P;
- }
+ /*
+ * DMAs use destinations as sources,
+ * so use BIDIRECTIONAL mapping
+ */
+ unmap->bidi_cnt++;
+ if (P(blocks, disks))
+ unmap->addr[j++] = dma_map_page(device->dev,
+ P(blocks, disks),
+ offset, len,
+ DMA_BIDIRECTIONAL);
+ else {
+ unmap->addr[j++] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_P;
+ }
- unmap->bidi_cnt++;
- if (Q(blocks, disks))
- unmap->addr[j++] = dma_map_page(device->dev, Q(blocks, disks),
- offset, len, DMA_BIDIRECTIONAL);
- else {
- unmap->addr[j++] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_Q;
- }
+ unmap->bidi_cnt++;
+ if (Q(blocks, disks))
+ unmap->addr[j++] = dma_map_page(device->dev,
+ Q(blocks, disks),
+ offset, len,
+ DMA_BIDIRECTIONAL);
+ else {
+ unmap->addr[j++] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_Q;
+ }
- tx = do_async_gen_syndrome(chan, coefs, j, unmap, dma_flags, submit);
- dmaengine_unmap_put(unmap);
- return tx;
+ tx = do_async_gen_syndrome(chan, coefs, j, unmap,
+ dma_flags, submit);
+ return tx;
+ }
}
dmaengine_unmap_put(unmap);
@@ -293,10 +300,7 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
BUG_ON(disks < 4);
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
-
- if (unmap && disks <= dma_maxpq(device, 0) &&
+ if (device && disks <= dma_maxpq(device, 0) &&
is_dma_pq_aligned(device, offset, 0, len)) {
struct device *dev = device->dev;
dma_addr_t pq[2];
@@ -305,58 +309,63 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
pr_debug("%s: (async) disks: %d len: %zu\n",
__func__, disks, len);
- unmap->len = len;
- for (i = 0; i < disks-2; i++)
- if (likely(blocks[i])) {
- unmap->addr[j] = dma_map_page(dev, blocks[i],
- offset, len,
- DMA_TO_DEVICE);
- coefs[j] = raid6_gfexp[i];
+ unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
+ if (unmap) {
+ unmap->len = len;
+ for (i = 0; i < disks-2; i++)
+ if (likely(blocks[i])) {
+ unmap->addr[j] = dma_map_page(dev,
+ blocks[i],
+ offset,
+ len,
+ DMA_TO_DEVICE);
+ coefs[j] = raid6_gfexp[i];
+ unmap->to_cnt++;
+ src_cnt++;
+ j++;
+ }
+
+ if (!P(blocks, disks)) {
+ pq[0] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_P;
+ } else {
+ pq[0] = dma_map_page(dev, P(blocks, disks),
+ offset, len,
+ DMA_TO_DEVICE);
+ unmap->addr[j++] = pq[0];
+ unmap->to_cnt++;
+ }
+ if (!Q(blocks, disks)) {
+ pq[1] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_Q;
+ } else {
+ pq[1] = dma_map_page(dev, Q(blocks, disks),
+ offset, len,
+ DMA_TO_DEVICE);
+ unmap->addr[j++] = pq[1];
unmap->to_cnt++;
- src_cnt++;
- j++;
}
- if (!P(blocks, disks)) {
- pq[0] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_P;
- } else {
- pq[0] = dma_map_page(dev, P(blocks, disks),
- offset, len,
- DMA_TO_DEVICE);
- unmap->addr[j++] = pq[0];
- unmap->to_cnt++;
- }
- if (!Q(blocks, disks)) {
- pq[1] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_Q;
- } else {
- pq[1] = dma_map_page(dev, Q(blocks, disks),
- offset, len,
- DMA_TO_DEVICE);
- unmap->addr[j++] = pq[1];
- unmap->to_cnt++;
- }
-
- if (submit->flags & ASYNC_TX_FENCE)
- dma_flags |= DMA_PREP_FENCE;
- for (;;) {
- tx = device->device_prep_dma_pq_val(chan, pq,
- unmap->addr,
- src_cnt,
- coefs,
- len, pqres,
- dma_flags);
- if (likely(tx))
- break;
- async_tx_quiesce(&submit->depend_tx);
- dma_async_issue_pending(chan);
- }
+ if (submit->flags & ASYNC_TX_FENCE)
+ dma_flags |= DMA_PREP_FENCE;
+ for (;;) {
+ tx = device->device_prep_dma_pq_val(chan, pq,
+ unmap->addr,
+ src_cnt,
+ coefs,
+ len, pqres,
+ dma_flags);
+ if (likely(tx))
+ break;
+ async_tx_quiesce(&submit->depend_tx);
+ dma_async_issue_pending(chan);
+ }
- dma_set_unmap(tx, unmap);
- async_tx_submit(chan, tx, submit);
+ dma_set_unmap(tx, unmap);
+ async_tx_submit(chan, tx, submit);
- return tx;
+ return tx;
+ }
} else {
struct page *p_src = P(blocks, disks);
struct page *q_src = Q(blocks, disks);
@@ -366,6 +375,8 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
void *cb_param_orig = submit->cb_param;
void *p, *q, *s;
+ dmaengine_unmap_put(unmap);
+
pr_debug("%s: (sync) disks: %d len: %zu\n",
__func__, disks, len);
@@ -411,9 +422,9 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
submit->cb_param = cb_param_orig;
submit->flags = flags_orig;
async_tx_sync_epilog(submit);
-
- return NULL;
}
+
+ return NULL;
}
EXPORT_SYMBOL_GPL(async_syndrome_val);
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 3c562f5..d540ac6 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -182,33 +182,36 @@ async_xor(struct page *dest, struct page **src_list, unsigned int offset,
BUG_ON(src_cnt <= 1);
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, src_cnt+1, GFP_NOIO);
-
- if (unmap && is_dma_xor_aligned(device, offset, 0, len)) {
+ if (device && is_dma_xor_aligned(device, offset, 0, len)) {
struct dma_async_tx_descriptor *tx;
int i, j;
/* run the xor asynchronously */
pr_debug("%s (async): len: %zu\n", __func__, len);
- unmap->len = len;
- for (i = 0, j = 0; i < src_cnt; i++) {
- if (!src_list[i])
- continue;
- unmap->to_cnt++;
- unmap->addr[j++] = dma_map_page(device->dev, src_list[i],
- offset, len, DMA_TO_DEVICE);
- }
+ unmap = dmaengine_get_unmap_data(device->dev, src_cnt + 1,
+ GFP_NOIO);
+ if (unmap) {
+ unmap->len = len;
+ for (i = 0, j = 0; i < src_cnt; i++) {
+ if (!src_list[i])
+ continue;
+ unmap->to_cnt++;
+ unmap->addr[j++] = dma_map_page(device->dev,
+ src_list[i],
+ offset, len,
+ DMA_TO_DEVICE);
+ }
- /* map it bidirectional as it may be re-used as a source */
- unmap->addr[j] = dma_map_page(device->dev, dest, offset, len,
- DMA_BIDIRECTIONAL);
- unmap->bidi_cnt = 1;
+ /* map it bidirectional as it may be re-used as a source */
+ unmap->addr[j] = dma_map_page(device->dev, dest, offset,
+ len, DMA_BIDIRECTIONAL);
+ unmap->bidi_cnt = 1;
- tx = do_async_xor(chan, unmap, submit);
- dmaengine_unmap_put(unmap);
- return tx;
+ tx = do_async_xor(chan, unmap, submit);
+ dmaengine_unmap_put(unmap);
+ return tx;
+ }
} else {
dmaengine_unmap_put(unmap);
/* run the xor synchronously */
@@ -228,9 +231,9 @@ async_xor(struct page *dest, struct page **src_list, unsigned int offset,
async_tx_quiesce(&submit->depend_tx);
do_sync_xor(dest, src_list, offset, src_cnt, len, submit);
-
- return NULL;
}
+
+ return NULL;
}
EXPORT_SYMBOL_GPL(async_xor);
@@ -278,10 +281,7 @@ async_xor_val(struct page *dest, struct page **src_list, unsigned int offset,
BUG_ON(src_cnt <= 1);
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, src_cnt, GFP_NOIO);
-
- if (unmap && src_cnt <= device->max_xor &&
+ if (device && src_cnt <= device->max_xor &&
is_dma_xor_aligned(device, offset, 0, len)) {
unsigned long dma_prep_flags = 0;
int i;
@@ -293,31 +293,39 @@ async_xor_val(struct page *dest, struct page **src_list, unsigned int offset,
if (submit->flags & ASYNC_TX_FENCE)
dma_prep_flags |= DMA_PREP_FENCE;
- for (i = 0; i < src_cnt; i++) {
- unmap->addr[i] = dma_map_page(device->dev, src_list[i],
- offset, len, DMA_TO_DEVICE);
- unmap->to_cnt++;
- }
- unmap->len = len;
-
- tx = device->device_prep_dma_xor_val(chan, unmap->addr, src_cnt,
- len, result,
- dma_prep_flags);
- if (unlikely(!tx)) {
- async_tx_quiesce(&submit->depend_tx);
-
- while (!tx) {
- dma_async_issue_pending(chan);
- tx = device->device_prep_dma_xor_val(chan,
- unmap->addr, src_cnt, len, result,
- dma_prep_flags);
+ unmap = dmaengine_get_unmap_data(device->dev, src_cnt,
+ GFP_NOIO);
+ if (unmap) {
+ for (i = 0; i < src_cnt; i++) {
+ unmap->addr[i] = dma_map_page(device->dev,
+ src_list[i],
+ offset, len,
+ DMA_TO_DEVICE);
+ unmap->to_cnt++;
+ }
+ unmap->len = len;
+
+ tx = device->device_prep_dma_xor_val(chan, unmap->addr,
+ src_cnt,
+ len, result,
+ dma_prep_flags);
+ if (unlikely(!tx)) {
+ async_tx_quiesce(&submit->depend_tx);
+
+ while (!tx) {
+ dma_async_issue_pending(chan);
+ tx = device->device_prep_dma_xor_val(chan,
+ unmap->addr, src_cnt, len,
+ result, dma_prep_flags);
+ }
}
+ dma_set_unmap(tx, unmap);
+ async_tx_submit(chan, tx, submit);
}
- dma_set_unmap(tx, unmap);
- async_tx_submit(chan, tx, submit);
} else {
enum async_tx_flags flags_orig = submit->flags;
+ dmaengine_unmap_put(unmap);
pr_debug("%s: (sync) len: %zu\n", __func__, len);
WARN_ONCE(device && src_cnt <= device->max_xor,
"%s: no space for dma address conversion\n",
@@ -335,8 +343,6 @@ async_xor_val(struct page *dest, struct page **src_list, unsigned int offset,
async_tx_sync_epilog(submit);
submit->flags = flags_orig;
}
- dmaengine_unmap_put(unmap);
-
return tx;
}
EXPORT_SYMBOL_GPL(async_xor_val);
--
1.8.3.2
^ permalink raw reply related
* RE: [PATCH] fix dmaengine_unmap failure.
From: Xuelin Shi @ 2014-03-19 6:39 UTC (permalink / raw)
To: Dan Williams; +Cc: Vinod Koul, dmaengine@vger.kernel.org, linuxppc-dev
In-Reply-To: <CAPcyv4gs-jos5TvfDbsaXTNebQf8VjJvbdjmjsbGZLZwZKi34g@mail.gmail.com>
SGkgRGFuLA0KDQpJbiBhc3luY19tdWx0KC4uLikgb2YgYXN5bmNfcmFpZDZfcmVjb3YuYywgdGhl
IGNvdW50IDMgaXMgdXNlZCB0byByZXF1ZXN0IGFuIHVubWFwLg0KSG93ZXZlciB0aGUgdG9fY250
IGFuZCBiaWRpX2NudCBhcmUgYm90aCBzZXQgdG8gMSBhbmQgZnJvbV9jbnQgdG8gMC4NClRoZW4g
d2hpbGUgdHJ5aW5nIHRvIGRvIHVubWFwLCB3ZSBhcmUgZ2V0dGluZyB0aGUgd3JvbmcgInVubWFw
IiBmcm9tIGEgZGlmZmVyZW50IG1lbXBvb2wuDQoNCkluIHRoaXMgcGF0Y2gsIHRoZSBtZW1wb29s
IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgdW5tYXAgc3RydWN0dXJlIGluc3RlYWQgb2YgY29tcHV0
aW5nIGl0IGFnYWluLg0KQnkgdGhpcyB3YXksIGl0IGlzIGd1YXJhbnRlZWQgdGhhdCB0aGUgdW5t
YXAgaXMgdGhlIHNhbWUgd2hlbiB3ZSBnZXQgYW5kIHB1dCB0aGUgdW5tYXAgZGF0YS4NCg0KQlRX
OiB0aGUgbWVtcG9vbCBpcyBqdXN0IHVzZWQgdG8gbWFuYWdlIHRoZSBzdHJ1Y3QgdW5tYXAsIG5v
dCB0aGUgcGFnZXMuDQoNClRoYW5rcywNClh1ZWxpbiBTaGkNCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogRGFuIFdpbGxpYW1zIFttYWlsdG86ZGFuLmoud2lsbGlhbXNAaW50
ZWwuY29tXSANClNlbnQ6IDIwMTTE6jPUwjE5yNUgMToxNA0KVG86IFNoaSBYdWVsaW4tQjI5MjM3
DQpDYzogVmlub2QgS291bDsgbGludXhwcGMtZGV2OyBkbWFlbmdpbmVAdmdlci5rZXJuZWwub3Jn
DQpTdWJqZWN0OiBSZTogW1BBVENIXSBmaXggZG1hZW5naW5lX3VubWFwIGZhaWx1cmUuDQoNCk9u
IFR1ZSwgTWFyIDE4LCAyMDE0IGF0IDE6MzIgQU0sICA8eHVlbGluLnNoaUBmcmVlc2NhbGUuY29t
PiB3cm90ZToNCj4gRnJvbTogWHVlbGluIFNoaSA8eHVlbGluLnNoaUBmcmVlc2NhbGUuY29tPg0K
Pg0KPiBUaGUgY291bnQgd2hpY2ggaXMgdXNlZCB0byBnZXRfdW5tYXBfZGF0YSBtYXliZSBub3Qg
dGhlIHNhbWUgYXMgdGhlIA0KPiBjb3VudCBjb21wdXRlZCBpbiBkbWFlbmdpbmVfdW5tYXAgd2hp
Y2ggY2F1c2VzIHRvIGZyZWUgZGF0YSBpbiBhIHdyb25nIA0KPiBwb29sLg0KPg0KPiBUaGlzIHBh
dGNoIGZpeGVzIHRoaXMgaXNzdWUgYnkga2VlcGluZyB0aGUgcG9vbCBpbiB1bm1hcF9kYXRhIA0K
PiBzdHJ1Y3R1cmUuDQoNCldvbid0IHRoaXMgZnJlZSB0aGUgZW50aXJlIGNvdW50IGFueXdheXM/
ICBJbiB3aGF0IHNjZW5hcmlvIGlzIHRoZSBjb3VudCBkaWZmZXJlbnQgYXQgdW5tYXA/DQoNCg0K
^ permalink raw reply
* Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
From: Srivatsa S. Bhat @ 2014-03-19 6:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Gautham R. Shenoy, linuxppc-dev
In-Reply-To: <1395185847.30666.22.camel@pasglop>
On 03/19/2014 05:07 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
>> From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>
>> Create a helper method that computes the cpumask corresponding to the
>> thread-siblings of a cpu. Use this for initializing the policy->cpus
>> mask for a given cpu.
>>
>> (Original code written by Srivatsa S. Bhat. Gautham moved this to a
>> helper function!)
>
> How does that differ from the existing entry in the sibling map which
> you can obtain with the helper cpu_sibling_mask() ? (You probably want
> to *copy* the mask of course but I don't see the need of re-creating
> one from scratch).
>
The intent here was to have a sibling mask that is invariant of CPU
hotplug. cpu_sibling_mask is updated on every hotplug operation, and this
would break cpufreq, since policy->cpus has to be hotplug invariant.
This should have been noted in the changelog of patch 1 as well as this
patch. (The earlier (internal) versions of this patchset had the
description in the changelogs, but somehow it got dropped accidentally).
I'll work with Gautham and ensure that we have this important info
included in the changelog. Thanks for pointing it out!
Regards,
Srivatsa S. Bhat
> Also, this should have been CCed to the cpufreq mailing list and maybe
> the relevant maintainer too.
>
> Cheers,
> Ben.
>
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
>> ---
>> drivers/cpufreq/powernv-cpufreq.c | 24 ++++++++++++++++++------
>> 1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
>> index ab1551f..4cad727 100644
>> --- a/drivers/cpufreq/powernv-cpufreq.c
>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>> @@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
>>
>> /* Helper routines */
>>
>> +/**
>> + * Sets the bits corresponding to the thread-siblings of cpu in its core
>> + * in 'cpus'.
>> + */
>> +static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
>> +{
>> + int base, i;
>> +
>> + base = cpu_first_thread_sibling(cpu);
>> +
>> + for (i = 0; i < threads_per_core; i++) {
>> + cpumask_set_cpu(base + i, cpus);
>> + }
>> +
>> + return;
>> +}
>> +
>> /* Access helpers to power mgt SPR */
>>
>> static inline unsigned long get_pmspr(unsigned long sprn)
>> @@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus, unsigned int new_index)
>>
>> static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
>> {
>> - int base, i;
>> -
>> #ifdef CONFIG_SMP
>> - base = cpu_first_thread_sibling(policy->cpu);
>> -
>> - for (i = 0; i < threads_per_core; i++)
>> - cpumask_set_cpu(base + i, policy->cpus);
>> + powernv_cpu_to_core_mask(policy->cpu, policy->cpus);
>> #endif
>> policy->cpuinfo.transition_latency = 25000;
>>
>
>
^ permalink raw reply
* Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Chenhui Zhao @ 2014-03-19 0:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <1395182529.12479.223.camel@snotra.buserror.net>
On Tue, Mar 18, 2014 at 05:42:09PM -0500, Scott Wood wrote:
> On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
> > On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
> > > On Wed, 2014-03-12 at 18:40 +0800, Chenhui Zhao wrote:
> > > > On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > > From: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > > >
> > > > > > T1040 supports deep sleep feature, which can switch off most parts of
> > > > > > the SoC when it is in deep sleep mode. This way, it becomes more
> > > > > > energy-efficient.
> > > > > >
> > > > > > The DDR controller will also be powered off in deep sleep. Therefore,
> > > > > > the last stage (the latter part of fsl_dp_enter_low) will run without DDR
> > > > > > access. This piece of code and related TLBs will be prefetched.
> > > > > >
> > > > > > Due to the different initialization code between 32-bit and 64-bit, they
> > > > > > have seperate resume entry and precedure.
> > > > > >
> > > > > > The feature supports 32-bit and 64-bit kernel mode.
> > > > > >
> > > > > > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > > > ---
> > > > > > arch/powerpc/include/asm/booke_save_regs.h | 3 +
> > > > > > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 17 ++
> > > > > > arch/powerpc/kernel/head_fsl_booke.S | 30 +++
> > > > > > arch/powerpc/platforms/85xx/Makefile | 2 +-
> > > > > > arch/powerpc/platforms/85xx/deepsleep.c | 201 +++++++++++++++++++
> > > > > > arch/powerpc/platforms/85xx/qoriq_pm.c | 38 ++++
> > > > > > arch/powerpc/platforms/85xx/sleep.S | 295 ++++++++++++++++++++++++++++
> > > > > > arch/powerpc/sysdev/fsl_soc.h | 7 +
> > > > > > 8 files changed, 592 insertions(+), 1 deletions(-)
> > > > > > create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> > > > > > create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> > > > > >
> > > > > > diff --git a/arch/powerpc/include/asm/booke_save_regs.h b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > index 87c357a..37c1f6c 100644
> > > > > > --- a/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > @@ -88,6 +88,9 @@
> > > > > > #define HIBERNATION_FLAG 1
> > > > > > #define DEEPSLEEP_FLAG 2
> > > > > >
> > > > > > +#define CPLD_FLAG 1
> > > > > > +#define FPGA_FLAG 2
> > > > >
> > > > > What is this?
> > > >
> > > > We have two kind of boards, QDS and RDB.
> > > > They have different register map. Use the flag to indicate the current board is using which kind
> > > > of register map.
> > >
> > > CPLD versus FPGA is not a meaningful difference. We don't care what
> > > technology is used to implement programmable logic -- we care what
> > > programming interface is exposed. Customers will have their own boards
> > > that will likely not imitate either of these programming interfaces, but
> > > what they do have will still probably be implemented in a CPLD or FPGA.
> > > Likewise, Freescale may have future reference boards whose CPLD/FPGA is
> > > not compatible.
> >
> > Will use a better name.
> >
> > >
> > > So use better naming, and structure the code so it's easy to plug in
> > > implementations for new or custom boards.
> > >
> > > > > > diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > index 20204fe..3285752 100644
> > > > > > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > @@ -162,6 +162,19 @@ _ENTRY(__early_start)
> > > > > > #include "fsl_booke_entry_mapping.S"
> > > > > > #undef ENTRY_MAPPING_BOOT_SETUP
> > > > > >
> > > > > > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > > > > > + /* if deep_sleep_flag != 0, jump to the deep sleep resume entry */
> > > > > > + LOAD_REG_ADDR(r4, deep_sleep_flag)
> > > > > > + lwz r3, 0(r4)
> > > > > > + cmpwi r3, 0
> > > > > > + beq 11f
> > > > > > + /* clear deep_sleep_flag */
> > > > > > + li r3, 0
> > > > > > + stw r3, 0(r4)
> > > > > > + b fsl_deepsleep_resume
> > > > > > +11:
> > > > > > +#endif
> > > > >
> > > > > Why do you come in via the normal kernel entry, versus specifying a
> > > > > direct entry point for deep sleep resume? How does U-Boot even know
> > > > > what the normal entry is when resuming?
> > > >
> > > > I wish to return to a specified point (like 64-bit mode), but the code in
> > > > fsl_booke_entry_mapping.S only can run in the first page. Because it
> > > > only setups a temp mapping of 4KB.
> > >
> > > Why do you need the entry mapping on 32-bit but not 64-bit?
> >
> > fsl_booke_entry_mapping.S is for 32-bit. 64-bit calls
> > initial_tlb_book3e() in exceptions-64e.S.
>
> The answer I was looking for is that __entry_deep_sleep calls
> start_initialization_book3e which calls the code to handle it.
>
> But why is it driven from sleep.S on 64-bit but not on 32-bit? Why
> can't you make it so that the 32-bit TLB setup can be called into in a
> similar manner?
Yes. I also wish to do like this. As I mentioned, the problem in 32-bit
is that the TLB setup code in fsl_booke_entry_mapping.S only setups a temp
mapping of 4KB, so these code only can run in this 4KB address space. But the
code in sleep.S is outside of the 4KB space. So can't put the TLB setup
code in sleep.S. There are two method to solve it.
1) The current method is running the TLB setup code of fsl_booke_entry_mapping.S in the 4KB
space, then jump to the code of sleep.S.
2) extend the temp mapping space in the TLB setup code to cover kernel, say 4MB or 8MB. But
not sure if there are any side effects.
>
> > > > > > +#define FSLDELAY(count) \
> > > > > > + li r3, (count)@l; \
> > > > > > + slwi r3, r3, 10; \
> > > > > > + mtctr r3; \
> > > > > > +101: nop; \
> > > > > > + bdnz 101b;
> > > > >
> > > > > You don't need a namespace prefix on local macros in a non-header file.
> > > > >
> > > > > Is the timebase stopped where you're calling this from?
> > > >
> > > > No. My purpose is to avoid jump in the last stage of entering deep sleep.
> > > > Jump may cause problem at that time.
> > >
> > > "bdnz" is a jump.
> > >
> > > What problems do you think a jump will cause?
> >
> > I mean a far jump which can jump to an address which has not been prefetched in
> > advance. I wish the code is executed in a restricted environment (predictable code
> > and address).
>
> Why would a timebase loop require a "far" jump?
I mean there is far jump in udely().
Do you mean using a timebase loop in the macro FSLDELAY? If so, I agree.
>
> > > > > You also probably want to do a "sync, readback, data dependency, isync"
> > > > > sequence to make sure that the store has hit CCSR before you begin your
> > > > > delay (or is a delay required at all if you do that?).
> > > >
> > > > Yes. It is safer with a sync sequence.
> > > >
> > > > The DDR controller need some time to signal the external DDR modules to
> > > > enter self refresh mode.
> > >
> > > Is it documented how much time it requires?
> > >
> > > -Scott
> >
> > No.
>
> How do you know the current delay is adequate in all circumstances (e.g
> clock speeds), much less on future chips? Is it documented that a delay
> is needed at all, or is this just something that appeared to make it
> work? If the latter, what happens if you put the synchronization in,
> but leave out the delay?
>
> -Scott
The code controls external parts (FPGA/CPLD, DDR module) to act, and
the sequent code must wait until external parts complete. We can't get
an ack from external parts, so use delay to make sure the sequence and
insert enough time to wait.
-Chenhui
^ permalink raw reply
* Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
From: Chenhui Zhao @ 2014-03-19 0:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <1395184882.12479.253.camel@snotra.buserror.net>
On Tue, Mar 18, 2014 at 06:21:22PM -0500, Scott Wood wrote:
> On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote:
> > On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote:
> > > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote:
> > > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote:
> > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > > + /* Configure the EPU Counters */
> > > > > > + epu_write(EPCCR15, 0x92840000);
> > > > > > + epu_write(EPCCR14, 0x92840000);
> > > > > > + epu_write(EPCCR12, 0x92840000);
> > > > > > + epu_write(EPCCR11, 0x92840000);
> > > > > > + epu_write(EPCCR10, 0x92840000);
> > > > > > + epu_write(EPCCR9, 0x92840000);
> > > > > > + epu_write(EPCCR8, 0x92840000);
> > > > > > + epu_write(EPCCR5, 0x92840000);
> > > > > > + epu_write(EPCCR4, 0x92840000);
> > > > > > + epu_write(EPCCR2, 0x92840000);
> > > > > > +
> > > > > > + /* Configure the SCUs Inputs */
> > > > > > + epu_write(EPSMCR15, 0x76000000);
> > > > > > + epu_write(EPSMCR14, 0x00000031);
> > > > > > + epu_write(EPSMCR13, 0x00003100);
> > > > > > + epu_write(EPSMCR12, 0x7F000000);
> > > > > > + epu_write(EPSMCR11, 0x31740000);
> > > > > > + epu_write(EPSMCR10, 0x65000030);
> > > > > > + epu_write(EPSMCR9, 0x00003000);
> > > > > > + epu_write(EPSMCR8, 0x64300000);
> > > > > > + epu_write(EPSMCR7, 0x30000000);
> > > > > > + epu_write(EPSMCR6, 0x7C000000);
> > > > > > + epu_write(EPSMCR5, 0x00002E00);
> > > > > > + epu_write(EPSMCR4, 0x002F0000);
> > > > > > + epu_write(EPSMCR3, 0x2F000000);
> > > > > > + epu_write(EPSMCR2, 0x6C700000);
> > > > >
> > > > > Where do these magic numbers come from? Which chips are they valid for?
> > > >
> > > > They are for T1040. Can be found in the RCPM chapter of T1040RM.
> > >
> > > Then put in a comment to that effect, including what part of the RCPM
> > > chapter.
> > >
> > > How do you plan to handle the addition of another SoC with different
> > > values?
> > >
> > > -Scott
> >
> > Had thought that using an array to put these values (pairs of offset and value)
> > and passing the array to the function.
>
> Arrays are better than a long sequence of function calls in any case.
>
> > However, luckily T104x and LS1 have same values for these registers
> > according to the current Reference Manuals.
>
> If it's likely that the values will remain the same on all chips for the
> near future, then a fancy mechanism to select the array to use can wait
> -- but you should still use an array, and have a comment acknowledging
> the possibility of needing to accommodate different values in the
> future.
>
> -Scott
OK. Will use an array to pass the values.
-Chenhui
^ permalink raw reply
* Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
From: Benjamin Herrenschmidt @ 2014-03-18 23:37 UTC (permalink / raw)
To: Gautham R. Shenoy; +Cc: linuxppc-dev, srivatsa.bhat
In-Reply-To: <1394449861-8688-3-git-send-email-ego@linux.vnet.ibm.com>
On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
> From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>
> Create a helper method that computes the cpumask corresponding to the
> thread-siblings of a cpu. Use this for initializing the policy->cpus
> mask for a given cpu.
>
> (Original code written by Srivatsa S. Bhat. Gautham moved this to a
> helper function!)
How does that differ from the existing entry in the sibling map which
you can obtain with the helper cpu_sibling_mask() ? (You probably want
to *copy* the mask of course but I don't see the need of re-creating
one from scratch).
Also, this should have been CCed to the cpufreq mailing list and maybe
the relevant maintainer too.
Cheers,
Ben.
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index ab1551f..4cad727 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
>
> /* Helper routines */
>
> +/**
> + * Sets the bits corresponding to the thread-siblings of cpu in its core
> + * in 'cpus'.
> + */
> +static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
> +{
> + int base, i;
> +
> + base = cpu_first_thread_sibling(cpu);
> +
> + for (i = 0; i < threads_per_core; i++) {
> + cpumask_set_cpu(base + i, cpus);
> + }
> +
> + return;
> +}
> +
> /* Access helpers to power mgt SPR */
>
> static inline unsigned long get_pmspr(unsigned long sprn)
> @@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus, unsigned int new_index)
>
> static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
> {
> - int base, i;
> -
> #ifdef CONFIG_SMP
> - base = cpu_first_thread_sibling(policy->cpu);
> -
> - for (i = 0; i < threads_per_core; i++)
> - cpumask_set_cpu(base + i, policy->cpus);
> + powernv_cpu_to_core_mask(policy->cpu, policy->cpus);
> #endif
> policy->cpuinfo.transition_latency = 25000;
>
^ permalink raw reply
* Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
From: Scott Wood @ 2014-03-18 23:21 UTC (permalink / raw)
To: Chenhui Zhao; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <20140317102727.GB6204@localhost.localdomain>
On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote:
> On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote:
> > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote:
> > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote:
> > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > + /* Configure the EPU Counters */
> > > > > + epu_write(EPCCR15, 0x92840000);
> > > > > + epu_write(EPCCR14, 0x92840000);
> > > > > + epu_write(EPCCR12, 0x92840000);
> > > > > + epu_write(EPCCR11, 0x92840000);
> > > > > + epu_write(EPCCR10, 0x92840000);
> > > > > + epu_write(EPCCR9, 0x92840000);
> > > > > + epu_write(EPCCR8, 0x92840000);
> > > > > + epu_write(EPCCR5, 0x92840000);
> > > > > + epu_write(EPCCR4, 0x92840000);
> > > > > + epu_write(EPCCR2, 0x92840000);
> > > > > +
> > > > > + /* Configure the SCUs Inputs */
> > > > > + epu_write(EPSMCR15, 0x76000000);
> > > > > + epu_write(EPSMCR14, 0x00000031);
> > > > > + epu_write(EPSMCR13, 0x00003100);
> > > > > + epu_write(EPSMCR12, 0x7F000000);
> > > > > + epu_write(EPSMCR11, 0x31740000);
> > > > > + epu_write(EPSMCR10, 0x65000030);
> > > > > + epu_write(EPSMCR9, 0x00003000);
> > > > > + epu_write(EPSMCR8, 0x64300000);
> > > > > + epu_write(EPSMCR7, 0x30000000);
> > > > > + epu_write(EPSMCR6, 0x7C000000);
> > > > > + epu_write(EPSMCR5, 0x00002E00);
> > > > > + epu_write(EPSMCR4, 0x002F0000);
> > > > > + epu_write(EPSMCR3, 0x2F000000);
> > > > > + epu_write(EPSMCR2, 0x6C700000);
> > > >
> > > > Where do these magic numbers come from? Which chips are they valid for?
> > >
> > > They are for T1040. Can be found in the RCPM chapter of T1040RM.
> >
> > Then put in a comment to that effect, including what part of the RCPM
> > chapter.
> >
> > How do you plan to handle the addition of another SoC with different
> > values?
> >
> > -Scott
>
> Had thought that using an array to put these values (pairs of offset and value)
> and passing the array to the function.
Arrays are better than a long sequence of function calls in any case.
> However, luckily T104x and LS1 have same values for these registers
> according to the current Reference Manuals.
If it's likely that the values will remain the same on all chips for the
near future, then a fancy mechanism to select the array to use can wait
-- but you should still use an array, and have a comment acknowledging
the possibility of needing to accommodate different values in the
future.
-Scott
^ permalink raw reply
* Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Scott Wood @ 2014-03-18 23:18 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc-dev, Chenhui Zhao, Jason.Jin, linux-kernel
In-Reply-To: <20140316045801.GA32188@pek-khao-d1.corp.ad.wrs.com>
On Sun, 2014-03-16 at 12:58 +0800, Kevin Hao wrote:
> On Fri, Mar 14, 2014 at 05:26:27PM -0500, Scott Wood wrote:
> > On Thu, 2014-03-13 at 15:46 +0800, Kevin Hao wrote:
> > > On Wed, Mar 12, 2014 at 12:43:05PM -0500, Scott Wood wrote:
> > > > > Shouldn't we use "readback, sync" here? The following is quoted form t4240RM:
> > > > > To guarantee that the results of any sequence of writes to configuration
> > > > > registers are in effect, the final configuration register write should be
> > > > > immediately followed by a read of the same register, and that should be
> > > > > followed by a SYNC instruction. Then accesses can safely be made to memory
> > > > > regions affected by the configuration register write.
> > > >
> > > > I agree that the sync before the readback is probably not necessary,
> > > > since transactions to the same address should already be ordered.
> > > >
> > > > A sync after the readback helps if you're trying to order the readback
> > > > with subsequent memory accesses, though in that case wouldn't a sync
> > > > alone (no readback) be adequate?
> > >
> > > No, we don't just want to order the subsequent memory access here.
> > > The 'write, readback, sync' is the required sequence if we want to make
> > > sure that the writing to CCSR register does really take effect.
> > >
> > > > Though maybe not always -- see the
> > > > comment near the end of fsl_elbc_write_buf() in
> > > > drivers/mtd/nand_fsl_elbc.c. I guess the readback does more than just
> > > > make sure the device has seen the write, ensuring that the device has
> > > > finished the transaction to the point of acting on another one.
> > >
> > > Agree.
> > >
> > > >
> > > > The data dependency plus isync sequence, which is done by the normal I/O
> > > > accessors used from C code, orders the readback versus all future
> > > > instructions (not just I/O). The delay loop is not I/O.
> > >
> > > According to the PowerISA, the sequence 'load, date dependency, isync' only
> > > order the load accesses.
> >
> > The point is to order the delay loop after the load, not to order
> > storage versus storage.
>
> I think the point is to make sure that the writing of the CCSR_DDR_SDRAM_CFG_2
> does really take effect before we begin to delay loop.
Yes.
> The sequence "write, readback, sync" will guarantee this according to the manual.
If you're referring to the section you quoted above, the manual does not
say that. It only talks about when accesses "to memory regions affected
by the configuration register write" can be safely made.
> If we just want to
> order the delay loop after the load, the following sequence should be enough:
> store to CCSR_DDR_SDRAM_CFG_2
> load from CCSR_DDR_SDRAM_CFG_2
> isync or sync
> delay loop
>
> Why do we need the 'date dependency' here? According to the e6500 manual, the
> instructions can execute out of order, but complete in order. So I am really
> wondering why we need to order the load and the following delay loop if there
> is no intention to order the storage access?
The data (not date) dependency means that the twi will not execute until
after the load instruction returns data (thus, after the device has
responded to the load). The twi, being a flow control instruction
rather than a storage instruction, should be fully ordered by isync.
>From the isync description in the ISA: "Except as described in the
preceding sentence, the isync instruction may complete before storage
accesses associated with instructions preceding the
isync instruction have been performed."
I don't know if that really applies to loads (as opposed to stores), and
it probably doesn't apply to guarded loads, but I feel safer leaving the
twi in.
As for sync instead of isync, I see nothing to indicate that it would be
adequate (though it may be that the only reason there needed to be a
delay loop in the first place was the lack of a readback/sync before
doing other I/O, in which case this is moot).
> > This is a sequence we're already using on all of our I/O loads
> > (excluding accesses like in this patch that don't use the standard
> > accessors). I'm confident that it works even if it's not
> > architecturally guaranteed.
>
> This sequence is used to order the load and the followed storage access.
It's also used to order loads versus other things, such as enabling
MSR[EE].
> And this is guaranteed by the architecture. But I don't think it is suitable
> for a case like this. The following is quoted from PowerISA:
> Because stores cannot be performed “out-of-order”
> (see Book III), if a Store instruction depends on the
> value returned by a preceding Load instruction
> (because the value returned by the Load is used to
> compute either the effective address specified by the
> Store or the value to be stored), the corresponding stor-
> age accesses are performed in program order. The
> same applies if whether the Store instruction is exe-
> cuted depends on a conditional Branch instruction that
> in turn depends on the value returned by a preceding
> Load instruction.
>
> Because an isync instruction prevents the execution of
> instructions following the isync until instructions pre-
> ceding the isync have completed, if an isync follows a
> conditional Branch instruction that depends on the
> value returned by a preceding Load instruction, the
> load on which the Branch depends is performed before
> any loads caused by instructions following the isync.
>
> I think the above description would guarantee that the load will be performed
> before any storage access (both load and store) following the isync in the
> following scenario:
> lwz r4, 0(r3)
> twi 0, r4, 0
> isync
I think it's a poorly worded section, but yes, it guarantees both loads
and stores -- unnecessarily doing so in separate places with different
wording. But by the definition of isync I don't see why it does not
apply to *any* instruction after the isync, not just loads and stores.
> > I'm not sure that there exists a clear
> > architectural way of synchronizing non-storage instructions relative to
> > storage instructions.
>
> Isn't what the execution synchronization instructions such as sync, isync, mtmsr
> do?
No. Execution synchronizing just says that the previous instructions
"have completed to a point at which they have reported all the
exceptions they will cause" (I'm assuming this doesn't include machine
check error reports), and that the previous instructions won't be
affected by context changes after the execution synchronizing
instruction, not that the previous instructions are fully completed.
> > Given that isync is documented as preventing any execution of
> > instructions after the isync until all previous instructions complete,
> > it doesn't seem to make sense for the architecture to explicitly talk
> > about loads (as opposed to any other instruction) following a load,
> > dependent conditional branch, isync sequence.
>
> Sorry, I didn't get what you mean.
I mean that I do not understand why it says, "the load on which the
Branch depends is performed before any loads caused by instructions
following the isync" rather than "the Load on which the Branch depends
is performed before any instructions following the isync".
> > > So if we want to order all the storage access as well
> > > as execution synchronization, we should choose sync here.
> >
> > Do we need execution synchronization or context synchronization?
>
> There is no context-altering instruction here, so I think an execution
> synchronizing instruction should be enough here.
Is the ISA ever explicit about what constitutes "context"? In any case,
just because we don't need that aspect of context synchronization
doesn't mean execution synchronization is enough. The behavior we want
is described in the isync instruction specifically, not in "context
synchronization" or "execution synchronization".
> > The t4240 RM section that talks about a readback and a sync is in the
> > context of subsequent memory operations ("Then accesses can safely be
> > made to memory regions affected..."), not arbitrary instructions.
>
> I assume that this sequence also guarantee that the writing does take effect.
You may assume that, but the manual doesn't say that. Sync could
(AFAIK) be implemented by emitting a barrier on the bus, or delaying
future storage accesses, rather than waiting for everything to have
finished before proceeding.
> > In any case, this is not performance critical and thus it's better to
> > oversynchronize than undersynchronize.
>
> On the contrary I think that sync is oversynchronize instead of
> undersynchronize. It not only provide the execution synchronizing but also
> order all the storage accesses. That is why I prefer the sync. :-)
sync is not a superset of isync. isync is not a superset of sync. If
you want to oversynchronize to be safe, do both (though even that isn't
equivalent to a barrier that orders everything, which is partly why a
readback is needed).
-Scott
^ permalink raw reply
* Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Scott Wood @ 2014-03-18 22:42 UTC (permalink / raw)
To: Chenhui Zhao; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <20140317111957.GD6204@localhost.localdomain>
On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
> On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
> > On Wed, 2014-03-12 at 18:40 +0800, Chenhui Zhao wrote:
> > > On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > From: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > >
> > > > > T1040 supports deep sleep feature, which can switch off most parts of
> > > > > the SoC when it is in deep sleep mode. This way, it becomes more
> > > > > energy-efficient.
> > > > >
> > > > > The DDR controller will also be powered off in deep sleep. Therefore,
> > > > > the last stage (the latter part of fsl_dp_enter_low) will run without DDR
> > > > > access. This piece of code and related TLBs will be prefetched.
> > > > >
> > > > > Due to the different initialization code between 32-bit and 64-bit, they
> > > > > have seperate resume entry and precedure.
> > > > >
> > > > > The feature supports 32-bit and 64-bit kernel mode.
> > > > >
> > > > > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > > ---
> > > > > arch/powerpc/include/asm/booke_save_regs.h | 3 +
> > > > > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 17 ++
> > > > > arch/powerpc/kernel/head_fsl_booke.S | 30 +++
> > > > > arch/powerpc/platforms/85xx/Makefile | 2 +-
> > > > > arch/powerpc/platforms/85xx/deepsleep.c | 201 +++++++++++++++++++
> > > > > arch/powerpc/platforms/85xx/qoriq_pm.c | 38 ++++
> > > > > arch/powerpc/platforms/85xx/sleep.S | 295 ++++++++++++++++++++++++++++
> > > > > arch/powerpc/sysdev/fsl_soc.h | 7 +
> > > > > 8 files changed, 592 insertions(+), 1 deletions(-)
> > > > > create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> > > > > create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> > > > >
> > > > > diff --git a/arch/powerpc/include/asm/booke_save_regs.h b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > index 87c357a..37c1f6c 100644
> > > > > --- a/arch/powerpc/include/asm/booke_save_regs.h
> > > > > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > @@ -88,6 +88,9 @@
> > > > > #define HIBERNATION_FLAG 1
> > > > > #define DEEPSLEEP_FLAG 2
> > > > >
> > > > > +#define CPLD_FLAG 1
> > > > > +#define FPGA_FLAG 2
> > > >
> > > > What is this?
> > >
> > > We have two kind of boards, QDS and RDB.
> > > They have different register map. Use the flag to indicate the current board is using which kind
> > > of register map.
> >
> > CPLD versus FPGA is not a meaningful difference. We don't care what
> > technology is used to implement programmable logic -- we care what
> > programming interface is exposed. Customers will have their own boards
> > that will likely not imitate either of these programming interfaces, but
> > what they do have will still probably be implemented in a CPLD or FPGA.
> > Likewise, Freescale may have future reference boards whose CPLD/FPGA is
> > not compatible.
>
> Will use a better name.
>
> >
> > So use better naming, and structure the code so it's easy to plug in
> > implementations for new or custom boards.
> >
> > > > > diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > index 20204fe..3285752 100644
> > > > > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > > > > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > @@ -162,6 +162,19 @@ _ENTRY(__early_start)
> > > > > #include "fsl_booke_entry_mapping.S"
> > > > > #undef ENTRY_MAPPING_BOOT_SETUP
> > > > >
> > > > > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > > > > + /* if deep_sleep_flag != 0, jump to the deep sleep resume entry */
> > > > > + LOAD_REG_ADDR(r4, deep_sleep_flag)
> > > > > + lwz r3, 0(r4)
> > > > > + cmpwi r3, 0
> > > > > + beq 11f
> > > > > + /* clear deep_sleep_flag */
> > > > > + li r3, 0
> > > > > + stw r3, 0(r4)
> > > > > + b fsl_deepsleep_resume
> > > > > +11:
> > > > > +#endif
> > > >
> > > > Why do you come in via the normal kernel entry, versus specifying a
> > > > direct entry point for deep sleep resume? How does U-Boot even know
> > > > what the normal entry is when resuming?
> > >
> > > I wish to return to a specified point (like 64-bit mode), but the code in
> > > fsl_booke_entry_mapping.S only can run in the first page. Because it
> > > only setups a temp mapping of 4KB.
> >
> > Why do you need the entry mapping on 32-bit but not 64-bit?
>
> fsl_booke_entry_mapping.S is for 32-bit. 64-bit calls
> initial_tlb_book3e() in exceptions-64e.S.
The answer I was looking for is that __entry_deep_sleep calls
start_initialization_book3e which calls the code to handle it.
But why is it driven from sleep.S on 64-bit but not on 32-bit? Why
can't you make it so that the 32-bit TLB setup can be called into in a
similar manner?
> > > > > +#define FSLDELAY(count) \
> > > > > + li r3, (count)@l; \
> > > > > + slwi r3, r3, 10; \
> > > > > + mtctr r3; \
> > > > > +101: nop; \
> > > > > + bdnz 101b;
> > > >
> > > > You don't need a namespace prefix on local macros in a non-header file.
> > > >
> > > > Is the timebase stopped where you're calling this from?
> > >
> > > No. My purpose is to avoid jump in the last stage of entering deep sleep.
> > > Jump may cause problem at that time.
> >
> > "bdnz" is a jump.
> >
> > What problems do you think a jump will cause?
>
> I mean a far jump which can jump to an address which has not been prefetched in
> advance. I wish the code is executed in a restricted environment (predictable code
> and address).
Why would a timebase loop require a "far" jump?
> > > > You also probably want to do a "sync, readback, data dependency, isync"
> > > > sequence to make sure that the store has hit CCSR before you begin your
> > > > delay (or is a delay required at all if you do that?).
> > >
> > > Yes. It is safer with a sync sequence.
> > >
> > > The DDR controller need some time to signal the external DDR modules to
> > > enter self refresh mode.
> >
> > Is it documented how much time it requires?
> >
> > -Scott
>
> No.
How do you know the current delay is adequate in all circumstances (e.g
clock speeds), much less on future chips? Is it documented that a delay
is needed at all, or is this just something that appeared to make it
work? If the latter, what happens if you put the synchronization in,
but leave out the delay?
-Scott
^ 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