* Re: [PATCH tip/core/rcu 48/55] powerpc: strengthen value-returning-atomics memory barriers
From: Olof Johansson @ 2011-09-09 18:43 UTC (permalink / raw)
To: paulmck
Cc: mathieu.desnoyers, laijs, eric.dumazet, patches, peterz,
linux-kernel, rostedt, josh, dhowells, darren, niv, linuxppc-dev,
tglx, anton, Valdis.Kletnieks, mingo, akpm, paulus
In-Reply-To: <20110909173455.GH2435@linux.vnet.ibm.com>
On Fri, Sep 9, 2011 at 10:34 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Fri, Sep 09, 2011 at 10:23:33AM -0700, Olof Johansson wrote:
>> [+linuxppc-dev]
>>
>> On Tue, Sep 6, 2011 at 11:00 AM, Paul E. McKenney
>> <paulmck@linux.vnet.ibm.com> wrote:
>> > The trailing isync/lwsync in PowerPC value-returning atomics needs
>> > to be a sync in order to provide the required ordering properties.
>> > The leading lwsync/eieio can remain, as the remainder of the required
>> > ordering guarantees are provided by the atomic instructions: Any
>> > reordering will cause the stwcx to fail, which will result in a retry.
>>
>> Admittedly, my powerpc barrier memory is starting to fade, but isn't
>> isync sufficient here? It will make sure all instructions before it
>> have retired, and will restart any speculative/issued instructions
>> beyond it.
>>
>> lwsync not being sufficient makes sense since a load can overtake it.
>
> As I understand it, although isync waits for the prior stwcx to execute,
> it does not guarantee that the corresponding store is visible to all
> processors before any following loads.
Ah yes, combined with brushing up on the semantics in
memory-barriers.txt, this sounds reasonable to me.
>> > diff --git a/arch/powerpc/include/asm/synch.h b/arch/powerpc/include/a=
sm/synch.h
>> > index d7cab44..4d97fbe 100644
>> > --- a/arch/powerpc/include/asm/synch.h
>> > +++ b/arch/powerpc/include/asm/synch.h
>> > @@ -37,11 +37,7 @@ static inline void isync(void)
>> > =A0#endif
>> >
>> > =A0#ifdef CONFIG_SMP
>> > -#define __PPC_ACQUIRE_BARRIER =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0\
>> > - =A0 =A0 =A0 START_LWSYNC_SECTION(97); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 \
>> > - =A0 =A0 =A0 isync; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> > - =A0 =A0 =A0 MAKE_LWSYNC_SECTION_ENTRY(97, __lwsync_fixup);
>> > -#define PPC_ACQUIRE_BARRIER =A0 =A0"\n" stringify_in_c(__PPC_ACQUIRE_=
BARRIER)
>> > +#define PPC_ACQUIRE_BARRIER =A0 =A0"\n" stringify_in_c(sync;)
>>
>> This can just be done as "\n\tsync\n" instead of the stringify stuff.
>
> That does sound a bit more straightforward, now that you mention it. =A0;=
-)
With that change, I'm:
Acked-by: Olof Johansson <olof@lixom.net>
But at least Ben or Anton should sign off on it too.
-Olof
^ permalink raw reply
* Re: [PATCH tip/core/rcu 48/55] powerpc: strengthen value-returning-atomics memory barriers
From: Paul E. McKenney @ 2011-09-09 17:34 UTC (permalink / raw)
To: Olof Johansson
Cc: mathieu.desnoyers, laijs, eric.dumazet, patches, peterz,
linux-kernel, rostedt, josh, dhowells, darren, niv, linuxppc-dev,
tglx, anton, Valdis.Kletnieks, mingo, akpm, paulus
In-Reply-To: <CAOesGMi--W6TCUMZzF07-Zep9Ta3tBJWZcG+5imEK_Hza0y9Jg@mail.gmail.com>
On Fri, Sep 09, 2011 at 10:23:33AM -0700, Olof Johansson wrote:
> [+linuxppc-dev]
>
> On Tue, Sep 6, 2011 at 11:00 AM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > The trailing isync/lwsync in PowerPC value-returning atomics needs
> > to be a sync in order to provide the required ordering properties.
> > The leading lwsync/eieio can remain, as the remainder of the required
> > ordering guarantees are provided by the atomic instructions: Any
> > reordering will cause the stwcx to fail, which will result in a retry.
>
> Admittedly, my powerpc barrier memory is starting to fade, but isn't
> isync sufficient here? It will make sure all instructions before it
> have retired, and will restart any speculative/issued instructions
> beyond it.
>
> lwsync not being sufficient makes sense since a load can overtake it.
As I understand it, although isync waits for the prior stwcx to execute,
it does not guarantee that the corresponding store is visible to all
processors before any following loads.
> > diff --git a/arch/powerpc/include/asm/synch.h b/arch/powerpc/include/asm/synch.h
> > index d7cab44..4d97fbe 100644
> > --- a/arch/powerpc/include/asm/synch.h
> > +++ b/arch/powerpc/include/asm/synch.h
> > @@ -37,11 +37,7 @@ static inline void isync(void)
> > #endif
> >
> > #ifdef CONFIG_SMP
> > -#define __PPC_ACQUIRE_BARRIER \
> > - START_LWSYNC_SECTION(97); \
> > - isync; \
> > - MAKE_LWSYNC_SECTION_ENTRY(97, __lwsync_fixup);
> > -#define PPC_ACQUIRE_BARRIER "\n" stringify_in_c(__PPC_ACQUIRE_BARRIER)
> > +#define PPC_ACQUIRE_BARRIER "\n" stringify_in_c(sync;)
>
> This can just be done as "\n\tsync\n" instead of the stringify stuff.
That does sound a bit more straightforward, now that you mention it. ;-)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH tip/core/rcu 48/55] powerpc: strengthen value-returning-atomics memory barriers
From: Olof Johansson @ 2011-09-09 17:23 UTC (permalink / raw)
To: Paul E. McKenney
Cc: mathieu.desnoyers, laijs, eric.dumazet, patches, peterz,
linux-kernel, rostedt, josh, dhowells, darren, niv, linuxppc-dev,
tglx, anton, Valdis.Kletnieks, mingo, akpm, paulus
In-Reply-To: <1315332049-2604-48-git-send-email-paulmck@linux.vnet.ibm.com>
[+linuxppc-dev]
On Tue, Sep 6, 2011 at 11:00 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> The trailing isync/lwsync in PowerPC value-returning atomics needs
> to be a sync in order to provide the required ordering properties.
> The leading lwsync/eieio can remain, as the remainder of the required
> ordering guarantees are provided by the atomic instructions: Any
> reordering will cause the stwcx to fail, which will result in a retry.
Admittedly, my powerpc barrier memory is starting to fade, but isn't
isync sufficient here? It will make sure all instructions before it
have retired, and will restart any speculative/issued instructions
beyond it.
lwsync not being sufficient makes sense since a load can overtake it.
> diff --git a/arch/powerpc/include/asm/synch.h b/arch/powerpc/include/asm/=
synch.h
> index d7cab44..4d97fbe 100644
> --- a/arch/powerpc/include/asm/synch.h
> +++ b/arch/powerpc/include/asm/synch.h
> @@ -37,11 +37,7 @@ static inline void isync(void)
> =A0#endif
>
> =A0#ifdef CONFIG_SMP
> -#define __PPC_ACQUIRE_BARRIER =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0\
> - =A0 =A0 =A0 START_LWSYNC_SECTION(97); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 \
> - =A0 =A0 =A0 isync; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> - =A0 =A0 =A0 MAKE_LWSYNC_SECTION_ENTRY(97, __lwsync_fixup);
> -#define PPC_ACQUIRE_BARRIER =A0 =A0"\n" stringify_in_c(__PPC_ACQUIRE_BAR=
RIER)
> +#define PPC_ACQUIRE_BARRIER =A0 =A0"\n" stringify_in_c(sync;)
This can just be done as "\n\tsync\n" instead of the stringify stuff.
-Olof
^ permalink raw reply
* RE: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Zang Roy-R61911 @ 2011-09-09 16:00 UTC (permalink / raw)
To: Anton Vorontsov, cjb@laptop.org
Cc: linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org,
linux-mmc@vger.kernel.org, Xu Lei-B33228
In-Reply-To: <20110909140701.GA9258@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1i
ZXIgMDksIDIwMTEgMjI6MDcgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bW1jQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGFrcG1A
bGludXgtDQo+IGZvdW5kYXRpb24ub3JnOyBYdSBMZWktQjMzMjI4OyBLdW1hciBHYWxhDQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0hdIGVTREhDOiBBY2Nlc3MgRnJlZXNjYWxlIGVTREhDIHJlZ2lzdGVy
cyBieSAzMi1iaXQNCj4gDQo+IE9uIEZyaSwgU2VwIDA5LCAyMDExIGF0IDA4OjA1OjQ2UE0gKzA4
MDAsIFJveSBaYW5nIHdyb3RlOg0KPiA+IEZyb206IFh1IGxlaSA8QjMzMjI4QGZyZWVzY2FsZS5j
b20+DQo+ID4NCj4gPiBGcmVlc2NhbGUgZVNESEMgcmVnaXN0ZXJzIG9ubHkgc3VwcG9ydCAzMi1i
aXQgYWNjZXNzZXMsDQo+ID4gdGhpcyBwYXRjaCBlbnN1cmVzIHRoYXQgYWxsIEZyZWVzY2FsZSBl
U0RIQyByZWdpc3RlciBhY2Nlc3Nlcw0KPiA+IGFyZSAzMi1iaXQuDQo+ID4NCj4gPiBTaWduZWQt
b2ZmLWJ5OiBYdSBsZWkgPEIzMzIyOEBmcmVlc2NhbGUuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6
IFJveSBaYW5nIDx0aWUtZmVpLnphbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5
OiBLdW1hciBHYWxhIDxnYWxha0BrZXJuZWwuY3Jhc2hpbmcub3JnPg0KPiA+IC0tLQ0KPiANCj4g
VGhlIHBhdGNoIGxvb2tzIE9LLg0KPiANCj4gQWNrZWQtYnk6IEFudG9uIFZvcm9udHNvdiA8Y2Jv
dWF0bWFpbHJ1QGdtYWlsLmNvbT4NClRoYW5rcy4NCkFkZCBDaHJpcy4NCg0KPiANCj4gWy4uLl0N
Cj4gPiArc3RhdGljIHU4IGVzZGhjX3JlYWRiKHN0cnVjdCBzZGhjaV9ob3N0ICpob3N0LCBpbnQg
cmVnKQ0KPiA+ICt7DQo+ID4gKwlpbnQgYmFzZSA9IHJlZyAmIH4weDM7DQo+ID4gKwlpbnQgc2hp
ZnQgPSAocmVnICYgMHgzKSAqIDg7DQo+ID4gKwl1OCByZXQgPSAoaW5fYmUzMihob3N0LT5pb2Fk
ZHIgKyBiYXNlKSA+PiBzaGlmdCkgJiAweGZmOw0KPiA+ICAJcmV0dXJuIHJldDsNCj4gPiAgfQ0K
PiANCj4gVGhvdWdoLCBJIHdvbmRlciBpZiB3ZSBjb3VsZCBjaGFuZ2Ugc2RoY2lfYmUzMmJzX3Jl
YWR7Yix3fSwgaW5zdGVhZA0KPiBvZiBtYWtpbmcgdGhpcyBsb2NhbCB0byBlU0RIQy4NCj4gDQo+
IFRoZSB0aGluZyBpczogc2RoY2lfYmUzMmJzX3dyaXRlYigpIGlzIHVzaW5nIGNscnNldGJpdHNf
YmUzMiwNCj4gc28gdGhlIHdyaXRlIHZhcmlhbnQgYWxyZWFkeSB1c2VzIDMyLWJpdCBhY2Nlc3Nv
cnMsIHNvIG5vdGhpbmcgc2hvdWxkDQo+IGJyZWFrIGlmIHdlIHN3aXRjaCBzZGhjaV9iZTMyYnNf
cmVhZGIoKSB0byBpbl9iZTMyKCkuDQo+IA0KPiBCdXQgbWF5YmUgaXQncyBzYWZlciBpZiB3ZSBk
byB0aGlzIGluIGEgc2VwYXJhdGUgcGF0Y2gsIHNvIHRoYXQgaXQNCj4gY291bGQgYmUgZWFzaWx5
IHJldmVydGVkIHdpdGhvdXQgaW1wYWN0aW5nIGVTREhDIGlmIHNvbWV0aGluZyBhY3R1YWxseQ0K
PiBicmVha3MuDQo+IA0KPiBZb3UgZGVjaWRlLiA6LSkNCj4gDQo+IFRoYW5rcyENClRoZSBzdWdn
ZXN0aW9uIG1ha2VzIHNlbnNlLiBJJ2QgbGlrZSB0byBkbyB0aGlzIGluIGEgc2VwYXJhdGUgcGF0
Y2ggYWZ0ZXIgdGhpcyBwYXRjaCBhcHBsaWVkLg0KVGhhbmtzLg0KUm95DQo=
^ permalink raw reply
* Re: [PATCH 54/62] TTY: irq: Remove IRQF_DISABLED
From: Tobias Klauser @ 2011-09-09 9:49 UTC (permalink / raw)
To: Yong Zhang
Cc: Jesper Nilsson, linux-cris-kernel, nios2-dev, Lucas De Marchi,
Greg Kroah-Hartman, linux-kernel, Mikael Starvik, Jesper Juhl,
linux-serial, Jiri Kosina, uclinux-dist-devel, tglx, Sonic Zhang,
linuxppc-dev, mingo, Alan Cox
In-Reply-To: <1315383059-3673-55-git-send-email-yong.zhang0@gmail.com>
On 2011-09-07 at 10:10:51 +0200, Yong Zhang <yong.zhang0@gmail.com> wrote:
> This flag is a NOOP and can be removed now.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
For altera_jtaguart and altera_uart:
Acked-by: Tobias Klauser <tklauser@distanz.ch>
^ permalink raw reply
* Re: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Anton Vorontsov @ 2011-09-09 14:07 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, akpm, linux-mmc, Xu lei
In-Reply-To: <1315569946-21386-1-git-send-email-tie-fei.zang@freescale.com>
On Fri, Sep 09, 2011 at 08:05:46PM +0800, Roy Zang wrote:
> From: Xu lei <B33228@freescale.com>
>
> Freescale eSDHC registers only support 32-bit accesses,
> this patch ensures that all Freescale eSDHC register accesses
> are 32-bit.
>
> Signed-off-by: Xu lei <B33228@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
The patch looks OK.
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
[...]
> +static u8 esdhc_readb(struct sdhci_host *host, int reg)
> +{
> + int base = reg & ~0x3;
> + int shift = (reg & 0x3) * 8;
> + u8 ret = (in_be32(host->ioaddr + base) >> shift) & 0xff;
> return ret;
> }
Though, I wonder if we could change sdhci_be32bs_read{b,w}, instead
of making this local to eSDHC.
The thing is: sdhci_be32bs_writeb() is using clrsetbits_be32,
so the write variant already uses 32-bit accessors, so nothing should
break if we switch sdhci_be32bs_readb() to in_be32().
But maybe it's safer if we do this in a separate patch, so that it
could be easily reverted without impacting eSDHC if something actually
breaks.
You decide. :-)
Thanks!
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Wolfram Sang @ 2011-09-09 13:08 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2239AC579C7D3646A720227A37E026811A2311@039-SN1MPN1-005.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
> Previously, I sent this patch together with another one. But
> technically they are separated patches. I got some comments from
> Anton about the patch. I will try to address the comment. but for this
> one, it is a stand along patch. I'd like to push it first.
Okay.
> I do not see any comment about byte swapping about this patch.
> you may have mis-understanding here.
I was misguided, yes, sorry. BE/LE issues with additional byteswapping
are a mind twister :/ Having a second look, it looks okay to me. One
could think about putting this into sdhci_platform as well, but this can
be done later if needed. Sadly, I currently don't have hardware to test
it.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Zang Roy-R61911 @ 2011-09-09 12:48 UTC (permalink / raw)
To: Wolfram Sang
Cc: Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110909123324.GQ1912@pengutronix.de>
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> Sent: Friday, September 09, 2011 20:33 PM
> To: Zang Roy-R61911
> Cc: cjb@laptop.org; linux-mmc@vger.kernel.org; linuxppc-dev@lists.ozlabs.=
org;
> akpm@linux-foundation.org; cbouatmailru@gmail.com; Xu Lei-B33228; Kumar G=
ala
> Subject: Re: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
>=20
> On Fri, Sep 09, 2011 at 12:23:05PM +0000, Zang Roy-R61911 wrote:
>=20
> > > > Freescale eSDHC registers only support 32-bit accesses,
> > > > this patch ensures that all Freescale eSDHC register accesses
> > > > are 32-bit.
> > >
> > > So, what about the byte-swapping that Anton needed? You are simply
> > > removing that if I am not mistaken.
> > I do not see any comment for this patch from Anton.
>=20
> Maybe he is busy?
Sounds fair.
>=20
> > You may miss the patch. Please confirm.
>=20
> I don't understand, what needs to be confirmed?
Confirm: there is no comment about this patch.=20
Previously, I sent this patch together with another one. But technically t=
hey are separated patches. I got some comments from Anton about the patch.=
I will try to address the comment. but for this one, it is a stand along p=
atch. I'd like to push it first.
> I am simply wondering
> what happens to the byteswapping that Anton (back then) intentionally
> implemented.
I do not see any comment about byte swapping about this patch.
you may have mis-understanding here.
Roy
^ permalink raw reply
* Re: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Wolfram Sang @ 2011-09-09 12:33 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2239AC579C7D3646A720227A37E026811A22BD@039-SN1MPN1-005.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
On Fri, Sep 09, 2011 at 12:23:05PM +0000, Zang Roy-R61911 wrote:
> > > Freescale eSDHC registers only support 32-bit accesses,
> > > this patch ensures that all Freescale eSDHC register accesses
> > > are 32-bit.
> >
> > So, what about the byte-swapping that Anton needed? You are simply
> > removing that if I am not mistaken.
> I do not see any comment for this patch from Anton.
Maybe he is busy?
> You may miss the patch. Please confirm.
I don't understand, what needs to be confirmed? I am simply wondering
what happens to the byteswapping that Anton (back then) intentionally
implemented.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Zang Roy-R61911 @ 2011-09-09 12:23 UTC (permalink / raw)
To: Wolfram Sang, cjb@laptop.org
Cc: Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110909114004.GP1912@pengutronix.de>
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> Sent: Friday, September 09, 2011 19:40 PM
> To: Zang Roy-R61911
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; akpm@linux-
> foundation.org; cbouatmailru@gmail.com; Xu Lei-B33228; Kumar Gala
> Subject: Re: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
>=20
> Hi,
>=20
> On Fri, Sep 09, 2011 at 08:05:46PM +0800, Roy Zang wrote:
> > From: Xu lei <B33228@freescale.com>
> >
> > Freescale eSDHC registers only support 32-bit accesses,
> > this patch ensures that all Freescale eSDHC register accesses
> > are 32-bit.
>=20
> So, what about the byte-swapping that Anton needed? You are simply
> removing that if I am not mistaken.
I do not see any comment for this patch from Anton. You may miss the patch.=
Please confirm.
I add Chris in the loop.
Thanks.
Roy
^ permalink raw reply
* RE: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Zang Roy-R61911 @ 2011-09-09 12:16 UTC (permalink / raw)
To: Wolfram Sang, cjb@laptop.org
Cc: Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110909114004.GP1912@pengutronix.de>
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> Sent: Friday, September 09, 2011 19:40 PM
> To: Zang Roy-R61911
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; akpm@linux-
> foundation.org; cbouatmailru@gmail.com; Xu Lei-B33228; Kumar Gala
> Subject: Re: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
>=20
> Hi,
>=20
> On Fri, Sep 09, 2011 at 08:05:46PM +0800, Roy Zang wrote:
> > From: Xu lei <B33228@freescale.com>
> >
> > Freescale eSDHC registers only support 32-bit accesses,
> > this patch ensures that all Freescale eSDHC register accesses
> > are 32-bit.
>=20
> So, what about the byte-swapping that Anton needed? You are simply
> removing that if I am not mistaken.
>=20
> > Signed-off-by: Xu lei <B33228@freescale.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > ---
> > This is a patch resend
> > http://patchwork.ozlabs.org/patch/106245/
> > based on latest Linus tree.
> >
> > Andrew,
> > Could you help to pick up this patch first?
>=20
> mmc-list is not dead, it must go via Chris, I'd think.
This is the third time that I re-send this patch to the list. There is no =
comment.
That is why I ask Andrew's help.
>=20
> > drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++----
> > 1 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci=
-of-
> esdhc.c
> > index fe604df..40036f6 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -1,7 +1,7 @@
> > /*
> > * Freescale eSDHC controller driver.
> > *
> > - * Copyright (c) 2007 Freescale Semiconductor, Inc.
> > + * Copyright (c) 2007, 2010 Freescale Semiconductor, Inc.
>=20
> I wonder if such a small change has impact on the copyright.
I just update the year for tracking. Anything wrong?
Roy
^ permalink raw reply
* [PATCH] powerpc: Optimize __arch_swab32 and __arch_swab16
From: Joakim Tjernlund @ 2011-09-09 12:10 UTC (permalink / raw)
To: linuxppc-dev
PPC __arch_swab32 and __arch_swab16 generates non optimal code.
They do not schedule very well, need to copy its input register
and swab16 needs an extra insn to clear its upper bits.
Fix this with better inline ASM.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/include/asm/swab.h | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/swab.h b/arch/powerpc/include/asm/swab.h
index c581e3e..3b9a200 100644
--- a/arch/powerpc/include/asm/swab.h
+++ b/arch/powerpc/include/asm/swab.h
@@ -61,25 +61,25 @@ static inline void __arch_swab32s(__u32 *addr)
static inline __attribute_const__ __u16 __arch_swab16(__u16 value)
{
- __u16 result;
-
- __asm__("rlwimi %0,%1,8,16,23"
- : "=r" (result)
- : "r" (value), "0" (value >> 8));
- return result;
+ __asm__("rlwimi %0,%0,16,0x00ff0000\n\t"
+ "rlwinm %0,%0,24,0x0000ffff"
+ : "+r"(value));
+ return value;
}
#define __arch_swab16 __arch_swab16
static inline __attribute_const__ __u32 __arch_swab32(__u32 value)
{
- __u32 result;
-
- __asm__("rlwimi %0,%1,24,16,23\n\t"
- "rlwimi %0,%1,8,8,15\n\t"
- "rlwimi %0,%1,24,0,7"
- : "=r" (result)
- : "r" (value), "0" (value >> 24));
- return result;
+ __u32 tmp;
+
+ __asm__("rlwimi %0,%1,24,0xffffffff"
+ : "=r" (value) : "r" (value));
+ tmp = value;
+ __asm__("rlwimi %0,%1,16,0x00ff0000"
+ : "+r" (value) : "r" (tmp));
+ __asm__("rlwimi %0,%1,16,0x000000ff"
+ : "+r" (value) : "r" (tmp));
+ return value;
}
#define __arch_swab32 __arch_swab32
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Wolfram Sang @ 2011-09-09 11:40 UTC (permalink / raw)
To: Roy Zang; +Cc: Xu lei, linux-mmc, akpm, linuxppc-dev
In-Reply-To: <1315569946-21386-1-git-send-email-tie-fei.zang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
Hi,
On Fri, Sep 09, 2011 at 08:05:46PM +0800, Roy Zang wrote:
> From: Xu lei <B33228@freescale.com>
>
> Freescale eSDHC registers only support 32-bit accesses,
> this patch ensures that all Freescale eSDHC register accesses
> are 32-bit.
So, what about the byte-swapping that Anton needed? You are simply
removing that if I am not mistaken.
> Signed-off-by: Xu lei <B33228@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> This is a patch resend
> http://patchwork.ozlabs.org/patch/106245/
> based on latest Linus tree.
>
> Andrew,
> Could you help to pick up this patch first?
mmc-list is not dead, it must go via Chris, I'd think.
> drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index fe604df..40036f6 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1,7 +1,7 @@
> /*
> * Freescale eSDHC controller driver.
> *
> - * Copyright (c) 2007 Freescale Semiconductor, Inc.
> + * Copyright (c) 2007, 2010 Freescale Semiconductor, Inc.
I wonder if such a small change has impact on the copyright.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Roy Zang @ 2011-09-09 12:05 UTC (permalink / raw)
To: linux-mmc; +Cc: Xu lei, linuxppc-dev, akpm
From: Xu lei <B33228@freescale.com>
Freescale eSDHC registers only support 32-bit accesses,
this patch ensures that all Freescale eSDHC register accesses
are 32-bit.
Signed-off-by: Xu lei <B33228@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
This is a patch resend
http://patchwork.ozlabs.org/patch/106245/
based on latest Linus tree.
Andrew,
Could you help to pick up this patch first?
Thanks.
Roy
drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index fe604df..40036f6 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -1,7 +1,7 @@
/*
* Freescale eSDHC controller driver.
*
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2010 Freescale Semiconductor, Inc.
* Copyright (c) 2009 MontaVista Software, Inc.
*
* Authors: Xiaobo Xie <X.Xie@freescale.com>
@@ -22,11 +22,21 @@
static u16 esdhc_readw(struct sdhci_host *host, int reg)
{
u16 ret;
+ int base = reg & ~0x3;
+ int shift = (reg & 0x2) * 8;
if (unlikely(reg == SDHCI_HOST_VERSION))
- ret = in_be16(host->ioaddr + reg);
+ ret = in_be32(host->ioaddr + base) & 0xffff;
else
- ret = sdhci_be32bs_readw(host, reg);
+ ret = (in_be32(host->ioaddr + base) >> shift) & 0xffff;
+ return ret;
+}
+
+static u8 esdhc_readb(struct sdhci_host *host, int reg)
+{
+ int base = reg & ~0x3;
+ int shift = (reg & 0x3) * 8;
+ u8 ret = (in_be32(host->ioaddr + base) >> shift) & 0xff;
return ret;
}
@@ -74,7 +84,7 @@ static unsigned int esdhc_of_get_min_clock(struct sdhci_host *host)
static struct sdhci_ops sdhci_esdhc_ops = {
.read_l = sdhci_be32bs_readl,
.read_w = esdhc_readw,
- .read_b = sdhci_be32bs_readb,
+ .read_b = esdhc_readb,
.write_l = sdhci_be32bs_writel,
.write_w = esdhc_writew,
.write_b = esdhc_writeb,
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 2/2 v2] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Wolfram Sang @ 2011-09-09 9:07 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xu Lei-B33228, Wood Scott-B07421, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2239AC579C7D3646A720227A37E026811A1F8D@039-SN1MPN1-005.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
> > I would do it in the IO accessors.
> >
> > Thanks,
> Any update for your comment?
It is still valid. You can go that road.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH 2/2 v2] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Zang Roy-R61911 @ 2011-09-09 9:03 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110812100450.GA23333@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3Qg
MTIsIDIwMTEgMTg6MDUgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgtbW1j
QHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGFrcG1AbGlu
dXgtDQo+IGZvdW5kYXRpb24ub3JnOyBYdSBMZWktQjMzMjI4OyBLdW1hciBHYWxhOyBXb29kIFNj
b3R0LUIwNzQyMQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDIvMiB2Ml0gZVNESEM6IEZpeCBlcnJv
cnMgd2hlbiBib290aW5nIGtlcm5lbCB3aXRoIGZzbCBlc2RoYw0KPiANCj4gSGVsbG8sDQo+IA0K
PiBPbiBGcmksIEF1ZyAxMiwgMjAxMSBhdCAwOTo0NDoyNkFNICswMDAwLCBaYW5nIFJveS1SNjE5
MTEgd3JvdGU6DQo+IFsuLi5dDQo+ID4gPiBXZSB0cnkgdG8gbm90IHBvbGx1dGUgZ2VuZXJpYyBz
ZGhjaS5jIGRyaXZlciB3aXRoIGNoaXAtc3BlY2lmaWMNCj4gPiA+IHF1aXJrcy4NCj4gPiA+DQo+
ID4gPiBNYXliZSB5b3UgY2FuIGRvIHRoZSBmaXh1cHMgdmlhIElPIGFjY2Vzc29ycz8gT3IgYnkg
aW50cm9kdWNpbmcNCj4gPiA+IHNvbWUgYWRkaXRpb25hbCBzZGhjaSBvcD8NCj4gPiBBbnRvbiwN
Cj4gPiB0aGFua3MgZm9yIHRoZSBjb21tZW50LCBhcyB3ZSBkaXNjdXNzZWQsIHRoZSBvcmlnaW5h
bCBjb2RlIHVzZSA4IGJpdCBieXRlDQo+IG9wZXJhdGlvbiwNCj4gPiB3aGlsZSBpbiBmYWN0LCBv
biBzb21lIHBvd2VycGMgcGxhdGZvcm0sIDMyIGJpdCBvcGVyYXRpb24gaXMgbmVlZGVkLg0KPiA+
IHNob3VsZCBpdCBiZSBwb3NzaWJsZSBmaXhlZCBieSBhZGRpbmcgc29tZSB3cmFwcGVyIGluIElP
IGFjY2Vzc29ycyBvcg0KPiBpbnRyb2R1Y2UgYWRkaXRpb25hbCBzZGhjaSBvcD8NCj4gDQo+IEkg
d291bGQgZG8gaXQgaW4gdGhlIElPIGFjY2Vzc29ycy4NCj4gDQo+IFRoYW5rcywNCkFueSB1cGRh
dGUgZm9yIHlvdXIgY29tbWVudD8NClJveQ0K
^ permalink raw reply
* defunct pthread in multi-threaded application
From: Suchita Sharma @ 2011-09-09 6:48 UTC (permalink / raw)
To: linuxppc-dev
Hello All,
We have a powerpc 8260 based system with linux-2.4.20 version.Some
of the pthreads in multi-threaded application is getting defunct after some
time.Want help to solve this problem.
Thanks in advance ,
Shuchitha
^ permalink raw reply
* [PATCH] perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
From: Anshuman Khandual @ 2011-09-09 7:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Neuling, Paul Mackerras,
linux-kernel, linuxppc-dev
perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
Extent the POWER7 PMU driver with definitions for generic front-end and back-end
stall events.
As explained in Ingo's original comment(8f62242246351b5a4bc0c1f00c0c7003edea128a
), the exact definitions of the stall events are very much processor specific as
different things mean different in their respective instruction pipeline. These
two Power7 raw events are the closest approximation to the concept detailed in
Ingo's comment.
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
It means cycles when the Global Completion Table has no slots from this thread
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a, /* CMPLU_STALL */
It means no groups completed and GCT not empty for this thread
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
Version 2: added new comments in commit message as suggested by Mikey.
No code changes.
diff --git a/arch/powerpc/kernel/power7-pmu.c b/arch/powerpc/kernel/power7-pmu.c
index 593740f..e5d2844 100644
--- a/arch/powerpc/kernel/power7-pmu.c
+++ b/arch/powerpc/kernel/power7-pmu.c
@@ -297,6 +297,8 @@ static void power7_disable_pmc(unsigned int pmc, unsigned long mmcr[])
static int power7_generic_events[] = {
[PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
+ [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
+ [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a, /* CMPLU_STALL */
[PERF_COUNT_HW_INSTRUCTIONS] = 2,
[PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU*/
[PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
--
Anshuman Khandual
LTC India
^ permalink raw reply related
* Re: [PATCH] perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
From: Michael Neuling @ 2011-09-09 6:26 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <4E69AFCF.3040404@linux.vnet.ibm.com>
In message <4E69AFCF.3040404@linux.vnet.ibm.com> you wrote:
> On Friday 09 September 2011 07:08 AM, Michael Neuling wrote:
> >> perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
> >>
> >> Extent the POWER7 PMU driver with definitions
> >> for generic front-end and back-end stall events.
> >
> > Anshuman,
> >
> > Can you explain what these P7 events actually are and how they relate to
> > Ingo's original comment on this in
> > 8f62242246351b5a4bc0c1f00c0c7003edea128a
> >
> > Both events limit performance: most front end stalls tend to be
> > caused by branch misprediction or instruction fetch cachemisses,
> > backend stalls can be caused by various resource shortages or
> > inefficient instruction scheduling.
> >
> As explained in Ingo's original comment, the exact definitions of the
> stall events are very much processor specific as different things mean
> different in their respective instruction pipeline. These two Power7
> raw events are the closest approximation to the concept detailed in
> Ingo's comment.
> >>
> >> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> >>
> >> diff --git a/arch/powerpc/kernel/power7-pmu.c b/arch/powerpc/kernel/power7
-pmu.c
> >> index 593740f..e5d2844 100644
> >> --- a/arch/powerpc/kernel/power7-pmu.c
> >> +++ b/arch/powerpc/kernel/power7-pmu.c
> >> @@ -297,6 +297,8 @@ static void power7_disable_pmc(unsigned int pmc, unsig
ned long mmcr[])
> >>
> >> static int power7_generic_events[] = {
> >> [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
> >> + [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
> >
> > eg. Is this Global Completion Table (GCT) empty?
> Yes, it means cycles when the Global Completion Table has no slots from this thread
> >
> >> + [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a, /* CMPLU_STALL
*/
> >
> > eg. Is this instruction completion stall?
> Yes, it means no groups completed and GCT not empty
I agree, I think they match what Ingo is trying to achieve.
Can you add these descriptions to the patch and resubmit please?
If you can find similar events for power4/5/5+/6 that would be great too
submit too.
FWIW, the patch compiles and runs for me.
Mikey
^ permalink raw reply
* Re: [PATCH] perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
From: Anshuman Khandual @ 2011-09-09 6:18 UTC (permalink / raw)
To: Michael Neuling; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <25545.1315532289@neuling.org>
On Friday 09 September 2011 07:08 AM, Michael Neuling wrote:
>> perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
>>
>> Extent the POWER7 PMU driver with definitions
>> for generic front-end and back-end stall events.
>
> Anshuman,
>
> Can you explain what these P7 events actually are and how they relate to
> Ingo's original comment on this in
> 8f62242246351b5a4bc0c1f00c0c7003edea128a
>
> Both events limit performance: most front end stalls tend to be
> caused by branch misprediction or instruction fetch cachemisses,
> backend stalls can be caused by various resource shortages or
> inefficient instruction scheduling.
>
As explained in Ingo's original comment, the exact definitions of the stall
events are very much processor specific as different things mean different in
their respective instruction pipeline. These two Power7 raw events are the closest
approximation to the concept detailed in Ingo's comment.
>>
>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>
>> diff --git a/arch/powerpc/kernel/power7-pmu.c b/arch/powerpc/kernel/power7-pmu.c
>> index 593740f..e5d2844 100644
>> --- a/arch/powerpc/kernel/power7-pmu.c
>> +++ b/arch/powerpc/kernel/power7-pmu.c
>> @@ -297,6 +297,8 @@ static void power7_disable_pmc(unsigned int pmc, unsigned long mmcr[])
>>
>> static int power7_generic_events[] = {
>> [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
>> + [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
>
> eg. Is this Global Completion Table (GCT) empty?
Yes, it means cycles when the Global Completion Table has no slots from this thread
>
>> + [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a, /* CMPLU_STALL */
>
> eg. Is this instruction completion stall?
Yes, it means no groups completed and GCT not empty
>
> Mikey
>
>> [PERF_COUNT_HW_INSTRUCTIONS] = 2,
>> [PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU*/
>> [PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
>>
>> --
>> Anshuman Khandual
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Anshuman Khandual
LTC India
^ permalink raw reply
* Re: [PATCH] perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
From: Michael Neuling @ 2011-09-09 1:38 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <4E5C6A7D.2010909@linux.vnet.ibm.com>
> perf events, powerpc: Add POWER7 stalled-cycles-frontend/backend events
>
> Extent the POWER7 PMU driver with definitions
> for generic front-end and back-end stall events.
Anshuman,
Can you explain what these P7 events actually are and how they relate to
Ingo's original comment on this in
8f62242246351b5a4bc0c1f00c0c7003edea128a
Both events limit performance: most front end stalls tend to be
caused by branch misprediction or instruction fetch cachemisses,
backend stalls can be caused by various resource shortages or
inefficient instruction scheduling.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>
> diff --git a/arch/powerpc/kernel/power7-pmu.c b/arch/powerpc/kernel/power7-pmu.c
> index 593740f..e5d2844 100644
> --- a/arch/powerpc/kernel/power7-pmu.c
> +++ b/arch/powerpc/kernel/power7-pmu.c
> @@ -297,6 +297,8 @@ static void power7_disable_pmc(unsigned int pmc, unsigned long mmcr[])
>
> static int power7_generic_events[] = {
> [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
> + [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
eg. Is this Global Completion Table (GCT) empty?
> + [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a, /* CMPLU_STALL */
eg. Is this instruction completion stall?
Mikey
> [PERF_COUNT_HW_INSTRUCTIONS] = 2,
> [PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU*/
> [PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
>
> --
> Anshuman Khandual
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [RFC PATCH 03/10] fadump: Register for firmware assisted dump.
From: Kumar Gala @ 2011-09-08 18:34 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Linux Kernel, Milton Miller, Michael Ellerman, Anton Blanchard,
linuxppc-dev, Eric W. Biederman
In-Reply-To: <20110713180705.6210.44160.stgit@mars.in.ibm.com>
>=20
> diff --git a/arch/powerpc/kernel/setup_64.c =
b/arch/powerpc/kernel/setup_64.c
> index a88bf27..3031ea7 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -63,6 +63,7 @@
> #include <asm/kexec.h>
> #include <asm/mmu_context.h>
> #include <asm/code-patching.h>
> +#include <asm/fadump.h>
>=20
> #include "setup.h"
>=20
> @@ -371,6 +372,13 @@ void __init setup_system(void)
> rtas_initialize();
> #endif /* CONFIG_PPC_RTAS */
>=20
> +#ifdef CONFIG_FA_DUMP
> + /*
> + * Setup Firmware-assisted dump.
> + */
> + setup_fadump();
Is there a reason this has to be done here? Can it be an initcall or =
called from platform init code?
> +#endif
> +
- k
^ permalink raw reply
* Re: [PATCH 17/62] powerpc: irq: Remove IRQF_DISABLED
From: Arnd Bergmann @ 2011-09-08 16:41 UTC (permalink / raw)
To: Yong Zhang
Cc: Meador Inge, cbe-oss-dev, Geoff Levand, linux-kernel,
Milton Miller, Michael Ellerman, Paul Mackerras, Scott Wood, tglx,
linuxppc-dev, mingo
In-Reply-To: <1315383059-3673-18-git-send-email-yong.zhang0@gmail.com>
On Wednesday 07 September 2011, Yong Zhang wrote:
>
> This flag is a NOOP and can be removed now.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> ---
> arch/powerpc/include/asm/floppy.h | 4 ++--
> arch/powerpc/include/asm/xics.h | 4 ++--
> arch/powerpc/kernel/smp.c | 2 +-
> arch/powerpc/platforms/cell/beat.c | 2 +-
> arch/powerpc/platforms/cell/celleb_scc_pciex.c | 2 +-
> arch/powerpc/platforms/cell/iommu.c | 3 +--
> arch/powerpc/platforms/cell/pmu.c | 2 +-
> arch/powerpc/platforms/cell/spu_base.c | 9 +++------
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 45/62] net: irq: Remove IRQF_DISABLED
From: Yong Zhang @ 2011-09-08 13:41 UTC (permalink / raw)
To: Thomas Gleixner
Cc: perex, dhowells, prakity, netdev, chunkeey, sonic.zhang,
klaus.kudielka, t.sailer, khilman, eric.dumazet, jhovold, cyril,
rmk+kernel, mingo, jpr, adobriyan, jreuter, cbe-oss-dev,
martinez.javier, samuel, vapier, grundler, tklauser,
lucas.demarchi, u.kleine-koenig, olof, uclinux-dist-devel,
linux-hams, leitao, blogic, shawn.guo, nico, geoff, jkosina,
linux-wireless, linux-kernel, ralf, ralph.hempel, jdmason, joe,
steve.glendinning, richard.cochran, linuxppc-dev, David Miller
In-Reply-To: <alpine.LFD.2.02.1109072000290.2723@ionos>
On Wed, Sep 07, 2011 at 08:03:14PM +0200, Thomas Gleixner wrote:
> On Wed, 7 Sep 2011, David Miller wrote:
>
> > From: Thomas Gleixner <tglx@linutronix.de>
> > Date: Wed, 7 Sep 2011 19:32:39 +0200 (CEST)
> >
> > > On Wed, 7 Sep 2011, David Miller wrote:
> > >
> > >> From: Yong Zhang <yong.zhang0@gmail.com>
> > >> Date: Wed, 7 Sep 2011 16:10:42 +0800
> > >>
> > >> > This flag is a NOOP and can be removed now.
> > >> >
> > >> > Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> > >>
> > >> I have the same concerns here as I had for the sparc case.
> > >>
> > >> Some of these drivers might be using IRQF_DISABLED to make sure the
> > >> IRQ cannot be delivered until it is explicitly enabled via an
> > >> enable_irq() call.
> > >>
> > >> How is that being accomodated now?
> > >
> > > Again IRQF_DISABLED never ever had that functionality.
> >
> > My bad.
> >
> > But what if these interrupts want interrupts disabled during their
> > interrupt handler, for other reasons?
>
> We run ALL interrupt handlers with irqs disabled always.
>
> > This has the potential to break tons of stuff, especially on the
> > really old chips which almost no developers have any more but some
> > user might try to use.
>
> It won't. We removed IRQF_DISABLED from kernel/irq/* long ago
Yeah, and this is why we say it's a NOOP now :)
Thanks,
Yong
^ permalink raw reply
* Re: [PATCH 45/62] net: irq: Remove IRQF_DISABLED
From: Thomas Gleixner @ 2011-09-07 18:03 UTC (permalink / raw)
To: David Miller
Cc: perex, dhowells, prakity, netdev, chunkeey, sonic.zhang,
klaus.kudielka, t.sailer, khilman, eric.dumazet, jhovold, cyril,
rmk+kernel, mingo, jpr, adobriyan, jreuter, cbe-oss-dev,
martinez.javier, samuel, vapier, grundler, yong.zhang0, tklauser,
lucas.demarchi, u.kleine-koenig, olof, uclinux-dist-devel,
linux-hams, leitao, blogic, shawn.guo, nico, geoff, jkosina,
linux-wireless, linux-kernel, ralf, ralph.hempel, jdmason, joe,
steve.glendinning, richard.cochran, linuxppc-dev
In-Reply-To: <20110907.135234.17759197083710999.davem@davemloft.net>
On Wed, 7 Sep 2011, David Miller wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Wed, 7 Sep 2011 19:32:39 +0200 (CEST)
>
> > On Wed, 7 Sep 2011, David Miller wrote:
> >
> >> From: Yong Zhang <yong.zhang0@gmail.com>
> >> Date: Wed, 7 Sep 2011 16:10:42 +0800
> >>
> >> > This flag is a NOOP and can be removed now.
> >> >
> >> > Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> >>
> >> I have the same concerns here as I had for the sparc case.
> >>
> >> Some of these drivers might be using IRQF_DISABLED to make sure the
> >> IRQ cannot be delivered until it is explicitly enabled via an
> >> enable_irq() call.
> >>
> >> How is that being accomodated now?
> >
> > Again IRQF_DISABLED never ever had that functionality.
>
> My bad.
>
> But what if these interrupts want interrupts disabled during their
> interrupt handler, for other reasons?
We run ALL interrupt handlers with irqs disabled always.
> This has the potential to break tons of stuff, especially on the
> really old chips which almost no developers have any more but some
> user might try to use.
It won't. We removed IRQF_DISABLED from kernel/irq/* long ago
Thanks,
tglx
^ 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