* [PATCH v2 5/6] mm: make clear_huge_page cache clear only around the fault address
From: Kirill A. Shutemov @ 2012-08-09 15:03 UTC (permalink / raw)
To: linux-mm
Cc: linux-mips, linux-sh, Jan Beulich, H. Peter Anvin, sparclinux,
Andrea Arcangeli, Andi Kleen, Robert Richter, x86, Hugh Dickins,
Ingo Molnar, Mel Gorman, Alex Shi, Thomas Gleixner,
KAMEZAWA Hiroyuki, Tim Chen, linux-kernel, Andy Lutomirski,
Johannes Weiner, Andrew Morton, linuxppc-dev, Kirill A. Shutemov
In-Reply-To: <1344524583-1096-1-git-send-email-kirill.shutemov@linux.intel.com>
From: Andi Kleen <ak@linux.intel.com>
Clearing a 2MB huge page will typically blow away several levels
of CPU caches. To avoid this only cache clear the 4K area
around the fault address and use a cache avoiding clears
for the rest of the 2MB area.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
mm/memory.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index b47199a..e9a75c2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3969,18 +3969,35 @@ EXPORT_SYMBOL(might_fault);
#endif
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS)
+
+#ifndef ARCH_HAS_USER_NOCACHE
+#define ARCH_HAS_USER_NOCACHE 0
+#endif
+
+#if ARCH_HAS_USER_NOCACHE == 0
+#define clear_user_highpage_nocache clear_user_highpage
+#endif
+
static void clear_gigantic_page(struct page *page,
unsigned long addr,
unsigned int pages_per_huge_page)
{
int i;
struct page *p = page;
+ unsigned long vaddr;
+ unsigned long haddr = addr & HPAGE_PMD_MASK;
+ int target = (addr - haddr) >> PAGE_SHIFT;
might_sleep();
+ vaddr = haddr;
for (i = 0; i < pages_per_huge_page;
i++, p = mem_map_next(p, page, i)) {
cond_resched();
- clear_user_highpage(p, addr + i * PAGE_SIZE);
+ vaddr = haddr + i*PAGE_SIZE;
+ if (!ARCH_HAS_USER_NOCACHE || i == target)
+ clear_user_highpage(p, vaddr);
+ else
+ clear_user_highpage_nocache(p, vaddr);
}
}
void clear_huge_page(struct page *page,
@@ -3988,16 +4005,23 @@ void clear_huge_page(struct page *page,
{
int i;
unsigned long haddr = addr & HPAGE_PMD_MASK;
+ unsigned long vaddr;
+ int target = (addr - haddr) >> PAGE_SHIFT;
if (unlikely(pages_per_huge_page > MAX_ORDER_NR_PAGES)) {
- clear_gigantic_page(page, haddr, pages_per_huge_page);
+ clear_gigantic_page(page, addr, pages_per_huge_page);
return;
}
might_sleep();
+ vaddr = haddr;
for (i = 0; i < pages_per_huge_page; i++) {
cond_resched();
- clear_user_highpage(page + i, haddr + i * PAGE_SIZE);
+ vaddr = haddr + i*PAGE_SIZE;
+ if (!ARCH_HAS_USER_NOCACHE || i == target)
+ clear_user_highpage(page + i, vaddr);
+ else
+ clear_user_highpage_nocache(page + i, vaddr);
}
}
--
1.7.7.6
^ permalink raw reply related
* [PATCH v2 0/6] Avoid cache trashing on clearing huge/gigantic page
From: Kirill A. Shutemov @ 2012-08-09 15:02 UTC (permalink / raw)
To: linux-mm
Cc: linux-mips, linux-sh, Jan Beulich, H. Peter Anvin, sparclinux,
Andrea Arcangeli, Andi Kleen, Robert Richter, x86, Hugh Dickins,
Ingo Molnar, Mel Gorman, Alex Shi, Thomas Gleixner,
KAMEZAWA Hiroyuki, Tim Chen, linux-kernel, Andy Lutomirski,
Johannes Weiner, Andrew Morton, linuxppc-dev, Kirill A. Shutemov
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Clearing a 2MB huge page will typically blow away several levels of CPU
caches. To avoid this only cache clear the 4K area around the fault
address and use a cache avoiding clears for the rest of the 2MB area.
This patchset implements cache avoiding version of clear_page only for
x86. If an architecture wants to provide cache avoiding version of
clear_page it should to define ARCH_HAS_USER_NOCACHE to 1 and implement
clear_page_nocache() and clear_user_highpage_nocache().
v2:
- No code change. Only commit messages are updated.
- RFC mark is dropped.
Andi Kleen (6):
THP: Use real address for NUMA policy
mm: make clear_huge_page tolerate non aligned address
THP: Pass real, not rounded, address to clear_huge_page
x86: Add clear_page_nocache
mm: make clear_huge_page cache clear only around the fault address
x86: switch the 64bit uncached page clear to SSE/AVX v2
arch/x86/include/asm/page.h | 2 +
arch/x86/include/asm/string_32.h | 5 ++
arch/x86/include/asm/string_64.h | 5 ++
arch/x86/lib/Makefile | 1 +
arch/x86/lib/clear_page_nocache_32.S | 30 +++++++++++
arch/x86/lib/clear_page_nocache_64.S | 92 ++++++++++++++++++++++++++++++++++
arch/x86/mm/fault.c | 7 +++
mm/huge_memory.c | 17 +++---
mm/memory.c | 29 ++++++++++-
9 files changed, 178 insertions(+), 10 deletions(-)
create mode 100644 arch/x86/lib/clear_page_nocache_32.S
create mode 100644 arch/x86/lib/clear_page_nocache_64.S
--
1.7.7.6
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Kumar Gala @ 2012-08-09 13:08 UTC (permalink / raw)
To: Li Yang
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jia Hongtao-B38951
In-Reply-To: <CADRPPNRT3i-cmAtTmCzi4Rt6ohPpvk1U0vNHZZQqbCGeCJ5Cag@mail.gmail.com>
On Aug 9, 2012, at 12:05 AM, Li Yang wrote:
> On Thu, Aug 9, 2012 at 10:52 AM, Jia Hongtao-B38951
> <B38951@freescale.com> wrote:
>>=20
>>=20
>>> -----Original Message-----
>>> From: Linuxppc-dev [mailto:linuxppc-dev-
>>> bounces+b38951=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Kumar =
Gala
>>> Sent: Wednesday, August 08, 2012 8:47 PM
>>> To: Jia Hongtao-B38951
>>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
>>> Subject: Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound =
PM
>>> support
>>>=20
>>>>>>>>>=20
>>>>>>>>> On Jul 24, 2012, at 5:20 AM, Jia Hongtao wrote:
>>>>>>>>>=20
>>>>>>>>>> Power supply for PCI inbound/outbound window registers is off
>>>>>>>>>> when
>>>>>>>>> system
>>>>>>>>>> go to deep-sleep state. We save the values of registers =
before
>>>>>>>>>> suspend and restore to registers after resume.
>>>>>>>>>>=20
>>>>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>>>>>>> ---
>>>>>>>>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
>>>>>>>>>> arch/powerpc/sysdev/fsl_pci.c | 121
>>>>>>>>> +++++++++++++++++++++++++++++++++
>>>>>>>>>> 2 files changed, 122 insertions(+), 1 deletions(-)
>>>>>>>>>=20
>>>>>>>>> Remind me why we need to save/restore PCI ATMUs, why not just
>>>>>>>>> re-parse the device tree to restore?
>>>>>>>>>=20
>>>>>>>>> - k
>>>>>>>>=20
>>>>>>>> Save/restore is the more efficient way. Latency of sleep/wakeup =
is
>>>>>>>> one of most important features in power management.
>>>>>>>>=20
>>>>>>>> -Hongtao.
>>>>>>>=20
>>>>>>> I don't think the time it takes to run through setup_pci_atmu() =
is
>>>>>>> that long compared to fsl_pci_resume().
>>>>>>>=20
>>>>>>> Also, don't you need to setup PCICCSRBAR and do setup_pci_cmd() =
on
>>>>> resume?
>>>>>>>=20
>>>>>>> - k
>>>>>>=20
>>>>>> Hi Kumar,
>>>>>> I did some tests on P1022DS and found out that PCI_CMD and =
PCICSRBAR
>>>>>> is not lost when system in deep sleep. We don't need to save it.
>>>>>=20
>>>>> How does the PCI code know you're entering deep sleep and not
>>> hibernation?
>>>>>=20
>>>>> -Scott
>>>>=20
>>>> When system come back from hibernation PCI will be initialized =
again.
>>>> So no need to save PCI_CMD and PEXCSRBAR.
>>>>=20
>>>> -Hongtao.
>>>>=20
>>>=20
>>> What do you mean PCI will be initialized again? What code path are =
you
>>> talking about that would set PCI_CMD & PEXCSRBAR?
>>>=20
>>> - k
>>=20
>>=20
>> In hibernation mode:
>>=20
>> When system come back from hibernation kernel will start up again.
>> Before loading hibernation image PCI initialization has already done.
>> Some other hardware also re-init again.
>=20
> In current Linux implementation, restoring from hibernation image is
> using late initcall. By that time, all the platform devices are
> already initialized like a fresh boot.
>=20
> - Leo
I ask against, what specific code path (I'd like a call trace) would =
cause PCI_CMD and PEXCSRBAR to be set in the wakeup case?
- k=
^ permalink raw reply
* RE: [PATCH 3/3 v4] powerpc/mpic: FSL MPIC error interrupt support.
From: Sethi Varun-B16395 @ 2012-08-09 12:29 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Hamciuc Bogdan-BHAMCIU1
In-Reply-To: <50216492.60904@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDgsIDIwMTIgMTI6MjUgQU0NCj4gVG86IFNl
dGhpIFZhcnVuLUIxNjM5NQ0KPiBDYzogS3VtYXIgR2FsYTsgbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmc7IEhhbWNpdWMgQm9nZGFuLUJIQU1DSVUxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
My8zIHY0XSBwb3dlcnBjL21waWM6IEZTTCBNUElDIGVycm9yIGludGVycnVwdA0KPiBzdXBwb3J0
Lg0KPiANCj4gT24gMDgvMDYvMjAxMiAxMToyMiBBTSwgU2V0aGkgVmFydW4tQjE2Mzk1IHdyb3Rl
Og0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog
S3VtYXIgR2FsYSBbbWFpbHRvOmdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmddDQo+ID4+IFNlbnQ6
IE1vbmRheSwgQXVndXN0IDA2LCAyMDEyIDk6MjMgUE0NCj4gPj4gVG86IFNldGhpIFZhcnVuLUIx
NjM5NQ0KPiA+PiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IEhhbWNpdWMgQm9n
ZGFuLUJIQU1DSVUxDQo+ID4+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMy8zIHY0XSBwb3dlcnBjL21w
aWM6IEZTTCBNUElDIGVycm9yIGludGVycnVwdA0KPiA+PiBzdXBwb3J0Lg0KPiA+Pg0KPiA+Pg0K
PiA+PiBPbiBBdWcgNiwgMjAxMiwgYXQgNzo0NCBBTSwgVmFydW4gU2V0aGkgd3JvdGU6DQo+ID4+
DQo+ID4+PiBBbGwgU09DIGRldmljZSBlcnJvciBpbnRlcnJ1cHRzIGFyZSBtdXhlZCBhbmQgZGVs
aXZlcmVkIHRvIHRoZSBjb3JlDQo+ID4+PiBhcyBhIHNpbmdsZSBNUElDIGVycm9yIGludGVycnVw
dC4gQ3VycmVudGx5IGFsbCB0aGUgZGV2aWNlIGRyaXZlcnMNCj4gPj4+IHJlcXVpcmluZyBhY2Nl
c3MgdG8gZGV2aWNlIGVycm9ycyBoYXZlIHRvIHJlZ2lzdGVyIGZvciB0aGUgTVBJQw0KPiA+Pj4g
ZXJyb3IgaW50ZXJydXB0IGFzIGEgc2hhcmVkIGludGVycnVwdC4NCj4gPj4+DQo+ID4+PiBXaXRo
IHRoaXMgcGF0Y2ggd2UgYWRkIGludGVycnVwdCBkZW11eGluZyBjYXBhYmlsaXR5IGluIHRoZSBt
cGljDQo+ID4+PiBkcml2ZXIsIGFsbG93aW5nIGRldmljZSBkcml2ZXJzIHRvIHJlZ2lzdGVyIGZv
ciB0aGVpciBpbmRpdmlkdWFsDQo+ID4+PiBlcnJvcg0KPiA+PiBpbnRlcnJ1cHRzLg0KPiA+Pj4g
VGhpcyBpcyBhY2hpZXZlZCBieSBoYW5kbGluZyBlcnJvciBpbnRlcnJ1cHRzIGluIGEgY2FzY2Fk
ZWQgZmFzaGlvbi4NCj4gPj4+DQo+ID4+PiBNUElDIGVycm9yIGludGVycnVwdCBpcyBoYW5kbGVk
IGJ5IHRoZSAiZXJyb3JfaW50X2hhbmRsZXIiLCB3aGljaA0KPiA+Pj4gc3Vic2VxdWVudGx5IGRl
bXV4ZXMgaXQgdXNpbmcgdGhlIEVJU1IgYW5kIGRlbGl2ZXJzIGl0IHRvIHRoZQ0KPiA+Pj4gcmVz
cGVjdGl2ZSBkcml2ZXJzLg0KPiA+Pj4NCj4gPj4+IFRoZSBlcnJvciBpbnRlcnJ1cHQgY2FwYWJp
bGl0eSBpcyBkZXBlbmRlbnQgb24gdGhlIE1QSUMgRUlNUg0KPiA+Pj4gcmVnaXN0ZXIsIHdoaWNo
IHdhcyBpbnRyb2R1Y2VkIGluIEZTTCBNUElDIHZlcnNpb24gNC4xIChQNDA4MCByZXYyKS4NCj4g
Pj4+IFNvLCBlcnJvciBpbnRlcnJ1cHQgZGVtdXhpbmcgY2FwYWJpbGl0eSBpcyBkZXBlbmRlbnQg
b24gdGhlIE1QSUMNCj4gPj4+IHZlcnNpb24gYW5kIGNhbiBiZSB1c2VkIGZvciB2ZXJzaW9ucyA+
PSA0LjEuDQo+ID4+Pg0KPiA+Pj4gU2lnbmVkLW9mZi1ieTogVmFydW4gU2V0aGkgPFZhcnVuLlNl
dGhpQGZyZWVzY2FsZS5jb20+DQo+ID4+PiBTaWduZWQtb2ZmLWJ5OiBCb2dkYW4gSGFtY2l1YyA8
Ym9nZGFuLmhhbWNpdWNAZnJlZXNjYWxlLmNvbT4gW0luIHRoZQ0KPiA+Pj4gaW5pdGlhbCB2ZXJz
aW9uIG9mIHRoZSBwYXRjaCB3ZSB3ZXJlIHVzaW5nIGhhbmRsZV9zaW1wbGVfaXJxIGFzIHRoZQ0K
PiA+Pj4gaGFuZGxlciBmb3IgY2FzY2FkZWQgZXJyb3IgaW50ZXJydXB0cywgdGhpcyByZXN1bHRl
ZCBpbiBpc3N1ZXMgaW4NCj4gPj4+IGNhc2Ugb2YgdGhyZWFkZWQgaXNycyAod2l0aCBSVCBrZXJu
ZWwpLiBUaGlzIGlzc3VlIHdhcyBkZWJ1Z2dlZCBieQ0KPiA+Pj4gQm9nZGFuIGFuZCBkZWNpc2lv
biB3YXMgdGFrZW4gdG8gdXNlIHRoZSBoYW5kbGVfbGV2ZWxfaXJxIGhhbmRsZXJdDQo+ID4+PiAt
LS0NCj4gPj4+IGFyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9tcGljLmggICAgfCAgIDE2ICsrKysN
Cj4gPj4+IGFyY2gvcG93ZXJwYy9zeXNkZXYvTWFrZWZpbGUgICAgICAgfCAgICAyICstDQo+ID4+
PiBhcmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9tcGljX2Vyci5jIHwgIDE1Mw0KPiA+PiArKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gPj4+IGFyY2gvcG93ZXJwYy9zeXNkZXYv
bXBpYy5jICAgICAgICAgfCAgIDQ1ICsrKysrKysrKystDQo+ID4+PiBhcmNoL3Bvd2VycGMvc3lz
ZGV2L21waWMuaCAgICAgICAgIHwgICAyMiArKysrKw0KPiA+Pj4gNSBmaWxlcyBjaGFuZ2VkLCAy
MzYgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkgY3JlYXRlIG1vZGUNCj4gPj4+IDEwMDY0
NCBhcmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9tcGljX2Vyci5jDQo+ID4+Pg0KPiA+Pj4gZGlmZiAt
LWdpdCBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9tcGljLmgNCj4gPj4+IGIvYXJjaC9wb3dl
cnBjL2luY2x1ZGUvYXNtL21waWMuaCBpbmRleCBlMTRkMzVkLi42YzhlNTNiIDEwMDY0NA0KPiA+
Pj4gLS0tIGEvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL21waWMuaA0KPiA+Pj4gKysrIGIvYXJj
aC9wb3dlcnBjL2luY2x1ZGUvYXNtL21waWMuaA0KPiA+Pj4gQEAgLTExOCw2ICsxMTgsOSBAQA0K
PiA+Pj4gI2RlZmluZSBNUElDX01BWF9DUFVTCQkzMg0KPiA+Pj4gI2RlZmluZSBNUElDX01BWF9J
U1UJCTMyDQo+ID4+Pg0KPiA+Pj4gKyNkZWZpbmUgTVBJQ19NQVhfRVJSICAgICAgMzINCj4gPj4+
ICsjZGVmaW5lIE1QSUNfRlNMX0VSUl9JTlQgIDE2DQo+ID4+PiArDQo+ID4+PiAvKg0KPiA+Pj4g
ICogVHNpMTA4IGltcGxlbWVudGF0aW9uIG9mIE1QSUMgaGFzIG1hbnkgZGlmZmVyZW5jZXMgZnJv
bSB0aGUNCj4gPj4+IG9yaWdpbmFsIG9uZSAgKi8gQEAgLTI3MCw2ICsyNzMsNyBAQCBzdHJ1Y3Qg
bXBpYw0KPiA+Pj4gCXN0cnVjdCBpcnFfY2hpcAkJaGNfaXBpOw0KPiA+Pj4gI2VuZGlmDQo+ID4+
PiAJc3RydWN0IGlycV9jaGlwCQloY190bTsNCj4gPj4+ICsJc3RydWN0IGlycV9jaGlwCQloY19l
cnI7DQo+ID4+PiAJY29uc3QgY2hhcgkJKm5hbWU7DQo+ID4+PiAJLyogRmxhZ3MgKi8NCj4gPj4+
IAl1bnNpZ25lZCBpbnQJCWZsYWdzOw0KPiA+Pj4gQEAgLTI4Myw2ICsyODcsOCBAQCBzdHJ1Y3Qg
bXBpYw0KPiA+Pj4gCS8qIHZlY3RvciBudW1iZXJzIHVzZWQgZm9yIGludGVybmFsIHNvdXJjZXMg
KGlwaS90aW1lcnMpICovDQo+ID4+PiAJdW5zaWduZWQgaW50CQlpcGlfdmVjc1s0XTsNCj4gPj4+
IAl1bnNpZ25lZCBpbnQJCXRpbWVyX3ZlY3NbOF07DQo+ID4+PiArCS8qIHZlY3RvciBudW1iZXJz
IHVzZWQgZm9yIEZTTCBNUElDIGVycm9yIGludGVycnVwdHMgKi8NCj4gPj4+ICsJdW5zaWduZWQg
aW50CQllcnJfaW50X3ZlY3NbTVBJQ19NQVhfRVJSXTsNCj4gPj4+DQo+ID4+PiAJLyogU3B1cmlv
dXMgdmVjdG9yIHRvIHByb2dyYW0gaW50byB1bnVzZWQgc291cmNlcyAqLw0KPiA+Pj4gCXVuc2ln
bmVkIGludAkJc3B1cmlvdXNfdmVjOw0KPiA+Pj4gQEAgLTMwNiw2ICszMTIsMTEgQEAgc3RydWN0
IG1waWMNCj4gPj4+IAlzdHJ1Y3QgbXBpY19yZWdfYmFuawljcHVyZWdzW01QSUNfTUFYX0NQVVNd
Ow0KPiA+Pj4gCXN0cnVjdCBtcGljX3JlZ19iYW5rCWlzdXNbTVBJQ19NQVhfSVNVXTsNCj4gPj4+
DQo+ID4+PiArCS8qIGlvcmVtYXAnZWQgYmFzZSBmb3IgZXJyb3IgaW50ZXJydXB0IHJlZ2lzdGVy
cyAqLw0KPiA+Pj4gKwl1MzIgX19pb21lbQkqZXJyX3JlZ3M7DQo+ID4+PiArCS8qIGVycm9yIGlu
dGVycnVwdCBjb25maWcgKi8NCj4gPj4+ICsJdTMyCQkJZXJyX2ludF9jb25maWdfZG9uZTsNCj4g
Pj4NCj4gPj4gSSB0aG91Z2h0IHdlIHdlcmUgZ29pbmcgdG8gcmVtb3ZlIHRoaXMgYXMgaXQgZG9u
J3QgcmVhbGx5IHByb3ZpZGUgYW55DQo+ID4+IHZhbHVlLg0KPiA+Pg0KPiA+IFtTZXRoaSBWYXJ1
bi1CMTYzOTVdIFdlIG5lZWQgYSB3YXkgdG8gZGV0ZXJtaW5lIHRoYXQgaXJxIGhhbmRsZSBnb3QN
Cj4gPiByZWdpc3RlcmVkIGZvciBNcGljIGVycm9yIGludGVycnVwdCwgb25seSB0aGVuIGNhbiB3
ZSBnbyBhaGVhZCBhbmQNCj4gPiBhc3NpZ24gaW5kaXZpZHVhbCAoY2FzY2FkZWQpIGVycm9yIGlu
dGVycnVwdHMuIEluaXRpYWxseSB3ZSB3ZXJlIGRvaW5nDQo+ID4gdGhlIHNhbWUgdGhpbmcgd2hp
bGUgdHJhbnNsYXRpbmcgZXJyb3IgaW50ZXJydXB0IHNwZWNpZmllciwgbm93IHdlIGFyZQ0KPiBy
ZWdpc3RlcmluZyB0aGUgaGFuZGxlciBpbiBtcGljX2luaXQuDQo+IA0KPiBJZiB5b3UgcmVnaXN0
ZXIgaXQgaW4gbXBpY19pbml0KCksIHdoZW4gd291bGQgeW91IGJlIHVuc3VyZSBhYm91dCB3aGV0
aGVyDQo+IHRoZSByZWdpc3RyYXRpb24gaGFzIGhhcHBlbmVkPw0KPiANCkl0IHdhcyBqdXN0IGEg
c2FuaXR5IGNoZWNrIHRvIGVuc3VyZSB0aGF0IHRoZSBlcnJvciBpbnRlcnJ1cHQgaGFuZGxlciBh
Y3R1YWxseSBnb3QNCnJlZ2lzdGVyZWQgZHVyaW5nIG1waWNfaW5pdCwgc28gdGhhdCB3ZSBjYW4g
YXNzaWduIGluZGl2aWR1YWwgZXJyb3IgaW50ZXJydXB0cyBpbg0KdGhlIHhsYXRlIGZ1bmN0aW9u
LiBJIGFncmVlIHRoYXQgdGhpcyBpc24ndCBhIG5lY2Vzc2FyeSByZXF1aXJlbWVudC4gU3VibWl0
dGVkDQphIG5ldyB2ZXJzaW9uIG9mIHRoZSBwYXRjaCBhZnRlciByZW1vdmluZyB0aGUgY2hlY2su
DQoNCi1WYXJ1bg0KDQo=
^ permalink raw reply
* Re: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
From: Arnd Bergmann @ 2012-08-09 11:43 UTC (permalink / raw)
To: linux-arm-kernel
Cc: thomas.petazzoni, andrew, netdev, devicetree-discuss,
linuxppc-dev, ben.dooks, Ian Molton, David Miller
In-Reply-To: <50239815.6020108@codethink.co.uk>
On 08/08/12 14:19, Ian Molton wrote:
> On 08/08/12 13:39, Arnd Bergmann wrote:
>> On Wednesday 08 August 2012, Ian Molton wrote:
>>> This method would require a small amount of rework in the driver to
>>> set up <n> ports, rather than just one.
>> This looks quite nice, but it is still very much incompatible with the
>> existing binding. Obviously we can abandon an existing binding and
>> introduce a second one for the same hardware, but that should not
>> be taken lightly.
> Fair, however the existing users aren't anywhere near as
> numerous as the new ones.
Depends on how you count the numbers. I see at least three machines
supported in the kernel with the old binding and none with the new one
so far ;-)
>> I don't fully understand your concern with the overlapping
>> registers, mostly because I still don't know all the combinations
>> that are actually valid here. Let me try to say what I understood
>> so far, and you can correct me if that's wrong:
>>
>> * A system can have multiple instances of an mv64360 ethernet
>> block, with a register area of 0x2000 bytes.
>> * Each such block can have three MACs and three PHYs.
>> * The first 0x400 bytes in the register space control the three
>> PHYs and the remaining registers control the MACs.
>> * While this is meant to be used in a way that you assign
>> the each of the three PHYs to one of the MACs, this is not
>> always done, and sometimes you use a different PHY (?), or
>> one from a different instance of the mv64360 ethernet block
>> on the same SoC?.
> Nearly - the whole block is 0x2000 in size, yes. And each one
> can have 3 MACs and PHYs, as you say.
>
> There is SMI @ 0x2000 - just one for all ports, and in many
> (all?) cases, for all all the other controllers on the SoC to
> share. On the armadaXP SoC, for example, each ethernet
> block has its own alias of the same bas SMI reg. (there are
> 4 blocks)
>
> ethernet0@ 0x2400
> ## regs in order: Main regs, MIB counters, Special mcast table, Mcast
> table, Unicast table.
> port0 has regs at +0x0000 *0x1000 +0x1400 +0x1500 +0x1600
> port1 has regs at +0x0400 *0x1080 +0x1800 +0x1900 +0x1a00
> port2 has regs at +0x0800 *0x1100 +0x1c00 +0x1d00 +0x1e00
> ethernet1@ 0x6400
> port0 has regs at +0x0000 *0x1000 +0x1400 +0x1500 +0x1600
> ...
>
> As you can see, instead of putting port1 at +0x1700 or so,
> marvell have overlapped the register files - in fact, doubly
> so, since port1 + 0x1080 is right in the middle of
> (port0 + 0x1000) -> (port0 + 0x16ff), so one cant simply map two
> sets of regs like 0x0000->0x03ff and 0x1000->0x16ff for port one
> either.
This could theoretically be dealt with by having 5 register ranges
per device, but that would cause extra overhead and also be
incompatible with the existing binding. I think showing one
parent device with children at address 0, 1 and 2 is ok. The driver
already knows all those offsets and they are always the same
for all variants of mv643xx, right?
Arnd
^ permalink raw reply
* Re: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
From: Ian Molton @ 2012-08-09 10:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: thomas.petazzoni, andrew, netdev, devicetree-discuss, ben.dooks,
linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <50226779.6060201@codethink.co.uk>
Adding devicetree-discuss and linuxppc-dev, as well as Dale Farnsworth,
who initially added the bindings for mv643xx.
On 08/08/12 14:19, Ian Molton wrote:
> On 08/08/12 13:39, Arnd Bergmann wrote:
>> On Wednesday 08 August 2012, Ian Molton wrote:
>>> The SMI / PHY stuff should look very similar, so I'm happy with something
>>> like:
>>>
>>> mdio@2000 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> device_type = "mdio";
>>> compatible = "marvell,mv643xx-mdio";
>>> phy0: ethernet-phy@0 {
>>> device_type = "ethernet-phy";
>>> compatible = "marvell,whatever";
>>> interrupts = <76>;
>>> interrupt-parent = <&mpic>;
>>> reg = <0 32>; // Auto probed phy addr
>>> };
>>>
>>> phy1: ethernet-phy@3 {
>>> device_type = "ethernet-phy";
>>> compatible = "marvell,whatever";
>>> interrupts = <77>;
>>> interrupt-parent = <&mpic>;
>>> reg = <3 1>; // specified phy addr
>>> };
>>>
>>> ... and so on.
>>> }
>>>
>>> Where we can use the reg parameter to allow auto-probing, by
>>> specifying a size of 32 (32 phy addrs max).
>> I don't understand the auto-probed phy address. What is the purpose of that?
> Personally, I think it should die - but the existing driver and a number
> of its users actually scan the bus for their PHY.
>
> I doubt the PHY really moves about or is hotplugged by any of them,
> and its actually quite a slow process.
>
>> If possible, I think we should keep using #size-cells=<0>, which would
>> make the method you describe impossible. It might still work if you just
>> leave out the "reg" property for that node.
> I can certainly investigate that. I couldn't see any good evidence that
> it was a supported mechanism when I looked.
>
>> I also don't understand how the phy driver would locate ethernet-phy@0
>> on the bus if it does not know the address.
>>
>>> The ethernet driver itself is more complicated:
>>>
>>> We have the following considerations:
>>>
>>> * we have one MDIO bus, typically, shared between all the MACs / PHYs.
>>> * each ethernet device can multiple ports (up to three), each with its
>>> own MAC/PHY.
>>> * MAC <-> PHY mapping can be specified, probed (ugh!) or a (gah!)
>>> mix of the two.
>>> * existing D-T users, albeit not well documented / code complete.
>>> * some port address ranges overlap (MIB counters, MCAST / UNICAST
>>> tables, etc.
>>>
>>> The existing ethernet-group idea only works because the current
>>> platform-device based driver doesnt really do proper resource
>>> management, and thus the MAC registers are actually mapped by
>>> the MDIO driver.
>>>
>>> I don't think that preserving this bad behaviour is a good idea, which
>>> leaves us with two choices:
>>>
>>> 1) My preferred solution - allow each device to specify up to three
>>> interrupts, MACs, and PHYs. This is clean in that it doesnt require
>>> multiply instantiating a driver three times over the same address
>>> space.
>>>
>>> ethernet@2400 {
>>> compatible = "marvell,mv643xx-eth";
>>> reg = <0x2400 0x1c00>
>>> interrupt_parent = <&mpic>;
>>> ports = <3>;
>>> interrupts = <4>, <5>, <6>;
>>> phys = <&phy0>, <&phy1>, <&phy2>;
>>> };
>>>
>>> ethernet@6400 {
>>> compatible = "marvell,mv643xx-eth";
>>> reg = <0x6400 0x1c00>
>>> interrupt_parent = <&mpic>;
>>> ports = <1>;
>>> interrupts = <4>;
>>> phys = <&phy3>;
>>> };
>>>
>>> Note that the address is 2400, not 2000 - since this driver no longer
>>> would share its address range with the MDIO driver.
>>>
>>> This method would require a small amount of rework in the driver to
>>> set up <n> ports, rather than just one.
>> This looks quite nice, but it is still very much incompatible with the
>> existing binding. Obviously we can abandon an existing binding and
>> introduce a second one for the same hardware, but that should not
>> be taken lightly.
> Fair, however the existing users aren't anywhere near as
> numerous as the new ones.
>
>>> 2) Create some kind of pseudo-ethernet group device that manages
>>> all the work for some sort of lightweight ethernet device, one per
>>> port. This can never be done cleanly since the port address ranges
>>> overlap:
>>>
>>> pseudo_eth@2400 {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> compatible = "marvell,mv643xx-shared-eth"
>>> reg = <0x2400 0x1c00>;
>>>
>>> ethernet@0 {
>>> compatible = "marvell,mv643xx-port";
>>> interrupts = <4>;
>>> interrupt_parent = <&mpic>;
>>> phy = <&phy0>;
>>> };
>>>
>>> ethernet@1 {
>>> compatible = "marvell,mv643xx-port";
>>> interrupts = <5>;
>>> interrupt_parent = <&mpic>;
>>> phy = <&phy1>;
>>> };
>>>
>>> ethernet@2 {
>>> compatible = "marvell,mv643xx-port";
>>> interrupts = <6>;
>>> interrupt_parent = <&mpic>;
>>> phy = <&phy2>;
>>> };
>>> }
>>> pseudo_eth@6400 {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> compatible = "marvell,mv643xx-shared-eth"
>>> reg = <0x6400 0x1c00>;
>>>
>>> ethernet@0 {
>>> compatible = "marvell,mv643xx-port";
>>> interrupts = <4>;
>>> interrupt_parent = <&mpic>;
>>> phy = <&phy3>;
>>> };
>>> };
>> This looks almost compatible with the existing binding, which is
>> good.
> Well, I'm not sure about that - if the existing bindings are really
> baked into firmware, then "almost" wont be any use at all.
>
>> I would in fact recommend to use the actual "compatible"
>> strings from the binding. More generally speaking, you should not
>> use wildcards in those strings anyway, so always use
>> "marvell,mv64360-eth" instead of "marvell,mv64x60-eth" or
>> "marvell,mv643xx-eth". If you have multiple chips that are
>> completely compatible, put use the identifier for the older one.
> Noted.
>
>> I don't fully understand your concern with the overlapping
>> registers, mostly because I still don't know all the combinations
>> that are actually valid here. Let me try to say what I understood
>> so far, and you can correct me if that's wrong:
>>
>> * A system can have multiple instances of an mv64360 ethernet
>> block, with a register area of 0x2000 bytes.
>> * Each such block can have three MACs and three PHYs.
>> * The first 0x400 bytes in the register space control the three
>> PHYs and the remaining registers control the MACs.
>> * While this is meant to be used in a way that you assign
>> the each of the three PHYs to one of the MACs, this is not
>> always done, and sometimes you use a different PHY (?), or
>> one from a different instance of the mv64360 ethernet block
>> on the same SoC?.
> Nearly - the whole block is 0x2000 in size, yes. And each one
> can have 3 MACs and PHYs, as you say.
>
> There is SMI @ 0x2000 - just one for all ports, and in many
> (all?) cases, for all all the other controllers on the SoC to
> share. On the armadaXP SoC, for example, each ethernet
> block has its own alias of the same bas SMI reg. (there are
> 4 blocks)
>
> ethernet0@ 0x2400
> ## regs in order: Main regs, MIB counters, Special mcast table, Mcast
> table, Unicast table.
> port0 has regs at +0x0000 *0x1000 +0x1400 +0x1500 +0x1600
> port1 has regs at +0x0400 *0x1080 +0x1800 +0x1900 +0x1a00
> port2 has regs at +0x0800 *0x1100 +0x1c00 +0x1d00 +0x1e00
> ethernet1@ 0x6400
> port0 has regs at +0x0000 *0x1000 +0x1400 +0x1500 +0x1600
> ...
>
> As you can see, instead of putting port1 at +0x1700 or so,
> marvell have overlapped the register files - in fact, doubly
> so, since port1 + 0x1080 is right in the middle of
> (port0 + 0x1000) -> (port0 + 0x16ff), so one cant simply map two
> sets of regs like 0x0000->0x03ff and 0x1000->0x16ff for port one
> either.
>
> -Ian
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Jia Hongtao-B38951 @ 2012-08-09 10:32 UTC (permalink / raw)
To: Wood Scott-B07421, Kumar Gala
Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <5022D44E.8040102@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwOSwgMjAxMiA1OjA0IEFNDQo+IFRvOiBLdW1h
ciBHYWxhDQo+IENjOiBKaWEgSG9uZ3Rhby1CMzg5NTE7IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51
eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gTGkgWWFuZy1SNTg0NzINCj4gU3ViamVjdDog
UmU6IFtQQVRDSCA1LzZdIHBvd2VycGMvZnNsLXBjaTogQWRkIHBjaSBpbmJvdW5kL291dGJvdW5k
IFBNDQo+IHN1cHBvcnQNCj4gDQo+IE9uIDA4LzA4LzIwMTIgMDc6NDYgQU0sIEt1bWFyIEdhbGEg
d3JvdGU6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBPbiBKdWwgMjQsIDIwMTIsIGF0IDU6MjAgQU0s
IEppYSBIb25ndGFvIHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFBvd2VyIHN1cHBseSBm
b3IgUENJIGluYm91bmQvb3V0Ym91bmQgd2luZG93IHJlZ2lzdGVycyBpcyBvZmYNCj4gPj4+Pj4+
Pj4gd2hlbg0KPiA+Pj4+Pj4+IHN5c3RlbQ0KPiA+Pj4+Pj4+PiBnbyB0byBkZWVwLXNsZWVwIHN0
YXRlLiBXZSBzYXZlIHRoZSB2YWx1ZXMgb2YgcmVnaXN0ZXJzIGJlZm9yZQ0KPiA+Pj4+Pj4+PiBz
dXNwZW5kIGFuZCByZXN0b3JlIHRvIHJlZ2lzdGVycyBhZnRlciByZXN1bWUuDQo+ID4+Pj4+Pj4+
DQo+ID4+Pj4+Pj4+IFNpZ25lZC1vZmYtYnk6IEppYW5nIFl1dGFuZyA8YjE0ODk4QGZyZWVzY2Fs
ZS5jb20+DQo+ID4+Pj4+Pj4+IFNpZ25lZC1vZmYtYnk6IEppYSBIb25ndGFvIDxCMzg5NTFAZnJl
ZXNjYWxlLmNvbT4NCj4gPj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogTGkgWWFuZyA8bGVvbGlAZnJl
ZXNjYWxlLmNvbT4NCj4gPj4+Pj4+Pj4gLS0tDQo+ID4+Pj4+Pj4+IGFyY2gvcG93ZXJwYy9pbmNs
dWRlL2FzbS9wY2ktYnJpZGdlLmggfCAgICAyICstDQo+ID4+Pj4+Pj4+IGFyY2gvcG93ZXJwYy9z
eXNkZXYvZnNsX3BjaS5jICAgICAgICAgfCAgMTIxDQo+ID4+Pj4+Pj4gKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrDQo+ID4+Pj4+Pj4+IDIgZmlsZXMgY2hhbmdlZCwgMTIyIGluc2Vy
dGlvbnMoKyksIDEgZGVsZXRpb25zKC0pDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBSZW1pbmQgbWUg
d2h5IHdlIG5lZWQgdG8gc2F2ZS9yZXN0b3JlIFBDSSBBVE1Vcywgd2h5IG5vdCBqdXN0DQo+ID4+
Pj4+Pj4gcmUtcGFyc2UgdGhlIGRldmljZSB0cmVlIHRvIHJlc3RvcmU/DQo+ID4+Pj4+Pj4NCj4g
Pj4+Pj4+PiAtIGsNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBTYXZlL3Jlc3RvcmUgaXMgdGhlIG1vcmUg
ZWZmaWNpZW50IHdheS4gTGF0ZW5jeSBvZiBzbGVlcC93YWtldXANCj4gPj4+Pj4+IGlzIG9uZSBv
ZiBtb3N0IGltcG9ydGFudCBmZWF0dXJlcyBpbiBwb3dlciBtYW5hZ2VtZW50Lg0KPiA+Pj4+Pj4N
Cj4gPj4+Pj4+IC1Ib25ndGFvLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGRvbid0IHRoaW5rIHRoZSB0
aW1lIGl0IHRha2VzIHRvIHJ1biB0aHJvdWdoIHNldHVwX3BjaV9hdG11KCkgaXMNCj4gPj4+Pj4g
dGhhdCBsb25nIGNvbXBhcmVkIHRvIGZzbF9wY2lfcmVzdW1lKCkuDQo+ID4+Pj4+DQo+ID4+Pj4+
IEFsc28sIGRvbid0IHlvdSBuZWVkIHRvIHNldHVwIFBDSUNDU1JCQVIgYW5kIGRvIHNldHVwX3Bj
aV9jbWQoKSBvbg0KPiA+Pj4gcmVzdW1lPw0KPiA+Pj4+Pg0KPiA+Pj4+PiAtIGsNCj4gPj4+Pg0K
PiA+Pj4+IEhpIEt1bWFyLA0KPiA+Pj4+IEkgZGlkIHNvbWUgdGVzdHMgb24gUDEwMjJEUyBhbmQg
Zm91bmQgb3V0IHRoYXQgUENJX0NNRCBhbmQNCj4gPj4+PiBQQ0lDU1JCQVIgaXMgbm90IGxvc3Qg
d2hlbiBzeXN0ZW0gaW4gZGVlcCBzbGVlcC4gV2UgZG9uJ3QgbmVlZCB0bw0KPiBzYXZlIGl0Lg0K
PiANCj4gSG93IGRvIHlvdSBrbm93IHlvdSdyZSBub3QganVzdCBnZXR0aW5nIGx1Y2t5PyAgTWF5
YmUgaXQgb25seSBzdXJ2aXZlcw0KPiBkZWVwIHNsZWVwIHVwIHRvIGEgY2VydGFpbiBkdXJhdGlv
biwgb3IgdW5kZXIgb3RoZXIgc3BlY2lmaWMNCj4gY2lyY3Vtc3RhbmNlcy4NCg0KSSB0ZXN0ZWQg
Zm9yIG1vcmUgdGhhbiAxMCBtaW5zIGluIGRlZXAgc2xlZXAgYW5kIHRoZSByZXN1bHQgaXMgdGhl
IHNhbWUuDQoNCj4gDQo+IENhbiB5b3UgZmluZCBhbnl3aGVyZSB0aGF0IGRvY3VtZW50cyB3aGF0
IHN0YXRlIHdpbGwgYmUgcmV0YWluZWQgZHVyaW5nDQo+IGRlZXAgc2xlZXAsIG9yIGFzayBhbiBh
cHByb3ByaWF0ZSBoYXJkd2FyZSBkZXNpZ25lcj8NCj4gDQo+IC1TY290dA0KDQpJIGFncmVlIHdp
dGggeW91IHRoYXQgd2Ugc2hvdWxkIGZpbmQgb3V0IHdoYXQgc3RhdGUgd2lsbCBiZSByZXRhaW5l
ZCBkdXJpbmcNCmRlZXAgc2xlZXAuIEJ1dCBQMTAyMiBSTSBkb2MgaGFzIGxpbWl0ZWQgaW5mb3Jt
YXRpb24gZm9yIHRoaXMuIElmIEkgY2FuIGdldA0KbW9yZSBpbmZvcm1hdGlvbiBmcm9tIGhhcmR3
YXJlIGRlc2lnbmVyIHRoYXQgd2lsbCBiZSBnb29kLg0K
^ permalink raw reply
* [PATCH v7 8/8] carma: remove unnecessary DMA_INTERRUPT capability
From: qiang.liu @ 2012-08-09 8:23 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev, dan.j.williams, arnd, gregkh,
linux-kernel, dan.j.williams, vinod.koul
Cc: Qiang Liu, herbert, davem, Ira W. Snyder
From: Qiang Liu <qiang.liu@freescale.com>
These drivers set the DMA_INTERRUPT capability bit when requesting a DMA
controller channel. This was historical, and is no longer needed.
Recent changes to the drivers/dma/fsldma.c driver have removed support
for this flag. This makes the carma drivers unable to find a DMA channel
with the required capabilities.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
Based on git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
against branch char-misc-next.
drivers/misc/carma/carma-fpga-program.c | 1 -
drivers/misc/carma/carma-fpga.c | 2 +-
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga-program.c b/drivers/misc/carma/carma-fpga-program.c
index a2d25e4..eaddfe9 100644
--- a/drivers/misc/carma/carma-fpga-program.c
+++ b/drivers/misc/carma/carma-fpga-program.c
@@ -978,7 +978,6 @@ static int fpga_of_probe(struct platform_device *op)
dev_set_drvdata(priv->dev, priv);
dma_cap_zero(mask);
dma_cap_set(DMA_MEMCPY, mask);
- dma_cap_set(DMA_INTERRUPT, mask);
dma_cap_set(DMA_SLAVE, mask);
dma_cap_set(DMA_SG, mask);
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 8c279da..0c43297 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -666,7 +666,7 @@ static int data_submit_dma(struct fpga_device *priv, struct data_buf *buf)
src = SYS_FPGA_BLOCK;
tx = chan->device->device_prep_dma_memcpy(chan, dst, src,
REG_BLOCK_SIZE,
- DMA_PREP_INTERRUPT);
+ 0);
if (!tx) {
dev_err(priv->dev, "unable to prep SYS-FPGA DMA\n");
return -ENOMEM;
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 7/8] fsl-dma: fix a warning of unitialized cookie
From: qiang.liu @ 2012-08-09 8:23 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev, dan.j.williams, linux-kernel,
dan.j.williams, vinod.koul
Cc: arnd, gregkh, Qiang Liu, herbert, davem
From: Qiang Liu <qiang.liu@freescale.com>
Fix a warning of unitialized value when compile with -Wuninitialized.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dan Williams <dan.j.williams@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
Reported-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
drivers/dma/fsldma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8b9c0f7..361203d 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -405,7 +405,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
struct fsldma_chan *chan = to_fsl_chan(tx->chan);
struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_desc_sw *child;
- dma_cookie_t cookie;
+ dma_cookie_t cookie = 0;
spin_lock_bh(&chan->desc_lock);
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 6/8] fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave
From: qiang.liu @ 2012-08-09 8:23 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev, dan.j.williams, linux-kernel,
dan.j.williams, vinod.koul
Cc: arnd, gregkh, Timur Tabi, Qiang Liu, herbert, davem
From: Qiang Liu <qiang.liu@freescale.com>
The use of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be
used instead. Interrupts will be turned off and context will be saved,
there is needless to use irqsave.
Change all instances of spin_lock_irqsave() to spin_lock_bh().
All manipulation of protected fields is done using tasklet context or
weaker, which makes spin_lock_bh() the correct choice.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dan Williams <dan.j.williams@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Timur Tabi <timur@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
Acked-by: Ira W. Snyder <iws@ovro.caltech.edu>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Comments by Arnd Bergmann in v6:
"You could actually change the use of spin_lock_bh inside of the tasklet
function (dma_do_tasklet) do just spin_lock(), because softirqs are
already disabled there, but your version is also ok."
drivers/dma/fsldma.c | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b05a81f..8b9c0f7 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -405,10 +405,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
struct fsldma_chan *chan = to_fsl_chan(tx->chan);
struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_desc_sw *child;
- unsigned long flags;
dma_cookie_t cookie;
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_bh(&chan->desc_lock);
/*
* assign cookies to all of the software descriptors
@@ -421,7 +420,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
/* put this transaction onto the tail of the pending queue */
append_ld_queue(chan, desc);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_bh(&chan->desc_lock);
return cookie;
}
@@ -762,15 +761,14 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
chan_dbg(chan, "free all channel resources\n");
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_bh(&chan->desc_lock);
fsldma_cleanup_descriptors(chan);
fsldma_free_desc_list(chan, &chan->ld_pending);
fsldma_free_desc_list(chan, &chan->ld_running);
fsldma_free_desc_list(chan, &chan->ld_completed);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_bh(&chan->desc_lock);
dma_pool_destroy(chan->desc_pool);
chan->desc_pool = NULL;
@@ -989,7 +987,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
{
struct dma_slave_config *config;
struct fsldma_chan *chan;
- unsigned long flags;
int size;
if (!dchan)
@@ -999,7 +996,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
switch (cmd) {
case DMA_TERMINATE_ALL:
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_bh(&chan->desc_lock);
/* Halt the DMA engine */
dma_halt(chan);
@@ -1010,7 +1007,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
fsldma_free_desc_list(chan, &chan->ld_completed);
chan->idle = true;
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_bh(&chan->desc_lock);
return 0;
case DMA_SLAVE_CONFIG:
@@ -1052,11 +1049,10 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_bh(&chan->desc_lock);
fsl_chan_xfer_ld_queue(chan);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_bh(&chan->desc_lock);
}
/**
@@ -1069,15 +1065,14 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan,
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
enum dma_status ret;
- unsigned long flags;
ret = dma_cookie_status(dchan, cookie, txstate);
if (ret == DMA_SUCCESS)
return ret;
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_bh(&chan->desc_lock);
fsldma_cleanup_descriptors(chan);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_bh(&chan->desc_lock);
return dma_cookie_status(dchan, cookie, txstate);
}
@@ -1156,11 +1151,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
static void dma_do_tasklet(unsigned long data)
{
struct fsldma_chan *chan = (struct fsldma_chan *)data;
- unsigned long flags;
chan_dbg(chan, "tasklet entry\n");
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_bh(&chan->desc_lock);
/* the hardware is now idle and ready for more */
chan->idle = true;
@@ -1168,7 +1162,7 @@ static void dma_do_tasklet(unsigned long data)
/* Run all cleanup for descriptors which have been completed */
fsldma_cleanup_descriptors(chan);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_bh(&chan->desc_lock);
chan_dbg(chan, "tasklet exit\n");
}
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 5/8] fsl-dma: change release process of dma descriptor for supporting async_tx
From: qiang.liu @ 2012-08-09 8:22 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev, dan.j.williams, linux-kernel,
dan.j.williams, vinod.koul
Cc: arnd, Ira W. Snyder, gregkh, Qiang Liu, herbert, davem
From: Qiang Liu <qiang.liu@freescale.com>
Fix the potential risk when enable config NET_DMA and ASYNC_TX.
Async_tx is lack of support in current release process of dma descriptor,
all descriptors will be released whatever is acked or no-acked by async_tx,
so there is a potential race condition when dma engine is uesd by others
clients (e.g. when enable NET_DMA to offload TCP).
In our case, a race condition which is raised when use both of talitos
and dmaengine to offload xor is because napi scheduler will sync all
pending requests in dma channels, it affects the process of raid operations
due to ack_tx is not checked in fsl dma. The no-acked descriptor is freed
which is submitted just now, as a dependent tx, this freed descriptor trigger
BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf40000 CPU: 0
GPR00: 00000001 ecf41ca0 ee44/921a94a0 0000003f 00000001 c00593e4 00000000 00000001
GPR08: 00000000 a7a7a7a7 00000001 045/920000002 42028042 100a38d4 ed576d98 00000000
GPR16: ed5a11b0 00000000 2b162000 00000200 046/920000000 2d555000 ed3015e8 c15a7aa0
GPR24: 00000000 c155fc40 00000000 ecb63220 ecf41d28 e47/92f640bb0 ef640c30 ecf41ca0
NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
Another modification in this patch is the change of completed descriptors,
there is a potential risk which caused by exception interrupt, all descriptors
in ld_running list are seemed completed when an interrupt raised, it works fine
under normal condition, but if there is an exception occured, it cannot work
as our excepted. Hardware should not be depend on s/w list, the right way is
to read current descriptor address register to find the last completed
descriptor. If an interrupt is raised by an error, all descriptors in ld_running
should not be seemed finished, or these unfinished descriptors in ld_running
will be released wrongly.
A simple way to reproduce,
Enable dmatest first, then insert some bad descriptors which can trigger
Programming Error interrupts before the good descriptors. Last, the good
descriptors will be freed before they are processsed because of the exception
intrerrupt.
Note: the bad descriptors are only for simulating an exception interrupt.
This case can illustrate the potential risk in current fsl-dma very well.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dan Williams <dan.j.williams@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Tested-by: Kim Phillips <kim.phillips@freescale.com>
---
drivers/dma/fsldma.c | 233 ++++++++++++++++++++++++++++++++++----------------
drivers/dma/fsldma.h | 17 +++-
2 files changed, 175 insertions(+), 75 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 36490a3..b05a81f 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -472,6 +472,111 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
}
/**
+ * fsldma_clean_completed_descriptor - free all descriptors which
+ * has been completed and acked
+ * @chan: Freescale DMA channel
+ *
+ * This function is used on all completed and acked descriptors.
+ * All descriptors should only be freed in this function.
+ */
+static void
+fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
+{
+ struct fsl_desc_sw *desc, *_desc;
+
+ /* Run the callback for each descriptor, in order */
+ list_for_each_entry_safe(desc, _desc, &chan->ld_completed, node)
+ if (async_tx_test_ack(&desc->async_tx))
+ fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
+ * fsldma_run_tx_complete_actions - cleanup a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ * @cookie: Freescale DMA transaction identifier
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies.
+ */
+static dma_cookie_t fsldma_run_tx_complete_actions(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc, dma_cookie_t cookie)
+{
+ struct dma_async_tx_descriptor *txd = &desc->async_tx;
+ struct device *dev = chan->common.device->dev;
+ dma_addr_t src = get_desc_src(chan, desc);
+ dma_addr_t dst = get_desc_dst(chan, desc);
+ u32 len = get_desc_cnt(chan, desc);
+
+ BUG_ON(txd->cookie < 0);
+
+ if (txd->cookie > 0) {
+ cookie = txd->cookie;
+
+ /* Run the link descriptor callback function */
+ if (txd->callback) {
+#ifdef FSL_DMA_LD_DEBUG
+ chan_dbg(chan, "LD %p callback\n", desc);
+#endif
+ txd->callback(txd->callback_param);
+ }
+
+ /* Unmap the dst buffer, if requested */
+ if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
+ if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
+ dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
+ else
+ dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
+ }
+
+ /* Unmap the src buffer, if requested */
+ if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
+ if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
+ dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
+ else
+ dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
+ }
+ }
+
+ /* Run any dependencies */
+ dma_run_dependencies(txd);
+
+ return cookie;
+}
+
+/**
+ * fsldma_clean_running_descriptor - move the completed descriptor from
+ * ld_running to ld_completed
+ * @chan: Freescale DMA channel
+ * @desc: the descriptor which is completed
+ *
+ * Free the descriptor directly if acked by async_tx api, or move it to
+ * queue ld_completed.
+ */
+static void
+fsldma_clean_running_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ /* Remove from the list of transactions */
+ list_del(&desc->node);
+
+ /*
+ * the client is allowed to attach dependent operations
+ * until 'ack' is set
+ */
+ if (!async_tx_test_ack(&desc->async_tx)) {
+ /*
+ * Move this descriptor to the list of descriptors which is
+ * completed, but still awaiting the 'ack' bit to be set.
+ */
+ list_add_tail(&desc->node, &chan->ld_completed);
+ return;
+ }
+
+ dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
+}
+
+/**
* fsl_chan_xfer_ld_queue - transfer any pending transactions
* @chan : Freescale DMA channel
*
@@ -539,51 +644,58 @@ static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
}
/**
- * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
+ * fsldma_cleanup_descriptors - cleanup link descriptors which are completed
+ * and move them to ld_completed to free until flag 'ack' is set
* @chan: Freescale DMA channel
- * @desc: descriptor to cleanup and free
*
- * This function is used on a descriptor which has been executed by the DMA
- * controller. It will run any callbacks, submit any dependencies, and then
- * free the descriptor.
+ * This function is used on descriptors which have been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies, then
+ * free these descriptors if flag 'ack' is set.
*/
-static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
- struct fsl_desc_sw *desc)
+static void fsldma_cleanup_descriptors(struct fsldma_chan *chan)
{
- struct dma_async_tx_descriptor *txd = &desc->async_tx;
- struct device *dev = chan->common.device->dev;
- dma_addr_t src = get_desc_src(chan, desc);
- dma_addr_t dst = get_desc_dst(chan, desc);
- u32 len = get_desc_cnt(chan, desc);
+ struct fsl_desc_sw *desc, *_desc;
+ dma_cookie_t cookie = 0;
+ dma_addr_t curr_phys = get_cdar(chan);
+ int seen_current = 0;
- /* Run the link descriptor callback function */
- if (txd->callback) {
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p callback\n", desc);
-#endif
- txd->callback(txd->callback_param);
- }
+ fsldma_clean_completed_descriptor(chan);
- /* Run any dependencies */
- dma_run_dependencies(txd);
+ /* Run the callback for each descriptor, in order */
+ list_for_each_entry_safe(desc, _desc, &chan->ld_running, node) {
+ /*
+ * do not advance past the current descriptor loaded into the
+ * hardware channel, subsequent descriptors are either in
+ * process or have not been submitted
+ */
+ if (seen_current)
+ break;
- /* Unmap the dst buffer, if requested */
- if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
- if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
- dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
- else
- dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
- }
+ /*
+ * stop the search if we reach the current descriptor and the
+ * channel is busy
+ */
+ if (desc->async_tx.phys == curr_phys) {
+ seen_current = 1;
+ if (!dma_is_idle(chan))
+ break;
+ }
- /* Unmap the src buffer, if requested */
- if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
- if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
- dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
- else
- dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
+ cookie = fsldma_run_tx_complete_actions(chan, desc, cookie);
+
+ fsldma_clean_running_descriptor(chan, desc);
}
- fsl_dma_free_descriptor(chan, desc);
+ /*
+ * Start any pending transactions automatically
+ *
+ * In the ideal case, we keep the DMA controller busy while we go
+ * ahead and free the descriptors below.
+ */
+ fsl_chan_xfer_ld_queue(chan);
+
+ if (cookie > 0)
+ chan->common.completed_cookie = cookie;
}
/**
@@ -654,8 +766,10 @@ static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
chan_dbg(chan, "free all channel resources\n");
spin_lock_irqsave(&chan->desc_lock, flags);
+ fsldma_cleanup_descriptors(chan);
fsldma_free_desc_list(chan, &chan->ld_pending);
fsldma_free_desc_list(chan, &chan->ld_running);
+ fsldma_free_desc_list(chan, &chan->ld_completed);
spin_unlock_irqrestore(&chan->desc_lock, flags);
dma_pool_destroy(chan->desc_pool);
@@ -893,6 +1007,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
/* Remove and free all of the descriptors in the LD queue */
fsldma_free_desc_list(chan, &chan->ld_pending);
fsldma_free_desc_list(chan, &chan->ld_running);
+ fsldma_free_desc_list(chan, &chan->ld_completed);
chan->idle = true;
spin_unlock_irqrestore(&chan->desc_lock, flags);
@@ -956,11 +1071,15 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan,
enum dma_status ret;
unsigned long flags;
- spin_lock_irqsave(&chan->desc_lock, flags);
ret = dma_cookie_status(dchan, cookie, txstate);
+ if (ret == DMA_SUCCESS)
+ return ret;
+
+ spin_lock_irqsave(&chan->desc_lock, flags);
+ fsldma_cleanup_descriptors(chan);
spin_unlock_irqrestore(&chan->desc_lock, flags);
- return ret;
+ return dma_cookie_status(dchan, cookie, txstate);
}
/*----------------------------------------------------------------------------*/
@@ -1037,52 +1156,19 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
static void dma_do_tasklet(unsigned long data)
{
struct fsldma_chan *chan = (struct fsldma_chan *)data;
- struct fsl_desc_sw *desc, *_desc;
- LIST_HEAD(ld_cleanup);
unsigned long flags;
chan_dbg(chan, "tasklet entry\n");
spin_lock_irqsave(&chan->desc_lock, flags);
- /* update the cookie if we have some descriptors to cleanup */
- if (!list_empty(&chan->ld_running)) {
- dma_cookie_t cookie;
-
- desc = to_fsl_desc(chan->ld_running.prev);
- cookie = desc->async_tx.cookie;
- dma_cookie_complete(&desc->async_tx);
-
- chan_dbg(chan, "completed_cookie=%d\n", cookie);
- }
-
- /*
- * move the descriptors to a temporary list so we can drop the lock
- * during the entire cleanup operation
- */
- list_splice_tail_init(&chan->ld_running, &ld_cleanup);
-
/* the hardware is now idle and ready for more */
chan->idle = true;
- /*
- * Start any pending transactions automatically
- *
- * In the ideal case, we keep the DMA controller busy while we go
- * ahead and free the descriptors below.
- */
- fsl_chan_xfer_ld_queue(chan);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
-
- /* Run the callback for each descriptor, in order */
- list_for_each_entry_safe(desc, _desc, &ld_cleanup, node) {
+ /* Run all cleanup for descriptors which have been completed */
+ fsldma_cleanup_descriptors(chan);
- /* Remove from the list of transactions */
- list_del(&desc->node);
-
- /* Run all cleanup for this descriptor */
- fsldma_cleanup_descriptor(chan, desc);
- }
+ spin_unlock_irqrestore(&chan->desc_lock, flags);
chan_dbg(chan, "tasklet exit\n");
}
@@ -1264,6 +1350,7 @@ static int __devinit fsl_dma_chan_probe(struct fsldma_device *fdev,
spin_lock_init(&chan->desc_lock);
INIT_LIST_HEAD(&chan->ld_pending);
INIT_LIST_HEAD(&chan->ld_running);
+ INIT_LIST_HEAD(&chan->ld_completed);
chan->idle = true;
chan->common.device = &fdev->common;
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..a58275a 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -138,8 +138,21 @@ struct fsldma_chan {
char name[8]; /* Channel name */
struct fsldma_chan_regs __iomem *regs;
spinlock_t desc_lock; /* Descriptor operation lock */
- struct list_head ld_pending; /* Link descriptors queue */
- struct list_head ld_running; /* Link descriptors queue */
+ /*
+ * Descriptors which are queued to run, but have not yet been
+ * submitted to the hardware for execution
+ */
+ struct list_head ld_pending;
+ /*
+ * Descriptors which are currently being executed by the hardware
+ */
+ struct list_head ld_running;
+ /*
+ * Descriptors which have finished execution by the hardware. These
+ * descriptors have already had their cleanup actions run. They are
+ * waiting for the ACK bit to be set by the async_tx API.
+ */
+ struct list_head ld_completed; /* Link descriptors queue */
struct dma_chan common; /* DMA common channel */
struct dma_pool *desc_pool; /* Descriptors pool */
struct device *dev; /* Channel device */
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 4/8] fsl-dma: move functions to avoid forward declarations
From: qiang.liu @ 2012-08-09 8:22 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev, dan.j.williams, linux-kernel,
dan.j.williams, vinod.koul
Cc: arnd, Ira W. Snyder, gregkh, Qiang Liu, herbert, davem
From: Qiang Liu <qiang.liu@freescale.com>
These functions will be modified in the next patch in the series. By
moving the function in a patch separate from the changes, it will make
review easier.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dan Williams <dan.j.williams@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
---
drivers/dma/fsldma.c | 230 +++++++++++++++++++++++++-------------------------
1 files changed, 115 insertions(+), 115 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index d4720d3..36490a3 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -472,6 +472,121 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
}
/**
+ * fsl_chan_xfer_ld_queue - transfer any pending transactions
+ * @chan : Freescale DMA channel
+ *
+ * HARDWARE STATE: idle
+ * LOCKING: must hold chan->desc_lock
+ */
+static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
+{
+ struct fsl_desc_sw *desc;
+
+ /*
+ * If the list of pending descriptors is empty, then we
+ * don't need to do any work at all
+ */
+ if (list_empty(&chan->ld_pending)) {
+ chan_dbg(chan, "no pending LDs\n");
+ return;
+ }
+
+ /*
+ * The DMA controller is not idle, which means that the interrupt
+ * handler will start any queued transactions when it runs after
+ * this transaction finishes
+ */
+ if (!chan->idle) {
+ chan_dbg(chan, "DMA controller still busy\n");
+ return;
+ }
+
+ /*
+ * If there are some link descriptors which have not been
+ * transferred, we need to start the controller
+ */
+
+ /*
+ * Move all elements from the queue of pending transactions
+ * onto the list of running transactions
+ */
+ chan_dbg(chan, "idle, starting controller\n");
+ desc = list_first_entry(&chan->ld_pending, struct fsl_desc_sw, node);
+ list_splice_tail_init(&chan->ld_pending, &chan->ld_running);
+
+ /*
+ * The 85xx DMA controller doesn't clear the channel start bit
+ * automatically at the end of a transfer. Therefore we must clear
+ * it in software before starting the transfer.
+ */
+ if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
+ u32 mode;
+
+ mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode &= ~FSL_DMA_MR_CS;
+ DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ }
+
+ /*
+ * Program the descriptor's address into the DMA controller,
+ * then start the DMA transaction
+ */
+ set_cdar(chan, desc->async_tx.phys);
+ get_cdar(chan);
+
+ dma_start(chan);
+ chan->idle = false;
+}
+
+/**
+ * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies, and then
+ * free the descriptor.
+ */
+static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ struct dma_async_tx_descriptor *txd = &desc->async_tx;
+ struct device *dev = chan->common.device->dev;
+ dma_addr_t src = get_desc_src(chan, desc);
+ dma_addr_t dst = get_desc_dst(chan, desc);
+ u32 len = get_desc_cnt(chan, desc);
+
+ /* Run the link descriptor callback function */
+ if (txd->callback) {
+#ifdef FSL_DMA_LD_DEBUG
+ chan_dbg(chan, "LD %p callback\n", desc);
+#endif
+ txd->callback(txd->callback_param);
+ }
+
+ /* Run any dependencies */
+ dma_run_dependencies(txd);
+
+ /* Unmap the dst buffer, if requested */
+ if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
+ if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
+ dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
+ else
+ dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
+ }
+
+ /* Unmap the src buffer, if requested */
+ if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
+ if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
+ dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
+ else
+ dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
+ }
+
+ fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
* fsl_dma_alloc_chan_resources - Allocate resources for DMA channel.
* @chan : Freescale DMA channel
*
@@ -816,121 +931,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
}
/**
- * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
- * @chan: Freescale DMA channel
- * @desc: descriptor to cleanup and free
- *
- * This function is used on a descriptor which has been executed by the DMA
- * controller. It will run any callbacks, submit any dependencies, and then
- * free the descriptor.
- */
-static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
- struct fsl_desc_sw *desc)
-{
- struct dma_async_tx_descriptor *txd = &desc->async_tx;
- struct device *dev = chan->common.device->dev;
- dma_addr_t src = get_desc_src(chan, desc);
- dma_addr_t dst = get_desc_dst(chan, desc);
- u32 len = get_desc_cnt(chan, desc);
-
- /* Run the link descriptor callback function */
- if (txd->callback) {
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p callback\n", desc);
-#endif
- txd->callback(txd->callback_param);
- }
-
- /* Run any dependencies */
- dma_run_dependencies(txd);
-
- /* Unmap the dst buffer, if requested */
- if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
- if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
- dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
- else
- dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
- }
-
- /* Unmap the src buffer, if requested */
- if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
- if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
- dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
- else
- dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
- }
-
- fsl_dma_free_descriptor(chan, desc);
-}
-
-/**
- * fsl_chan_xfer_ld_queue - transfer any pending transactions
- * @chan : Freescale DMA channel
- *
- * HARDWARE STATE: idle
- * LOCKING: must hold chan->desc_lock
- */
-static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
-{
- struct fsl_desc_sw *desc;
-
- /*
- * If the list of pending descriptors is empty, then we
- * don't need to do any work at all
- */
- if (list_empty(&chan->ld_pending)) {
- chan_dbg(chan, "no pending LDs\n");
- return;
- }
-
- /*
- * The DMA controller is not idle, which means that the interrupt
- * handler will start any queued transactions when it runs after
- * this transaction finishes
- */
- if (!chan->idle) {
- chan_dbg(chan, "DMA controller still busy\n");
- return;
- }
-
- /*
- * If there are some link descriptors which have not been
- * transferred, we need to start the controller
- */
-
- /*
- * Move all elements from the queue of pending transactions
- * onto the list of running transactions
- */
- chan_dbg(chan, "idle, starting controller\n");
- desc = list_first_entry(&chan->ld_pending, struct fsl_desc_sw, node);
- list_splice_tail_init(&chan->ld_pending, &chan->ld_running);
-
- /*
- * The 85xx DMA controller doesn't clear the channel start bit
- * automatically at the end of a transfer. Therefore we must clear
- * it in software before starting the transfer.
- */
- if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
- u32 mode;
-
- mode = DMA_IN(chan, &chan->regs->mr, 32);
- mode &= ~FSL_DMA_MR_CS;
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
- }
-
- /*
- * Program the descriptor's address into the DMA controller,
- * then start the DMA transaction
- */
- set_cdar(chan, desc->async_tx.phys);
- get_cdar(chan);
-
- dma_start(chan);
- chan->idle = false;
-}
-
-/**
* fsl_dma_memcpy_issue_pending - Issue the DMA start command
* @chan : Freescale DMA channel
*/
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 3/8] fsl-dma: add fsl_dma_free_descriptor() to reduce code duplication
From: qiang.liu @ 2012-08-09 8:21 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev, dan.j.williams, linux-kernel,
dan.j.williams, vinod.koul
Cc: arnd, Ira W. Snyder, gregkh, Qiang Liu, herbert, davem
From: Qiang Liu <qiang.liu@freescale.com>
There are several places where descriptors are freed using identical
code. Put this code into a function to reduce code duplication.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dan Williams <dan.j.williams@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
drivers/dma/fsldma.c | 38 ++++++++++++++++++++------------------
1 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 4f2f212..d4720d3 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -427,6 +427,21 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
}
/**
+ * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
+ * @chan : Freescale DMA channel
+ * @desc: descriptor to be freed
+ */
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ list_del(&desc->node);
+#ifdef FSL_DMA_LD_DEBUG
+ chan_dbg(chan, "LD %p free\n", desc);
+#endif
+ dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
+}
+
+/**
* fsl_dma_alloc_descriptor - Allocate descriptor from channel's DMA pool.
* @chan : Freescale DMA channel
*
@@ -500,13 +515,8 @@ static void fsldma_free_desc_list(struct fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe(desc, _desc, list, node) {
- list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p free\n", desc);
-#endif
- dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
- }
+ list_for_each_entry_safe(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
@@ -514,13 +524,8 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe_reverse(desc, _desc, list, node) {
- list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p free\n", desc);
-#endif
- dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
- }
+ list_for_each_entry_safe_reverse(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
/**
@@ -855,10 +860,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
}
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p free\n", desc);
-#endif
- dma_pool_free(chan->desc_pool, desc, txd->phys);
+ fsl_dma_free_descriptor(chan, desc);
}
/**
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 2/8] fsl-dma: remove attribute DMA_INTERRUPT of dmaengine
From: qiang.liu @ 2012-08-09 8:21 UTC (permalink / raw)
To: linux-crypto, linuxppc-dev, dan.j.williams, linux-kernel,
dan.j.williams, vinod.koul
Cc: arnd, gregkh, Qiang Liu, herbert, davem
From: Qiang Liu <qiang.liu@freescale.com>
Delete attribute DMA_INTERRUPT because fsl-dma doesn't support this function,
exception will be thrown if talitos is used to offload xor at the same time.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
Acked-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
drivers/dma/fsldma.c | 31 -------------------------------
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8f84761..4f2f212 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -543,35 +543,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
}
static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *dchan, unsigned long flags)
-{
- struct fsldma_chan *chan;
- struct fsl_desc_sw *new;
-
- if (!dchan)
- return NULL;
-
- chan = to_fsl_chan(dchan);
-
- new = fsl_dma_alloc_descriptor(chan);
- if (!new) {
- chan_err(chan, "%s\n", msg_ld_oom);
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->tx_list);
-
- /* Set End-of-link to the last link descriptor of new list */
- set_ld_eol(chan, new);
-
- return &new->async_tx;
-}
-
-static struct dma_async_tx_descriptor *
fsl_dma_prep_memcpy(struct dma_chan *dchan,
dma_addr_t dma_dst, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -1352,12 +1323,10 @@ static int __devinit fsldma_of_probe(struct platform_device *op)
fdev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
- dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
dma_cap_set(DMA_SG, fdev->common.cap_mask);
dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_prep_dma_sg = fsl_dma_prep_sg;
fdev->common.device_tx_status = fsl_tx_status;
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
From: qiang.liu @ 2012-08-09 8:20 UTC (permalink / raw)
To: linux-crypto, dan.j.williams, herbert, davem, linux-kernel,
linuxppc-dev
Cc: arnd, vinod.koul, gregkh, Qiang Liu, dan.j.williams
From: Qiang Liu <qiang.liu@freescale.com>
Expose Talitos's XOR functionality to be used for RAID parity
calculation via the Async_tx layer.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
---
drivers/crypto/Kconfig | 9 +
drivers/crypto/talitos.c | 413 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/talitos.h | 53 ++++++
3 files changed, 475 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index be6b2ba..f0a7c29 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -222,6 +222,15 @@ config CRYPTO_DEV_TALITOS
To compile this driver as a module, choose M here: the module
will be called talitos.
+config CRYPTO_DEV_TALITOS_RAIDXOR
+ bool "Talitos RAID5 XOR Calculation Offload"
+ default y
+ select DMA_ENGINE
+ depends on CRYPTO_DEV_TALITOS
+ help
+ Say 'Y' here to use the Freescale Security Engine (SEC) to
+ offload RAID XOR parity Calculation
+
config CRYPTO_DEV_IXP4XX
tristate "Driver for IXP4xx crypto hardware acceleration"
depends on ARCH_IXP4XX
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index efff788..b34264e 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -619,6 +619,399 @@ static void talitos_unregister_rng(struct device *dev)
hwrng_unregister(&priv->rng);
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+static void talitos_release_xor(struct device *dev, struct talitos_desc *hwdesc,
+ void *context, int error);
+
+static enum dma_status talitos_is_tx_complete(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ struct dma_tx_state *state)
+{
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t last_used;
+ dma_cookie_t last_complete;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ last_used = chan->cookie;
+ last_complete = xor_chan->completed_cookie;
+
+ if (state->last)
+ state->last = last_complete;
+
+ if (state->used)
+ state->used = last_used;
+
+ return dma_async_is_complete(cookie, last_complete, last_used);
+}
+
+static void talitos_process_pending(struct talitos_xor_chan *xor_chan)
+{
+ struct talitos_xor_desc *desc, *_desc;
+ unsigned long flags;
+ int status;
+ struct talitos_private *priv;
+ int ch;
+
+ priv = dev_get_drvdata(xor_chan->dev);
+ ch = atomic_inc_return(&priv->last_chan) &
+ (priv->num_channels - 1);
+ spin_lock_irqsave(&xor_chan->desc_lock, flags);
+
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ status = talitos_submit(xor_chan->dev, ch, &desc->hwdesc,
+ talitos_release_xor, desc);
+ if (status != -EINPROGRESS)
+ break;
+
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->in_progress_q);
+ }
+
+ spin_unlock_irqrestore(&xor_chan->desc_lock, flags);
+}
+
+static void talitos_xor_run_tx_complete_actions(struct talitos_xor_desc *desc,
+ struct talitos_xor_chan *xor_chan)
+{
+ struct device *dev = xor_chan->dev;
+ dma_addr_t dest, addr;
+ unsigned int src_cnt = desc->unmap_src_cnt;
+ unsigned int len = desc->unmap_len;
+ enum dma_ctrl_flags flags = desc->async_tx.flags;
+ struct dma_async_tx_descriptor *tx = &desc->async_tx;
+
+ /* unmap dma addresses */
+ dest = desc->hwdesc.ptr[6].ptr;
+ if (likely(!(flags & DMA_COMPL_SKIP_DEST_UNMAP)))
+ dma_unmap_page(dev, dest, len, DMA_BIDIRECTIONAL);
+
+ desc->idx = 6 - src_cnt;
+ if (likely(!(flags & DMA_COMPL_SKIP_SRC_UNMAP))) {
+ while(desc->idx < 6) {
+ addr = desc->hwdesc.ptr[desc->idx++].ptr;
+ if (addr == dest)
+ continue;
+ dma_unmap_page(dev, addr, len, DMA_TO_DEVICE);
+ }
+ }
+
+ /* run dependent operations */
+ dma_run_dependencies(tx);
+}
+
+static void talitos_release_xor(struct device *dev, struct talitos_desc *hwdesc,
+ void *context, int error)
+{
+ struct talitos_xor_desc *desc = context;
+ struct talitos_xor_chan *xor_chan;
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ if (unlikely(error))
+ dev_err(dev, "xor operation: talitos error %d\n", error);
+
+ xor_chan = container_of(desc->async_tx.chan, struct talitos_xor_chan,
+ common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ if (xor_chan->completed_cookie < desc->async_tx.cookie)
+ xor_chan->completed_cookie = desc->async_tx.cookie;
+
+ callback = desc->async_tx.callback;
+ callback_param = desc->async_tx.callback_param;
+
+ if (callback) {
+ spin_unlock_bh(&xor_chan->desc_lock);
+ callback(callback_param);
+ spin_lock_bh(&xor_chan->desc_lock);
+ }
+
+ talitos_xor_run_tx_complete_actions(desc, xor_chan);
+
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->free_desc);
+ spin_unlock_bh(&xor_chan->desc_lock);
+ if (!list_empty(&xor_chan->pending_q))
+ talitos_process_pending(xor_chan);
+}
+
+/**
+ * talitos_issue_pending - move the descriptors in submit
+ * queue to pending queue and submit them for processing
+ * @chan: DMA channel
+ */
+static void talitos_issue_pending(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_splice_tail_init(&xor_chan->submit_q,
+ &xor_chan->pending_q);
+ spin_unlock_bh(&xor_chan->desc_lock);
+ talitos_process_pending(xor_chan);
+}
+
+static dma_cookie_t talitos_async_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+ struct talitos_xor_desc *desc;
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t cookie;
+
+ desc = container_of(tx, struct talitos_xor_desc, async_tx);
+ xor_chan = container_of(tx->chan, struct talitos_xor_chan, common);
+
+ spin_lock_bh(&xor_chan->desc_lock);
+
+ cookie = xor_chan->common.cookie + 1;
+ if (cookie < 0)
+ cookie = 1;
+
+ desc->async_tx.cookie = cookie;
+ xor_chan->common.cookie = desc->async_tx.cookie;
+
+ list_splice_tail_init(&desc->tx_list,
+ &xor_chan->submit_q);
+
+ spin_unlock_bh(&xor_chan->desc_lock);
+
+ return cookie;
+}
+
+static struct talitos_xor_desc *talitos_xor_alloc_descriptor(
+ struct talitos_xor_chan *xor_chan, gfp_t flags)
+{
+ struct talitos_xor_desc *desc;
+
+ desc = kmalloc(sizeof(*desc), flags);
+ if (desc) {
+ xor_chan->total_desc++;
+ desc->async_tx.tx_submit = talitos_async_tx_submit;
+ }
+
+ return desc;
+}
+
+static void talitos_free_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc, *_desc;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ spin_lock_bh(&xor_chan->desc_lock);
+
+ list_for_each_entry_safe(desc, _desc, &xor_chan->submit_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->in_progress_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->free_desc, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+
+ /* Some descriptor not freed? */
+ if (unlikely(xor_chan->total_desc))
+ dev_warn(chan->device->dev, "Failed to free xor channel resource\n");
+
+ spin_unlock_bh(&xor_chan->desc_lock);
+}
+
+static int talitos_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc;
+ LIST_HEAD(tmp_list);
+ int i;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ if (!list_empty(&xor_chan->free_desc))
+ return xor_chan->total_desc;
+
+ for (i = 0; i < TALITOS_MAX_DESCRIPTOR_NR; i++) {
+ desc = talitos_xor_alloc_descriptor(xor_chan,
+ GFP_KERNEL | GFP_DMA);
+ if (!desc) {
+ dev_err(xor_chan->common.device->dev,
+ "Only %d initial descriptors\n", i);
+ break;
+ }
+ list_add_tail(&desc->node, &tmp_list);
+ }
+
+ if (!i)
+ return -ENOMEM;
+
+ /* At least one desc is allocated */
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_splice_init(&tmp_list, &xor_chan->free_desc);
+ spin_unlock_bh(&xor_chan->desc_lock);
+
+ return xor_chan->total_desc;
+}
+
+static struct dma_async_tx_descriptor *talitos_prep_dma_xor(
+ struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
+ unsigned int src_cnt, size_t len, unsigned long flags)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *new;
+ struct talitos_desc *desc;
+ int i, j;
+
+ BUG_ON(len > TALITOS_MAX_DATA_LEN);
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ spin_lock_bh(&xor_chan->desc_lock);
+ if (!list_empty(&xor_chan->free_desc)) {
+ new = container_of(xor_chan->free_desc.next,
+ struct talitos_xor_desc, node);
+ list_del(&new->node);
+ } else {
+ new = talitos_xor_alloc_descriptor(xor_chan, GFP_KERNEL | GFP_DMA);
+ }
+ spin_unlock_bh(&xor_chan->desc_lock);
+
+ if (!new) {
+ dev_err(xor_chan->common.device->dev,
+ "No free memory for XOR DMA descriptor\n");
+ return NULL;
+ }
+ dma_async_tx_descriptor_init(&new->async_tx, &xor_chan->common);
+
+ INIT_LIST_HEAD(&new->node);
+ INIT_LIST_HEAD(&new->tx_list);
+
+ desc = &new->hwdesc;
+ /* Set destination: Last pointer pair */
+ to_talitos_ptr(&desc->ptr[6], dest);
+ desc->ptr[6].len = cpu_to_be16(len);
+ desc->ptr[6].j_extent = 0;
+ new->unmap_src_cnt = src_cnt;
+ new->unmap_len = len;
+
+ /* Set Sources: End loading from second-last pointer pair */
+ for (i = 5, j = 0; j < src_cnt && i >= 0; i--, j++) {
+ to_talitos_ptr(&desc->ptr[i], src[j]);
+ desc->ptr[i].len = cpu_to_be16(len);
+ desc->ptr[i].j_extent = 0;
+ }
+
+ /*
+ * documentation states first 0 ptr/len combo marks end of sources
+ * yet device produces scatter boundary error unless all subsequent
+ * sources are zeroed out
+ */
+ for (; i >= 0; i--) {
+ to_talitos_ptr(&desc->ptr[i], 0);
+ desc->ptr[i].len = 0;
+ desc->ptr[i].j_extent = 0;
+ }
+
+ desc->hdr = DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_AESU_XOR |
+ DESC_HDR_TYPE_RAID_XOR;
+
+ new->async_tx.parent = NULL;
+ new->async_tx.next = NULL;
+ new->async_tx.cookie = 0;
+ async_tx_ack(&new->async_tx);
+
+ list_add_tail(&new->node, &new->tx_list);
+
+ new->async_tx.flags = flags;
+ new->async_tx.cookie = -EBUSY;
+
+ return &new->async_tx;
+}
+
+static void talitos_unregister_async_xor(struct device *dev)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct talitos_xor_chan *xor_chan;
+ struct dma_chan *chan, *_chan;
+
+ if (priv->dma_dev_common.chancnt)
+ dma_async_device_unregister(&priv->dma_dev_common);
+
+ list_for_each_entry_safe(chan, _chan, &priv->dma_dev_common.channels,
+ device_node) {
+ xor_chan = container_of(chan, struct talitos_xor_chan,
+ common);
+ list_del(&chan->device_node);
+ priv->dma_dev_common.chancnt--;
+ kfree(xor_chan);
+ }
+}
+
+/**
+ * talitos_register_dma_async - Initialize the Freescale XOR ADMA device
+ * It is registered as a DMA device with the capability to perform
+ * XOR operation with the Async_tx layer.
+ * The various queues and channel resources are also allocated.
+ */
+static int talitos_register_async_tx(struct device *dev, int max_xor_srcs)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct dma_device *dma_dev = &priv->dma_dev_common;
+ struct talitos_xor_chan *xor_chan;
+ int err;
+
+ xor_chan = kzalloc(sizeof(struct talitos_xor_chan), GFP_KERNEL);
+ if (!xor_chan) {
+ dev_err(dev, "unable to allocate xor channel\n");
+ return -ENOMEM;
+ }
+
+ dma_dev->dev = dev;
+ dma_dev->device_alloc_chan_resources = talitos_alloc_chan_resources;
+ dma_dev->device_free_chan_resources = talitos_free_chan_resources;
+ dma_dev->device_prep_dma_xor = talitos_prep_dma_xor;
+ dma_dev->max_xor = max_xor_srcs;
+ dma_dev->device_tx_status = talitos_is_tx_complete;
+ dma_dev->device_issue_pending = talitos_issue_pending;
+ INIT_LIST_HEAD(&dma_dev->channels);
+ dma_cap_set(DMA_XOR, dma_dev->cap_mask);
+
+ xor_chan->dev = dev;
+ xor_chan->common.device = dma_dev;
+ xor_chan->total_desc = 0;
+ INIT_LIST_HEAD(&xor_chan->submit_q);
+ INIT_LIST_HEAD(&xor_chan->pending_q);
+ INIT_LIST_HEAD(&xor_chan->in_progress_q);
+ INIT_LIST_HEAD(&xor_chan->free_desc);
+ spin_lock_init(&xor_chan->desc_lock);
+
+ list_add_tail(&xor_chan->common.device_node, &dma_dev->channels);
+ dma_dev->chancnt++;
+
+ err = dma_async_device_register(dma_dev);
+ if (err) {
+ dev_err(dev, "Unable to register XOR with Async_tx\n");
+ goto err_out;
+ }
+
+ return err;
+
+err_out:
+ talitos_unregister_async_xor(dev);
+ return err;
+}
+#endif
+
/*
* crypto alg
*/
@@ -2891,6 +3284,26 @@ static int talitos_probe(struct platform_device *ofdev)
dev_info(dev, "hwrng\n");
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ /*
+ * register with async_tx xor, if capable
+ * SEC 2.x support up to 3 RAID sources,
+ * SEC 3.x support up to 6
+ */
+ if (hw_supports(dev, DESC_HDR_SEL0_AESU | DESC_HDR_TYPE_RAID_XOR)) {
+ int max_xor_srcs = 3;
+ if (of_device_is_compatible(np, "fsl,sec3.0"))
+ max_xor_srcs = 6;
+ err = talitos_register_async_tx(dev, max_xor_srcs);
+ if (err) {
+ dev_err(dev, "failed to register async_tx xor: %d\n",
+ err);
+ goto err_out;
+ }
+ dev_info(dev, "max_xor_srcs %d\n", max_xor_srcs);
+ }
+#endif
+
/* register crypto algorithms the device supports */
for (i = 0; i < ARRAY_SIZE(driver_algs); i++) {
if (hw_supports(dev, driver_algs[i].desc_hdr_template)) {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 61a1405..fc9d125 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -30,6 +30,7 @@
#define TALITOS_TIMEOUT 100000
#define TALITOS_MAX_DATA_LEN 65535
+#define TALITOS_MAX_DESCRIPTOR_NR 256
#define DESC_TYPE(desc_hdr) ((be32_to_cpu(desc_hdr) >> 3) & 0x1f)
#define PRIMARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) >> 28) & 0xf)
@@ -131,7 +132,57 @@ struct talitos_private {
/* hwrng device */
struct hwrng rng;
+
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ /* XOR Device */
+ struct dma_device dma_dev_common;
+#endif
+};
+
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+/**
+ * talitos_xor_chan - context management for the async_tx channel
+ * @completed_cookie: the last completed cookie
+ * @desc_lock: lock for tx queue
+ * @total_desc: number of descriptors allocated
+ * @submit_q: queue of submitted descriptors
+ * @pending_q: queue of pending descriptors
+ * @in_progress_q: queue of descriptors in progress
+ * @free_desc: queue of unused descriptors
+ * @dev: talitos device implementing this channel
+ * @common: the corresponding xor channel in async_tx
+ */
+struct talitos_xor_chan {
+ dma_cookie_t completed_cookie;
+ spinlock_t desc_lock;
+ unsigned int total_desc;
+ struct list_head submit_q;
+ struct list_head pending_q;
+ struct list_head in_progress_q;
+ struct list_head free_desc;
+ struct device *dev;
+ struct dma_chan common;
+};
+
+/**
+ * talitos_xor_desc - software xor descriptor
+ * @async_tx: the referring async_tx descriptor
+ * @node:
+ * @hwdesc: h/w descriptor
+ * @unmap_src_cnt: number of xor sources
+ * @unmap_len: transaction byte count
+ * @idx: index of xor sources
+ */
+struct talitos_xor_desc {
+ struct dma_async_tx_descriptor async_tx;
+ struct list_head tx_list;
+ struct list_head node;
+ struct talitos_desc hwdesc;
+ unsigned int unmap_src_cnt;
+ unsigned int unmap_len;
+ unsigned int idx;
};
+#endif
extern int talitos_submit(struct device *dev, int ch, struct talitos_desc *desc,
void (*callback)(struct device *dev,
@@ -284,6 +335,7 @@ extern int talitos_submit(struct device *dev, int ch, struct talitos_desc *desc,
/* primary execution unit mode (MODE0) and derivatives */
#define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x00100000)
#define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x00200000)
+#define DESC_HDR_MODE0_AESU_XOR cpu_to_be32(0x0c600000)
#define DESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x00400000)
#define DESC_HDR_MODE0_DEU_3DES cpu_to_be32(0x00200000)
#define DESC_HDR_MODE0_MDEU_CONT cpu_to_be32(0x08000000)
@@ -344,6 +396,7 @@ extern int talitos_submit(struct device *dev, int ch, struct talitos_desc *desc,
#define DESC_HDR_TYPE_IPSEC_ESP cpu_to_be32(1 << 3)
#define DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU cpu_to_be32(2 << 3)
#define DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU cpu_to_be32(4 << 3)
+#define DESC_HDR_TYPE_RAID_XOR cpu_to_be32(21 << 3)
/* link table extent field bits */
#define DESC_PTR_LNKTBL_JUMP 0x80
--
1.7.5.1
^ permalink raw reply related
* [PATCH v7 0/8] Raid: enable talitos xor offload for improving performance
From: qiang.liu @ 2012-08-09 8:19 UTC (permalink / raw)
To: linux-crypto, vinod.koul, dan.j.williams, herbert, arnd, gregkh,
linuxppc-dev, linux-kernel, dan.j.williams
Hi all,
The following 8 patches enabling fsl-dma and talitos offload raid
operations for improving raid performance and balancing CPU load.
These patches include talitos, fsl-dma and carma module (caram uses
some features of fsl-dma).
Write performance will be improved by 25-30% tested by iozone.
Write performance is improved about 2% after using spin_lock_bh replace
spin_lock_irqsave.
CPU load will be reduced by 8%.
"fwiw, I gave v5 a test-drive, setting up a RAID5 array on ramdisks
[1], and this patchseries, along with FSL_DMA && NET_DMA set seems
to be holding water, so this series gets my:"
Tested-by: Kim Phillips <kim.phillips@freescale.com>
[1] mdadm --create --verbose --force /dev/md0 --level=raid5 --raid-devices=4 \
/dev/ram[0123]
Changes in v7:
- add test result which is provided by Kim Phillips;
- correct one coding style issue in patch 5/8;
- add comments by Arnd Bergmann in patch 6/8;
Changes in v6:
- swap the order of original patch 3/6 and 4/6;
- merge Ira's patch to reduce the size of original patch;
- merge Ira's patch of carma in 8/8;
- update documents and descriptions according to Ira's advice;
Changes in v5:
- add detail description in patch 3/6 about the process of completed
descriptor, the process is in align with fsl-dma Reference Manual,
illustrate the potential risk and how to reproduce it;
- drop the patch 7/7 in v4 according to Timur's comments;
Changes in v4:
- fix an error in talitos when dest addr is same with src addr, dest
should be freed only one time if src is same with dest addr;
- correct coding style in fsl-dma according to Ira's comments;
- fix a race condition in fsl-dma fsl_tx_status(), remove the interface
which is used to free descriptors in queue ld_completed, this interface
has been included in fsldma_cleanup_descriptor(), in v3, there is one
place missed spin_lock protect;
- split the original patch 3/4 up to 2 patches 3/7 and 4/7 according to
Li Yang's comments;
- fix a warning of unitialized cookie;
- add memory copy self test in fsl-dma;
- add more detail description about use spin_lock_bh() to instead of
spin_lock_irqsave() according to Timur's comments.
Changes in v3:
- change release process of fsl-dma descriptor for resolve the
potential race condition;
- add test result when use spin_lock_bh replace spin_lock_irqsave;
- modify the benchmark results according to the latest patch.
Changes in v2:
- rebase onto cryptodev tree;
- split the patch 3/4 up to 3 independent patches;
- remove the patch 4/4, the fix is not for cryptodev tree;
Qiang Liu (8):
Talitos: Support for async_tx XOR offload
fsl-dma: remove attribute DMA_INTERRUPT of dmaengine
fsl-dma: add fsl_dma_free_descriptor() to reduce code duplication
fsl-dma: move functions to avoid forward declarations
fsl-dma: change release process of dma descriptor for supporting async_tx
fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave
fsl-dma: fix a warning of unitialized cookie
carma: remove unnecessary DMA_INTERRUPT capability
drivers/crypto/Kconfig | 9 +
drivers/crypto/talitos.c | 413 ++++++++++++++++++++++++++
drivers/crypto/talitos.h | 53 ++++
drivers/dma/fsldma.c | 488 +++++++++++++++++--------------
drivers/dma/fsldma.h | 17 +-
drivers/misc/carma/carma-fpga-program.c | 1 -
drivers/misc/carma/carma-fpga.c | 2 +-
7 files changed, 761 insertions(+), 222 deletions(-)
^ permalink raw reply
* [PATCH 3/3, v2] powerpc/e5500: Add Power ISA properties to comply with ePAPR 1.1
From: Olivia Yin @ 2012-08-09 7:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olivia Yin
In-Reply-To: <1344498156-25127-2-git-send-email-hong-hua.yin@freescale.com>
power-isa-version and power-isa-* are cpu node general properties defined in ePAPR.
If the power-isa-version property exists, then for each category from the
Categories section of Book I of the Power ISA version indicated, the
existence of a property named power-isa-[CAT], where [CAT] is the
abbreviated category name with all uppercase letters converted to
lowercase, indicates that the category is supported by the implementation.
This patch update all the e5500 platforms.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Olivia Yin <hong-hua.yin@freescale.com>
---
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
branch: next
arch/powerpc/boot/dts/fsl/e5500_power_isa.dtsi | 59 ++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 3 +
2 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/e5500_power_isa.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/e5500_power_isa.dtsi b/arch/powerpc/boot/dts/fsl/e5500_power_isa.dtsi
new file mode 100644
index 0000000..0e26eb5
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/e5500_power_isa.dtsi
@@ -0,0 +1,59 @@
+/*
+ * e5500 Power ISA Device Tree Source (include)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/ {
+ cpus {
+ power-isa-version = "2.06";
+ power-isa-b; // Base
+ power-isa-e; // Embedded
+ power-isa-atb; // Alternate Time Base
+ power-isa-cs; // Cache Specification
+ power-isa-ds; // Decorated Storage
+ power-isa-e.ed; // Embedded.Enhanced Debug
+ power-isa-e.pd; // Embedded.External PID
+ power-isa-e.hv; // Embedded.Hypervisor
+ power-isa-e.le; // Embedded.Little-Endian
+ power-isa-e.pm; // Embedded.Performance Monitor
+ power-isa-e.pc; // Embedded.Processor Control
+ power-isa-ecl; // Embedded Cache Locking
+ power-isa-exp; // External Proxy
+ power-isa-fp; // Floating Point
+ power-isa-fp.r; // Floating Point.Record
+ power-isa-mmc; // Memory Coherence
+ power-isa-scpm; // Store Conditional Page Mobility
+ power-isa-wt; // Wait
+ power-isa-64; // 64-bit
+ mmu-type = "power-embedded";
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
index ae823a4..0a198b0 100644
--- a/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e5500_power_isa.dtsi"
+
/ {
compatible = "fsl,P5020";
#address-cells = <2>;
--
1.6.4
^ permalink raw reply related
* [PATCH 2/3, v2] powerpc/e500mc: Add Power ISA properties to comply with ePAPR 1.1
From: Olivia Yin @ 2012-08-09 7:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olivia Yin
In-Reply-To: <1344498156-25127-1-git-send-email-hong-hua.yin@freescale.com>
power-isa-version and power-isa-* are cpu node general properties defined in ePAPR.
If the power-isa-version property exists, then for each category from the
Categories section of Book I of the Power ISA version indicated, the
existence of a property named power-isa-[CAT], where [CAT] is the
abbreviated category name with all uppercase letters converted to
lowercase, indicates that the category is supported by the implementation.
The patch update all the e500mc platforms.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Olivia Yin <hong-hua.yin@freescale.com>
---
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
branch: next
arch/powerpc/boot/dts/fsl/e500mc_power_isa.dtsi | 58 +++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 3 +
4 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/e500mc_power_isa.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/e500mc_power_isa.dtsi b/arch/powerpc/boot/dts/fsl/e500mc_power_isa.dtsi
new file mode 100644
index 0000000..fa40047
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/e500mc_power_isa.dtsi
@@ -0,0 +1,58 @@
+/*
+ * e500mc Power ISA Device Tree Source (include)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/ {
+ cpus {
+ power-isa-version = "2.06";
+ power-isa-b; // Base
+ power-isa-e; // Embedded
+ power-isa-atb; // Alternate Time Base
+ power-isa-cs; // Cache Specification
+ power-isa-ds; // Decorated Storage
+ power-isa-e.ed; // Embedded.Enhanced Debug
+ power-isa-e.pd; // Embedded.External PID
+ power-isa-e.hv; // Embedded.Hypervisor
+ power-isa-e.le; // Embedded.Little-Endian
+ power-isa-e.pm; // Embedded.Performance Monitor
+ power-isa-e.pc; // Embedded.Processor Control
+ power-isa-ecl; // Embedded Cache Locking
+ power-isa-exp; // External Proxy
+ power-isa-fp; // Floating Point
+ power-isa-fp.r; // Floating Point.Record
+ power-isa-mmc; // Memory Coherence
+ power-isa-scpm; // Store Conditional Page Mobility
+ power-isa-wt; // Wait
+ mmu-type = "power-embedded";
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
index 2d0a40d..7a2697d 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500mc_power_isa.dtsi"
+
/ {
compatible = "fsl,P2041";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
index 136def3..c9ca2c3 100644
--- a/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500mc_power_isa.dtsi"
+
/ {
compatible = "fsl,P3041";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
index b9556ee..493d9a0 100644
--- a/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500mc_power_isa.dtsi"
+
/ {
compatible = "fsl,P4080";
#address-cells = <2>;
--
1.6.4
^ permalink raw reply related
* [PATCH 1/3, v2] powerpc/e500v2: Add Power ISA properties to comply with ePAPR 1.1
From: Olivia Yin @ 2012-08-09 7:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olivia Yin
power-isa-version and power-isa-* are cpu node general properties defined in ePAPR.
If the power-isa-version property exists, then for each category from the
Categories section of Book I of the Power ISA version indicated, the
existence of a property named power-isa-[CAT], where [CAT] is the
abbreviated category name with all uppercase letters converted to
lowercase, indicates that the category is supported by the implementation.
The patch update all e500v2 platforms.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Olivia Yin <hong-hua.yin@freescale.com>
---
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
branch: next
arch/powerpc/boot/dts/fsl/e500v2_power_isa.dtsi | 52 +++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/mpc8572si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi | 3 +
arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi | 3 +
arch/powerpc/boot/dts/mpc8540ads.dts | 2 +
arch/powerpc/boot/dts/mpc8541cds.dts | 2 +
arch/powerpc/boot/dts/mpc8555cds.dts | 2 +
arch/powerpc/boot/dts/mpc8560ads.dts | 2 +
17 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/e500v2_power_isa.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/e500v2_power_isa.dtsi b/arch/powerpc/boot/dts/fsl/e500v2_power_isa.dtsi
new file mode 100644
index 0000000..efd6c73
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/e500v2_power_isa.dtsi
@@ -0,0 +1,52 @@
+/*
+ * e500v2 Power ISA Device Tree Source (include)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/ {
+ cpus {
+ power-isa-version = "2.03";
+ power-isa-b; // Base
+ power-isa-e; // Embedded
+ power-isa-atb; // Alternate Time Base
+ power-isa-cs; // Cache Specification
+ power-isa-e.le; // Embedded.Little-Endian
+ power-isa-e.pm; // Embedded.Performance Monitor
+ power-isa-ecl; // Embedded Cache Locking
+ power-isa-mmc; // Memory Coherence
+ power-isa-sp; // Signal Processing Engine
+ power-isa-sp.fd; // SPE.Embedded Float Scalar Double
+ power-isa-sp.fs; // SPE.Embedded Float Scalar Single
+ power-isa-sp.fv; // SPE.Embedded Float Vector
+ mmu-type = "power-embedded";
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi b/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
index 7de45a7..152906f 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,MPC8536";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi b/arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi
index 8777f92..5a69baf 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,MPC8544";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi b/arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi
index 720422d..fc1ce97 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,MPC8548";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi b/arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi
index eacd62c..122ca3b 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,MPC8568";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi b/arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi
index b07064d..2cd15a2 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,MPC8569";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/mpc8572si-pre.dtsi b/arch/powerpc/boot/dts/fsl/mpc8572si-pre.dtsi
index ca18832..28c2a86 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8572si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8572si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,MPC8572";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi
index 7354a8f..6e76f9b 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,P1010";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
index 6f0376e..fed9c4c 100644
--- a/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,P1020";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi
index 4abd54b..36161b5 100644
--- a/arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,P1021";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
index e930f4f..1956dea 100644
--- a/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,P1022";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi
index ac45f6d..132a152 100644
--- a/arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,P1023";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi
index 3213288..42bf3c6 100644
--- a/arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi
@@ -33,6 +33,9 @@
*/
/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
/ {
compatible = "fsl,P2020";
#address-cells = <2>;
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
index f99fb11..2d31863 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -11,6 +11,8 @@
/dts-v1/;
+/include/ "fsl/e500v2_power_isa.dtsi"
+
/ {
model = "MPC8540ADS";
compatible = "MPC8540ADS", "MPC85xxADS";
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts b/arch/powerpc/boot/dts/mpc8541cds.dts
index 0f5e939..1c03c26 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -11,6 +11,8 @@
/dts-v1/;
+/include/ "fsl/e500v2_power_isa.dtsi"
+
/ {
model = "MPC8541CDS";
compatible = "MPC8541CDS", "MPC85xxCDS";
diff --git a/arch/powerpc/boot/dts/mpc8555cds.dts b/arch/powerpc/boot/dts/mpc8555cds.dts
index fe10438..36a7ea1 100644
--- a/arch/powerpc/boot/dts/mpc8555cds.dts
+++ b/arch/powerpc/boot/dts/mpc8555cds.dts
@@ -11,6 +11,8 @@
/dts-v1/;
+/include/ "fsl/e500v2_power_isa.dtsi"
+
/ {
model = "MPC8555CDS";
compatible = "MPC8555CDS", "MPC85xxCDS";
diff --git a/arch/powerpc/boot/dts/mpc8560ads.dts b/arch/powerpc/boot/dts/mpc8560ads.dts
index 6e85e1b..1a43f5a 100644
--- a/arch/powerpc/boot/dts/mpc8560ads.dts
+++ b/arch/powerpc/boot/dts/mpc8560ads.dts
@@ -11,6 +11,8 @@
/dts-v1/;
+/include/ "fsl/e500v2_power_isa.dtsi"
+
/ {
model = "MPC8560ADS";
compatible = "MPC8560ADS", "MPC85xxADS";
--
1.6.4
^ permalink raw reply related
* Re: [PATCH V5 2/3] powerpc/swiotlb: Enable at early stage and disable if not necessary
From: Tony Breeds @ 2012-08-09 5:57 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org list,
Jia Hongtao
In-Reply-To: <66F04906-39B4-493D-8C63-202112AB1EA3@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]
On Wed, Aug 08, 2012 at 02:03:45PM -0500, Kumar Gala wrote:
>
> On Aug 3, 2012, at 5:14 AM, Jia Hongtao wrote:
>
> > Remove the dependency on PCI initialization for SWIOTLB initialization.
> > So that PCI can be initialized at proper time.
> >
> > SWIOTLB is partly determined by PCI inbound/outbound map which is assigned
> > in PCI initialization. But swiotlb_init() should be done at the stage of
> > mem_init() which is much earlier than PCI initialization. So we reserve the
> > memory for SWIOTLB first and free it if not necessary.
> >
> > All boards are converted to fit this change.
> >
> > Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > arch/powerpc/include/asm/swiotlb.h | 6 ++++++
> > arch/powerpc/kernel/dma-swiotlb.c | 20 ++++++++++++++++++++
> > arch/powerpc/mm/mem.c | 3 +--
> > arch/powerpc/platforms/44x/currituck.c | 10 ++--------
> > arch/powerpc/platforms/85xx/mpc85xx_ds.c | 1 +
> > arch/powerpc/platforms/85xx/qemu_e500.c | 1 +
> > arch/powerpc/sysdev/fsl_pci.c | 5 +----
> > 7 files changed, 32 insertions(+), 14 deletions(-)
>
> Josh, Tony
>
> Can you ack the 44x/currituck.c change.
Looks fine to me.
Acked-by: Tony Breeds <tony@bakeyournoodle.com>
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Li Yang @ 2012-08-09 5:05 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01A51DA2@039-SN1MPN1-002.039d.mgd.msft.net>
On Thu, Aug 9, 2012 at 10:52 AM, Jia Hongtao-B38951
<B38951@freescale.com> wrote:
>
>
>> -----Original Message-----
>> From: Linuxppc-dev [mailto:linuxppc-dev-
>> bounces+b38951=freescale.com@lists.ozlabs.org] On Behalf Of Kumar Gala
>> Sent: Wednesday, August 08, 2012 8:47 PM
>> To: Jia Hongtao-B38951
>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
>> Subject: Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM
>> support
>>
>> >>>>>>
>> >>>>>> On Jul 24, 2012, at 5:20 AM, Jia Hongtao wrote:
>> >>>>>>
>> >>>>>>> Power supply for PCI inbound/outbound window registers is off
>> >>>>>>> when
>> >>>>>> system
>> >>>>>>> go to deep-sleep state. We save the values of registers before
>> >>>>>>> suspend and restore to registers after resume.
>> >>>>>>>
>> >>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>> >>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>> >>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>> >>>>>>> ---
>> >>>>>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
>> >>>>>>> arch/powerpc/sysdev/fsl_pci.c | 121
>> >>>>>> +++++++++++++++++++++++++++++++++
>> >>>>>>> 2 files changed, 122 insertions(+), 1 deletions(-)
>> >>>>>>
>> >>>>>> Remind me why we need to save/restore PCI ATMUs, why not just
>> >>>>>> re-parse the device tree to restore?
>> >>>>>>
>> >>>>>> - k
>> >>>>>
>> >>>>> Save/restore is the more efficient way. Latency of sleep/wakeup is
>> >>>>> one of most important features in power management.
>> >>>>>
>> >>>>> -Hongtao.
>> >>>>
>> >>>> I don't think the time it takes to run through setup_pci_atmu() is
>> >>>> that long compared to fsl_pci_resume().
>> >>>>
>> >>>> Also, don't you need to setup PCICCSRBAR and do setup_pci_cmd() on
>> >> resume?
>> >>>>
>> >>>> - k
>> >>>
>> >>> Hi Kumar,
>> >>> I did some tests on P1022DS and found out that PCI_CMD and PCICSRBAR
>> >>> is not lost when system in deep sleep. We don't need to save it.
>> >>
>> >> How does the PCI code know you're entering deep sleep and not
>> hibernation?
>> >>
>> >> -Scott
>> >
>> > When system come back from hibernation PCI will be initialized again.
>> > So no need to save PCI_CMD and PEXCSRBAR.
>> >
>> > -Hongtao.
>> >
>>
>> What do you mean PCI will be initialized again? What code path are you
>> talking about that would set PCI_CMD & PEXCSRBAR?
>>
>> - k
>
>
> In hibernation mode:
>
> When system come back from hibernation kernel will start up again.
> Before loading hibernation image PCI initialization has already done.
> Some other hardware also re-init again.
In current Linux implementation, restoring from hibernation image is
using late initcall. By that time, all the platform devices are
already initialized like a fresh boot.
- Leo
^ permalink raw reply
* RE: [PATCH V4 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2012-08-09 3:52 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <50228B8A.7010008@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDgsIDIwMTIgMTE6NTQgUE0NCj4gVG86IEpp
YSBIb25ndGFvLUIzODk1MQ0KPiBDYzogV29vZCBTY290dC1CMDc0MjE7IEt1bWFyIEdhbGE7IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBMaQ0KPiBZYW5nLVI1ODQ3Mg0KPiBTdWJqZWN0
OiBSZTogW1BBVENIIFY0IDMvM10gcG93ZXJwYy9mc2wtcGNpOiBVbmlmeSBwY2kvcGNpZQ0KPiBp
bml0aWFsaXphdGlvbiBjb2RlDQo+IA0KPiBPbiAwOC8wNy8yMDEyIDEwOjU3IFBNLCBKaWEgSG9u
Z3Rhby1CMzg5NTEgd3JvdGU6DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiA+PiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBB
dWd1c3QgMDcsIDIwMTIgMTE6MjAgUE0NCj4gPj4gVG86IEppYSBIb25ndGFvLUIzODk1MQ0KPiA+
PiBDYzogV29vZCBTY290dC1CMDc0MjE7IEt1bWFyIEdhbGE7IGxpbnV4cHBjLWRldkBsaXN0cy5v
emxhYnMub3JnOyBMaQ0KPiA+PiBZYW5nLVI1ODQ3Mg0KPiA+PiBTdWJqZWN0OiBSZTogW1BBVENI
IFY0IDMvM10gcG93ZXJwYy9mc2wtcGNpOiBVbmlmeSBwY2kvcGNpZQ0KPiA+PiBpbml0aWFsaXph
dGlvbiBjb2RlDQo+ID4+DQo+ID4+IE9uIDA4LzA3LzIwMTIgMDE6MjMgQU0sIEppYSBIb25ndGFv
LUIzODk1MSB3cm90ZToNCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+
IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4+Pj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMDYs
IDIwMTIgMTE6MTYgUE0NCj4gPj4+PiBUbzogSmlhIEhvbmd0YW8tQjM4OTUxDQo+ID4+Pj4gQ2M6
IFdvb2QgU2NvdHQtQjA3NDIxOyBLdW1hciBHYWxhOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJz
Lm9yZzsNCj4gPj4+PiBMaQ0KPiA+Pj4+IFlhbmctUjU4NDcyDQo+ID4+Pj4gU3ViamVjdDogUmU6
IFtQQVRDSCBWNCAzLzNdIHBvd2VycGMvZnNsLXBjaTogVW5pZnkgcGNpL3BjaWUNCj4gPj4+PiBp
bml0aWFsaXphdGlvbiBjb2RlDQo+ID4+Pj4NCj4gPj4+PiBPbiAwOC8wNS8yMDEyIDA5OjM5IFBN
LCBKaWEgSG9uZ3Rhby1CMzg5NTEgd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gPj4+Pj4+IFNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMDQsIDIwMTIgMTI6MDQgQU0NCj4g
Pj4+Pj4+IFRvOiBKaWEgSG9uZ3Rhby1CMzg5NTENCj4gPj4+Pj4+IENjOiBLdW1hciBHYWxhOyBs
aW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgV29vZCBTY290dC1CMDc0MjE7DQo+ID4+Pj4+
PiBMaQ0KPiA+Pj4+Pj4gWWFuZy1SNTg0NzINCj4gPj4+Pj4+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
VjQgMy8zXSBwb3dlcnBjL2ZzbC1wY2k6IFVuaWZ5IHBjaS9wY2llDQo+ID4+Pj4+PiBpbml0aWFs
aXphdGlvbiBjb2RlDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gMDgvMDIvMjAxMiAxMDozOSBQTSwg
SmlhIEhvbmd0YW8tQjM4OTUxIHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+
Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4gRnJvbTogS3VtYXIgR2Fs
YSBbbWFpbHRvOmdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmddDQo+ID4+Pj4+Pj4+IFNlbnQ6IFRo
dXJzZGF5LCBBdWd1c3QgMDIsIDIwMTIgODoyNCBQTQ0KPiA+Pj4+Pj4+PiBUbzogSmlhIEhvbmd0
YW8tQjM4OTUxDQo+ID4+Pj4+Pj4+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg
V29vZCBTY290dC1CMDc0MjE7IExpDQo+ID4+Pj4+Pj4+IFlhbmctUjU4NDcyDQo+ID4+Pj4+Pj4+
IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjQgMy8zXSBwb3dlcnBjL2ZzbC1wY2k6IFVuaWZ5IHBjaS9w
Y2llDQo+ID4+Pj4+Pj4+IGluaXRpYWxpemF0aW9uIGNvZGUNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+
Pj4gWW91IG5lZWQgdG8gY29udmVydCBhbGwgYm9hcmRzIHRvIHVzZSBmc2xfcGNpX2luaXQgYmVm
b3JlIHRoaXMNCj4gPj4gcGF0Y2guDQo+ID4+Pj4+Pj4+IE90aGVyd2lzZSB3ZSdsbCBlbmQgdXAg
d2l0aCBQQ0kgZ2V0dGluZyBpbml0aWFsaXplZCB0d2ljZSBvbg0KPiA+PiBib2FyZHMuDQo+ID4+
Pj4+Pj4+DQo+ID4+Pj4+Pj4+IC0gaw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgd2UgY292ZXJ0
IGFsbCBib2FyZHMgd2l0aCBwbGF0Zm9ybSBkcml2ZXIgaW4gdGhpcyBwYXRjaCBQQ0kNCj4gPj4+
Pj4+PiB3aWxsIGJlIGluaXRpYWxpemVkIG9ubHkgb25jZSB3aXRob3V0IGNvbnZlcnRpbmcgYWxs
IGJvYXJkcyB0bw0KPiA+Pj4+Pj4+IHVzZSBmc2xfcGNpX2luaXQgZmlyc3QuDQo+ID4+Pj4+Pg0K
PiA+Pj4+Pj4gVGhlbiB3ZSdkIGhhdmUgdG8gcGljayBhcGFydCBjb3JlIGNoYW5nZXMgZnJvbSBi
b2FyZCBjaGFuZ2VzIHdoZW4NCj4gPj4+Pj4+IHJldmlld2luZy4NCj4gPj4+Pj4+DQo+ID4+Pj4+
Pj4gSWYgd2UgY29udmVydCBhbGwgYm9hcmRzIHRvIHVzZSBmc2xfcGNpX2luaXQgYmVmb3JlIHRo
aXMgcGF0Y2gNCj4gPj4+Pj4+PiBhbmQgY29udmVydCB0aGVtIHRvIHVzZSBwbGF0Zm9ybSBkcml2
ZXIgYWdhaW4gYWZ0ZXIgdGhpcyBwYXRjaC4NCj4gPj4+Pj4+PiBUaGVuIGJldHdlZW4gdGhpcyBw
YXRjaCBhbmQgbmV4dCBwY2kgd2lsbCBiZSBpbml0aWFsaXplZCB0d2ljZQ0KPiB0b28uDQo+ID4+
Pj4+Pg0KPiA+Pj4+Pj4gV2h5PyAgVGhhdCBvbmUgcGF0Y2ggc2hvdWxkIGJvdGggY3JlYXRlIHRo
ZSBwbGF0Zm9ybSBkcml2ZXIgYW5kDQo+ID4+Pj4+PiByZW1vdmUgdGhlIGluaXQgZnJvbSBmc2xf
cGNpX2luaXQoKSAtLSBleGNlcHQgdGhpbmdzIGxpa2UgcHJpbWFyeQ0KPiA+PiBidXMNCj4gPj4+
Pj4+IGRldGVjdGlvbiB3aGljaCBoYXMgdG8gaGFwcGVuIGdsb2JhbGx5Lg0KPiA+Pj4+Pj4NCj4g
Pj4+Pj4+IC1TY290dA0KPiA+Pj4+Pg0KPiA+Pj4+PiAiT25lIHBhdGNoIGJvdGggY3JlYXRlIHRo
ZSBwbGF0Zm9ybSBkcml2ZXIgYW5kIHJlbW92ZSB0aGUgaW5pdA0KPiA+Pj4+PiBmcm9tIGZzbF9w
Y2lfaW5pdCgpIiBtZWFucyB3ZSBzaG91bGQgY3JlYXRlIHBsYXRmb3JtIGRyaXZlciBhbmQNCj4g
Pj4+Pj4gYXBwbGllZCB0byBhbGwgYm9hcmRzLiBJZiBzbyB3aHkgbm90IGp1c3QgZGlyZWN0bHkg
Y29udmVydCBhbGwNCj4gPj4+Pj4gYm9hcmRzIHVzaW5nIHBsYXRmb3JtIGRyaXZlcj8NCj4gPj4+
Pg0KPiA+Pj4+IEJlY2F1c2UgaXQncyBoYXJkZXIgdG8gcmV2aWV3IHdoZW4geW91IGhhdmUgYSBi
dW5jaCBvZiBib2FyZCBjb2RlDQo+ID4+Pj4gaW4NCj4gPj4gdGhlDQo+ID4+Pj4gcGF0Y2ggaW4g
YWRkaXRpb24gdG8gY29yZSBjaGFuZ2VzLg0KPiA+Pj4+DQo+ID4+Pj4gQmVjYXVzZSB5b3UgbWln
aHQgd2FudCBwZW9wbGUgdG8gYWN0dWFsbHkgdGVzdCBvbiB0aGUgYm9hcmRzIGluDQo+ID4+IHF1
ZXN0aW9uDQo+ID4+Pj4gd2hlbiBjb252ZXJ0aW5nLCBlc3BlY2lhbGx5IGdpdmVuIHRoZSBjaGFu
Z2UgaW4gaG93IHByaW1hcnkgYnVzZXMNCj4gPj4+PiBhcmUgZGV0ZXJtaW5lZCwgYW5kIHRoYXQg
c29tZSBib2FyZHMgbWF5IG5lZWQgdG8gcHJvdmlkZSB0aGVpciBvd24NCj4gPj4+PiBhbHRlcm5h
dGl2ZS4NCj4gPj4+Pg0KPiA+Pj4+IC1TY290dA0KPiA+Pj4NCj4gPj4+IEJ1dCBpZiB3ZSBzZXBh
cmF0ZSB0aGUgY29yZSBjaGFuZ2VzIGFuZCB0aGUgYm9hcmRzIHVwZGF0ZSwgYmV0d2Vlbg0KPiA+
Pj4gdGhpcw0KPiA+PiB0d28NCj4gPj4+IHBhdGNoZXMgUENJIHdpbGwgYmUgaW5pdGlhbGl6ZWQg
dHdpY2UuDQo+ID4+DQo+ID4+IEFzIEkgc2FpZCBlYXJsaWVyLCB5b3UgY2FuIHJlbW92ZSB0aGUg
aW5pdGNhbGwgYW5kIHJlcXVpcmUgYm9hcmRzIHRvDQo+ID4+IG1hbnVhbGx5IGNhbGwgZnNsX3Bj
aV9pbml0KCkgdW50aWwgYWxsIGJvYXJkcyBhcmUgY29udmVydGVkLg0KPiA+Pg0KPiA+PiAtU2Nv
dHQNCj4gPg0KPiA+IEFzIEkgc2FpZCBlYXJsaWVyLCBJIGNhbiBkbyB0aGlzIGJ1dCBpdCBkb2Vz
IG5vdCBzb2x2ZSB0aGUgdHdpY2UtaW5pdA0KPiBwcm9ibGVtLg0KPiANCj4gSSBtdXN0IGhhdmUg
bWlzc2VkIGl0LiAgV2h5IGRvZXMgaXQgbm90IHNvbHZlIHRoZSBwcm9ibGVtPyAgSWYgYSBib2Fy
ZA0KPiBkb2Vzbid0IGNhbGwgZnNsX3BjaV9pbml0KCksIHRoZSBwbGF0Zm9ybSBkcml2ZXIgZG9l
c24ndCBnZXQgcmVnaXN0ZXJlZC4NCj4gDQo+ID4gSWYgSSBkbyB0aGlzIGZpcnN0IGFuZCB0aGVu
IGFkZCBwbGF0Zm9ybSBkcml2ZXIgd2UgYWxzbyBoYXZlIHRvDQo+ID4gY29udmVydCBhbGwgYm9h
cmRzIHVzaW5nIHBsYXRmb3JtIGRyaXZlciBpbiB0aGUgc2FtZSBwYXRjaC4NCj4gPg0KPiA+IFdl
IGZpbmFsbHkgdXNpbmcgdGhlIHBsYXRmb3JtIGRyaXZlciBzbyBXaHkgZG8geW91IGtlZXAgaW5z
aXN0aW5nIG9uDQo+ID4gY29udmVydGluZyBhbGwgYm9hcmRzIHVzaW5nIGZzbF9wY2lfaW5pdCgp
IGZpcnN0IGV2ZW4gaXQgZG9lcyBubw0KPiBpbXByb3ZlbWVudC4NCj4gDQo+IFdoYXQgd2UncmUg
YXNraW5nIGZvciBpcyBiaXNlY3RhYmlsaXR5IChkb24ndCBoYXZlIGFueSBpbnRlcm1lZGlhdGUN
Cj4gc3RhZ2VzIHdoZXJlIFBDSSBnZXRzIGluaXRpYWxpemVkIHR3aWNlKSwgYW5kIHRoZSBhYmls
aXR5IHRvIGhhdmUgYQ0KPiBzbW9vdGggdHJhbnNpdGlvbiB3aGVyZSBib2FyZHMgY2FuIGJlIGNv
bnZlcnRlZCBhcyBwZW9wbGUgYXJlIGFibGUgdG8NCj4gdGVzdCB0aGVtIGFuZCBsb29rIGludG8g
dGhlaXIgaW5kaXZpZHVhbCBuZWVkcyByZWdhcmRpbmcgcHJpbWFyeSBidXMuDQo+IA0KPiAtU2Nv
dHQNCg0KSW4gbXkgcGF0Y2ggdGhlcmUgaXMgbm8gYmlzZWN0YWJpbGl0eSBwcm9ibGVtLiBJZiB5
b3UgZG9uJ3QgdGhpbmsgc28gY291bGQNCnlvdSBwbGVhc2UgZ2l2ZSBtb3JlIGRldGFpbHM/DQoN
Ci1Ib25ndGFvLg0K
^ permalink raw reply
* RE: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2012-08-09 3:48 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <50228D8B.3040204@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwOSwgMjAxMiAxMjowMiBBTQ0KPiBUbzogSmlh
IEhvbmd0YW8tQjM4OTUxDQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmc7DQo+IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpIFlhbmctUjU4
NDcyDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjUgMy8zXSBwb3dlcnBjL2ZzbC1wY2k6IFVuaWZ5
IHBjaS9wY2llDQo+IGluaXRpYWxpemF0aW9uIGNvZGUNCj4gDQo+IE9uIDA4LzA4LzIwMTIgMDQ6
MzkgQU0sIEppYSBIb25ndGFvLUIzODk1MSB3cm90ZToNCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4+IFNl
bnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNywgMjAxMiAxMToyOSBQTQ0KPiA+PiBUbzogSmlhIEhvbmd0
YW8tQjM4OTUxDQo+ID4+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmc7DQo+ID4+IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpIFlhbmctUjU4
NDcyDQo+ID4+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjUgMy8zXSBwb3dlcnBjL2ZzbC1wY2k6IFVu
aWZ5IHBjaS9wY2llDQo+ID4+IGluaXRpYWxpemF0aW9uIGNvZGUNCj4gPj4NCj4gPj4gT24gMDgv
MDcvMjAxMiAwMzowOSBBTSwgSmlhIEhvbmd0YW8tQjM4OTUxIHdyb3RlOg0KPiA+Pj4gSSBhbSBy
ZWFsbHkgbm90IHN1cmUgdGhhdCBhbGwgYm9hcmRzIG5lZWQgcHJpbWFyeSBidXMuIENvdWxkIHlv
dQ0KPiA+Pj4gZ2l2ZSBtZSB0aGUgbGluayBvZiBkaXNjdXNzaW9uIGFib3V0IHByaW1hcnkgdGhh
dCB5b3UgbWVudGlvbmVkPw0KPiA+Pg0KPiA+PiBodHRwczovL2xpc3RzLm96bGFicy5vcmcvcGlw
ZXJtYWlsL2xpbnV4cHBjLWRldi8yMDEyLUp1bmUvMDk4NTg2Lmh0bWwNCj4gPj4NCj4gPj4gLVNj
b3R0DQo+ID4NCj4gPg0KPiA+IEl0IHNlZW1zIGluIHFlbXUgaXNhX2lvX2Jhc2UgbXVzdCBiZSBu
b24temVyby4NCj4gDQo+IEluIGFsbCBjYXNlcy4gIEl0IGp1c3Qgc2hvd3MgdXAgd29yc2UgdW5k
ZXIgUUVNVSBiZWNhdXNlIG9mIGEgZGlmZmVyZW50DQo+IGlzc3VlLg0KPiANCj4gPiBJZiB0aGVy
ZSBpcyBubyBpc2EgYnJpZGdlIHNob3VsZCBpc2FfaW9fYmFzZSBiZSBub24temVybyBmb3Igb3Ro
ZXINCj4gYm9hcmRzPw0KPiANCj4gWWVzLCB1bnRpbCB0aGUgYnVncyBhcmUgZml4ZWQuDQo+IA0K
PiA+IElmIG5vdCBtYXliZSB3ZSBzaG91bGQgZml4IHFlbXUgYnVnLg0KPiANCj4gSWYgeW91IHdh
bnQgdG8gdHJ5IHRvIG1ha2UgUUVNVSBhY2NlcHQgSS9PIEJBUnMgd2l0aCBhZGRyZXNzIHplcm8s
IGdvDQo+IGFoZWFkLCBidXQgeW91IGRvbid0IGdldCB0byBhc3N1bWUgdGhhdCBzb21lb25lIGVs
c2Ugd2lsbCBkbyBpdCwgd2Ugc3RpbGwNCj4gbmVlZCB0byBiZSBjb21wYXRpYmxlIHdpdGggb2xk
ZXIgUUVNVXMgKHRoaXMgYnVnIGlzIG5vdCBzbyBzZXZlcmUgdGhhdA0KPiBjb21wYXRpYmlsaXR5
IGlzIHVucmVhc29uYWJsZSksIGFuZCBpdCBzdGlsbCBkb2Vzbid0IGFkZHJlc3MgdGhlIGZhY3QN
Cj4gdGhhdCB0aGluZ3MgYXJlIG5vdCBmdW5jdGlvbmluZyBhcyBkZXNpZ25lZC4gIElJUkMgdGhl
cmUgYXJlIHNvbWUgcmVhbA0KPiBoYXJkd2FyZSBQQ0kgY2FyZHMgdGhhdCBkb24ndCBsaWtlIGdl
dHRpbmcgYW4gYWRkcmVzcyBvZiB6ZXJvIGVpdGhlci4NCj4gDQo+ID4gT3IgInF1aWNrIGZpeCIg
aW4gdGhlIGxpbmsgaXMgYSB3b3JrYXJvdW5kLg0KPiANCj4gSSB0aGluayB0aGF0ICJxdWljayBm
aXgiIG1heSBoYXZlIHByb2JsZW1zIGlmIHRoZXJlIGlzIGEgcHJpbWFyeSBidXMgYnV0DQo+IGl0
J3Mgbm90IHRoZSBmaXJzdCBvbmUgZGV0ZWN0ZWQuICBJbiBhbnkgY2FzZSwgYW55IGZpeCBvciB3
b3JrYXJvdW5kIGhhcw0KPiB0byBoYXBwZW4gYmVmb3JlIHlvdSBtYWtlIGNoYW5nZXMgdGhhdCBy
ZWx5IG9uIGl0Lg0KPiANCj4gLVNjb3R0DQoNCklmIHRoZXJlIGlzIG5vIHByaW1hcnkgYXNzaWdu
ZWQgYW5kIGFjY2lkZW50bHkgdGhlIHByaW1hcnkgaXMgbm90IHRoZQ0KZmlyc3Qgb25lIHRoaXMg
InF1aWNrIGZpeCIgbWF5IGhhdmUgcHJvYmxlbS4gQnV0IHRoaXMgLWFjY2lkZW50LSBvbmx5IGhh
cHBlbmVkDQppbiBnZV9pbXAzYSBib2FyZCBpZiBJIGRpZG4ndCBtaXNzIG90aGVyIGJvYXJkcy4g
DQoNClNvIGlmIHRoZXJlIGlzIG5vIHByaW1hcnkgYXNzaWduZWQgYnV0IHRoZSBwcmltYXJ5IGlz
IHRoZSBmaXJzdCBidXMgZGV0ZWN0ZWQNCnRoaXMgInF1aWNrIGZpeCIgaXMgcmlnaHQuIFRoYXQg
bWVhbnMgdGhlICJxdWljayBmaXgiIGlzIHRoZSBlcXVpdmFsZW50DQpzdWJzdGl0dXRpb24gZm9y
ICJhcmJpdHJhcmlseSBkZXNpZ25hdGUgb25lIGFzIHByaW1hcnkiLg0KDQpNYXliZSB3ZSBjYW4g
dXNlIHRoZSAicXVpY2sgZml4IiBhbmQgZml4IGdlX2ltcDNhIGFzIGFuIGV4Y2VwdGlvbmFsIGNh
c2UuDQoNCi1Ib25ndGFvLg0KDQoNCg==
^ permalink raw reply
* RE: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2012-08-09 3:48 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <50228CA5.801@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDgsIDIwMTIgMTE6NTggUE0NCj4gVG86IEpp
YSBIb25ndGFvLUIzODk1MQ0KPiBDYzogV29vZCBTY290dC1CMDc0MjE7IExpIFlhbmctUjU4NDcy
OyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gR2FsYSBLdW1hci1CMTE3ODANCj4g
U3ViamVjdDogUmU6IFtQQVRDSCBWNSAzLzNdIHBvd2VycGMvZnNsLXBjaTogVW5pZnkgcGNpL3Bj
aWUNCj4gaW5pdGlhbGl6YXRpb24gY29kZQ0KPiANCj4gT24gMDgvMDgvMjAxMiAwNDowMyBBTSwg
SmlhIEhvbmd0YW8tQjM4OTUxIHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPj4gU2VudDogVHVl
c2RheSwgQXVndXN0IDA3LCAyMDEyIDExOjI1IFBNDQo+ID4+IFRvOiBMaSBZYW5nLVI1ODQ3Mg0K
PiA+PiBDYzogV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3Jn
OyBMaSBZYW5nLVI1ODQ3MjsNCj4gPj4gSmlhDQo+ID4+IEhvbmd0YW8tQjM4OTUxDQo+ID4+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggVjUgMy8zXSBwb3dlcnBjL2ZzbC1wY2k6IFVuaWZ5IHBjaS9wY2ll
DQo+ID4+IGluaXRpYWxpemF0aW9uIGNvZGUNCj4gPj4NCj4gPj4gT24gMDgvMDYvMjAxMiAxMToy
MCBQTSwgTGkgWWFuZyB3cm90ZToNCj4gPj4+IE9uIE1vbiwgQXVnIDYsIDIwMTIgYXQgMTE6MDkg
UE0sIFNjb3R0IFdvb2QNCj4gPj4+IDxzY290dHdvb2RAZnJlZXNjYWxlLmNvbT4NCj4gPj4gd3Jv
dGU6DQo+ID4+Pj4gT24gMDgvMDUvMjAxMiAxMDowNyBQTSwgSmlhIEhvbmd0YW8tQjM4OTUxIHdy
b3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gPj4+Pj4+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4+Pj4+PiBTZW50OiBTYXR1
cmRheSwgQXVndXN0IDA0LCAyMDEyIDEyOjI4IEFNDQo+ID4+Pj4+PiBUbzogSmlhIEhvbmd0YW8t
QjM4OTUxDQo+ID4+Pj4+PiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGdhbGFr
QGtlcm5lbC5jcmFzaGluZy5vcmc7IExpDQo+ID4+Pj4+PiBZYW5nLSBSNTg0NzI7IFdvb2QgU2Nv
dHQtQjA3NDIxDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW1BBVENIIFY1IDMvM10gcG93ZXJwYy9m
c2wtcGNpOiBVbmlmeSBwY2kvcGNpZQ0KPiA+Pj4+Pj4gaW5pdGlhbGl6YXRpb24gY29kZQ0KPiA+
Pj4+Pj4NCj4gPj4+Pj4+IEFzIEkgZXhwbGFpbmVkIGJlZm9yZSwgdGhpcyBoYXMgdG8gYmUgZG9u
ZSBnbG9iYWxseSwgbm90IGZyb20gdGhlDQo+ID4+Pj4+PiBwcm9iZSBmdW5jdGlvbiwgc28gd2Ug
Y2FuIGFzc2lnbiBhIGRlZmF1bHQgcHJpbWFyeSBidXMgaWYgdGhlcmUNCj4gPj4gaXNuJ3QgYW55
IElTQS4NCj4gPj4+Pj4+ICBUaGVyZSBhcmUgYnVncyBpbiB0aGUgTGludXggUFBDIFBDSSBjb2Rl
IHJlbGF0aW5nIHRvIG5vdCBoYXZpbmcNCj4gPj4+Pj4+IGFueSBwcmltYXJ5IGJ1cy4NCj4gPj4+
Pj4+DQo+ID4+Pj4+PiAtU2NvdHQNCj4gPj4+Pj4NCj4gPj4+Pj4gSW4gbXkgd2F5IG9mIHNlYXJj
aGluZyBJU0EgeW91IGNhbiBhbHNvIGFzc2lnbiBhIGRlZmF1bHQgcHJpbWFyeQ0KPiA+Pj4+PiBi
dXMgaW4gYm9hcmQgc3BlY2lmaWMgZmlsZXMuDQo+ID4+Pj4NCj4gPj4+PiBUaGF0IHdhcyBtZWFu
dCBmb3Igd2hlbiB0aGUgYm9hcmQgZmlsZSBoYWQgYW4gYWx0ZXJuYXRlIHdheSBvZg0KPiA+Pj4+
IHNlYXJjaGluZyBmb3IgdGhlIHByaW1hcnkgYnVzIChlLmcuIGxvb2sgZm9yIGk4MjU5KSwgbm90
IGFzIGENCj4gPj4+PiByZXBsYWNlbWVudCBmb3IgdGhlIG1lY2hhbmlzbSB0aGF0IGd1YXJhbnRl
ZXMgdGhlcmUncyBhIHByaW1hcnkgYnVzLg0KPiA+Pj4+DQo+ID4+Pj4gWW91IGFyZSBjYXVzaW5n
IGEgcmVncmVzc2lvbiBpbiB0aGUgcWVtdV9lNTAwLmMgcGxhdGZvcm0uDQo+ID4+Pg0KPiA+Pj4g
Q2FuIHdlIGZpeCB0aGUgcWVtdSBkZXZpY2UgdHJlZSB0byBhZGRyZXNzIHRoZSBwcm9ibGVtIGlm
IHdlIGRvIG1ha2UNCj4gPj4+IGl0IGEgcnVsZSB0byB1c2UgdGhlIElTQSBub2RlIHRvIGluZGlj
YXRlIHRoZSBwcmltYXJ5IGJ1cz8NCj4gPj4NCj4gPj4gTm8uICBUaGVyZSBpcyBubyBJU0EsIGFu
ZCB3ZSdyZSBub3QgZ29pbmcgdG8gbGllIGFuZCBzYXkgdGhlcmUgaXMuDQo+ID4NCj4gPiBCdXQg
d2UgY2FuIGFzc2lnbiBhIGRlZmF1bHQgcHJpbWFyeSBmb3IgcWVtdS4NCj4gDQo+IE5vdCBpbiB0
aGUgZGV2aWNlIHRyZWUuICBXaGF0IG90aGVyIG1lY2hhbmlzbSBkbyB5b3UgcHJvcG9zZT8gIEFu
ZCB3aHkgZG8NCj4geW91IHdhbnQgdG8gZml4IGl0IG9ubHkgZm9yIFFFTVUgYW5kIG5vdCBvdGhl
ciBib2FyZHMsIHdoZXJlIHRoaW5ncw0KPiBoYXBwZW4gdG8gd29yayBidXQgbm90IGFzIGRlc2ln
bmVkPw0KPiANCj4gS3VtYXIsIGNhbiB5b3Ugc3BlYWsgdXAgaGVyZSBhcyBtYWludGFpbmVyIHNv
IHdlIGNhbiBzdG9wIGdvaW5nIGJhY2sgYW5kDQo+IGZvcnRoIGVuZGxlc3NseT8NCj4gDQo+ID4+
IEkgcmVhbGx5IGRvbid0IHVuZGVyc3RhbmQgd2hhdCB0aGUgcHJvYmxlbSBpcyB3aXRoIGxlYXZp
bmcgdGhlDQo+ID4+IHByaW1hcnkgZGV0ZWN0aW9uIGNvZGUgYXMgZ2xvYmFsLiAgRWl0aGVyIGZp
eCB0aGUgYnVncyBzbyB3ZSBkb24ndA0KPiA+PiBuZWVkIGEgcHJpbWFyeSwgb3IgYWNjZXB0IHNv
bWUgImltcHVyaXR5IiBpbiB0aGUgd29ya2Fyb3VuZC4NCj4gPj4NCj4gPj4gLVNjb3R0DQo+ID4N
Cj4gPiBHbG9iYWwgZGV0ZWN0aW9uIGZvciBwcmltYXJ5IGlzIG9rIGJ1dCB3ZSB0aGluayBvdXIg
d2F5IGlzIGRlZXBlcg0KPiB1bmlmaWVkLg0KPiANCj4gU28gbXkgd2F5IHdvcmtzIGFuZCAiaXMg
b2siLCBhbmQgeW91ciB3YXkgZG9lc24ndCB3b3JrIGJ1dCBpcw0KPiB0aGVvcmV0aWNhbGx5IGNs
ZWFuZXIuDQoNClNvcnJ5LCBJIG1lYW50IGdsb2JhbCBkZXRlY3Rpb24gaXMgb2sgYnV0IEkgZGlk
bid0IG1lYW4gdGhhdCB5b3VyIGxvZ2ljDQppcyBvay4gVGhlIGNvbmNlcm4gaXMgaW4gc29tZSBj
YXNlcyB0aGVyZSBpcyBubyBpc2Egbm9kZSBpbiBkZXZpY2UgdHJlZQ0KYW5kIHRoZSBwcmltYXJ5
IGlzIG5vdCB0aGUgZmlyc3QgYnVzLiBZb3VyIGxvZ2ljIGFzc2lnbmVkIGEgd3JvbmcgcHJpbWFy
eQ0KdGhlcmUuIElzIHRoYXQgYSBwcm9ibGVtPyBUYWtlIGdlX2ltcDNhIGFzIGFuIGV4YW1wbGUu
DQoNClNvIG1heWJlIHdlIHNob3VsZCBmaXggdGhpcyBleGNlcHRpb25hbCBib2FyZC4NCg0KDQo+
IA0KPiA+IElzIHRoZXJlIGFueSBwcm9ibGVtIHRvIGZpeCB0aGUgYnVncz8NCj4gDQo+IElmIHlv
dSB3YW50IHRvIGZpeCB0aGVtLCBnbyBhaGVhZC4gIFlvdSBkb24ndCBnZXQgdG8gcmVseSBvbiB0
aGUgYnVncw0KPiBiZWlnbiBmaXhlZCB1bnRpbCBhZnRlciB0aGV5J3JlIGFjdHVhbGx5IGZpeGVk
Lg0KPiANCj4gPiBJIHJlYWxseSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBoYXZlIHRvIG5lZWQg
YSBwcmltYXJ5IGJ1cy4NCj4gDQo+IERpZCB5b3UgcmVhZCBCZW4ncyBlLW1haWwgdGhhdCBJIHBv
c3RlZCBhIGxpbmsgdG8/DQo+IA0KPiAtU2NvdHQNCg0K
^ permalink raw reply
* RE: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Jia Hongtao-B38951 @ 2012-08-09 2:52 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <1C95474C-B59D-4635-8FA9-B76165E177CD@kernel.crashing.org>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b38951=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Kumar Gala
> Sent: Wednesday, August 08, 2012 8:47 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
> Subject: Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM
> support
>=20
> >>>>>>
> >>>>>> On Jul 24, 2012, at 5:20 AM, Jia Hongtao wrote:
> >>>>>>
> >>>>>>> Power supply for PCI inbound/outbound window registers is off
> >>>>>>> when
> >>>>>> system
> >>>>>>> go to deep-sleep state. We save the values of registers before
> >>>>>>> suspend and restore to registers after resume.
> >>>>>>>
> >>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> >>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> >>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> >>>>>>> ---
> >>>>>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
> >>>>>>> arch/powerpc/sysdev/fsl_pci.c | 121
> >>>>>> +++++++++++++++++++++++++++++++++
> >>>>>>> 2 files changed, 122 insertions(+), 1 deletions(-)
> >>>>>>
> >>>>>> Remind me why we need to save/restore PCI ATMUs, why not just
> >>>>>> re-parse the device tree to restore?
> >>>>>>
> >>>>>> - k
> >>>>>
> >>>>> Save/restore is the more efficient way. Latency of sleep/wakeup is
> >>>>> one of most important features in power management.
> >>>>>
> >>>>> -Hongtao.
> >>>>
> >>>> I don't think the time it takes to run through setup_pci_atmu() is
> >>>> that long compared to fsl_pci_resume().
> >>>>
> >>>> Also, don't you need to setup PCICCSRBAR and do setup_pci_cmd() on
> >> resume?
> >>>>
> >>>> - k
> >>>
> >>> Hi Kumar,
> >>> I did some tests on P1022DS and found out that PCI_CMD and PCICSRBAR
> >>> is not lost when system in deep sleep. We don't need to save it.
> >>
> >> How does the PCI code know you're entering deep sleep and not
> hibernation?
> >>
> >> -Scott
> >
> > When system come back from hibernation PCI will be initialized again.
> > So no need to save PCI_CMD and PEXCSRBAR.
> >
> > -Hongtao.
> >
>=20
> What do you mean PCI will be initialized again? What code path are you
> talking about that would set PCI_CMD & PEXCSRBAR?
>=20
> - k
In hibernation mode:
When system come back from hibernation kernel will start up again.
Before loading hibernation image PCI initialization has already done.
Some other hardware also re-init again.
-Hongtao.
^ 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