* RE: [PATCH 5/6 v5] kvm: booke: clear host tlb reference flag on guest tlb invalidation
From: Bhushan Bharat-R65777 @ 2013-09-20 18:04 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: kvm@vger.kernel.org, agraf@suse.de, kvm-ppc@vger.kernel.org,
paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1379693889.16231.11.camel@aoeu.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjAsIDIwMTMgOTo0OCBQTQ0KPiBUbzogQmh1
c2hhbiBCaGFyYXQtUjY1Nzc3DQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgYmVuaEBrZXJuZWwu
Y3Jhc2hpbmcub3JnOyBhZ3JhZkBzdXNlLmRlOw0KPiBwYXVsdXNAc2FtYmEub3JnOyBrdm1Admdl
ci5rZXJuZWwub3JnOyBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtDQo+IGRldkBs
aXN0cy5vemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggNS82IHY1XSBrdm06IGJvb2tl
OiBjbGVhciBob3N0IHRsYiByZWZlcmVuY2UgZmxhZyBvbiBndWVzdA0KPiB0bGIgaW52YWxpZGF0
aW9uDQo+IA0KPiBPbiBUaHUsIDIwMTMtMDktMTkgYXQgMjM6MTkgLTA1MDAsIEJodXNoYW4gQmhh
cmF0LVI2NTc3NyB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiBTZW50OiBGcmlkYXksIFNlcHRl
bWJlciAyMCwgMjAxMyAyOjM4IEFNDQo+ID4gPiBUbzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+
ID4gPiBDYzogYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBhZ3JhZkBzdXNlLmRlOyBwYXVsdXNA
c2FtYmEub3JnOw0KPiA+ID4ga3ZtQHZnZXIua2VybmVsLm9yZzsga3ZtLXBwY0B2Z2VyLmtlcm5l
bC5vcmc7DQo+ID4gPiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgQmh1c2hhbiBCaGFy
YXQtUjY1Nzc3DQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDUvNiB2NV0ga3ZtOiBib29rZTog
Y2xlYXIgaG9zdCB0bGIgcmVmZXJlbmNlDQo+ID4gPiBmbGFnIG9uIGd1ZXN0IHRsYiBpbnZhbGlk
YXRpb24NCj4gPiA+DQo+ID4gPiBUaGlzIGJyZWFrcyB3aGVuIHlvdSBoYXZlIGJvdGggRTUwMF9U
TEJfQklUTUFQIGFuZCBFNTAwX1RMQl9UTEIwIHNldC4NCj4gPg0KPiA+IEkgZG8gbm90IHNlZSBh
bnkgY2FzZSB3aGVyZSB3ZSBzZXQgYm90aCBFNTAwX1RMQl9CSVRNQVAgYW5kDQo+ID4gRTUwMF9U
TEJfVExCMC4NCj4gDQo+IFRoaXMgd291bGQgaGFwcGVuIGlmIHlvdSBoYXZlIGEgZ3Vlc3QgVExC
MSBlbnRyeSB0aGF0IGlzIGJhY2tlZCBieSBzb21lIDRLIHBhZ2VzDQo+IGFuZCBzb21lIGxhcmdl
ciBwYWdlcyAoZS5nLiBpZiB0aGUgZ3Vlc3QgbWFwcyBDQ1NSIHdpdGggb25lIGJpZw0KPiBUTEIx
IGFuZCB0aGVyZSBhcmUgdmFyeWluZyBJL08gcGFzc3Rocm91Z2ggcmVnaW9ucyBtYXBwZWQpLiAg
SXQncyBub3QgY29tbW9uLA0KPiBidXQgaXQncyBwb3NzaWJsZS4NCg0KQWdyZWUNCg0KPiANCj4g
PiAgQWxzbyB3ZSBoYXZlIG5vdCBvcHRpbWl6ZWQgdGhhdCB5ZXQgKGtlZXBpbmcgdHJhY2sgb2Yg
bXVsdGlwbGUgc2hhZG93DQo+ID4gVExCMCBlbnRyaWVzIGZvciBvbmUgZ3Vlc3QgVExCMSBlbnRy
eSkNCj4gDQo+IFRoaXMgaXMgYWJvdXQgY29ycmVjdG5lc3MsIG5vdCBvcHRpbWl6YXRpb24uDQo+
IA0KPiA+IFdlIHVzZXMgdGhlc2UgYml0IGZsYWdzIG9ubHkgZm9yIFRMQjEgYW5kIGlmIHNpemUg
b2Ygc3RsYmUgaXMgNEsgdGhlbg0KPiA+IHdlIHNldCBFNTAwX1RMQl9UTEIwICBvdGhlcndpc2Ug
d2Ugc2V0IEU1MDBfVExCX0JJVE1BUC4gQWx0aG91Z2ggSQ0KPiA+IHRoaW5rIHRoYXQgRTUwMF9U
TEJfQklUTUFQIHNob3VsZCBiZSBzZXQgb25seSBpZiBzdGxiZSBzaXplIGlzIGxlc3MNCj4gPiB0
aGFuIGd0bGJlIHNpemUuDQo+IA0KPiBXaHk/ICBFdmVuIGlmIHRoZXJlJ3Mgb25seSBvbmUgYml0
IHNldCBpbiB0aGUgbWFwLCB3ZSBuZWVkIGl0IHRvIGtlZXAgdHJhY2sgb2YNCj4gd2hpY2ggZW50
cnkgd2FzIHVzZWQuDQoNCklmIHRoZXJlIGlzIG9uZSBlbnRyeSB0aGVuIHdpbGwgbm90IHRoaXMg
YmUgc2ltcGxlL2Zhc3RlciB0byBub3QgbG9va3VwIGJpdG1hcCBhbmQgZ3Vlc3QtPmhvc3QgYXJy
YXk/DQpBIGZsYWcgaW5kaWNhdGUgaXQgaXMgMToxIG1hcCBhbmQgdGhpcyBpcyBwaHlzaWNhbCBh
ZGRyZXNzLg0KDQotQmhhcmF0DQoNCj4gDQo+IC1TY290dA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 5/6 v5] kvm: booke: clear host tlb reference flag on guest tlb invalidation
From: Scott Wood @ 2013-09-20 18:08 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, kvm@vger.kernel.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0717AEA1@039-SN2MPN1-011.039d.mgd.msft.net>
On Fri, 2013-09-20 at 13:04 -0500, Bhushan Bharat-R65777 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, September 20, 2013 9:48 PM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; benh@kernel.crashing.org; agraf@suse.de;
> > paulus@samba.org; kvm@vger.kernel.org; kvm-ppc@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH 5/6 v5] kvm: booke: clear host tlb reference flag on guest
> > tlb invalidation
> >
> > On Thu, 2013-09-19 at 23:19 -0500, Bhushan Bharat-R65777 wrote:
> > > We uses these bit flags only for TLB1 and if size of stlbe is 4K then
> > > we set E500_TLB_TLB0 otherwise we set E500_TLB_BITMAP. Although I
> > > think that E500_TLB_BITMAP should be set only if stlbe size is less
> > > than gtlbe size.
> >
> > Why? Even if there's only one bit set in the map, we need it to keep track of
> > which entry was used.
>
> If there is one entry then will not this be simple/faster to not lookup bitmap and guest->host array?
> A flag indicate it is 1:1 map and this is physical address.
The difference would be negligible, and you'd have added overhead (both
runtime and complexity) of making this a special case.
-Scott
^ permalink raw reply
* RE: [PATCH 5/6 v5] kvm: booke: clear host tlb reference flag on guest tlb invalidation
From: Bhushan Bharat-R65777 @ 2013-09-20 18:11 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: kvm@vger.kernel.org, agraf@suse.de, kvm-ppc@vger.kernel.org,
paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1379700490.16231.19.camel@aoeu.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjAsIDIwMTMgMTE6MzggUE0NCj4gVG86IEJo
dXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogV29vZCBTY290dC1CMDc0MjE7IGJlbmhAa2VybmVs
LmNyYXNoaW5nLm9yZzsgYWdyYWZAc3VzZS5kZTsNCj4gcGF1bHVzQHNhbWJhLm9yZzsga3ZtQHZn
ZXIua2VybmVsLm9yZzsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZA
bGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDUvNiB2NV0ga3ZtOiBib29r
ZTogY2xlYXIgaG9zdCB0bGIgcmVmZXJlbmNlIGZsYWcgb24gZ3Vlc3QNCj4gdGxiIGludmFsaWRh
dGlvbg0KPiANCj4gT24gRnJpLCAyMDEzLTA5LTIwIGF0IDEzOjA0IC0wNTAwLCBCaHVzaGFuIEJo
YXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogRnJpZGF5LCBTZXB0
ZW1iZXIgMjAsIDIwMTMgOTo0OCBQTQ0KPiA+ID4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0K
PiA+ID4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IGFn
cmFmQHN1c2UuZGU7DQo+ID4gPiBwYXVsdXNAc2FtYmEub3JnOyBrdm1Admdlci5rZXJuZWwub3Jn
OyBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+IGxpbnV4cHBjLSBkZXZAbGlzdHMub3ps
YWJzLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCA1LzYgdjVdIGt2bTogYm9va2U6IGNs
ZWFyIGhvc3QgdGxiIHJlZmVyZW5jZQ0KPiA+ID4gZmxhZyBvbiBndWVzdCB0bGIgaW52YWxpZGF0
aW9uDQo+ID4gPg0KPiA+ID4gT24gVGh1LCAyMDEzLTA5LTE5IGF0IDIzOjE5IC0wNTAwLCBCaHVz
aGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4gPiA+IFdlIHVzZXMgdGhlc2UgYml0IGZsYWdz
IG9ubHkgZm9yIFRMQjEgYW5kIGlmIHNpemUgb2Ygc3RsYmUgaXMgNEsNCj4gPiA+ID4gdGhlbiB3
ZSBzZXQgRTUwMF9UTEJfVExCMCAgb3RoZXJ3aXNlIHdlIHNldCBFNTAwX1RMQl9CSVRNQVAuDQo+
ID4gPiA+IEFsdGhvdWdoIEkgdGhpbmsgdGhhdCBFNTAwX1RMQl9CSVRNQVAgc2hvdWxkIGJlIHNl
dCBvbmx5IGlmIHN0bGJlDQo+ID4gPiA+IHNpemUgaXMgbGVzcyB0aGFuIGd0bGJlIHNpemUuDQo+
ID4gPg0KPiA+ID4gV2h5PyAgRXZlbiBpZiB0aGVyZSdzIG9ubHkgb25lIGJpdCBzZXQgaW4gdGhl
IG1hcCwgd2UgbmVlZCBpdCB0bw0KPiA+ID4ga2VlcCB0cmFjayBvZiB3aGljaCBlbnRyeSB3YXMg
dXNlZC4NCj4gPg0KPiA+IElmIHRoZXJlIGlzIG9uZSBlbnRyeSB0aGVuIHdpbGwgbm90IHRoaXMg
YmUgc2ltcGxlL2Zhc3RlciB0byBub3QgbG9va3VwIGJpdG1hcA0KPiBhbmQgZ3Vlc3QtPmhvc3Qg
YXJyYXk/DQo+ID4gQSBmbGFnIGluZGljYXRlIGl0IGlzIDE6MSBtYXAgYW5kIHRoaXMgaXMgcGh5
c2ljYWwgYWRkcmVzcy4NCj4gDQo+IFRoZSBkaWZmZXJlbmNlIHdvdWxkIGJlIG5lZ2xpZ2libGUs
IGFuZCB5b3UnZCBoYXZlIGFkZGVkIG92ZXJoZWFkIChib3RoIHJ1bnRpbWUNCj4gYW5kIGNvbXBs
ZXhpdHkpIG9mIG1ha2luZyB0aGlzIGEgc3BlY2lhbCBjYXNlLg0KDQpNYXkgYmUgeW91IGFyZSBy
aWdodCAsIEkgd2lsbCBzZWUgaWYgSSBjYW4gZ2l2ZSBhIHRyeSA6KQ0KQlRXIEkgaGF2ZSBhbHJl
YWR5IHNlbnQgdjYgb2YgdGhpcyBwYXRjaC4NCg0KLUJoYXJhdA0KDQo+IA0KPiAtU2NvdHQNCj4g
DQoNCg==
^ permalink raw reply
* [PATCH 1/2] powerpc: make kernel module helper endian-safe.
From: Eugene Surovegin @ 2013-09-20 18:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anton Blanchard
Signed-off-by: Eugene Surovegin <surovegin@google.com>
---
arch/powerpc/kernel/module_64.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 6ee59a0..a102f44 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -62,6 +62,16 @@ struct ppc64_stub_entry
r2) into the stub. */
static struct ppc64_stub_entry ppc64_stub =
{ .jump = {
+#ifdef __LITTLE_ENDIAN__
+ 0x00, 0x00, 0x82, 0x3d, /* addis r12,r2, <high> */
+ 0x00, 0x00, 0x8c, 0x39, /* addi r12,r12, <low> */
+ /* Save current r2 value in magic place on the stack. */
+ 0x28, 0x00, 0x41, 0xf8, /* std r2,40(r1) */
+ 0x20, 0x00, 0x6c, 0xe9, /* ld r11,32(r12) */
+ 0x28, 0x00, 0x4c, 0xe8, /* ld r2,40(r12) */
+ 0xa6, 0x03, 0x69, 0x7d, /* mtctr r11 */
+ 0x20, 0x04, 0x80, 0x4e /* bctr */
+#else
0x3d, 0x82, 0x00, 0x00, /* addis r12,r2, <high> */
0x39, 0x8c, 0x00, 0x00, /* addi r12,r12, <low> */
/* Save current r2 value in magic place on the stack. */
@@ -70,6 +80,7 @@ static struct ppc64_stub_entry ppc64_stub =
0xe8, 0x4c, 0x00, 0x28, /* ld r2,40(r12) */
0x7d, 0x69, 0x03, 0xa6, /* mtctr r11 */
0x4e, 0x80, 0x04, 0x20 /* bctr */
+#endif
} };
/* Count how many different 24-bit relocations (different symbol,
@@ -269,8 +280,13 @@ static inline int create_stub(Elf64_Shdr *sechdrs,
*entry = ppc64_stub;
+#ifdef __LITTLE_ENDIAN__
+ loc1 = (Elf64_Half *)&entry->jump[0];
+ loc2 = (Elf64_Half *)&entry->jump[4];
+#else
loc1 = (Elf64_Half *)&entry->jump[2];
loc2 = (Elf64_Half *)&entry->jump[6];
+#endif
/* Stub uses address relative to r2. */
reladdr = (unsigned long)entry - my_r2(sechdrs, me);
--
1.8.1.5
^ permalink raw reply related
* [PATCH 2/2] powerpc: make ftrace endian-safe.
From: Eugene Surovegin @ 2013-09-20 18:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anton Blanchard
In-Reply-To: <1379702541-28372-1-git-send-email-ebs@ebshome.net>
Signed-off-by: Eugene Surovegin <surovegin@google.com>
---
arch/powerpc/kernel/ftrace.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1fb7856..9b27b29 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -174,7 +174,11 @@ __ftrace_make_nop(struct module *mod,
pr_devel(" %08x %08x\n", jmp[0], jmp[1]);
+#ifdef __LITTLE_ENDIAN__
+ ptr = ((unsigned long)jmp[1] << 32) + jmp[0];
+#else
ptr = ((unsigned long)jmp[0] << 32) + jmp[1];
+#endif
/* This should match what was called */
if (ptr != ppc_function_entry((void *)addr)) {
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH 5/6 v6] kvm: booke: clear host tlb reference flag on guest tlb invalidation
From: Scott Wood @ 2013-09-20 18:50 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: kvm, agraf, kvm-ppc, Bharat Bhushan, paulus, linuxppc-dev
In-Reply-To: <1379651122-26078-1-git-send-email-Bharat.Bhushan@freescale.com>
On Fri, 2013-09-20 at 09:55 +0530, Bharat Bhushan wrote:
> On booke, "struct tlbe_ref" contains host tlb mapping information
> (pfn: for guest-pfn to pfn, flags: attribute associated with this mapping)
> for a guest tlb entry. So when a guest creates a TLB entry then
> "struct tlbe_ref" is set to point to valid "pfn" and set attributes in
> "flags" field of the above said structure. When a guest TLB entry is
> invalidated then flags field of corresponding "struct tlbe_ref" is
> updated to point that this is no more valid, also we selectively clear
> some other attribute bits, example: if E500_TLB_BITMAP was set then we clear
> E500_TLB_BITMAP, if E500_TLB_TLB0 is set then we clear this.
>
> Ideally we should clear complete "flags" as this entry is invalid and does not
> have anything to re-used. The other part of the problem is that when we use
> the same entry again then also we do not clear (started doing or-ing etc).
>
> So far it was working because the selectively clearing mentioned above
> actually clears "flags" what was set during TLB mapping. But the problem
> starts coming when we add more attributes to this then we need to selectively
> clear them and which is not needed.
>
> This patch we do both
> - Clear "flags" when invalidating;
> - Clear "flags" when reusing same entry later
>
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> v5->v6
> - Fix flag clearing comment
The changes between v5 and v6 are not just about comments...
>
> arch/powerpc/kvm/e500_mmu_host.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
> index 1c6a9d7..7370e1c 100644
> --- a/arch/powerpc/kvm/e500_mmu_host.c
> +++ b/arch/powerpc/kvm/e500_mmu_host.c
> @@ -230,15 +230,15 @@ void inval_gtlbe_on_host(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel,
> ref->flags &= ~(E500_TLB_TLB0 | E500_TLB_VALID);
> }
>
> - /* Already invalidated in between */
> - if (!(ref->flags & E500_TLB_VALID))
> - return;
> -
> - /* Guest tlbe is backed by at most one host tlbe per shadow pid. */
> - kvmppc_e500_tlbil_one(vcpu_e500, gtlbe);
> + /*
> + * Check whether TLB entry is already invalidated in between
> + * Guest tlbe is backed by at most one host tlbe per shadow pid.
> + */
> + if (ref->flags & E500_TLB_VALID)
> + kvmppc_e500_tlbil_one(vcpu_e500, gtlbe);
I'd phrase this combined comment as "If it's still valid, it's a TLB0
entry, and thus backed by at most one host tlbe per shadow pid".
Otherwise looks good.
-Scott
^ permalink raw reply
* Re: [PATCH 12/51] DMA-API: net: intel/e1000: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Jeff Kirsher @ 2013-09-20 19:45 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, Peter P Waskiewicz Jr,
linux-fbdev, linux-nvme, linux-ide, Carolyn Wyborny, devel,
linux-samsung-soc, linux-scsi, e1000-devel, Don Skidmore,
Jesse Brandeburg, b43-dev, linux-media, Alex Duyck, devicetree,
Greg Rose, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
John Ronciak, linux-crypto, uclinux-dist-devel, Bruce Allan,
linuxppc-dev, Tushar Dave
In-Reply-To: <E1VMluG-0007gV-6y@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Thu, 2013-09-19 at 22:37 +0100, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/ethernet/intel/e1000/e1000_main.c | 9 ++-------
> 1 files changed, 2 insertions(+), 7 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling
From: Jeff Kirsher @ 2013-09-20 19:48 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, Peter P Waskiewicz Jr,
linux-fbdev, linux-nvme, linux-ide, Carolyn Wyborny, devel,
linux-samsung-soc, linux-scsi, e1000-devel, Don Skidmore,
Jesse Brandeburg, b43-dev, linux-media, Alex Duyck, devicetree,
Greg Rose, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
John Ronciak, linux-crypto, uclinux-dist-devel, Bruce Allan,
linuxppc-dev, Tushar Dave
In-Reply-To: <E1VMllX-0007fP-33@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]
On Thu, 2013-09-19 at 22:27 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev,
> "No usable DMA configuration,
> aborting\n");
> goto err_dma;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 18 ++++++------------
> 1 files changed, 6 insertions(+), 12 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling
From: Jeff Kirsher @ 2013-09-20 19:49 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, Peter P Waskiewicz Jr,
linux-fbdev, linux-nvme, linux-ide, Carolyn Wyborny, devel,
linux-samsung-soc, linux-scsi, e1000-devel, Don Skidmore,
Jesse Brandeburg, b43-dev, linux-media, Alex Duyck, devicetree,
Greg Rose, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
John Ronciak, linux-crypto, uclinux-dist-devel, Bruce Allan,
linuxppc-dev, Tushar Dave
In-Reply-To: <E1VMlmV-0007fU-75@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
On Thu, 2013-09-19 at 22:28 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev,
> "No usable DMA configuration,
> aborting\n");
> goto err_dma;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 18 ++++++------------
> 1 files changed, 6 insertions(+), 12 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling
From: Jeff Kirsher @ 2013-09-20 19:49 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, Peter P Waskiewicz Jr,
linux-fbdev, linux-nvme, linux-ide, Carolyn Wyborny, devel,
linux-samsung-soc, linux-scsi, e1000-devel, Don Skidmore,
Jesse Brandeburg, b43-dev, linux-media, Alex Duyck, devicetree,
Greg Rose, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
John Ronciak, linux-crypto, uclinux-dist-devel, Bruce Allan,
linuxppc-dev, Tushar Dave
In-Reply-To: <E1VMlnT-0007fa-Al@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
On Thu, 2013-09-19 at 22:29 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev, "No usable DMA "
> "configuration, aborting\n");
> goto err_dma;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/ethernet/intel/igbvf/netdev.c | 18 ++++++------------
> 1 files changed, 6 insertions(+), 12 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
From: Jeff Kirsher @ 2013-09-20 19:50 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, Peter P Waskiewicz Jr,
linux-fbdev, linux-nvme, linux-ide, Carolyn Wyborny, devel,
linux-samsung-soc, linux-scsi, e1000-devel, Don Skidmore,
Jesse Brandeburg, b43-dev, linux-media, Alex Duyck, devicetree,
Greg Rose, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
John Ronciak, linux-crypto, uclinux-dist-devel, Bruce Allan,
linuxppc-dev, Tushar Dave
In-Reply-To: <E1VMloR-0007fk-Ei@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
On Thu, 2013-09-19 at 22:30 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> pr_err("No usable DMA configuration,
> aborting\n");
> goto err_dma_mask;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +++++-----------
> 1 files changed, 5 insertions(+), 11 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling
From: Jeff Kirsher @ 2013-09-20 19:51 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, Peter P Waskiewicz Jr,
linux-fbdev, linux-nvme, linux-ide, Carolyn Wyborny, devel,
linux-samsung-soc, linux-scsi, e1000-devel, Don Skidmore,
Jesse Brandeburg, b43-dev, linux-media, Alex Duyck, devicetree,
Greg Rose, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
John Ronciak, linux-crypto, uclinux-dist-devel, Bruce Allan,
linuxppc-dev, Tushar Dave
In-Reply-To: <E1VMlpP-0007fp-IC@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
On Thu, 2013-09-19 at 22:31 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
> !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev,
> "No usable DMA configuration,
> aborting\n");
> goto err_dma;
> }
> }
> pci_using_dac = 0;
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +++++----------
> 1 files changed, 5 insertions(+), 10 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 08/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling
From: Jeff Kirsher @ 2013-09-20 19:51 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, Peter P Waskiewicz Jr,
linux-fbdev, linux-nvme, linux-ide, Carolyn Wyborny, devel,
linux-samsung-soc, linux-scsi, e1000-devel, Don Skidmore,
Jesse Brandeburg, b43-dev, linux-media, Alex Duyck, devicetree,
Greg Rose, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
John Ronciak, linux-crypto, uclinux-dist-devel, Bruce Allan,
linuxppc-dev, Tushar Dave
In-Reply-To: <E1VMlqN-0007fw-MQ@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
On Thu, 2013-09-19 at 22:32 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
> !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev, "No usable DMA "
> "configuration, aborting\n");
> goto err_dma;
> }
> }
> pci_using_dac = 0;
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15
> +++++----------
> 1 files changed, 5 insertions(+), 10 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
From: Scott Wood @ 2013-09-20 21:22 UTC (permalink / raw)
To: leroy christophe; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <5238860F.4030405@c-s.fr>
On Tue, 2013-09-17 at 18:40 +0200, leroy christophe wrote:
> Le 16/09/2013 23:02, Scott Wood a =C3=A9crit :
> > On Fri, 2013-09-13 at 07:04 +0200, leroy christophe wrote:
> >> Le 12/09/2013 20:44, Scott Wood a =C3=A9crit :
> >>> On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
> >>>> This is a reorganisation of the setup of the TLB at kernel startup=
, in order
> >>>> to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.=
3 of MPC866
> >>>> and MPC885 reference manuals.
> >>>>
> >>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >>>>
> >>>> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/=
arch/powerpc/kernel/head_8xx.S
> >>>> --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46=
:10.000000000 +0200
> >>>> +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.=
000000000 +0200
> >>>> @@ -785,27 +785,24 @@
> >>>> * these mappings is mapped by page tables.
> >>>> */
> >>>> initial_mmu:
> >>>> - tlbia /* Invalidate all TLB entries */
> >>>> -/* Always pin the first 8 MB ITLB to prevent ITLB
> >>>> - misses while mucking around with SRR0/SRR1 in asm
> >>>> -*/
> >>>> - lis r8, MI_RSV4I@h
> >>>> - ori r8, r8, 0x1c00
> >>>> -
> >>>> + lis r8, MI_RESETVAL@h
> >>>> mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */
> >>>> =20
> >>>> -#ifdef CONFIG_PIN_TLB
> >>>> - lis r10, (MD_RSV4I | MD_RESETVAL)@h
> >>>> - ori r10, r10, 0x1c00
> >>>> - mr r8, r10
> >>>> -#else
> >>>> lis r10, MD_RESETVAL@h
> >>>> -#endif
> >>>> #ifndef CONFIG_8xx_COPYBACK
> >>>> oris r10, r10, MD_WTDEF@h
> >>>> #endif
> >>>> mtspr SPRN_MD_CTR, r10 /* Set data TLB control */
> >>>> =20
> >>>> + tlbia /* Invalidate all TLB entries */
> >>> Is this change to make sure we invalidate everything even if the
> >>> bootloader set RSV4I?
> >> Most probably. It is step 2 of the process defined in MPC866 and MPC=
885
> >> Reference Manuals:
> >>
> >> =C2=A78.10.3 Loading Locked TLB Entries:
> >> The process of loading a single reserved entry in the TLB is as foll=
ows:
> > To minimize code churn we should just fix actual problems, rather tha=
n
> > shuffle things around to conform to a suggested sequence. After all,
> > we're not just trying to load a single entry.
> Ok, I'll try again.
> >
> >>>> + ori r8, r8, 0x1c00
> >>>> + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */
> >>>> +#ifdef CONFIG_PIN_TLB
> >>>> + ori r10, r10, 0x1c00
> >>>> + mtspr SPRN_MD_CTR, r10 /* Set data TLB control */
> >>>> +#endif
> >>> Still 0x1c00?
> >> Yes, I kept the same entries in order to limit modifications:
> >> * 28 =3D First 8Mbytes page
> >> * 29 =3D IMMR
> >> * 30 =3D Second 8Mbytes page
> >> * 31 =3D Third 8Mbytes page
> > If you actually want to program them in increasing order then it look=
s
> > like you're still missing a write to CTR between the last two 8M entr=
ies
> > -- thus you'll overwrite the IMMR with the last 8M entry. That was t=
he
> > same problem that v1 fixed -- did that change get lost accidentally?
> Oops, no, in fact I diffed from the version which was including it=20
> already. My mistake.
> >
> > The hardware wants to decrement; why fight it?
> I see your point.
> However it is not clear in the documentation if the decrement is done=20
> really after the update, or at xTLB interrupt. So I propose to still se=
t=20
> the CTR ourself as described in the reference Manual and not assume tha=
t=20
> the HW decrements it.
It says "every update" -- do you have any reason to believe that's
wrong? It could be tested...
-Scott
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 22:20 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, linux-doc, David Airlie, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, Joonyoung Shim,
linux-scsi, e1000-devel, Seung-Woo Kim, b43-dev, linux-media,
devicetree, Inki Dae, Kukjin Kim, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Kyungmin Park, linux-crypto,
uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920140018.GP25647@n2100.arm.linux.org.uk>
Hey,
On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote:
> Another would be if subsystem maintainers are happy that I carry them,
> I can add the acks, and then later on towards the end of the cycle,
> provide a branch subsystem maintainers could pull.
>
> Or... if you can think of something easier...
I'm happy with the latter method and it's likely that you'll end up
carrying at least some of the patches through your tree anyway.
Please feel free to add my acks to all libata related patches and
carry them through your tree.
Thanks and have fun routing.
--
tejun
^ permalink raw reply
* Re: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Timur Tabi @ 2013-09-21 0:23 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, Aggrwal Poonam-B10812, Jain Priyanka-B32167,
Kushwaha Prabhakar-B32579, linuxppc-dev@lists.ozlabs.org,
Prabhakar Kushwaha
In-Reply-To: <1379693218.16231.7.camel@aoeu.buserror.net>
Scott Wood wrote:
> The patch is not "lying". It is describing the board, not what the
> patch supports. This was something you used to constantly tell people
> to do...
The patch says:
"DIU supports video at up to 1280x1024x32bpp"
How is this not misleading?
I understand that the patch describes the board, and that's correct. It
should also indicate which major functionality is not supported. I was
expecting something like this:
- Video
- DIU hardware is capable of video up to 1280x1024x32bpp
- DIU support is currently not implemented
> There are other things in that description that Linux doesn't do
> anything with, such as QIXIS.
Fair enough, but the QIXIS is not something that would generally be
supported by Linux, as there is no "QIXIS driver". There is a DIU
driver, however.
The patch description should state which major components are not
currently supported by software, but would be expected to be supported.
^ permalink raw reply
* Re: [PATCH V2 0/6] perf: New conditional branch filter
From: Anshuman Khandual @ 2013-09-21 6:41 UTC (permalink / raw)
To: Stephane Eranian
Cc: LKML, Arnaldo Carvalho de Melo, Linux PPC dev, ellerman,
Sukadev Bhattiprolu, michael.neuling
In-Reply-To: <CABPqkBS2AD873tHnyCHeC7uwsJdP1V6=8WGUTHG+R0z2pphHjQ@mail.gmail.com>
On 08/30/2013 05:18 PM, Stephane Eranian wrote:
> 2013/8/30 Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> >
>> > This patchset is the re-spin of the original branch stack sampling
>> > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
>> > also enables SW based branch filtering support for PPC64 platforms which have
>> > branch stack sampling support. With this new enablement, the branch filter support
>> > for PPC64 platforms have been extended to include all these combinations discussed
>> > below with a sample test application program.
>> >
>> >
> I am trying to understand which HW has support for capturing the
> branches: PPC7 or PPC8.
> Then it seems you're saying that only PPC8 has the filtering support.
> On PPC7 you use the
> SW filter. Did I get this right?
>
> I will look at the patch set.
>
Hey Stephane,
Just wondering if you got a chance to go though the patchset ?
Regards
Anshuman
^ permalink raw reply
* Re: [PATCH V2 0/6] perf: New conditional branch filter
From: Anshuman Khandual @ 2013-09-21 6:45 UTC (permalink / raw)
To: Stephane Eranian
Cc: LKML, Arnaldo Carvalho de Melo, Linux PPC dev, ellerman,
Sukadev Bhattiprolu, michael.neuling
In-Reply-To: <523D3FA2.2070209@linux.vnet.ibm.com>
On 09/21/2013 12:11 PM, Anshuman Khandual wrote:
> On 08/30/2013 05:18 PM, Stephane Eranian wrote:
>> 2013/8/30 Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>>>
>>>> This patchset is the re-spin of the original branch stack sampling
>>>> patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
>>>> also enables SW based branch filtering support for PPC64 platforms which have
>>>> branch stack sampling support. With this new enablement, the branch filter support
>>>> for PPC64 platforms have been extended to include all these combinations discussed
>>>> below with a sample test application program.
>>>>
>>>>
>> I am trying to understand which HW has support for capturing the
>> branches: PPC7 or PPC8.
>> Then it seems you're saying that only PPC8 has the filtering support.
>> On PPC7 you use the
>> SW filter. Did I get this right?
>>
>> I will look at the patch set.
>>
>
> Hey Stephane,
>
> Just wondering if you got a chance to go though the patchset ?
s/though/through/
^ permalink raw reply
* Re: [PATCH V2 0/6] perf: New conditional branch filter
From: Stephane Eranian @ 2013-09-21 6:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: Sukadev Bhattiprolu, LKML, Arnaldo Carvalho de Melo,
Linux PPC dev, Michael Neuling, Anshuman Khandual
In-Reply-To: <1378778772.25578.1.camel@concordia>
On Tue, Sep 10, 2013 at 4:06 AM, Michael Ellerman
<michael@ellerman.id.au> wrote:
>
> On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote:
> > This patchset is the re-spin of the original branch stack sampling
> > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
> > also enables SW based branch filtering support for PPC64 platforms which have
> > branch stack sampling support. With this new enablement, the branch filter support
> > for PPC64 platforms have been extended to include all these combinations discussed
> > below with a sample test application program.
>
> ...
>
> > Mixed filters
> > -------------
> > (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog
> > Error:
> > The perf.data file has no samples!
> >
> > NOTE: As expected. The HW filters all the branches which are calls and SW tries to find return
> > branches in that given set. Both the filters are mutually exclussive, so obviously no samples
> > found in the end profile.
>
> The semantics of multiple filters is not clear to me. It could be an OR,
> or an AND. You have implemented AND, does that match existing behaviour
> on x86 for example?
>
The semantic on the API is OR. AND does not make sense: CALL & RETURN?
On x86, the HW filter is an OR (default: ALL, set bit to disable a
type). I suspect
it is similar on PPC.
>
> cheers
>
>
^ permalink raw reply
* [RESEND PATCH 1/2] powerpc: net: filter: fix DIVWU instruction opcode
From: Vladimir Murzin @ 2013-09-21 7:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: matt, netdev, Vladimir Murzin, dborkman, edumazet, paulus, davem
Currently DIVWU stands for *signed* divw opcode:
7d 2a 4b 96 divwu r9,r10,r9
7d 2a 4b d6 divw r9,r10,r9
Use the *unsigned* divw opcode for DIVWU.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Acked-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/include/asm/ppc-opcode.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index d7fe9f5..c91842c 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -218,7 +218,7 @@
#define PPC_INST_MULLW 0x7c0001d6
#define PPC_INST_MULHWU 0x7c000016
#define PPC_INST_MULLI 0x1c000000
-#define PPC_INST_DIVWU 0x7c0003d6
+#define PPC_INST_DIVWU 0x7c000396
#define PPC_INST_RLWINM 0x54000000
#define PPC_INST_RLDICR 0x78000004
#define PPC_INST_SLW 0x7c000030
--
1.7.10.4
^ permalink raw reply related
* [RESEND PATCH 2/2] ppc: bpf_jit: support MOD operation
From: Vladimir Murzin @ 2013-09-21 7:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: matt, netdev, Vladimir Murzin, dborkman, edumazet, paulus, davem
In-Reply-To: <1379748334-3313-1-git-send-email-murzin.v@gmail.com>
commit b6069a9570 (filter: add MOD operation) added generic
support for modulus operation in BPF.
This patch brings JIT support for PPC64
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Acked-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/net/bpf_jit_comp.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index bf56e33..96f24dc 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -193,6 +193,28 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
PPC_MUL(r_A, r_A, r_scratch1);
}
break;
+ case BPF_S_ALU_MOD_X: /* A %= X; */
+ ctx->seen |= SEEN_XREG;
+ PPC_CMPWI(r_X, 0);
+ if (ctx->pc_ret0 != -1) {
+ PPC_BCC(COND_EQ, addrs[ctx->pc_ret0]);
+ } else {
+ PPC_BCC_SHORT(COND_NE, (ctx->idx*4)+12);
+ PPC_LI(r_ret, 0);
+ PPC_JMP(exit_addr);
+ }
+ PPC_DIVWU(r_scratch1, r_A, r_X);
+ PPC_MUL(r_scratch1, r_X, r_scratch1);
+ PPC_SUB(r_A, r_A, r_scratch1);
+ break;
+ case BPF_S_ALU_MOD_K: /* A %= K; */
+#define r_scratch2 (r_scratch1 + 1)
+ PPC_LI32(r_scratch2, K);
+ PPC_DIVWU(r_scratch1, r_A, r_scratch2);
+ PPC_MUL(r_scratch1, r_scratch2, r_scratch1);
+ PPC_SUB(r_A, r_A, r_scratch1);
+#undef r_scratch2
+ break;
case BPF_S_ALU_DIV_X: /* A /= X; */
ctx->seen |= SEEN_XREG;
PPC_CMPWI(r_X, 0);
--
1.8.1.5
^ permalink raw reply related
* unregister
From: Yu Chen @ 2013-09-21 13:10 UTC (permalink / raw)
To: linuxppc-dev
^ permalink raw reply
* Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
From: Russell King - ARM Linux @ 2013-09-21 20:00 UTC (permalink / raw)
To: Heiko Stübner
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
Vinod Koul, linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <201309201926.29084.heiko@sntech.de>
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > The DMA API requires drivers to call the appropriate dma_set_mask()
> > functions before doing any DMA mapping. Add this required call to
> > the AMBA PL08x driver.
> ^--- copy and paste error - should of course be PL330
Fixed, thanks.
^ permalink raw reply
* [PATCH] powerpc/p1010rdb:update dts to adapt to both old and new p1010rdb
From: Zhao Qiang @ 2013-09-22 2:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Zhao Qiang, Shengzhou Liu
P1010rdb-pa and p1010rdb-pb have different phy interrupts.
So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
arch/powerpc/boot/dts/p1010rdb-pa.dts | 33 ++++++++++++++++++
arch/powerpc/boot/dts/p1010rdb-pb.dts | 33 ++++++++++++++++++
arch/powerpc/boot/dts/p1010rdb.dts | 66 -----------------------------------
arch/powerpc/boot/dts/p1010rdb.dtsi | 51 ++++++++++++++++++++++++---
4 files changed, 112 insertions(+), 71 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1010rdb-pa.dts
create mode 100644 arch/powerpc/boot/dts/p1010rdb-pb.dts
delete mode 100644 arch/powerpc/boot/dts/p1010rdb.dts
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa.dts b/arch/powerpc/boot/dts/p1010rdb-pa.dts
new file mode 100644
index 0000000..e1688d4
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1010rdb-pa.dts
@@ -0,0 +1,33 @@
+/*
+ * P1010 RDB-PA Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "fsl/p1010si-pre.dtsi"
+
+/ {
+ model = "fsl,P1010RDB-PA";
+ compatible = "fsl,P1010RDB";
+
+ /include/ "p1010rdb.dtsi"
+};
+
+&phy0 {
+ interrupts = <3 1 0 0>;
+};
+
+&phy1 {
+ interrupts = <2 1 0 0>;
+};
+
+&phy2 {
+ interrupts = <2 1 0 0>;
+};
+
+/include/ "fsl/p1010si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1010rdb-pb.dts b/arch/powerpc/boot/dts/p1010rdb-pb.dts
new file mode 100644
index 0000000..37f9366
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1010rdb-pb.dts
@@ -0,0 +1,33 @@
+/*
+ * P1010 RDB-PB Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "fsl/p1010si-pre.dtsi"
+
+/ {
+ model = "fsl,P1010RDB-PB";
+ compatible = "fsl,P1010RDB";
+
+ /include/ "p1010rdb.dtsi"
+};
+
+&phy0 {
+ interrupts = <0 1 0 0>;
+};
+
+&phy1 {
+ interrupts = <2 1 0 0>;
+};
+
+&phy2 {
+ interrupts = <1 1 0 0>;
+};
+
+/include/ "fsl/p1010si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
deleted file mode 100644
index b868d22..0000000
--- a/arch/powerpc/boot/dts/p1010rdb.dts
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * P1010 RDB Device Tree Source
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-/include/ "fsl/p1010si-pre.dtsi"
-
-/ {
- model = "fsl,P1010RDB";
- compatible = "fsl,P1010RDB";
-
- memory {
- device_type = "memory";
- };
-
- board_ifc: ifc: ifc@ffe1e000 {
- /* NOR, NAND Flashes and CPLD on board */
- ranges = <0x0 0x0 0x0 0xee000000 0x02000000
- 0x1 0x0 0x0 0xff800000 0x00010000
- 0x3 0x0 0x0 0xffb00000 0x00000020>;
- reg = <0x0 0xffe1e000 0 0x2000>;
- };
-
- board_soc: soc: soc@ffe00000 {
- ranges = <0x0 0x0 0xffe00000 0x100000>;
- };
-
- pci0: pcie@ffe09000 {
- reg = <0 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
- pcie@0 {
- ranges = <0x2000000 0x0 0xa0000000
- 0x2000000 0x0 0xa0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- pci1: pcie@ffe0a000 {
- reg = <0 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
- pcie@0 {
- ranges = <0x2000000 0x0 0x80000000
- 0x2000000 0x0 0x80000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-};
-
-/include/ "p1010rdb.dtsi"
-/include/ "fsl/p1010si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi b/arch/powerpc/boot/dts/p1010rdb.dtsi
index 7fc3402..5e5ca56 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
@@ -32,7 +32,17 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-&board_ifc {
+memory {
+ device_type = "memory";
+};
+
+board_ifc: ifc: ifc@ffe1e000 {
+ /* NOR, NAND Flashes and CPLD on board */
+ ranges = <0x0 0x0 0x0 0xee000000 0x02000000
+ 0x1 0x0 0x0 0xff800000 0x00010000
+ 0x3 0x0 0x0 0xffb00000 0x00000020>;
+ reg = <0x0 0xffe1e000 0 0x2000>;
+
nor@0,0 {
#address-cells = <1>;
#size-cells = <1>;
@@ -124,7 +134,9 @@
};
};
-&board_soc {
+board_soc: soc: soc@ffe00000 {
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+
i2c@3000 {
eeprom@50 {
compatible = "st,24c256";
@@ -199,17 +211,14 @@
mdio@24000 {
phy0: ethernet-phy@0 {
- interrupts = <3 1 0 0>;
reg = <0x1>;
};
phy1: ethernet-phy@1 {
- interrupts = <2 1 0 0>;
reg = <0x0>;
};
phy2: ethernet-phy@2 {
- interrupts = <2 1 0 0>;
reg = <0x2>;
};
@@ -261,3 +270,35 @@
ptimer-handle = <&ptp_timer>;
};
};
+
+pci0: pcie@ffe09000 {
+ reg = <0 0xffe09000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+};
+
+pci1: pcie@ffe0a000 {
+ reg = <0 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+
+ pcie@0 {
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+};
--
1.8.0
^ permalink raw reply related
* [PATCH v2 0/2] powerpc/85xx: introduce corenet_generic machine
From: Kevin Hao @ 2013-09-22 7:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc
v2:
- Fold the original patch 2 into patch 1.
- Update the patch 1 according to Scott and Kumar's comments.
- Introduce a new patch to rename the corenet_ds.c to corenet_generic.c.
v1:
This patch series introduces a common machine to support p2041rdb, p3041ds,
p4080ds, p5020ds, p5040ds, t4240qds and b4qds to avoid the code duplication.
Boot test on p5020ds and p4080ds.
Kevin Hao (2):
powerpc/85xx: introduce corenet_generic machine
powerpc/85xx: rename the corenet_ds.c to corenet_generic.c
arch/powerpc/platforms/85xx/Kconfig | 10 ++
arch/powerpc/platforms/85xx/Makefile | 8 +-
arch/powerpc/platforms/85xx/b4_qds.c | 97 --------------
arch/powerpc/platforms/85xx/corenet_ds.c | 96 --------------
arch/powerpc/platforms/85xx/corenet_ds.h | 19 ---
arch/powerpc/platforms/85xx/corenet_generic.c | 182 ++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/p2041_rdb.c | 87 ------------
arch/powerpc/platforms/85xx/p3041_ds.c | 89 -------------
arch/powerpc/platforms/85xx/p4080_ds.c | 87 ------------
arch/powerpc/platforms/85xx/p5020_ds.c | 93 -------------
arch/powerpc/platforms/85xx/p5040_ds.c | 84 ------------
arch/powerpc/platforms/85xx/t4240_qds.c | 93 -------------
12 files changed, 193 insertions(+), 752 deletions(-)
delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h
create mode 100644 arch/powerpc/platforms/85xx/corenet_generic.c
delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
--
1.8.3.1
^ 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