* RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Shaohui Xie @ 2014-12-23 8:17 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Emilian Medve, Igal.Liberman@freescale.com
In-Reply-To: <1419322085.5581.182.camel@freescale.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyMywgMjAxNCA0OjA4IFBNDQo+IFRvOiBYaWUgU2hh
b2h1aS1CMjE5ODkNCj4gQ2M6IE1lZHZlIEVtaWxpYW4tRU1NRURWRTE7IGxpbnV4cHBjLWRldkBs
aXN0cy5vemxhYnMub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgTGliZXJtYW4g
SWdhbC1CMzE5NTANCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gW3YyXSBwb3dlci9mc2w6IGFkZCBN
RElPIGR0IGJpbmRpbmcgZm9yIEZNYW4NCj4gDQo+IE9uIFR1ZSwgMjAxNC0xMi0yMyBhdCAwMToz
NSAtMDYwMCwgWGllIFNoYW9odWktQjIxOTg5IHdyb3RlOg0KPiA+ICstIGJ1cy1mcmVxdWVuY3kN
Cj4gPiArCQlVc2FnZTogb3B0aW9uYWwNCj4gPiArCQlWYWx1ZSB0eXBlOiA8dTMyPg0KPiA+ICsJ
CURlZmluaXRpb246IFNwZWNpZmllcyBleHRlcm5hbCBNRElPIGJ1cyBjbG9jayBzcGVlZCB3aGlj
aCBpcw0KPiA+ICsJCWRpZmZlcmVudCBmcm9tIE1ESU8gc3RhbmRhcmQgMi41TUh6LiBTaG91bGQg
YmUgZGVmaW5lZCBmb3INCj4gU29Dcw0KPiA+ICsJCW9uIHdoaWNoIHRoZSBzdGFuZGFyZCBvbmUg
Y2Fubm90IHdvcmsuDQo+ID4NCj4gPiBXaGF0IHNob3VsZCBJIHJlcGhyYXNlIGl0PyBSZXBsYWNl
IHRoZSBsYXN0IHNlbnRlbmNlIHdpdGggIlNob3VsZCBiZQ0KPiA+IGRlZmluZWQgRm9yIFNvQ3Mg
b24gd2hpY2ggYSBsb3dlciBmcmVxdWVuY3kgdGhhbiB0aGUgc3RhbmRhcmQgaXMNCj4gcmVxdWly
ZWQuIj8NCj4gDQo+IE5laXRoZXIgb2YgdGhlc2Ugd29yayB3aXRoIEVtaWwncyBzY2VuYXJpbyBv
ZiBhIHN5c3RlbSB0aGF0IGFsbG93cyBhDQo+IGZhc3Rlci10aGFuLXN0YW5kYXJkIHNwZWVkLg0K
PiANCj4gSG93IGFib3V0OiAiRGVmaW5pdGlvbjogU3BlY2lmaWVzIHRoZSBleHRlcm5hbCBNRElP
IGJ1cyBjbG9jayBzcGVlZCB0byBiZQ0KPiB1c2VkLCBpZiBkaWZmZXJlbnQgZnJvbSB0aGUgc3Rh
bmRhcmQgMi41IE1Iei4gIFRoaXMgbWF5IGJlIGR1ZSB0byB0aGUNCj4gc3RhbmRhcmQgc3BlZWQg
YmVpbmcgdW5zdXBwb3J0ZWQgKGUuZy4gZHVlIHRvIGEgaGFyZHdhcmUgcHJvYmxlbSksIG9yIHRv
DQo+IGFkdmVydGlzZSB0aGF0IGFsbCByZWxldmFudCBjb21wb25lbnRzIGluIHRoZSBzeXN0ZW0g
c3VwcG9ydCBhIGZhc3Rlcg0KPiBzcGVlZC4iDQpbUy5IXSBPSy4gSSdsbCB1c2UgdGhpcyBpbiBW
My4NCg0KPiANCj4gPiBIb3cgYWJvdXQgdGhlIHZhbHVlIHVzZWQgaW4gZXhhbXBsZT8NCj4gPiBT
aG91bGQgMi41TUh6IGJlIHVzZWQgb3IgYSBsb3dlciBvbmU/DQo+IA0KPiBJZiB5b3UgZG9uJ3Qg
aGF2ZSBhIHJlYWxpc3RpYyBleGFtcGxlIHRvIHVzZSwgZG9uJ3QgcHV0IGl0IGluIHRoZSBleGFt
cGxlDQo+IGF0IGFsbC4gIDIuNU1IeiBpcyB0aGUgd29yc3QgZXhhbXBsZSB0byB1c2UgYmVjYXVz
ZSB0aGF0J3MgdGhlIGRlZmF1bHQNCj4gYW5kIHRoZXJlJ2QgYmUgbm8gcmVhc29uIHRvIHVzZSB0
aGUgcHJvcGVydHkgYXQgYWxsLg0KW1MuSF0gT0suIFRoZSBWMyB3aWxsIG5vdCBoYXZlIHRoaXMg
aW4gZXhhbXBsZS4NCg0KVGhhbmsgeW91IGFsbCBmb3IgcmV2aWV3aW5nIQ0KU2hhb2h1aQ0K
^ permalink raw reply
* Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Scott Wood @ 2014-12-23 8:08 UTC (permalink / raw)
To: Xie Shaohui-B21989
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Medve Emilian-EMMEDVE1, Liberman Igal-B31950
In-Reply-To: <DM2PR0301MB08642FFDB6207DE205731547E2570@DM2PR0301MB0864.namprd03.prod.outlook.com>
On Tue, 2014-12-23 at 01:35 -0600, Xie Shaohui-B21989 wrote:
> +- bus-frequency
> + Usage: optional
> + Value type: <u32>
> + Definition: Specifies external MDIO bus clock speed which is
> + different from MDIO standard 2.5MHz. Should be defined for SoCs
> + on which the standard one cannot work.
>
> What should I rephrase it? Replace the last sentence with "Should be defined
> For SoCs on which a lower frequency than the standard is required."?
Neither of these work with Emil's scenario of a system that allows a
faster-than-standard speed.
How about: "Definition: Specifies the external MDIO bus clock speed to
be used, if different from the standard 2.5 MHz. This may be due to the
standard speed being unsupported (e.g. due to a hardware problem), or to
advertise that all relevant components in the system support a faster
speed."
> How about the value used in example?
> Should 2.5MHz be used or a lower one?
If you don't have a realistic example to use, don't put it in the
example at all. 2.5MHz is the worst example to use because that's the
default and there'd be no reason to use the property at all.
-Scott
^ permalink raw reply
* Re: Ask help about killing irqchip.irq_print_chip on PPC platforms
From: Scott Wood @ 2014-12-23 7:58 UTC (permalink / raw)
To: Jiang Liu
Cc: Tudor Laurentiu, Thomas Gleixner, linuxppc-dev,
Linux Kernel Mailing List
In-Reply-To: <5499204B.4040808@linux.intel.com>
On Tue, 2014-12-23 at 15:56 +0800, Jiang Liu wrote:
> Hi Scott and Tudor,
> Sorry, resend and Ccing the list.
Resending reply...
> We are trying to clean up some irqchip interfaces, and
> irqchip.irq_print_chip is a candidate for removal. After some
> changes on x86 side, arch/powerpc/sysdev/fsl_msi.c may be the
> last user of irqchip.irq_print_chip. So could you please help
> to advice on whether we could kill irqchip.irq_print_chip
> by using "fsl-msi" instead of "fsl-msi-%d" for irqchip name?
> Will it break any userspace interfaces?
> Thanks!
> Gerry
fsl-msi-%d was introduced to allow userspace to identify the cascade
interrupt belonging to a particular MSI, for the purpose of setting
affinity, as this cannot be done on the MSI itself due to hardware
limitations.
Removing it would not exactly eliminate a lot of code or complexity...
-Scott
^ permalink raw reply
* Ask help about killing irqchip.irq_print_chip on PPC platforms
From: Jiang Liu @ 2014-12-23 7:56 UTC (permalink / raw)
To: Tudor Laurentiu, Thomas Gleixner, Scott Wood
Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <54991DE5.5090805@linux.intel.com>
Hi Scott and Tudor,
Sorry, resend and Ccing the list.
We are trying to clean up some irqchip interfaces, and
irqchip.irq_print_chip is a candidate for removal. After some
changes on x86 side, arch/powerpc/sysdev/fsl_msi.c may be the
last user of irqchip.irq_print_chip. So could you please help
to advice on whether we could kill irqchip.irq_print_chip
by using "fsl-msi" instead of "fsl-msi-%d" for irqchip name?
Will it break any userspace interfaces?
Thanks!
Gerry
^ permalink raw reply
* RE: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
From: Dongsheng.Wang @ 2014-12-23 7:55 UTC (permalink / raw)
To: Dongsheng.Wang@freescale.com, Michael Ellerman
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org, anton@samba.org
In-Reply-To: <1419313550.30550.7.camel@ellerman.id.au>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2FuZyBEb25nc2hlbmct
QjQwNTM0DQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDI6NTMgUE0NCj4gVG86
ICdNaWNoYWVsIEVsbGVybWFuJw0KPiBDYzogYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBXb29k
IFNjb3R0LUIwNzQyMTsgYW50b25Ac2FtYmEub3JnOyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gcG93ZXJwYy9zbXA6IEZpeCBOb24tYm9v
dCBjcHVzIGNhbm5vdCBiZSBicmluZyB1cC4NCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1pY2hhZWwgRWxsZXJtYW4gW21haWx0bzptcGVAZWxs
ZXJtYW4uaWQuYXVdDQo+ID4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjMsIDIwMTQgMTo0NiBQ
TQ0KPiA+IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiBDYzogYmVuaEBrZXJuZWwuY3Jh
c2hpbmcub3JnOyBXb29kIFNjb3R0LUIwNzQyMTsgYW50b25Ac2FtYmEub3JnOw0KPiA+IGxpbnV4
cHBjLSBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2Vy
cGMvc21wOiBGaXggTm9uLWJvb3QgY3B1cyBjYW5ub3QgYmUgYnJpbmcgdXAuDQo+ID4NCj4gPiBP
biBUdWUsIDIwMTQtMTItMjMgYXQgMDI6NDEgKzAwMDAsIERvbmdzaGVuZy5XYW5nQGZyZWVzY2Fs
ZS5jb20gd3JvdGU6DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+
IEZyb206IE1pY2hhZWwgRWxsZXJtYW4gW21haWx0bzptcGVAZWxsZXJtYW4uaWQuYXVdDQo+ID4g
PiA+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDk6MDEgQU0NCj4gPiA+ID4gVG86
IFdhbmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiA+ID4gPiBDYzogYmVuaEBrZXJuZWwuY3Jhc2hpbmcu
b3JnOyBXb29kIFNjb3R0LUIwNzQyMTsgYW50b25Ac2FtYmEub3JnOw0KPiA+ID4gPiBsaW51eHBw
Yy0gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSF0gcG93
ZXJwYy9zbXA6IEZpeCBOb24tYm9vdCBjcHVzIGNhbm5vdCBiZSBicmluZyB1cC4NCj4gPiA+ID4N
Cj4gPiA+ID4gT24gTW9uLCAyMDE0LTEyLTIyIGF0IDE0OjM4ICswODAwLCBEb25nc2hlbmcgV2Fu
ZyB3cm90ZToNCj4gPiA+ID4gPiBGcm9tOiBXYW5nIERvbmdzaGVuZyA8ZG9uZ3NoZW5nLndhbmdA
ZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEtlcm5lbCBjYW5ub3QgYnJpbmcg
dXAgTm9uLWJvb3QgY3B1cyBhbHdheXMgZ2V0ICJQcm9jZXNzb3IgeHggaXMgc3R1Y2siLg0KPiA+
ID4gPiA+IHRoaXMgaXNzdWUgYnJpbmcgYnkgaHR0cDovL3BhdGNod29yay5vemxhYnMub3JnL3Bh
dGNoLzQxODkxMi8gKHBvd2VycGM6DQo+ID4gPiA+ID4gU2Vjb25kYXJ5IENQVXMgbXVzdCBzZXQg
Y3B1X2NhbGxpbl9tYXAgYWZ0ZXIgc2V0dGluZyBhY3RpdmUgYW5kDQo+ID4gPiA+ID4gb25saW5l
KSBXZSBuZWVkIHRvIHRha2UgdGltZWJhc2UgYWZ0ZXIgYm9vdHVwIGNwdSBnaXZlIHRoZQ0KPiA+
ID4gPiA+IHRpbWViYXNlDQo+ID4gZmlyc3RseS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdoZW4g
c3RhcnRfc2Vjb25kYXJ5LCBub24tYm9vdCBjcHVzIHNldCBjcHVfY2FsbGluX21hcCBmb3IgYm9v
dA0KPiA+ID4gPiA+IGNwdSBhZnRlciB0aGF0IGJvb3QgY3B1IHdpbGwgZ2l2ZSB0aGUgdGltZWJh
c2UgZm9yIG5vbi1ib290IGNwdS4NCj4gPiA+ID4gPiBPdGhlcndpc2Ugbm9uLWJvb3QgY3B1cyB3
aWxsIGZhbGwgaW4gZGVhZCBsb29wIHRvIHdhaXRpbmcgYm9vdHVwDQo+ID4gPiA+ID4gY3B1IHRv
IGdpdmUgaW1lYmFzZS4NCj4gPiA+ID4NCj4gPiA+ID4gUmlnaHQuDQo+ID4gPiA+DQo+ID4gPiA+
IEhvd2V2ZXIsIGRvZXNuJ3QgdGhpcyBpbnRyb2R1Y2UgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhl
IHNlY29uZGFyeQ0KPiA+ID4gPiBjcHUgaXMgdXAgYW5kIG1hcmtlZCBvbmxpbmUgYnV0IGhhcyBh
biB1bnN5bmNocm9uaXNlZCBjbG9jaz8NCj4gPg0KPiA+ID4gWWVzLCByaWdodC4gQnV0IEZyZWVz
Y2FsZSBwbGF0Zm9ybSBib290LWNwdSB3aWxsIGZyZWV6ZSB0aGUgVEIgdW50aWwNCj4gPiA+IHNl
Y29uZGFyeSBjcHUgdGFrZSB0aGUgdGltZSBiYXNlLCBzbyB0aGUgY2xvY2sgaXMgc3luY2hyb25p
emVkLg0KPiA+DQo+ID4gSXQgZG9lcyB0aGUgZnJlZXplIGluIGdpdmVfdGltZWJhc2UoKSBkb2Vz
bid0IGl0Pw0KPiA+DQo+ID4gU28gdGhlcmUncyBzdGlsbCBhIHdpbmRvdyB0aGVyZSB3aGVyZSB0
aGUgc2Vjb25kYXJ5IGlzIHVwICYgb25saW5lIGJ1dA0KPiA+IGhhc24ndCBoYWQgaXQncyB0aW1l
YmFzZSBzeW5jaHJvbmlzZWQsIGFuZCB0aGUgcHJpbWFyeSBoYXNuJ3QgZnJvemVuIHRoZQ0KPiB0
aW1lYmFzZSB5ZXQuDQo+ID4gU28gdGhhdCBtYWtlcyBtZSBuZXJ2b3VzLg0KPiA+DQo+ID4gPiBG
b3IgZ2VuZXJpYyBQb3dlclBDIG1heWJlIGhhcyB0aGlzIGlzc3VlLiBTbyBmb3Igc2FmZSBJIHRo
aW5rIHdlDQo+ID4gPiBuZWVkIHRvIHNldCBjcHUgb25saW5lIGFmdGVyIHN5bmNocm9uaXplZCBj
bG9jay4NCj4gPiA+DQo+ID4gPiBJIHdpbGwgdXBkYXRlIG15IHBhdGNoIGlmIHlvdSBhZ3JlZSB0
aGlzIHdheS4NCj4gPiA+ICsgICAgICAgaWYgKHNtcF9vcHMtPnRha2VfdGltZWJhc2UpDQo+ID4g
PiArICAgICAgICAgICAgICAgc21wX29wcy0+dGFrZV90aW1lYmFzZSgpOw0KPiA+ID4gKyAgICAg
ICBzZWNvbmRhcnlfY3B1X3RpbWVfaW5pdCgpOw0KPiA+ID4gKw0KPiA+ID4gTW92ZSBzZXRfY3B1
X29ubGluZSB0byBoZXJlLg0KPiA+ID4gKyAgICAgICBzZXRfY3B1X29ubGluZShjcHUsIHRydWUp
Ow0KPiA+DQo+ID4gQnV0IHRoYXQgcmV2ZXJzZXMgdGhlIGVmZmVjdCBvZiB0aGUgb3JpZ2luYWwg
cGF0Y2gsIHdoaWNoIHdhcyB0aGF0IHdlDQo+ID4gaGF2ZSB0byBzZXQgb25saW5lICpiZWZvcmUq
IHdlIHNldCB0aGUgY2FsbGluIG1hcC4NCj4gPg0KPiA+DQo+ID4gTG9va2luZyBoYXJkZXIgYXQg
QW50b24ncyBwYXRjaCBJJ20gbm90IHN1cmUgaXQncyByaWdodCBhbnl3YXkuDQo+ID4NCj4gPiBU
aGUgaXNzdWUgaGUgd2FzIHRyeWluZyB0byBmaXggd2FzIHRoYXQgdGhlIGNwdSB3YXMgb25saW5l
IGJ1dCBub3QNCj4gPiBhY3RpdmUsIHdoaWNoIGNvbmZ1c2VkIHRoZSBzY2hlZHVsZXIuDQo+ID4N
Cj4gPiBJIHRoaW5rIEFudG9uIG1pc3NlZCB0aGF0IHdlIGhhdmUgYSBsb29wIHRoYXQgd2FpdHMg
Zm9yIG9ubGluZSBhdCB0aGUNCj4gPiBib3R0b20gb2YNCj4gPiBfX2NwdV91cCgpOg0KPiA+DQo+
ID4gCS8qIFdhaXQgdW50aWwgY3B1IHB1dHMgaXRzZWxmIGluIHRoZSBvbmxpbmUgbWFwICovDQo+
ID4gCXdoaWxlICghY3B1X29ubGluZShjcHUpKQ0KPiA+IAkJY3B1X3JlbGF4KCk7DQo+ID4NCj4g
Pg0KPiA+IEhlIG11c3QgaGF2ZSBzZWVuIGEgY2FzZSB3aGVyZSB0aGF0IHBvcHBlZCBkdWUgdG8g
dGhlIGNwdSBiZWluZw0KPiA+IG9ubGluZSwgYnV0IHRoZSBjcHUgd2Fzbid0IHlldCBhY3RpdmUu
DQo+ID4NCj4gPiBIaXMgcGF0Y2ggZml4ZWQgdGhlIHByb2JsZW0gYnkgZW5zdXJpbmcgdGhlIHBy
ZXZpb3VzIGxvb3AgdGhhdCB3YWl0cw0KPiA+IGZvciBjcHVfY2FsbGluX21hcCBkb2Vzbid0IGZp
bmlzaCB1bnRpbCBhY3RpdmUgJiBvbmxpbmUgYXJlIHNldCwNCj4gPiBtYWtpbmcgdGhlIHdoaWxl
IGxvb3AgYWJvdmUgYSBub3AuDQo+ID4NCj4gPiBTbyBJIHRoaW5rIHdlIHNob3VsZCBwcm9iYWJs
eSByZXZlcnQgQW50b24ncyBwYXRjaCBhbmQgaW5zdGVhZCBjaGFuZ2UNCj4gPiB0aGF0IHdoaWxl
IGxvb3AgdG86DQo+ID4NCj4gPiAJLyogV2FpdCB1bnRpbCBjcHUgaXMgb25saW5lIEFORCBhY3Rp
dmUgKi8NCj4gPiAJd2hpbGUgKCFjcHVfb25saW5lKGNwdSkgfHwgIWNwdV9hY3RpdmUoY3B1KSkN
Cj4gPiAJCWNwdV9yZWxheCgpOw0KPiA+DQoNCkJhc2Ugb24gQW50b24ncyBwYXRjaCwgd2Ugc2hv
dWxkIHByb2JhYmx5IGNoYW5nZSBfX2N1cF91cC4NClBsZWFzZSBjb21tZW50IHRoZSBjaGFuZ2Vz
Lg0KLS0tIGEvYXJjaC9wb3dlcnBjL2tlcm5lbC9zbXAuYw0KKysrIGIvYXJjaC9wb3dlcnBjL2tl
cm5lbC9zbXAuYw0KQEAgLTUyOCwxMiArNTI4LDEwIEBAIGludCBfX2NwdV91cCh1bnNpZ25lZCBp
bnQgY3B1LCBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnRpZGxlKQ0KICAgICAgICB9DQoNCiAgICAgICAg
LyoNCi0gICAgICAgICogd2FpdCB0byBzZWUgaWYgdGhlIGNwdSBtYWRlIGEgY2FsbGluIChpcyBh
Y3R1YWxseSB1cCkuDQotICAgICAgICAqIHVzZSB0aGlzIHZhbHVlIHRoYXQgSSBmb3VuZCB0aHJv
dWdoIGV4cGVyaW1lbnRhdGlvbi4NCi0gICAgICAgICogLS0gQ29ydA0KKyAgICAgICAgKiBXYWl0
IHVudGlsIGNwdSBwdXRzIGl0c2VsZiBpbiB0aGUgb25saW5lIG1hcA0KICAgICAgICAgKi8NCiAg
ICAgICAgaWYgKHN5c3RlbV9zdGF0ZSA8IFNZU1RFTV9SVU5OSU5HKQ0KLSAgICAgICAgICAgICAg
IGZvciAoYyA9IDUwMDAwOyBjICYmICFjcHVfY2FsbGluX21hcFtjcHVdOyBjLS0pDQorICAgICAg
ICAgICAgICAgZm9yIChjID0gNTAwMDA7IGMgJiYgIWNwdV9vbmxpbmUoY3B1KTsgYy0tKQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgdWRlbGF5KDEwMCk7DQogI2lmZGVmIENPTkZJR19IT1RQTFVH
X0NQVQ0KICAgICAgICBlbHNlDQpAQCAtNTQxLDExICs1MzksMTAgQEAgaW50IF9fY3B1X3VwKHVu
c2lnbmVkIGludCBjcHUsIHN0cnVjdCB0YXNrX3N0cnVjdCAqdGlkbGUpDQogICAgICAgICAgICAg
ICAgICogQ1BVcyBjYW4gdGFrZSBtdWNoIGxvbmdlciB0byBjb21lIHVwIGluIHRoZQ0KICAgICAg
ICAgICAgICAgICAqIGhvdHBsdWcgY2FzZS4gIFdhaXQgZml2ZSBzZWNvbmRzLg0KICAgICAgICAg
ICAgICAgICAqLw0KLSAgICAgICAgICAgICAgIGZvciAoYyA9IDUwMDA7IGMgJiYgIWNwdV9jYWxs
aW5fbWFwW2NwdV07IGMtLSkNCisgICAgICAgICAgICAgICBmb3IgKGMgPSA1MDAwOyBjICYmICFj
cHVfb25saW5lKGNwdSk7IGMtLSkNCiAgICAgICAgICAgICAgICAgICAgICAgIG1zbGVlcCgxKTsN
CiAjZW5kaWYNCi0NCi0gICAgICAgaWYgKCFjcHVfY2FsbGluX21hcFtjcHVdKSB7DQorICAgICAg
IGlmICghY3B1X29ubGluZShjcHUpKSB7DQogICAgICAgICAgICAgICAgcHJpbnRrKEtFUk5fRVJS
ICJQcm9jZXNzb3IgJXUgaXMgc3R1Y2suXG4iLCBjcHUpOw0KICAgICAgICAgICAgICAgIHJldHVy
biAtRU5PRU5UOw0KICAgICAgICB9DQpAQCAtNTU1LDggKzU1Miw4IEBAIGludCBfX2NwdV91cCh1
bnNpZ25lZCBpbnQgY3B1LCBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnRpZGxlKQ0KICAgICAgICBpZiAo
c21wX29wcy0+Z2l2ZV90aW1lYmFzZSkNCiAgICAgICAgICAgICAgICBzbXBfb3BzLT5naXZlX3Rp
bWViYXNlKCk7DQoNCi0gICAgICAgLyogV2FpdCB1bnRpbCBjcHUgcHV0cyBpdHNlbGYgaW4gdGhl
IG9ubGluZSBtYXAgKi8NCi0gICAgICAgd2hpbGUgKCFjcHVfb25saW5lKGNwdSkpDQorICAgICAg
IC8qIFdhaXQgdW50aWwgY3B1IHN5bmNocm9uaXplZCBjbG9jayAqLw0KKyAgICAgICB3aGlsZSAo
IWNwdV9jYWxsaW5fbWFwW2NwdV0pDQogICAgICAgICAgICAgICAgY3B1X3JlbGF4KCk7DQoNCiAg
ICAgICAgcmV0dXJuIDA7DQpAQCAtNzAzLDEwICs3MDAsNiBAQCB2b2lkIHN0YXJ0X3NlY29uZGFy
eSh2b2lkICp1bnVzZWQpDQoNCiAgICAgICAgaWYgKHNtcF9vcHMtPnNldHVwX2NwdSkNCiAgICAg
ICAgICAgICAgICBzbXBfb3BzLT5zZXR1cF9jcHUoY3B1KTsNCi0gICAgICAgaWYgKHNtcF9vcHMt
PnRha2VfdGltZWJhc2UpDQotICAgICAgICAgICAgICAgc21wX29wcy0+dGFrZV90aW1lYmFzZSgp
Ow0KLQ0KLSAgICAgICBzZWNvbmRhcnlfY3B1X3RpbWVfaW5pdCgpOw0KDQogI2lmZGVmIENPTkZJ
R19QUEM2NA0KICAgICAgICBpZiAoc3lzdGVtX3N0YXRlID09IFNZU1RFTV9SVU5OSU5HKQ0KQEAg
LTczOCw2ICs3MzEsMTAgQEAgdm9pZCBzdGFydF9zZWNvbmRhcnkodm9pZCAqdW51c2VkKQ0KICAg
ICAgICBub3RpZnlfY3B1X3N0YXJ0aW5nKGNwdSk7DQogICAgICAgIHNldF9jcHVfb25saW5lKGNw
dSwgdHJ1ZSk7DQoNCisgICAgICAgaWYgKHNtcF9vcHMtPnRha2VfdGltZWJhc2UpDQorICAgICAg
ICAgICAgICAgc21wX29wcy0+dGFrZV90aW1lYmFzZSgpOw0KKw0KKyAgICAgICBzZWNvbmRhcnlf
Y3B1X3RpbWVfaW5pdCgpOw0KICAgICAgICAvKg0KICAgICAgICAgKiBDUFUgbXVzdCBiZSBtYXJr
ZWQgYWN0aXZlIGFuZCBvbmxpbmUgYmVmb3JlIHdlIHNpZ25hbCBiYWNrIHRvIHRoZQ0KICAgICAg
ICAgKiBtYXN0ZXIsIGJlY2F1c2UgdGhlIHNjaGVkdWxlciBuZWVkcyB0byBzZWUgdGhlIGNwdV9v
bmxpbmUgYW5kDQoNClJlZ2FyZHMsDQotRG9uZ3NoZW5nDQoNCj4gVW1tLi4gU29ycnkgYWJvdXQg
dGhhdC4uLkkgZm9yZ290IEFudG9uJ3MgcGF0Y2guDQo+IA0KPiBCdXQgc2V0X2NwdV9vbmxpbmUg
YWxzbyBzZXQgY3B1X2FjdGl2ZV9iaXRzLCBJIHRoaW5rIHRoaXMganVkZ21lbnQgY2Fubm90IGZp
eA0KPiBBbnRvbidzIGlzc3VlLg0KPiBJdCBpcyBhY3R1YWxseSB0aGUgZWZmZWN0cyBvZiB0aGUg
b3JpZ2luYWwgaXMgdGhlIHNhbWUuDQo+IA0KPiBSZWdyYWRzLA0KPiAtRG9uZ3NoZW5nDQoNCg==
^ permalink raw reply
* RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Shaohui Xie @ 2014-12-23 7:35 UTC (permalink / raw)
To: Scott Wood, Emilian Medve
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Igal.Liberman@freescale.com
In-Reply-To: <1419283551.5581.172.camel@freescale.com>
DQoNCkJlc3QgUmVnYXJkcywgDQpTaGFvaHVpIFhpZQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gU2VudDogVHVlc2RheSwgRGVj
ZW1iZXIgMjMsIDIwMTQgNToyNiBBTQ0KPiBUbzogTWVkdmUgRW1pbGlhbi1FTU1FRFZFMQ0KPiBD
YzogWGllIFNoYW9odWktQjIxOTg5OyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4g
ZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IExpYmVybWFuIElnYWwtQjMxOTUwDQo+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0hdIFt2Ml0gcG93ZXIvZnNsOiBhZGQgTURJTyBkdCBiaW5kaW5nIGZvciBG
TWFuDQo+IA0KPiBPbiBNb24sIDIwMTQtMTItMjIgYXQgMDU6MDggLTA2MDAsIEVtaWwgTWVkdmUg
d3JvdGU6DQo+ID4gSGVsbG8gU2NvdHQsDQo+ID4NCj4gPg0KPiA+IE9uIDEyLzIyLzIwMTQgMDM6
NDIgQU0sIFNjb3R0IFdvb2Qgd3JvdGU6DQo+ID4gPiBPbiBNb24sIDIwMTQtMTItMjIgYXQgMDM6
MzcgLTA2MDAsIEVtaWwgTWVkdmUgd3JvdGU6DQo+ID4gPj4gSGVsbG8gU2NvdHQsDQo+ID4gPj4N
Cj4gPiA+Pg0KPiA+ID4+IE9uIDEyLzIyLzIwMTQgMDI6MzIgQU0sIFNjb3R0IFdvb2Qgd3JvdGU6
DQo+ID4gPj4+IE9uIE1vbiwgMjAxNC0xMi0yMiBhdCAwMjoyMCAtMDYwMCwgRW1pbCBNZWR2ZSB3
cm90ZToNCj4gPiA+Pj4+IEZvciB0aGUgcHVycG9zZSBvZiBhbiBleGFtcGxlIGluIHRoZSBiaW5k
aW5nIGRvY3VtZW50LCBJIHN1Z2dlc3QNCj4gPiA+Pj4+IHdlIGp1c3Qgc3RpY2sgd2l0aCB0aGUg
SUVFRSBzdGFuZGFyZCBmcmVxdWVuY3kuDQo+ID4gPj4+DQo+ID4gPj4+IFRoZSB3aG9sZSByZWFz
b24gZm9yIHRoaXMgcHJvcGVydHkgZXhpc3RpbmcgaW4gdGhlIGRldmljZSB0cmVlIGlzDQo+ID4g
Pj4+IG5vbi1zdGFuZGFyZCBmcmVxdWVuY2llcy4NCj4gPiA+Pg0KPiA+ID4+IFdoaWxlIHRoZSBz
dGFuZGFyZCBjbGFpbXMgMi41IE1IeiwgbW9zdCBNRElPIGNvbnRyb2xsZXJzIGFuZCBQSFkNCj4g
PiA+PiBkZXZpY2VzIHN1cHBvcnQgZnJlcXVlbmNpZXMgd2VsbCBiZXlvbmQgdGhlIHN0YW5kYXJk
LiBTcGVjaWZ5aW5nIGENCj4gPiA+PiBsb3dlciB0aGVuIHRoZSBzdGFuZGFyZCBmcmVxdWVuY3kg
Zm9yIHRoZSBiZW5lZml0IG9mIHNvbWUgZXJyYXRhIGlzDQo+ID4gPj4ganVzdCBvbmUgc2lkZSBv
ZiB0aGlzIHByb3BlcnR5DQo+ID4gPg0KPiA+ID4gVGhlIGVycmF0dW0gd2FzICh1bnRpbCBub3cp
IHRoZSBvbmx5IGNsYWltZWQgcmVhc29uIGZvciBpdC4gIElmDQo+ID4gPiB0aGVyZSBhcmUgb3Ro
ZXIgcmVhc29ucyB3aHkgb25lIHdvdWxkIHNwZWNpZnkgYSBkaWZmZXJlbnQgZnJlcXVlbmN5DQo+
ID4gPiAoaW4gcGFydGljdWxhciwgdGhhdCByZWxhdGUgdG8gaGFyZHdhcmUgZGVzY3JpcHRpb24p
LCBwbGVhc2UNCj4gZWxhYm9yYXRlLg0KPiA+DQo+ID4gRnJvbSBtZW1vcnksIHRoZSAxIEdiL3Mg
Vml0ZXNzZSBQSFkocykgd2UgaGF2ZSBvbiBzb21lIG9mIG91ciBEUw0KPiA+IGJvYXJkcyBzdXBw
b3J0IDEyLjUgTUh6LiBJIGNhbiBkaWcgb3V0IG1vcmUgc3BlY3MgZm9yIHNwZWNpZmljcyBvbg0K
PiA+IG90aGVyIFBIWShzKQ0KPiA+DQo+ID4gMi41IE1IeiBpcyBzbG93IGFuZCBldmVuIG1vcmUg
c28gZm9yIGhpZ2ggc3BlZWQgaW50ZXJmYWNlcy4gV2l0aCBib3RoDQo+ID4gcG9sbGluZyBhbmQg
aW50ZXJydXB0cyAoYm90aCBNRElPIGFuZC9vciBQSFkpIHdlJ3ZlIG5vdGljZWQgKG9yDQo+ID4g
YmxhbWVkKSBpbiB0aGUgcGFzdCBzb21lIEV0aGVybmV0IHBlcmZvcm1hbmNlIGlzc3VlcyBvbiB0
aGlzIHZlcnkNCj4gPiBzbG93bmVzcw0KPiA+DQo+ID4gQXMgb2YgcmlnaHQgbm93IEknbSBub3Qg
YXdhcmUgb2YgYW5vdGhlciB3YXkgdG8gc3BlY2lmeS9jb29yZGluYXRlIHRoZQ0KPiA+IE1EQyBz
cGVlZCBzbyBzZXR0aW5nIGEgZGVmYXVsdCAoY29tbW9uIGRlbm9taW5hdG9yKSBpbiB0aGUgRFQg
dGhhdCBpcw0KPiA+IGRpZmZlcmVudCB0aGVuIHRoZSBJRUVFIHN0YW5kYXJkIHNlZW1zIG9rDQo+
ID4NCj4gPiA+Pj4+IFdlIGNhbiBjb250aW51ZSB0aGlzIGNvbnZlcnNhdGlvbiBhYm91dCBlcnJh
dGEgaGFuZGxpbmcgd2hlbiB3ZQ0KPiA+ID4+Pj4gc3VibWl0IHRoZSBjb2RlIHJlbGV2YW50IHRv
IHRoaXMgYmluZGluZyAoYW5kIHRoZSBGTWFuIHYzDQo+ID4gPj4+PiBzdXBwb3J0KQ0KPiA+ID4+
Pg0KPiA+ID4+PiBJdCBhZmZlY3RzIHRoZSBiaW5kaW5nLCBzbyBsZXQncyBkaXNjdXNzIGl0IG5v
dyBwbGVhc2UuDQo+ID4gPj4NCj4gPiA+PiBJIHRoaW5rIHRoaXMgc3BlY2lmaWMgKHVucHVibGlz
aGVkIHlldCkgZXJyYXRhIGhhcyBsZXNzIGJlYXJpbmcgb24NCj4gPiA+PiB0aGUgYmluZGluZyB0
aGVuIHlvdSBtaWdodCBiZWxpZXZlLiBUaGlzIGlzIG1vc3RseSBhYm91dCBwcm92aWRpbmcNCj4g
PiA+PiBhIGNvbW1vbi9kZWZhdWx0IGZyZXF1ZW5jeSBzdXBwb3J0ZWQgYnkgYWxsIHRoZSBkZXZp
Y2VzIG9uIHNvbWUNCj4gPiA+PiBib2FyZA0KPiA+ID4NCj4gPiA+IFdoYXQgcmVhc29uIG90aGVy
IHRoYW4gYW4gZXJyYXR1bSB3b3VsZCB0aGVyZSBiZSBmb3IgdGhlIHN0YW5kYXJkDQo+ID4gPiBm
cmVxdWVuY3kgbm90IGJlaW5nIHN1cHBvcnRlZD8NCj4gPg0KPiA+IFRoaXMgaXMgbm90IGFib3V0
IG5vdCBzdXBwb3J0aW5nIHRoZSBzdGFuZGFyZCBmcmVxdWVuY3kuIFRoaXMgaXMgYWJvdXQNCj4g
PiB0aGUgZGVmYXVsdCBmcmVxdWVuY3kgYmVpbmcgZGlmZmVyZW50IHRoZW4gdGhlIHN0YW5kYXJk
DQo+IA0KPiBPSywgdGhvdWdoIHJhdGhlciB0aGFuIHRhbGsgYWJvdXQgZGVmYXVsdHMgSSdkIHBo
cmFzZSBpdCBhcyBpbmRpY2F0aW5nDQo+IHRoYXQgYSBoaWdoZXIgZnJlcXVlbmN5IHRoYW4gc3Rh
bmRhcmQgaXMgc3VwcG9ydGVkLCBvciB0aGF0IGEgbG93ZXINCj4gZnJlcXVlbmN5IHRoYW4gc3Rh
bmRhcmQgaXMgcmVxdWlyZWQuDQpbUy5IXSBiZWxvdyBpcyB0aGUgc3RhdGVtZW50IGluIHYyOg0K
DQorLSBidXMtZnJlcXVlbmN5DQorCQlVc2FnZTogb3B0aW9uYWwNCisJCVZhbHVlIHR5cGU6IDx1
MzI+DQorCQlEZWZpbml0aW9uOiBTcGVjaWZpZXMgZXh0ZXJuYWwgTURJTyBidXMgY2xvY2sgc3Bl
ZWQgd2hpY2ggaXMNCisJCWRpZmZlcmVudCBmcm9tIE1ESU8gc3RhbmRhcmQgMi41TUh6LiBTaG91
bGQgYmUgZGVmaW5lZCBmb3IgU29Dcw0KKwkJb24gd2hpY2ggdGhlIHN0YW5kYXJkIG9uZSBjYW5u
b3Qgd29yay4NCg0KV2hhdCBzaG91bGQgSSByZXBocmFzZSBpdD8gUmVwbGFjZSB0aGUgbGFzdCBz
ZW50ZW5jZSB3aXRoICJTaG91bGQgYmUgZGVmaW5lZA0KRm9yIFNvQ3Mgb24gd2hpY2ggYSBsb3dl
ciBmcmVxdWVuY3kgdGhhbiB0aGUgc3RhbmRhcmQgaXMgcmVxdWlyZWQuIj8NCg0KSG93IGFib3V0
IHRoZSB2YWx1ZSB1c2VkIGluIGV4YW1wbGU/DQpTaG91bGQgMi41TUh6IGJlIHVzZWQgb3IgYSBs
b3dlciBvbmU/DQoNClRoYW5rcyENClNoYW9odWkNCg==
^ permalink raw reply
* [PATCH] powerpc/kvm: Create proper names for the kvm_host_state PMU fields
From: Michael Ellerman @ 2014-12-23 7:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: agraf
In-Reply-To: <53BE67EA.8000206@suse.de>
We have two arrays in kvm_host_state that contain register values for
the PMU. Currently we only create an asm-offsets symbol for the base of
the arrays, and do the array offset in the assembly code.
Creating an asm-offsets symbol for each field individually makes the
code much nicer to read, particularly for the MMCRx/SIxR/SDAR fields, and
might have helped us notice the recent double restore bug we had in this
code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kernel/asm-offsets.c | 15 +++++++++++++--
arch/powerpc/kvm/book3s_hv_interrupts.S | 26 +++++++++++++-------------
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 28 ++++++++++++++--------------
3 files changed, 40 insertions(+), 29 deletions(-)
Looks like this fell through the cracks between the powerpc & kvm trees.
It needed a rework to go on top of the 970 HV removal, this is the result. I'll
put it in the powerpc tree.
cheers
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index e624f9646350..4717859fdd04 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -644,8 +644,19 @@ int main(void)
HSTATE_FIELD(HSTATE_SAVED_XIRR, saved_xirr);
HSTATE_FIELD(HSTATE_HOST_IPI, host_ipi);
HSTATE_FIELD(HSTATE_PTID, ptid);
- HSTATE_FIELD(HSTATE_MMCR, host_mmcr);
- HSTATE_FIELD(HSTATE_PMC, host_pmc);
+ HSTATE_FIELD(HSTATE_MMCR0, host_mmcr[0]);
+ HSTATE_FIELD(HSTATE_MMCR1, host_mmcr[1]);
+ HSTATE_FIELD(HSTATE_MMCRA, host_mmcr[2]);
+ HSTATE_FIELD(HSTATE_SIAR, host_mmcr[3]);
+ HSTATE_FIELD(HSTATE_SDAR, host_mmcr[4]);
+ HSTATE_FIELD(HSTATE_MMCR2, host_mmcr[5]);
+ HSTATE_FIELD(HSTATE_SIER, host_mmcr[6]);
+ HSTATE_FIELD(HSTATE_PMC1, host_pmc[0]);
+ HSTATE_FIELD(HSTATE_PMC2, host_pmc[1]);
+ HSTATE_FIELD(HSTATE_PMC3, host_pmc[2]);
+ HSTATE_FIELD(HSTATE_PMC4, host_pmc[3]);
+ HSTATE_FIELD(HSTATE_PMC5, host_pmc[4]);
+ HSTATE_FIELD(HSTATE_PMC6, host_pmc[5]);
HSTATE_FIELD(HSTATE_PURR, host_purr);
HSTATE_FIELD(HSTATE_SPURR, host_spurr);
HSTATE_FIELD(HSTATE_DSCR, host_dscr);
diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S b/arch/powerpc/kvm/book3s_hv_interrupts.S
index 36540a99d178..0fdc4a28970b 100644
--- a/arch/powerpc/kvm/book3s_hv_interrupts.S
+++ b/arch/powerpc/kvm/book3s_hv_interrupts.S
@@ -93,15 +93,15 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mfspr r5, SPRN_MMCR1
mfspr r9, SPRN_SIAR
mfspr r10, SPRN_SDAR
- std r7, HSTATE_MMCR(r13)
- std r5, HSTATE_MMCR + 8(r13)
- std r6, HSTATE_MMCR + 16(r13)
- std r9, HSTATE_MMCR + 24(r13)
- std r10, HSTATE_MMCR + 32(r13)
+ std r7, HSTATE_MMCR0(r13)
+ std r5, HSTATE_MMCR1(r13)
+ std r6, HSTATE_MMCRA(r13)
+ std r9, HSTATE_SIAR(r13)
+ std r10, HSTATE_SDAR(r13)
BEGIN_FTR_SECTION
mfspr r9, SPRN_SIER
- std r8, HSTATE_MMCR + 40(r13)
- std r9, HSTATE_MMCR + 48(r13)
+ std r8, HSTATE_MMCR2(r13)
+ std r9, HSTATE_SIER(r13)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mfspr r3, SPRN_PMC1
mfspr r5, SPRN_PMC2
@@ -109,12 +109,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mfspr r7, SPRN_PMC4
mfspr r8, SPRN_PMC5
mfspr r9, SPRN_PMC6
- stw r3, HSTATE_PMC(r13)
- stw r5, HSTATE_PMC + 4(r13)
- stw r6, HSTATE_PMC + 8(r13)
- stw r7, HSTATE_PMC + 12(r13)
- stw r8, HSTATE_PMC + 16(r13)
- stw r9, HSTATE_PMC + 20(r13)
+ stw r3, HSTATE_PMC1(r13)
+ stw r5, HSTATE_PMC2(r13)
+ stw r6, HSTATE_PMC3(r13)
+ stw r7, HSTATE_PMC4(r13)
+ stw r8, HSTATE_PMC5(r13)
+ stw r9, HSTATE_PMC6(r13)
31:
/*
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 10554df13852..bb94e6f20c81 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -83,35 +83,35 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
cmpwi r4, 0
beq 23f /* skip if not */
BEGIN_FTR_SECTION
- ld r3, HSTATE_MMCR(r13)
+ ld r3, HSTATE_MMCR0(r13)
andi. r4, r3, MMCR0_PMAO_SYNC | MMCR0_PMAO
cmpwi r4, MMCR0_PMAO
beql kvmppc_fix_pmao
END_FTR_SECTION_IFSET(CPU_FTR_PMAO_BUG)
- lwz r3, HSTATE_PMC(r13)
- lwz r4, HSTATE_PMC + 4(r13)
- lwz r5, HSTATE_PMC + 8(r13)
- lwz r6, HSTATE_PMC + 12(r13)
- lwz r8, HSTATE_PMC + 16(r13)
- lwz r9, HSTATE_PMC + 20(r13)
+ lwz r3, HSTATE_PMC1(r13)
+ lwz r4, HSTATE_PMC2(r13)
+ lwz r5, HSTATE_PMC3(r13)
+ lwz r6, HSTATE_PMC4(r13)
+ lwz r8, HSTATE_PMC5(r13)
+ lwz r9, HSTATE_PMC6(r13)
mtspr SPRN_PMC1, r3
mtspr SPRN_PMC2, r4
mtspr SPRN_PMC3, r5
mtspr SPRN_PMC4, r6
mtspr SPRN_PMC5, r8
mtspr SPRN_PMC6, r9
- ld r3, HSTATE_MMCR(r13)
- ld r4, HSTATE_MMCR + 8(r13)
- ld r5, HSTATE_MMCR + 16(r13)
- ld r6, HSTATE_MMCR + 24(r13)
- ld r7, HSTATE_MMCR + 32(r13)
+ ld r3, HSTATE_MMCR0(r13)
+ ld r4, HSTATE_MMCR1(r13)
+ ld r5, HSTATE_MMCRA(r13)
+ ld r6, HSTATE_SIAR(r13)
+ ld r7, HSTATE_SDAR(r13)
mtspr SPRN_MMCR1, r4
mtspr SPRN_MMCRA, r5
mtspr SPRN_SIAR, r6
mtspr SPRN_SDAR, r7
BEGIN_FTR_SECTION
- ld r8, HSTATE_MMCR + 40(r13)
- ld r9, HSTATE_MMCR + 48(r13)
+ ld r8, HSTATE_MMCR2(r13)
+ ld r9, HSTATE_SIER(r13)
mtspr SPRN_MMCR2, r8
mtspr SPRN_SIER, r9
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
--
2.1.0
^ permalink raw reply related
* RE: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
From: Dongsheng.Wang @ 2014-12-23 6:53 UTC (permalink / raw)
To: Michael Ellerman
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org, anton@samba.org
In-Reply-To: <1419313550.30550.7.camel@ellerman.id.au>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWljaGFlbCBFbGxlcm1h
biBbbWFpbHRvOm1wZUBlbGxlcm1hbi5pZC5hdV0NCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIg
MjMsIDIwMTQgMTo0NiBQTQ0KPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0DQo+IENjOiBiZW5o
QGtlcm5lbC5jcmFzaGluZy5vcmc7IFdvb2QgU2NvdHQtQjA3NDIxOyBhbnRvbkBzYW1iYS5vcmc7
IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENI
XSBwb3dlcnBjL3NtcDogRml4IE5vbi1ib290IGNwdXMgY2Fubm90IGJlIGJyaW5nIHVwLg0KPiAN
Cj4gT24gVHVlLCAyMDE0LTEyLTIzIGF0IDAyOjQxICswMDAwLCBEb25nc2hlbmcuV2FuZ0BmcmVl
c2NhbGUuY29tIHdyb3RlOg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+
IEZyb206IE1pY2hhZWwgRWxsZXJtYW4gW21haWx0bzptcGVAZWxsZXJtYW4uaWQuYXVdDQo+ID4g
PiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyMywgMjAxNCA5OjAxIEFNDQo+ID4gPiBUbzogV2Fu
ZyBEb25nc2hlbmctQjQwNTM0DQo+ID4gPiBDYzogYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBX
b29kIFNjb3R0LUIwNzQyMTsgYW50b25Ac2FtYmEub3JnOw0KPiA+ID4gbGludXhwcGMtIGRldkBs
aXN0cy5vemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIXSBwb3dlcnBjL3NtcDog
Rml4IE5vbi1ib290IGNwdXMgY2Fubm90IGJlIGJyaW5nIHVwLg0KPiA+ID4NCj4gPiA+IE9uIE1v
biwgMjAxNC0xMi0yMiBhdCAxNDozOCArMDgwMCwgRG9uZ3NoZW5nIFdhbmcgd3JvdGU6DQo+ID4g
PiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2FuZ0BmcmVlc2NhbGUuY29tPg0K
PiA+ID4gPg0KPiA+ID4gPiBLZXJuZWwgY2Fubm90IGJyaW5nIHVwIE5vbi1ib290IGNwdXMgYWx3
YXlzIGdldCAiUHJvY2Vzc29yIHh4IGlzIHN0dWNrIi4NCj4gPiA+ID4gdGhpcyBpc3N1ZSBicmlu
ZyBieSBodHRwOi8vcGF0Y2h3b3JrLm96bGFicy5vcmcvcGF0Y2gvNDE4OTEyLyAocG93ZXJwYzoN
Cj4gPiA+ID4gU2Vjb25kYXJ5IENQVXMgbXVzdCBzZXQgY3B1X2NhbGxpbl9tYXAgYWZ0ZXIgc2V0
dGluZyBhY3RpdmUgYW5kDQo+ID4gPiA+IG9ubGluZSkgV2UgbmVlZCB0byB0YWtlIHRpbWViYXNl
IGFmdGVyIGJvb3R1cCBjcHUgZ2l2ZSB0aGUgdGltZWJhc2UNCj4gZmlyc3RseS4NCj4gPiA+ID4N
Cj4gPiA+ID4gV2hlbiBzdGFydF9zZWNvbmRhcnksIG5vbi1ib290IGNwdXMgc2V0IGNwdV9jYWxs
aW5fbWFwIGZvciBib290DQo+ID4gPiA+IGNwdSBhZnRlciB0aGF0IGJvb3QgY3B1IHdpbGwgZ2l2
ZSB0aGUgdGltZWJhc2UgZm9yIG5vbi1ib290IGNwdS4NCj4gPiA+ID4gT3RoZXJ3aXNlIG5vbi1i
b290IGNwdXMgd2lsbCBmYWxsIGluIGRlYWQgbG9vcCB0byB3YWl0aW5nIGJvb3R1cA0KPiA+ID4g
PiBjcHUgdG8gZ2l2ZSBpbWViYXNlLg0KPiA+ID4NCj4gPiA+IFJpZ2h0Lg0KPiA+ID4NCj4gPiA+
IEhvd2V2ZXIsIGRvZXNuJ3QgdGhpcyBpbnRyb2R1Y2UgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhl
IHNlY29uZGFyeQ0KPiA+ID4gY3B1IGlzIHVwIGFuZCBtYXJrZWQgb25saW5lIGJ1dCBoYXMgYW4g
dW5zeW5jaHJvbmlzZWQgY2xvY2s/DQo+IA0KPiA+IFllcywgcmlnaHQuIEJ1dCBGcmVlc2NhbGUg
cGxhdGZvcm0gYm9vdC1jcHUgd2lsbCBmcmVlemUgdGhlIFRCIHVudGlsDQo+ID4gc2Vjb25kYXJ5
IGNwdSB0YWtlIHRoZSB0aW1lIGJhc2UsIHNvIHRoZSBjbG9jayBpcyBzeW5jaHJvbml6ZWQuDQo+
IA0KPiBJdCBkb2VzIHRoZSBmcmVlemUgaW4gZ2l2ZV90aW1lYmFzZSgpIGRvZXNuJ3QgaXQ/DQo+
IA0KPiBTbyB0aGVyZSdzIHN0aWxsIGEgd2luZG93IHRoZXJlIHdoZXJlIHRoZSBzZWNvbmRhcnkg
aXMgdXAgJiBvbmxpbmUgYnV0IGhhc24ndA0KPiBoYWQgaXQncyB0aW1lYmFzZSBzeW5jaHJvbmlz
ZWQsIGFuZCB0aGUgcHJpbWFyeSBoYXNuJ3QgZnJvemVuIHRoZSB0aW1lYmFzZSB5ZXQuDQo+IFNv
IHRoYXQgbWFrZXMgbWUgbmVydm91cy4NCj4gDQo+ID4gRm9yIGdlbmVyaWMgUG93ZXJQQyBtYXli
ZSBoYXMgdGhpcyBpc3N1ZS4gU28gZm9yIHNhZmUgSSB0aGluayB3ZSBuZWVkDQo+ID4gdG8gc2V0
IGNwdSBvbmxpbmUgYWZ0ZXIgc3luY2hyb25pemVkIGNsb2NrLg0KPiA+DQo+ID4gSSB3aWxsIHVw
ZGF0ZSBteSBwYXRjaCBpZiB5b3UgYWdyZWUgdGhpcyB3YXkuDQo+ID4gKyAgICAgICBpZiAoc21w
X29wcy0+dGFrZV90aW1lYmFzZSkNCj4gPiArICAgICAgICAgICAgICAgc21wX29wcy0+dGFrZV90
aW1lYmFzZSgpOw0KPiA+ICsgICAgICAgc2Vjb25kYXJ5X2NwdV90aW1lX2luaXQoKTsNCj4gPiAr
DQo+ID4gTW92ZSBzZXRfY3B1X29ubGluZSB0byBoZXJlLg0KPiA+ICsgICAgICAgc2V0X2NwdV9v
bmxpbmUoY3B1LCB0cnVlKTsNCj4gDQo+IEJ1dCB0aGF0IHJldmVyc2VzIHRoZSBlZmZlY3Qgb2Yg
dGhlIG9yaWdpbmFsIHBhdGNoLCB3aGljaCB3YXMgdGhhdCB3ZSBoYXZlIHRvDQo+IHNldCBvbmxp
bmUgKmJlZm9yZSogd2Ugc2V0IHRoZSBjYWxsaW4gbWFwLg0KPiANCj4gDQo+IExvb2tpbmcgaGFy
ZGVyIGF0IEFudG9uJ3MgcGF0Y2ggSSdtIG5vdCBzdXJlIGl0J3MgcmlnaHQgYW55d2F5Lg0KPiAN
Cj4gVGhlIGlzc3VlIGhlIHdhcyB0cnlpbmcgdG8gZml4IHdhcyB0aGF0IHRoZSBjcHUgd2FzIG9u
bGluZSBidXQgbm90IGFjdGl2ZSwgd2hpY2gNCj4gY29uZnVzZWQgdGhlIHNjaGVkdWxlci4NCj4g
DQo+IEkgdGhpbmsgQW50b24gbWlzc2VkIHRoYXQgd2UgaGF2ZSBhIGxvb3AgdGhhdCB3YWl0cyBm
b3Igb25saW5lIGF0IHRoZSBib3R0b20gb2YNCj4gX19jcHVfdXAoKToNCj4gDQo+IAkvKiBXYWl0
IHVudGlsIGNwdSBwdXRzIGl0c2VsZiBpbiB0aGUgb25saW5lIG1hcCAqLw0KPiAJd2hpbGUgKCFj
cHVfb25saW5lKGNwdSkpDQo+IAkJY3B1X3JlbGF4KCk7DQo+IA0KPiANCj4gSGUgbXVzdCBoYXZl
IHNlZW4gYSBjYXNlIHdoZXJlIHRoYXQgcG9wcGVkIGR1ZSB0byB0aGUgY3B1IGJlaW5nIG9ubGlu
ZSwgYnV0IHRoZQ0KPiBjcHUgd2Fzbid0IHlldCBhY3RpdmUuDQo+IA0KPiBIaXMgcGF0Y2ggZml4
ZWQgdGhlIHByb2JsZW0gYnkgZW5zdXJpbmcgdGhlIHByZXZpb3VzIGxvb3AgdGhhdCB3YWl0cyBm
b3INCj4gY3B1X2NhbGxpbl9tYXAgZG9lc24ndCBmaW5pc2ggdW50aWwgYWN0aXZlICYgb25saW5l
IGFyZSBzZXQsIG1ha2luZyB0aGUgd2hpbGUNCj4gbG9vcCBhYm92ZSBhIG5vcC4NCj4gDQo+IFNv
IEkgdGhpbmsgd2Ugc2hvdWxkIHByb2JhYmx5IHJldmVydCBBbnRvbidzIHBhdGNoIGFuZCBpbnN0
ZWFkIGNoYW5nZSB0aGF0IHdoaWxlDQo+IGxvb3AgdG86DQo+IA0KPiAJLyogV2FpdCB1bnRpbCBj
cHUgaXMgb25saW5lIEFORCBhY3RpdmUgKi8NCj4gCXdoaWxlICghY3B1X29ubGluZShjcHUpIHx8
ICFjcHVfYWN0aXZlKGNwdSkpDQo+IAkJY3B1X3JlbGF4KCk7DQo+IA0KVW1tLi4gU29ycnkgYWJv
dXQgdGhhdC4uLkkgZm9yZ290IEFudG9uJ3MgcGF0Y2guDQoNCkJ1dCBzZXRfY3B1X29ubGluZSBh
bHNvIHNldCBjcHVfYWN0aXZlX2JpdHMsIEkgdGhpbmsgdGhpcyBqdWRnbWVudCBjYW5ub3QgZml4
IEFudG9uJ3MgaXNzdWUuDQpJdCBpcyBhY3R1YWxseSB0aGUgZWZmZWN0cyBvZiB0aGUgb3JpZ2lu
YWwgaXMgdGhlIHNhbWUuDQoNClJlZ3JhZHMsDQotRG9uZ3NoZW5nDQoNCg==
^ permalink raw reply
* Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
From: Michael Ellerman @ 2014-12-23 5:52 UTC (permalink / raw)
To: Geoff Levand
Cc: cbe-oss-dev, Rickard Strandqvist, Andre Heider, linux-kernel,
Paul Mackerras, Nathan Whitehorn, linuxppc-dev
In-Reply-To: <1419302677.4364.100.camel@smoke>
On Mon, 2014-12-22 at 18:44 -0800, Geoff Levand wrote:
> Hi Michael,
>
> On Tue, 2014-12-23 at 11:26 +1100, Michael Ellerman wrote:
> > On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote:
> > > ps3_repository_write_highmem_info() is needed by otheros++. What we
> > > need is a kernel patch to add the highmem info to the repository once it
> > > is known.
> >
> > OK so where's that patch?
>
> I put one in my ps3-linux repo. I'll post it after I do some more
> testing.
Great, thanks.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
From: Michael Ellerman @ 2014-12-23 5:45 UTC (permalink / raw)
To: Dongsheng.Wang@freescale.com
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org, anton@samba.org
In-Reply-To: <BN1PR03MB1889A560297773EE7E2342B9D570@BN1PR03MB188.namprd03.prod.outlook.com>
On Tue, 2014-12-23 at 02:41 +0000, Dongsheng.Wang@freescale.com wrote:
> > -----Original Message-----
> > From: Michael Ellerman [mailto:mpe@ellerman.id.au]
> > Sent: Tuesday, December 23, 2014 9:01 AM
> > To: Wang Dongsheng-B40534
> > Cc: benh@kernel.crashing.org; Wood Scott-B07421; anton@samba.org; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
> >
> > On Mon, 2014-12-22 at 14:38 +0800, Dongsheng Wang wrote:
> > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > >
> > > Kernel cannot bring up Non-boot cpus always get "Processor xx is stuck".
> > > this issue bring by http://patchwork.ozlabs.org/patch/418912/ (powerpc:
> > > Secondary CPUs must set cpu_callin_map after setting active and
> > > online) We need to take timebase after bootup cpu give the timebase firstly.
> > >
> > > When start_secondary, non-boot cpus set cpu_callin_map for boot cpu
> > > after that boot cpu will give the timebase for non-boot cpu. Otherwise
> > > non-boot cpus will fall in dead loop to waiting bootup cpu to give
> > > imebase.
> >
> > Right.
> >
> > However, doesn't this introduce the possibility that the secondary cpu is up and
> > marked online but has an unsynchronised clock?
> Yes, right. But Freescale platform boot-cpu will freeze the TB until secondary cpu
> take the time base, so the clock is synchronized.
It does the freeze in give_timebase() doesn't it?
So there's still a window there where the secondary is up & online but hasn't
had it's timebase synchronised, and the primary hasn't frozen the timebase yet.
So that makes me nervous.
> For generic PowerPC maybe has this issue. So for safe I think we need to set cpu online
> after synchronized clock.
>
> I will update my patch if you agree this way.
> + if (smp_ops->take_timebase)
> + smp_ops->take_timebase();
> + secondary_cpu_time_init();
> +
> Move set_cpu_online to here.
> + set_cpu_online(cpu, true);
But that reverses the effect of the original patch, which was that we have to
set online *before* we set the callin map.
Looking harder at Anton's patch I'm not sure it's right anyway.
The issue he was trying to fix was that the cpu was online but not active,
which confused the scheduler.
I think Anton missed that we have a loop that waits for online at the bottom of
__cpu_up():
/* Wait until cpu puts itself in the online map */
while (!cpu_online(cpu))
cpu_relax();
He must have seen a case where that popped due to the cpu being online, but the
cpu wasn't yet active.
His patch fixed the problem by ensuring the previous loop that waits for
cpu_callin_map doesn't finish until active & online are set, making the while
loop above a nop.
So I think we should probably revert Anton's patch and instead change that
while loop to:
/* Wait until cpu is online AND active */
while (!cpu_online(cpu) || !cpu_active(cpu))
cpu_relax();
cheers
^ permalink raw reply
* Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
From: Geoff Levand @ 2014-12-23 2:44 UTC (permalink / raw)
To: Michael Ellerman
Cc: cbe-oss-dev, Rickard Strandqvist, Andre Heider, linux-kernel,
Paul Mackerras, Nathan Whitehorn, linuxppc-dev
In-Reply-To: <1419294380.30550.1.camel@ellerman.id.au>
Hi Michael,
On Tue, 2014-12-23 at 11:26 +1100, Michael Ellerman wrote:
> On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote:
> > ps3_repository_write_highmem_info() is needed by otheros++. What we
> > need is a kernel patch to add the highmem info to the repository once it
> > is known.
>
> OK so where's that patch?
I put one in my ps3-linux repo. I'll post it after I do some more
testing.
-Geoff
^ permalink raw reply
* RE: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
From: Dongsheng.Wang @ 2014-12-23 2:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org, anton@samba.org
In-Reply-To: <1419296441.30550.3.camel@ellerman.id.au>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWljaGFlbCBFbGxlcm1h
biBbbWFpbHRvOm1wZUBlbGxlcm1hbi5pZC5hdV0NCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIg
MjMsIDIwMTQgOTowMSBBTQ0KPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0DQo+IENjOiBiZW5o
QGtlcm5lbC5jcmFzaGluZy5vcmc7IFdvb2QgU2NvdHQtQjA3NDIxOyBhbnRvbkBzYW1iYS5vcmc7
IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENI
XSBwb3dlcnBjL3NtcDogRml4IE5vbi1ib290IGNwdXMgY2Fubm90IGJlIGJyaW5nIHVwLg0KPiAN
Cj4gT24gTW9uLCAyMDE0LTEyLTIyIGF0IDE0OjM4ICswODAwLCBEb25nc2hlbmcgV2FuZyB3cm90
ZToNCj4gPiBGcm9tOiBXYW5nIERvbmdzaGVuZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNv
bT4NCj4gPg0KPiA+IEtlcm5lbCBjYW5ub3QgYnJpbmcgdXAgTm9uLWJvb3QgY3B1cyBhbHdheXMg
Z2V0ICJQcm9jZXNzb3IgeHggaXMgc3R1Y2siLg0KPiA+IHRoaXMgaXNzdWUgYnJpbmcgYnkgaHR0
cDovL3BhdGNod29yay5vemxhYnMub3JnL3BhdGNoLzQxODkxMi8gKHBvd2VycGM6DQo+ID4gU2Vj
b25kYXJ5IENQVXMgbXVzdCBzZXQgY3B1X2NhbGxpbl9tYXAgYWZ0ZXIgc2V0dGluZyBhY3RpdmUg
YW5kDQo+ID4gb25saW5lKSBXZSBuZWVkIHRvIHRha2UgdGltZWJhc2UgYWZ0ZXIgYm9vdHVwIGNw
dSBnaXZlIHRoZSB0aW1lYmFzZSBmaXJzdGx5Lg0KPiA+DQo+ID4gV2hlbiBzdGFydF9zZWNvbmRh
cnksIG5vbi1ib290IGNwdXMgc2V0IGNwdV9jYWxsaW5fbWFwIGZvciBib290IGNwdQ0KPiA+IGFm
dGVyIHRoYXQgYm9vdCBjcHUgd2lsbCBnaXZlIHRoZSB0aW1lYmFzZSBmb3Igbm9uLWJvb3QgY3B1
LiBPdGhlcndpc2UNCj4gPiBub24tYm9vdCBjcHVzIHdpbGwgZmFsbCBpbiBkZWFkIGxvb3AgdG8g
d2FpdGluZyBib290dXAgY3B1IHRvIGdpdmUNCj4gPiBpbWViYXNlLg0KPiANCj4gUmlnaHQuDQo+
IA0KPiBIb3dldmVyLCBkb2Vzbid0IHRoaXMgaW50cm9kdWNlIHRoZSBwb3NzaWJpbGl0eSB0aGF0
IHRoZSBzZWNvbmRhcnkgY3B1IGlzIHVwIGFuZA0KPiBtYXJrZWQgb25saW5lIGJ1dCBoYXMgYW4g
dW5zeW5jaHJvbmlzZWQgY2xvY2s/DQo+IA0KWWVzLCByaWdodC4gQnV0IEZyZWVzY2FsZSBwbGF0
Zm9ybSBib290LWNwdSB3aWxsIGZyZWV6ZSB0aGUgVEIgdW50aWwgc2Vjb25kYXJ5IGNwdQ0KdGFr
ZSB0aGUgdGltZSBiYXNlLCBzbyB0aGUgY2xvY2sgaXMgc3luY2hyb25pemVkLg0KDQpGb3IgZ2Vu
ZXJpYyBQb3dlclBDIG1heWJlIGhhcyB0aGlzIGlzc3VlLiBTbyBmb3Igc2FmZSBJIHRoaW5rIHdl
IG5lZWQgdG8gc2V0IGNwdSBvbmxpbmUNCmFmdGVyIHN5bmNocm9uaXplZCBjbG9jay4NCg0KSSB3
aWxsIHVwZGF0ZSBteSBwYXRjaCBpZiB5b3UgYWdyZWUgdGhpcyB3YXkuDQorICAgICAgIGlmIChz
bXBfb3BzLT50YWtlX3RpbWViYXNlKQ0KKyAgICAgICAgICAgICAgIHNtcF9vcHMtPnRha2VfdGlt
ZWJhc2UoKTsNCisgICAgICAgc2Vjb25kYXJ5X2NwdV90aW1lX2luaXQoKTsNCisNCk1vdmUgc2V0
X2NwdV9vbmxpbmUgdG8gaGVyZS4NCisgICAgICAgc2V0X2NwdV9vbmxpbmUoY3B1LCB0cnVlKTsN
Cg0KUmVnYXJkcywNCi1Eb25nc2hlbmcNCg==
^ permalink raw reply
* Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
From: Michael Ellerman @ 2014-12-23 1:00 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: scottwood, linuxppc-dev, anton
In-Reply-To: <1419230320-37558-1-git-send-email-dongsheng.wang@freescale.com>
On Mon, 2014-12-22 at 14:38 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> Kernel cannot bring up Non-boot cpus always get "Processor xx is stuck".
> this issue bring by http://patchwork.ozlabs.org/patch/418912/ (powerpc:
> Secondary CPUs must set cpu_callin_map after setting active and online)
> We need to take timebase after bootup cpu give the timebase firstly.
>
> When start_secondary, non-boot cpus set cpu_callin_map for boot cpu
> after that boot cpu will give the timebase for non-boot cpu. Otherwise
> non-boot cpus will fall in dead loop to waiting bootup cpu to give
> imebase.
Right.
However, doesn't this introduce the possibility that the secondary cpu is up
and marked online but has an unsynchronised clock?
cheers
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] IBM Akebono: Remove select of IBM_EMAC_RGMII_WOL
From: Michael Ellerman @ 2014-12-23 0:31 UTC (permalink / raw)
To: Paul Bolle
Cc: Jiri Kosina, linux-kernel, linuxppc-dev, Alistair Popple,
Valentin Rothberg
In-Reply-To: <2224792.Nmvmc626jj@mexican>
On Tue, 2014-12-23 at 09:48 +1100, Alistair Popple wrote:
> Hi Paul,
>
> These days I've been made maintainer of the PPC4XX tree so maybe adding Acked-
> by: Alistair Popple <alistair@popple.id.au> might help?
>
> Jiri, if you would rather this go via the main PPC tree please let us know and
> we'll see if Michael Ellerman (added to CC) would be willing to take it (he
> has taken over most of the day to day maintenance of the PPC tree). Thanks!
It never went to linuxppc as far as I can see, though I am happy to take it.
Although it is a trivial patch I'd still rather you CC'ed us on patches to
arch/powerpc.
cheers
^ permalink raw reply
* Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
From: Michael Ellerman @ 2014-12-23 0:26 UTC (permalink / raw)
To: Geoff Levand
Cc: cbe-oss-dev, Rickard Strandqvist, Andre Heider, linux-kernel,
Paul Mackerras, Nathan Whitehorn, linuxppc-dev
In-Reply-To: <1419269161.3786.4.camel@infradead.org>
On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote:
> On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote:
> > Remove the function ps3_repository_write_highmem_info() that is not used anywhere.
>
> NAK
>
> ps3_repository_write_highmem_info() is needed by otheros++. What we
> need is a kernel patch to add the highmem info to the repository once it
> is known.
OK so where's that patch?
> These ps3_repository_write_highmem routines are also the only
> documentation the freeBSD port has as to how the highmem info is (should
> be) saved in the repository.
We don't carry dead code as documentation for BSD.
cheers
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] IBM Akebono: Remove select of IBM_EMAC_RGMII_WOL
From: Alistair Popple @ 2014-12-22 22:48 UTC (permalink / raw)
To: Paul Bolle, Jiri Kosina; +Cc: linuxppc-dev, linux-kernel, Valentin Rothberg
In-Reply-To: <1419243273.30945.19.camel@x220>
Hi Paul,
These days I've been made maintainer of the PPC4XX tree so maybe adding Acked-
by: Alistair Popple <alistair@popple.id.au> might help?
Jiri, if you would rather this go via the main PPC tree please let us know and
we'll see if Michael Ellerman (added to CC) would be willing to take it (he
has taken over most of the day to day maintenance of the PPC tree). Thanks!
Regards,
Alistair
On Mon, 22 Dec 2014 11:14:33 Paul Bolle wrote:
> Hi Jiri,
>
> On Mon, 2014-11-03 at 10:52 +0100, Paul Bolle wrote:
> > Commit 2a2c74b2efcb ("IBM Akebono: Add the Akebono platform") added a
> > select of IBM_EMAC_RGMII_WOL. But that Kconfig symbol isn't (yet) part
> > of the tree. So this select has been a nop since that commit was
> > included in v3.16-rc1.
> >
> > The code to add this symbol is not included in next-20141103. So let's
> > remove this select. It can be readded when that symbol is actually added
> > to the tree.
> >
> > Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> > Cc: Alistair Popple <alistair@popple.id.au>
> > ---
> > Untested. Done on top of next-20141103.
> >
> > Third time's a charm? First raised in
> > https://lkml.org/lkml/2014/5/1/106 . Reminder sent in
> > https://lkml.org/lkml/2014/9/4/645 . I'm not aware of any news on this
> > front, so this trivial patch seems reasonable now.
> >
> > A patch to readd this select could be added - if people still care about
> > it, that is - in the series that adds this symbol. A web search suggests
> > Alistair takes care of that series, so Alistair gets a Cc: here.
>
> This select of IBM_EMAC_RGMII_WOL still shows up in next-20141221 and
> v3.19-rc1. Did you have a chance to look at this patch?
>
> > arch/powerpc/platforms/44x/Kconfig | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/powerpc/platforms/44x/Kconfig
> > b/arch/powerpc/platforms/44x/Kconfig index d2ac1c116454..5538e57c36c1
> > 100644
> > --- a/arch/powerpc/platforms/44x/Kconfig
> > +++ b/arch/powerpc/platforms/44x/Kconfig
> > @@ -214,7 +214,6 @@ config AKEBONO
> >
> > select ETHERNET
> > select NET_VENDOR_IBM
> > select IBM_EMAC_EMAC4
> >
> > - select IBM_EMAC_RGMII_WOL
> >
> > select USB if USB_SUPPORT
> > select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
> > select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
>
> Thanks,
>
>
> Paul Bolle
^ permalink raw reply
* Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
From: Rickard Strandqvist @ 2014-12-22 22:11 UTC (permalink / raw)
To: Nathan Whitehorn
Cc: cbe-oss-dev, Geoff Levand, Andre Heider,
linux-kernel@vger.kernel.org, Paul Mackerras, linuxppc-dev
In-Reply-To: <54985686.7080609@freebsd.org>
2014-12-22 18:36 GMT+01:00 Nathan Whitehorn <nwhitehorn@freebsd.org>:
>
> On 12/22/14 09:26, Geoff Levand wrote:
>>
>> On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote:
>>>
>>> Remove the function ps3_repository_write_highmem_info() that is not used
>>> anywhere.
>>
>> NAK
>>
>> ps3_repository_write_highmem_info() is needed by otheros++. What we
>> need is a kernel patch to add the highmem info to the repository once it
>> is known.
>>
>> These ps3_repository_write_highmem routines are also the only
>> documentation the freeBSD port has as to how the highmem info is (should
>> be) saved in the repository.
>>
>> -Geoff
>>
>>
>
> Yes, we really need this for FreeBSD since that port uses the repository
> directly instead of FDT. Thanks for noticing this. We could adapt FreeBSD to
> use FDT (this is the only non-device-tree PowerPC port), but there hasn't
> been any reason to do that thus far given the availability of the repository
> information.
> -Nathan
Hi
Too bad that did not have the benefit of the patch, but it looks like
something good come because of it anyhow.
Kind regards
Rickard Strandqvist
^ permalink raw reply
* Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Scott Wood @ 2014-12-22 21:25 UTC (permalink / raw)
To: Emil Medve
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Liberman Igal-B31950
In-Reply-To: <5497FBAB.4010206@Freescale.com>
On Mon, 2014-12-22 at 05:08 -0600, Emil Medve wrote:
> Hello Scott,
>
>
> On 12/22/2014 03:42 AM, Scott Wood wrote:
> > On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 12/22/2014 02:32 AM, Scott Wood wrote:
> >>> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
> >>>> For the purpose of an example in the binding document, I suggest we just
> >>>> stick with the IEEE standard frequency.
> >>>
> >>> The whole reason for this property existing in the device tree is
> >>> non-standard frequencies.
> >>
> >> While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
> >> support frequencies well beyond the standard. Specifying a lower then
> >> the standard frequency for the benefit of some errata is just one side
> >> of this property
> >
> > The erratum was (until now) the only claimed reason for it. If there
> > are other reasons why one would specify a different frequency (in
> > particular, that relate to hardware description), please elaborate.
>
> From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS boards
> support 12.5 MHz. I can dig out more specs for specifics on other PHY(s)
>
> 2.5 MHz is slow and even more so for high speed interfaces. With both
> polling and interrupts (both MDIO and/or PHY) we've noticed (or blamed)
> in the past some Ethernet performance issues on this very slowness
>
> As of right now I'm not aware of another way to specify/coordinate the
> MDC speed so setting a default (common denominator) in the DT that is
> different then the IEEE standard seems ok
>
> >>>> We can continue this conversation about errata handling when we submit
> >>>> the code relevant to this binding (and the FMan v3 support)
> >>>
> >>> It affects the binding, so let's discuss it now please.
> >>
> >> I think this specific (unpublished yet) errata has less bearing on the
> >> binding then you might believe. This is mostly about providing a
> >> common/default frequency supported by all the devices on some board
> >
> > What reason other than an erratum would there be for the standard
> > frequency not being supported?
>
> This is not about not supporting the standard frequency. This is about
> the default frequency being different then the standard
OK, though rather than talk about defaults I'd phrase it as indicating
that a higher frequency than standard is supported, or that a lower
frequency than standard is required.
-Scott
^ permalink raw reply
* Re: [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events
From: Sukadev Bhattiprolu @ 2014-12-22 19:45 UTC (permalink / raw)
To: Jiri Olsa
Cc: peterz, linux-kernel, Arnaldo Carvalho de Melo, dev,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20141222144315.GC29096@krava.brq.redhat.com>
Jiri Olsa [jolsa@redhat.com] wrote:
| > + values for each of 'config', 'config1' and 'config2' are defined by
| > + corresponding entries in /sys/bus/event_sources/devices/<pmu>/format/*
| > + param1 and param2 are defined as formats for the PMU in:
| > + /sys/bus/event_sources/devices/<pmu>/format/*
|
| ^^^^ misaligned tab
Thanks, Fixed the typos and alignment below.
---
>From 1fdb5012081903172c11a41f9edb0d51525ba500 Mon Sep 17 00:00:00 2001
From: Cody P Schafer <cody@linux.vnet.ibm.com>
Date: Wed, 24 Sep 2014 12:27:23 -0700
Subject: [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events
Changelog[v6]:
- [Sukadev Bhattiprolu]: Update documentation of perf-list and
perf-record; Added documentation for perf-stat.
- [Jiri Olsa] Fix some typos/formatting
CC: Haren Myneni <hbabu@us.ibm.com>
CC: Cody P Schafer <dev@codyps.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
tools/perf/Documentation/perf-list.txt | 13 +++++++++++++
tools/perf/Documentation/perf-record.txt | 12 ++++++++++++
tools/perf/Documentation/perf-stat.txt | 20 ++++++++++++++++----
3 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt
index cbb4f74..3e2aec9 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -89,6 +89,19 @@ raw encoding of 0x1A8 can be used:
You should refer to the processor specific documentation for getting these
details. Some of them are referenced in the SEE ALSO section below.
+PARAMETERIZED EVENTS
+--------------------
+
+Some pmu events listed by 'perf-list' will be displayed with '?' in them. For
+example:
+
+ hv_gpci/dtbp_ptitc,phys_processor_idx=?/
+
+This means that when provided as an event, a value for '?' must
+also be supplied. For example:
+
+ perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ...
+
OPTIONS
-------
diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt
index af9a54e..7d8df2e 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -33,6 +33,18 @@ OPTIONS
- a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
hexadecimal event descriptor.
+ - a symbolically formed PMU event like 'pmu/param1=0x3,param2/' where
+ 'param1', 'param2', etc are defined as formats for the PMU in
+ /sys/bus/event_sources/devices/<pmu>/format/*.
+
+ - a symbolically formed event like 'pmu/config=M,config1=N,config3=K/'
+
+ where M, N, K are numbers (in decimal, hex, octal format). Acceptable
+ values for each of 'config', 'config1' and 'config2' are defined by
+ corresponding entries in /sys/bus/event_sources/devices/<pmu>/format/*
+ param1 and param2 are defined as formats for the PMU in:
+ /sys/bus/event_sources/devices/<pmu>/format/*
+
- a hardware breakpoint event in the form of '\mem:addr[:access]'
where addr is the address in memory you want to break in.
Access is the memory access type (read, write, execute) it can
diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt
index 29ee857..04e150d 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -25,10 +25,22 @@ OPTIONS
-e::
--event=::
- Select the PMU event. Selection can be a symbolic event name
- (use 'perf list' to list all events) or a raw PMU
- event (eventsel+umask) in the form of rNNN where NNN is a
- hexadecimal event descriptor.
+ Select the PMU event. Selection can be:
+
+ - a symbolic event name (use 'perf list' to list all events)
+
+ - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
+ hexadecimal event descriptor.
+
+ - a symbolically formed event like 'pmu/param1=0x3,param2/' where
+ param1 and param2 are defined as formats for the PMU in
+ /sys/bus/event_sources/devices/<pmu>/format/*
+
+ - a symbolically formed event like 'pmu/config=M,config1=N,config2=K/'
+ where M, N, K are numbers (in decimal, hex, octal format).
+ Acceptable values for each of 'config', 'config1' and 'config2'
+ parameters are defined by corresponding entries in
+ /sys/bus/event_sources/devices/<pmu>/format/*
-i::
--no-inherit::
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v6 3/4] perf Documentation: add event parameters
From: Sukadev Bhattiprolu @ 2014-12-22 19:34 UTC (permalink / raw)
To: Jiri Olsa
Cc: peterz, linux-kernel, Arnaldo Carvalho de Melo, dev,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20141222143943.GB29096@krava.brq.redhat.com>
Jiri Olsa [jolsa@redhat.com] wrote:
| On Sun, Dec 21, 2014 at 11:49:26PM -0800, Sukadev Bhattiprolu wrote:
| > From: Cody P Schafer <cody@linux.vnet.ibm.com>
| > + In the case of the last example, a value replacing "?" would
| > + need to be provided by the user selecting the particular event.
| > + This is referred to as "event parameterization". All
| > + non-numerical values indicate an event parameter.
|
| I see.. here's the glitch ;-) I thought we agreed on forcing '?'
| as the value for param events, not 'All non-numerical values'
Yes, it is currently more broad than needed, but it is not really
user input - we are just parsing sysfs entries that developer specified
in the kernel. If necessary, we can tighten that independently ?
|
| thanks,
| jirka
^ permalink raw reply
* Re: [PATCH v6 1/4] tools/perf: support parsing parameterized events
From: Sukadev Bhattiprolu @ 2014-12-22 19:30 UTC (permalink / raw)
To: Jiri Olsa
Cc: peterz, linux-kernel, Arnaldo Carvalho de Melo, dev,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20141222143710.GA29096@krava.brq.redhat.com>
Jiri Olsa [jolsa@redhat.com] wrote:
| On Sun, Dec 21, 2014 at 11:49:24PM -0800, Sukadev Bhattiprolu wrote:
|
| SNIP
|
| > + }
| >
| > switch (format->value) {
| > case PERF_PMU_FORMAT_VALUE_CONFIG:
| > @@ -592,11 +629,16 @@ static int pmu_config_term(struct list_head *formats,
| > }
| >
| > /*
| > - * XXX If we ever decide to go with string values for
| > - * non-hardcoded terms, here's the place to translate
| > - * them into value.
| > + * Either directly use a numeric term, or try to translate string terms
| > + * using event parameters.
| > */
| > - pmu_format_value(format->bits, term->val.num, vp, zero);
| > + if (term->type_val == PARSE_EVENTS__TERM_TYPE_NUM)
| > + val = term->val.num;
| > + else
| > + if (pmu_resolve_param_term(term, head_terms, &val))
| > + return -EINVAL;
| > +
|
| I'm ok with the change logic, but I'm missing here check for the 'term'
| string value to be '?', so we force subst terms to have '?' as value..
| I believe thats what we decided in the previous set discussion, right?
The =? is not a user input, so I did not think of validating that.
perf tool expects kernel/sysfs to show entries like 'core=?'. Are you
saying that we should error out if kernel mistakenly displays 'core=$val'
or 'core=?val' ?
If a required parameter is missing, we catch that in pmu_resolve_param_term().
If a bogus parameter is specified we catch that above in pmu_config_term().
|
| I guess the it'd be nice to parse it directly in the bison code like
| below (could be done later), but I'd be ok with simple check on this
| place for now.
|
| thanks,
| jirka
|
|
| ---
| diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
| index 93c4c9fbc922..7e021c64d5cc 100644
| --- a/tools/perf/util/parse-events.y
| +++ b/tools/perf/util/parse-events.y
| @@ -484,6 +484,14 @@ PE_TERM '=' PE_VALUE
| $$ = term;
| }
| |
| +PE_TERM '=' PE_SUBST
| +{
| + struct parse_events_term *term;
| +
| + ABORT_ON(parse_events_term__subst(&term, (int)$1, NULL, NULL));
| + $$ = term;
| +}
| +|
| PE_TERM
| {
| struct parse_events_term *term;
^ permalink raw reply
* Re: [git pull] Please pull mpe/linux.git powerpc-3.19-2 tag
From: Scott Wood @ 2014-12-22 19:23 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, anton
In-Reply-To: <87r3vrbvpv.fsf@igel.home>
On Mon, 2014-12-22 at 15:33 +0100, Andreas Schwab wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>
> > Anton Blanchard (1):
> > powerpc: Secondary CPUs must set cpu_callin_map after setting active and online
>
> This breaks booting on the PowerMac7,3. It takes forever to boot to
> user space (~5 minutes instead of ~4 seconds), and then I see these
> processes in top:
>
> 37 root 20 0 0 0 0 D 0.000 0.000 0:00.00 kwindfarm
> 10 root rt 0 0 0 0 R 0.000 0.000 0:00.00 migration/1
> 11 root 20 0 0 0 0 R 0.000 0.000 0:00.00 ksoftirqd/1
>
> (The latter two processes don't accumulate any cpu time, but they are
> constantly in run state.)
http://patchwork.ozlabs.org/patch/423315/
-Scott
^ permalink raw reply
* Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
From: Nathan Whitehorn @ 2014-12-22 17:36 UTC (permalink / raw)
To: Geoff Levand, Rickard Strandqvist, Andre Heider
Cc: cbe-oss-dev, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1419269161.3786.4.camel@infradead.org>
On 12/22/14 09:26, Geoff Levand wrote:
> On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote:
>> Remove the function ps3_repository_write_highmem_info() that is not used anywhere.
> NAK
>
> ps3_repository_write_highmem_info() is needed by otheros++. What we
> need is a kernel patch to add the highmem info to the repository once it
> is known.
>
> These ps3_repository_write_highmem routines are also the only
> documentation the freeBSD port has as to how the highmem info is (should
> be) saved in the repository.
>
> -Geoff
>
>
Yes, we really need this for FreeBSD since that port uses the repository
directly instead of FDT. Thanks for noticing this. We could adapt
FreeBSD to use FDT (this is the only non-device-tree PowerPC port), but
there hasn't been any reason to do that thus far given the availability
of the repository information.
-Nathan
^ permalink raw reply
* Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
From: Geoff Levand @ 2014-12-22 17:26 UTC (permalink / raw)
To: Rickard Strandqvist, Andre Heider, Nathan Whitehorn
Cc: cbe-oss-dev, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1419087601-4889-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote:
> Remove the function ps3_repository_write_highmem_info() that is not used anywhere.
NAK
ps3_repository_write_highmem_info() is needed by otheros++. What we
need is a kernel patch to add the highmem info to the repository once it
is known.
These ps3_repository_write_highmem routines are also the only
documentation the freeBSD port has as to how the highmem info is (should
be) saved in the repository.
-Geoff
^ permalink raw reply
* Re: [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events
From: Jiri Olsa @ 2014-12-22 14:43 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: peterz, linux-kernel, Arnaldo Carvalho de Melo, dev,
Paul Mackerras, linuxppc-dev
In-Reply-To: <1419234567-22784-5-git-send-email-sukadev@linux.vnet.ibm.com>
On Sun, Dec 21, 2014 at 11:49:27PM -0800, Sukadev Bhattiprolu wrote:
> From: Cody P Schafer <cody@linux.vnet.ibm.com>
>
> Changelog[v6]:
> - [Sukadev Bhattiprolu]: Update documentation of perf-list and
> perf-record; Added documentation for perf-stat.
>
> CC: Haren Myneni <hbabu@us.ibm.com>
> CC: Cody P Schafer <dev@codyps.com>
> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> ---
> tools/perf/Documentation/perf-list.txt | 13 +++++++++++++
> tools/perf/Documentation/perf-record.txt | 12 ++++++++++++
> tools/perf/Documentation/perf-stat.txt | 20 ++++++++++++++++----
> 3 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt
> index cbb4f74..d8be6fa 100644
> --- a/tools/perf/Documentation/perf-list.txt
> +++ b/tools/perf/Documentation/perf-list.txt
> @@ -89,6 +89,19 @@ raw encoding of 0x1A8 can be used:
> You should refer to the processor specific documentation for getting these
> details. Some of them are referenced in the SEE ALSO section below.
>
> +PARAMETERIZED EVENTS
> +--------------------
> +
> +Some pmu events listed by 'perf-list' will be displayed with '$x' in them. For
> +example:
s/$x/?/ ^^^^
> +
> + hv_gpci/dtbp_ptitc,phys_processor_idx=?/
> +
> +This means that when provided as an event, a value for '?' must
> +also be supplied. For example:
> +
> + perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ...
> +
> OPTIONS
> -------
>
> diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt
> index af9a54e..acdcf3b 100644
> --- a/tools/perf/Documentation/perf-record.txt
> +++ b/tools/perf/Documentation/perf-record.txt
> @@ -33,6 +33,18 @@ OPTIONS
> - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
> hexadecimal event descriptor.
SNIP
> +
> + - a symbolically formed event like 'pmu/config=M,config1=N,config3=K/'
> +
> + where M, N, K are numbers (in decimal, hex, octal format). Acceptable
> + values for each of 'config', 'config1' and 'config2' are defined by
> + corresponding entries in /sys/bus/event_sources/devices/<pmu>/format/*
> + param1 and param2 are defined as formats for the PMU in:
> + /sys/bus/event_sources/devices/<pmu>/format/*
^^^^ misaligned tab
> +
> - a hardware breakpoint event in the form of '\mem:addr[:access]'
> where addr is the address in memory you want to break in.
> Access is the memory access type (read, write, execute) it can
> diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt
> index 29ee857..04e150d 100644
> --- a/tools/perf/Documentation/perf-stat.txt
> +++ b/tools/perf/Documentation/perf-stat.txt
> @@ -25,10 +25,22 @@ OPTIONS
>
thanks,
jirka
^ 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