* Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
From: Kumar Gala @ 2013-04-04 19:13 UTC (permalink / raw)
To: Leekha Shaveta-B20052
Cc: Wood Scott-B07421, Mehresh Ramneek-B31383, Zhao Chenhui-B35336,
Garg Vakul-B16394, Lian Minghuan-B31939, Tang Yuantian-B29983,
Fleming Andy-AFLEMING, Sethi Varun-B16395,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <E12D2F89F87F4A49B0320A4C2DE7E749151B05@039-SN2MPN1-011.039d.mgd.msft.net>
On Apr 4, 2013, at 2:03 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----Original Message-----
> From: Wood Scott-B07421=20
> Sent: Wednesday, April 03, 2013 10:10 PM
> To: Leekha Shaveta-B20052
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Zhao =
Chenhui-B35336; Lian Minghuan-B31939; Garg Vakul-B16394; Tang =
Yuantian-B29983; Fleming Andy-AFLEMING; Mehresh Ramneek-B31383; Sethi =
Varun-B16395
> Subject: Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device =
tree files for B4860 and B4420
>=20
> On 04/03/2013 01:42:14 AM, Leekha Shaveta-B20052 wrote:
>>=20
>>=20
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Wednesday, April 03, 2013 12:49 AM
>> To: Leekha Shaveta-B20052
>> Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Lian=20
>> Minghuan-B31939; Leekha Shaveta-B20052; Garg Vakul-B16394; Tang=20
>> Yuantian-B29983; Fleming Andy-AFLEMING; Mehresh Ramneek-B31383; Sethi
>> Varun-B16395
>> Subject: Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon =
device=20
>> tree files for B4860 and B4420
>>=20
>> On 04/02/2013 02:16:05 AM, Shaveta Leekha wrote:
>>> +/ {
>>> + compatible =3D "fsl,B4860";
>>> +
>>> + cpus {
>>> + cpu1: PowerPC,e6500@1 {
>>> + device_type =3D "cpu";
>>> + reg =3D <2 3>;
>>> + next-level-cache =3D <&L2>;
>>> + };
>>> + cpu2: PowerPC,e6500@2 {
>>> + device_type =3D "cpu";
>>> + reg =3D <4 5>;
>>> + next-level-cache =3D <&L2>;
>>> + };
>>> + cpu3: PowerPC,e6500@3 {
>>> + device_type =3D "cpu";
>>> + reg =3D <6 7>;
>>> + next-level-cache =3D <&L2>;
>>> + };
>>=20
>> The unit addresses need to match "reg".
>> [SL] You mean "@1" should match to "reg =3D <2 3>" ?
>=20
> Yes, it should be "@2" for that node.
>=20
>> As each e6500 core in B4860 is dual- threaded, reg property here=20
>> represents the thread's identifier in that PA core.
>>=20
>> So convention used in T4 and B4 is: core 0 having threads 0 and 1,
>> Core 1 having <2 3> and
>> so on....
>=20
> The convention used in device trees is that the unit address matches =
the reg.
>=20
> -Scott
> [SL] Ok, I can change that. Will make unit address as @2 for <2 3>, @4 =
for <4 5> and so on....
>=20
> Kumar, please respond here, as I have followed the convention used in =
T4 device tree files for
> Dual-threaded cores.
Scott is correct, we probably need to fix the T4 dts.
- k=
^ permalink raw reply
* Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Alex Williamson @ 2013-04-04 16:43 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Wood Scott-B07421, Joerg Roedel, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D459471@039-SN2MPN1-013.039d.mgd.msft.net>
On Thu, 2013-04-04 at 16:35 +0000, Sethi Varun-B16395 wrote:
>
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Thursday, April 04, 2013 8:52 PM
> > To: Sethi Varun-B16395
> > Cc: Joerg Roedel; Yoder Stuart-B08248; Wood Scott-B07421;
> > iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> > kernel@vger.kernel.org; galak@kernel.crashing.org;
> > benh@kernel.crashing.org
> > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> > implementation.
> >
> > On Thu, 2013-04-04 at 13:00 +0000, Sethi Varun-B16395 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > > Sent: Wednesday, April 03, 2013 11:32 PM
> > > > To: Joerg Roedel
> > > > Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421;
> > > > iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> > > > linux- kernel@vger.kernel.org; galak@kernel.crashing.org;
> > > > benh@kernel.crashing.org
> > > > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and
> > > > iommu implementation.
> > > >
> > > > On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote:
> > > > > Cc'ing Alex Williamson
> > > > >
> > > > > Alex, can you please review the iommu-group part of this patch?
> > > >
> > > > Sure, it looks pretty reasonable. AIUI, all PCI devices are below
> > > > some kind of host bridge that is either new and supports
> > > > partitioning or old and doesn't. I don't know if that's a
> > > > visibility or isolation requirement, perhaps PCI ACS-ish. In the
> > > > new host bridge case, each device gets a group. This seems not to
> > > > have any quirks for multifunction devices though. On AMD and Intel
> > > > IOMMUs we test multifunction device ACS support to determine whether
> > > > all the functions should be in the same group. Is there any reason
> > to trust multifunction devices on PAMU?
> > > >
> > > [Sethi Varun-B16395] In the case where we can partition endpoints we
> > > can distinguish transactions based on the bus,device,function number
> > > combination. This support is available in the PCIe controller (host
> > > bridge).
> >
> > So can x86 IOMMUs, that's the visibility aspect of IOMMU groups.
> > Visibility alone doesn't necessarily imply that a device is isolated
> > though. A multifunction PCI device that doesn't expose ACS support may
> > not isolate functions from each other. For example a peer-to-peer DMA
> > between functions may not be translated by the upstream IOMMU. IOMMU
> > groups should encompass both visibility and isolation.
> [Sethi Varun-B16395] We can isolate the DMA access to the host based
> on the to the pci bus,device,function number.
The IOMMU can only isolate DMA that it can see. A multifunction device
may never expose peer-to-peer DMA to the upstream device, it's
implementation specific. The ACS flags allow that possibility to be
controlled and prevented.
> I thought that was enough to put devices in to separate iommu groups.
> This is a PCIe controller property which allows us to partition PCIe
> devices. But, what I can understand from your point is that we also
> need to consider isolation at PCIe device level as well. I will check
> for the case of multifunction devices.
>
> >
> > > > I also find it curious what happens to the iommu group of the host
> > > > bridge. In the partitionable case the host bridge group is removed,
> > > > in the non-partitionable case the host bridge group becomes the
> > > > group for the children, removing the host bridge. It's unique to
> > > > PAMU so far that these host bridges are even in an iommu group (x86
> > > > only adds pci devices), but I don't see it as necessarily wrong
> > > > leaving it in either scenario. Does it solve some problem to remove
> > them from the groups?
> > > > Thanks,
> > > [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity,
> > > it would always be owned by the host.
> >
> > Ownership of a device shouldn't play into the group context. An IOMMU
> > group should be defined by it's visibility and isolation from other
> > devices. Whether the PCIe controller is allowed to be handed to
> > userspace is a question for VFIO.
> [Sethi Varun-B16395] The problem is in the case, where we can't
> partition PCIe devices. PCIe devices share the same device group as
> the PCI controller. This becomes a problem while assigning the devices
> to the guest, as you are required to unbind all the PCIe devices
> including the controller from the host. PCIe controller can't be
> unbound from the host, so we simply delete the controller iommu_group.
Unbinding devices is a VFIO implementation, it shouldn't leak into IOMMU
groups. Also note that VFIO has a driver white list where we can have
exceptions to the rule. I recently added pciehp to that list because
the host driver provides functionality. Being attached to the host
driver means the device is not accessible to the user through VFIO, but
other devices in the group are. Thanks,
Alex
^ permalink raw reply
* RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Yoder Stuart-B08248 @ 2013-04-04 16:43 UTC (permalink / raw)
To: Alex Williamson, Sethi Varun-B16395
Cc: Wood Scott-B07421, Joerg Roedel, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1365088930.2882.296.camel@bling.home>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBXaWxsaWFtc29u
IFttYWlsdG86YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBB
cHJpbCAwNCwgMjAxMyAxMDoyMiBBTQ0KPiBUbzogU2V0aGkgVmFydW4tQjE2Mzk1DQo+IENjOiBK
b2VyZyBSb2VkZWw7IFlvZGVyIFN0dWFydC1CMDgyNDg7IFdvb2QgU2NvdHQtQjA3NDIxOyBpb21t
dUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgbGludXhwcGMtDQo+IGRldkBsaXN0cy5vemxh
YnMub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBnYWxha0BrZXJuZWwuY3Jhc2hp
bmcub3JnOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCA1
LzUgdjExXSBpb21tdS9mc2w6IEZyZWVzY2FsZSBQQU1VIGRyaXZlciBhbmQgaW9tbXUgaW1wbGVt
ZW50YXRpb24uDQo+IA0KPiBPbiBUaHUsIDIwMTMtMDQtMDQgYXQgMTM6MDAgKzAwMDAsIFNldGhp
IFZhcnVuLUIxNjM5NSB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gPiA+IEZyb206IEFsZXggV2lsbGlhbXNvbiBbbWFpbHRvOmFsZXgud2lsbGlhbXNvbkBy
ZWRoYXQuY29tXQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwMywgMjAxMyAxMTozMiBQ
TQ0KPiA+ID4gVG86IEpvZXJnIFJvZWRlbA0KPiA+ID4gQ2M6IFNldGhpIFZhcnVuLUIxNjM5NTsg
WW9kZXIgU3R1YXJ0LUIwODI0ODsgV29vZCBTY290dC1CMDc0MjE7DQo+ID4gPiBpb21tdUBsaXN0
cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGxp
bnV4LQ0KPiA+ID4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsgZ2FsYWtAa2VybmVsLmNyYXNoaW5n
Lm9yZzsNCj4gPiA+IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6
IFtQQVRDSCA1LzUgdjExXSBpb21tdS9mc2w6IEZyZWVzY2FsZSBQQU1VIGRyaXZlciBhbmQgaW9t
bXUNCj4gPiA+IGltcGxlbWVudGF0aW9uLg0KPiA+ID4NCj4gPiA+IE9uIFR1ZSwgMjAxMy0wNC0w
MiBhdCAxODoxOCArMDIwMCwgSm9lcmcgUm9lZGVsIHdyb3RlOg0KPiA+ID4gPiBDYydpbmcgQWxl
eCBXaWxsaWFtc29uDQo+ID4gPiA+DQo+ID4gPiA+IEFsZXgsIGNhbiB5b3UgcGxlYXNlIHJldmll
dyB0aGUgaW9tbXUtZ3JvdXAgcGFydCBvZiB0aGlzIHBhdGNoPw0KPiA+ID4NCj4gPiA+IFN1cmUs
IGl0IGxvb2tzIHByZXR0eSByZWFzb25hYmxlLiAgQUlVSSwgYWxsIFBDSSBkZXZpY2VzIGFyZSBi
ZWxvdyBzb21lDQo+ID4gPiBraW5kIG9mIGhvc3QgYnJpZGdlIHRoYXQgaXMgZWl0aGVyIG5ldyBh
bmQgc3VwcG9ydHMgcGFydGl0aW9uaW5nIG9yIG9sZA0KPiA+ID4gYW5kIGRvZXNuJ3QuICBJIGRv
bid0IGtub3cgaWYgdGhhdCdzIGEgdmlzaWJpbGl0eSBvciBpc29sYXRpb24NCj4gPiA+IHJlcXVp
cmVtZW50LCBwZXJoYXBzIFBDSSBBQ1MtaXNoLiAgSW4gdGhlIG5ldyBob3N0IGJyaWRnZSBjYXNl
LCBlYWNoDQo+ID4gPiBkZXZpY2UgZ2V0cyBhIGdyb3VwLiAgVGhpcyBzZWVtcyBub3QgdG8gaGF2
ZSBhbnkgcXVpcmtzIGZvciBtdWx0aWZ1bmN0aW9uDQo+ID4gPiBkZXZpY2VzIHRob3VnaC4gIE9u
IEFNRCBhbmQgSW50ZWwgSU9NTVVzIHdlIHRlc3QgbXVsdGlmdW5jdGlvbiBkZXZpY2UgQUNTDQo+
ID4gPiBzdXBwb3J0IHRvIGRldGVybWluZSB3aGV0aGVyIGFsbCB0aGUgZnVuY3Rpb25zIHNob3Vs
ZCBiZSBpbiB0aGUgc2FtZQ0KPiA+ID4gZ3JvdXAuICBJcyB0aGVyZSBhbnkgcmVhc29uIHRvIHRy
dXN0IG11bHRpZnVuY3Rpb24gZGV2aWNlcyBvbiBQQU1VPw0KPiA+ID4NCj4gPiBbU2V0aGkgVmFy
dW4tQjE2Mzk1XSBJbiB0aGUgY2FzZSB3aGVyZSB3ZSBjYW4gcGFydGl0aW9uIGVuZHBvaW50cyB3
ZQ0KPiA+IGNhbiBkaXN0aW5ndWlzaCB0cmFuc2FjdGlvbnMgYmFzZWQgb24gdGhlIGJ1cyxkZXZp
Y2UsZnVuY3Rpb24gbnVtYmVyDQo+ID4gY29tYmluYXRpb24uIFRoaXMgc3VwcG9ydCBpcyBhdmFp
bGFibGUgaW4gdGhlIFBDSWUgY29udHJvbGxlciAoaG9zdA0KPiA+IGJyaWRnZSkuDQo+IA0KPiBT
byBjYW4geDg2IElPTU1VcywgdGhhdCdzIHRoZSB2aXNpYmlsaXR5IGFzcGVjdCBvZiBJT01NVSBn
cm91cHMuDQo+IFZpc2liaWxpdHkgYWxvbmUgZG9lc24ndCBuZWNlc3NhcmlseSBpbXBseSB0aGF0
IGEgZGV2aWNlIGlzIGlzb2xhdGVkDQo+IHRob3VnaC4gIEEgbXVsdGlmdW5jdGlvbiBQQ0kgZGV2
aWNlIHRoYXQgZG9lc24ndCBleHBvc2UgQUNTIHN1cHBvcnQgbWF5DQo+IG5vdCBpc29sYXRlIGZ1
bmN0aW9ucyBmcm9tIGVhY2ggb3RoZXIuICBGb3IgZXhhbXBsZSBhIHBlZXItdG8tcGVlciBETUEN
Cj4gYmV0d2VlbiBmdW5jdGlvbnMgbWF5IG5vdCBiZSB0cmFuc2xhdGVkIGJ5IHRoZSB1cHN0cmVh
bSBJT01NVS4gIElPTU1VDQo+IGdyb3VwcyBzaG91bGQgZW5jb21wYXNzIGJvdGggdmlzaWJpbGl0
eSBhbmQgaXNvbGF0aW9uLg0KPiANCj4gPiA+IEkgYWxzbyBmaW5kIGl0IGN1cmlvdXMgd2hhdCBo
YXBwZW5zIHRvIHRoZSBpb21tdSBncm91cCBvZiB0aGUgaG9zdA0KPiA+ID4gYnJpZGdlLiAgSW4g
dGhlIHBhcnRpdGlvbmFibGUgY2FzZSB0aGUgaG9zdCBicmlkZ2UgZ3JvdXAgaXMgcmVtb3ZlZCwg
aW4NCj4gPiA+IHRoZSBub24tcGFydGl0aW9uYWJsZSBjYXNlIHRoZSBob3N0IGJyaWRnZSBncm91
cCBiZWNvbWVzIHRoZSBncm91cCBmb3INCj4gPiA+IHRoZSBjaGlsZHJlbiwgcmVtb3ZpbmcgdGhl
IGhvc3QgYnJpZGdlLiAgSXQncyB1bmlxdWUgdG8gUEFNVSBzbyBmYXIgdGhhdA0KPiA+ID4gdGhl
c2UgaG9zdCBicmlkZ2VzIGFyZSBldmVuIGluIGFuIGlvbW11IGdyb3VwICh4ODYgb25seSBhZGRz
IHBjaQ0KPiA+ID4gZGV2aWNlcyksIGJ1dCBJIGRvbid0IHNlZSBpdCBhcyBuZWNlc3NhcmlseSB3
cm9uZyBsZWF2aW5nIGl0IGluIGVpdGhlcg0KPiA+ID4gc2NlbmFyaW8uICBEb2VzIGl0IHNvbHZl
IHNvbWUgcHJvYmxlbSB0byByZW1vdmUgdGhlbSBmcm9tIHRoZSBncm91cHM/DQo+ID4gPiBUaGFu
a3MsDQo+ID4gW1NldGhpIFZhcnVuLUIxNjM5NV0gVGhlIFBDSWUgY29udHJvbGxlciBpc24ndCBh
IHBhcnRpdGlvbmFibGUgZW50aXR5LA0KPiA+IGl0IHdvdWxkIGFsd2F5cyBiZSBvd25lZCBieSB0
aGUgaG9zdC4NCj4gDQo+IE93bmVyc2hpcCBvZiBhIGRldmljZSBzaG91bGRuJ3QgcGxheSBpbnRv
IHRoZSBncm91cCBjb250ZXh0LiAgQW4gSU9NTVUNCj4gZ3JvdXAgc2hvdWxkIGJlIGRlZmluZWQg
YnkgaXQncyB2aXNpYmlsaXR5IGFuZCBpc29sYXRpb24gZnJvbSBvdGhlcg0KPiBkZXZpY2VzLiAg
V2hldGhlciB0aGUgUENJZSBjb250cm9sbGVyIGlzIGFsbG93ZWQgdG8gYmUgaGFuZGVkIHRvDQo+
IHVzZXJzcGFjZSBpcyBhIHF1ZXN0aW9uIGZvciBWRklPLiAgVGhhbmtzLA0KDQpSaWdodCBub3cg
dGhlIGFkZF9kZXZpY2UoKSBjYWxsYmFjayBnZXRzIGNhbGxlZCBmb3IgYWxsIHBsYXRmb3JtDQpk
ZXZpY2VzIChpbmNsdWRpbmcgUENJIGNvbnRyb2xsZXIpIGFuZCBQQ0kgZGV2aWNlcy4gIFBDSSBj
b250cm9sbGVycw0KYXJlIGEga2luZCBvZiBzcGVjaWFsIGNhc2UgaW4gdGhhdCB0aGVpciBkZXZp
Y2UgdHJlZSBub2RlIGhhcyBhDQpwcm9wZXJ0eSBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgRE1BIGNh
cGFibGUuLi5idXQgaW4gZmFjdCB0aGUNClBDSSBjb250cm9sbGVyIGl0c2VsZiBkb2VzIG5vdCBE
TUEsIGJ1dCBpdCdzIHRoZSBQQ0kgZW5kcG9pbnRzDQp1bmRlciBpdC4NCg0KU28sIGFzIHlvdSBu
b3RlZCB0aGUgYnJpZGdlL2NvbnRyb2xsZXIgc2hvdWxkbid0IGJlIGluIGFuIElPTU1VDQpncm91
cCBhbmQgc28gc2luY2UgdGhlIHBsYXRmb3JtICdhZGQgZGV2aWNlJyBjb2RlIGRpZG4ndCBzcGVj
aWFsDQpjYXNlIFBDSSBjb250cm9sbGVycywgdGhpcyBwYXRjaCByZW1vdmVzIHRoZWlyIGdyb3Vw
IGlmIGl0J3MgdGhlcmUuDQoNClN0dWFydA0K
^ permalink raw reply
* RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-04-04 16:35 UTC (permalink / raw)
To: Alex Williamson
Cc: Wood Scott-B07421, Joerg Roedel, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1365088930.2882.296.camel@bling.home>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBXaWxsaWFtc29u
IFttYWlsdG86YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBB
cHJpbCAwNCwgMjAxMyA4OjUyIFBNDQo+IFRvOiBTZXRoaSBWYXJ1bi1CMTYzOTUNCj4gQ2M6IEpv
ZXJnIFJvZWRlbDsgWW9kZXIgU3R1YXJ0LUIwODI0ODsgV29vZCBTY290dC1CMDc0MjE7DQo+IGlv
bW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJz
Lm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGdhbGFrQGtlcm5lbC5jcmFz
aGluZy5vcmc7DQo+IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BB
VENIIDUvNSB2MTFdIGlvbW11L2ZzbDogRnJlZXNjYWxlIFBBTVUgZHJpdmVyIGFuZCBpb21tdQ0K
PiBpbXBsZW1lbnRhdGlvbi4NCj4gDQo+IE9uIFRodSwgMjAxMy0wNC0wNCBhdCAxMzowMCArMDAw
MCwgU2V0aGkgVmFydW4tQjE2Mzk1IHdyb3RlOg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQWxleCBXaWxsaWFtc29uIFttYWlsdG86YWxleC53aWxs
aWFtc29uQHJlZGhhdC5jb21dDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDAzLCAyMDEz
IDExOjMyIFBNDQo+ID4gPiBUbzogSm9lcmcgUm9lZGVsDQo+ID4gPiBDYzogU2V0aGkgVmFydW4t
QjE2Mzk1OyBZb2RlciBTdHVhcnQtQjA4MjQ4OyBXb29kIFNjb3R0LUIwNzQyMTsNCj4gPiA+IGlv
bW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJz
Lm9yZzsNCj4gPiA+IGxpbnV4LSBrZXJuZWxAdmdlci5rZXJuZWwub3JnOyBnYWxha0BrZXJuZWwu
Y3Jhc2hpbmcub3JnOw0KPiA+ID4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnDQo+ID4gPiBTdWJq
ZWN0OiBSZTogW1BBVENIIDUvNSB2MTFdIGlvbW11L2ZzbDogRnJlZXNjYWxlIFBBTVUgZHJpdmVy
IGFuZA0KPiA+ID4gaW9tbXUgaW1wbGVtZW50YXRpb24uDQo+ID4gPg0KPiA+ID4gT24gVHVlLCAy
MDEzLTA0LTAyIGF0IDE4OjE4ICswMjAwLCBKb2VyZyBSb2VkZWwgd3JvdGU6DQo+ID4gPiA+IENj
J2luZyBBbGV4IFdpbGxpYW1zb24NCj4gPiA+ID4NCj4gPiA+ID4gQWxleCwgY2FuIHlvdSBwbGVh
c2UgcmV2aWV3IHRoZSBpb21tdS1ncm91cCBwYXJ0IG9mIHRoaXMgcGF0Y2g/DQo+ID4gPg0KPiA+
ID4gU3VyZSwgaXQgbG9va3MgcHJldHR5IHJlYXNvbmFibGUuICBBSVVJLCBhbGwgUENJIGRldmlj
ZXMgYXJlIGJlbG93DQo+ID4gPiBzb21lIGtpbmQgb2YgaG9zdCBicmlkZ2UgdGhhdCBpcyBlaXRo
ZXIgbmV3IGFuZCBzdXBwb3J0cw0KPiA+ID4gcGFydGl0aW9uaW5nIG9yIG9sZCBhbmQgZG9lc24n
dC4gIEkgZG9uJ3Qga25vdyBpZiB0aGF0J3MgYQ0KPiA+ID4gdmlzaWJpbGl0eSBvciBpc29sYXRp
b24gcmVxdWlyZW1lbnQsIHBlcmhhcHMgUENJIEFDUy1pc2guICBJbiB0aGUNCj4gPiA+IG5ldyBo
b3N0IGJyaWRnZSBjYXNlLCBlYWNoIGRldmljZSBnZXRzIGEgZ3JvdXAuICBUaGlzIHNlZW1zIG5v
dCB0bw0KPiA+ID4gaGF2ZSBhbnkgcXVpcmtzIGZvciBtdWx0aWZ1bmN0aW9uIGRldmljZXMgdGhv
dWdoLiAgT24gQU1EIGFuZCBJbnRlbA0KPiA+ID4gSU9NTVVzIHdlIHRlc3QgbXVsdGlmdW5jdGlv
biBkZXZpY2UgQUNTIHN1cHBvcnQgdG8gZGV0ZXJtaW5lIHdoZXRoZXINCj4gPiA+IGFsbCB0aGUg
ZnVuY3Rpb25zIHNob3VsZCBiZSBpbiB0aGUgc2FtZSBncm91cC4gIElzIHRoZXJlIGFueSByZWFz
b24NCj4gdG8gdHJ1c3QgbXVsdGlmdW5jdGlvbiBkZXZpY2VzIG9uIFBBTVU/DQo+ID4gPg0KPiA+
IFtTZXRoaSBWYXJ1bi1CMTYzOTVdIEluIHRoZSBjYXNlIHdoZXJlIHdlIGNhbiBwYXJ0aXRpb24g
ZW5kcG9pbnRzIHdlDQo+ID4gY2FuIGRpc3Rpbmd1aXNoIHRyYW5zYWN0aW9ucyBiYXNlZCBvbiB0
aGUgYnVzLGRldmljZSxmdW5jdGlvbiBudW1iZXINCj4gPiBjb21iaW5hdGlvbi4gVGhpcyBzdXBw
b3J0IGlzIGF2YWlsYWJsZSBpbiB0aGUgUENJZSBjb250cm9sbGVyIChob3N0DQo+ID4gYnJpZGdl
KS4NCj4gDQo+IFNvIGNhbiB4ODYgSU9NTVVzLCB0aGF0J3MgdGhlIHZpc2liaWxpdHkgYXNwZWN0
IG9mIElPTU1VIGdyb3Vwcy4NCj4gVmlzaWJpbGl0eSBhbG9uZSBkb2Vzbid0IG5lY2Vzc2FyaWx5
IGltcGx5IHRoYXQgYSBkZXZpY2UgaXMgaXNvbGF0ZWQNCj4gdGhvdWdoLiAgQSBtdWx0aWZ1bmN0
aW9uIFBDSSBkZXZpY2UgdGhhdCBkb2Vzbid0IGV4cG9zZSBBQ1Mgc3VwcG9ydCBtYXkNCj4gbm90
IGlzb2xhdGUgZnVuY3Rpb25zIGZyb20gZWFjaCBvdGhlci4gIEZvciBleGFtcGxlIGEgcGVlci10
by1wZWVyIERNQQ0KPiBiZXR3ZWVuIGZ1bmN0aW9ucyBtYXkgbm90IGJlIHRyYW5zbGF0ZWQgYnkg
dGhlIHVwc3RyZWFtIElPTU1VLiAgSU9NTVUNCj4gZ3JvdXBzIHNob3VsZCBlbmNvbXBhc3MgYm90
aCB2aXNpYmlsaXR5IGFuZCBpc29sYXRpb24uDQpbU2V0aGkgVmFydW4tQjE2Mzk1XSBXZSBjYW4g
aXNvbGF0ZSB0aGUgRE1BIGFjY2VzcyB0byB0aGUgaG9zdCBiYXNlZCBvbiB0aGUgdG8gdGhlIHBj
aSBidXMsZGV2aWNlLGZ1bmN0aW9uIG51bWJlci4NCkkgdGhvdWdodCB0aGF0IHdhcyBlbm91Z2gg
dG8gcHV0IGRldmljZXMgaW4gdG8gc2VwYXJhdGUgaW9tbXUgZ3JvdXBzLiBUaGlzIGlzIGEgUENJ
ZSBjb250cm9sbGVyIHByb3BlcnR5IHdoaWNoIGFsbG93cyB1cyB0byBwYXJ0aXRpb24gUENJZSBk
ZXZpY2VzLiBCdXQsIHdoYXQgSSBjYW4gdW5kZXJzdGFuZCBmcm9tIHlvdXIgcG9pbnQgaXMgdGhh
dCB3ZSBhbHNvIG5lZWQgdG8gY29uc2lkZXIgaXNvbGF0aW9uIGF0IFBDSWUgZGV2aWNlIGxldmVs
IGFzIHdlbGwuIEkgd2lsbCBjaGVjayBmb3IgdGhlIGNhc2Ugb2YgbXVsdGlmdW5jdGlvbiBkZXZp
Y2VzLg0KDQo+IA0KPiA+ID4gSSBhbHNvIGZpbmQgaXQgY3VyaW91cyB3aGF0IGhhcHBlbnMgdG8g
dGhlIGlvbW11IGdyb3VwIG9mIHRoZSBob3N0DQo+ID4gPiBicmlkZ2UuICBJbiB0aGUgcGFydGl0
aW9uYWJsZSBjYXNlIHRoZSBob3N0IGJyaWRnZSBncm91cCBpcyByZW1vdmVkLA0KPiA+ID4gaW4g
dGhlIG5vbi1wYXJ0aXRpb25hYmxlIGNhc2UgdGhlIGhvc3QgYnJpZGdlIGdyb3VwIGJlY29tZXMg
dGhlDQo+ID4gPiBncm91cCBmb3IgdGhlIGNoaWxkcmVuLCByZW1vdmluZyB0aGUgaG9zdCBicmlk
Z2UuICBJdCdzIHVuaXF1ZSB0bw0KPiA+ID4gUEFNVSBzbyBmYXIgdGhhdCB0aGVzZSBob3N0IGJy
aWRnZXMgYXJlIGV2ZW4gaW4gYW4gaW9tbXUgZ3JvdXAgKHg4Ng0KPiA+ID4gb25seSBhZGRzIHBj
aSBkZXZpY2VzKSwgYnV0IEkgZG9uJ3Qgc2VlIGl0IGFzIG5lY2Vzc2FyaWx5IHdyb25nDQo+ID4g
PiBsZWF2aW5nIGl0IGluIGVpdGhlciBzY2VuYXJpby4gIERvZXMgaXQgc29sdmUgc29tZSBwcm9i
bGVtIHRvIHJlbW92ZQ0KPiB0aGVtIGZyb20gdGhlIGdyb3Vwcz8NCj4gPiA+IFRoYW5rcywNCj4g
PiBbU2V0aGkgVmFydW4tQjE2Mzk1XSBUaGUgUENJZSBjb250cm9sbGVyIGlzbid0IGEgcGFydGl0
aW9uYWJsZSBlbnRpdHksDQo+ID4gaXQgd291bGQgYWx3YXlzIGJlIG93bmVkIGJ5IHRoZSBob3N0
Lg0KPiANCj4gT3duZXJzaGlwIG9mIGEgZGV2aWNlIHNob3VsZG4ndCBwbGF5IGludG8gdGhlIGdy
b3VwIGNvbnRleHQuICBBbiBJT01NVQ0KPiBncm91cCBzaG91bGQgYmUgZGVmaW5lZCBieSBpdCdz
IHZpc2liaWxpdHkgYW5kIGlzb2xhdGlvbiBmcm9tIG90aGVyDQo+IGRldmljZXMuICBXaGV0aGVy
IHRoZSBQQ0llIGNvbnRyb2xsZXIgaXMgYWxsb3dlZCB0byBiZSBoYW5kZWQgdG8NCj4gdXNlcnNw
YWNlIGlzIGEgcXVlc3Rpb24gZm9yIFZGSU8uDQpbU2V0aGkgVmFydW4tQjE2Mzk1XSBUaGUgcHJv
YmxlbSBpcyBpbiB0aGUgY2FzZSwgd2hlcmUgd2UgY2FuJ3QgcGFydGl0aW9uIFBDSWUgZGV2aWNl
cy4gUENJZSBkZXZpY2VzIHNoYXJlIHRoZSBzYW1lIGRldmljZSBncm91cCBhcyB0aGUgUENJIGNv
bnRyb2xsZXIuIFRoaXMgYmVjb21lcyBhIHByb2JsZW0gd2hpbGUgYXNzaWduaW5nIHRoZSBkZXZp
Y2VzIHRvIHRoZSBndWVzdCwgYXMgeW91IGFyZSByZXF1aXJlZCB0byB1bmJpbmQgYWxsIHRoZSBQ
Q0llIGRldmljZXMgaW5jbHVkaW5nIHRoZSBjb250cm9sbGVyIGZyb20gdGhlIGhvc3QuIFBDSWUg
Y29udHJvbGxlciBjYW4ndCBiZSB1bmJvdW5kIGZyb20gdGhlIGhvc3QsIHNvIHdlIHNpbXBseSBk
ZWxldGUgdGhlIGNvbnRyb2xsZXIgaW9tbXVfZ3JvdXAuDQoNCi1WYXJ1bg0KIA0KDQo=
^ permalink raw reply
* Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Alex Williamson @ 2013-04-04 15:22 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Wood Scott-B07421, Joerg Roedel, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D45883B@039-SN2MPN1-013.039d.mgd.msft.net>
On Thu, 2013-04-04 at 13:00 +0000, Sethi Varun-B16395 wrote:
>
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Wednesday, April 03, 2013 11:32 PM
> > To: Joerg Roedel
> > Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421;
> > iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> > kernel@vger.kernel.org; galak@kernel.crashing.org;
> > benh@kernel.crashing.org
> > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> > implementation.
> >
> > On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote:
> > > Cc'ing Alex Williamson
> > >
> > > Alex, can you please review the iommu-group part of this patch?
> >
> > Sure, it looks pretty reasonable. AIUI, all PCI devices are below some
> > kind of host bridge that is either new and supports partitioning or old
> > and doesn't. I don't know if that's a visibility or isolation
> > requirement, perhaps PCI ACS-ish. In the new host bridge case, each
> > device gets a group. This seems not to have any quirks for multifunction
> > devices though. On AMD and Intel IOMMUs we test multifunction device ACS
> > support to determine whether all the functions should be in the same
> > group. Is there any reason to trust multifunction devices on PAMU?
> >
> [Sethi Varun-B16395] In the case where we can partition endpoints we
> can distinguish transactions based on the bus,device,function number
> combination. This support is available in the PCIe controller (host
> bridge).
So can x86 IOMMUs, that's the visibility aspect of IOMMU groups.
Visibility alone doesn't necessarily imply that a device is isolated
though. A multifunction PCI device that doesn't expose ACS support may
not isolate functions from each other. For example a peer-to-peer DMA
between functions may not be translated by the upstream IOMMU. IOMMU
groups should encompass both visibility and isolation.
> > I also find it curious what happens to the iommu group of the host
> > bridge. In the partitionable case the host bridge group is removed, in
> > the non-partitionable case the host bridge group becomes the group for
> > the children, removing the host bridge. It's unique to PAMU so far that
> > these host bridges are even in an iommu group (x86 only adds pci
> > devices), but I don't see it as necessarily wrong leaving it in either
> > scenario. Does it solve some problem to remove them from the groups?
> > Thanks,
> [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity,
> it would always be owned by the host.
Ownership of a device shouldn't play into the group context. An IOMMU
group should be defined by it's visibility and isolation from other
devices. Whether the PCIe controller is allowed to be handed to
userspace is a question for VFIO. Thanks,
Alex
^ permalink raw reply
* RE: [PATCH] bookehv: Handle debug exception on guest exit
From: Bhushan Bharat-R65777 @ 2013-04-04 14:58 UTC (permalink / raw)
To: Alexander Graf
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <436085E0-D605-40C1-BCDF-EB4D24B01AFA@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, April 04, 2013 6:55 PM
> To: Bhushan Bharat-R65777
> Cc: linuxppc-dev@lists.ozlabs.org; kvm@vger.kernel.org; kvm-ppc@vger.kern=
el.org;
> Wood Scott-B07421; Bhushan Bharat-R65777
> Subject: Re: [PATCH] bookehv: Handle debug exception on guest exit
>=20
>=20
> On 20.03.2013, at 18:45, Bharat Bhushan wrote:
>=20
> > EPCR.DUVD controls whether the debug events can come in hypervisor
> > mode or not. When KVM guest is using the debug resource then we do not
> > want debug events to be captured in guest entry/exit path. So we set
> > EPCR.DUVD when entering and clears EPCR.DUVD when exiting from guest.
> >
> > Debug instruction complete is a post-completion debug exception but
> > debug event gets posted on the basis of MSR before the instruction is
> > executed. Now if the instruction switches the context from guest mode
> > (MSR.GS =3D 1) to hypervisor mode (MSR.GS =3D 0) then the xSRR0 points =
to
> > first instruction of KVM handler and xSRR1 points that MSR.GS is clear
> > (hypervisor context). Now as xSRR1.GS is used to decide whether KVM
> > handler will be invoked to handle the exception or host host kernel
> > debug handler will be invoked to handle the exception.
> > This leads to host kernel debug handler handling the exception which
> > should either be handled by KVM.
> >
> > This is tested on e500mc in 32 bit mode
> >
> > Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> > ---
> > v0:
> > - Do not apply this change for debug_crit as we do not know those chips=
have
> issue or not.
> > - corrected 64bit case branching
> >
> > arch/powerpc/kernel/exceptions-64e.S | 29 +++++++++++++++++++++++++++=
+-
> > arch/powerpc/kernel/head_booke.h | 26 ++++++++++++++++++++++++++
> > 2 files changed, 54 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/exceptions-64e.S
> > b/arch/powerpc/kernel/exceptions-64e.S
> > index 4684e33..8b26294 100644
> > --- a/arch/powerpc/kernel/exceptions-64e.S
> > +++ b/arch/powerpc/kernel/exceptions-64e.S
> > @@ -516,6 +516,33 @@ kernel_dbg_exc:
> > andis. r15,r14,DBSR_IC@h
> > beq+ 1f
> >
> > +#ifdef CONFIG_KVM_BOOKE_HV
> > + /*
> > + * EPCR.DUVD controls whether the debug events can come in
> > + * hypervisor mode or not. When KVM guest is using the debug
> > + * resource then we do not want debug events to be captured
> > + * in guest entry/exit path. So we set EPCR.DUVD when entering
> > + * and clears EPCR.DUVD when exiting from guest.
> > + * Debug instruction complete is a post-completion debug
> > + * exception but debug event gets posted on the basis of MSR
> > + * before the instruction is executed. Now if the instruction
> > + * switches the context from guest mode (MSR.GS =3D 1) to hypervisor
> > + * mode (MSR.GS =3D 0) then the xSRR0 points to first instruction of
>=20
> Can't we just execute that code path with MSR.DE=3D0?
Single stepping uses DBCR0.IC (instruction complete).
Can you describe how MSR.DE =3D 0 will work?
>=20
>=20
> Alex
>=20
> > + * KVM handler and xSRR1 points that MSR.GS is clear
> > + * (hypervisor context). Now as xSRR1.GS is used to decide whether
> > + * KVM handler will be invoked to handle the exception or host
> > + * host kernel debug handler will be invoked to handle the exception.
> > + * This leads to host kernel debug handler handling the exception
> > + * which should either be handled by KVM.
> > + */
> > + mfspr r10, SPRN_EPCR
> > + andis. r10,r10,SPRN_EPCR_DUVD@h
> > + beq+ 2f
> > +
> > + andis. r10,r9,MSR_GS@h
> > + beq+ 3f
> > +2:
> > +#endif
> > LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
> > LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e)
> > cmpld cr0,r10,r14
> > @@ -523,7 +550,7 @@ kernel_dbg_exc:
> > blt+ cr0,1f
> > bge+ cr1,1f
> >
> > - /* here it looks like we got an inappropriate debug exception. */
> > +3: /* here it looks like we got an inappropriate debug exception. */
> > lis r14,DBSR_IC@h /* clear the IC event */
> > rlwinm r11,r11,0,~MSR_DE /* clear DE in the DSRR1 value */
> > mtspr SPRN_DBSR,r14
> > diff --git a/arch/powerpc/kernel/head_booke.h
> > b/arch/powerpc/kernel/head_booke.h
> > index 5f051ee..edc6a3b 100644
> > --- a/arch/powerpc/kernel/head_booke.h
> > +++ b/arch/powerpc/kernel/head_booke.h
> > @@ -285,7 +285,33 @@ label:
> > mfspr r10,SPRN_DBSR; /* check single-step/branch taken */ \
> > andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \
> > beq+ 2f; \
> > +#ifdef CONFIG_KVM_BOOKE_HV \
> > + /* \
> > + * EPCR.DUVD controls whether the debug events can come in \
> > + * hypervisor mode or not. When KVM guest is using the debug \
> > + * resource then we do not want debug events to be captured \
> > + * in guest entry/exit path. So we set EPCR.DUVD when entering =
\
> > + * and clears EPCR.DUVD when exiting from guest. \
> > + * Debug instruction complete is a post-completion debug \
> > + * exception but debug event gets posted on the basis of MSR \
> > + * before the instruction is executed. Now if the instruction \
> > + * switches the context from guest mode (MSR.GS =3D 1) to hypervisor =
\
> > + * mode (MSR.GS =3D 0) then the xSRR0 points to first instruction of =
\
> > + * KVM handler and xSRR1 points that MSR.GS is clear \
> > + * (hypervisor context). Now as xSRR1.GS is used to decide whether =
\
> > + * KVM handler will be invoked to handle the exception or host =
\
> > + * host kernel debug handler will be invoked to handle the exception.=
\
> > + * This leads to host kernel debug handler handling the exception =
\
> > + * which should either be handled by KVM. \
> > + */ \
> > + mfspr r10, SPRN_EPCR; \
> > + andis. r10,r10,SPRN_EPCR_DUVD@h; \
> > + beq+ 3f; \
> > \
> > + andis. r10,r9,MSR_GS@h; \
> > + beq+ 1f; \
> > +3: \
> > +#endif \
> > lis r10,KERNELBASE@h; /* check if exception in vectors */ \
> > ori r10,r10,KERNELBASE@l; \
> > cmplw r12,r10; \
> > --
> > 1.7.0.4
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> > the body of a message to majordomo@vger.kernel.org More majordomo info
> > at http://vger.kernel.org/majordomo-info.html
>=20
^ permalink raw reply
* [PATCH] Adjunct partition test
From: Michael Wolf @ 2013-04-04 14:53 UTC (permalink / raw)
To: linuxppc-dev
Some versions pHyp will perform the adjunct partition test before the
ANDCOND test. The result of this is that H_RESOURCE can be returned and
cause the BUG_ON condition to occur. So add a check for H_RESOURCE as
well.
Signed-off-by: Michael Wolf <mjw@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index c9a29da..724fa0b 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -185,7 +185,13 @@ static long pSeries_lpar_hpte_remove(unsigned long hpte_group)
(0x1UL << 4), &dummy1, &dummy2);
if (lpar_rc == H_SUCCESS)
return i;
- BUG_ON(lpar_rc != H_NOT_FOUND);
+
+ /*
+ * The test for adjunct partition is performed before the
+ * ANDCOND test. H_RESOURCE may be returned, so we need to
+ * check for that as well.
+ */
+ BUG_ON(lpar_rc != H_NOT_FOUND && lpar_rc != H_RESOURCE);
slot_offset++;
slot_offset &= 0x7;
^ permalink raw reply related
* Re: [PATCH 18/18] cpufreq: powerpc/platforms/cell: move cpufreq driver to drivers/cpufreq
From: Arnd Bergmann @ 2013-04-04 14:48 UTC (permalink / raw)
To: Viresh Kumar
Cc: robin.randhawa, linux-pm, patches, Liviu.Dudau, linux-kernel,
cpufreq, rjw, Steve.Bannister, arvind.chauhan, linuxppc-dev,
linaro-kernel, charles.garcia-tobin
In-Reply-To: <CAKohpok_ftPoME0tFRMWMM9A2mNSOpQSvbJut0=AzhCuB-Yjrg@mail.gmail.com>
On Thursday 04 April 2013, Viresh Kumar wrote:
>
> On 4 April 2013 18:32, Arnd Bergmann <arnd@arndb.de> wrote:
> > Moving the files is good, but I don't see a reason to make the cbe_cpufreq.h
> > header globally visible in include/linux/. Isn't it just used by as the
> > interface between ppc_cbe_cpufreq_pmi.c and ppc_cbe_cpufreq.c?
>
> When i moved it initially i thought it is also used by
> arch/powerpc/platforms/cell/cpufreq_spudemand.c and hence moved it
> to include/linux and never realized i am wrong..
>
> Here is the fixup (And attached complete patch: original+fixup for Rafael
> to apply):
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v3 3/3] powerpc/mpc512x: add platform code for MPC5125.
From: Matteo Facchinetti @ 2013-04-04 13:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: agust
Tested on MPC5125 Tower evaluation board with
mpc512x_defconfig compile configuration.
In detail, supports for:
- PSC / UART
- RTC
- ETH
- DIU
- I2C
Signed-off-by: Matteo Facchinetti <matteo.facchinetti@sirius-es.it>
---
v2:
* change mpc512x_select_psc_compat() implementation
and fix it using const char* return
* drop device_type and port-number properties in mpc5125twr.dts
* add "fsl,mpc5121" and "fsl,mpc5125" in mpc512x dts files
* change reset module name in mpc5125twr.dts (different from mpc5121)
---
v3:
* fix i2c compatible in mpc5125twr.dts changing
from "fsl-i2c" to "fsl,mpc5121-i2c", "fsl-i2c"
---
arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
arch/powerpc/boot/dts/mpc5125twr.dts | 233 +++++++++++++++++++++++++
arch/powerpc/boot/dts/pdm360ng.dts | 2 +-
arch/powerpc/platforms/512x/clock.c | 9 +-
arch/powerpc/platforms/512x/mpc512x.h | 1 +
arch/powerpc/platforms/512x/mpc512x_generic.c | 1 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 20 ++-
7 files changed, 264 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc5125twr.dts
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index f269b13..7d3cb79 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -13,7 +13,7 @@
/ {
model = "mpc5121ads";
- compatible = "fsl,mpc5121ads";
+ compatible = "fsl,mpc5121ads", "fsl,mpc5121";
nfc@40000000 {
/*
diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts b/arch/powerpc/boot/dts/mpc5125twr.dts
new file mode 100644
index 0000000..4177b62
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc5125twr.dts
@@ -0,0 +1,233 @@
+/*
+ * STx/Freescale ADS5125 MPC5125 silicon
+ *
+ * Copyright (C) 2009 Freescale Semiconductor Inc. All rights reserved.
+ *
+ * Reworked by Matteo Facchinetti (engineering@sirius-es.it)
+ * Copyright (C) 2013 Sirius Electronic Systems
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "mpc5125twr"; // In BSP "mpc5125ads"
+ compatible = "fsl,mpc5125ads", "fsl,mpc5125";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&ipic>;
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ ethernet0 = ð0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5125@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>; // L1, 32K
+ i-cache-size = <0x8000>; // L1, 32K
+ timebase-frequency = <49500000>;// 49.5 MHz (csb/4)
+ bus-frequency = <198000000>; // 198 MHz csb bus
+ clock-frequency = <396000000>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>; // 256MB at 0
+ };
+
+ sram@30000000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x30000000 0x08000>; // 32K at 0x30000000
+ };
+
+ soc@80000000 {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x80000000 0x400000>;
+ reg = <0x80000000 0x400000>;
+ bus-frequency = <66000000>; // 66 MHz ips bus
+
+ // IPIC
+ // interrupts cell = <intr #, sense>
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: interrupt-controller@c00 {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ rtc@a00 { // Real time clock
+ compatible = "fsl,mpc5121-rtc";
+ reg = <0xa00 0x100>;
+ interrupts = <79 0x8 80 0x8>;
+ };
+
+ reset@e00 { // Reset module
+ compatible = "fsl,mpc5125-reset";
+ reg = <0xe00 0x100>;
+ };
+
+ clock@f00 { // Clock control
+ compatible = "fsl,mpc5121-clock";
+ reg = <0xf00 0x100>;
+ };
+
+ pmc@1000{ // Power Management Controller
+ compatible = "fsl,mpc5121-pmc";
+ reg = <0x1000 0x100>;
+ interrupts = <83 0x2>;
+ };
+
+ gpio0: gpio@1100 {
+ compatible = "fsl,mpc5125-gpio";
+ reg = <0x1100 0x080>;
+ interrupts = <78 0x8>;
+ };
+
+ gpio1: gpio@1180 {
+ compatible = "fsl,mpc5125-gpio";
+ reg = <0x1180 0x080>;
+ interrupts = <86 0x8>;
+ };
+
+ can@1300 { // CAN rev.2
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <12 0x8>;
+ reg = <0x1300 0x80>;
+ };
+
+ can@1380 {
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <13 0x8>;
+ reg = <0x1380 0x80>;
+ };
+
+ sdhc@1500 {
+ compatible = "fsl,mpc5121-sdhc";
+ interrupts = <8 0x8>;
+ reg = <0x1500 0x100>;
+ };
+
+ i2c@1700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ reg = <0x1700 0x20>;
+ interrupts = <0x9 0x8>;
+ };
+
+ i2c@1720 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ reg = <0x1720 0x20>;
+ interrupts = <0xa 0x8>;
+ };
+
+ i2c@1740 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ reg = <0x1740 0x20>;
+ interrupts = <0xb 0x8>;
+ };
+
+ i2ccontrol@1760 {
+ compatible = "fsl,mpc5121-i2c-ctrl";
+ reg = <0x1760 0x8>;
+ };
+
+ diu@2100 {
+ compatible = "fsl,mpc5121-diu";
+ reg = <0x2100 0x100>;
+ interrupts = <64 0x8>;
+ };
+
+ mdio@2800 {
+ compatible = "fsl,mpc5121-fec-mdio";
+ reg = <0x2800 0x800>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ };
+
+ eth0: ethernet@2800 {
+ compatible = "fsl,mpc5125-fec";
+ reg = <0x2800 0x800>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <4 0x8>;
+ phy-handle = < &phy0 >;
+ phy-connection-type = "rmii";
+ };
+
+ // IO control
+ ioctl@a000 {
+ compatible = "fsl,mpc5125-ioctl";
+ reg = <0xA000 0x1000>;
+ };
+
+ usb@3000 {
+ compatible = "fsl,mpc5121-usb2-dr";
+ reg = <0x3000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <43 0x8>;
+ dr_mode = "host";
+ phy_type = "ulpi";
+ };
+
+ // 5125 PSCs are not 52xx or 5121 PSC compatible
+ // PSC1 uart0 aka ttyPSC0
+ serial@11100 {
+ compatible = "fsl,mpc5125-psc-uart", "fsl,mpc5125-psc";
+ reg = <0x11100 0x100>;
+ interrupts = <40 0x8>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ // PSC9 uart1 aka ttyPSC1
+ serial@11900 {
+ compatible = "fsl,mpc5125-psc-uart", "fsl,mpc5125-psc";
+ reg = <0x11900 0x100>;
+ interrupts = <40 0x8>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ pscfifo@11f00 {
+ compatible = "fsl,mpc5121-psc-fifo";
+ reg = <0x11f00 0x100>;
+ interrupts = <40 0x8>;
+ };
+
+ dma@14000 {
+ compatible = "fsl,mpc5121-dma"; // BSP name: "mpc512x-dma2"
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
index 0b06947..7433740 100644
--- a/arch/powerpc/boot/dts/pdm360ng.dts
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -17,7 +17,7 @@
/ {
model = "pdm360ng";
- compatible = "ifm,pdm360ng";
+ compatible = "ifm,pdm360ng", "fsl,mpc5121";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&ipic>;
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
index 52d57d2..e504166 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -29,6 +29,8 @@
#include <asm/mpc5121.h>
#include <asm/clk_interface.h>
+#include "mpc512x.h"
+
#undef CLK_DEBUG
static int clocks_initialized;
@@ -683,8 +685,13 @@ static void psc_clks_init(void)
struct device_node *np;
struct platform_device *ofdev;
u32 reg;
+ const char *psc_compat;
+
+ psc_compat = mpc512x_select_psc_compat();
+ if (!psc_compat)
+ return;
- for_each_compatible_node(np, NULL, "fsl,mpc5121-psc") {
+ for_each_compatible_node(np, NULL, psc_compat) {
if (!of_property_read_u32(np, "reg", ®)) {
int pscnum = (reg & 0xf00) >> 8;
struct clk *clk = psc_dev_clk(pscnum);
diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
index c32b399..0a8e600 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -15,6 +15,7 @@ extern void __init mpc512x_init_IRQ(void);
extern void __init mpc512x_init(void);
extern int __init mpc5121_clk_init(void);
void __init mpc512x_declare_of_platform_devices(void);
+extern const char *mpc512x_select_psc_compat(void);
extern void mpc512x_restart(char *cmd);
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
diff --git a/arch/powerpc/platforms/512x/mpc512x_generic.c b/arch/powerpc/platforms/512x/mpc512x_generic.c
index ca1ca66..1ca7b61 100644
--- a/arch/powerpc/platforms/512x/mpc512x_generic.c
+++ b/arch/powerpc/platforms/512x/mpc512x_generic.c
@@ -28,6 +28,7 @@
*/
static const char * const board[] __initconst = {
"prt,prtlvt",
+ "fsl,mpc5125ads",
NULL
};
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index d30235b..1ef2fa1 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -350,6 +350,17 @@ void __init mpc512x_declare_of_platform_devices(void)
#define DEFAULT_FIFO_SIZE 16
+const char *mpc512x_select_psc_compat(void)
+{
+ if (of_machine_is_compatible("fsl,mpc5121"))
+ return "fsl,mpc5121-psc";
+
+ if (of_machine_is_compatible("fsl,mpc5125"))
+ return "fsl,mpc5125-psc";
+
+ return NULL;
+}
+
static unsigned int __init get_fifo_size(struct device_node *np,
char *prop_name)
{
@@ -375,9 +386,16 @@ void __init mpc512x_psc_fifo_init(void)
void __iomem *psc;
unsigned int tx_fifo_size;
unsigned int rx_fifo_size;
+ const char *psc_compat;
int fifobase = 0; /* current fifo address in 32 bit words */
- for_each_compatible_node(np, NULL, "fsl,mpc5121-psc") {
+ psc_compat = mpc512x_select_psc_compat();
+ if (!psc_compat) {
+ pr_err("%s: no compatible devices found\n", __func__);
+ return;
+ }
+
+ for_each_compatible_node(np, NULL, psc_compat) {
tx_fifo_size = get_fifo_size(np, "fsl,tx-fifo-size");
rx_fifo_size = get_fifo_size(np, "fsl,rx-fifo-size");
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 18/18] cpufreq: powerpc/platforms/cell: move cpufreq driver to drivers/cpufreq
From: Viresh Kumar @ 2013-04-04 13:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: robin.randhawa, linux-pm, patches, Liviu.Dudau, linux-kernel,
cpufreq, rjw, Steve.Bannister, arvind.chauhan, linuxppc-dev,
linaro-kernel, charles.garcia-tobin
In-Reply-To: <201304041302.09995.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]
On 4 April 2013 18:32, Arnd Bergmann <arnd@arndb.de> wrote:
> Moving the files is good, but I don't see a reason to make the cbe_cpufreq.h
> header globally visible in include/linux/. Isn't it just used by as the
> interface between ppc_cbe_cpufreq_pmi.c and ppc_cbe_cpufreq.c?
When i moved it initially i thought it is also used by
arch/powerpc/platforms/cell/cpufreq_spudemand.c and hence moved it
to include/linux and never realized i am wrong..
Here is the fixup (And attached complete patch: original+fixup for Rafael
to apply):
Compile tested only.
---
drivers/cpufreq/ppc_cbe_cpufreq.c | 3 ++-
{include/linux => drivers/cpufreq}/ppc_cbe_cpufreq.h | 0
drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c | 3 ++-
drivers/cpufreq/ppc_cbe_cpufreq_pmi.c | 3 ++-
4 files changed, 6 insertions(+), 3 deletions(-)
rename {include/linux => drivers/cpufreq}/ppc_cbe_cpufreq.h (100%)
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq.c
b/drivers/cpufreq/ppc_cbe_cpufreq.c
index 138d88c..56e0c17 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq.c
@@ -23,12 +23,13 @@
#include <linux/cpufreq.h>
#include <linux/module.h>
#include <linux/of_platform.h>
-#include <linux/ppc_cbe_cpufreq.h>
#include <asm/machdep.h>
#include <asm/prom.h>
#include <asm/cell-regs.h>
+#include "ppc_cbe_cpufreq.h"
+
static DEFINE_MUTEX(cbe_switch_mutex);
diff --git a/include/linux/ppc_cbe_cpufreq.h b/drivers/cpufreq/ppc_cbe_cpufreq.h
similarity index 100%
rename from include/linux/ppc_cbe_cpufreq.h
rename to drivers/cpufreq/ppc_cbe_cpufreq.h
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
b/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
index 6708710..84d2f2c 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
@@ -25,12 +25,13 @@
#include <linux/io.h>
#include <linux/kernel.h>
-#include <linux/ppc_cbe_cpufreq.h>
#include <linux/time.h>
#include <asm/machdep.h>
#include <asm/hw_irq.h>
#include <asm/cell-regs.h>
+#include "ppc_cbe_cpufreq.h"
+
/* to write to MIC register */
static u64 MIC_Slow_Fast_Timer_table[] = {
[0 ... 7] = 0x007fc00000000000ull,
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
index 448b888..d29e8da 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
@@ -25,7 +25,6 @@
#include <linux/timer.h>
#include <linux/module.h>
#include <linux/of_platform.h>
-#include <linux/ppc_cbe_cpufreq.h>
#include <asm/processor.h>
#include <asm/prom.h>
@@ -36,6 +35,8 @@
#include <asm/time.h>
#endif
+#include "ppc_cbe_cpufreq.h"
+
static u8 pmi_slow_mode_limit[MAX_CBE];
bool cbe_cpufreq_has_pmi = false;
[-- Attachment #2: 0001-cpufreq-powerpc-platforms-cell-move-cpufreq-driver-t.patch --]
[-- Type: application/octet-stream, Size: 7490 bytes --]
From 47275a6b874359f1b42fbea3e9d10372049ee6c6 Mon Sep 17 00:00:00 2001
Message-Id: <47275a6b874359f1b42fbea3e9d10372049ee6c6.1365083336.git.viresh.kumar@linaro.org>
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Mon, 25 Mar 2013 11:20:23 +0530
Subject: [PATCH] cpufreq: powerpc/platforms/cell: move cpufreq driver to
drivers/cpufreq
This patch moves cpufreq driver of powerpc platforms/cell to drivers/cpufreq.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/powerpc/platforms/cell/Kconfig | 26 +---------------------
arch/powerpc/platforms/cell/Makefile | 3 ---
drivers/cpufreq/Kconfig.powerpc | 18 +++++++++++++++
drivers/cpufreq/Makefile | 3 +++
.../cpufreq/ppc_cbe_cpufreq.c | 3 ++-
.../cpufreq/ppc_cbe_cpufreq.h | 4 ++--
.../cpufreq/ppc_cbe_cpufreq_pervasive.c | 2 +-
.../cpufreq/ppc_cbe_cpufreq_pmi.c | 2 +-
8 files changed, 28 insertions(+), 33 deletions(-)
rename arch/powerpc/platforms/cell/cbe_cpufreq.c => drivers/cpufreq/ppc_cbe_cpufreq.c (99%)
rename arch/powerpc/platforms/cell/cbe_cpufreq.h => drivers/cpufreq/ppc_cbe_cpufreq.h (82%)
rename arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c => drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c (99%)
rename arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c => drivers/cpufreq/ppc_cbe_cpufreq_pmi.c (99%)
diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
index 53aaefe..9978f59 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -113,34 +113,10 @@ config CBE_THERM
default m
depends on CBE_RAS && SPU_BASE
-config CBE_CPUFREQ
- tristate "CBE frequency scaling"
- depends on CBE_RAS && CPU_FREQ
- default m
- help
- This adds the cpufreq driver for Cell BE processors.
- For details, take a look at <file:Documentation/cpu-freq/>.
- If you don't have such processor, say N
-
-config CBE_CPUFREQ_PMI_ENABLE
- bool "CBE frequency scaling using PMI interface"
- depends on CBE_CPUFREQ
- default n
- help
- Select this, if you want to use the PMI interface
- to switch frequencies. Using PMI, the
- processor will not only be able to run at lower speed,
- but also at lower core voltage.
-
-config CBE_CPUFREQ_PMI
- tristate
- depends on CBE_CPUFREQ_PMI_ENABLE
- default CBE_CPUFREQ
-
config PPC_PMI
tristate
default y
- depends on CBE_CPUFREQ_PMI || PPC_IBM_CELL_POWERBUTTON
+ depends on CPU_FREQ_CBE_PMI || PPC_IBM_CELL_POWERBUTTON
help
PMI (Platform Management Interrupt) is a way to
communicate with the BMC (Baseboard Management Controller).
diff --git a/arch/powerpc/platforms/cell/Makefile b/arch/powerpc/platforms/cell/Makefile
index a4a8935..fe053e7 100644
--- a/arch/powerpc/platforms/cell/Makefile
+++ b/arch/powerpc/platforms/cell/Makefile
@@ -5,9 +5,6 @@ obj-$(CONFIG_PPC_CELL_NATIVE) += iommu.o setup.o spider-pic.o \
obj-$(CONFIG_CBE_RAS) += ras.o
obj-$(CONFIG_CBE_THERM) += cbe_thermal.o
-obj-$(CONFIG_CBE_CPUFREQ_PMI) += cbe_cpufreq_pmi.o
-obj-$(CONFIG_CBE_CPUFREQ) += cbe-cpufreq.o
-cbe-cpufreq-y += cbe_cpufreq_pervasive.o cbe_cpufreq.o
obj-$(CONFIG_CBE_CPUFREQ_SPU_GOVERNOR) += cpufreq_spudemand.o
obj-$(CONFIG_PPC_IBM_CELL_POWERBUTTON) += cbe_powerbutton.o
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
index 2e5a007..9e1ae94 100644
--- a/drivers/cpufreq/Kconfig.powerpc
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -1,3 +1,21 @@
+config CPU_FREQ_CBE
+ tristate "CBE frequency scaling"
+ depends on CBE_RAS && PPC_CELL
+ default m
+ help
+ This adds the cpufreq driver for Cell BE processors.
+ For details, take a look at <file:Documentation/cpu-freq/>.
+ If you don't have such processor, say N
+
+config CPU_FREQ_CBE_PMI
+ bool "CBE frequency scaling using PMI interface"
+ depends on CPU_FREQ_CBE
+ default n
+ help
+ Select this, if you want to use the PMI interface to switch
+ frequencies. Using PMI, the processor will not only be able to run at
+ lower speed, but also at lower core voltage.
+
config CPU_FREQ_MAPLE
bool "Support for Maple 970FX Evaluation Board"
depends on PPC_MAPLE
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7b16092f..bfefa22 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -78,6 +78,9 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra-cpufreq.o
##################################################################################
# PowerPC platform drivers
+obj-$(CONFIG_CPU_FREQ_CBE) += ppc-cbe-cpufreq.o
+ppc-cbe-cpufreq-y += ppc_cbe_cpufreq_pervasive.o ppc_cbe_cpufreq.o
+obj-$(CONFIG_CPU_FREQ_CBE_PMI) += ppc_cbe_cpufreq_pmi.o
obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC) += pmac32-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/drivers/cpufreq/ppc_cbe_cpufreq.c
similarity index 99%
rename from arch/powerpc/platforms/cell/cbe_cpufreq.c
rename to drivers/cpufreq/ppc_cbe_cpufreq.c
index 718c6a3..e577a1d 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq.c
@@ -27,7 +27,8 @@
#include <asm/machdep.h>
#include <asm/prom.h>
#include <asm/cell-regs.h>
-#include "cbe_cpufreq.h"
+
+#include "ppc_cbe_cpufreq.h"
static DEFINE_MUTEX(cbe_switch_mutex);
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.h b/drivers/cpufreq/ppc_cbe_cpufreq.h
similarity index 82%
rename from arch/powerpc/platforms/cell/cbe_cpufreq.h
rename to drivers/cpufreq/ppc_cbe_cpufreq.h
index c1d86bf..b4c00a5 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.h
+++ b/drivers/cpufreq/ppc_cbe_cpufreq.h
@@ -1,5 +1,5 @@
/*
- * cbe_cpufreq.h
+ * ppc_cbe_cpufreq.h
*
* This file contains the definitions used by the cbe_cpufreq driver.
*
@@ -17,7 +17,7 @@ int cbe_cpufreq_get_pmode(int cpu);
int cbe_cpufreq_set_pmode_pmi(int cpu, unsigned int pmode);
-#if defined(CONFIG_CBE_CPUFREQ_PMI) || defined(CONFIG_CBE_CPUFREQ_PMI_MODULE)
+#if defined(CONFIG_CPU_FREQ_CBE_PMI) || defined(CONFIG_CPU_FREQ_CBE_PMI_MODULE)
extern bool cbe_cpufreq_has_pmi;
#else
#define cbe_cpufreq_has_pmi (0)
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c b/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
similarity index 99%
rename from arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c
rename to drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
index 20472e4..84d2f2c 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
@@ -30,7 +30,7 @@
#include <asm/hw_irq.h>
#include <asm/cell-regs.h>
-#include "cbe_cpufreq.h"
+#include "ppc_cbe_cpufreq.h"
/* to write to MIC register */
static u64 MIC_Slow_Fast_Timer_table[] = {
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
similarity index 99%
rename from arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
rename to drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
index 60a07a4..d29e8da 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
@@ -35,7 +35,7 @@
#include <asm/time.h>
#endif
-#include "cbe_cpufreq.h"
+#include "ppc_cbe_cpufreq.h"
static u8 pmi_slow_mode_limit[MAX_CBE];
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* Re: [PATCH] bookehv: Handle debug exception on guest exit
From: Alexander Graf @ 2013-04-04 13:25 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: scottwood, Bharat Bhushan, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <1363801557-27436-1-git-send-email-Bharat.Bhushan@freescale.com>
On 20.03.2013, at 18:45, Bharat Bhushan wrote:
> EPCR.DUVD controls whether the debug events can come in
> hypervisor mode or not. When KVM guest is using the debug
> resource then we do not want debug events to be captured
> in guest entry/exit path. So we set EPCR.DUVD when entering
> and clears EPCR.DUVD when exiting from guest.
>=20
> Debug instruction complete is a post-completion debug
> exception but debug event gets posted on the basis of MSR
> before the instruction is executed. Now if the instruction
> switches the context from guest mode (MSR.GS =3D 1) to hypervisor
> mode (MSR.GS =3D 0) then the xSRR0 points to first instruction of
> KVM handler and xSRR1 points that MSR.GS is clear
> (hypervisor context). Now as xSRR1.GS is used to decide whether
> KVM handler will be invoked to handle the exception or host
> host kernel debug handler will be invoked to handle the exception.
> This leads to host kernel debug handler handling the exception
> which should either be handled by KVM.
>=20
> This is tested on e500mc in 32 bit mode
>=20
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> v0:
> - Do not apply this change for debug_crit as we do not know those =
chips have issue or not.
> - corrected 64bit case branching
>=20
> arch/powerpc/kernel/exceptions-64e.S | 29 =
++++++++++++++++++++++++++++-
> arch/powerpc/kernel/head_booke.h | 26 ++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/exceptions-64e.S =
b/arch/powerpc/kernel/exceptions-64e.S
> index 4684e33..8b26294 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -516,6 +516,33 @@ kernel_dbg_exc:
> andis. r15,r14,DBSR_IC@h
> beq+ 1f
>=20
> +#ifdef CONFIG_KVM_BOOKE_HV
> + /*
> + * EPCR.DUVD controls whether the debug events can come in
> + * hypervisor mode or not. When KVM guest is using the debug
> + * resource then we do not want debug events to be captured
> + * in guest entry/exit path. So we set EPCR.DUVD when entering
> + * and clears EPCR.DUVD when exiting from guest.
> + * Debug instruction complete is a post-completion debug
> + * exception but debug event gets posted on the basis of MSR
> + * before the instruction is executed. Now if the instruction
> + * switches the context from guest mode (MSR.GS =3D 1) to =
hypervisor
> + * mode (MSR.GS =3D 0) then the xSRR0 points to first =
instruction of
Can't we just execute that code path with MSR.DE=3D0?
Alex
> + * KVM handler and xSRR1 points that MSR.GS is clear
> + * (hypervisor context). Now as xSRR1.GS is used to decide =
whether
> + * KVM handler will be invoked to handle the exception or host
> + * host kernel debug handler will be invoked to handle the =
exception.
> + * This leads to host kernel debug handler handling the =
exception
> + * which should either be handled by KVM.
> + */
> + mfspr r10, SPRN_EPCR
> + andis. r10,r10,SPRN_EPCR_DUVD@h
> + beq+ 2f
> +
> + andis. r10,r9,MSR_GS@h
> + beq+ 3f
> +2:
> +#endif
> LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
> LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e)
> cmpld cr0,r10,r14
> @@ -523,7 +550,7 @@ kernel_dbg_exc:
> blt+ cr0,1f
> bge+ cr1,1f
>=20
> - /* here it looks like we got an inappropriate debug exception. =
*/
> +3: /* here it looks like we got an inappropriate debug exception. =
*/
> lis r14,DBSR_IC@h /* clear the IC event */
> rlwinm r11,r11,0,~MSR_DE /* clear DE in the DSRR1 value =
*/
> mtspr SPRN_DBSR,r14
> diff --git a/arch/powerpc/kernel/head_booke.h =
b/arch/powerpc/kernel/head_booke.h
> index 5f051ee..edc6a3b 100644
> --- a/arch/powerpc/kernel/head_booke.h
> +++ b/arch/powerpc/kernel/head_booke.h
> @@ -285,7 +285,33 @@ label:
> mfspr r10,SPRN_DBSR; /* check single-step/branch =
taken */ \
> andis. r10,r10,(DBSR_IC|DBSR_BT)@h; =
\
> beq+ 2f; =
\
> +#ifdef CONFIG_KVM_BOOKE_HV =
\
> + /* =
\
> + * EPCR.DUVD controls whether the debug events can come in =
\
> + * hypervisor mode or not. When KVM guest is using the debug =
\
> + * resource then we do not want debug events to be captured =
\
> + * in guest entry/exit path. So we set EPCR.DUVD when entering =
\
> + * and clears EPCR.DUVD when exiting from guest. =
\
> + * Debug instruction complete is a post-completion debug =
\
> + * exception but debug event gets posted on the basis of MSR =
\
> + * before the instruction is executed. Now if the instruction =
\
> + * switches the context from guest mode (MSR.GS =3D 1) to =
hypervisor \
> + * mode (MSR.GS =3D 0) then the xSRR0 points to first =
instruction of \
> + * KVM handler and xSRR1 points that MSR.GS is clear =
\
> + * (hypervisor context). Now as xSRR1.GS is used to decide =
whether \
> + * KVM handler will be invoked to handle the exception or host =
\
> + * host kernel debug handler will be invoked to handle the =
exception. \
> + * This leads to host kernel debug handler handling the =
exception \
> + * which should either be handled by KVM. =
\
> + */ =
\
> + mfspr r10, SPRN_EPCR; =
\
> + andis. r10,r10,SPRN_EPCR_DUVD@h; =
\
> + beq+ 3f; =
\
> =
\
> + andis. r10,r9,MSR_GS@h; =
\
> + beq+ 1f; =
\
> +3: =
\
> +#endif =
\
> lis r10,KERNELBASE@h; /* check if exception in vectors =
*/ \
> ori r10,r10,KERNELBASE@l; =
\
> cmplw r12,r10; =
\
> --=20
> 1.7.0.4
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 18/18] cpufreq: powerpc/platforms/cell: move cpufreq driver to drivers/cpufreq
From: Arnd Bergmann @ 2013-04-04 13:02 UTC (permalink / raw)
To: Viresh Kumar
Cc: robin.randhawa, linux-pm, patches, Liviu.Dudau, linux-kernel,
cpufreq, rjw, Steve.Bannister, arvind.chauhan, linuxppc-dev,
linaro-kernel, charles.garcia-tobin
In-Reply-To: <0f989533f2e47d4d632710029bf0273082bafee3.1365079581.git.viresh.kumar@linaro.org>
On Thursday 04 April 2013, Viresh Kumar wrote:
> This patch moves cpufreq driver of powerpc platforms/cell to drivers/cpufreq.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Compile Tested only.
>
> arch/powerpc/platforms/cell/Kconfig | 26 +---------------------
> arch/powerpc/platforms/cell/Makefile | 3 ---
> drivers/cpufreq/Kconfig.powerpc | 18 +++++++++++++++
> drivers/cpufreq/Makefile | 3 +++
> .../cpufreq/ppc_cbe_cpufreq.c | 2 +-
> .../cpufreq/ppc_cbe_cpufreq_pervasive.c | 3 +--
> .../cpufreq/ppc_cbe_cpufreq_pmi.c | 3 +--
> .../linux/ppc_cbe_cpufreq.h | 4 ++--
Moving the files is good, but I don't see a reason to make the cbe_cpufreq.h
header globally visible in include/linux/. Isn't it just used by as the
interface between ppc_cbe_cpufreq_pmi.c and ppc_cbe_cpufreq.c?
Arnd
^ permalink raw reply
* RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-04-04 13:00 UTC (permalink / raw)
To: Alex Williamson, Joerg Roedel
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1365012091.2882.252.camel@bling.home>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBXaWxsaWFtc29u
IFttYWlsdG86YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwg
QXByaWwgMDMsIDIwMTMgMTE6MzIgUE0NCj4gVG86IEpvZXJnIFJvZWRlbA0KPiBDYzogU2V0aGkg
VmFydW4tQjE2Mzk1OyBZb2RlciBTdHVhcnQtQjA4MjQ4OyBXb29kIFNjb3R0LUIwNzQyMTsNCj4g
aW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxh
YnMub3JnOyBsaW51eC0NCj4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsgZ2FsYWtAa2VybmVsLmNy
YXNoaW5nLm9yZzsNCj4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnDQo+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggNS81IHYxMV0gaW9tbXUvZnNsOiBGcmVlc2NhbGUgUEFNVSBkcml2ZXIgYW5kIGlvbW11
DQo+IGltcGxlbWVudGF0aW9uLg0KPiANCj4gT24gVHVlLCAyMDEzLTA0LTAyIGF0IDE4OjE4ICsw
MjAwLCBKb2VyZyBSb2VkZWwgd3JvdGU6DQo+ID4gQ2MnaW5nIEFsZXggV2lsbGlhbXNvbg0KPiA+
DQo+ID4gQWxleCwgY2FuIHlvdSBwbGVhc2UgcmV2aWV3IHRoZSBpb21tdS1ncm91cCBwYXJ0IG9m
IHRoaXMgcGF0Y2g/DQo+IA0KPiBTdXJlLCBpdCBsb29rcyBwcmV0dHkgcmVhc29uYWJsZS4gIEFJ
VUksIGFsbCBQQ0kgZGV2aWNlcyBhcmUgYmVsb3cgc29tZQ0KPiBraW5kIG9mIGhvc3QgYnJpZGdl
IHRoYXQgaXMgZWl0aGVyIG5ldyBhbmQgc3VwcG9ydHMgcGFydGl0aW9uaW5nIG9yIG9sZA0KPiBh
bmQgZG9lc24ndC4gIEkgZG9uJ3Qga25vdyBpZiB0aGF0J3MgYSB2aXNpYmlsaXR5IG9yIGlzb2xh
dGlvbg0KPiByZXF1aXJlbWVudCwgcGVyaGFwcyBQQ0kgQUNTLWlzaC4gIEluIHRoZSBuZXcgaG9z
dCBicmlkZ2UgY2FzZSwgZWFjaA0KPiBkZXZpY2UgZ2V0cyBhIGdyb3VwLiAgVGhpcyBzZWVtcyBu
b3QgdG8gaGF2ZSBhbnkgcXVpcmtzIGZvciBtdWx0aWZ1bmN0aW9uDQo+IGRldmljZXMgdGhvdWdo
LiAgT24gQU1EIGFuZCBJbnRlbCBJT01NVXMgd2UgdGVzdCBtdWx0aWZ1bmN0aW9uIGRldmljZSBB
Q1MNCj4gc3VwcG9ydCB0byBkZXRlcm1pbmUgd2hldGhlciBhbGwgdGhlIGZ1bmN0aW9ucyBzaG91
bGQgYmUgaW4gdGhlIHNhbWUNCj4gZ3JvdXAuICBJcyB0aGVyZSBhbnkgcmVhc29uIHRvIHRydXN0
IG11bHRpZnVuY3Rpb24gZGV2aWNlcyBvbiBQQU1VPw0KPiANCltTZXRoaSBWYXJ1bi1CMTYzOTVd
IEluIHRoZSBjYXNlIHdoZXJlIHdlIGNhbiBwYXJ0aXRpb24gZW5kcG9pbnRzIHdlIGNhbiBkaXN0
aW5ndWlzaCB0cmFuc2FjdGlvbnMgYmFzZWQgb24gdGhlIGJ1cyxkZXZpY2UsZnVuY3Rpb24gbnVt
YmVyIGNvbWJpbmF0aW9uLiBUaGlzIHN1cHBvcnQgaXMgYXZhaWxhYmxlIGluIHRoZSBQQ0llIGNv
bnRyb2xsZXIgKGhvc3QgYnJpZGdlKS4NCg0KPiBJIGFsc28gZmluZCBpdCBjdXJpb3VzIHdoYXQg
aGFwcGVucyB0byB0aGUgaW9tbXUgZ3JvdXAgb2YgdGhlIGhvc3QNCj4gYnJpZGdlLiAgSW4gdGhl
IHBhcnRpdGlvbmFibGUgY2FzZSB0aGUgaG9zdCBicmlkZ2UgZ3JvdXAgaXMgcmVtb3ZlZCwgaW4N
Cj4gdGhlIG5vbi1wYXJ0aXRpb25hYmxlIGNhc2UgdGhlIGhvc3QgYnJpZGdlIGdyb3VwIGJlY29t
ZXMgdGhlIGdyb3VwIGZvcg0KPiB0aGUgY2hpbGRyZW4sIHJlbW92aW5nIHRoZSBob3N0IGJyaWRn
ZS4gIEl0J3MgdW5pcXVlIHRvIFBBTVUgc28gZmFyIHRoYXQNCj4gdGhlc2UgaG9zdCBicmlkZ2Vz
IGFyZSBldmVuIGluIGFuIGlvbW11IGdyb3VwICh4ODYgb25seSBhZGRzIHBjaQ0KPiBkZXZpY2Vz
KSwgYnV0IEkgZG9uJ3Qgc2VlIGl0IGFzIG5lY2Vzc2FyaWx5IHdyb25nIGxlYXZpbmcgaXQgaW4g
ZWl0aGVyDQo+IHNjZW5hcmlvLiAgRG9lcyBpdCBzb2x2ZSBzb21lIHByb2JsZW0gdG8gcmVtb3Zl
IHRoZW0gZnJvbSB0aGUgZ3JvdXBzPw0KPiBUaGFua3MsDQpbU2V0aGkgVmFydW4tQjE2Mzk1XSBU
aGUgUENJZSBjb250cm9sbGVyIGlzbid0IGEgcGFydGl0aW9uYWJsZSBlbnRpdHksIGl0IHdvdWxk
IGFsd2F5cyBiZSBvd25lZCBieSB0aGUgaG9zdC4NCg0KLVZhcnVuDQoNCg==
^ permalink raw reply
* [PATCH 18/18] cpufreq: powerpc/platforms/cell: move cpufreq driver to drivers/cpufreq
From: Viresh Kumar @ 2013-04-04 12:54 UTC (permalink / raw)
To: rjw
Cc: robin.randhawa, Arnd Bergmann, linux-pm, Viresh Kumar, patches,
Liviu.Dudau, linux-kernel, cpufreq, Steve.Bannister,
arvind.chauhan, linuxppc-dev, linaro-kernel, charles.garcia-tobin
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
This patch moves cpufreq driver of powerpc platforms/cell to drivers/cpufreq.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Compile Tested only.
arch/powerpc/platforms/cell/Kconfig | 26 +---------------------
arch/powerpc/platforms/cell/Makefile | 3 ---
drivers/cpufreq/Kconfig.powerpc | 18 +++++++++++++++
drivers/cpufreq/Makefile | 3 +++
.../cpufreq/ppc_cbe_cpufreq.c | 2 +-
.../cpufreq/ppc_cbe_cpufreq_pervasive.c | 3 +--
.../cpufreq/ppc_cbe_cpufreq_pmi.c | 3 +--
.../linux/ppc_cbe_cpufreq.h | 4 ++--
8 files changed, 27 insertions(+), 35 deletions(-)
rename arch/powerpc/platforms/cell/cbe_cpufreq.c => drivers/cpufreq/ppc_cbe_cpufreq.c (99%)
rename arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c => drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c (98%)
rename arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c => drivers/cpufreq/ppc_cbe_cpufreq_pmi.c (99%)
rename arch/powerpc/platforms/cell/cbe_cpufreq.h => include/linux/ppc_cbe_cpufreq.h (82%)
diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
index 53aaefe..9978f59 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -113,34 +113,10 @@ config CBE_THERM
default m
depends on CBE_RAS && SPU_BASE
-config CBE_CPUFREQ
- tristate "CBE frequency scaling"
- depends on CBE_RAS && CPU_FREQ
- default m
- help
- This adds the cpufreq driver for Cell BE processors.
- For details, take a look at <file:Documentation/cpu-freq/>.
- If you don't have such processor, say N
-
-config CBE_CPUFREQ_PMI_ENABLE
- bool "CBE frequency scaling using PMI interface"
- depends on CBE_CPUFREQ
- default n
- help
- Select this, if you want to use the PMI interface
- to switch frequencies. Using PMI, the
- processor will not only be able to run at lower speed,
- but also at lower core voltage.
-
-config CBE_CPUFREQ_PMI
- tristate
- depends on CBE_CPUFREQ_PMI_ENABLE
- default CBE_CPUFREQ
-
config PPC_PMI
tristate
default y
- depends on CBE_CPUFREQ_PMI || PPC_IBM_CELL_POWERBUTTON
+ depends on CPU_FREQ_CBE_PMI || PPC_IBM_CELL_POWERBUTTON
help
PMI (Platform Management Interrupt) is a way to
communicate with the BMC (Baseboard Management Controller).
diff --git a/arch/powerpc/platforms/cell/Makefile b/arch/powerpc/platforms/cell/Makefile
index a4a8935..fe053e7 100644
--- a/arch/powerpc/platforms/cell/Makefile
+++ b/arch/powerpc/platforms/cell/Makefile
@@ -5,9 +5,6 @@ obj-$(CONFIG_PPC_CELL_NATIVE) += iommu.o setup.o spider-pic.o \
obj-$(CONFIG_CBE_RAS) += ras.o
obj-$(CONFIG_CBE_THERM) += cbe_thermal.o
-obj-$(CONFIG_CBE_CPUFREQ_PMI) += cbe_cpufreq_pmi.o
-obj-$(CONFIG_CBE_CPUFREQ) += cbe-cpufreq.o
-cbe-cpufreq-y += cbe_cpufreq_pervasive.o cbe_cpufreq.o
obj-$(CONFIG_CBE_CPUFREQ_SPU_GOVERNOR) += cpufreq_spudemand.o
obj-$(CONFIG_PPC_IBM_CELL_POWERBUTTON) += cbe_powerbutton.o
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
index 2e5a007..9e1ae94 100644
--- a/drivers/cpufreq/Kconfig.powerpc
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -1,3 +1,21 @@
+config CPU_FREQ_CBE
+ tristate "CBE frequency scaling"
+ depends on CBE_RAS && PPC_CELL
+ default m
+ help
+ This adds the cpufreq driver for Cell BE processors.
+ For details, take a look at <file:Documentation/cpu-freq/>.
+ If you don't have such processor, say N
+
+config CPU_FREQ_CBE_PMI
+ bool "CBE frequency scaling using PMI interface"
+ depends on CPU_FREQ_CBE
+ default n
+ help
+ Select this, if you want to use the PMI interface to switch
+ frequencies. Using PMI, the processor will not only be able to run at
+ lower speed, but also at lower core voltage.
+
config CPU_FREQ_MAPLE
bool "Support for Maple 970FX Evaluation Board"
depends on PPC_MAPLE
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7b16092f..bfefa22 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -78,6 +78,9 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra-cpufreq.o
##################################################################################
# PowerPC platform drivers
+obj-$(CONFIG_CPU_FREQ_CBE) += ppc-cbe-cpufreq.o
+ppc-cbe-cpufreq-y += ppc_cbe_cpufreq_pervasive.o ppc_cbe_cpufreq.o
+obj-$(CONFIG_CPU_FREQ_CBE_PMI) += ppc_cbe_cpufreq_pmi.o
obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC) += pmac32-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/drivers/cpufreq/ppc_cbe_cpufreq.c
similarity index 99%
rename from arch/powerpc/platforms/cell/cbe_cpufreq.c
rename to drivers/cpufreq/ppc_cbe_cpufreq.c
index 718c6a3..6d7a51d 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq.c
@@ -23,11 +23,11 @@
#include <linux/cpufreq.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/ppc_cbe_cpufreq.h>
#include <asm/machdep.h>
#include <asm/prom.h>
#include <asm/cell-regs.h>
-#include "cbe_cpufreq.h"
static DEFINE_MUTEX(cbe_switch_mutex);
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c b/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
similarity index 98%
rename from arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c
rename to drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
index 20472e4..6708710 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq_pervasive.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pervasive.c
@@ -25,13 +25,12 @@
#include <linux/io.h>
#include <linux/kernel.h>
+#include <linux/ppc_cbe_cpufreq.h>
#include <linux/time.h>
#include <asm/machdep.h>
#include <asm/hw_irq.h>
#include <asm/cell-regs.h>
-#include "cbe_cpufreq.h"
-
/* to write to MIC register */
static u64 MIC_Slow_Fast_Timer_table[] = {
[0 ... 7] = 0x007fc00000000000ull,
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
similarity index 99%
rename from arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
rename to drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
index 60a07a4..448b888 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
@@ -25,6 +25,7 @@
#include <linux/timer.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/ppc_cbe_cpufreq.h>
#include <asm/processor.h>
#include <asm/prom.h>
@@ -35,8 +36,6 @@
#include <asm/time.h>
#endif
-#include "cbe_cpufreq.h"
-
static u8 pmi_slow_mode_limit[MAX_CBE];
bool cbe_cpufreq_has_pmi = false;
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.h b/include/linux/ppc_cbe_cpufreq.h
similarity index 82%
rename from arch/powerpc/platforms/cell/cbe_cpufreq.h
rename to include/linux/ppc_cbe_cpufreq.h
index c1d86bf..b4c00a5 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.h
+++ b/include/linux/ppc_cbe_cpufreq.h
@@ -1,5 +1,5 @@
/*
- * cbe_cpufreq.h
+ * ppc_cbe_cpufreq.h
*
* This file contains the definitions used by the cbe_cpufreq driver.
*
@@ -17,7 +17,7 @@ int cbe_cpufreq_get_pmode(int cpu);
int cbe_cpufreq_set_pmode_pmi(int cpu, unsigned int pmode);
-#if defined(CONFIG_CBE_CPUFREQ_PMI) || defined(CONFIG_CBE_CPUFREQ_PMI_MODULE)
+#if defined(CONFIG_CPU_FREQ_CBE_PMI) || defined(CONFIG_CPU_FREQ_CBE_PMI_MODULE)
extern bool cbe_cpufreq_has_pmi;
#else
#define cbe_cpufreq_has_pmi (0)
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
From: Viresh Kumar @ 2013-04-04 12:54 UTC (permalink / raw)
To: rjw
Cc: robin.randhawa, linux-pm, Viresh Kumar, patches, Liviu.Dudau,
linux-kernel, cpufreq, Steve.Bannister, Paul Mackerras,
Olof Johansson, arvind.chauhan, linuxppc-dev, linaro-kernel,
charles.garcia-tobin
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Compile Tested only.
arch/powerpc/platforms/Kconfig | 31 ----------------------
arch/powerpc/platforms/pasemi/Makefile | 1 -
arch/powerpc/platforms/powermac/Makefile | 2 --
drivers/cpufreq/Kconfig.powerpc | 26 ++++++++++++++++++
drivers/cpufreq/Makefile | 3 +++
.../cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c | 0
.../cpufreq/pmac32-cpufreq.c | 0
.../cpufreq/pmac64-cpufreq.c | 0
8 files changed, 29 insertions(+), 34 deletions(-)
rename arch/powerpc/platforms/pasemi/cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c (100%)
rename arch/powerpc/platforms/powermac/cpufreq_32.c => drivers/cpufreq/pmac32-cpufreq.c (100%)
rename arch/powerpc/platforms/powermac/cpufreq_64.c => drivers/cpufreq/pmac64-cpufreq.c (100%)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 52de8bc..46a223f 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -194,37 +194,6 @@ config PPC_IO_WORKAROUNDS
source "drivers/cpufreq/Kconfig"
-menu "CPU Frequency drivers"
- depends on CPU_FREQ
-
-config CPU_FREQ_PMAC
- bool "Support for Apple PowerBooks"
- depends on ADB_PMU && PPC32
- select CPU_FREQ_TABLE
- help
- This adds support for frequency switching on Apple PowerBooks,
- this currently includes some models of iBook & Titanium
- PowerBook.
-
-config CPU_FREQ_PMAC64
- bool "Support for some Apple G5s"
- depends on PPC_PMAC && PPC64
- select CPU_FREQ_TABLE
- help
- This adds support for frequency switching on Apple iMac G5,
- and some of the more recent desktop G5 machines as well.
-
-config PPC_PASEMI_CPUFREQ
- bool "Support for PA Semi PWRficient"
- depends on PPC_PASEMI
- default y
- select CPU_FREQ_TABLE
- help
- This adds the support for frequency switching on PA Semi
- PWRficient processors.
-
-endmenu
-
menu "CPUIdle driver"
source "drivers/cpuidle/Kconfig"
diff --git a/arch/powerpc/platforms/pasemi/Makefile b/arch/powerpc/platforms/pasemi/Makefile
index ce6d789..8e8d4ca 100644
--- a/arch/powerpc/platforms/pasemi/Makefile
+++ b/arch/powerpc/platforms/pasemi/Makefile
@@ -1,3 +1,2 @@
obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o dma_lib.o misc.o
obj-$(CONFIG_PPC_PASEMI_MDIO) += gpio_mdio.o
-obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += cpufreq.o
diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile
index ea47df6..52c6ce1 100644
--- a/arch/powerpc/platforms/powermac/Makefile
+++ b/arch/powerpc/platforms/powermac/Makefile
@@ -9,8 +9,6 @@ obj-y += pic.o setup.o time.o feature.o pci.o \
sleep.o low_i2c.o cache.o pfunc_core.o \
pfunc_base.o udbg_scc.o udbg_adb.o
obj-$(CONFIG_PMAC_BACKLIGHT) += backlight.o
-obj-$(CONFIG_CPU_FREQ_PMAC) += cpufreq_32.o
-obj-$(CONFIG_CPU_FREQ_PMAC64) += cpufreq_64.o
# CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really
# need this to be a bool. Cheat here and pretend CONFIG_NVRAM=m is really
# CONFIG_NVRAM=y
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
index e76992f..2e5a007 100644
--- a/drivers/cpufreq/Kconfig.powerpc
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -5,3 +5,29 @@ config CPU_FREQ_MAPLE
help
This adds support for frequency switching on Maple 970FX
Evaluation Board and compatible boards (IBM JS2x blades).
+
+config CPU_FREQ_PMAC
+ bool "Support for Apple PowerBooks"
+ depends on ADB_PMU && PPC32
+ select CPU_FREQ_TABLE
+ help
+ This adds support for frequency switching on Apple PowerBooks,
+ this currently includes some models of iBook & Titanium
+ PowerBook.
+
+config CPU_FREQ_PMAC64
+ bool "Support for some Apple G5s"
+ depends on PPC_PMAC && PPC64
+ select CPU_FREQ_TABLE
+ help
+ This adds support for frequency switching on Apple iMac G5,
+ and some of the more recent desktop G5 machines as well.
+
+config PPC_PASEMI_CPUFREQ
+ bool "Support for PA Semi PWRficient"
+ depends on PPC_PASEMI
+ select CPU_FREQ_TABLE
+ default y
+ help
+ This adds the support for frequency switching on PA Semi
+ PWRficient processors.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db96d74..7b16092f 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -79,6 +79,9 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra-cpufreq.o
##################################################################################
# PowerPC platform drivers
obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
+obj-$(CONFIG_CPU_FREQ_PMAC) += pmac32-cpufreq.o
+obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
+obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += pasemi-cpufreq.o
##################################################################################
# Other platform drivers
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
similarity index 100%
rename from arch/powerpc/platforms/pasemi/cpufreq.c
rename to drivers/cpufreq/pasemi-cpufreq.c
diff --git a/arch/powerpc/platforms/powermac/cpufreq_32.c b/drivers/cpufreq/pmac32-cpufreq.c
similarity index 100%
rename from arch/powerpc/platforms/powermac/cpufreq_32.c
rename to drivers/cpufreq/pmac32-cpufreq.c
diff --git a/arch/powerpc/platforms/powermac/cpufreq_64.c b/drivers/cpufreq/pmac64-cpufreq.c
similarity index 100%
rename from arch/powerpc/platforms/powermac/cpufreq_64.c
rename to drivers/cpufreq/pmac64-cpufreq.c
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* Re: [PATCH -V5 00/25] THP support for PPC64
From: Aneesh Kumar K.V @ 2013-04-04 8:38 UTC (permalink / raw)
To: Simon Jeons; +Cc: paulus, linuxppc-dev, linux-mm
In-Reply-To: <515D1A2C.1000606@gmail.com>
Simon Jeons <simon.jeons@gmail.com> writes:
> Hi Aneesh,
> On 04/04/2013 01:57 PM, Aneesh Kumar K.V wrote:
>> Hi,
>>
>> This patchset adds transparent hugepage support for PPC64.
>>
>> TODO:
>> * hash preload support in update_mmu_cache_pmd (we don't do that for hugetlb)
>>
>> Some numbers:
>>
>> The latency measurements code from Anton found at
>> http://ozlabs.org/~anton/junkcode/latency2001.c
>>
>> THP disabled 64K page size
>> ------------------------
>> [root@llmp24l02 ~]# ./latency2001 8G
>> 8589934592 731.73 cycles 205.77 ns
>> [root@llmp24l02 ~]# ./latency2001 8G
>> 8589934592 743.39 cycles 209.05 ns
>
> Could you explain what's the meaning of result?
>
That is the total memory range, cycles taken to access an address and
time taken to access. That numbers shows the overhead of tlb miss.
you can find the source at http://ozlabs.org/~anton/junkcode/latency2001.c
-aneesh
^ permalink raw reply
* Re: [PATCH v2 2/11] Add PRRN Event Handler
From: Benjamin Herrenschmidt @ 2013-04-04 7:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Nathan Fontenot, linuxppc-dev
In-Reply-To: <20130404033436.GC19443@drongo>
On Thu, 2013-04-04 at 14:34 +1100, Paul Mackerras wrote:
> Also, rtasd isn't actually a task, it's just a function that gets run
> via schedule_delayed_work_on() and re-schedules itself each time it
> runs. Is there any deadlock possibility in calling flush_work from a
> work function?
There used to be, but I'm not familiar with the "new" implementation of
the work queue stuff.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 4/5] powerpc/fsl-booke: Add B4_QDS board support
From: Leekha Shaveta-B20052 @ 2013-04-04 7:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <13F7FFD3-2CFB-463F-84D2-2613D2B697E1@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Wednesday, April 03, 2013 10:12 PM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 4/5] powerpc/fsl-booke: Add B4_QDS board support
On Apr 2, 2013, at 2:16 AM, Shaveta Leekha wrote:
> - Add support for B4 board in board file b4_qds.c, It is common for=20
> B4860, B4420 and B4220QDS as they share same QDS board
> - Add B4QDS support in Kconfig and Makefile
>=20
> B4860QDS is a high-performance computing evaluation, development and=20
> test platform supporting the B4860 QorIQ Power Architecture processor,=20
> with following major features:
>=20
> - Four dual-threaded e6500 Power Architecture processors
> organized in one cluster-each core runs up to 1.8 GHz
> - Two DDR3/3L controllers for high-speed memory interface each
> runs at up to 1866.67 MHz
> - CoreNet fabric that fully supports coherency using MESI protocol
> between the e6500 cores, SC3900 FVP cores, memories and
> external interfaces.
> - Data Path Acceleration Architecture having FMAN, QMan, BMan, SEC 5.3 =
and RMAN
> - Large internal cache memory with snooping and stashing capabilities
> - Sixteen 10-GHz SerDes lanes that serve:
> - Two SRIO interfaces. Each supports up to 4 lanes and
> a total of up to 8 lanes
> - Up to 8-lanes Common Public Radio Interface (CPRI) controller
> for glue-less antenna connection
> - Two 10-Gbit Ethernet controllers (10GEC)
> - Six 1G/2.5-Gbit Ethernet controllers for network communications
> - PCI Express controller
> - Debug (Aurora)
> - Various system peripherals
>=20
> B4420 and B4220 have some differences in comparison to B4860 with=20
> fewer core/clusters(both SC3900 and e6500), fewer DDR controllers, fewer =
serdes lanes, fewer SGMII interfaces and reduced target frequencies.
>=20
> Key differences between B4860 and B4420:
> B4420 has:
> - Fewer e6500 cores:
> 1 cluster with 2 e6500 cores
> - Fewer SC3900 cores/clusters:
> 1 cluster with 2 SC3900 cores per cluster
> - Single DDRC @ 1.6GHz
> - 2 X 4 lane serdes
> - 3 SGMII interfaces
> - no sRIO
> - no 10G
>=20
> Key differences between B4860 and B4220:
> B4220 has:
> - Fewer e6500 cores:
> 1 cluster with 1 e6500 core
> - Fewer SC3900 cores/clusters:
> 1 cluster with 2 SC3900 cores per cluster
> - Single DDRC @ 1.33GHz
> - 2 X 2 lane serdes
> - 2 SGMII interfaces
> - no sRIO
> - no 10G
>=20
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 17 ++++++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/b4_qds.c | 102=20
> ++++++++++++++++++++++++++++++++++
> 3 files changed, 120 insertions(+), 0 deletions(-) create mode 100644=20
> arch/powerpc/platforms/85xx/b4_qds.c
commit messages should line wrap at 75 chars.
- k
[SL] Ok, will do that.
Regards,
Shaveta=20
^ permalink raw reply
* RE: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
From: Leekha Shaveta-B20052 @ 2013-04-04 7:10 UTC (permalink / raw)
To: Kumar Gala
Cc: Li Yang-R58472, Zhao Chenhui-B35336, Mehresh Ramneek-B31383,
Garg Vakul-B16394, Lian Minghuan-B31939, Tang Yuantian-B29983,
Fleming Andy-AFLEMING, Sethi Varun-B16395,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2E7EAABC-5A34-46D2-B4C8-80081AC1563F@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Wednesday, April 03, 2013 10:10 PM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Li Yang-R58472; Tan=
g Yuantian-B29983; Sethi Varun-B16395; Lian Minghuan-B31939; Mehresh Ramnee=
k-B31383; Fleming Andy-AFLEMING; Garg Vakul-B16394
Subject: Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree=
files for B4860 and B4420
On Apr 2, 2013, at 2:16 AM, Shaveta Leekha wrote:
> B4860 and B4420 are similar that share some commonalities
>=20
> * common features have been added in b4si-pre.dtsi and b4si-post.dtsi
> * differences are added in respective silicon files of B4860 and B4420
What are the differences between B4860 & B4420, beyond # of cores?
[SL] have detailed the differences in board support patch sent in this patc=
h set.
Do I need to mention the differences here also?=20
>=20
> There are several things missing from the device trees of B4860 and B4420=
:
>=20
> * DPAA related nodes (Qman, Bman, Fman, Rman)
> * DSP related nodes/information
What about:
serdes, sfp [security fuse processor], thermal, gpio, maple, cpri, quad tim=
ers,=20
[SL] I would prefer to add, what have been added in device tree so far in p=
atch description
As that is clear to me.
But as u suggested, I mentioned some of the nodes/things missing, though th=
e list is not
Exhaustive. Also I am not sure of, what would be added/required in future i=
n these device tree files.
Anyways, I can add all the things you have mentioned above.
Please tell if anything else is missing.
Regards,
Shaveta
>=20
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Vakul Garg <vakul@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 94 ++++++++++
> arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 49 +++++
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 138 ++++++++++++++
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 59 ++++++
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 262 ++++++++++++++++++++++=
+++++
> arch/powerpc/boot/dts/fsl/b4si-pre.dtsi | 65 +++++++
Remove b4si-pre.dtsi, there isn't enough here to warrant not just merging i=
t into b4420si-pre.dtsi & b4860si-pre.dtsi
> 6 files changed, 667 insertions(+), 0 deletions(-) create mode 100644=20
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4si-pre.dtsi
>=20
> diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi=20
> b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> new file mode 100644
> index 0000000..bba0c03
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> @@ -0,0 +1,94 @@
> +/*
> + * B4420 Silicon/SoC Device Tree Source (post include)
> + *
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * This software is provided by Freescale Semiconductor "as is" and=20
> +any
> + * express or implied warranties, including, but not limited to, the=20
> +implied
> + * warranties of merchantability and fitness for a particular purpose=20
> +are
> + * disclaimed. In no event shall Freescale Semiconductor be liable=20
> +for any
> + * direct, indirect, incidental, special, exemplary, or consequential=20
> +damages
> + * (including, but not limited to, procurement of substitute goods or=20
> +services;
> + * loss of use, data, or profits; or business interruption) however=20
> +caused and
> + * on any theory of liability, whether in contract, strict liability,=20
> +or tort
> + * (including negligence or otherwise) arising in any way out of the=20
> +use of
> + * this software, even if advised of the possibility of such damage.
> + */
> +
> +/include/ "b4si-post.dtsi"
> +
> +/* controller at 0x200000 */
> +&pci0 {
> + compatible =3D "fsl,b4420-pcie", "fsl,qoriq-pcie-v2.4"; };
> +
> +&dcsr {
> + dcsr-epu@0 {
> + compatible =3D "fsl,b4420-dcsr-epu", "fsl,dcsr-epu";
> + };
> + dcsr-npc {
> + compatible =3D "fsl,b4420-dcsr-cnpc", "fsl,dcsr-cnpc";
> + };
> + dcsr-dpaa@9000 {
> + compatible =3D "fsl,b4420-dcsr-dpaa", "fsl,dcsr-dpaa";
> + };
> + dcsr-ocn@11000 {
> + compatible =3D "fsl,b4420-dcsr-ocn", "fsl,dcsr-ocn";
> + };
> + dcsr-nal@18000 {
> + compatible =3D "fsl,b4420-dcsr-nal", "fsl,dcsr-nal";
> + };
> + dcsr-rcpm@22000 {
> + compatible =3D "fsl,b4420-dcsr-rcpm", "fsl,dcsr-rcpm";
> + };
> + dcsr-snpc@30000 {
> + compatible =3D "fsl,b4420-dcsr-snpc", "fsl,dcsr-snpc";
> + };
> + dcsr-snpc@31000 {
> + compatible =3D "fsl,b4420-dcsr-snpc", "fsl,dcsr-snpc";
> + };
> + dcsr-cpu-sb-proxy@108000 {
> + compatible =3D "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
> + cpu-handle =3D <&cpu1>;
> + reg =3D <0x108000 0x1000 0x109000 0x1000>;
> + };
> +};
> +
> +&soc {
> + cpc: l3-cache-controller@10000 {
> + compatible =3D "fsl,b4420-l3-cache-controller", "cache";
> + };
> +
> + corenet-cf@18000 {
> + compatible =3D "fsl,b4420-corenet-cf";
> + };
> +
> + guts: global-utilities@e0000 {
> + compatible =3D "fsl,b4420-device-config", "fsl,qoriq-device-config-2.0=
";
> + };
> +
> + clockgen: global-utilities@e1000 {
> + compatible =3D "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2";
> + };
> +
> + L2: l2-cache-controller@c20000 {
> + compatible =3D "fsl,b4420-l2-cache-controller";
> + };
> +};
> diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi=20
> b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> new file mode 100644
> index 0000000..555b0e4
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> @@ -0,0 +1,49 @@
> +/*
> + * B4420 Silicon/SoC Device Tree Source (pre include)
> + *
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * This software is provided by Freescale Semiconductor "as is" and=20
> +any
> + * express or implied warranties, including, but not limited to, the=20
> +implied
> + * warranties of merchantability and fitness for a particular purpose=20
> +are
> + * disclaimed. In no event shall Freescale Semiconductor be liable=20
> +for any
> + * direct, indirect, incidental, special, exemplary, or consequential=20
> +damages
> + * (including, but not limited to, procurement of substitute goods or=20
> +services;
> + * loss of use, data, or profits; or business interruption) however=20
> +caused and
> + * on any theory of liability, whether in contract, strict liability,=20
> +or tort
> + * (including negligence or otherwise) arising in any way out of the=20
> +use of
> + * this software, even if advised of the possibility of such damage.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "b4si-pre.dtsi"
> +
> +/ {
> + compatible =3D "fsl,B4420";
> +
> + cpus {
> + cpu1: PowerPC,e6500@1 {
> + device_type =3D "cpu";
> + reg =3D <2 3>;
> + next-level-cache =3D <&L2>;
> + };
> + };
> +};
> diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi=20
> b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> new file mode 100644
> index 0000000..f43910f
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> @@ -0,0 +1,138 @@
> +/*
> + * B4860 Silicon/SoC Device Tree Source (post include)
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND=20
> +ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=20
> +IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE=20
> +ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE=20
> +FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL=20
> +DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR=20
> +SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER=20
> +CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,=20
> +OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE=20
> +USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/include/ "b4si-post.dtsi"
> +
> +/* controller at 0x200000 */
> +&pci0 {
> + compatible =3D "fsl,b4860-pcie", "fsl,qoriq-pcie-v2.4"; };
> +
> +&rio {
> + compatible =3D "fsl,srio";
> + interrupts =3D <16 2 1 11>;
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + fsl,iommu-parent =3D <&pamu0>;
> + ranges;
> +
> + port1 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <1>;
> + fsl,liodn-reg =3D <&guts 0x510>; /* RIO1LIODNR */
> + };
> +
> + port2 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <2>;
> + fsl,liodn-reg =3D <&guts 0x514>; /* RIO2LIODNR */
> + };
> +};
> +
> +&dcsr {
> + dcsr-epu@0 {
> + compatible =3D "fsl,b4860-dcsr-epu", "fsl,dcsr-epu";
> + };
> + dcsr-npc {
> + compatible =3D "fsl,b4860-dcsr-cnpc", "fsl,dcsr-cnpc";
> + };
> + dcsr-dpaa@9000 {
> + compatible =3D "fsl,b4860-dcsr-dpaa", "fsl,dcsr-dpaa";
> + };
> + dcsr-ocn@11000 {
> + compatible =3D "fsl,b4860-dcsr-ocn", "fsl,dcsr-ocn";
> + };
> + dcsr-ddr@13000 {
> + compatible =3D "fsl,dcsr-ddr";
> + dev-handle =3D <&ddr2>;
> + reg =3D <0x13000 0x1000>;
> + };
> + dcsr-nal@18000 {
> + compatible =3D "fsl,b4860-dcsr-nal", "fsl,dcsr-nal";
> + };
> + dcsr-rcpm@22000 {
> + compatible =3D "fsl,b4860-dcsr-rcpm", "fsl,dcsr-rcpm";
> + };
> + dcsr-snpc@30000 {
> + compatible =3D "fsl,b4860-dcsr-snpc", "fsl,dcsr-snpc";
> + };
> + dcsr-snpc@31000 {
> + compatible =3D "fsl,b4860-dcsr-snpc", "fsl,dcsr-snpc";
> + };
> + dcsr-cpu-sb-proxy@108000 {
> + compatible =3D "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
> + cpu-handle =3D <&cpu1>;
> + reg =3D <0x108000 0x1000 0x109000 0x1000>;
> + };
> + dcsr-cpu-sb-proxy@110000 {
> + compatible =3D "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
> + cpu-handle =3D <&cpu2>;
> + reg =3D <0x110000 0x1000 0x111000 0x1000>;
> + };
> + dcsr-cpu-sb-proxy@118000 {
> + compatible =3D "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
> + cpu-handle =3D <&cpu3>;
> + reg =3D <0x118000 0x1000 0x119000 0x1000>;
> + };
> +};
> +
> +&soc {
> + ddr2: memory-controller@9000 {
> + compatible =3D "fsl,qoriq-memory-controller-v4.5", "fsl,qoriq-memory-c=
ontroller";
> + reg =3D <0x9000 0x1000>;
> + interrupts =3D <16 2 1 9>;
> + };
> +
> + cpc: l3-cache-controller@10000 {
> + compatible =3D "fsl,b4860-l3-cache-controller", "cache";
> + };
> +
> + corenet-cf@18000 {
> + compatible =3D "fsl,b4860-corenet-cf";
> + };
> +
> + guts: global-utilities@e0000 {
> + compatible =3D "fsl,b4860-device-config", "fsl,qoriq-device-config-2.0=
";
> + };
> +
> + clockgen: global-utilities@e1000 {
> + compatible =3D "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2";
> + };
> +
> + L2: l2-cache-controller@c20000 {
> + compatible =3D "fsl,b4860-l2-cache-controller";
> + };
> +};
> diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi=20
> b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> new file mode 100644
> index 0000000..f5737a0
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> @@ -0,0 +1,59 @@
> +/*
> + * B4860 Silicon/SoC Device Tree Source (pre include)
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND=20
> +ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=20
> +IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE=20
> +ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE=20
> +FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL=20
> +DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR=20
> +SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER=20
> +CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,=20
> +OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE=20
> +USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "b4si-pre.dtsi"
> +
> +/ {
> + compatible =3D "fsl,B4860";
> +
> + cpus {
> + cpu1: PowerPC,e6500@1 {
> + device_type =3D "cpu";
> + reg =3D <2 3>;
> + next-level-cache =3D <&L2>;
> + };
> + cpu2: PowerPC,e6500@2 {
> + device_type =3D "cpu";
> + reg =3D <4 5>;
> + next-level-cache =3D <&L2>;
> + };
> + cpu3: PowerPC,e6500@3 {
> + device_type =3D "cpu";
> + reg =3D <6 7>;
> + next-level-cache =3D <&L2>;
> + };
> + };
> +};
> diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi=20
> b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> new file mode 100644
> index 0000000..06c97a2
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> @@ -0,0 +1,262 @@
> +/*
> + * B4420 Silicon/SoC Device Tree Source (post include)
> + *
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * This software is provided by Freescale Semiconductor "as is" and=20
> +any
> + * express or implied warranties, including, but not limited to, the=20
> +implied
> + * warranties of merchantability and fitness for a particular purpose=20
> +are
> + * disclaimed. In no event shall Freescale Semiconductor be liable=20
> +for any
> + * direct, indirect, incidental, special, exemplary, or consequential=20
> +damages
> + * (including, but not limited to, procurement of substitute goods or=20
> +services;
> + * loss of use, data, or profits; or business interruption) however=20
> +caused and
> + * on any theory of liability, whether in contract, strict liability,=20
> +or tort
> + * (including negligence or otherwise) arising in any way out of the=20
> +use of
> + * this software, even if advised of the possibility of such damage.
> + */
> +
> +&ifc {
> + #address-cells =3D <2>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,ifc", "simple-bus";
> + interrupts =3D <25 2 0 0>;
> +};
> +
> +/* controller at 0x200000 */
> +&pci0 {
> + compatible =3D "fsl,b4-pcie", "fsl,qoriq-pcie-v2.4";
> + device_type =3D "pci";
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + bus-range =3D <0x0 0xff>;
> + interrupts =3D <20 2 0 0>;
> + fsl,iommu-parent =3D <&pamu0>;
> + pcie@0 {
> + #interrupt-cells =3D <1>;
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + device_type =3D "pci";
> + interrupts =3D <20 2 0 0>;
> + interrupt-map-mask =3D <0xf800 0 0 7>;
> + interrupt-map =3D <
> + /* IDSEL 0x0 */
> + 0000 0 0 1 &mpic 40 1 0 0
> + 0000 0 0 2 &mpic 1 1 0 0
> + 0000 0 0 3 &mpic 2 1 0 0
> + 0000 0 0 4 &mpic 3 1 0 0
> + >;
> + };
> +};
> +
> +&dcsr {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,dcsr", "simple-bus";
> +
> + dcsr-epu@0 {
> + compatible =3D "fsl,b4-dcsr-epu", "fsl,dcsr-epu";
> + interrupts =3D <52 2 0 0
> + 84 2 0 0
> + 85 2 0 0
> + 94 2 0 0
> + 95 2 0 0>;
> + reg =3D <0x0 0x1000>;
> + };
> + dcsr-npc {
> + compatible =3D "fsl,b4-dcsr-cnpc", "fsl,dcsr-cnpc";
> + reg =3D <0x1000 0x1000 0x1002000 0x10000>;
> + };
> + dcsr-nxc@2000 {
> + compatible =3D "fsl,dcsr-nxc";
> + reg =3D <0x2000 0x1000>;
> + };
> + dcsr-corenet {
> + compatible =3D "fsl,dcsr-corenet";
> + reg =3D <0x8000 0x1000 0x1A000 0x1000>;
> + };
> + dcsr-dpaa@9000 {
> + compatible =3D "fsl,b4-dcsr-dpaa", "fsl,dcsr-dpaa";
> + reg =3D <0x9000 0x1000>;
> + };
> + dcsr-ocn@11000 {
> + compatible =3D "fsl,b4-dcsr-ocn", "fsl,dcsr-ocn";
> + reg =3D <0x11000 0x1000>;
> + };
> + dcsr-ddr@12000 {
> + compatible =3D "fsl,dcsr-ddr";
> + dev-handle =3D <&ddr1>;
> + reg =3D <0x12000 0x1000>;
> + };
> + dcsr-nal@18000 {
> + compatible =3D "fsl,b4-dcsr-nal", "fsl,dcsr-nal";
> + reg =3D <0x18000 0x1000>;
> + };
> + dcsr-rcpm@22000 {
> + compatible =3D "fsl,b4-dcsr-rcpm", "fsl,dcsr-rcpm";
> + reg =3D <0x22000 0x1000>;
> + };
> + dcsr-snpc@30000 {
> + compatible =3D "fsl,b4-dcsr-snpc", "fsl,dcsr-snpc";
> + reg =3D <0x30000 0x1000 0x1022000 0x10000>;
> + };
> + dcsr-snpc@31000 {
> + compatible =3D "fsl,b4-dcsr-snpc", "fsl,dcsr-snpc";
> + reg =3D <0x31000 0x1000 0x1042000 0x10000>;
> + };
> + dcsr-cpu-sb-proxy@100000 {
> + compatible =3D "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
> + cpu-handle =3D <&cpu0>;
> + reg =3D <0x100000 0x1000 0x101000 0x1000>;
> + };
> +};
> +
> +&soc {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + device_type =3D "soc";
> + compatible =3D "simple-bus";
> +
> + soc-sram-error {
> + compatible =3D "fsl,soc-sram-error";
> + interrupts =3D <16 2 1 2>;
> + };
> +
> + corenet-law@0 {
> + compatible =3D "fsl,corenet-law";
> + reg =3D <0x0 0x1000>;
> + fsl,num-laws =3D <32>;
> + };
> +
> + ddr1: memory-controller@8000 {
> + compatible =3D "fsl,qoriq-memory-controller-v4.5", "fsl,qoriq-memory-c=
ontroller";
> + reg =3D <0x8000 0x1000>;
> + interrupts =3D <16 2 1 8>;
> + };
> +
> + cpc: l3-cache-controller@10000 {
> + compatible =3D "fsl,b4-l3-cache-controller", "cache";
> + reg =3D <0x10000 0x1000>;
> + interrupts =3D <16 2 1 4>;
> + };
> +
> + corenet-cf@18000 {
> + compatible =3D "fsl,b4-corenet-cf";
> + reg =3D <0x18000 0x1000>;
> + interrupts =3D <16 2 1 0>;
> + fsl,ccf-num-csdids =3D <32>;
> + fsl,ccf-num-snoopids =3D <32>;
> + };
> +
> + iommu@20000 {
> + compatible =3D "fsl,pamu-v1.0", "fsl,pamu";
> + reg =3D <0x20000 0x4000>;
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + interrupts =3D <
> + 24 2 0 0
> + 16 2 1 1>;
> +
> +
> + /* PCIe, DMA, SRIO */
> + pamu0: pamu@0 {
> + reg =3D <0 0x1000>;
> + fsl,primary-cache-geometry =3D <8 1>;
> + fsl,secondary-cache-geometry =3D <32 2>;
> + };
> +
> + /* AXI2, Maple */
> + pamu1: pamu@1000 {
> + reg =3D <0x1000 0x1000>;
> + fsl,primary-cache-geometry =3D <32 1>;
> + fsl,secondary-cache-geometry =3D <32 2>;
> + };
> +
> + /* Q/BMan */
> + pamu2: pamu@2000 {
> + reg =3D <0x2000 0x1000>;
> + fsl,primary-cache-geometry =3D <32 1>;
> + fsl,secondary-cache-geometry =3D <32 2>;
> + };
> +
> + /* AXI1, FMAN */
> + pamu3: pamu@3000 {
> + reg =3D <0x3000 0x1000>;
> + fsl,primary-cache-geometry =3D <32 1>;
> + fsl,secondary-cache-geometry =3D <32 2>;
> + };
> + };
> +
> +/include/ "qoriq-mpic.dtsi"
> +
> + guts: global-utilities@e0000 {
> + compatible =3D "fsl,b4-device-config";
> + reg =3D <0xe0000 0xe00>;
> + fsl,has-rstcr;
> + fsl,liodn-bits =3D <12>;
> + };
> +
> + rcpm: global-utilities@e2000 {
> + compatible =3D "fsl,b4-rcpm", "fsl,qoriq-rcpm-2";
> + reg =3D <0xe2000 0x1000>;
> + };
> +
> +/include/ "qoriq-dma-0.dtsi"
> + dma@100300 {
> + fsl,iommu-parent =3D <&pamu0>;
> + fsl,liodn-reg =3D <&guts 0x580>; /* DMA1LIODNR */
> + };
> +
> +/include/ "qoriq-dma-1.dtsi"
> + dma@101300 {
> + fsl,iommu-parent =3D <&pamu0>;
> + fsl,liodn-reg =3D <&guts 0x584>; /* DMA2LIODNR */
> + };
> +
> +/include/ "qonverge-usb2-dr-0.dtsi"
> + usb0: usb@210000 {
> + compatible =3D "fsl-usb2-dr-v2.4", "fsl-usb2-dr";
> + fsl,iommu-parent =3D <&pamu1>;
> + fsl,liodn-reg =3D <&guts 0x520>; /* USB1LIODNR */
> + };
> +
> +/include/ "qoriq-espi-0.dtsi"
> + spi@110000 {
> + fsl,espi-num-chipselects =3D <4>;
> + };
> +
> +/include/ "qoriq-esdhc-0.dtsi"
> + sdhc@114000 {
> + sdhci,auto-cmd12;
> + fsl,iommu-parent =3D <&pamu1>;
> + fsl,liodn-reg =3D <&guts 0x530>; /* eSDHCLIODNR */
> + };
> +
> +/include/ "qoriq-i2c-0.dtsi"
> +/include/ "qoriq-i2c-1.dtsi"
> +/include/ "qoriq-duart-0.dtsi"
> +/include/ "qoriq-duart-1.dtsi"
> +/include/ "qoriq-sec5.3-0.dtsi"
> +
> + L2: l2-cache-controller@c20000 {
> + compatible =3D "fsl,b4-l2-cache-controller";
> + reg =3D <0xc20000 0x1000>;
white space issue
> + next-level-cache =3D <&cpc>;
> + };
> +};
> diff --git a/arch/powerpc/boot/dts/fsl/b4si-pre.dtsi=20
> b/arch/powerpc/boot/dts/fsl/b4si-pre.dtsi
> new file mode 100644
> index 0000000..b6161c8
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4si-pre.dtsi
> @@ -0,0 +1,65 @@
> +/*
> + * B4420 Silicon/SoC Device Tree Source (pre include)
> + *
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * This software is provided by Freescale Semiconductor "as is" and=20
> +any
> + * express or implied warranties, including, but not limited to, the=20
> +implied
> + * warranties of merchantability and fitness for a particular purpose=20
> +are
> + * disclaimed. In no event shall Freescale Semiconductor be liable=20
> +for any
> + * direct, indirect, incidental, special, exemplary, or consequential=20
> +damages
> + * (including, but not limited to, procurement of substitute goods or=20
> +services;
> + * loss of use, data, or profits; or business interruption) however=20
> +caused and
> + * on any theory of liability, whether in contract, strict liability,=20
> +or tort
> + * (including negligence or otherwise) arising in any way out of the=20
> +use of
> + * this software, even if advised of the possibility of such damage.
> + */
> +
> +/ {
> + compatible =3D "fsl,B4";
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + interrupt-parent =3D <&mpic>;
> +
> + aliases {
> + ccsr =3D &soc;
> + dcsr =3D &dcsr;
> +
> + serial0 =3D &serial0;
> + serial1 =3D &serial1;
> + serial2 =3D &serial2;
> + serial3 =3D &serial3;
> + pci0 =3D &pci0;
> + dma0 =3D &dma0;
> + dma1 =3D &dma1;
> + sdhc =3D &sdhc;
> + };
> +
> + cpus {
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> +
> + cpu0: PowerPC,e6500@0 {
> + device_type =3D "cpu";
> + reg =3D <0 1>;
> + next-level-cache =3D <&L2>;
> + };
> + };
> +};
> --
> 1.7.6.GIT
>=20
^ permalink raw reply
* RE: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
From: Leekha Shaveta-B20052 @ 2013-04-04 7:03 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Zhao Chenhui-B35336, Mehresh Ramneek-B31383, Garg Vakul-B16394,
Lian Minghuan-B31939, Tang Yuantian-B29983, Fleming Andy-AFLEMING,
Sethi Varun-B16395, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1365007194.25627.1@snotra>
-----Original Message-----
From: Wood Scott-B07421=20
Sent: Wednesday, April 03, 2013 10:10 PM
To: Leekha Shaveta-B20052
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; =
Lian Minghuan-B31939; Garg Vakul-B16394; Tang Yuantian-B29983; Fleming Andy=
-AFLEMING; Mehresh Ramneek-B31383; Sethi Varun-B16395
Subject: Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree=
files for B4860 and B4420
On 04/03/2013 01:42:14 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, April 03, 2013 12:49 AM
> To: Leekha Shaveta-B20052
> Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Lian=20
> Minghuan-B31939; Leekha Shaveta-B20052; Garg Vakul-B16394; Tang=20
> Yuantian-B29983; Fleming Andy-AFLEMING; Mehresh Ramneek-B31383; Sethi
> Varun-B16395
> Subject: Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device=20
> tree files for B4860 and B4420
>=20
> On 04/02/2013 02:16:05 AM, Shaveta Leekha wrote:
> > +/ {
> > + compatible =3D "fsl,B4860";
> > +
> > + cpus {
> > + cpu1: PowerPC,e6500@1 {
> > + device_type =3D "cpu";
> > + reg =3D <2 3>;
> > + next-level-cache =3D <&L2>;
> > + };
> > + cpu2: PowerPC,e6500@2 {
> > + device_type =3D "cpu";
> > + reg =3D <4 5>;
> > + next-level-cache =3D <&L2>;
> > + };
> > + cpu3: PowerPC,e6500@3 {
> > + device_type =3D "cpu";
> > + reg =3D <6 7>;
> > + next-level-cache =3D <&L2>;
> > + };
>=20
> The unit addresses need to match "reg".
> [SL] You mean "@1" should match to "reg =3D <2 3>" ?
Yes, it should be "@2" for that node.
> As each e6500 core in B4860 is dual- threaded, reg property here=20
> represents the thread's identifier in that PA core.
>=20
> So convention used in T4 and B4 is: core 0 having threads 0 and 1,
> Core 1 having <2 3> and
> so on....
The convention used in device trees is that the unit address matches the re=
g.
-Scott
[SL] Ok, I can change that. Will make unit address as @2 for <2 3>, @4 for =
<4 5> and so on....
Kumar, please respond here, as I have followed the convention used in T4 de=
vice tree files for
Dual-threaded cores.
Regards,
Shaveta
^ permalink raw reply
* Re: [PATCH 9/9] powerpc: cpufreq: move cpufreq driver to drivers/cpufreq
From: Amit Kucheria @ 2013-04-04 6:30 UTC (permalink / raw)
To: Viresh Kumar, deepthi
Cc: Robin Randhawa, linux-pm, Liviu Dudau, linux-kernel, cpufreq,
Rafael J. Wysocki, Steve Bannister, Paul Mackerras,
Olof Johansson, Arvind Chauhan, linuxppc-dev, Lists linaro-kernel,
Charles Garcia-Tobin
In-Reply-To: <CAKohpo=EPbGocbNaZcNtGuZy4Tst5jH4rPviQ6L=YuZceDnKMw@mail.gmail.com>
On Thu, Apr 4, 2013 at 11:55 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 3 April 2013 16:00, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>> On Wed, 2013-04-03 at 15:00 +0530, Viresh Kumar wrote:
>>> On 31 March 2013 09:33, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
>>> > Benjamin/Paul/Olof,
>>> >
>>> > Any comments on this?
>>>
>>> Ping!!
>>
>> I'm on vacation until end of April. No objection to the patch but
>> somebody needs to test it.
>
> Hi,
>
> Can somebody else from powerpc world give it a try?
Deepthi, can you help?
> OR
>
> @Rafael: Can we get this pushed in linux-next as is and then people would
> be forced to test it and in case there are any complains, i will fix them or
> you can revert it?
^ permalink raw reply
* Re: [PATCH 9/9] powerpc: cpufreq: move cpufreq driver to drivers/cpufreq
From: Viresh Kumar @ 2013-04-04 6:25 UTC (permalink / raw)
To: Olof Johansson, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki
Cc: robin.randhawa, linux-pm, Liviu.Dudau, linux-kernel, cpufreq,
Steve.Bannister, Arnd Bergmann, arvind.chauhan, linaro-kernel,
charles.garcia-tobin
In-Reply-To: <1364985034.16520.12.camel@pasglop>
On 3 April 2013 16:00, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2013-04-03 at 15:00 +0530, Viresh Kumar wrote:
>> On 31 March 2013 09:33, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> > Benjamin/Paul/Olof,
>> >
>> > Any comments on this?
>>
>> Ping!!
>
> I'm on vacation until end of April. No objection to the patch but
> somebody needs to test it.
Hi,
Can somebody else from powerpc world give it a try?
OR
@Rafael: Can we get this pushed in linux-next as is and then people would
be forced to test it and in case there are any complains, i will fix them or
you can revert it?
^ permalink raw reply
* Re: [PATCH -V5 00/25] THP support for PPC64
From: Simon Jeons @ 2013-04-04 6:14 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev, linux-mm
In-Reply-To: <1365055083-31956-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Hi Aneesh,
On 04/04/2013 01:57 PM, Aneesh Kumar K.V wrote:
> Hi,
>
> This patchset adds transparent hugepage support for PPC64.
>
> TODO:
> * hash preload support in update_mmu_cache_pmd (we don't do that for hugetlb)
>
> Some numbers:
>
> The latency measurements code from Anton found at
> http://ozlabs.org/~anton/junkcode/latency2001.c
>
> THP disabled 64K page size
> ------------------------
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 731.73 cycles 205.77 ns
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 743.39 cycles 209.05 ns
Could you explain what's the meaning of result?
> [root@llmp24l02 ~]#
>
> THP disabled large page via hugetlbfs
> -------------------------------------
> [root@llmp24l02 ~]# ./latency2001 -l 8G
> 8589934592 416.09 cycles 117.01 ns
> [root@llmp24l02 ~]# ./latency2001 -l 8G
> 8589934592 415.74 cycles 116.91 ns
>
> THP enabled 64K page size.
> ----------------
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 405.07 cycles 113.91 ns
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 411.82 cycles 115.81 ns
> [root@llmp24l02 ~]#
>
> We are close to hugetlbfs in latency and we can achieve this with zero
> config/page reservation. Most of the allocations above are fault allocated.
>
> Another test that does 50000000 random access over 1GB area goes from
> 2.65 seconds to 1.07 seconds with this patchset.
>
> split_huge_page impact:
> ---------------------
> To look at the performance impact of large page invalidate, I tried the below
> experiment. The test involved, accessing a large contiguous region of memory
> location as below
>
> for (i = 0; i < size; i += PAGE_SIZE)
> data[i] = i;
>
> We wanted to access the data in sequential order so that we look at the
> worst case THP performance. Accesing the data in sequential order implies
> we have the Page table cached and overhead of TLB miss is as minimal as
> possible. We also don't touch the entire page, because that can result in
> cache evict.
>
> After we touched the full range as above, we now call mprotect on each
> of that page. A mprotect will result in a hugepage split. This should
> allow us to measure the impact of hugepage split.
>
> for (i = 0; i < size; i += PAGE_SIZE)
> mprotect(&data[i], PAGE_SIZE, PROT_READ);
>
> Split hugepage impact:
> ---------------------
> THP enabled: 2.851561705 seconds for test completion
> THP disable: 3.599146098 seconds for test completion
>
> We are 20.7% better than non THP case even when we have all the large pages split.
>
> Detailed output:
>
> THP enabled:
> ---------------------------------------
> [root@llmp24l02 ~]# cat /proc/vmstat | grep thp
> thp_fault_alloc 0
> thp_fault_fallback 0
> thp_collapse_alloc 0
> thp_collapse_alloc_failed 0
> thp_split 0
> thp_zero_page_alloc 0
> thp_zero_page_alloc_failed 0
> [root@llmp24l02 ~]# /root/thp/tools/perf/perf stat -e page-faults,dTLB-load-misses ./split-huge-page-mpro 20G
> time taken to touch all the data in ns: 2763096913
>
> Performance counter stats for './split-huge-page-mpro 20G':
>
> 1,581 page-faults
> 3,159 dTLB-load-misses
>
> 2.851561705 seconds time elapsed
>
> [root@llmp24l02 ~]#
> [root@llmp24l02 ~]# cat /proc/vmstat | grep thp
> thp_fault_alloc 1279
> thp_fault_fallback 0
> thp_collapse_alloc 0
> thp_collapse_alloc_failed 0
> thp_split 1279
> thp_zero_page_alloc 0
> thp_zero_page_alloc_failed 0
> [root@llmp24l02 ~]#
>
> 77.05% split-huge-page [kernel.kallsyms] [k] .clear_user_page
> 7.10% split-huge-page [kernel.kallsyms] [k] .perf_event_mmap_ctx
> 1.51% split-huge-page split-huge-page-mpro [.] 0x0000000000000a70
> 0.96% split-huge-page [unknown] [H] 0x000000000157e3bc
> 0.81% split-huge-page [kernel.kallsyms] [k] .up_write
> 0.76% split-huge-page [kernel.kallsyms] [k] .perf_event_mmap
> 0.76% split-huge-page [kernel.kallsyms] [k] .down_write
> 0.74% split-huge-page [kernel.kallsyms] [k] .lru_add_page_tail
> 0.61% split-huge-page [kernel.kallsyms] [k] .split_huge_page
> 0.59% split-huge-page [kernel.kallsyms] [k] .change_protection
> 0.51% split-huge-page [kernel.kallsyms] [k] .release_pages
>
>
> 0.96% split-huge-page [unknown] [H] 0x000000000157e3bc
> |
> |--79.44%-- reloc_start
> | |
> | |--86.54%-- .__pSeries_lpar_hugepage_invalidate
> | | .pSeries_lpar_hugepage_invalidate
> | | .hpte_need_hugepage_flush
> | | .split_huge_page
> | | .__split_huge_page_pmd
> | | .vma_adjust
> | | .vma_merge
> | | .mprotect_fixup
> | | .SyS_mprotect
>
>
> THP disabled:
> ---------------
> [root@llmp24l02 ~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
> [root@llmp24l02 ~]# /root/thp/tools/perf/perf stat -e page-faults,dTLB-load-misses ./split-huge-page-mpro 20G
> time taken to touch all the data in ns: 3513767220
>
> Performance counter stats for './split-huge-page-mpro 20G':
>
> 3,27,726 page-faults
> 3,29,654 dTLB-load-misses
>
> 3.599146098 seconds time elapsed
>
> [root@llmp24l02 ~]#
>
> Changes from V4:
> * Fix bad page error in page_table_alloc
> BUG: Bad page state in process stream pfn:f1a59
> page:f0000000034dc378 count:1 mapcount:0 mapping: (null) index:0x0
> [c000000f322c77d0] [c00000000015e198] .bad_page+0xe8/0x140
> [c000000f322c7860] [c00000000015e3c4] .free_pages_prepare+0x1d4/0x1e0
> [c000000f322c7910] [c000000000160450] .free_hot_cold_page+0x50/0x230
> [c000000f322c79c0] [c00000000003ad18] .page_table_alloc+0x168/0x1c0
>
> Changes from V3:
> * PowerNV boot fixes
>
> Change from V2:
> * Change patch "powerpc: Reduce PTE table memory wastage" to use much simpler approach
> for PTE page sharing.
> * Changes to handle huge pages in KVM code.
> * Address other review comments
>
> Changes from V1
> * Address review comments
> * More patch split
> * Add batch hpte invalidate for hugepages.
>
> Changes from RFC V2:
> * Address review comments
> * More code cleanup and patch split
>
> Changes from RFC V1:
> * HugeTLB fs now works
> * Compile issues fixed
> * rebased to v3.8
> * Patch series reorded so that ppc64 cleanups and MM THP changes are moved
> early in the series. This should help in picking those patches early.
>
> Thanks,
> -aneesh
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH -V5 00/25] THP support for PPC64
From: Aneesh Kumar K.V @ 2013-04-04 6:10 UTC (permalink / raw)
To: Simon Jeons; +Cc: paulus, linuxppc-dev, linux-mm
In-Reply-To: <515D16E4.8020207@gmail.com>
Simon Jeons <simon.jeons@gmail.com> writes:
> Hi Aneesh,
> On 04/04/2013 01:57 PM, Aneesh Kumar K.V wrote:
>> Hi,
>>
>> This patchset adds transparent hugepage support for PPC64.
>>
>> TODO:
>> * hash preload support in update_mmu_cache_pmd (we don't do that for hugetlb)
>>
>> Some numbers:
>>
>> The latency measurements code from Anton found at
>> http://ozlabs.org/~anton/junkcode/latency2001.c
>
> Is there test case against x86?
>
That test should work even with x86
-aneesh
^ permalink raw reply
* Re: [PATCH -V5 00/25] THP support for PPC64
From: Simon Jeons @ 2013-04-04 6:00 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev, linux-mm
In-Reply-To: <1365055083-31956-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Hi Aneesh,
On 04/04/2013 01:57 PM, Aneesh Kumar K.V wrote:
> Hi,
>
> This patchset adds transparent hugepage support for PPC64.
>
> TODO:
> * hash preload support in update_mmu_cache_pmd (we don't do that for hugetlb)
>
> Some numbers:
>
> The latency measurements code from Anton found at
> http://ozlabs.org/~anton/junkcode/latency2001.c
Is there test case against x86?
>
> THP disabled 64K page size
> ------------------------
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 731.73 cycles 205.77 ns
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 743.39 cycles 209.05 ns
> [root@llmp24l02 ~]#
>
> THP disabled large page via hugetlbfs
> -------------------------------------
> [root@llmp24l02 ~]# ./latency2001 -l 8G
> 8589934592 416.09 cycles 117.01 ns
> [root@llmp24l02 ~]# ./latency2001 -l 8G
> 8589934592 415.74 cycles 116.91 ns
>
> THP enabled 64K page size.
> ----------------
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 405.07 cycles 113.91 ns
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 411.82 cycles 115.81 ns
> [root@llmp24l02 ~]#
>
> We are close to hugetlbfs in latency and we can achieve this with zero
> config/page reservation. Most of the allocations above are fault allocated.
>
> Another test that does 50000000 random access over 1GB area goes from
> 2.65 seconds to 1.07 seconds with this patchset.
>
> split_huge_page impact:
> ---------------------
> To look at the performance impact of large page invalidate, I tried the below
> experiment. The test involved, accessing a large contiguous region of memory
> location as below
>
> for (i = 0; i < size; i += PAGE_SIZE)
> data[i] = i;
>
> We wanted to access the data in sequential order so that we look at the
> worst case THP performance. Accesing the data in sequential order implies
> we have the Page table cached and overhead of TLB miss is as minimal as
> possible. We also don't touch the entire page, because that can result in
> cache evict.
>
> After we touched the full range as above, we now call mprotect on each
> of that page. A mprotect will result in a hugepage split. This should
> allow us to measure the impact of hugepage split.
>
> for (i = 0; i < size; i += PAGE_SIZE)
> mprotect(&data[i], PAGE_SIZE, PROT_READ);
>
> Split hugepage impact:
> ---------------------
> THP enabled: 2.851561705 seconds for test completion
> THP disable: 3.599146098 seconds for test completion
>
> We are 20.7% better than non THP case even when we have all the large pages split.
>
> Detailed output:
>
> THP enabled:
> ---------------------------------------
> [root@llmp24l02 ~]# cat /proc/vmstat | grep thp
> thp_fault_alloc 0
> thp_fault_fallback 0
> thp_collapse_alloc 0
> thp_collapse_alloc_failed 0
> thp_split 0
> thp_zero_page_alloc 0
> thp_zero_page_alloc_failed 0
> [root@llmp24l02 ~]# /root/thp/tools/perf/perf stat -e page-faults,dTLB-load-misses ./split-huge-page-mpro 20G
> time taken to touch all the data in ns: 2763096913
>
> Performance counter stats for './split-huge-page-mpro 20G':
>
> 1,581 page-faults
> 3,159 dTLB-load-misses
>
> 2.851561705 seconds time elapsed
>
> [root@llmp24l02 ~]#
> [root@llmp24l02 ~]# cat /proc/vmstat | grep thp
> thp_fault_alloc 1279
> thp_fault_fallback 0
> thp_collapse_alloc 0
> thp_collapse_alloc_failed 0
> thp_split 1279
> thp_zero_page_alloc 0
> thp_zero_page_alloc_failed 0
> [root@llmp24l02 ~]#
>
> 77.05% split-huge-page [kernel.kallsyms] [k] .clear_user_page
> 7.10% split-huge-page [kernel.kallsyms] [k] .perf_event_mmap_ctx
> 1.51% split-huge-page split-huge-page-mpro [.] 0x0000000000000a70
> 0.96% split-huge-page [unknown] [H] 0x000000000157e3bc
> 0.81% split-huge-page [kernel.kallsyms] [k] .up_write
> 0.76% split-huge-page [kernel.kallsyms] [k] .perf_event_mmap
> 0.76% split-huge-page [kernel.kallsyms] [k] .down_write
> 0.74% split-huge-page [kernel.kallsyms] [k] .lru_add_page_tail
> 0.61% split-huge-page [kernel.kallsyms] [k] .split_huge_page
> 0.59% split-huge-page [kernel.kallsyms] [k] .change_protection
> 0.51% split-huge-page [kernel.kallsyms] [k] .release_pages
>
>
> 0.96% split-huge-page [unknown] [H] 0x000000000157e3bc
> |
> |--79.44%-- reloc_start
> | |
> | |--86.54%-- .__pSeries_lpar_hugepage_invalidate
> | | .pSeries_lpar_hugepage_invalidate
> | | .hpte_need_hugepage_flush
> | | .split_huge_page
> | | .__split_huge_page_pmd
> | | .vma_adjust
> | | .vma_merge
> | | .mprotect_fixup
> | | .SyS_mprotect
>
>
> THP disabled:
> ---------------
> [root@llmp24l02 ~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
> [root@llmp24l02 ~]# /root/thp/tools/perf/perf stat -e page-faults,dTLB-load-misses ./split-huge-page-mpro 20G
> time taken to touch all the data in ns: 3513767220
>
> Performance counter stats for './split-huge-page-mpro 20G':
>
> 3,27,726 page-faults
> 3,29,654 dTLB-load-misses
>
> 3.599146098 seconds time elapsed
>
> [root@llmp24l02 ~]#
>
> Changes from V4:
> * Fix bad page error in page_table_alloc
> BUG: Bad page state in process stream pfn:f1a59
> page:f0000000034dc378 count:1 mapcount:0 mapping: (null) index:0x0
> [c000000f322c77d0] [c00000000015e198] .bad_page+0xe8/0x140
> [c000000f322c7860] [c00000000015e3c4] .free_pages_prepare+0x1d4/0x1e0
> [c000000f322c7910] [c000000000160450] .free_hot_cold_page+0x50/0x230
> [c000000f322c79c0] [c00000000003ad18] .page_table_alloc+0x168/0x1c0
>
> Changes from V3:
> * PowerNV boot fixes
>
> Change from V2:
> * Change patch "powerpc: Reduce PTE table memory wastage" to use much simpler approach
> for PTE page sharing.
> * Changes to handle huge pages in KVM code.
> * Address other review comments
>
> Changes from V1
> * Address review comments
> * More patch split
> * Add batch hpte invalidate for hugepages.
>
> Changes from RFC V2:
> * Address review comments
> * More code cleanup and patch split
>
> Changes from RFC V1:
> * HugeTLB fs now works
> * Compile issues fixed
> * rebased to v3.8
> * Patch series reorded so that ppc64 cleanups and MM THP changes are moved
> early in the series. This should help in picking those patches early.
>
> Thanks,
> -aneesh
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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